Thanks as always, Ivo.
I only acquired 8 total hours of data this month, but between all the practice with it (my Rosette folders are over 50GB lol) and the discussions here on the ST forums, it's probably been one of my best learning months ever.
admin wrote: ↑Sat Feb 26, 2022 5:35 am
Hmmm.... I'm not seeing any material differences in luminance between the two (indeed equivalent) methods.
Can you post the result of "L + Synthetic L From RGB, Mono" with 2xG exposure, and "L + Synthetic L From R(2xG)B, Mono (Mono from OSC/DSLR)", processed as follows;
- AutoDev on both stacks
- then stacks loaded in the Layer module (one in foreground, one in background), with Layer Mode set to "Difference".
Maybe 'material' difference is the key, and I'm being too particular about true equivalence.
Originally I was doing this just visually, with the preview screen that Compose gives you, saving screenshots and flipping between them, both in color and mono, and was noticing differences. But I had also saved the linear compose results and could see statistical differences in image analytics. Had not stretched them.
Using your suggested test, the layer difference result is indeed black. Pretty black. If kept and that result then stretched, there is a shadow of the image, maybe rounding errors, not really sure. Oddly, the difference is more pronounced if one loads separate R, G, and B files into compose, compared to loading the same file (a la OSC/DSLR) into all three slots and letting ST split and assign them. A stretch of that kept layer difference result actually creates a nearly-viable image, with perhaps some holes in the star cores. I figure that's perhaps due to truly identical pixels there from blown stars.
My folder for this is getting littered with files that I am losing track of.
So I will need to better organize my experiments and get back to you on this. Though again, perhaps it is so deminimus as to not be an actual problem that would ever be seen.
My only current need for this is coming in to ST with my channels already split, and thus I will use ST to create the OIII mono out of the G and B. But when it seemed like (2xG) versus doubling G exposure weren't identical, I started wondering if I was doing it properly for my G-weighting.
It is purely meant to "fill in" - to the best of ST's abilities - any missing channels, for the purpose of color only. E.g. it provides a channel with some data at least - an interpolation or extrapolation.
It;s always on, unless you explicitly turn it off. Indeed, you can turn it off to just put data in specific channels (like making Ha red), or you can use it to extract specific channels (say you only want the green channel, you'd turn off the interpolation, load your RGB file in only the green slot and "Keep" the result).
Does that help?
Ruh Roh.
This is one thing that has worried me. In most, if not all, of the documentation I can find (user notes, manual special techniques, etc), the steps are either silent as to Channel Interpolation, or say to keep it ON, when discussing channel extraction and combining.
As a result, when using ST to split off a channel and save, I've kept it on the default. Hasn't seemed to hurt, that I can tell, but what do I know lol.
I suppose it now really depends what I do with it after. As well as what ST does when saving a split single channel if interpolation had been on instead of off. I know ST saves RGB tiffs, even if mono or a single channel that I think is considered mono, so the question is if that "some" data filled into the other channels will affect the saved file.
I may have to devise more experiments here too.
These slider multiply red, green and blue before any matrix stuff.
If you imported H (in red) and O (in green or blue, or even both) then given RGB is mapped to R = 100%R, G = 50%G + 50%B, and once again 50%G + 50%B for B, then you can see how any individual change to G or B affects the re-mapped G or B equally (they both have the same equation; 50%G + 50%B).
That formula 50%G + 50%B indeed implies the ratios are additive.
Behavior of O in the two channels (G and B) when the identity matrix is active (RGB mapping to straight RGB), is essentially allowing you to choose a different hue by choosing a different ratio for O for each individual G and B channels. E.g. it does not lock you to the usual cyan hue of a straight HOO, as forced by the R = 100%R, G = 50%G + 50%B bit.
If you choose a different hue like that , as always, you should still - on a well calibrated screen - observe minimal changes in brightness of the detail, no matter the hue chosen. And you are still able to perfectly throttle the Ha in the red channel, versus whatever-hue-you-have-chosen-for-O-III by varying the Red Bias Reduce parameter.
Does that help?
Very much so!
I will go check this out again. I saw some unexpected changes occur and was worried that I was either creating a third hue, or creating (or at least emphasizing) non-real color structure. Good to know that it's rather just an option to alter the particular tint of the OIII.
I did try to read up and experiment first, but got stuck. 
