Help Me Understand How Color Module NB Matrix Works

[Mike in Rancho]

I'm probably tying myself in knots with this unnecessarily, but here goes...

I'm having difficulty reconciling what is actually being performed in the Color module with respect to the bicolor and SHO matrix mappings. Some of this is confusion as to what should be thought of as "channels" when it comes to the earlier compose module, versus what ST is doing in Color, since Color and Luminance are separate. I think. At least up that point, anyway. And some of it may be because, at least in other programs, I think similar results are actually achieved by a true (pixel math etc) blending of the actual R, G, or B channels.

I've tried reading the module description, user notes, and links therefrom. Oh I think the link in the user notes to the Hangouts video might be broken. But I still found it anyway with a google search, and had previously watched it.

So, let's say in compose we load in some SII, Ha, and OIII, and process through in the Synth L created thereby. The compose said our R channel was the SII file, the G channel was the Ha file, and the B channel was the OIII file. When we enter color, if we don't open up the matrices, it is directly applied in that manner. Usually very very green! All to be expected, and we have the RGB channels that are what we know them to be from compose.

Now, where I start getting lost is when we start using the NB matrix selections. Let's say I pick [SHO 50SII+50Ha, 50Ha+50OIII, 100OIII]. What is actually happening here when it comes to S,H,O, or R,G,B? From just reading it at face value, it looks like the SII (R) and Ha (G) are 50-50 blended to make a new R channel, Ha (old R) and OIII (B) are 50-50 blended to make a new G channel, and the B channel stays the same. But is that really what's happening, that we have all new channels where the differing structures have been mixed together? If so, I was wondering how the bias sliders work on that - particularly as it has been explained that the R, G, and B channel bias sliders are in actuality working on the SII, Ha, and OIII. All by math?

Or, is that all off base? Should I be thinking of it in terms of each filter's detail being color blended only, to a certain hue, more as something like this from the above-noted matrix: The SII is entirely red; the Ha is half green and half red (brown?); and the OIII is 2/3 blue and 1/3 green. Those are the hues and then the sliders alter the bias of them, and of course where the data overlaps the colors will blend together.

Or is there another way to help decode the meaning or underlying function of the matrix formulas that I am completely missing?

Thanks!

Signed,

Confused in Cali

[admin]

No worries!

So, let's say in compose we load in some SII, Ha, and OIII, and process through in the Synth L created thereby. The compose said our R channel was the SII file, the G channel was the Ha file, and the B channel was the OIII file. When we enter color, if we don't open up the matrices, it is directly applied in that manner. Usually very very green! All to be expected, and we have the RGB channels that are what we know them to be from compose.

Correct.

Now, where I start getting lost is when we start using the NB matrix selections. Let's say I pick [SHO 50SII+50Ha, 50Ha+50OIII, 100OIII]. What is actually happening here when it comes to S,H,O, or R,G,B? From just reading it at face value, it looks like the SII (R) and Ha (G) are 50-50 blended to make a new R channel, Ha (old R) and OIII (B) are 50-50 blended to make a new G channel, and the B channel stays the same. But is that really what's happening, that we have all new channels where the differing structures have been mixed together? If so, I was wondering how the bias sliders work on that - particularly as it has been explained that the R, G, and B channel bias sliders are in actuality working on the SII, Ha, and OIII. All by math?

Bingo. That's precisely what is happening.

E.g., unique to StarTools, no matter what colors (for all intents and purposes "hue") you are choosing for your three different narrowbands, the Color module will make sure that you still perfectly control S-II with the red bias slider, Ha with the green bias slider and O-III with the blue bias slider. Always.

In other words, you are controlling the pure bands/signal at all times, pre-remapping, and not some "scrambled egg" RGB combination post-remapping.

Or in yet other words, StarTools keeps track of where all the signal goes in the final colored images for you, so you can still control precisely the balance of how much S-II, Ha and O-III you wish to have poke through. No matter what hues are being allocated to those bands.

