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

Add option to use flat regions of reference background for WFSS bkg subtraction step #9007

Open
stscijgbot-jp opened this issue Dec 13, 2024 · 3 comments

Comments

@stscijgbot-jp
Copy link
Collaborator

Issue JP-3818 was created on JIRA by Ned Molter:

Based on a suggestion from Norbert Pirzkal on the linked ticket JP-1136, it should be made possible to select certain regions of the reference background to use for background subtraction.  His comment on that ticket reads,

We (NIRCam) have been working on empirical backgrounds. While we assumed that there would be a pointing and potentially a time variation to the sky spectrum that gets dispersed to form the background, we do not yet have a set of models that properly reflects that. The direct consequence of this is that the "inflection" in the shape of the background in the dispersion direction is not a perfect match to what is observed in specific cases. This brings up the point that we should be considering, in my opinion, allowing for the scaling (as we defined earlier and using the variance of each pixel) to be computed either other the full detector OR only using the region of the detector where the background is know to be flat. This is because trying to scale the whole background can result in a slight (1-2%) over subtraction of the background in the flat most region (as it is the overall background residuals that average zero by our mathematical construct). Since most of the fully dispersed spectra are over that region, it is possible, if not likely, that some users might prefer the residuals in this "high value" region of the detector to be as good as possible (to detect fainter sources for example). So I would suggest that an option exists to compute the scale over the whole detector (default) OR using only the regions where the background is flat (see the yellow regions in the plots show at https://jwst-docs.stsci.edu/jwst-near-infrared-camera/nircam-performance/nircam-wfss-backgrounds#gsc.tab=0])

@stscijgbot-jp
Copy link
Collaborator Author

Comment by Ned Molter on JIRA:

Norbert Pirzkal thanks for suggesting this feature.  It'll probably fall to me to implement this one too, although leaving the ticket assigned to David for now so it can get assigned a prioritization.

How do you suggest we determine the "flat" regions of the background?  Were you thinking that this information would be passed in via reference files, or is there a straightforward way to figure this out on-the-fly for all filters?

@stscijgbot-jp
Copy link
Collaborator Author

Comment by Norbert Pirzkal on JIRA:

Good question. This information is already tabulated somewhere since APT is able to actually show these regions on the detectors. Otherwise, what I have done in the past, was to take the model of the background and simply use the region where the background model is close to unity. But that latter approach is maybe harder to implement correctly than just use pre computed values. As shown in Table 2 of https://jwst-docs.stsci.edu/jwst-near-infrared-camera/nircam-performance/nircam-wfss-field-of-view#gsc.tab=0

I am not expecting this to be a default use, as I mentioned in my earlier post so it probably should not be too critical to the pipeline itself.

@stscijgbot-jp
Copy link
Collaborator Author

Comment by Ned Molter on JIRA:

Good to know that's already tabulated somewhere.  I agree it would be easier to use the pre-computed values because I suspect the definition of "near" unity might change by pupil/filter/detector.  I don't know from where APT gets reference information like this, but I'm sure we can ask around and maybe those can be retrieved from CRDS as reference files without (too much) additional work.

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

No branches or pull requests

1 participant