Color and luminance separation comparison results

[ISO]

Hello folks

With reference to the earlier thread...

http://www.retouchpro.com/forums/pho...nance-rgb.html

I have done comparison of method suggested by John with Lobster droplet from free gamma (www.freegamma.com/).

The method of John is working very well for me but when it comes to saturated yellow color images there is very slight luminosity variation. Lobster give near perfect results even for such type of images.

Here are results of screen shots..

1. Splitted image (John method) original layer off.
http://i187.photobucket.com/albums/x.../untitled2.jpg

2. Splitted image (John method) original layer ON. Note diff.
http://i187.photobucket.com/albums/x.../untitled3.jpg

3. Lobster splits original layer off
http://i187.photobucket.com/albums/x...s/untitled.jpg

4. Lobster splits original layer ON
http://i187.photobucket.com/albums/x.../untitled1.jpg

5. John method color layer
http://i187.photobucket.com/albums/x.../untitled4.jpg

6.Lobster generated color layer
http://i187.photobucket.com/albums/x.../untitled5.jpg

It seems Lobster droplet employ different method of splitting color from RGB images.

Any thoughts or suggestion are most welcome.

Regards,

[Der_W]

I just played with a test file that someone over at Luminous Landscape sent me and it seems like Lobster is blending the original layer back into their chromaticity layers with some kind of mask (I guess it's a chromaticity mask).

The results are therefore perfect, but not what was originally planned, because the separation gets lost.
You can try this yourself when creating a 50% gray layer above the chromaticity set and blending it in "Color" mode. If the result is anything but a 100% solid gray (no variation at all), then it's a mix of luminosity and color (which is the case in my test file).

[ISO]

Hello Jonas

Things have become interesting and mysterious after your reply.

Thank you very much for your input.

I will try as per your guidelines.

Pl. note. Luminosity layer is the same what we achieved. I deleted lobster luma layer and placed our luma layer above colour and it works.

Regards,

[John Wheeler]

Hi Mukund

Jonas is correct.

I took a closer look at the differences going on between Lobster and the blends in PS. It was not quite what I thought before yet close.

Warning to others, this is more of a technical post of how PS blends vs Lobster blends work and their differences. If you don't need or like to know those differences, save yourself some time and skip this post. You've been warned

They both use the same definitions for Hue, Saturation, and Luminosity as per the PS blend modes:

Hue: Standard mathematical definition (Range 0 to 360 degrees)
Saturation: Max (R,G,B) - Min (R,G,B) (Range 0 to 1)
Luminosity = .3R + .59G + .11B (Range 0 to 1)

Note that in PS, Color is meant to mean combination of Hue and Saturation as per the definitions above. Also note that the above Blend definition of Saturation is different than the Saturation numbers you see in PS Color Pickers.

Unlike RGB where each color channel can independently have any value from 0 to 255, Hue, Saturation, and Luminosity as defined above have dependencies on their Range (e.g. for a given Hue, not all combinations of Luminosity and Saturation are possible).

In the PS blends of Hue, Sat, Color, Luminosity,, that means there has to be priority given to one of the channels when there is a conflict. In PS: Hue, and Luminosity take precedence over Saturation as defined above. E.G. Solid Yellow (R=255,G=255,B=0) Hue=60degrees, L=.89, Sat=1.

In extracting Color (Hue and Sat) in Photoshop with a gray layer at 50%, with priority given to Hue and Luminosity, Saturation must be reduced with a result of R=144,G=144,B=1 Hue=60 degrees, L=.5, Sat=.56.

Extracting the luminosity as indicated before works fine since it takes priority.

The downside the blending prioritization approach in PS is that once the Luminosity and Color (Hue + Sat) are extracted, since the Sat is not always maintained, if you combined the Luminosity and Color back together, you would not end up with the original image. That is why in the comparison Mukund provided when trying to combine the luminosity and color back together, the saturation was reduced.

In Lobster (I do not have a copy to verify), I believe that the key difference is the when extracting the Color/Chroma (Hue and Sat) priority is given to Hue and Saturation over Luminosity set at .5. This will create an extraction with the same Hue and Saturation as the original yet the result will not be a constant Luminosity. The advantage of this approach is that you can combine the extracted Luminosity and the Lobster extracted Color/Chroma and end up with the same original image.

The extraction as per Lobster can also be done in PS yet with quite a few more pushups than what I had provided before. This could all be automated in a PS action. I question the value though if one already has Lobster software in their possession.

It was an interesting puzzle and I learned a little more about PS blends in the process so thanks for posting the thread.

Sorry for the long technical post

[Der_W]

Out of pure technical curiosity (I haven't found any of my typical images on which the easy workflow with the luminosity at 0.5 wouldn't work perfectly) but how would you go about recreating what Lobster does in Photoshop?

I'm actually a little stuck in my own methods so I'm probably running against a wall trying to replicate their result the whole time and so it'd be great if you could give me a hint :-).

[John Wheeler]

Hi Jonas

(and all others not interested in technical details save some time and skip the post)

I too initially thought that separating out the luminosity and then the color at gray/L at 50% could be recombined quite successfully. I was aware that the Saturation as defined in previous post was at risk yet also incorrectly thought that pulling out Color at 50% would cover that. For images with lower saturation it is not as obvious. With colors with high saturation it is quite a problem. The following example shows this:

- I started with a fully saturated color wheel
- Extracted Color at gray/L at 50%
- Extracted Luminosity
- Combined Luminosity (lower layer) with Color (upper layer) with upper layer Blend set to Color
- Grouped passthrough and masked to show result on top portion of image and original in bottom portion of image.

You can see that for many colors at max saturation the color appear similar while others there is a more significant shift. In reality, the saturation is lower for most all of the result colors. Again this is using a worst case starting point of only fully saturated color wheel yet it demonstrates quite well the flaw in my original thinking that Color extracted at gray/L=50% was OK for recombining back with the Luminosity to get the Original Image.

Screen shot 2011-06-17 at 5.30.42 PM.jpg

The efficacy of accurately reproducing the Lobster extracted colors I believe is in question. The reason being is that it (as well as PS) is based on a definition of Saturation which IMO was based on computational efficiency rather than meaningfulness from a color model. You may see why below.

I do not know any specifics about Lobster extraction yet I would guess it follows something like my approach outlined below per your request/question.

First let me give a definition based on RGB values with
Cmax being Max (R,G,B) Range 0 to 1
Cmin being Min (R, G, B) Range 0 to 1
Cmid being the remaining color channel other than Cmax and Cmin Range 0 to 1

So we have 3 color values in the range of 0 to 1 typically all 3 somewhere in the middle of that range for most images.

Sat = Cmax-Cmin

I have not double checked my math yet it appears that if you want to shift the Luminosity by Delta L yet hold the Hue and the Saturation, all you have to do is subtract that Delta L value equally from all the Color Channels. This is computationally efficient and only works when:
- If delta L is postitive that Delta L <= Cmin
- If delta L is negative that |Delta L| <= 1-Cmax

Visually, what this means is that the relative spacing among the 3 color values remains fixed and you slide the group down or up with a limit that Cmin can't go below 0 and Cmax can't go above 1. This keeps the the Blend definition of Sat whole as long as this is maintained.

If the Delta L is larger then these limits then the Sat is not held constant while the Hue is held.

For the PS Luminosity and Color to be properly combined, the Max Delta L allowed for a pixel should not exceed the limits above and therefore Saturation is given priority and Luminosity is sacrificed.

-We already have what starting L value is. Delta L is just is a subtracting .5 when L is above .5 and is subtract from .5 when less than 1.
- Take the min with Cmin or 1-Cmax respectively and then use Subtract Blend or Linear Dodge (Add) respectively.

I have not double checked the above approach nor looked form more layer efficient ways to proceed (I am sure there would be) yet have tested the concept and it seems to work. This should give you an idea of what would be needed to get you going. Like I said, the efficacy of doing this is limited by the value and reason behind PS definition of Saturation for these Blend modes. As you can see from my above explanation, it appears to be more computationally easy than necessarily color model meaningful.

I don't know if this is the Lobster approach so am guessing based on the images that they and Mukund have shared.

Hope this was of some use to you.

[ISO]

Thanks John for the detail reply.

You might want to check your approach with actual Lobster droplet. Following are links for free evaluation copy.

For Mac

http://www.freegamma.com/LobsterDemo.dmg

For win

http://www.freegamma.com/LobsterDemoInstaller.zip

It works with CS3 & CS4

[Der_W]

Hi John,

thank you for your valuable input :-)!
It turns out that I tried something quite similar (subtracting lower/higher luminosity values to keep the channels from clipping and combining the results), but your way seems more efficient than my earlier tries :-)!