This feat, of course, only works in a useful fashion, if luminance (for all intents and purposes "the detail" at this stage) is kept the same.

You can verify this behavior by opening, say a SHO dataset, process it as normal and entering the Color module. As you know, chances are that the green is super strong (Ha being dominant) if all bias sliders are left at 1.0.

Go ahead and set those sliders to 1.0 and choose the "Identity" matrix (e.g. straight SHO->RGB mapping). This is our baseline. Notice that - unsurprisingly - the bias sliders work as expected, you control S-II with the red bias slider, Ha with the green bias slider and O-III with the blue bias slider.

Now let's verify this is still the case if, say, we decide to swap the red and blue channels for a straight OHS->RGB mapping. We can do so with the RGB:BGR matrix.

You should now notice that you still are 100% controlling S-II with the red bias slider, Ha with the green bias slider and O-III with the blue bias slider.

For the next version of StarTools, a simple label change, depending on the dataset would make this more intuitive. So if you originally imported a SHO dataset "Red Bias Reduce" would always read "S-II Bias Reduce", "Green Bias Reduce" would always read "H-alpha Bias Reduce" and "Blue Bias Reduce" would always read "O-III Bias Reduce".
If you imported a HOO duoband set, "Red Bias Reduce" would always read "H-alpha Bias Reduce", "Green Bias Reduce" would always read "O-III Bias Reduce" and "Blue Bias Reduce" would also always read "O-III Bias Reduce".

Does this help?

[Mike in Rancho]

Thank you, Ivo.

Indeed helpful. I think I am inching closer to comprehension.

I composed my SHO Rosette for the experiment you suggested, and yes the simple straight remapping works as indicated.

I also must start keeping in mind the parallel stream processing, and that the L worked on in the modules is in essence a two dimensional grayscale, and the extra dimensions of RGB do not come into play (that we can see) until the color module.

The bias slider clarification might be handy, though I haven't had any trouble remembering what is what when it comes to bias reduce. It is more the fancier remapping descriptions where I am uncertain.

Is it a holdover or akin to the "other software" methods? My understanding is that, to effect something similar to what ST does naturally, they actually have to do it in their version of the compose module. So they would truly blend full RGB channels into something else. But of course when they get to the point where they are adjusting channel bias, they would probably be working on the RGB that is now in front of them, instead of the emission filters. As you say, scrambled eggs.

If I may though, for a final (perhaps) clarification on how to consider the blends -- and maybe I'll try an easier one from the bicolors:

H(H+O)O is written out as [100R, 50R+25G+25B, 100B]. Then again maybe it's not easier. As I note that here we have changed back to RGB inside the codes, whereas for SHO it is the filters in the codes. But I digress. I believe it is the case that each "slot" in the Duoband or SHO mapping, however comprised, is dropping into R, G, and B, and in that order.

But, what does it mean as far as our filter hues by having the G channel say 50R+25G+25B? I presume some kind of strength weighting of the pixels that are going into it? And of course same as far as the SHO mappings go. I know from using H(H+O)O so many times that the H ends up a gold/orange of sorts, and the OIII becomes closer to full blue. This seems to make sense. Our H is now composed of red and a bit of green (percent?), and our O is now composed of blue plus a bit of green. It seems to me they are 2/3+1/3, but I don't know. Also unsure if O being the composed (BG) makes duoband easier. Perhaps I was wrong there.

What I would like to do is make myself a color key for all these combos, with a little square patch for what each filter's base hue will end up as in either the SHO or duoband mappings. I figure I could probably do that in Gimp, since you can create colors specifically to RGB levels, but I just need to decode what the blends mean as far as percentages go so that I could generate that.


EDIT: Actually, on further thought and based on your test/verification idea above, I think I might be able to create a set of "test pattern" tiffs (maybe offset rectangles of 255 0 0, 0 255 0, 0 0 255) to compose and maybe watch what happens to them as I try out various things in Color. On a quick test of a single 3 panel image, I can already see some adjustments though. A muting, really. Perhaps the perceptual/luminance effect that had been noted in another thread.

