Closed stscieisenhamer closed 5 years ago
Dependent on issues #598 #239 #639
This will be the direct image exposures.
This will be the grism exposures, including the catalog and segmentation map produced by the image3 processing of the direct images.
Produce the direct uber-image, catalog , and segmentation image for use as input to the Level2 Spectral processing. Since an uber-image will not be done for 7.3, a catalog will be used from the potential list of catalogs available. An attempt will be made to associate the "closest" catalog to their respective grism observations, as determined by APT. "Closest" means the first direct image taken after the grism exposure in question.
Produce the source-based spectrum files.
item
attributeAssociation.have_items
to be a property to look through the members.item
Association.finalize
collect all the direct_image
members and determine the right catalog name.Constructing the level-3 direct image ASN will be a bit tricky. The Grism Working Group wants to first produce a combined direct image for each different filter that was used for the direct images, and then a special routine does the combining of those images into the uber image. So we may need to specify output product names for the filter-specific products (images, source catalogs, segmentation maps), and the uber products (final uber image and the source catalog and segmentation map resulting from it). So perhaps a scheme in which we define multiple products, such as:
[prod-filter1]
name = <...>_filter1_i2d.fits
[members]
filter1-exp1
filter1-exp2
...
[prod-filter2]
name = <...>_filter2_i2d.fits
[members]
filter2-exp1
filter2-exp2
...
[prod-filter<n>]
...
[prod-uber]
name = <...>_uber_i2d.fits
[members]
<...>_filter1_id2.fits
<...>_filter2_id2.fits
...
This can be done. Or, does calwebb_image3
want just a single list and it sorts out the filter stuff itself?
Right now I think that calwebb_image3 assumes there'll be only 1 product specified and works on just the first one, but that could easily be expanded to loop over products.
What is an "Out Of Field" image? For NIRCam grism, this is part of the sequence. Does it need to be in any association?
Updated information - we no longer need the segmentation map in the association, only the uber image and uber source catalog are being saved. The source catalog itself will contain the bounding box information for the objects - and this will be used by the grism pipeline. https://github.com/STScI-JWST/jwst/issues/739#issuecomment-328912868
out-of-field image -> is this one of the grisms or a member of the association that created the mosaic direct image which the catalog was made from?
or is out-of-field image an orphan member of the association that doesn't connect on-the-sky to any other exposures of that area?
In the example proposal we have, in the exposure sequence, there is an exposure type listed as 'out-of-image'. when looking at the sql, these exposures occur at the end of the first grism, and if 'both' is specified, they appear between the two grisms. hence, they seem to exist, but don't know the purpose or science to them.
ahh, I think it's these expsosures, which are used probably for contamination measurements laters?
Direct images occur automatically at the end of the dither sequence and three positions are imaged: one at the final dither position, and two additional fields in each direction parallel to the dispersion axis to cover the out-of-field sources.
from here: https://jwst-docs.stsci.edu/display/JTI/NIRCam+Wide+Field+Slitless+Spectroscopy
That's not necessarily contamination, it could be useful data, just with the undispersed target off the detector.
That too, but they know that off image objects, outside of the imaging FOV, are getting dispersed onto the detector when the grism is in use and they need to figure out where that light originated. In any case, It's probably best to get the team to specify how they want the pipeline to handle these images. :smile:
I'm guessing they would be part of the list of direct image exposures that become members of the level-2 and level-3 direct image ASN's, so that the final combined image from calimage3 covers additional area outside the grism FOV and hence those slightly off-FOV targets will get detected and included in the source catalog. calspec2 can then choose to do whatever it wants with those sources in the catalog.
Presuming "out-of-field" are just more "direct image" is actually a good thing. Otherwise, there appears to be no way to distinguish between the actual direct images and the out-of-field images. The only difference would be the dithers involved. If we need to depend on dither differences, that would make a very fragile system. Its possible the dither pattern indicator may help on that, but would have to see actual data to confirm.
Further clarification/status: APT does denote the intent difference between the direct and out-of-field images. However, it is recorded in a field, apt label, that has had a sordid history and is on the verge of being eliminated completely. Currently in discussion with APT developers where it is recognized that this should actually not be the case. A PR will be filed shortly to document/implement an appropriate solution. This will most likely take a bit of time.
Related to #239 but otherwise no specifics yet.