I'll try your method and see if it works for me as well!

[Flashtones]

Can someone explain how this separation would be used in day to day retouching?

Best I got from a quick look at the Lobster site is it's a better way of making luminosity adjustments. But what else?

[John Wheeler]

Good question Flashtone

I don't know all that Lobster has to offer vs the normal blend options of Color, Hue, Sat, and Luminosity.

Sometimes the term "separating out" the Luminosity from Color (Hue and Sat) makes it sound more complicated that it really is. Here are a couple examples

If I have an image and put a Levels (or Curves) adjustment Layer above it, if I use the middle slider on Levels on all 3 RGB color channels simultaneously (or non linear curve with Curves), one will introduce a Hue shift for some parts of the image. By setting the blending mode to Luminosity on the Adj Layer, the Hue of the original image is maintained, the adjustment Layer only changes Luminosity (no Hue shift). Note that the blend attempts to keep the Sat of the original image yet will give priority to the Luminosity shift of the Adj Layer

Another simple example same as above yet I use a Hue/Sat adjustment Layer. If I want to shift the colors yet maintain the Luminosity of the original image, I set the Blend mode of the Adj Layer to Color. This will respect the Hue shift from the Adj Layer yet maintain the Luminosity of the original image. Note that this blend tries to use the Sat value from the Adj Layer yet gives priority to the Luminosity of the original image.

