The new Color module demystified

Guides, tutorials, tips & tricks.
User avatar
admin
Site Admin
Posts: 3367
Joined: Thu Dec 02, 2010 10:51 pm
Location: Melbourne
Contact:

The new Color module demystified

Post by admin »

So you had a play with the latest beta and you may have come across the new Color module.
If all is well, the results you've been able to achieve are a lot better, but there are a good number of new features in there.

All of a sudden there are parameters like 'Style' and 'LRGB Method Emulation' and some of you have understandably cried out "I thought StarTools was supposed to make things simpler!".

This post is to demystify what exactly StarTools is doing to your colors and how the Style and LRGB Method Emulation let you wield awesome power, virtually without having to lift a finger.

First up is the 'Style' parameter. Ever since Tracking (and by extent, non-linear processing) was introduced in 1.3, a number of completely new and innovative abilities were bestowed upon StarTools' modules.
We're all familiar with StarTools detail aware noise reduction, deconvolution after stretching, and lately the intelligent 'detail aware' wavelet sharpener. Around 1.3.2 the Color module was revamped with a new way of Color compositing, separating luminance and color processing completely. At the time it seemed like the logical way to implement it, having the Tracking data at our disposal, but it turned out to have some more interesting atributes.

This algorithm, which is now embodied in the 'Scientific (Color Constancy)' setting of the 'Style' parameter, is a new, more scientifically accurate way of representing color in your images. Color perception is a difficult subject and there are no right answers to what constitutes 'the right way' to present color in deep space images. I'd love to elaborate on this, but we'll save that discussion for another time. What does exist, however is a 'worse' way of presenting color in deep space images and it is, unfortunately, surprisingly common. Take this image of the Orion nebula for example;
o_old.jpg
o_old.jpg (104.68 KiB) Viewed 20851 times
It's not the prettiest image, but there's nothing majorly wrong with that. Or so you'd say... Indeed, this is typical of the best that people using other software come up with in terms of color. But here is the rub;
o_uns.jpg
o_uns.jpg (12.71 KiB) Viewed 20851 times
This is the exact same image, same color calibration, just stretched less. The core now appears green (which, incidentally, is correct; OIII emissions are dominant), you might also notice that the stars that are visible are much bluer.
So how come, in the previous image, the core was nearly white?

The answer is that this is the result of (erroneously) stretching the color data along with the luminance (brightness) as well, which is strangely very much common practice, even in other software that prides itself on scientific accuracy. Color is a product of discrepancies in the red, green and blue channels. Stretching these channels non-linearly deforms, stretches, squashes and skew these discrepancies based on their in-channel brightness. The result is that hues and saturation levels vary wildly as the user starts stretching the data in order to recover more luminance detail.

