Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rescaled PIXAR_xx keywords may be inaccurate in resampled images #7668

Closed
stscijgbot-jp opened this issue Jun 29, 2023 · 15 comments · Fixed by #7894
Closed

Rescaled PIXAR_xx keywords may be inaccurate in resampled images #7668

stscijgbot-jp opened this issue Jun 29, 2023 · 15 comments · Fixed by #7894

Comments

@stscijgbot-jp
Copy link
Collaborator

Issue JP-3035 was created on JIRA by Howard Bushouse:

Help Desk ticket INC0184650 suggests that the rescaled values of the PIXAR_SR and PIXAR_A2 keywords in resampled images may not be correct. This could be due to the fact that the rescaling is done from the average pixel area given in distorted images, whereas for resampled images it would be more accurate to compute it from scratch for a pixel near the output WCS reference point (i.e. near CRPIX1, CRPIX2).

@stscijgbot-jp
Copy link
Collaborator Author

Comment by Howard Bushouse on JIRA:

Tracked in github via #7390

@stscijgbot-jp
Copy link
Collaborator Author

Comment by Howard Bushouse on JIRA:

From Mihai Cara :

"I think that there may be a bug in how resampled pixel scale is computed in #⁠7033. The issue is that the code from #⁠7033 rescales average pixel scale while the code used to compute actual output/resampled pixel scale that is used to construct the actual output WCS computes (see compute_scale) pixel scale near CRPIX and re-scales that value. Pixel scale near CRPIX is not the same as the mean pixel scale stored in PIXAR_SR. So, I think both PIXAR_SR and PIXAR_A2 are most likely incorrect in the sense that they do not represent actual pixel scale of the output WCS."

@stscijgbot-jp
Copy link
Collaborator Author

Comment by Howard Bushouse on JIRA:

Mihai Cara Nadia Dencheva could one of our friends in Periwinkle look into this issue in the near future? 

@stscijgbot-jp
Copy link
Collaborator Author

Comment by Nadia Dencheva on JIRA:

Howard Bushouse No one is available next sprint but I'll put it at the top of the list of things to do next.

@stscijgbot-jp
Copy link
Collaborator Author

Comment by Howard Bushouse on JIRA:

Nadia Dencheva Just a gentle reminder to not forget about this one. Would be nice to get into DMS B9.2 yet, if possible.

@stscijgbot-jp
Copy link
Collaborator Author

stscijgbot-jp commented Sep 10, 2023

Comment by Mihai Cara on JIRA:

After reading the documentation for these keywords, I have more questions in order to figure out the best way of solving this issue.

Where can I find the source code that computes pixel area map? How does it work? Is it based on the WCS? If so, what WCS is used for this and at what stage.

Documentation uses "the absolute value of the nominal pixel area". What does nominal mean here in the context of pixel area?

In https://jira.stsci.edu/browse/JP-1757 James says ??"these represent a "nominal" pixel area in the unrectified data, often taken to be the area of the pixel at either aperture reference point or the distortion model reference point."?? That is one possible interpretation.

Previous interpretation is in direct conflict with another description from the the documentation for these keywords: ??"The primary header of the tabular PHOTOM reference files contains the keywords PIXAR_SR and PIXAR_A2, which give the average pixel area in units of steradians and square arcseconds, respectively."??

Another important aspect of this is how are these keywords used? If they can be used on CAL files to convert image data to flux units (and as we know actual pixel area varies across the image in CAL images) then they may be "nominal" in the sense that CAL data have been flat-field corrected relative to these "nominal" values so that a pixel at any location when multiplied by PIXAR_SR will result in the correct flux. Is this picture correct?

Implementing correct rescaling of these keywords in the resample step depends on the precise definition and intended usage.

@stscijgbot-jp
Copy link
Collaborator Author

Comment by Mihai Cara on JIRA:

Another important question, CC: Howard Bushouse , Nadia Dencheva :

Can ever resample step (in the pipeline or custom user processing) have input images that with different PIXAR_* values?

@stscijgbot-jp
Copy link
Collaborator Author

Comment by Howard Bushouse on JIRA:

