Hey, I noticed what seems to be a small bug in Stage 3 for NIRSpec. I am working on a NIRSpec/G395 NRS2 reduction using v2.4.0 of exotedrf. The spectral trace for this particular dataset is close to the bottom edge of the detector and I noticed that, when the input extract_width for the Stage 3 Extract1DStep extends the aperture past the edge of the detector, the resulting 1D spectrum from that column gets a value of zero.
I've attached images showing examples of this aperture (via the centroiding_nrs2.png output) and the resulting spectrum:
Manually reducing the aperture size so that it stays within the detector bounds fixes this of course, so that the spectrum is non-zero and looks how it should.
Here is an example to compare:
I am assuming this zeroing behavior is unintentional though. I suggest some kind of check so that the extraction aperture can be automatically clipped if it will exceed the edge of the detector, and return the spectrum up to the edge.
Hey, I noticed what seems to be a small bug in Stage 3 for NIRSpec. I am working on a NIRSpec/G395 NRS2 reduction using v2.4.0 of exotedrf. The spectral trace for this particular dataset is close to the bottom edge of the detector and I noticed that, when the input
extract_widthfor the Stage 3Extract1DStepextends the aperture past the edge of the detector, the resulting 1D spectrum from that column gets a value of zero.I've attached images showing examples of this aperture (via the
centroiding_nrs2.pngoutput) and the resulting spectrum:Manually reducing the aperture size so that it stays within the detector bounds fixes this of course, so that the spectrum is non-zero and looks how it should.
Here is an example to compare:
I am assuming this zeroing behavior is unintentional though. I suggest some kind of check so that the extraction aperture can be automatically clipped if it will exceed the edge of the detector, and return the spectrum up to the edge.