Ofcourse, the notion that things out there in space 'magically' change their color based on how we stretch our image would be a fairly ludicrous proposition. Yet, sadly, here we are, with a majority of images out there suggesting that this is the case. :(

Now look at the two images again. The core is clearly green in the second (less stretched) image, while the core in the first image is so pale that we might have missed it is actually green (indeed many astrophotographers throw their hands up in the air and just depict it as white). However, notice the area adjacent to the core at 3 o'clock (in the second image it is completely absent). It is decidedly more green. Could the two areas be of similar chemical make up?

In fact they are! It is just neigh impossible to see, as stretching the luminosity component has (for no good reason at all) drained the core of its color, compared to the area adjacent to it.

And here is where StarTools' Tracking aided color compositing algorithm comes in;
o_new.jpg
o_new.jpg (117.9 KiB) Viewed 20851 times
New let's ignore for a minute that the colors might appear a little oversaturated. In the interest of fairness I applied the same settings for image #1 and image #3. I had to be a good bit more aggressive with the saturation to show any color in #1.

What we're seeing here is 'color constancy'. No matter how the image was stretched, the colors are absolutely comparable between areas that vary wildly in their dynamic range. The area adjacent to the core at 3 o'clock is the exact same green as the core. Also spare a moment to look at the stars. They now show color, no matter how dull or bright they are. The full visible black body emission spectrum is covered and what's most important - temperatures are completely stable and independent of how dull or bright they were recorded and subsequently stretched. This is because StarTools stays true to the color data as initially recorded, undoing all the stretching (thanks to Tracking!) to the luminance data to arrive at the 'virgin' colors as they were recorded.

This is how color in space should be presented from a scientific point of view - reproducibility no matter the exposure time or who processed it, with true separation from the way luminance was processed. Faint Andromedas should produce the same colors as bright Andromedas. Short exposure star fields should produce the same colors as long exposure starfields, etc.

Here is another striking example;
glb_old.jpg
glb_old.jpg (14.85 KiB) Viewed 20851 times
vs
glb_new.jpg
glb_new.jpg (18.25 KiB) Viewed 20851 times
Notice how star colors are recovered until well into the core of the globular cluster, while the viewer is able to objectively compare star temperatures all the way; colors are constant and comparable throughout the DSO.

Now, as of 1.3.5 there is actually a way to 'dumb down' (which perversely was a lot of work to implement and get right!) color compositing to the levels of other software. StarTools is all about enabling the user, not about pushing philosophies, so if you want to create images with the 'handicapped' traditional look you now can, using the 'Artistic' setting for the 'Style' parameter.

As a StarTools user you may have felt that your colors were never quite like 'the other guys'; more vivid, just more colorful. And you would have been right. You may have secretly liked it but you may have been uneasy being proud of the result as it is 'different' to what a lot of other folks have been producing (your Andromeda may have had a 'strange' yellow core, your M42 may have had an 'odd' green core, your M16 may have had many more tints of red and pink, or your stars seemed almost too CGI-pretty to be true). Now you now why, and now you know you can be just as proud at your images - perhaps even more, as they have been more scientifically correct/valuable to look at than the other guy's.

Now, on to the enigmatic 'LRGB Method Emulation' setting.
Over the past two decades, astrophotographer have struggled with compositing color (e.g. combining separate luminance and color information) images, leading to a number of different LRGB compositing methods. I won't go into them here, but all attempt to invarably 'marry' luminance and color information. The different techniques all produced different hues and saturations for the same data. And what is true for all of them is that they involved a lot of layering and pixel math to produce.

Because StarTools separates color from luminance until the very last moment (that moment being when you use the Color module), really any method of color compositing can be chosen for combining the data at that moment. The 'LRGB Method Emulation' simply lets you choose from a number of popular compositing techniques at the click of a button. You will notice that all these different settings have a subtle (or sometimes not-so-subtle) impact on the hues (and sometimes saturation and luminance) that are produced. It's just that easy.

Even if your data was from a non-LRGB source, it still works as StarTools will have still separated color from luminace during processing by creating a synthetic luminance frame from your RGB-only data where needed. Conversely, as you may have seen in the latest YouTube video, processing LRGB data is now no different than processing DSLR or OSC data. Luminance is separated anyway! The only difference is that you load your data through the LRGB module. It's a big step towards a unified yet extremely powerful workflow for all data sources.

I hope this little write-up has been informative (and hopefully mildly thought prevoking :twisted:) and the usage of the Color module is now a bit clearer. If you have any questions, do ask away!
Ivo Jager
StarTools creator and astronomy enthusiast
User avatar
Cheman
Posts: 386
Joined: Tue Aug 20, 2013 11:20 pm
Location: Gardnerville Nevada, USA
Contact:

Re: The new Color module demystified

Post by Cheman »

great info and great StarTools tools as usual. Keep up the fantastic work you do :thumbsup: .
Che
User avatar
admin
Site Admin
Posts: 3367
Joined: Thu Dec 02, 2010 10:51 pm
Location: Melbourne
Contact:

Re: The new Color module demystified

Post by admin »

Cheman wrote:great info and great StarTools tools as usual. Keep up the fantastic work you do :thumbsup: .
Che
Thanks Che! :D
AP is such an incredibly deep subject, and there is so much to take into account and improve on when you sit down and investigate what the current state of the art is...
Ivo Jager
StarTools creator and astronomy enthusiast
astromr
Posts: 3
Joined: Sat Oct 19, 2013 4:41 pm

Re: The new Color module demystified

Post by astromr »

Hi Ivo,

true words in your last post, and a well written text about colours in your first post. Very interesting.

The text immediately reminded me to the article in the German magazine "Sterne und Weltraum" in 2009 (astrofotografie.fg-vds.de/artikel/pdf/Noligcra_FG-Astrophotographie.pdf, unfortunately in German), where Harald Tomsik and Peter Riepe describe the algorithm "NOLIGCRA". There, stretching is performed in a way so that the ratio between the three colors R, G and B stays constant. The result is similar to yours. The method has been implemented in Regim already, an Astrophotography Tool by Andreas Röhrig. I guess Fitswork, another German Astrophotography tool, uses a similar method, when you select "Y" in the histogram window there.

So you are not alone with that idea, and these guys only underpin your color approach in StarTools. Excellent work!

Best regards
Michael
User avatar
admin
Site Admin
Posts: 3367
Joined: Thu Dec 02, 2010 10:51 pm
Location: Melbourne
Contact:

Re: The new Color module demystified

Post by admin »

astromr wrote:Hi Ivo,

true words in your last post, and a well written text about colours in your first post. Very interesting.

The text immediately reminded me to the article in the German magazine "Sterne und Weltraum" in 2009 (astrofotografie.fg-vds.de/artikel/pdf/Noligcra_FG-Astrophotographie.pdf, unfortunately in German), where Harald Tomsik and Peter Riepe describe the algorithm "NOLIGCRA". There, stretching is performed in a way so that the ratio between the three colors R, G and B stays constant. The result is similar to yours. The method has been implemented in Regim already, an Astrophotography Tool by Andreas Röhrig. I guess Fitswork, another German Astrophotography tool, uses a similar method, when you select "Y" in the histogram window there.

So you are not alone with that idea, and these guys only underpin your color approach in StarTools. Excellent work!

Best regards
Michael
A very interesting article indeed, highlighting the exact problem StarTools tries to address. The technique in the article isn't new however, and I've found references to this technique going back as far as 1999 - also by some clever German astronomers. Take for example this article by Till Credner of the Max-Planck-Institut für Aeronomie. In fact, it apppears this algorithm has been reinvented many times (see here for example), including by yours truly in the earlier versions of StarTools.

In fact, this method of color rendering is available in the StarTools Color module in the 'LRGB Emulation Method' parameter under 'RGB ratio' .

There is a fundamental flaw with this method though, which is that it does not take into account any psychovisual effects on hue and saturation that this method has. If luminance is really to be taken as gospel, then any color combination should not affect *perceived* luminance. Yet this method does exactly that unfortunately - multiplying luminance by a pure blue pixel will significantly reduce perceived luminance for the end result pixel (roughly by a factor of 8.7 versus a pure grey pixel), yielding correct color, but causing luminance to be very, very low. Therefore a more sophisticated algorithm is required to restore perceived luminance to what it was before color was introduced. CIE L*a*b color space luminance retention does exactly that.
Ivo Jager
StarTools creator and astronomy enthusiast
puckja
Posts: 30
Joined: Thu Sep 19, 2013 3:27 pm

Re: The new Color module demystified

Post by puckja »

Wonderful post! I have been wondering why suddenly the Color Module worked quite different after I upgraded into beta version. Exactly as you described, I was "surprised" to see those different color result before I read this post. As guilty I am, I switched back to "dumbed down" style before I know any better. :lol:

I am with you about the ill effect of stretching Lum and RGB data together. Mostly my data came from OSC cam. I am glad to know that ST separate L and RGB channels for stretching. Does that mean we should avoid any further histogram manipulate after "COLOR" module? Or my underlaid question is that does ST always separate them or at some point L & RBG will be "flattened" together?

And if we import nonlinear image into ST (no tracking activated), does ST still separate L & RGB in those files for further processing?

Thanks!
User avatar
admin
Site Admin
Posts: 3367
Joined: Thu Dec 02, 2010 10:51 pm
Location: Melbourne
Contact:

Re: The new Color module demystified

Post by admin »

puckja wrote:I am glad to know that ST separate L and RGB channels for stretching. Does that mean we should avoid any further histogram manipulate after "COLOR" module? Or my underlaid question is that does ST always separate them or at some point L & RBG will be "flattened" together?
Yes and no. :) In Photoshop terms, the Color module 'flattens' L and RGB color, but it's still not permanent. After using the Color module any further stretching will affect the color, as you say. However, you can just redo Color again for a second (or third, etc.) time and it will fix up the colors for you again. The only caveat is that you must use the CIELab LRGB emulation modes if you use Color multiple times (they are the only ones that truly separate luminance and color). If you don't (e.g. you use the 'LRGB Ratio' or '50/50 Layer' modes without CIELab luminance retention) then Color's manipulation of the signal will affect the luminance as well.
And if we import nonlinear image into ST (no tracking activated), does ST still separate L & RGB in those files for further processing?
No unfortunately not - the Color module relies heavily on the Tracking information to keep color constant.
Ivo Jager
StarTools creator and astronomy enthusiast
puckja
Posts: 30
Joined: Thu Sep 19, 2013 3:27 pm

