cmccully
commented
9 years ago @saurabhwjha That seems to make sense. Submit a pull request and I will add it to the repo. This may create a few bad pixels from the background subtraction step, but I think that should be alright. One way around this is to add a few pixel buffer to both sides of the of the chip gaps that you have defined here.
@cmccully I'm trying to understand the logic in finding the chip gaps.
This wasn't quite working for some data I had where the bottom rows were messed up (maybe from the guide probe, not sure), so I had to start the wavelength solution at say row 200, not row 50. But the chip gap logic was identifying the whole chip as the gap.
I had to change the code to something like:
ypix = slice(200 / ccdsum + 1, 3800 / ccdsum)
[...] chipgap1 = (np.min(w[w > 950]) - 1, np.max(w[w < 1100]) + 1) chipgap2 = (np.min(w[w > 2050]) - 1, np.max(w[w < 2250]) + 1) chipgap3 = (np.min(w[w > 3100]) - 1, hdu[2].data.shape[1] + 1)
That uses fewer rows (from 251 to 750) and hardcodes where the chip gaps are likely to appear (e.g., 950 to 1100) rather than allowing any place on the chip.
This doesn't quite get all the curvature of the chip gaps near the top and bottom but I don't think we're likely to have spectra that close to the edge. I don't know if this will mess up the 2d background step though.