You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of JP-3169, extraction keywords were added to the x1d headers. Additional information about the extraction box locations on the full frame image would be useful, and are contained in the cal files currently.
As the code is currently written for NIRISS WFSS, it appears that the new keyword "EXTRYSTP" is always equivalent to the y size of the cutout which is equivalent to the cal file keyword "SLTSIZE2" (and EXTRXSTP = SLTSIZE1 = x size of cutout). There is potential for this to be a value add to not have to go back to the cal file for this information, especially in having to identify the correct extension between the cal and x1d files, but what is missing from this new x1d header is the starting location of the slit on the full frame grism image (SLTSTRT2 / SLTSTRT1 in the cal files).
For a random source in a random file,
in the cal file:
SLTSTRT1= 457 / Starting pixel in x direction
SLTSIZE1= 1335 / Number of pixels in x direction
SLTSTRT2= 48 / Starting pixel in y direction
SLTSIZE2= 755 / Number of pixels in y direction
SOURCEID= 25 / Source ID
SRCXPOS = 1249.6156515288842 / Source position in slit (x-axis)
SRCYPOS = 370.8518033884632 / Source position in slit (y-axis)
From this I'm able to go to the grism image and see what source is at (457, 755) and look to see if maybe the slit is miscentered or needs to be adjusted on the full frame rate image
in the x1d file:
SRCXPOS = 1249.6156515288842 / Source position in slit (x-axis)
SRCYPOS = 370.8518033884632 / Source position in slit (y-axis)
EXTRXSTR= 1 / X axis start of extraction region
EXTRXSTP= 1335 / X axis end of extraction region
EXTRYSTR= 1 / Y axis start of extraction region
EXTRYSTP= 755 / Y axis end of extraction region
From this I can only tell how big the cutout is and where the center of the source is. I still need to go back to the cal image to find where the start of the cutout actually is.
It would be great to be able to go from the x1d directly to the grism image, and I think only the starting x and y pixel positions are needed for that additional information, but I don't have a good grasp on 1) if that information is stored going into extract_1d and 2) how that would translate for the other modes.
This may relate also to some of the intermediate WFSS products, although I think that both can occur and both be of value.
The text was updated successfully, but these errors were encountered:
Issue JP-3751 was created on JIRA by Rachel Plesha:
As part of JP-3169, extraction keywords were added to the x1d headers. Additional information about the extraction box locations on the full frame image would be useful, and are contained in the cal files currently.
As the code is currently written for NIRISS WFSS, it appears that the new keyword "EXTRYSTP" is always equivalent to the y size of the cutout which is equivalent to the cal file keyword "SLTSIZE2" (and EXTRXSTP = SLTSIZE1 = x size of cutout). There is potential for this to be a value add to not have to go back to the cal file for this information, especially in having to identify the correct extension between the cal and x1d files, but what is missing from this new x1d header is the starting location of the slit on the full frame grism image (SLTSTRT2 / SLTSTRT1 in the cal files).
For a random source in a random file,
in the cal file:
From this I'm able to go to the grism image and see what source is at (457, 755) and look to see if maybe the slit is miscentered or needs to be adjusted on the full frame rate image
in the x1d file:
From this I can only tell how big the cutout is and where the center of the source is. I still need to go back to the cal image to find where the start of the cutout actually is.
It would be great to be able to go from the x1d directly to the grism image, and I think only the starting x and y pixel positions are needed for that additional information, but I don't have a good grasp on 1) if that information is stored going into extract_1d and 2) how that would translate for the other modes.
This may relate also to some of the intermediate WFSS products, although I think that both can occur and both be of value.
The text was updated successfully, but these errors were encountered: