StarTools

I never run out of these. I did try to read up and experiment first, but got stuck.

First, in Compose, with for example a file in each channel other than L, there seems to be a results difference between choosing one of the 2xG options, or doing it via a straight RGB option but doubling the weight of G in exposure. However, based on the ST formulas for this that have been posted here in the forums, I would think it should be the same. Sqrt (2 x exp) versus Sqrt (manually doubled exposure). Other than doubling G, other exposures kept at defaults and I know it's just the ratios that matter.

There actually is a method to the madness -- now that I can acquire separate SII to go with my duoband, I have to do more extracting to create my OIII rather than just utilize ST's handy DSLR bicolor composing. But I still wanted to get the weighting advantage of my G pixels, so I created my OIII by just loading G and B as L+Synth L from R(2xG)B, Mono.

Second, even with some playing around, reading the docs, manual, and user notes, I can't really get a handle on what "color channel interpolation" actually means. I read what it can apparently be used for (though struggling to find an example), but outside of that I'm befuddled. I presume there is generally no harm just leaving it at the default ON in any of my channel splitting and combining?

Honestly I think I've only used it once, which was to "colorize" a mono Ha file. Looked pretty metallic though.

Last but not least, in actual bicolor of Color (following a bicolor compose), it was my understanding that the G and B bias controls were sort of either/or as to affecting the OIII channel. And from what I've been able to see, they appear to be additive - meaning reduce of just 2.0 G, or just 2.0 B, or both 1.0 G and 1.0 B, are all the same. Unless you flip back to Color Constancy. In which case, the G and B sliders now seem to be having somewhat independent effects. I noticed this when I was working an HOO version of my Rosette. Is this proper functioning, even though, due to Compose, we are supposed to be working on the identical (GB)(GB), and in Color are in one of the bicolor matrices?

That's all my rambling for tonight.

Mike in Rancho wrote: ↑Fri Feb 25, 2022 9:20 am I never run out of these. I did try to read up and experiment first, but got stuck.

First, in Compose, with for example a file in each channel other than L, there seems to be a results difference between choosing one of the 2xG options, or doing it via a straight RGB option but doubling the weight of G in exposure. However, based on the ST formulas for this that have been posted here in the forums, I would think it should be the same. Sqrt (2 x exp) versus Sqrt (manually doubled exposure). Other than doubling G, other exposures kept at defaults and I know it's just the ratios that matter.

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".

There actually is a method to the madness -- now that I can acquire separate SII to go with my duoband, I have to do more extracting to create my OIII rather than just utilize ST's handy DSLR bicolor composing. But I still wanted to get the weighting advantage of my G pixels, so I created my OIII by just loading G and B as L+Synth L from R(2xG)B, Mono.

Makes perfect sense and that should indeed do the trick of maximising signal fidelity!

Second, even with some playing around, reading the docs, manual, and user notes, I can't really get a handle on what "color channel interpolation" actually means. I read what it can apparently be used for (though struggling to find an example), but outside of that I'm befuddled. I presume there is generally no harm just leaving it at the default ON in any of my channel splitting and combining?

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.

Honestly I think I've only used it once, which was to "colorize" a mono Ha file. Looked pretty metallic though.

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?

Last but not least, in actual bicolor of Color (following a bicolor compose), it was my understanding that the G and B bias controls were sort of either/or as to affecting the OIII channel. And from what I've been able to see, they appear to be additive - meaning reduce of just 2.0 G, or just 2.0 B, or both 1.0 G and 1.0 B, are all the same. Unless you flip back to Color Constancy. In which case, the G and B sliders now seem to be having somewhat independent effects. I noticed this when I was working an HOO version of my Rosette. Is this proper functioning, even though, due to Compose, we are supposed to be working on the identical (GB)(GB), and in Color are in one of the bicolor matrices?

That's all my rambling for tonight.

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?

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.

....further musings on the first matter from above....

1. The fact that the difference layer only shows "visible" differences in the one case, and only just barely if zoomed in, and either way really only develops when that difference itself is stretched out, may render the whole thing somewhat moot.

2. That said, query if utilizing AutoDev is the best test. True, it's what we are going to use in ST, but because it is optimizing what it finds in front of it, the end results will be converging towards each other. May be quite dependent on the dataset.

3. Just to "see" what the benefit is, I ran the same suggested test, but this time the layer difference was between a straight up RGB as mono, and the 2xG version. Difference layer was also primarily black and had to be zoomed/stretched to see anything. Quite subtle, therefore, and maybe is supposed to be, yet similar to my prior difference test between 2xG and doubled G.

4. Using a duoband dataset for this may not be the best test, based on what gets through the filter to fall on G and B. However, 2xG as part of the bicolor from OSC/DSLR is likely the most frequent use case - though not tested out here.

Will dive further into it sometime, but I imagine it is working as it is supposed to.