So in both of the above cases, the Luminosity and Color are effectively split and modified (or not) separately.

There are many other options/techniques. I like to think of it as a complete additional color mode (Luminosity, Hue, Sat) sitting right inside RGB color mode (except you don't have the downside of switching color spaces and associated issues e.g. possibly having to flatten layers etc etc)

Hope that makes sense and is more helpful than what can come across as technobabble of my other posts

[Flashtones]

Thanks John.

Sure, setting adj layers to Lum, hue, sat or color is the usual approach. I'm wondering in what situations one would go the next step to actually separating the image into luminosity and chromacity layers before adding adjustment layers?

IOW, why physically separate the color from the luminosity (using the plugin or your alternative approach) when we can effectively do the same with adj layers and blend modes?

[Der_W]

Because we can't (at least not fully).

The problem with the blending modes is that they take effect after the adjustments were applied.
I did a test image here where I first drew an overlay curve and then applied it in "Color" mode.

This is the original: http://dl.dropbox.com/u/7124285/JW-P...pieren_PRE.jpg
This is the curves applied in "Color" mode: http://dl.dropbox.com/u/7124285/JW-P...erkopieren.jpg
This is the curves applied to the color directly: http://dl.dropbox.com/u/7124285/JW-P...eren_Farbe.jpg

As you can see when the curve is applied to the color, the results are richer and less shadows/highlights desaturate.


On the other hand personally I haven't found much use for this separation in my workflow as I tend to work out the main color and luminosity in the RAW converter, so no need for this kind of curves.

Jacob Rus at the Applied Color Theory newsgroup also wrote a reply to a somewhat similar question. Here's the advantages and disadvantages of the separation he came up with:

Originally Posted by Jacob Rus

To my mind, here are advantages:

* Not all filters work in CIELAB mode
* The curves dialog is designed for RGB and is a horribly inflexible and
limited interface in CIELAB mode; this can be improved somewhat by
doing something like the "ladder" trick, but even that is far from ideal.
* You can't use the exclusion blending mode in CIELAB mode. This is
really tragic because the combination of exclusion + linear light mode
layers allows some really powerful tricks.
* Some RGB color space might be your intended output space, in which
case you won't have to worry about gamut clipping between working
view and final output.

And the disadvantages:

* Photoshop's way of splitting "luminosity" (a term made up by Adobe)
from "color" is an extremely bad approximation of the way the chromatic/
achromatic components are split by human color vision. The mathematical
computation it does is only actually meaningful when gamma = 1.0, and
the primaries in use are the NTSC primaries. When you use sRGB, the
computation is essentially arbitrary. In practice any kind of operation
performed by Photoshop luminosity/color severely distorts every color
relationship in a usually undesirable way. CIELAB is a much better
approximation (though it suffers some big problems with hue constancy
along radial lines).
* RGB is an extremely unnatural way to break up the colors of an image,
so every time you do anything with tools like hue/saturation, curves,
etc. you'll end up severely distorting hue, chroma relationships between
colors, or else spending inordinate amounts of effort trying to avoid
such distortions. This is true whether you work on your original image
or work with some intermediate processed form.
* If you plan to output CMYK, it's very difficult to get the content of your
image to properly fill the CMYK gamut in most RGB working spaces.

There are probably some other advantages/disadvantages, but this is
enough of a list for now. :-)

