StarTools

If I understand what I've read on this forum correctly, when using DSS you should not use background normalization?
I thought this was a necessary step when using Kappa-Sigma stacking? ( referring to the authors of DSS and Nebulosity as well)
If anyone can clear up my confusion I'd much appreciate it!

Hi,

It's background calibration that should be turned off, as seen here;



Hope this helps!

Ivo,
This is what I am referring to, from the DSS help file. It clearly says that to use Kappa-Sigma stacking you have to normalize the sub's background.

"...Stacking
Background Calibration
The Background Calibration consists in normalizing the background value of each picture before stacking it.
The background value is defined as the median value of all the pixels of the picture.
Two options are available.
With the Per Channel Background Calibration option the background for each channel is adjusted separately to match the background of the reference frame.
With the RGB Channels Calibration the three red, green and blue channels of each light frame are normalized to the same background value which is the minimum of the three medians values (one for each channel) computed from the reference frame. On top on creating compatible images (stacking wise) this option is also creating a neutral gray background. A side effect is that the overall saturation of the stacked image is quite low (grayscale look).
It is important to check one of these options when using Kappa-Sigma Clipping or Kappa-Sigma Clipping Median methods to ensure that the pictures being stacked have all the same background value...."

And from Craig Stark in the Nebulosity help file:

"...If you're using standard-deviation based
stacking, Drizzle, or Colors in Motion, it is a good idea to normalize your images before
stacking..."

Unfortunately, it seems DSS stacking algorithm applies the normalization to the individual frames and leaves it there, rather than temporarily performing the adjustment when determining which frame's pixel value to use and then consulting the unadulterated frames that the remaining pixels belong to for the final mean or median value.

As noted, this has implications for color recovery.

For most (most!) imaging conditions, I can't really think of a reason why background levels would not be the same for each frame though. Especially when you are simply stacking subs with the same exposure length and minimal drift between frames, under identical lighting conditions, as most of us would do. With these limitations/provisions in mind, background normalization is not a strict necessity.

Rule of thumb for StarTools is; avoid any procedure that modifies the data as it was recorded if you can help it.

If this is of any value whatsoever, never having used DSS or Nebulosity and using normalisation only as a contrast measure, programmes such as PixInsight do not normalise data, unless selected. There seems no reason to do so.

Also from CCDStack2:
"...The importance of prior normalization:
For all stack based rejections is imperative that the stack first be properly normalized. Otherwise some images may be over-rejected and others may be under-rejected..."

dariv wrote:Also from CCDStack2:
"...The importance of prior normalization:
For all stack based rejections is imperative that the stack first be properly normalized. Otherwise some images may be over-rejected and others may be under-rejected..."

The CCDStack2 manual also explains;

Normalization

Normalizing the stack results in all images having similar ADU values for corresponding pixels (and area and features).
Normalization mathematically compensates for variations in sky background, sky transparency, exposure times and so on.
Such compensation is often necessary to produce optimal data rejection and image combines

Hence my comment;

For most (most!) imaging conditions, I can't really think of a reason why background levels would not be the same for each frame though. Especially when you are simply stacking subs with the same exposure length and minimal drift between frames, under identical lighting conditions, as most of us would do. With these limitations/provisions in mind, background normalization is not a strict necessity.

Does that make sense?

If any of the aforementioned variables are not constant across your stack, you actually have bigger problems than worrying about than the effect of normalization; you will have frames with distinctly different signal-to-noise ratios and/or point spread functions (e.g. atmospheric "blur"). In the case of gradients and uneven lighting (one of the cited the reasons for the normalization), assuming a simple single constant for the background is not correct; the light gradient should be modeled and it is sub-optimal to just assume a constant. In any case, when such variables are introduced, trying to figure out which pixel is the "truth" just became a lot harder than any sort of simple rejection like Kappa Sigma rejection can address...

Ivo,
Thank you for the clarification!