That's not a solely ST-processed image, correct?
Detail is quite good, but the stars (that haven't gone missing?) are a little burnt out (swallowing nearby stars) and "stringy", while the Ha appears rather oversaturated on my calibrated screens.
Are you able to get something like this in StarTools OK?
-
- StarTools_2799.jpg (393.15 KiB) Viewed 6075 times
E.g. a textbook HOO bi-color where red perfectly controls Ha contribution and green and/or blue perfectly control O-III contribution?
Or you could process the dataset as a regular RGB dataset (e.g. not use Compose module), in which case, you can get some slightly different coloring (effectively you get control over the hue of the O-III via independent green and blue bias behavior).
Then you could use the Shrink Module;
-
- StarTools_2800.jpg (411.5 KiB) Viewed 6075 times
and/or Super Structure module, to push back the stars without completely mangling them. The halos on them are quite strong, which can be caused by adverse (or variable) atmospheric conditions (bad transparency, changing seeing, etc.).
Regardless, if done properly (e.g. weighed properly and stacked properly), then noise in whichever channel, is not an issue (unless there is some severe remnant shot noise from subtracted light pollution etc.). It's all properly accounted for when added to the synthetic luminance signal. E.g. that's why you would use the stacker settings as recommended(!), and then import such a dataset in the Compose module using 'L + Synthetic L from R(2xG)B, R(GB)(GB) (Bi-Color from OSC/DSLR)'. Or if you are not after a bi-color and rather use tristimulus response as recorded, you can indeed load the data without bi-color, for example like so;
-
- StarTools_2801.jpg (339.01 KiB) Viewed 6075 times
Color noise is indeed barely visible to humans and can indeed be blurred to extremes without people noticing.
Also note that, an OSC or DSLR samples twice as many pixels in the green channel, compared to the red and blue channels (Bayer matrix). This yields a sqrt(2) = ~1.4x better signal to begin with.
The only issue with this dataset is really the stars. However, it is (or should be) trivial to bring out O-III dominant areas in a linear, documentary fashion.
With regards to the video
These sorts of videos make me a little angry to be totally honest.
Juxtaposing O-III vs Ha should be (is)
trivial. There is no need for "rescuing" anything! The "method" in the video is nonsensical straight out of the gate; non-linear manipulation of individual channels is inappropriate in the chrominance domain. It just introduces hue artifacts, suggesting emission concentrations or dominance that do not exist. This is *bad*. Star removal is equally unnecessary (and obviously introduces neurally hallucinated artifacts) and the Range Selection stuff is pretty borderline as well (selectively modifying color in the image based on a mask). Background extraction from a
stretched image? Big frown. To top it off DenoiseAI's dog hair and cat fur generator. Just. No.
It's destructive nonsense that has rather little to do with photography.
Sadly the author still thinks he's "
not betraying the spirit of the data". That's just not true.
Instead, the "secret" is decoupling luminance from chrominance, and respecting these separate domains. Unless you're creating 90s album art, we don't do non-linear stretches on individual RGB channels for terrestrial imaging either; the coloring (RGB ratios) gets distorted per-pixel, based on brightness and the hues no longer describe anything remotely related to reality (they no longer convey anything about relative emission concentrations).
AFAIK, the O-III in the dataset of the video, is just fine and can even be added the luminance without problems for a deeper signal (and better color vs detail correlation, so we don't have to rely on just the Ha detail for O-III coloring to show).
This is the dataset from the video after a 2 minute, completely standard process in StarTools;
-
- StarTools_2803.jpg (423.18 KiB) Viewed 6075 times
Workflow; Imported in the Compose module as follows; Ha as red, O-III as green O-III as blue. Exposure time for synthetic luminance generation is set to 0 for green and blue (e.g. O-III); the point of the video is to "rescue" coloring when your O-III is poor (it is not - it is faint, sure - but let's assume it is poor and we don't want to use it). Bin, Crop, Wipe. AutoDev, then straight into the Color module.
E.g. what we're doing here is using Ha luminance (detail) and HOO for coloring (chrominance). It just works, gives you full control over the true linear Ha:O-III coloring in your image and
truly respects the data. Not a mask or curve in sight for this purpose, because they are inappropriate tools.
Noise reduction after switching tracking off (not a single tweak), yields this;
-
- NewComposite.jpg (620.93 KiB) Viewed 6075 times
PS by know you should have noticed the utterly consistent color rendering of HOO bi-colors in StarTools (if using defaults of course); you can trust blue/cyan to be truly indicative of O-III, red to be truly indicative of Ha and white to be indicative of a mix.