See the full post here if you're a member of the group: http://tech.groups.yahoo.com/group/c.../message/23975

[John Wheeler]

Hi Flashstone

For most basic image processing as Jonas also mentioned, I too use Lightroom (or ACR) and sometimes don't even need to go to PS.

There are two approaches that I think about where I use this type of capability

1) Specific turn the crank how to I solve a specific problem type of approch. Here are just two examples of how I have used the separation
- For mask creation, for me it is how do I best separate out what I want from what I don't want. Separating out the Luminosity/Hue/Sat provides me options for mask creation that is a new angle compared with other approaches.
- For eliminating some camera sensor based Moire patterns per my previous post on ReTouchPRO and here is the direct link to my blog (details in the screencast): http://jkwphoto.blogspot.com/2011/05...ove-moire.html
- many many other approaches yet point 2 may better explain why

2) Second way of looking at how to use the separation: On a broader base of thinking about the value of separating out Luminosity and Color (Hue and Sat) is basically identical to why you would want to see the individual channels of any color model/mode. Why would you want to see or manipulate the individual channels of RGB. Why would you want to see or manipulate the individual channels of LAB. Why would you want to see or manipulate the individual channels of CMYK. Basically it gives me insight to the image and the problems I am trying to solve. It also provides approaches to the solution that are not available when the channels are just all combined with each other.

The main difference with the Luminosity/Hue/Sat model embedded in the RGB model is that you don't have a channels panel to have immediate easy access to each separate channel so you have to pull them out with a Layers approach.

I am certainly not trying to sell this technique for anything special. Just another technique within PS among many others. So I will leave this with you to think about. Every time you hear about a technique that touts the major advantages of converting to LAB mode so the the color and Luminosity are separated and can be manipulated separately, there is often a way to do the same thing (or very similar) from right within RGB using the separation techniques talked about above. Each color mode/model has its strengths and weaknesses so this is just another option to explore.

So what is it good for? Sometimes you have to go exploring to find out just like exploring any other available color model/mode. Hope that helps.

[andrewrodney]

I too have to wonder what the practical implications of all this really is. We have a process designed by Thomas Knoll way back in 1990, whereby there is a boost in saturation (which I suppose produces what some are saying is a hue shift?) when altering “luminosity” (the wrong term but one we have to live with). We also have the ability to use blend modes to counter this designed effect. According to Thomas, there’s a lot more code involved doing the move as he designed it, and he designed it because *most* users prefer the rendering. But its not forced upon us.

It seems that for many years, the idea that having this rendering was wrong. Colorimetrically? I suppose. What about the results of this distortion or lack of distortion when once again, we have to convert the data to an output color space? What appears preferable to the user, with or without the ‘shift’ is all that matters. And it appears this is a bit moot if you do all this work in a raw converter which I think makes far more sense for so many reasons.

I think the question should be, with the two (or even more) options in Photoshop alone, is there a need for a 3rd party product? If one decides to do all the heavy lifting in terms of global color and tone work from raw, is there any difficulty with the current Adobe tools and if so, are there other raw converters that solve this problem if the problem even exists?

In practice any kind of operation
performed by Photoshop luminosity/color severely distorts every color
relationship in a usually undesirable way.

RGB is an extremely unnatural way to break up the colors of an image,
so every time you do anything with tools like hue/saturation, curves,
etc. you'll end up severely distorting hue, chroma relationships between
colors, or else spending inordinate amounts of effort trying to avoid
such distortions.

This may be true in the context of the math. But the image(s) itself? Can someone illustrate the distortions such that using either of the above Photoshop methods, or an Adobe raw converter, the image is unacceptable visually? I don’t care about the math behind the process, I care about the image rendering.

[andrewrodney]

Oh, and in terms of having this distortion or lack of distortion while working in RGB or otherwise, there’s no such distortion in either case when converting to an output color space or even another RGB working space? Considering the effect of rendering intents on a conversion, I kind of doubt it. Is this all a solution in search of a problem?

[John Wheeler]

Originally Posted by John Wheeler

The efficacy of accurately reproducing the Lobster extracted colors I believe is in question. The reason being is that it (as well as PS) is based on a definition of Saturation which IMO was based on computational efficiency rather than meaningfulness from a color model.