Re: The new Color module demystified

Post by puckja »

Ivo:

Thanks a lot for the detailed info. I will keep that in mind.

Another thing I found about this "new" color module behavior was that: I feel the brightness of the nebulosity (e.g. the bubble nebula) was reduced somehow as soon as the change was made in the color module. This was some kind of "side effect" that I was puzzled and hence hesitate to use the color module.

On the other hand, if I de-track it (and hence denoise the image) and then came back to color(, which is not ideal at all), then there is no such "nebulosity brightness reduction" effect.

So what is the right way to do it without my problem? Thanks!

Puck
User avatar
admin
Site Admin
Posts: 3367
Joined: Thu Dec 02, 2010 10:51 pm
Location: Melbourne
Contact:

Re: The new Color module demystified

Post by admin »

puckja wrote:Ivo:

Thanks a lot for the detailed info. I will keep that in mind.

Another thing I found about this "new" color module behavior was that: I feel the brightness of the nebulosity (e.g. the bubble nebula) was reduced somehow as soon as the change was made in the color module. This was some kind of "side effect" that I was puzzled and hence hesitate to use the color module.
Puck, that should *not* happen. Could you perhaps post a before and afater screenshot so we can see the problem? The whole idea behind StarTools seperation of luminance and color is that perceived brightness should not change. To that end, the Color module does its processing in CIE L * a * b color space (with a daylight white reference), which is supposed to psychovisually retain brightness independent of colour. What sort of monitor do you use for your processing? Is it calibrated?
Ivo Jager
StarTools creator and astronomy enthusiast
puckja
Posts: 30
Joined: Thu Sep 19, 2013 3:27 pm

