chris-simpson
commented
1 year ago I'm not sure what circumstances you're referring to. When stacking frames, the exposure time of the output is simply the exposure time of the first input frame (the entire header is copied). This is obviously correct if all the inputs have the same exposure time (because all stacking operations are some form of average, there is no "sum" operation).
If the inputs have different exposure times, then the scaleByExposureTime() primitive can be used to scale them to the same effective exposure time. This does update the exposure time with the new effective exposure time (with the actual exposure time being saved in a new keyword, ORIGTEXP), so the count rate you get from dividing the image values by the value of the exposure time keyword is correctly preserved.
You should not use stackFrames(scale=True) to scale images because this scales by the background level, not the counts in the objects. This option is used for combining near-infrared images to form sky frames, and for scaling a sky frame before subtraction. Frames that are going to be used for photometry should not use the scale=True option precisely for this reason.
In the soon-to-be-released v3.1 of DRAGONS, scaleByExposureTime() has been superseded by scaleCountsToReference(). The default behaviour of this new primitive is to scale by the exposure time (for consistency) but it has a parameter that allows the scaling factor to deviate from this by some amount, ultimately allowing it to take whatever value provides the same number of counts in the objects, regardless of the exposure time. Again, the exposure time keyword in the header is multiplied by this scaling factor to preserve the counts per second of the image. This can result in the inputs having different exposure times but this means the data weren't taken in photometric conditions so you can't obtain absolute photometry anyway and the fact that the counts per second of the stack are based on the counts per second of the first image rather than the average counts per second isn't necessarily inferior.
If I'm missing a particular set of circumstances where you think the wrong thing is happening, please let me know.
When reducing multiple exposures and stacking for a single reduced science image, the header of the output .fits file should probably include some updated exposure time value. Otherwise, photometry estimates, background subtraction efforts etc. performed with these output (stacked) images will have erroneous exposure times (unless manually overwritten).