Comment by Christian Hayes on JIRA:

Assigning to myself for now while the NIRSpec Team is investigating potential options.

Comment by Melanie Clarke on JIRA:

Quick question - what do you mean by "extract wavelengths in addition to fluxes"?

Comment by Christian Hayes on JIRA:

extract1d.extract1d currently does not extract wavelengths according to the input source extraction regions.  If I'm not mistaken I believe the wavelengths are "extracted" in extract_1d.extract.extract here:  https://github.com/spacetelescope/jwst/blob/a32f8b01e8000603d6cc916511a87c0e0b77e47e/jwst/extract_1d/extract.py#L1861C1-L1880C70].  This uses the ystart/ystop and xstart/xstop to extract the wavelengths and won't use curved traces to extract the wavelengths if they are supplied through "src_coeff".  

This isn't particularly a problem for extracting from resampled data currently because each column (for NIRSpec data) will have the same wavelength, and fluxes are box-car extracted by column anyway.  If we want to extract from unrectified cal spectra, there is a non-negligible slit tilt, such that the wavelengths from the default rectangular extraction box won't match those in a curved trace.  So, we would need to extract wavelengths from the same aperture as the fluxes in order to extract the correct wavelengths.  If it helps I can put together an example to illustrate.

Comment by Melanie Clarke on JIRA:

Got it, thanks.  That sounds like a bug or oversight in the current implementation – I'll keep it in mind while we're working on JP-3753.

Comment by Christian Hayes on JIRA:

Just noting with #8961 the 1D wavelength arrays from extract_1d are now calculated as a weighted average using the extraction profile, so this piece has already been added to the pipeline.

Comment by Christian Hayes on JIRA:

Greg Sloan Sarah Kendrew Andreea Petric I'm looking into options for deriving a trace for unrectified NIRSpec data and have am discussing with the NIRSpec team a potential option for using the WCS to calculate a trace using source positions.  This would be similar to what is done in the pipeline now for resampled data when turning on use_source_posn.  

I think Greg had mentioned at one point that calculating traces for unrectified data might be of interest for MIRI LRS too.  Is that still the case? I know there had been some discussion of deriving traces from reference files on the PSF-based extraction ticket.  If the above sounds like it might be of interest I could look into making the code flexible enough to work for MIRI LRS too (if so I might want to follow up with you about details).  I'm also happy to chat if you're interested.

Comment by Greg Sloan on JIRA:

The spectral trace for unrectified data is built into the specwcs file for both LRS slit and slitless. That information is then used in the rectification process.

We have not yet folded distortions of the trace with position in the slit (or in the slitless field) into the specwcs file. That is coming up on our to-do list.

LRS is also very interested in extracting spectra from unrectified images. The PSF-based extraction code that we are testing already does that.

Comment by Christian Hayes on JIRA:

Okay thanks!  I had figured that this was being addressed for LRS as part of the PSF-based extraction, but thought I should check.

Comment by Christian Hayes on JIRA:

Melanie Clarke I have a potential implementation for this ticket opened up as a draft PR here:  https://github.com/spacetelescope/jwst/pull/9022].  After the holidays would you be able to take a look at it and see if it looks reasonable to add?

This would add an option to extract_1d, calculate a source trace from WCS (the NIRSpec slit and detector frames) using the expected source positions in slits/slitlets for BOTS, MOS, and FS, and will extract the pixels around the trace.  This is set as the default for BOTS.  I also added an option to apply a cross-dispersion offset to the trace in case users see that their spectra are slightly shifted from the expected positions.  

If it otherwise looks fine, I wrote this up as a separate option/function, but one question I have is:  should it should be combined in some way with the location_from_wcs and use_source_posn option?  Both use the same core concept of calculating source positions on the detector from WCS, and for resampled data the use_trace option effectively reverts to what use_source_posn provides, though they are set up slightly differently and have different defaults for different cases.

Comment by Melanie Clarke on JIRA:

Thanks for this, Christian Hayes!  I looked through your implementation – I haven't tested yet, but it looks very promising to me.

I do think it would be nice to unify the use_trace and use_source_posn options a little more – I wonder if the use_trace option is even really needed? It is effectively just a source position appropriately calculated at each wavelength element instead of a single value, when the data is not resampled.  We could probably extend it to unresampled MIRI LRS fixed slit data as well, using a sky to detector transform for the dithered_ra/dec.

Also, I'm wondering if instead of a trace_offset option, we ought to just add a step-level option to offset the nominal center of the aperture in cross-dispersion, for any spectral extraction.  That seems like it might be a generally useful override for everyone.