Every once in a while I feel like participating in one of the endless "Process my data" threads on CN. Most of the stacks have, presumably, been through a normalization step. A few times I have asked the imager if they could re-stack without channel normalization, but that has only really produced an ST-friendly re-stack once or twice.
What is the best (or correct) way to approach a normalized stack in ST? Or is the result likely to be compromised anyway, so I should just go back to fretting about not having any new data of my own?
"Normalized" stacks
Re: "Normalized" stacks
The StarTools suggestion is not to normalize. See https://www.startools.org/links--tutori ... -and-donts.
However, for stacking programs such as Astro Pixel Processor, the suggestion is to run its normalization routine. See https://www.startools.org/links--tutori ... p-settings
The suggestion there is to disable the neutralize background option as part of APP's normalization. That suggestion is probably misplaced since that "neutralization" is only a temporary histogram adjustment for a rough background improvement based on the whole image and does not alter the linear data in any way. There is a separate tool in APP that calibrates background that, like other APP tools, StarTools suggests to avoid.
However, for stacking programs such as Astro Pixel Processor, the suggestion is to run its normalization routine. See https://www.startools.org/links--tutori ... p-settings
The suggestion there is to disable the neutralize background option as part of APP's normalization. That suggestion is probably misplaced since that "neutralization" is only a temporary histogram adjustment for a rough background improvement based on the whole image and does not alter the linear data in any way. There is a separate tool in APP that calibrates background that, like other APP tools, StarTools suggests to avoid.
-
Mike in Rancho
- Posts: 1166
- Joined: Sun Jun 20, 2021 10:05 pm
- Location: Alta Loma, CA
Re: "Normalized" stacks
I'm thinking it's already a given, and Ron was talking about shared data where the poster doesn't employ ST guidelines! 
And indeed I think it's not so much stacking or rejection normalization but rather channel normalization, or neutralizing (in other words, white balancing!) that's the problem.
Once that is done, I don't believe there's any getting it back. Pending Ivo's commentary, the "proper" ST method of handling such datasets is likely to open as left option already white balanced, and thus process through in color and legacy mode, for lack of a better term. That way an "incorrect" luminance layer is not created from the data, and then just make due as you can in the color module later.
One could still try it in full compose mode too, but the lum weighting won't be as correct, and the colors may not balance as nicely, as with a non-white-balanced set.
And indeed I think it's not so much stacking or rejection normalization but rather channel normalization, or neutralizing (in other words, white balancing!) that's the problem.
Once that is done, I don't believe there's any getting it back. Pending Ivo's commentary, the "proper" ST method of handling such datasets is likely to open as left option already white balanced, and thus process through in color and legacy mode, for lack of a better term. That way an "incorrect" luminance layer is not created from the data, and then just make due as you can in the color module later.
One could still try it in full compose mode too, but the lum weighting won't be as correct, and the colors may not balance as nicely, as with a non-white-balanced set.
Re: "Normalized" stacks
For now I'll just fret about my own imaging 
Just for further complication, I would not be surprised to discover that different stacking programs use the word normalization to mean different things with respect to stacking.
The tooltip in Siril says that normalization "matches the mean background of all input images" - which does not itself sound like 'color balancing'. But what, exactly, is one 'input image' for a debayered color sub, and/or how is 'the background' defined for a debayered sub?
Just for further complication, I would not be surprised to discover that different stacking programs use the word normalization to mean different things with respect to stacking.
The tooltip in Siril says that normalization "matches the mean background of all input images" - which does not itself sound like 'color balancing'. But what, exactly, is one 'input image' for a debayered color sub, and/or how is 'the background' defined for a debayered sub?
-
Mike in Rancho
- Posts: 1166
- Joined: Sun Jun 20, 2021 10:05 pm
- Location: Alta Loma, CA
Re: "Normalized" stacks
Well yes, I suppose it is a term with many meanings. At minimum, I think I am aware of rejection normalization, output (final stacking) normalization, color channel normalization (the one we want avoided), and even narrowband normalization as part of post, recently discussed with Ivo in terms of the popular PI Bill Blanshan technique. There might be more!
The first two are probably okay, and many seem to consider them mandatory. Rejection normalization for sure. I assume each channel is treated independently, as I don't think it would work otherwise.
I just go full bore now with whatever PI sets up for me in terms of rejection normalization and output normalization, including local normalization, and I think I have at least a modest nod from Ivo to do so. Let's face it, he's stashed away at least two of my older datasets for the Wipe Hall of Shame!
The PI docs on integration have some discussion of normalization, including the math. I think there's a fair bit of commonality in the different uses for normalizing, as far as the equations go.
If you can grasp it, come back and explain it to me.
https://pixinsight.com/doc/tools/ImageI ... iption_004
But by and large I doubt you have to shy away from posted datasets other than those that have been color normalized/neutralized/white balanced, and for those just use caution or even just abort, if the colors can't be properly balanced well enough.
The first two are probably okay, and many seem to consider them mandatory. Rejection normalization for sure. I assume each channel is treated independently, as I don't think it would work otherwise.
I just go full bore now with whatever PI sets up for me in terms of rejection normalization and output normalization, including local normalization, and I think I have at least a modest nod from Ivo to do so. Let's face it, he's stashed away at least two of my older datasets for the Wipe Hall of Shame!
The PI docs on integration have some discussion of normalization, including the math. I think there's a fair bit of commonality in the different uses for normalizing, as far as the equations go.
If you can grasp it, come back and explain it to me.
https://pixinsight.com/doc/tools/ImageI ... iption_004
But by and large I doubt you have to shy away from posted datasets other than those that have been color normalized/neutralized/white balanced, and for those just use caution or even just abort, if the colors can't be properly balanced well enough.
Re: "Normalized" stacks
Are saying I should spend $275 on PI, because then I will be so confused about normalization that I will happily just give up and go with the flow?
I am wondering if I haven't been misinterpreting Siril's Normalization. If it is what they apply for rejection, then "No normalization" is a big mistake.
I am wondering if I haven't been misinterpreting Siril's Normalization. If it is what they apply for rejection, then "No normalization" is a big mistake.
-
Mike in Rancho
- Posts: 1166
- Joined: Sun Jun 20, 2021 10:05 pm
- Location: Alta Loma, CA
Re: "Normalized" stacks
Ha! No, not saying to go buy it at all. It just has a section there that seems to get into the nitty gritty of normalization, as well as certain terms that are often used (additive, scaling, etc), even in other programs, and so might be a decent basis for understanding.
We know DSS (at least the old one, I haven't yet tried the new release/beta) permits full shut off of normalizing. It warns that this will cause sigma rejection to not work properly, but otherwise doesn't really go into explaining it much.
ASTAP, to my knowledge (based on trying to read the log as it writes it out on the screen), is forced normalization and I don't see any ways of shutting it off. But, would you really even want to?
I don't know about Siril (also haven't yet tried the new release/beta), but it often struck me as a PI-Lite, but easier to understand. Except for stacking, in which case they tried really hard to make it even more confounding than PI. As such, I have no way to comment on Siril stacking options, other than the terms they use might be awfully similar to what PI uses.
But I would very much think you'd want normalizing for rejection at the very minimum, and likely for output too, especially if you ever get satellite trails, do multi session integration, have meridian flips, or track your way across the sky. Honestly I was astounded by the overall brightness change in my subs during even fairly short acquisition. If you have some way to blink through subs, where they are all autostretched to a particular reference (rather than independently for each sub), it can really be quite something. And then just imagine trying to apply pixel rejection, or even average stacking, on them all.
We know DSS (at least the old one, I haven't yet tried the new release/beta) permits full shut off of normalizing. It warns that this will cause sigma rejection to not work properly, but otherwise doesn't really go into explaining it much.
ASTAP, to my knowledge (based on trying to read the log as it writes it out on the screen), is forced normalization and I don't see any ways of shutting it off. But, would you really even want to?
I don't know about Siril (also haven't yet tried the new release/beta), but it often struck me as a PI-Lite, but easier to understand. Except for stacking, in which case they tried really hard to make it even more confounding than PI. As such, I have no way to comment on Siril stacking options, other than the terms they use might be awfully similar to what PI uses.
But I would very much think you'd want normalizing for rejection at the very minimum, and likely for output too, especially if you ever get satellite trails, do multi session integration, have meridian flips, or track your way across the sky. Honestly I was astounded by the overall brightness change in my subs during even fairly short acquisition. If you have some way to blink through subs, where they are all autostretched to a particular reference (rather than independently for each sub), it can really be quite something. And then just imagine trying to apply pixel rejection, or even average stacking, on them all.
Re: "Normalized" stacks
I had blindly stuck to "no normalization" in Siril since I first started using ST, based on a quite possibly flawed understanding. One trigger to re-think it was that the newest version of Siril includes a new checkbox in the Stacking panel "RGB equalization". So clearly normalization and color balancing are separate in Siril (at least now, but probably all along).
Re: "Normalized" stacks
Went back to a couple of datasets and re-stacked with normalization on. Can't say I see any difference in what comes out the other end of ST.