I would have to agree with Andrew (glad to cross paths with you again). For a $99 plugin the value add does not seem to be there IMHO. I also did not mind doing the little bit of evaluation though because it did sound initially intriguing. Sometimes there really is a difference in what tools have to offer. With the initial look though, I have not been intrigued enough to download the evaluation copy. If there is someone out there with more knowledge of the tool and why it would be worth purchasing, it would be great to hear.

[e2b]

Originally Posted by John Wheeler

If there is someone out there with more knowledge of the tool and why it would be worth purchasing, it would be great to hear.

As I understand it, Lobster makes two claims:
1. That separation of luminosity from chromaticity is useful.
2. That of the various possible sets of chromaticities that could be separated from luminosity, the set that Lobster produces is particularly (if not uniquely) useful.

I too would be interested in hearing about how these claims stand in the light of practical experience.

I have managed well enough until now without finding a need for this sort of separation, but nevertheless I have found this whole thread absolutely fascinating, especially the insights into the inner workings of PS - thanks Der_W, for drawing it to my attention

Steve

[John Wheeler]

Originally Posted by e2b

...nevertheless I have found this whole thread absolutely fascinating, especially the insights into the inner workings of PS - thanks Der_W, for drawing it to my attention
Steve

Hi Steve and any other ReTouchers that are also fascinated by the inner workings of PS (isn't that the definition of a fellow gearhead? ) then here is a reference for you (WARNING - not directly useful to the retoucher unless you need the math insights)

Buried away in Adobe's "PDF Reference and Adobe Extensions to the PDF Specification" is a boatload of details on their inner workings of Adobe software including Photoshop. This document is "in theory" a common reference for all their Adobe products (not sure I really believe that). In any case, the math for all the blending modes (including Color, Hue, Sat, Luminosity and all the others) are found starting around 320 of this PDF document with the actual blend equations starting on page 324 (told you it was buried).

Here is the reference to the PDF file for the original PDF document:

http://wwwimages.adobe.com/www.adobe...32000_2008.pdf


Here is the reference to the Adobe page with all the udpates to that document.

http://www.adobe.com/devnet/pdf/pdf_reference.html

And yes, the word "fascinating" is in the eye of the beholder

[Flashtones]

Thanks for the thorough replies. I've played with the separation at various times in the past thanks to the actions of a certain generous poster here (shout out to Jonas!)

It's interesting and fun, but I just always forget to break it out for use when I'm actually working and not just testing.

Jonas, I agree in your provided example it looks better. Interestingly, it more resembles a HSL layer set to about +45 saturation than it does a curve in color mode. However, it seems to do so with less banding in the background, thought I wonder if that might be because the original you worked on was higher bit or less jpegged than the original I borrowed (solely for this test of course) from your post?

[e2b]

Thanks for the links to reference material John. It is not just the mathematics that interested me, but the insights into quirky things like the special definition of luminosity, inconsistencies in usage between different modules within PS, etc. (thanks Jonas). I guess there must have been many decisions made in the process of developing PS, which were expedient at the time, but now seem hard to explain.

To me, PS is essentially a very successful commercial product that satisfies the vast majority of its users, even if it does some odd things internally - it is not intended to be a sort of universal programming language. However, it has become such a standard tool that people seem compelled to go out of their way to achieve within PS (with actions, plugins and droplets) that are not really in its nature.

Sometimes it is better to do things outside the constraints of PS, with Lightroom being a case in point.

Steve

[John Wheeler]

Originally Posted by e2b

Sometimes it is better to do things outside the constraints of PS, with Lightroom being a case in point.Steve

Agreed or ACR as another.

[Der_W]

Hi Flashtones,

it's not just the web version (I did the whole test on this version, so it's the same file I was working on).
There really seems to be slightly less banding in the background and the lower saturated tones seems to stay less with the overlay curves (which in my opinion looks more natural).

However as you correctly said, it looks really close to each other, so why worry about the little differences and do the extra work.
It's nice to have options like these, but it's certainly no must :-)!

Edit: +1 to doing things in Lightroom/ACR.
Edit #2: Don't know if you've seen this one already: http://av.adobe.com/russellbrown/Layers2ACR_SM.mov (script here: http://www.russellbrown.com/images/t..._Installer.zip)

[nebulaoperator]

Great article. Thank you John and everyone. Thank you for script Jonas.