search

spacetelescope / jwst

Python library for science observations from the James Webb Space Telescope
https://jwst-pipeline.readthedocs.io/en/latest/
Other
565 stars 167 forks source link

Modify combine_1d for combining background data #3163

Closed philhodge closed 5 years ago

philhodge commented 5 years ago

For the case that the FLUX column of the input extract1d tables is actually background, e.g. when combining background data to make a master spectroscopic background spectrum, the combine_1d step must scale the values read from the FLUX column by dividing by the NPIXELS column. This is because NPIXELS can vary from row to row within a table, and it can differ from one table to another; the background values have to be put on the same scale (e.g. background level per pixel) before they can be combined.

Since the combine_1d step should treat background data differently from target data, the step must be able to distinguish between these two types of input. A new command-line parameter could be added for this purpose. The parameter could be background, a boolean with default value False; True would mean that all the input extract1d tables contain background rather than target data.

jdavies-st commented 5 years ago

A boolean background would work well. Also, this parameter will have to be switched by the input association. The exptype of the association member can have "background" as a type, so this could also inform the function that it should treat it as background.

hbushouse commented 5 years ago

We should keep in mind that upcoming changes to the level-2b processing flow, and the photom step in particular, will be applying flux conversion to the pixel values, where the conversion factors will be scaled in such a way that when extract_1d is run using an agreed upon standard aperture size (for a given instrument mode) the resulting 1-D spectrum will be in flux units scaled to an infinite aperture. So only in cases where we use an aperture height in extract_1d that is different than the standard (which we may do for extracting background) do we need to worry about doing any rescaling of the resulting 1-D flux values. That should likely be added into extract_1d itself, such that everything that comes out will always have the correct infinite aperture flux? That may make a background option in combine_1d unnecessary.

But then our routine that interpolates 1-D background spectra back to 2-D image space will also need to know how to rescale properly to a per pixel background flux (e.g. it may need to know what the standard aperture size - number of pixels - is for a given instrument mode).

philhodge commented 5 years ago

@hbushouse , the standard aperture size has to do with extracting point-source data. In this issue I was referring just to background data, which is obviously an extended source. When extract_1d is run for background data, the extraction height (or width) might or might not be the same as when extracting a science target, but in any case the height (width) will be saved in the NPIXELS column. In contrast to science data, which are expected to taper off significantly over the extraction height, background data are expected to be approximately uniform over the extraction height. extract_1d just sums the data; summed point-source science data are approximately independent of a small change in the extraction height, while summed background data are linearly proportional to the extraction height. combine_1d has to divide by NPIXELS, if and only if the input is background data. The output of combine_1d does not have an NPIXELS column, and it shouldn't, because NPIXELS can be different for the various input spectra, and it can vary from column to column for any one input spectrum.

The expand_to_2d module in master_background currently expects its input to be similar to a MultiSpecModel. If there is an NPIXELS column, expand_to_2d will divide the background flux by that column; if there is no NPIXELS column (as in the output of combine_1d), expand_to_2d assumes NPIXELS is 1.

philhodge commented 5 years ago

There are two other changes that need to be made. The input spectra are weighted by either the integration time or the exposure time (unit weight is also an option). The current default is integration time, but it seems to me that the default ought to be the exposure time.

If background=True, the input spectra should also be weighted by the NPIXELS column. The idea here is that if you average two (just for example) background spectra that had different extraction heights, the one with a larger extraction height should have more weight because more background area went into its 1-D spectrum.