Re: The new Color module demystified

Post by puckja »

Ivo:

Thanks for taking a look. The image before going into COLOR module is here:
https://dl.dropboxusercontent.com/u/554 ... before.jpg
Before going into COLOR
Before going into COLOR
before.jpg (115.02 KiB) Viewed 20642 times
The default setting render the image like this:
https://dl.dropboxusercontent.com/u/554 ... 0Color.jpg

Trying to reduce the over saturation, and cap green color to brown, but it was still not quite right:
https://dl.dropboxusercontent.com/u/554 ... 0color.jpg
After COLOR
After COLOR
after color.jpg (155.86 KiB) Viewed 20642 times
This is one version that I de-noise first and then used COLOR module:
https://dl.dropboxusercontent.com/u/554 ... _ST_2.tiff

The stacked (7x3min) data is here:
https://dl.dropboxusercontent.com/u/554 ... stack7.fit

The images were taken with Lodestar Color and calibrated/stacked by AstroArt 5, and then processed by ST 1.3.5.262

Log:
-----------------------------------------------------------
StarTools 1.3.5.262
-----------------------------------------------------------
File loaded [M:\Puck_personal\Astro Image\AA\2013_1117\bubble_180s_AA+defect8k_stack7.fit].
---
--- Auto Develop
Parameter [Ignore Fine Detail <] set to [Off]
Parameter [Outside ROI Influence] set to [50 %]
--- Crop
Parameter [X1] set to [10 pixels]
Parameter [Y1] set to [9 pixels]
Parameter [X2] set to [743 pixels (-9)]
Parameter [Y2] set to [569 pixels (-11)]
--- Wipe
Parameter [Mode] set to [Correct Color & Brightness]
Parameter [UNKNOWN] set to [Yes]
Parameter [Precision] set to [256 x 256 pixels]
Parameter [Dark Anomaly Filter] set to [12 pixels]
Parameter [Drop Off Point] set to [0 %]
Parameter [Corner Aggressiveness] set to [100 %]
Parameter [Aggressiveness] set to [60 %]
--- Develop
Parameter [White Calibration] set to [Use Stars]
Parameter [Gamma] set to [1.00]
Parameter [Skyglow] set to [0 %]
Parameter [Digital Development] set to [86.32 %]
Parameter [Blue Luminance Contrib.] set to [100 %]
Parameter [Green Luminance Contrib.] set to [100 %]
Parameter [Red Luminance Contrib.] set to [100 %]
Parameter [Dark Anomaly Headroom] set to [5 %]
Parameter [Dark Anomaly Filter] set to [Off]
--- Wavelet Sharpen
Parameter [Intelligent Enhance] set to [Yes]
Parameter [Scale 1] set to [100 %]
Parameter [Scale 2] set to [100 %]
Parameter [Scale 3] set to [100 %]
Parameter [Scale 4] set to [100 %]
Parameter [Scale 5] set to [100 %]
Parameter [Mask Fuzz] set to [8.0 pixels]
Parameter [Amount] set to [100 %]
Parameter [Small Detail Bias] set to [75 %]
--- Develop
Parameter [White Calibration] set to [Use Stars]
Parameter [Gamma] set to [1.00]
Parameter [Skyglow] set to [0 %]
Parameter [Digital Development] set to [82.93 %]
Parameter [Blue Luminance Contrib.] set to [100 %]
Parameter [Green Luminance Contrib.] set to [100 %]
Parameter [Red Luminance Contrib.] set to [100 %]
Parameter [Dark Anomaly Headroom] set to [5 %]
Parameter [Dark Anomaly Filter] set to [Off]
Post Reply