Closed mcara closed 9 years ago
The number of missed pixels and skipped lines is the number of pixels or lines on the output image where there was no overlap by the input image. This is the same definition that was used in the older version of the code.
So, since there is no skew, the number of skipped lines is 256 - 100 = 156 and the number of missed pixels is 256^2 - 100^2 = 55536, which is the result drizzle.tdriz reports.
However, the docstring says:
Returns:
A tuple with three values: a version string, the number of pixels
on the input image that are not on the output image, and the number
of complete lines on the input image not on the output image.
May be my English is not good, but "the number of pixels on the input image that are not on the output image" tells me that the returned number is the number of pixels in the input image. Same goes for the number of "complete lines".
Oh, the documentation is wrong then and it will be handled as a documentation error.
I changed the comment about the return value from dodrizzle to match what the code actually does.
Yet, I am not convinced that this is a simple documentation error. The original drizzle (from drizzlepac) behaves as documented:
>>> import numpy as np
>>> inmask=np.zeros((100,100),dtype=np.float32)
>>> inmask[22:25,33:49]=1
>>> inwht=np.ones_like(inmask,dtype=np.float32)
>>> outsci=np.zeros((256,256),dtype=np.float32)
>>> outwht=np.zeros((256,256),dtype=np.float32)
>>> outctx=np.zeros((256,256),dtype=np.int32)
>>> in_y, in_x = np.indices((100,100), dtype=np.float64)
>>> pixmap = np.dstack((in_y,in_x))
>>> from drizzlepac import cdriz
The following tasks in the stwcs.gui package can be run with TEAL:
apply_headerlet archive_headerlet attach_headerlet
delete_headerlet extract_headerlet headerlet_summary
restore_headerlet updatewcs write_headerlet
The following task in the fitsblender package can be run with TEAL:
blendheaders
The following task in the stsci.skypac package can be run with TEAL:
skymatch
The following tasks in the drizzlepac package can be run with TEAL:
astrodrizzle imagefindpars mapreg pixreplace
pixtopix pixtosky refimagefindpars resetbits
skytopix tweakback tweakreg updatenpol
>>> cdriz.tdriz(inmask,inwht,outsci,outwht,outctx,0,0,1,1,inmask.shape[0],
... 1.0,1.0,1.0,'center',1.0,'square','counts',1,1,'',
... 0,0,1,lambda x,y: (x,y))
('Callable C-based DRIZZLE Version 0.8 (20th May 2009)', 0, 0)
>>> np.any(outsci>0)
True
>>> np.sum(outsci>0)
48
and it correctly (i.e., in agreement with its documentation) reports that no rows or pixels from the input image were missed.
If the change in behavior of tdriz
was intentional, what was the reason for it? I seems that it is more important to know that pixels from the input image were missed as opposite to knowing that drizzle had to use 'fillval' on some pixels in the output image...
The comment documents the way the code acts now. I reviewed the original code to see if there was a difference and couldn't see any, but the code was complex and perhaps I misunderstood it? The real question is which statistic is more useful, are both equally useful, or is the result irrelevant?
All previous versions of drizzle used to report the number of missed pixels in the input frame. The reason for this is that it is a useful diagnostic tool too see how much of the input image did not fit into the output frame. On the other hand, what does the number of pixels for which drizzle have used 'fillval' (which is what this drizzle is now reporting) tells me? For most practical cases drizzle will have to set some pixels to 'fillval'. We know that... Do we really need to know how many pixels have been set to 'fillval'?
I honestly don't know why one would be more useful than another, which is why I asked.
Since issue #1 was closed, I am opening a new issue here. It seems that the problems described in issue #1 have been addressed in the sense that 1) I cannot get it to crash (at least not yet); and 2) there are expected number of pixels != 0 in the output image. However, the number of pixels reported as "missing" and the number of skipped lines (second and third values in the returned tuple) make no sense:
First of all, I am drizzling 100x100 image onto a 256x256 output image using a mapping represented by an identity transformation (so pixel [11,15] should be mapped directly to pixel [11,15] in the output image).
Second, there are only 100 "complete lines" in my input image. How can
tdriz
report that it could not map 156 lines from my input image???Third, the number of missed pixels (second value in the tuple) also does not make sense. There should not be any missed pixels at all (due to this specific mapping used in my example). To verify that
tdriz
indeed does not miss anything, I changed the fillval to '0' and set my input array to ones:So, "flux" in the output image is, as expected, 10000=100x100. So, how come I have missed 55536 pixels from my input image?