[Mike in Rancho]

Ok everyone (or anyone who is reading this, anyway...might be few), I went full nerd and did a bunch of late night testing. Phew.

My conclusion is this: color is a meaningless pile of mush and a giant can of worms.

Just kidding. But is is hard to stay consistent. Little changes seem to be happening all the time. Results are very much affected by your sat levels, and of course Style and LRGB emulation scheme. And even with everything held the same each time, the pixel RGB levels don't always come out identical even when you think they should be. I noted that particularly with slight shifts in the blue numbers.

Anyway, here's what I did. A Drive link to various files is here: https://drive.google.com/drive/folders/ ... sp=sharing

I created three mono files that are essentially circle test patterns. When composited, they create one of those overlaying blend things. Each is just grayscale and the details are at full intensity. I may think up another set of patterns that has varying intensity, but that's for another time.

Here is what it looks like, basically, if you compose the three test files I linked. This is actually also pretty instructive for some basic testing and watching what happens, not only in the color module but compose weighting as well.

Compose of Circle Test Monos.jpg (116.93 KiB) Viewed 3664 times

Compose was done as L+Synth, and RGB for all my tricolor testing, and R(GB)(GB) for the duo testing. Unknown if this was error, but I opened the composite as linear, then did a Wipe but zeroed out all the settings (in case ST needs a Wipe), and did no AutoDev, going then straight to Color. In Color, I kept all the presets the same as to each matrix chosen. For the most part this was just the default tricolor/bicolor settings of 200%, 2.0., 2.0, and no channel bias reductions. I then kept each tricolor and bicolor matrix, saved, and opened in Gimp to use the RGB pointer on each solid panel. I did not check the blended regions. The Gimp xcf file linked has every layer (about 40 of them including two Identity OFF). Use the view button for the layers above to see them and/or blink against another layer below that is also set to "see."

Finally, I did not test any of the matrices for "Interpolate G..." or the ones like "RG0" since I have no idea what they mean, and thus would not be able to figure out if they were right or not.

I may or may not turn all of this into a "key" for each matrix setting. It could be useful as a base, but as noted, changes to saturation or style and LRGB emulation really wreak major alterations. So it would almost need a variably-sliding key based on ST's settings.

There were several matrices for which I am uncertain if they are doing what they are supposed to be doing. Or at least, doing what they say they are doing.

There are two easy ones: RGB:BRG, and RGB:GBR. I think they are just swapped.

There are three others in the tricolor that have me perplexed. Granted I am still trying to wrap my head around these channel formulae (I'm getting there!), but they still don't "look" right or seem to have the right RGB levels results for the description provided. They are:

20SII+80Ha, 100OIII, 85OIII+15Ha (my test panel #5)
85OIII+15Ha, 100OIII, 20SII+80Ha (my test panel #18)
100OIII, 85OIII+15Ha, 20SII+80Ha (my test panel #25)

Again, it could just be me still trying to contemplate the mapping correctly. All all the rest of them I need to stare at intensely some more.

Hope this is useful for anyone!

EDIT: As a tangential matter but not terribly important, there are a few places where quick "in your head" comparisons are a bit more difficult due to mixed naming conventions of the mappings. For example, in one mapping the middle (G) channel might look like 85OIII+15Ha, but in the next one or two down the middle channel is listed the other way around, as say 20Ha+80OIII. Just a note.

[Startrek]

Mike,
I had issues early last with trying to produce a Bi Color NB images of Ha Oiii Nebula from L Extreme data.It always ends up salmon , magenta or Cyan etc... definitely not Bi Color blends
Ivo gave me the details about loading Compose then using the Matrix options
I used the first Matrix option SHO ........., then all I did was reduce the green bias to say 3.50, increase the blue to 1.50 and adjust the red to taste ( usually 2.50 ) and “Bingo” a Bi Color image
It may not be technically or scientifically perfect but it’s Bi Color and pleasing to the eye , definitely a quantum leap from those all red unicolor images

OSC and DSLR’s can only do so much in regard to Narrowband images and luckily we have these great filters ( L Enhance and L Extreme ) and Startools to produce some nice Bi Color blends
Mono will always be King , but it’s a price we have to pay for true Narrowband images
Clear Skies
Martin

[Mike in Rancho]

Hi Martin, and thanks.

My concern here is more about learning the nuts and bolts of what is going on "behind the scenes" with the various mapping formulas. I don't have it all down mathematically, but I am starting to latch onto the general process.

And now that I can also add an independent SII (even if inefficient) to my duoband datasets (where appropriate), the impetus to understand this has grown.

I agree there are shortcomings in NB (or duo) through OSC/DSLR, but there can be shortcomings in everything, including mono. All depends on what equipment you have, how well it all matches up, and what you do with it. My personal line in the sand is that I accept potential imperfections (bayer contamination, inefficiency, interpolation) but still try to stay legit to the acquired data. It is false color, which is simply inherent in narrowband. But I stay away from fake or "faux" color through selective manipulation or creation of a third file (usually SII) that is just fantasy.

And besides, in many cases the bayer contamination will be utterly drowned out by the actual signal such that you could not reasonably stretch it out to notice it. And sometimes, such as the Ha shadow from R that lands in (GB), that could easily be considered an Hb tinting. In the case of an L-eNhance, that is even more legit as it is built in. Meanwhile, some mono folks will add 15% of their Ha into B/G in order to get a fake Hb colorization of their hydrogen.

After that other thread I did a few tests of bicolor but using the SHO matrix sets, and also mapped it out the best I could on some scratch paper. Indeed, as long as the (GB)(GB) was done in composite, it remains bicolor. And yes I suppose it offers more choices than just the handful of stock bicolors in ST, though many of them just scramble a bicolor such that the two hues are rather similar. Brown and brownish lol. Doing bicolor through the SHO seems to be less of the color wheel opposites, though some can still end up close.

But I can see the appeal of it if one wants more subtle hues, and lower sats isn't enough to get there.

That said, salmon and teal is the classic HOO bicolor, so I'm not sure anything was wrong. Just as long as you composed to R(GB)(GB). If you end up with three hues, then indeed something went amiss.

Anyway, in my prior post, where I pointed out the possible bugs, those linked test files can probably be tested against R(GB)(RB) for the SHO mappings, if you wanted to see what the base results are. I did not do those though. The Gimp file with all the panels just has the SHO matrices saved after a SII/Ha/OIII compose, and the bicolor matrices were the only ones done following an R(GB)(GB). Might be interesting to add those though. Takes a little while, as there are a lot of tricolor matrices!

[admin]

This is so awesome to see - someone really getting into the nitty gritty of things in real-time!

My conclusion is this: color is a meaningless pile of mush and a giant can of worms.

You jest, but in a way you are not terribly far off the mark either. It's an incredibly deep subject with 100s of nuance or arbitrary decisions at every step.

Just kidding. But is is hard to stay consistent. Little changes seem to be happening all the time. Results are very much affected by your sat levels, and of course Style and LRGB emulation scheme. And even with everything held the same each time, the pixel RGB levels don't always come out identical even when you think they should be. I noted that particularly with slight shifts in the blue numbers.

Indeed - all depends on whether you like to things consistent for a computer, or for a human observer. Even then if you push a hue/saturation/brightness value out of gamut of your screen, all bets are off as well.

Trouble with the "pure R/G/B" values from your three circles is, that most values will indeed be just that; from the other thread, remember that once an algorithm or formula starts regarding blue vs green, blue is a whopping 5.1x fainter than green at full bore. A color space or formula will happily let you say "let's pull up blue to the brightness level of green". But when it comes to converting this to RGB values again, you would get B values ("bluer than blue") far, far outside the maximum the screen can display ("out of gamut").

By using green at a visual brightness more than 5.1x that of blue, you are already forcing StarTools to work out-of-gamut from the get-go. Depending on what you are trying to ascertain/test that may or may not be a problem. The only LRGB Method Emulation not working out-of-gamut will be the "naive" "RGB Ratio" method, which does not do any color space translations at all. Instead it naively establishes the R:G:B ratios as found in the linear data and mutiplies the luminance for the R, G and B ratios it found.

Also, ever heard people say "white is not a color"? How pure white is treated is also ill-defined, depending on the color space; gray has an unknown hue or saturation and pure white's brightness (in AP that is) tends to be undefined (usually being the result of clipping an value that was out-of-bounds; overexposure).

Finally, I did not test any of the matrices for "Interpolate G..." or the ones like "RG0" since I have no idea what they mean, and thus would not be able to figure out if they were right or not.

RG0 just means it unceremoniously sets any blue (B) to 0, e.g. it pretends the blue component was 0 in the color data.

There are two easy ones: RGB:BRG, and RGB:GBR. I think they are just swapped.

Good catch!

There are three others in the tricolor that have me perplexed. Granted I am still trying to wrap my head around these channel formulae (I'm getting there!), but they still don't "look" right or seem to have the right RGB levels results for the description provided. They are:

20SII+80Ha, 100OIII, 85OIII+15Ha (my test panel #5)
85OIII+15Ha, 100OIII, 20SII+80Ha (my test panel #18)

These are indeed incorrectly labeled - should read;
20SII+80Ha, 100Ha, 85OIII+15Ha (my test panel #5)
85OIII+15Ha, 100Ha, 20SII+80Ha (my test panel #18)

100OIII, 85OIII+15Ha, 20SII+80Ha (my test panel #25)

Labeled as intended, but wrong matrix applied.

Hope this is useful for anyone!

Very, very useful.

EDIT: As a tangential matter but not terribly important, there are a few places where quick "in your head" comparisons are a bit more difficult due to mixed naming conventions of the mappings. For example, in one mapping the middle (G) channel might look like 85OIII+15Ha, but in the next one or two down the middle channel is listed the other way around, as say 20Ha+80OIII. Just a note.

Thank you once again, I am updating the list to be of the convention; S-II (if any) first, then Ha (if any), then O-III (if any)

First 1.8 maintenance release incoming soon. Thank you again!

EDIT: I'm sure you have seen me posting this before, but this is still my all-time-favourite document on what goes into color rendering, from measuring RGB values to conversion and rendering on a medium.

EDIT2: 1.8.526 MR1 now up for download.

[Mike in Rancho]

Thanks Ivo!

I had a hunch my test patterns might be too over the top. But I guess they got the job done, in a way.

Is it more because, as you say, each one was too "pure," or because they had the luminance intensity on full blast?

I will play around with them some more to try to fashion some tests that are closer to realistic, but still reveal what is happening to the base color all by itself. Maybe leave the text labels as-is, but change my circles.

I have watched that one video for "what is brown," but do not think I've seen this 300+ page tutorial before. I just downloaded it though.

EDIT: I'm sure you have seen me posting this before, but this is still my all-time-favourite document on what goes into color rendering, from measuring RGB values to conversion and rendering on a medium.

EDIT2: 1.8.526 MR1 now up for download.

EDITS:

1. I didn't realize the color document was by professor Brown, and not about brown the color.

2. My computer is ashamed that I now have to switch HDR back to medium for routine processing.

Is everyone really ripping through ST that much faster than I am? And Ivo, didn't you recently comment about more speed over more cores?

Probably not as to a lowly 4 core/8 thread CPU though. Still, it turbos at 4.0GHz, and when all cores are maxed simultaneously - such as HDR elicits, they are at 3.7.