Mihai Cara For the purpose of this ticket, which is concerned with setting the values of the PIXAR_xx keywords in resampled images, I think it would be fine to compute the values based on the pixel area at the tangent reference point of the resampled image (i.e. at the location of CRPIX1, CRPIX2, or equivalent). Because they're resampled, the pixel area should vary much more slowly than in distorted images (I guess for really big mosaics it'll tend to vary somewhat from center to edge?). So don't base the values on a rescaled version of the input keyword values, but rather just compute it from the output resampled image, if that's doable. That way you also don't have to worry about whether any of the inputs had different values of PIXAR_xx (probably a very rare case, but I guess it could happen?).

@stscijgbot-jp
Copy link
Collaborator Author

stscijgbot-jp commented Sep 12, 2023

Comment by Mihai Cara on JIRA:

Based on my current intuition about questions I asked on 09/10/2023, I believe that James and some parts of the documentation are correct that PIXAR_* are computed at some (arbitrary or not) position in the chip. So, these values are correct only at one location and do not represent average pixel area as also described in the docs. The reason for me to believe this is that no matter what method for computing average pixel area I use, I get the same value that is quite different (>=5%) from PIXAR_*

Figuring out the output pixel scale is not difficult indeed: first, it may be possible to find it from our functions since we are constructing it (but this will not work when user provides 'output_wcs') or as you mention, it does not matter where we compute it since output images are not distorted.

The issue is that we need to compute (according to my understanding of what drizzle is doing and my derived formulas to compute correct PIXAR_* values for the resampled image) the actual average pixel scale of input images. I am imagining that some could have different average pixel scales and so I believe the process of computing output PIXAR_* must be done in a way that takes this into account.

Finally, while it is OK for input distorted images to have been calibrated in a way that requires a "nominal" PIXAR defined at an arbitrary location in the chip, for the output image it would be very strange if PIXAR_* would not correspond to the average pixel area (or pixel area anywhere in the image since all pixels in the output image essentially have the same pixel area). That is, I think PIXAR_* in the output image must represent the true pixel scale. Do you agree?

@stscijgbot-jp
Copy link
Collaborator Author

Comment by Howard Bushouse on JIRA:

Mihai Cara Agree. The purpose of the PIXAR_xx keyword values in the resampled images is NOT to estimate or record a history of what the values were in the input images. All they need to represent is the true pixel area in the resampled image, period.

@stscijgbot-jp
Copy link
Collaborator Author

Comment by Howard Bushouse on JIRA:

Fixed by #7894

@stscijgbot-jp
Copy link
Collaborator Author

Comment by Alicia Canipe on JIRA:

Howard Bushouse or Clare Shanahan, now that this issue is resolved, should we pass the info along to Pier and resolve the help desk ticket? It's currently "on hold". I was pondering next steps for this one, since it's in the "Ready for Testing" phase

@stscijgbot-jp
Copy link
Collaborator Author

Comment by Howard Bushouse on JIRA:

Alicia Canipe Yes, that sounds appropriate.

@stscijgbot-jp
Copy link
Collaborator Author

Comment by Misty Cracraft on JIRA:

These are the results from some testing on MIRI rescaled images.

Combining 5 F770W MIRI images.

Sample input cal file PIXAR keywords:

PIXAR_SR= 2.84403609523084E-13 / Nominal pixel area in steradians              

PIXAR_A2=               0.0121 / Nominal pixel area in arcsec^2                

 

Combined image, no scaling specified:

PIXAR_SR= 2.89107770927621E-13 / Nominal pixel area in steradians              

PIXAR_A2=  0.01230013934805663 / Nominal pixel area in arcsec^2                

 

Specify resample pixel scale of 0.06 “/pix

PIXAR_SR= 8.46159499407524E-14 / Nominal pixel area in steradians              

PIXAR_A2= 0.003600000000000001 / Nominal pixel area in arcsec^2         

 

Given that I specified an output scaling of 0.06 " with the pixel_scale keyword for resampling, it looks like the last set of PIXAR keywords is correct, but how do I know if the initial set with no scale value specified is correct?      

@stscijgbot-jp
Copy link
Collaborator Author

Comment by David Law on JIRA:

I just tested this as well with a random MIRI image run through resample with old and new pipeline versions, computing the pixel area from the square of the CDELT keywords and comparing to the reported PIXAR values.  Old values were incorrect, new values are correct.  With that plus Misty Cracraft 's test for specific input pixel scale that should mean this ticket can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants