Closed stscijgbot-jp closed 8 months ago
stscijgbot-jp
commented
10 months ago Comment by Misty Cracraft on JIRA:
The MIRI area file has one value of PIXAR* keywords in the header. We only have one area file and the one set of keyword values which should match what we have in the photom files. So this is not an issue for MIRI. Whether we pull the value from the area or photom files, it's the same.
stscijgbot-jp
commented
10 months ago Comment by Howard Bushouse on JIRA:
I'm not sure that the statement "there is some utility in having a common PIXAR_A2/PIXAR_SR pair of values between the different filters so that the resampled products in level 3 are on a common pixel scale" is correct, in that I don't think the PIXAR keyword values get used at all during resampling in order to set the output pixel scale. Need Mihai Cara to confirm how the output (resampled) pixel scale is set for imaging modes.
stscijgbot-jp
commented
10 months ago Comment by Bryan Hilbert on JIRA:
This issue has also been reported in https://jira.stsci.edu/browse/JP-3247
stscijgbot-jp
commented
10 months ago Comment by Kevin Volk on JIRA:
I am assuming that the cal file PIXAR_A2 value or PIXAR_SR value is used in the resampling step to set the pixel size; but whether it comes from there or from the pixel area map file it still is an open question as to whether the pixel area should be made common between the filters.
stscijgbot-jp
commented
10 months ago Comment by Mihai Cara on JIRA:
??I'm not sure that the statement "there is some utility in having a common PIXAR_A2/PIXAR_SR pair of values between the different filters so that the resampled products in level 3 are on a common pixel scale" is correct, in that I don't think the PIXAR keyword values get used at all during resampling in order to set the output pixel scale.??
stscijgbot-jp
commented
10 months ago Comment by Kevin Volk on JIRA:
Still, the question remains: should the pixel areas from the WCS, which come from the distortion solution, be matched between filters? The other practical question is what to do about the PIXAR_A2/PIXAR_SR keywords if these are not used in the resampling, because users will still interpret them as the square of the pixel scale given what they say they are.
stscijgbot-jp
commented
10 months ago Comment by Mihai Cara on JIRA:
question remains: should the pixel areas from the WCS, which come from the distortion solution, be matched between filters?
For what purpose? resampling definitely does not need this and it will have no effect on resampled data.
Second part of the question - I don't know. I do not think I understand the question. PIXAR_A2/PIXARSR is a "{+}nominal{+}" pixel area whatever this means (I understand it as pixel area at some pre-determined location). Distorted pixels in "cal" images are not square but it is reasonable to interpret them as "square of the pixel scale" {}at a the nominal location{_}. ... as an approximation. But they are pixel area of distorted pixels.
stscijgbot-jp
commented
10 months ago Comment by Kevin Volk on JIRA:
The PIXAR_A2 and PIXAR_SR values in the pixel area map files are the mean value over the imaging pixels used to normalize the map to 1.0, and this is vital for the interpretation of the area map values. I am still not clear exactly where the resampled pixel area comes from. It must come from somewhere.
For the second part, there is some utility in having the pixel grid the same for different filters to allow direct pixel-by-pixel comparison of the surface brightness values in extended sources rather than having to resample say the F090W i2s filter image to match a i2d F115W filter image before doing the comparison.
It is the case of extended emission that lead to the question of a common pixel area when we discussed this in the NIRISS imaging sub-group. For point sources it does not matter as long as the correct conversion from MJy/ster to Jansky is used, which has to be consistent between the photom file and the source_catalog step.
stscijgbot-jp
commented
10 months ago Comment by Mihai Cara on JIRA:
??The PIXAR_A2 and PIXAR_SR values in the pixel area map files are the mean value over the imaging pixels used to normalize the map to 1.0??
Are you sure? Have you tried computing the actual pixel area for every pixel in the image and the mean value of those pixel area values equal to PIXAR_A2 and PIXAR_SR? When I performed this test, I was not successful: PIXAR_A2 and PIXAR_SR are quite different from the mean pixel area. Maybe I did something wrong and so an independent verification would be great but my conclusion was that PIXAR_A2 and PIXAR_SR do not correspond to mean values.
stscijgbot-jp
commented
10 months ago Comment by Kevin Volk on JIRA:
The area map is calculated from the distortion coefficients, and yes the code does use the distortion to calculate the pixel area for each pixel over the 2048x2048 grid of the detector and averages these values. I have done it two ways: one by just sampling the pixel corners at each pixel and calculating the area, and the other by applying a differential area calculation directly from the coefficients. These agree to the machine precision. It should be OK.
stscijgbot-jp
commented
10 months ago Comment by Mihai Cara on JIRA:
I just tested an old NIRISS image and indeed, the agreement between computed mean area and PIXAR_SR is very good. For NIRCAM, I was getting 1.6% difference. So, it seems like different instruments have different definitions for PIXAR_SR
stscijgbot-jp
commented
10 months ago Comment by Kevin Volk on JIRA:
I have put this ticket as NIS-medium priority for the moment. Nominally this is an issue with only a small science impact for which there is an easy work-around, which would mean urgency = 2, criticality = 2 and the assignment would be NIS-low. But this I think is misleading. Yes users can simply substitute the correct mean pixel area value into the header based on the instrument, which is a simple work-around. The science impact is small because the change in the mean pixel area is relatively small from filter to filter. However I think it is a bad idea to be leaving in a systematic error of this sort in all the NIRISS imaging data when we can fix it fairly easily, I believe, in the code. Even if the systematic effects are small, users are pushing the data to get precise measurements and it can impact the science results.
As well, it is highly likely that the users are making their own source catalogues from the resampled images rather than just using the pipeline product, and they are very likely to just use the pixel area in the header for the conversion from MJy/ster to Jansky. It is not obvious to me that we can communicate to all NIRISS users the need for fixing this header value before doing any photometric measurements.
stscijgbot-jp
commented
8 months ago Comment by Howard Bushouse on JIRA:
Closing this ticket, because it's a duplicate of JP-3247, which is being worked for DMS B10.2.
Issue JP-3454 was created on JIRA by Kevin Volk:
In looking at some recently re-reduced NIRISS photometry data, I discovered that the PIXAR_A2/PIXAR_SR values in the header of the cal.fits files are all the same for the 12 NIRISS imaging filters. However, in the pixel area map files these values are slightly different for each filter as determined from the observations of the astrometric field. This is an inconsistency. Paul Goudfrooij looked at the photom code lines 1048-1118, in the "save_area_info" routine, and discovered that the code reads the pixel area reference files to the attribute of the science data model, but it then reads the PIXAR_A2 and PIXAR_SR values from the imaging photom reference file header and assigns these to the science image. For NIRISS the value in the photom reference file header is specifically that for the F150W filter, which is the one used in the SIAF and is also the reference for the filter-to-filter WCS offsets. This is why all the PIXAR_A2 values are the same for the different filters, since the imaging photom file is not tabulating the individual average pixel areas of the filters.
This introduces an inconsistency in the photometry values since the calibration is to MJy/ster and one needs to use the proper PIXAR_SR value in converting from Jansky/(ADU/s), which is what is measured from the standard star observations, to the (MJy/ster)/(ADU/s) units. The differences in the PIXAR_A2 values between the different NIRISS filters are not large, but nonetheless this is a problem in the photometric calibration. This also potentially affects the source_catalog values where the flux density values in Jansky are calculated from the resampled images. For NIRISS I create the photom values using the PIXAR_SR values in the header of the cal files for each filter, and the pipeline presumably does the inverse of this in making the source catalogue, so these actually cancel out right now and the values in Jansky should be OK. But for any comparison of the surface brightness values between filters this means there is a small error in the values from one filter to another, except for F150W.
I am flagging this for all the imaging modes because the photom code is common to all instruments. I have not gone to look at the pixel area maps for NIRCam or MIRI to see whether they have different PIXAR_A2/PIXAR_SR values between different filters. So maybe this does not actually apply to all the instruments.
Finally, I note that there is some utility in having a common PIXAR_A2/PIXAR_SR pair of values between the different filters so that the resampled products in level 3 are on a common pixel scale when users wish to compare the images. This has been noted in a JP ticket as I recall, although I do not remember the number off hand. So we may need to weigh the pros and cons of having a single mean pixel area value and rescaling the pixel area maps slightly to have mean values that are not exactly 1.0, or keeping the current situation where the mean area values are different from filter to filter. This may need some discussion in the pipeline working group.