Accepted Wisdom | Ledet Dan Margulis Photoshop Training

Ledet training home -> Adobe training -> Photoshop training -> Professional Photoshop training with Dan Margulis

Dan Margulis Applied Color Theory

Accepted Wisdom and Luminosity

PP5 book and 10 channels

Posted by: "chris broadhurst"

Sat Dec 29, 2007 2:46 pm (PST)

Hello,

I read (only twice) the Lab book and have asked for and now got Dan's PP5 book for Christmas and have a basic question which I hope you can answer as I'm sure Dan is busy recording the videos (which I'm really looking forward to).

He mentions 10 channels - why is the grey channel (rgb desaturate) omitted as a potentially useful channel to use?

It is significantly different from the L lab channel (and of course all the other channels).

Is there nothing useful in this channel to correct images?

Thank you

Chris Broadhurst

Web Site: http://www.broadhurst-family.co.uk/lefteye/

____________________________________________________________________________

Re: PP5 book and 10 channels

Posted by: Stephen Marsh

Sat Dec 29, 2007 6:00 pm (PST)

Chris Broadhurst wrote:

He mentions 10 channels - why is the grey channel (rgb desaturate)

omitted as a potentially useful channel to use?

One could also ask why the simple mode/grayscale command or C2P Gray is not included. I think it is a colour channel thing.

I can't speak for Dan, but my impression is that this method is just a quick, easy way to make use of standard, existing channel data from the three common colour modes hardwired into Photoshop.

In Photoshop, "Gray" can be a rather loose term, meaning one thing in one place and something else in another. But I digress. Ah, channels...what wonderful things they are!

I would hazard a guess that Dan wouuld call this the 13 channel technique if Photoshop still had HSB as a mode choice (one can get HSB via a plug). Then there are other spaces, why stop at 13?

It is significantly different from the L lab channel (and of course

all the other channels).

Yes, a simple desaturation of the RGB colour data does result in different channel structure, as does channel mixer or apply image or calculations etc. You are *almost* onto something important here, that I have been thinking of making a post about for some time.

Is there nothing useful in this channel to correct images?

There is something useful in all channels, no matter how the channel is made...it is just up to the end user to discover how to make use of the channel! Easier said than done. Please let the list know of good uses for a simple desaturation of RGB. Tip, perhaps look into Channel blends...

Further, it is *far* more than "useful" if the desaturation is done correctly, so that the desaturated results *perfectly* match a Photoshop blending mode when layered over the full colour image in that blending mode...some would say it is the only correct way to perform certain edits while in this blend mode!

I originally missed the following post, but Stephen Best introduces the concept to the list in the following thread - based off his own research and originally inspired by "Lobster" from www.freegamma.com where H/S/Luminosity "channel layer" edits are performed:

http: //tech.groups.yahoo.com/group/colortheory/message/16232

If you wish to get up to speed on the issues, then the FreeGamma website has many useful PDF downloads in the manual section, that non Lobster users can learn a lot from. I would like to give credit and a huge thanks to Ian Lobb, developer of this commercial product, as he is pioneer in this area.

I am not associated with Lobster, one can try a free demo for both Mac and PC.

And although one can't easily recreate exactly what Lobster does with Hue/Saturation, it is a simple process to separate the Luminosity data from the image and work with it in Photoshop, with or without Lobster with the same results and workflow as Lobster for Luminosity edits. Luminosity is pretty easy, it is not so easy to replicate what Lobster does with Hue and Saturation, due to the unique way they create the HS data while in RGB (there are many ways to separate the HS, with good and bad points for various methods and results).

Perhaps some list members would like a civil discussion where we all learn some new things about basic Photoshop operations, that may go against the "accepted wisdom"? If so, it will require that people meet each other half way, the topic will not progress unless there is feedback that advances the discussion (otherwise I would simply make a post, rather than make such an invitation which requires work on the part of participating members).

Regards,

Stephen Marsh.

____________________________________________________________________________

Re: "accepted wisdom"

Posted by: Lee Clawson

Sun Dec 30, 2007 2:42 pm (PST)

Stephen,

Half way is fine... I'd also like to suggest that our past has been less than ideal in this respect and we need more effort from the moderators to help support and guide a discussion of ideas that go outside accepted wisdom. Too many who had the experience, ability and willingness to share new ideas are no longer posting (more than 3).

Lee Clawson

2/\V/\7 Studio

____________________________________________________________________________

Re: "accepted wisdom" - Blend If, "Gray"

Posted by: Stephen Marsh

Sun Dec 30, 2007 4:29 pm (PST)

Thank you for the reply Lee - not to mention the suggestion and observations which are noted. Cheers.

So it sounds like there is at least one taker, fantastic Lee!

The proposed discussion will centre around separating and working in Luminosity and Hue/Saturation in Photoshop while in RGB. Similar basic idea as working in Lab without changing modes. Isolating tone from colour (or that is at least the premise). Curves will be the main topic point, although other editing tools are also applicable. The first half of the discussion will be on Luminosity edits.

Before I embark on such a thread, I will use Blend If as a segway to the topic of Luminosity. Blend If is a current "hot topic" at this time (or anytime!), I have been writing about this topic for many years. Recently, John Bongiovanni wrote:

Before starting, you have to know where you want the blending to

happen. The object is to set the sliders so that only that part of the

image is affected (with the transition zone mentioned in an earlier

post).

John then goes on to list the common visual methods used to find the appropriate range for blending, which I and most other folk have always used. This could be with individual channels and or with the "Gray" channel function.

I will use RGB as an example (I usually find CMYK better to explain Blend If).

Blend If uses either the separate channel structure (brightness levels for R, G, B channels) and or a composite "Gray". Some users may have noted that this "Gray" does not appear to be their Grayscale working space or even the Lightness channel values of Lab mode. There is a disconnect between the values found in the info palette readings and what the "Gray" Blend If sliders are doing. There is no info palette reading that is directly applicable to Blend If, if one wishes to measure the "Gray" value. Please test these statements for yourself.

It is probably obvious by now that I am going to say that the Blend If, "Gray" function uses Photoshop RGB Luminosity values, rather than the Grayscale working space or L of Lab, B of HSB etc. This is displayed as a 0-255 range in Blend If, "Gray", rather than 0-100% as one would expect for a Luminosity reading.

If the info palette does not display Luminosity values, then how does one make use of this knowledge? This is another segway to the next thread, but I don't want to get ahead of myself! The answer is curves. The master/composite RGB channel is actually showing RGB Luminosity values when you mouse-over the image or cmd/ctrl click the image to set control points on the master curve.

By using the RGB curve interface as an "info palette", one can find the RGB Luminosity values that directly equate to the Blend If, "Gray" function! In practice, one still uses a combination of both visual and numerical approaches. But with the addition of numerical precision, there is no need to guess or play "slide it and see".

The RGB master curve can also be displayed in % values, although this may not be helpful for the 0-255 numbering system of Blend If, it is worth keeping in mind when it comes to some other operations.

The .com/package.shtml site has all this and further information in PDF form, authored by Ian Lobb (the first that I know of to make these observations public, even though it may be considered point of sale material). Again, I invite readers to test and verify these statements for yourself, rather than relying on what I or others write (or textbooks etc).

I will hold off on starting the thread on Photoshop RGB Luminosity extraction and edits until the Blend If, "Gray" = Photoshop Luminosity topic introduced in this post has been put to bed.

Sincerely,

Stephen Marsh.

____________________________________________________________________________

Re: "accepted wisdom" - Blend If, "Gray"

Posted by: Dan Margulis

Tue Jan 1, 2008 8:34 am (PST)

Stephen writes:

John then goes on to list the common visual methods used to find the

appropriate range for blending, which I and most other folk have

always used. This could be with individual channels and or with the

"Gray" channel function.

I'll add another one, which was necessitated by a change for the worse in Photoshop CS3. For unknown reasons, we are no longer able to view individual channels when adjusting the Blend If sliders; we have to look at the composite color. That makes identifying the transition much harder.

Now, to identify whether the Blend If options are working, I (making sure that there is a copy of the top layer somewhere) add noise. Now I adjust the Blend If options and it becomes obvious where the noise has been eliminated. When satisfied that I've got the sliders right, I apply the previously saved copy of the noisy layer, retaining the sliders settings while killing the noise.

Blend If uses either the separate channel structure (brightness levels

for R, G, B channels) and or a composite "Gray". Some users may have

noted that this "Gray" does not appear to be their Grayscale working

space or even the Lightness channel values of Lab mode. There is a

disconnect between the values found in the info palette readings and

what the "Gray" Blend If sliders are doing.

While the gray sliders are usable for areas of gross difference, if we need so much precision that we're investigating specific numbers, we probably shouldn't be using it at all, but rather one or more channel sliders. For example, if we're trying to blur a sky where the foreground is significantly darker, the gray sliders will probably work but the blue sliders would be more precise. And if we were trying to blur only the blue areas of the sky but not the white clouds, we'd exclude areas that were anything other than light in the blue channel, but also exclude areas that *are* light in the red.

The generic difference between operating in a luminosity mode in RGB/CMYK and in the L channel of LAB is that in one case we're working on three channels individually and then averaging the result to create a new tonal range, while in the other we're doing the averaging first and then the operation.

Either method is better in specific cases. Sharpening is ordinarily more accurate on the averaged data, which is why we occasionally see a superiority in LAB sharpening vs. RGB/Luminosity. Curving works better on the individual, unaveraged channels when the colors are subtle, but when the colors are intense the curve can be more effective if the values are averaged first. When applying a single curve or other adjustment to establish tonality independent of color, the values need to be averaged before the operation is applied.

In the specific case of Blend If, an averaged approach--which is what the gray slider is--is very unlikely to be as effective as an individual-channel one. The idea of Blend If is to find some kind of transition line. That line will be most apparent in one of the three channels, least apparent in another, and somewhere in the middle in the third. The gray slider averages the bad in with the good. Again, it may work, but there are lots of cases where it can't, or is much more difficult than just using the best channel, whatever it is.

Dan Margulis

____________________________________________________________________________

Re: "accepted wisdom" - Blend If, "Gray"

Posted by: Rick Gordon

Tue Jan 1, 2008 6:16 pm (PST)

You can get around this limitation by setting up a second view of the document, showing the channel you want. Bring the composite view to the front, but not obscuring the other view, and make your adjustment, which will also update the view in the single-channel-view document.

Rick Gordon

------------------

On 1/1/08 at 4:12 PM +0000, Dan Margulis wrote

>I'll add another one, which was necessitated by a change for the worse in Photoshop CS3. For unknown reasons, we are no longer able to view individual channels when adjusting the Blend If sliders; we have to look at the composite color. That makes identifying the transition much harder.

___________________________________________________

RICK GORDON

EMERALD VALLEY GRAPHICS AND CONSULTING

___________________________________________________

____________________________________________________________________________

Re: "accepted wisdom" - Blend If, "Gray"

Posted by: John Bongiovanni

Mon Dec 31, 2007 7:23 pm

I read some of the references, and what you've written makes sense (sounds like a mis-feature of PhotoShop). I did have to take anti-allergy pills to keep reading a document where emphasis is supplied (frequently) with sentences entirely in capitals, but that's unrelated to your discussion.

In any event, I find that I never attempt Blend-If in RGB (or CMYK, for that matter). I generally find it easier to go into LAB, as what I'm trying to differentiate is usually expressed easily as color and/or lightness variation. All of this gets too jumbled in RGB to be of use.

Of course, Gray doesn't have this problem. But I find that first-order, I'm differentiating on color, and second-order on lightness. The classic example is some effect you want to apply just to a sky, but I've found it useful with faces and in many other situations.

Stephen, my sense from your post is that you use Blend-If in RGB and in CMYK. I'd love to see an example of this.

John Bongiovanni

____________________________________________________________________________

Re: "accepted wisdom" - Blend If, "Gray"

Posted by: Stephen Marsh

Fri Jan 4, 2008 10:05 pm (PST)

John Bongiovanni wrote:

I read some of the references, and what you've written makes sense

(sounds like a mis-feature of PhotoShop).

Great John, thanks for taking an active interest!

To the best of my knowledge, the Photoshop User Guide/Help or other popular texts or commentary on Photoshop do not mention these points (please cite references if I am incorrect in these statements):

1. The Blend If, "Gray" function is based on RGB luminosity levels.

2. The RGB Master/Composite curve interface displays RGB luminosity values for the tonal levels that one mouse-overs in the image.

3. That one can make use of the RGB curve values to predict the response of the Blend If, Gray values.

Points 1 and 2 can not be proved with the information posted so far (that this is luminosity data), but it is shown in the PDF references that I linked to earlier. Point 3 can be easily verified, that there is indeed a direct relation between the numbering system used on the Master/Composite RGB curve and the Blend If, "Gray" layer option feature. Points 1 and 2 will be discussed in a future post, if there is interest shown by the list.

I did have to take anti-allergy pills to keep reading a document

where emphasis is supplied (frequently) with sentences entirely in

capitals, but that's unrelated to your discussion.

The author Ian Lobb is introducing concepts and making statements that are not stated by noted commentators or even in the manual. In some cases the author is contradicting some well respected authors. It would appear that despite his lack of fame and his observations being used to promote a commercial product, that Mr Lobb has some points that are worth taking note of. Some I agree with, others I am not yet sure of. One can do exactly what the commercial Lobster product does when it comes to Luminosity extraction and editing, for no cost, without even downloading the demo. Or, one can download the demo and try the full Lobster workflow, editing Luminosity in one layer and working the separate R, G, B Hue/Saturation content layers separately, taking advantage of the unique Lobster results (different to other similar methods). The demo works on a cropped/resized version of the image (no watermarking), so it may run fast, as opposed to very slow when used on a full sized source file (keep in mind if purchasing).

Stephen, my sense from your post is that you use Blend-If in RGB and

in CMYK. I'd love to see an example of this. \

I was only using Blend If as a bridge to my intended topic on luminosity and hue/saturation 'channel layer' separation/editing in Photoshop. I don't really wish to distract things with Blend If at this time. That being said, it all depends on what one is doing. The more different the channel structure is, the more flexible Blend If (and Channel Mixer) is. For Blend If, Lab is often more flexible than CMYK, while CMYK is more flexible than RGB. Usually the individual channels provide more flexibility than the "Gray" option, but this is not to say that blending via Luminosity is useless. It all depends on the task at hand and the image data.

When using the Luminosity data of Blend If, "Gray" - it is very similar to the Lightness channel of Lab mode (different, but close enough in general behaviour). When using the L in Lab or "Gray" in Grayscale, RGB or CMYK mode it will often be for moves based on tone, rather than one individual channels brightness or tonal levels etc.

Perhaps the most common example of this is when using a sharpening layer, where one may use blend if to do two common things:

1. Exclude sharpening from the extreme endpoints, splitting the sliders to create a softer transition. This is similar to what can be achieved using a "Bell" or End Point (midtone) Layer Mask.

2. Reduce the intensity of one or both USM halos. The more common method is to use two layers, one at Darken mode and one at Lighten mode at say 50% opacity. This adds two full layers of data to the image as the USM is being split into two for more control. Blend If can achieve similar results in lightening the intensity of one or both halos. Not pixel perfect to the two layer blend mode opacity trick, but not so different either. This has the benefit of only using one extra layer and one can preset the Blend If layer before entering USM, thus one can have a live preview of the effect during application.

Just as USM may have the endpoints of the luminosity range protected, adding noise will often require similar treatment where no noise is introduced into deep shadows or extreme highlights. This is quickly and easily accomplished with Blend If, "Gray".

Other common uses for Blend If, "Gray" (Luminosity) in RGB or CMYK include: HiRaLoAm USM, Shadow/Highlight command, shadow noise reduction, separating highlights from midtones from shadows etc.

Moving on to my intended topic, has anybody worked out how to extract the luminosity component of an RGB image?

The idea is to create a monotone image that when placed over the original image in Luminosity blend mode will not change the image in any way. Not any tone will do though. For example, using the grayscale conversion offered by the common ~tilde composite channel method or the Lightness L channel of Lab mode - when layered over the original RGB image in Luminosity mode there is a change to the images tones. This indicates that the gray pixel data being blended does not represent the original RGB luminosity levels of the image (which is why duping the background layer at luminosity mode does not change the image, both are the same luminosity). This luminosity "channel" layer has practical benefits in editing RGB luminosity in Photoshop, it is

not just another "interesting but useless Photoshop fact".

On this proposed Luminosity "Channel Layer" thread I have an independent link that backs up my independent research, with the same independent research carried out by fellow list member Stephen Best, which also confirms the independent research originally commercialised by Ian Lobb in his "Lobster" software. This luminosity extraction is fairly easy with a little bit of experimentation in Photoshop or with enough searching via internet search engines.

Any takers? This will advance the discussion into both practical areas and theoretical areas that go against accepted wisdom.

Sincerely,

Stephen Marsh.

___________________________________________________________________________

Re: "accepted wisdom" - Blend If, "Gray"

Posted by: "Bob"

Sat Jan 5, 2008 7:33 pm (PST)

Stephen Marsh wrote:

This luminosity extraction is

fairly easy with a little bit of experimentation in Photoshop or with

enough searching via internet search engines.

Any takers? This will advance the discussion into both practical areas

and theoretical areas that go against accepted wisdom.

Yes, and I may even be able to contribute, as I think this is relevant:

This is what I am using, which I believe qualifies as a channels (plural!) based luminosity layer:

I put the B&W Adjustment Layer in luminosity mode, and adjust the luminosity level of the individual colors (ranges of) with the sliders. Try it!

Blend If on the B&W adjustment layer offers a refinement opportunity to moderate the effect in the highlight and shadow areas.

It's fast, can be done visually and it is very easy to do.

Although, limited in the intensity of the effect, that can be overcome by duplicating the B&W adjustment layer.

Since I have not seen/read this technique reported anywhere, at this point I consider this as my unique contribution. Please correct me if I am wrong.

Bob Kenedi

___________________________________________________________________________

Re: "accepted wisdom" - Blend If, "Gray"

Posted by: Stephen Marsh

Sun Jan 6, 2008 7:44 am (PST)

Bob Kenedi wrote:

Since I have not seen/read this technique reported anywhere, at this

point I consider this as my unique contribution. Please correct me if

I am wrong.

Thanks for taking an interest Bob. Yes, this is one method of visually adjusting a colour images tonal values.

I discovered this for myself during the CS3 public beta, at the time I too had not seen it mentioned before. It has come up once again since then:

http: //tech.groups.yahoo.com/group/colortheory/message/16406

http: //tech.groups.yahoo.com/group/colortheory/message/18349

Back to the extraction/separation/harvesting of the luminosity component of a colour image. The goal is to create a monotone version of a full colour RGB image, that when blended in Luminosity mode over the original RGB image does not affect the underlying RGB pixel data in any way (until the monotone layer is edited). Extracting the luminosity component of the RGB image is the goal. The black and white command may be able to do this (obviously not in luminosity blend mode), I have not tried it for this task, but there are easier ways...I hinted at the answer in the following post that sparked this side topic:

http: //tech.groups.yahoo.com/group/colortheory/message/19027

Many would have discovered the method when creating a monotone version of a colour image, but as it did not create the "ideal" gray version the technique may have been dismissed and or not tried as a luminosity blend layer over the original colour image (or if it was, the significance of the move may not have been appreciated).

Sincerely,

Stephen Marsh.

___________________________________________________________________________

Re: "accepted wisdom" - Blend If, "Gray"

Posted by: Dan Margulis

Sun Jan 6, 2008 7:44 am (PST)

Bob Kenedi writes,

Since I have not seen/read this technique reported anywhere, at this

point I consider this as my unique contribution. Please correct me if

I am wrong.

The group had a lengthy thread on this topic, entitled "CS3's new B&W tool used for Contrast in color images"

The thread began on 7 August with

http: //tech.groups.yahoo.com/group/colortheory/message/18349

Dan Margulis

___________________________________________________________________________

Re: "accepted wisdom" - Blend If, "Gray"

Posted by: Dan Margulis

Sun Jan 6, 2008 9:50 am (PST)

Stephen writes,

Back to the extraction/separation/harvesting of the luminosity

component of a colour image. The goal is to create a monotone version

of a full colour RGB image, that when blended in Luminosity mode over

the original RGB image does not affect the underlying RGB pixel data

in any way (until the monotone layer is edited). Extracting the

luminosity component of the RGB image is the goal. The black and white

command may be able to do this (obviously not in luminosity blend

mode), I have not tried it for this task, but there are easier ways...

Since so many of us appear to work in this way, let me offer a tip that I've recently incorporated into the workflow and will be showing in video, although it has application to everybody whether they use my workflow or no.

As discussed in Canyon Conundrum, color combinations are computed differently in LAB than in RGB/CMYK--and often for the better. For this reason, I have recommended that much hand retouching be done in LAB when colors are being combined or blended.

This effect carries over to the type of work I'm showing and that Stephen mentions. If we have a two-layer RGB file where the top layer is set to Luminosity, flatten it, and send it to LAB, the result is visually identical. However, if we send it *unflattened*, then the two individual layers will be visually identical, but the overall result may not be, owing to the different computation method.

Furthermore, when there's a visible difference, the LAB version is usually better--sometimes significantly so. I haven't checked enough images to offer a firm estimate as to how often this happens--I'm going to make a note of what happens when I'm taping, because a large number of images have luminosity layers and then move into LAB.

My guess, however, is that when there's a Luminosity layer of any consequence and we convert to LAB unflattened, around half the time we won't notice any difference. The other half of the time, I'd say that the odds are around 4-1 that we prefer the LAB version, but there are some cases where we prefer the RGB version.

Consequently, I have a counterintuitive recommendation for anyone who uses Luminosity layers, even when there is no apparent need to go to LAB at all. Try converting the file to LAB unflattened (doesn't work with adjustment layers, sorry). If the result isn't significantly better, then just Command-Z and you've wasted a few seconds. But if it *is* better, then flatten the image in LAB

and return to RGB.

I adopted this approach just in time to save myself from a mistake in the opening of the third of my workflow videos, which deals with color enhancement and assumes that we start with a Luminosity-layered RGB document. The first example is already rather colorful and I planned to say that just because we have the hammer of LAB at the ready it doesn't mean that every file is a nail, that one of the tests of a good practitioner is knowing when *not* to mess around with LAB, and that this would be exactly such an example.

But I was wrong. The correct approach on this image is to convert to LAB unflattened, flatten it there, and return to RGB without further messing around.

Dan Margulis

___________________________________________________________________________ .

Re: "accepted wisdom" - Blend If, "Gray"

Posted by: "Alex Kent"

Tue Jan 8, 2008 5:09 am (PST)

i propose a method for doing this:

1. New Blank Layer over your colour image

2. Edit > Fill > 50% Gray

3. Change Blank Layer's blend mode to Colour

the greyscale image you can now see the RGB Luminance.

so if you merge the grey layer with your colour image, when you place this resultant layer with blend mode Luminosity over the original colour image, pixel values will not change.

alex kent.

___________________________________________________________________________

Re: "accepted wisdom" - Blend If, "Gray"

Posted by: Howard Smith

Tue Jan 8, 2008 5:44 am (PST)

Good one, Alex! Much better contrast retention than one would get by simply desaturating the color image. Even if someone finds fault with your proposal, it offers considerable potential for use in a great many applications. For a start, it can be made into a permanent image layer by creating a blank layer and using Shift-Alt-Ctrl-E to flatten a copy and place it into its own layer. The original 50% grayscale layer can then be dispensed with, leaving you with a good contrast, grayscale layer for blending or other editing.

Howard Smith

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Marsh

Tue Jan 8, 2008 5:45 am (PST)

Excellent Alex, fantastic reply. this is one way. One can also use white, black or any gray tone. The key is of course color or hue or saturation blend mode, so as not to affect the luminosity. One could also use a solid fill adjustment layer instead of pixel data (uses less memory).

Here is the link that I mentioned before also backs this up:

http: //web.mac.com/gapodaca/Photoshopmechanics/Podcast/Entries/2006/8/29_001_Grayscale_And_Luminosity_30-59-11.html

There are other methods, such as Desaturate/fade to color or the Hue/Saturation command. The Hue/Saturation command, as noted in past threads affects the luminosity of the image in normal blend mode, despite user expectations of only the saturation being affected if this is the only control used (the last thread on this was about adding a saturation boost to yellow flowers).

I have discovered during my research that the Hue/Saturation command is lossy, of all the Image/Adjustments sub functions, it is the only command that results in data loss to the file when the OK button is applied when zero adjustment settigs are entered (obviously the cancel button is there for a reason!). Luminosity data is not affected though, which means that this command can be used for the luminosity extraction (I prefer to fill with gray in color mode).

So, now we have the ability to layer a Luminosity "Channel" Layer in luminosity blend mode over the original RGB image and have pixel perfect results, no change to the image!

Instead of simply setting a curve adjustment layer (or levels, etc) to luminosity blend mode, one can clip/group a luminosity blend adjustment layer to the Luminosity "Channel" layer.

What practical use is this, you may ask. If the Luminosity "Channel" Layer, when blended in luminosity mode results in no difference, a pixel perfect match to the original image - why not simply use a standard luminosity blend adjustment layer without the extra Luminosity "Channel" Layer? How do results differ, when theory would seem to indicate that results would be pixel perfect? What ben efits does this bring to editing over regular methods?

This is where the fun starts and departures from "accepted wisdom" occur!

Sincerely,

Stephen Marsh.

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Marsh

Tue Jan 8, 2008 5:55 am (PST)

Howard Smith wrote:

Much better contrast retention than one would get by simply

desaturating the color image.

Yes, this is Luminosity data! A very critical part of the human visual experience (not to mention lossy compression and other things).

Even if someone finds fault with your

proposal, it offers considerable potential for use in a great many

applications.

There is nothing to fault, although steps can be refined.

Interested parties are again invited to download the PDF files from the www.freegamma.com website, to get up to speed on the supposed advantages of editing RGB luminosity via a Luminosity "Channel" layer.

Regards,

Stephen Marsh.

___________________________________________________________________________

Re: "accepted wisdom" - Blend If, "Gray"

Posted by: Dan Margulis

Tue Jan 15, 2008 4:51 am (PST)

Prior to taping my latest sessions, I wrote,

Since so many of us appear to work in this way, let me offer a tip that I've

recently incorporated into the workflow and will be showing in video,

although it has application to everybody whether they use my workflow or no.

As discussed in Canyon Conundrum, color combinations are computed

differently in LAB than in RGB/CMYK--and often for the better. For this

reason, I have recommended that much hand retouching be done in LAB when

colors are being combined or blended.

This effect carries over to the type of work I'm showing and that Stephen

mentions. If we have a two-layer RGB file where the top layer is set to

Luminosity, flatten it, and send it to LAB, the result is visually identical.

However, if we send it *unflattened*, then the two individual layers will be

visually identical, but the overall result may not be, owing to the different

computation method.

Furthermore, when there's a visible difference, the LAB version is usually

better--sometimes significantly so. I haven't checked enough images to offer

a firm estimate as to how often this happens--I'm going to make a note of what

happens when I'm taping, because a large number of images have

luminosity layers and then move into LAB.

My guess, however, is that when there's a Luminosity layer of any

consequence and we convert to LAB unflattened, around half the time we

won't notice any difference. The other half of the time, I'd say that the odds

are around 4-1 that we prefer the LAB version, but there are some cases where

we prefer the RGB version.

Consequently, I have a counterintuitive recommendation for anyone who

uses Luminosity layers, even when there is no apparent need to go to LAB

at all. Try converting the file to LAB unflattened (doesn't work with adjustment

layers, sorry). If the result isn't significantly better, then just Command-Z and

you've wasted a few seconds. But if it *is* better, then flatten the image in

LAB and return to RGB.

As discussed, I kept a scorecard during the sessions, which suggested that the above estimate is accurate. I had 25 RGB images with a luminosity layer. When they were headed for LAB I showed the alternatives in the video so that viewers could judge for themselves; when not headed for LAB I converted them offline and added them to my scorecard.

Certain variations are image-specific; skies that are flattened in LAB tend to have more contrast, while in RGB, they look darker. The LAB treatment is more likely to be correct but on some images it's not desirable.

My score was that on 11 occasions, flattening the file in LAB gave results that were better enough that it would make sense to convert the layered file to LAB and flatten, even if there was no other reason to go to LAB. On four other occasions, flattening in RGB seemed clearly better. The other ten times, although differences were visible, I had no preference.

These findings suggest not only that one should experiment with flattening luminosity-layered files in LAB even when the objective is to stay in RGB. They also suggest that when correcting in LAB, if quality is at a premium maybe we should make any changes to the L channel on a separate layer set to Luminosity, just in case it's one of the images in which flattening in RGB gives better results.

These files all involved channel-blending and/or curves to improve the

luminosity of the top layer, usually both. So there were substantial differences

between the top and bottom layer. When the top layer is sharpening only, the

differences between the two are small enough that it would be rare for either

LAB or RGB flattening to be much superior.

Dan Margulis

___________________________________________________________________________

Re: "accepted wisdom" - Blend If, "Gray"

Posted by: Stephen Marsh

Wed Jan 16, 2008 4:56 am (PST)

Dan Margulis wrote:

These files all involved channel-blending and/or curves to improve the

luminosity of the top layer, usually both. So there were substantial

differences between the top and bottom layer. When the top layer is

sharpening only, the differences between the two are small enough that

it would be rare for either LAB or RGB flattening to be much superior.

Thanks for the update Dan. This behaviour obviously affects other blend modes too. This is interesting, as in this case the "accepted wisdom" is to *generally* flatten before/during conversion, so as to preserve the previous appearance. In this case the 'new' appearance may be better, or not, depending on the image, edit and goal etc.

Another great example that I think I first heard of from Ben Willmore, was in some cases, not to flatten a monochrome channel mixer when moving from RGB to CMYK (if one is after K only with no CMY).

Sincerely,

Stephen Marsh.

___________________________________________________________________________ .

Re: "accepted wisdom" - Blend If, "Gray"

Posted by: "controltheweb"

Wed Jan 30, 2008 6:24 pm (PST)

Apologies, perhaps I need to read further, but the freegamma PDF document referencing luminosity in Photoshop seems to make a fundamental error. To wit:

"Each ... so-called source of luminosity will change the appearance of your file when placed at Luminosity mode."

... except one: Copy the image to a new layer, merge it with a black layer above it set to color. Set resulting layer to Luminosity = working method. (Use as clipping mask for curves layer, etc.)

The manual doesn't mention this method. Try it. All color sampler test points on an image will remain unchanged as opacity of luminosity blend layer is adjusted.

Is there something I've overlooked? Would love to be enlightened, if so! I use this type of luminosity layer in the methods suggested aby the freegamma/lobster information, as well as use it as the basis for a saturation mask (layer set to difference instead of luminosity).

Dave Larson

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Marsh

Thu Jan 31, 2008 1:39 am (PST)

Dave Larson wrote:

Apologies, perhaps I need to read further, but the freegamma PDF

document referencing luminosity in Photoshop seems to make a

fundamental error. To wit:

"Each ... so-called source of luminosity will change the appearance of

your file when placed at Luminosity mode."

Ian Lobb is commenting on the fact that the term luminosity is often used incorrectly or generally, when Photoshop has a rather specific definition of what Luminosity really is.

Some say that the L channel of Lab mode contains the luminosity channel data of an image (when this is lightness data, different to RGB luminosity values). Some also say that one can create luminosity by ctrl/cmd clicking on the composite/master channel icon to load the luminosity values (this is really work space grayscale data).

Ian Lobb is fighting against a lot of momentum, famous industry names and is taking great care to educate users in these often misunderstood issues...along the way I would imagine that he would also like to sell his software.

... except one: Copy the image to a new layer, merge it with a black

layer above it set to color. Set resulting layer to Luminosity =

working method. (Use as clipping mask for curves layer, etc.)

Yes, agreed. Dave, thank you for the belated reply! Back on the 9th of January, Alex Kent answerd my "challenge" with a similar answer:

http: //tech.groups.yahoo.com/group/colortheory/message/19048

Other methods are mentioned in my follow up reply:

http: //tech.groups.yahoo.com/group/colortheory/message/19050

The manual doesn't mention this method. Try it. All color sampler test

points on an image will remain unchanged as opacity of luminosity

blend layer is adjusted.

Agreed, these methods are not mentioned in the manual (manual = Lobster manual or other Lobster point of sale material).

Is there something I've overlooked? Would love to be enlightened,

if so! I use this type of luminosity layer in the methods suggested

aby the freegamma/lobster information, as well as use it as the basis

for a saturation mask (layer set to difference instead of luminosity).

No, you are not missing anything. It is obviously not in their interest to tell you how to extract the Luminosity data yourself, as that is half of what their product does. The Luminosity stuff is not really where Lobster is special...although they have put in a lot of work in their research, above and beyond what one finds in many well known Photoshop texts.

What is special about Lobster is how the Chromaticity info is generated and how it behaves when editing. One can use many methods to extract the chroma, but they are not all equal.

Sincerely,

Stephen Marsh

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Marsh

Thu Jan 31, 2008 2:13 am (PST)

Thanks for the interest John. The basics are all in the PDF material at the previously mentioned website. If you or somebody else is willing to participate in a basic exercise, we can go through it and discuss results and conclusions etc (again, this is all in the PDF's).

http://www.freegamma.com/

There are many uses for being able to losslessly split a file into luminosity and or chroma data. Similar but different to LAB, HSB, LCH etc. Some edits may involve direct editing of the Luminosity "Channel" layer data, such as filtering (USM, surface blur etc). Other edits may be with an adjustment layer clipped/grouped to the Luminosity "Channel" layer.

I don't know how to say this differently, so I will just have to repeat a section from a previous post:

"So, now we have the ability to layer a Luminosity "Channel" Layer in luminosity blend mode over the original RGB image and have pixel perfect results, no change to the image!

Instead of simply setting a curve adjustment layer (or levels, etc) to luminosity blend mode, one can clip/group a luminosity blend adjustment layer to the Luminosity "Channel" layer.

What practical use is this, you may ask. If the Luminosity "Channel" Layer, when blended in luminosity mode results in no difference, a pixel perfect match to the original image - why not simply use a standard luminosity blend adjustment layer without the extra Luminosity "Channel" Layer? How do results differ, when theory would seem to indicate that results would be pixel perfect? What benefits does this bring to editing over regular methods?

This is where the fun starts and departures from "accepted wisdom" occur!"

Sincerely,

Stephen Marsh

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "John R"

Thu Jan 31, 2008 2:37 pm (PST)

"So, now we have the ability to layer a Luminosity "Channel" Layer in

luminosity blend mode over the original RGB image and have pixel

perfect results, no change to the image!

Instead of simply setting a curve adjustment layer (or levels, etc) to

luminosity blend mode, one can clip/group a luminosity blend

adjustment layer to the Luminosity "Channel" layer.

Stephen, I went to the site and did the excercises. I see now WHY there is a definite difference in true luminosity of an image and the previous L channel of LAB, or a grayscale adaptation useage. I saw the color info increase if either are used as a luminosity layer in RGB mode

I'm slow, sorry. Remind me why we need the Luminosity "Channel" Layer not to change the image below? I saw where using the L channel or grayscale average changes color, but you lost me as to why I don't want it too, unless to better sharpen, orbetter adjust Curves without effecting color. Why else? Is it some type of blending function w using true luminosity alone? I did see where he increased texture w true luminosity. What else?

I adjusted the curve of the true luminosity layer. I was very impressed how it improved my image and did not touch the color in RGB. Then I sharpened the true luminosity layer, and was amazed how beautiful my image became with no color change.

This is where the fun starts and departures from "accepted

wisdom" occur!"

Right? Thinking like this is fun, but for extended periods and I will be ready for the rubber room.

John Robinson

Designer

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "John R"

Fri Feb 1, 2008 1:46 pm (PST)

Allow me to revise my last post. I do understand why I want the true Luminosity layer. Sheeez. But besides sharpening and tonal adjustments, I am having a hard time getting my head around the use of the 3 Chromaticity layers. The author is saying to use them to create masks and effects. If anyone explores this I would appreciate your findings with what you can create w them.

John Robinson

Designer

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Marsh

Mon Feb 4, 2008 7:27 am (PST)

John Robinson wrote:

Stephen, I went to the site and did the excercises. I see now

WHY there is a definite difference in true luminosity of an image and

the previous L channel of LAB, or a grayscale adaptation useage. I saw

the color info increase if either are used as a luminosity layer in

RGB mode

Excellent, thanks for the feedback John.

Yes, if the "gray" data does not match the Photoshop recipe for "Luminosity" blend mode, then the underlying tone (and saturation) will be affected (luminosity mode does lock the hue).

This may be wanted and is not in itself a bad thing. Blending the G channel in luminosity mode is one such example where the luminosity change is desired, as one does wish to change the underlying data (adding some G tone to the L in a portrait shot for example).

Having the ability to losslessly extract the luminosity component of a RGB image has many uses, some obvious and some not so obvious.

Allow me to revise my last post. I do understand why I want

the true Luminosity layer. Sheeez.

The current topic of extracting and working with RGB Luminosity data centres around two parts:

1. Splitting a regular RGB channel file into separate RGB Luminosity and Chromaticity components, and manipulating the layers in lieu of the channels palette as one would do in a traditional channel based space such as Lab or HSB etc. This process may or may not be lossless in the Luminosity and or Chromaticity extraction, depending on the methods used. Editing response will also vary depending on the method used to extract the colour info. Lobster commercialise this concept, and split the Chromaticity info into separate R, G, B "Channel" layers for further editing flexibility (what they term points of insertion, where and how to add adjustment layers depending on the goal).

What Lobster does with the colour data is not simple, nor is it easy to reverse engineer the editing response, even if layer structure and general visual appearance is similar in the "roll your own version".

This first point is more advanced and is putting the cart before the horse. Before moving onto the colour component and working an RGB image as a pseudo LCH image, there is still a lot of room for discussion on just the Luminosity aspect, which brings me to the next point[s]. Even if one does not use Lobster or other methods that are similar in theory, the luminosity stuff is freely available to all.

2. * Correctly extracting and blending the Luminosity component of the image in Luminosity blend mode does not alter the original pixels. This can be confirmed with difference blend tests or with various forms of statistical analysis on the image data.

* Layer Options Blend If "Gray", Image/Adjustments/Threshold and the RGB composite/master curve are all based on RGB Luminosity values. Luminosity values do not appear in the info palette. One can view the histogram in luminosity mode.

* A simple test comparing a luminosity blend curve or level results in a different result when clipped to a Luminosity "Channel" layer blended in luminosity mode (more so in saturated reds). Ian Lobb makes the controversial statement that without clipping the luminosity adjustment to a monotone Luminosity "Channel" layer, there will be errors in the math, more so with greater levels of saturation. The way to remove the errors is with a monotone Luminosity layer and clipping the adjustment to that monotone layer. Whether or not one likes the differing result for the image and edit at hand is open for debate, but the issue remains. Refer to the first point, the added data makes no difference to the file...but when a luminosity edit is applied to this data, there is a difference in the edited result when compared to not using the extra monotone layer...why is there a difference when there should be no difference? Do luminosity blend edits contain errors, that are overcome with the blended monotone layer, or are the monotone layer edits in error, not Photoshop?

* CMD/CTRL click in the RGB composite/master curve does not offer precise results compared to say grayscale or Lab mode curves - in regards to control point/lock down point editing and image response (even when blended in luminosity mode). Using the monotone luminosity method overcomes this issue.

* Luminosity and Chromaticity data is good for making masks.

I am having a hard time getting my head

around the use of the 3 Chromaticity layers. The author is

saying to use them to create masks and effects. If anyone

explores this I would appreciate your findings with what you

can create w them.

It is all about altering saturation (or hue) in different ways than with regular Photoshop edits. Where one inserts adjustments affects the final result (clipped to one channel or over all channel layers).

Again, this is moving far ahead in the proposed discussion and it is fairly specific to the Lobster product. Lobster edits result in different results than regular Photoshop methods, which may or may not be appealing to a given image and viewer. It is simply another tool in the toolkit, or perhaps an early part of the imaging workflow directly after capture/acquisition. One may scan or render the base image as required, then perform Lobster or similar edits on the separated RGB LCH data, before flattening to a regular RGB file and continuing on with more regular edits and layers etc. If the Lobster point of sale material does not explain things to your satisfaction, I am sure that the author Ian Lobb would be happy to explain his product in more detail.

Regards,

Stephen Marsh

___________________________________________________________________________ .

Re: "accepted wisdom" - RGB Luminosity

Posted by: Rick Gordon

Mon Feb 4, 2008 4:14 pm (PST)

This luminosity approach appears to match Lab luminosity. But I have not found an equivalent method that accurately maps chromaticity in RGB. Using a 50% gray, 128,128,128, or some percentage variant to account for gamma (e.g. 54% L), overlaid in luminosity mode gives something close, but comparing pixel-by-pixel Lab values from the Info palette to the a and b of a Lab copy gives close, but measurably and visibly different values. What's the formula for getting a match to Lab chromaticity?

I tried converting to different gamma variants of the same RGB profile (Adobe RGB), but that actually seemed to skew values further from Lab.

Rick Gordon

___________________________________________________

RICK GORDON

EMERALD VALLEY GRAPHICS AND CONSULTING

___________________________________________________

WWW: http://www.shelterpub.com

___________________________________________________________________________ .

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Marsh

Mon Feb 4, 2008 7:56 pm (PST)

Russell Cowgill wrote:

Stephen.....

I have a minuscule percentage of experience than most of the other

members of this group but I have an avid interest in all things

regarding digital imaging and color theory. I have read and studied

the information on the freegamma.com web site as well as from a couple

of other similarly inclined sources. I do understand the discussion

on the benefits of the luminosity layer but am much more in the dark

on the full utility of the separate chromaticity layers.

Russell, please refer to my previous recent post that briefly mentions inserting adjustments in between each separate layer or over the entire chroma layer structure. There is only limited room for discussion of Lobster on this list, the author of the software should be contacted for support. The intention of my postings has not been to advertise Lobster as a product.

http: //tech.groups.yahoo.com/group/colortheory/message/19230

Methods which may appear at first glance to be similar to Lobster simply offer different ways of working with LCH data in RGB and in providing different saturation and other results than regular RGB edits. The same goes for Lobster colour edits, results are different and it is simply another option.

If one only thinks in terms of hammers and nails, they may not appreciate the use of screws and screwdrivers!

I would welcome the chance to participate in a discussion on this

topic that purports to go against "accepted wisdom".

There is plenty of room for this in the Luminosity discussion, that one does not need Lobster to create/edit - which is very much on topic for this list. The Lobster author should be the one selling his product and workflow, not me! I would just like to discuss and verify the Lobster findings, which are not stated by anybody else.

I personally am not ready to discuss the colour extraction or editing aspect of "mock" LCH workflows inside RGB data - as we have barely had any discussion on the "simple" Luminosity side of the process.

Best,

Stephen Marsh

___________________________________________________________________________ .

Re: "accepted wisdom" - RGB Luminosity

Posted by: Dan Margulis

Tue Feb 5, 2008 1:43 pm (PST)

Stephen writes,

I guess by the lack of response from the majority of our 3,500

members, that nobody took things any further with the copious

information provided by the www.freegamma.com website? Do you agree

or not with the Lobster marketing points (which any user can take

advantage of without using Lobster)? Working with RGB luminosity is

currently one thing that I am very interested in, even if the ACT list

is not!??

There may be a lack of understanding of what the specific proposal is, but there certainly is no lack of interest in the concept. I began to promote luminosity maneuvers in the mid- 1990s (previously, AFAIK, nobody had ever suggested using Luminosity mode for any purpose) and since that time virtually everyone proficient in color manipulation uses Luminosity mode at certain times in certain types of images.

The question has always been how many such opportunities there are and how often we should use this particular weapon. This is not such an easy one to answer. The flip side of doing an aggressive correction for luminosity is that it implies a separate step for color in a fashion that seems foreign to most of us. This happens because in traditional curve workflows, the very act of opening range also intensifies colors. If the range is established in Luminosity mode, the detail may look great but the colors will seem weak. That much is accepted in the Lobster product--the fact that range is being established without reference to color creates the need for the nontraditional means of establishing color that the product provides.

Throughout this century there have been rumblings that the traditional one-pass correction workflow may not be as good as a once-for-color, once-for-contrast one. I've shown a lot of examples over the years where the second alternative works better, but have also pointed out some issues with it. I came close to advocating it as a *general* workflow in PP5E but thought there were too many shortcomings.

Last year, however, I recanted. The new workflow I showed (and for which the video is forthcoming) is not the one that has been previously bruited about. It's a *twice* for color, once for contrast approach. For present purposes, though, the point is that I now suggest that there should be a luminosity maneuver on almost *all* images where time permits, and understanding that there will have to be a subsequent color move. To that extent, I agree with the principles of the Lobster product.

The difference is in when the luminosity is computed. My suggestion is that one should create an entirely new color image and adjust that for contrast only, ignoring any atrocities that may occur to the color. Then, its luminosity is imposed on the original color. Correct first, merge channels later.

Lobster does the opposite. It computes the luminosity of the image *first* and creates, in effect, a single channel to represent it. Then, we work on that channel with curves or whatnot, and when finished, impose its detail on the original color. Thus, merge first, correct later.

If we were to choose only one of these approaches, well, it depends on the image. If the whole point of the exercise is to improve some brightly colored object, such as a flower, merge first, correct later is the better approach. If the picture is rather dull there isn't much difference between the two. But in all other cases AFAIK, correct first, merge later is better.

That news should not be controversial. Creating a proper luminosity layer is substantially the same as trying to get a high-quality B/W image from a color original. It's clearly understood at this point by those proficient in the field, IMHO, that the best results come from altering the color original and then converting to B/W, rather than from converting to B/W first and attempting to correct that.

The prime reason for not merging/converting first is to preserve the option of channel blends. A high percentage of images, maybe even the majority, either have a red channel that's incontestably superior for contrast as opposed to the blue, or vice-versa. (The green channel is likely to have strong and weak points, as opposed to being unconditionally better or worse.) So, we simply replace the red with the blue, or vice versa. Plus, there's a fourth channel that I commonly use for this type of blend--a Medium-GCR black, generated from a copy of the original, converted to CMYK through a special false profile. That extra black can replace, or be multiplied into, any of the RGB channels.

After any blending, it's also more likely that advantageous curves can be applied to individual channels than to a single luminosity composite, the exception being brightly colored objects as previously stated.

The correct first, merge later approach is not beginner-friendly, because for a while the colors become bizarre. The experienced person can ignore this, knowing that the bizarre colors will be eliminated by Luminosity mode, but the beginner may have difficulty with the concept. With Lobster, such bizarre colors are never seen.

The merge first, correct later approach of Lobster is very friendly to those who are accustomed to correcting with RGB master curves. It's the same single-curve approach, but contrast is much enhanced. If one were so bernighted as to design, say, a raw converter without access to individual channels, then using the merge-first luminosity approach coupled with a supplementary color fix would be infinitely preferable to a master-curve approach.

Since readers of this list are not likely to be making more than nominal use of master curves, the question arises as to how we might make use of the merge-first luminosity channel. The answer is simple: that merged luminosity channel is like the L of LAB. If the image is of the type where working on the L might give better results than in RGB, then it might also make sense to try the move in RGB on one of these pre-merged luminosity layers. There are several ways of creating such RGB layers in Photoshop without the use of Lobster, and there's no reason to fear doing one round of corrections with the correct- first-merge-later approach, followed by a second round of merge-first-correct-later.

Dan Margulis

___________________________________________________________________________ .

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Wai-hong Chung"

Wed Feb 6, 2008 12:15 am (PST)

Grateful if somebody would explain why "merge first, correct later" approach is better for improving brightly colored object like flowers?

Wai-hong Chung

___________________________________________________________________________ .

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Marsh

Wed Feb 6, 2008 12:19 am (PST)

Thanks for the reply Dan, I was making that comment due to the lack of interest shown in the thread. I thought I was being clear, but your post now makes me think otherwise.

I did not wish to make a post, laying out my thoughts on the matter. I wanted others to experiment and learn things through that process (just like I did) and to share and question and have an active discussion.

I thought that by reading the Lobster PDF files and doing the experiments, that others would see the importance of a discussion around these points. It seemed so obvious to me, that I did not think that I had to spell it out, as Lobster has done that beforehand as part of their point of sale/educational material.

There are two proposals. The first is not important for now, which is why my posts have been focused on luminosity and not colour as well. The extraction of the hue and saturation information into a layer or layers in combination with the luminosity layer is deeper. One must learn to walk before one can run. I feel that the second proposal is of more interest and importance.

Proposal 1: Splitting a regular RGB file into separate layers that contain the Luminosity, Hue & Saturation of the image and working in that pseudo "layer colour mode" as opposed to regular composite RGB editing.

Proposal 2: Adding a monotone luminosity layer data at luminosity blend mode does not affect the image in any way, the image does not change. If one then clips a luminosity adjustment layer to this "channel" layer, the final edits are different to simply just using a regular adjustment layer at luminosity blend mode. Something that does not affect the image has a definite affect on the image!

This is where "accepted wisdom" is silent. Accepted wisdom is that simply setting a curve adjustment to luminosity mode is the correct approach. Lobster shows that there are various issues with this traditional viewpoint. The Lobster luminosity channel layer approach overcomes these issues and overcomes some faults in Photoshop. Anybody can benefit from this without using Lobster, it is all built into Photoshop (Lobster 1.0 is a droplet after all).

The educational quality of the information at the Lobster site is very high, even if some don't like the writing or formatting style. The various issues that are raised are not mentioned in the Adobe manual or in mainstream books or internet lists.

My workflow has now changed. Now, whenever I use a luminosity adjustment, it is clipped to the monotone "channel" layer. It is then a simple matter to toggle the clipping on/off after the image is adjusted to see which result is preferred. For some colours, I may prefer the simple "traditional wisdom" approach. For others, notably saturated hues and reds in particular - I usually prefer the version clipped to the monotone luminosity channel layer.

Even though this is a commercial product, an old dog can learn new tricks by exploring these issues. The educational aspect is very interesting to me and I have learned a lot in the last few months from explorations based around these and similar concepts.

Sincerely,

Stephen Marsh

___________________________________________________________________________ .

Re: "accepted wisdom" - RGB Luminosity

Posted by: "John R"

Wed Feb 6, 2008 10:09 am (PST)

Thanks Stephen for the introduction to the droplet and the informative pfd's accompanying it. I open all rgb images now w the droplet to get the (what I refer to as) a true luminosity layer. You are correct that I have never heard a discussion on what slamming (my term) curves onto any rgb image does to hue and saturation before the discussion. One question on your terms above. What is a luminosity adjustment that is clipped to the monotone layer? Is that a curve adjustment layer or a levels adjustment layer in luminosity mode? Why put the adjustment layer in luminosity mode and not normal mode?

I'm not a color genius and sometimes it takes lot's of stupid questions.

John Robinson

___________________________________________________________________________ .

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Andy Adams"

Wed Feb 6, 2008 10:09 am (PST)

I really appreciate Dan's comments on this subject. That is because I needed his view on what I consider a "new" approach to creating a luminosity channel and how it relates to his tried and true methods.

I have been "trying" to keep up with Stephen Marsh's luminosity subject, but although I have gone to the Lobster site and printed out their info, time just doesn't allow me to devote what is needed to digest the info. What I would like is to see a concise "'how-to" that demonstrates all of Stephen's approach. The hit and miss info. that gets posted tends to contribute to my forgetting what the heck I thought I remembered. Granted, Stephen feels this may be too much to throw at us all at once, but for what it is worth that type of approach works best for me.

Andy Adams

___________________________________________________________________________ .

Re: "accepted wisdom" - RGB Luminosity

Posted by: john bongiovanni

Wed Feb 6, 2008 2:58 pm (PST)

I agree and would amplify somewhat. I, too, went through the Lobster website, following the examples (getting over my initial aversion to the presentation style). But in the end, it wasn't clear to me how I could compare this approach with what I've been doing, or with Dan's new workflow, or whatever. Theory says one thing, but what does it mean in practice? Is all of this just a bug in Photoshop that they just might fix next release? Personally, I don't have the background or the time to go down the path that Stephen clearly has, or the background Dan has to cut to the chase (or even to know whether Dan's cut-to-the-chase is correct).

Stephen, I think what you perceive as a lack of interest in the issue is actually a lack of list members with the expertise to engage at the level of your posts on the subject.

I, too, would welcome a specific workflow proposal which I could try on a set of photos, and report back results.

John Bongiovanni

___________________________________________________________________________ .

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Howard Smith"

Wed Feb 6, 2008 2:58 pm (PST)

My own feelings are similar to Andy's. There has been a lot of information posted, none accompanied by visual examples of the advantages of the new approach. Why does this remind me of the endless technical discussions about the superiority of 16-bit over 8-bit? When searching for actual images that proved the superiority of 16-bit over 8-bit, if any, all that came up was more discussion combined with expressions of amazement that so many people couldn't accept the logic. What good is logic? I work with images.

As well as I can recall (or understand) the only comment regarding a specific example of the advantages of the new method was a mention that it is superior for working with super-saturated images. Dan long ago described a technique for handling such images in LAB. Maybe someone can provide other verbal examples, but before-and-after image posts would sure be nice.

Stephen Marsh has been an excellent source of information for new approaches to using Photoshop, so I have no doubt he's onto something big here. It's just that before spending hours learning how to work with a new program, it would be nice to see why we should spend that time. Is it primarily useful for working with Smart Ojbects (not available in CS)? At this point it sounds too much like just another way to achieve bloated files. Many a time, information posted by Stephen on other subjects has led to significant progress in developing new techniques. This time, unfortunately, none of it strikes a chord for me. Am I all alone in the world with this?

I can imagine what kind of response this post will get, and that's OK. We can learn more from criticism than from tips. But could someone please post some representative before-and-after images along with the heated comments? Nothing proves a point like reproducible results.

Howard Smith

___________________________________________________________________________ .

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Best

Thu Feb 7, 2008 1:48 am (PST)

"Howard Smith" wrote:

There has been a lot of information posted, none accompanied by visual examples

of the advantages of the new approach.

My example (from over a year ago):

http: //tech.groups.yahoo.com/group/colortheory/message/16260

Note that I've since dispensed with Hue/Saturation for my own use. Not to steal Stephen Marsh's thunder but if anybody wants a copy of my latest script and instructions on how *I* apply it, I'm happy to post it here. My only interest is in the discussion arising. There's been quite a few emails with Stephen back & forth and his enthusiasm in this approach mirrors mine.

The basic technique, as expounded at length by Les Walkling on courses here (Les is a colleague of Lobster's author, Ian Lobb) is to treat the image firstly as a B&W one. Once you get the tonality right (that is the image would stand on its own as B&W) you've created a structural skeleton and can then proceed to layer colour on top of it. I've found this approach useful for my own work. Having a separate luminosity layer for sharpening etc is a bonus. The issue then is how you handle colour which is where it gets interesting. I'm sure Stephen will have more to say on this as he has progressed this further. As has Ian Lobb in his product. Dan's comments I've also taken in but would like to see specific examples :-).

Note that all this is totally different to simple luminosity blends which suffer from the same deficiencies outlined in Professional Photoshop. The problem with composite curve moves in Photoshop is structural and Adobe doesn't seem to be motivated to fix it. Hopefully the more people that become aware of its shortcomings, the sooner we'll see pure luminosity edits in a future version of Photoshop.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Marsh

Thu Feb 7, 2008 1:48 am (PST)

John Robinson wrote:

Thanks Stephen for the introduction to the droplet and the

informative pfd's accompanying it. I open all rgb images now

w the droplet to get the (what I refer to as) a true luminosity

layer.

The demo is restricted to 600 pixels wide and will resample the dupe of the original image to this size if I remember correctly.

As has been mentioned many times, one can extract the luminosity component without using the demo or full version of Lobster. Or one can purchase Lobster also for the chromaticity editing using Lobster's unique formula (which may appear similar to other methods that contain the hue/saturation data and will likely behave differently under the same edits).

You are correct that I have never heard a discussion on

what slamming (my term) curves onto any rgb image does to

hue and saturation before the discussion.

It comes up in discussion from time to time at various websites, but it is not a common area of discussion for most people.

One question on

your terms above. What is a luminosity adjustment that is

clipped to the monotone layer? Is that a curve adjustment

layer or a levels adjustment layer in luminosity mode?

Those two edits would probably be the most common examples. Others exist, either in adjustment layer or pixel form.

Why put the adjustment layer in luminosity mode and

not normal mode?

Have you played with this yourself? What are your observations?

At this stage of the discussion - simply for testing and analysis. The less variables, the better. However, in my recent post I mentioned that I now always test a clipped and unclipped version - so thus the curve is set to luminosity mode anyway.

In this case, the only difference is [i] a "superfluous" (by conventional wisdom) monotone layer blended in luminosity mode over the base image and [ii] the adjustment layer is clipped/grouped to the monotone luminosity blended layer.

The L layer makes no difference to the image by it's presence...but if the standard workflow luminosity blend curve is clipped/grouped to the monotone L layer, then there is a difference! This is the aspect that I find really interesting.

Let me go over the essentials again:

A. It has been shown that it is possible to extract and blend a monotone layer in luminosity mode and that this does not have any affect on the image until edits are performed on the monotone layer (flatten, perform difference blend tests against the original or use statistical analysis if you wish to test this claim, I did).

B. The "conventional wisdom" is to simply set an RGB curve adjustment layer to luminosity mode so as not to affect the "colour". Upon deeper exploration, one finds that hue is locked but saturation can be affected, so it is not a true separation of tone from colour, but better than no separation at all when this approach is desired.

C. The Lobster claim is that luminosity blend mode by itself is not accurate and that a monotone layer set to luminosity blend mode should be inserted and the luminosity adjustment layer is then clipped to this monotone L layer. The errors are usually found in more saturated hues. For those that do use the composite/master RGB curve (which Dan does not generally endorse), the addition of the monotone luminosity layer makes control point placement and subsequent editing behave correctly, which it does not do by default, even when set to luminosity mode. Again, the Lobster PDF files are the best place to get the info straight from the original source.

As this is such a common and critical blend mode, I feel that it is important to have a better understanding of what is taking place (I know that I don't have all the answers).

Sincerely,

Stephen Marsh

___________________________________________________________________________ .

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Paul Marriner"

Fri Feb 8, 2008 9:39 am (PST)

Stephen, I'd be interested in a copy of your script. Thank you.

Paul Marriner

___________________________________________________________________________ .

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Dan Dill"

Fri Feb 8, 2008 9:40 am (PST)

I am trying to get current with this thread and have now read through the manuals on the Lobster site. The LCH approach seems to make a lot of sense, so much so that I wonder if such an editing mode would find its way into Photoshop in future.

Anyhow, with respect to "the luminosity stuffis freely available to all.", does this refer to the Lobster Luminosity, or Lab Luminosity?

Dan Dill

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "John Arnold"

Fri Feb 8, 2008 9:41 am (PST)

Stephen,

Why does the clipping the curves adjustment layer to the monotone L layer make a difference? Or is that what we are attempting to deduce on our own?

By the way, when you refer to a monotone L layer, I am still a little confused. I always think of L as referring to the lightness channel but it doesn't appear that that's how the term is being used here. Maybe I am trying to make it a bit too complicated?

I have read manual one and am working through the curves experiments in manual two but have not yet finished. Maybe the answer lies ahead but my curiosity is aroused at this point on the significance of why clipping the layer affects the results.

Thanks for suggesting this exercise. I am finding it intruiging and adeducational.

Sincerely,

John Arnold

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "chris broadhurst"

Sat Feb 9, 2008 5:51 am (PST)

Thank you for sharing this Action with us Stephen, but there are two points I do not understand.

a) Why make the Luminosity layer gray? As I assume that Curving in the master rgb channel will have the same effect if the layer was left in colour and persumably would allow the option of individual channel curving when there are distinct colour tonal ranges.

b) What is the real difference/advantage in creating the Luminosity layer instead of just adding a Curve adjustment layer with blend mode set to Luminosity?

Thus I believe we could wind up with 2 Curve adjustment layers to achieve the same facility and also reduce the core usage.

I must add a general comment, about this forum, and that is that I find the posts both illuminating and instructional as I struggle with this fascinating subject - thank you all very much.

Chris Broadhurst

http://www.broadhurst-family.co.uk/lefteye/

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Marsh

Sat Feb 9, 2008 5:51 am (PST)

Dan Dill wrote:

Anyhow, with respect to "the luminosity stuff is freely available to

all.", does this refer to the Lobster Luminosity, or Lab Luminosity?

Dan, as shown in this thread, the Lightness channel of Lab mode,when blended over the original RGB image affects the luminosity levels of the RGB data - so thus the L channel of Lab mode does not represent RGB luminosity levels. The L of Lab represents Lightness, not Luminosity. On a less technical level, one could say that any gray tone has a "luminosity" value, but in the case of Lobster and this thread, Luminosity is a very specific term that should not be confused with the more general term.

What I was referring to was that once one takes the Lobster challenge, it is fairly easy to work out how to create the Luminosity data without using Lobster.

http: //tech.groups.yahoo.com/group/colortheory/message/19048

http: //tech.groups.yahoo.com/group/colortheory/message/19050

What Lobster does with the hue/saturation is different and not easy to

reverse engineer or exactly copy (structure and editing response).

Stephen Marsh

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Eric Vogel"

Sat Feb 9, 2008 5:53 am (PST)

I too would appreciate a copy of your latest script

Thanks Stephen,

Eric Vogel

[INSERTED BY MODERATOR]

The action can be found here - http: //www.macquarieeditions.com.au/misc/MacquarieEditions.atn

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Best

Sat Feb 9, 2008 4:58 pm (PST)

Here's an exercise:

1. Create a new RGB image and fill the left side with a mid gray (128R, 128G, 128B) and the right side with (0R, 169G, 255B). (Just create a rectangular marquee, fill it with the first colour, invert the selection, then fill with the second.) The latter colour is somewhat arbitrary but chosen because it has a corresponding luminosity to help illustrate the following. You can confirm this by running "Add Luminosity Layer" from the action set I provided and doing a readout with just luminosity layer visible. Both sides should read 128.

2. Apply a composite curve as an adjustment layer raising just the mid 128 point to a value of (say) 150. Leave the end points as is. Flatten (or duplicate with flatten), run "Add Luminosity Layer" and do a readout. The values you get should be 150 and 139 for the left/right sides respectively. Namely, the right side is darker than you'd expect.

3. Repeat the above, this time changing the blend mode from "Normal" to "Luminosity". The values you get should be unchanged at 150 and 139.

4. Go back to the original and run the "Add Standard Layers" action and do the same curve move in the Tonality adjustment layer. The readout you get should be 150 and 150. Namely for two colours with the same original luminosity, a common curve move will change luminosity identically.

What's going on here? You have to consider what a composite curve move does, namely it moves each channel in an identical fashion. Look at where the colour we've chosen lies on the respective component curves. The R value is at 0 and won't be affected by our mid tone move, the same for the B at 255. Only the G component will change, but not by the amount we expect! Why didn't it work as expected when we set the blend mode to luminosity? Because it does the same dumb moves then just takes the luminosity of the result and blends it with the layer below. Not what you want. If you want to change the luminosity by a predictable amount, you have to extract the luminosity first. The composite curve only mirrors luminosity for grays. The more you diverge from gray, the less predictable it becomes.

Why has the standard practice of doing tonality moves with the composite curve persisted? You have to look at what most people want to do with their images. They want to add an S-curve to give the image more snap, then bump the saturation globally to juice the colours. If you're getting a saturation boost as a byproduct of the composite curve move it just means you have to apply less of a saturation increase later. All this is probably fine if you just want to knock an image into shape quickly, but if you want to finesse it late in the process you need to isolate luminosity from colour (hue/saturation) so you can tweak one with affecting the other. Of course you could just bypass the composite curve and do all your tonality and colour adjustments with the individual channel components (as espoused by Professional Photoshop) but this requires you to adjust each in tandem.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Best

Sat Feb 9, 2008 4:58 pm (PST)

chris broadhurst wrote:

Thus I believe we could wind up with 2 Curve adjustment layers to

achieve the same facility and also reduce the core usage.

If you're concerned about the duplicate memory footprint, you could replace the copy of the luminosity with a Black & White adjustment layer in luminosity blend mode and clip your tonality curve to this. This won't preserve the original's luminosity (nor does it permit sharpening of just the luminosity component) but it does allow some interesting approaches to editing where you can lighten/darken areas of the image based on hue. This is something I've only just started to explore.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Dan Margulis

Sat Feb 9, 2008 4:58 pm (PST)

Wai-hong Chung writes,

Grateful if somebody would explain why "merge first, correct later" approach

is better for improving brightly colored object like flowers?

Curves are more efficient at emphasizing detail in the midrange than they are in the highlights and shadows. In brightly colored objects, such as red flowers, the detail resides in the highlight of the red/cyan channel but the shadow of the green/magenta channel.

When the channels are merged into a single luminosity channel, as in the Lobster implementation, a red flower is neither light nor dark, it is in the middle, where an S-shaped curve can improve its contrast more easily.

Dan Margulis

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Wai-hong Chung"

Sun Feb 10, 2008 10:24 am (PST)

Yes, I remember you've mentioned this in the PP5E as well as in the LAB book. Its just that there are too many points to note in these books that I forgot this one!

Thank you !

Wai-hong Chung form Hong Kong

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "George Machen"

Sun Feb 10, 2008 10:24 am (PST)

Yes, Dan discusses the issues surrounding under what types of particular image characteristics better benefit from "average first, correct later" vs. "correct first, average afterward" in his Lab book, pp. 286+, among other places.

But beyond that, isn't this consideration confined only to tonality/contrast corrections? Doesn't steepening the individual color channel curves in RGB or CMYK (especially the complementary color) additionally add saturation to the foreground of the significant interest object, and desaturate the receding edges, imparting a more realistic three-dimensional portrayal as would be seen by a human standing in place of the camera? (Simultaneous contrast.)

This latter effect cannot arise solely from an "average first, correct later" correction, no?

- George Machen

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Dan Margulis

Sun Feb 10, 2008 7:11 pm (PST)

Stephen writes,

There are two proposals. The first is not important for now, which is

why my posts have been focused on luminosity and not colour as well.

The extraction of the hue and saturation information into a layer or

layers in combination with the luminosity layer is deeper. One must

learn to walk before one can run. I feel that the second proposal is

of more interest and importance.

Proposal 1: Splitting a regular RGB file into separate layers that

contain the Luminosity, Hue & Saturation of the image and working in

that pseudo "layer colour mode" as opposed to regular composite RGB

editing.

This actually seems like the more important of the two. First, the luminosiity proposal is easily implemented with or without Lobster, while whatever is being done with Hue and Saturation is probably not. Second, RGB does not lack alternate methods of setting luminosity that are approximately as good as using the L channel of LAB, but at present there are significant advantages to computing color using the AB channels rather than RGB. Whether the Lobster method can contribute to minimizing that problem remains to be seen but it is certainly worth talking about.

Proposal 2: Adding a monotone luminosity layer data at luminosity

blend mode does not affect the image in any way, the image does not

change. If one then clips a luminosity adjustment layer to this

"channel" layer, the final edits are different to simply just using a

regular adjustment layer at luminosity blend mode. Something that does

not affect the image has a definite affect on the image!

The effect is that all channels are made to behave alike, so that a single curve can address contrast accurately, as opposed to a master curve that blindly applies the same adjustment to three very different channels.

This is where "accepted wisdom" is silent. Accepted wisdom is that

simply setting a curve adjustment to luminosity mode is the correct

approach. Lobster shows that there are various issues with this

traditional viewpoint.

I think this is where the confusion has arisen, caused by the title of the thread. If I read the above correctly, you are comparing applying a single curve to a single luminosity-based channel to applying a master RGB curve on a luminosity layer. If that's the basis of comparison, applying a master curve in that fashion is *not* generally accepted, and it certainly isn't wisdom--there's no case to be made for that approach at all. In some cases we may not be able to tell the difference, but in all the rest the luminosity curve will be better unless the operator has made an error.

The accepted wisdom on luminosity is that since color is no longer relevant, we are free to apply contrast-enhancing curves to each channel and also to blend channels as we see fit. Because the whole point of operating in luminosity mode is to enhance contrast, applying a master curve, which ordinarily hurts contrast in at least one channel, doesn't make much sense.

The educational quality of the information at the Lobster site is very

high, even if some don't like the writing or formatting style.

This is quite true. I wish the product was available for Macintosh, I would give it a try.

Dan Margulis

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Dan Margulis

Sun Feb 10, 2008 7:11 pm (PST)

John Naman writes,

Pardon my ignorance Dan, why not correct to "bizzare", THEN Lobster the

intermediate result? We are not restricted to Lob.Lum. at the beginning,

or did I miss something?

You missed something, as this is exactly what I advocated. I wrote,

"Since readers of this list are not likely to be making more than nominal use of master curves, the question arises as to how we might make use of the merge-first luminosity channel. The answer is simple: that merged luminosity channel is like the L of LAB. If the image is of the type where working on the L might give better results than in RGB, then it might also make sense to try the move in RGB on one of these pre-merged luminosity layers. There are several ways of creating such RGB layers in Photoshop without the use of Lobster, and there's no reason to fear doing one round of corrections with the correct- first-merge-later approach, followed by a second round of merge-first-correct-later."

Merge-first-correct-later is shorthand for the Lobster approach.

Dan Margulis

___________________________________________________________________________

Lobster

Posted by: "Peter Leyland"

Mon Feb 11, 2008 5:47 am (PST)

This is quite true. I wish the product was available for Macintosh, I would give it a try.

http://www.freegamma.com/

Peter

PDQ Print Services

[INSERTED BY MODERATOR]

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

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "John R"

Mon Feb 11, 2008 5:48 am (PST)

The droplet works fine on my G5 in CS2 at home and work.

John Robinson

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Marsh

Mon Feb 11, 2008 9:16 am (PST)

Howard Smith wrote:

My own feelings are similar to Andy's. There has been a lot of

information posted, none accompanied by visual examples of the

advantages of the new approach. Why does this remind me of the

endless technical discussions about the superiority of 16-bit over

8-bit? When searching for actual images that proved the superiority

of 16-bit over 8-bit, if any, all that came up was more discussion

combined with expressions of amazement that so many people couldn't

accept the logic. What good is logic? I work with images.

Howard, as you probably know, the journey is often more interesting than finally getting to the destination. Sometimes one can't have everything handed to them on a plate. I learned many new things on my quest to separate a regular composite RGB file into separate luminosity and chromaticity layers. I encourage others to do similar, if they are interested in these and similar concepts...who knows what you will discover?

The "secret" method for luminosity extraction that Lobster uses has been noted during the thread. Anybody with Photoshop and the ability to follow the simple minimal text instructions can test all this on their own images. One can even download the Lobster demo, if doing this manually or recording your own action or droplet is too much. Howard, I know that you are capable of doing this yourself from our many years of interaction on this list.

Stephen Marsh has been an excellent source of information for new

approaches to using Photoshop, so I have no doubt he's onto something

big here. It's just that before spending hours learning how to work

with a new program, it would be nice to see why we should spend that

time. Is it primarily useful for working with Smart Ojbects (not

available in CS)? At this point it sounds too much like just another

way to achieve bloated files. Many a time, information posted by

Stephen on other subjects has led to significant progress in

developing new techniques. This time, unfortunately, none of it

strikes a chord for me. Am I all alone in the world with this?

I can imagine what kind of response this post will get, and that's OK.

We can learn more from criticism than from tips. But could someone

please post some representative before-and-after images along with the

heated comments? Nothing proves a point like reproducible results.

Howard, this is just a random image, not chosen to prove any point or method as being superior overall or in one or more tonal areas.

http: //members.ozemail.com.au/~binaryfx/act-luminosity-curves.html

I strongly recommend that one explores the various methods on their own images, whether or not they are pastel, "normal" or saturated.

What Lobster note as errors mostly appear in colours of moderate to strong saturation, independent of luminosity and in various hues, some general hue group ranges more so than others, at various saturation levels.

This is covered in the short PDF at the Lobster website titled:

LEVELS AT LUMINOSITY MODE IN REGULAR RGB FILES:

http: //www.freegamma.com/manuals/LevelsAtLuminosity.pdf

A side issue of RGB Luminosity extraction is that it is 100% lossless when performed correctly (channel mixer is not lossless, there are errors, which is why it has not been mentioned, even though it can come very close to mixing the required L values). Some avoid Lab mode as it is not a lossless process, some folk care about the data integrity just as much or more so as they do for the final edited image (as noted in past Lab and 16 bit threads by some members).

Sincerely,

Stephen Marsh

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Howard Smith

Mon Feb 11, 2008 9:16 am (PST)

Stephen [Best], I really appreciate your taking the time to offer both a thorough explanation and an Action to illustrate it. At last the whole thing is becoming clear. By using a Curves Adjustment Layer for the Luminosity layer, and a separate Curves Adjustment Layer for the background layer, it is a simple matter to edit the saturation of individual colors separately from edits of their hue. By using only the Luminosity layer, the original layer, and two adjustment layers a whole new world of exploration opens up. Your Dodge/Burn layer is an innovative step that offers still greater utility. Funny thing is that this all looks so easy once it's understandable, and so complicated without that understanding.

Great post and an extremely useful action! Thanks again for clarifying this.

Howard Smith

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Howard Smith

Mon Feb 11, 2008 6:53 pm (PST)

Thank you for the additional information, Stephen [Marsh]. My problem is that I'm always in a hurry and so tend to skim over things looking for pertinent facts that can be put to use right away. In the case of Lobster's PDF and the many posts concerning this new technique, I came away with the idea that this involves the addition of numerous layers including some unique kind of separate chromaticity-only layers for R, G, and B. After reading Stephen Best's post and looking at his action, I realized that this is not nearly as cumbersome as I had taken it to be. Now that the procedure is so much more clear, experimentation will no doubt turn up a great variety of new uses for this approach. Now that I look back at the image originally posted by Stephen Best (complete with layers), I see that I should have taken more time to try to figure out what he was doing.

But, again, once one understands something like this, it all becomes simple. It's the preconceived ideas that act as a block to understanding.

Thanks again for your help, Stephen. You have always been a valuable source of new ideas and understandable explanations of those that are not readily understandable.

Sincerely,

Howard Smith

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Marsh

Mon Feb 11, 2008 6:53 pm (PST)

Dan Margulis wrote:

Stephen writes

There are two proposals. The first is not important for now, which

is why my posts have been focused on luminosity and not colour as

well. The extraction of the hue and saturation information into a

layer or layers in combination with the luminosity layer is deeper.

One must learn to walk before one can run. I feel that the second

proposal is of more interest and importance.

Proposal 1: Splitting a regular RGB file into separate layers that

contain the Luminosity, Hue & Saturation of the image and working in

that pseudo "layer colour mode" as opposed to regular composite RGB

editing.

This actually seems like the more important of the two. First, the

luminosiity proposal is easily implemented with or without Lobster,

while whatever is being done with Hue and Saturation is probably not.

Second, RGB does not lack alternate methods of setting luminosity that

are approximately as good as using the L channel of Lab, but at

present there are significant advantages to computing color using the

AB channels rather than RGB. Whether the Lobster method can contribute

to minimizing that problem remains to be seen but it is certainly

worth talking about.

Thanks Dan. On your opening sentence, both points are open for debate and not worth arguing either way at this time, as it would only detract from the Luminosity thread IMHO. I may introduce the second half of my thread, on Chromaticity, if the first half on the simpler Luminosity extraction and non-conventional Luminosity editing proceeds well.

The first point that you raise - agreed, this is indeed so. One can reverse engineer the Lobster Luminosity "Channel" layer without the need for having the demo or full version of Lobster, as has been noted numerous times in the thread with the appropriate steps. I like a challenge and Lobster challenged me with their challenge and I was happy to succeed. Beforehand, the same was true for Stephen Best when he "discovered" RGB luminosity extraction after purchasing Lobster and finding it too slow (in colour generation) for his large source files. The chromaticity data in Lobster is not easy to reverse engineer, other methods may look close - but deeper exploration of channel structure and editing response shows that they are different to Lobster (whether better or worse is a different separate debate for another time, as far as I am concerned).

Secondly, although RGB, hue/saturation data based, the Chromaticity saturation editing results are more like Lab than regular composite RGB saturation blend adjustments in the final results (smoother), if not in the channel structure (composite chromaticity normalised to 50% gray can look a little similar to the ab of Lab mode at first glance, but it is still RGB channel based, not Lab or LCH etc).

Proposal 2: Adding a monotone luminosity layer data at luminosity

blend mode does not affect the image in any way, the image does not

change. If one then clips a luminosity adjustment layer to this

"channel" layer, the final edits are different to simply just using a

regular adjustment layer at luminosity blend mode. Something that does

not affect the image has a definite affect on the image!

The effect is that all channels are made to behave alike, so that a

single curve can address contrast accurately, as opposed to a master

curve that blindly applies the same adjustment to three very different

channels.

My point is that before reading the Lobster notes, I was not aware that Luminosity blend mode is "lacking" and that it can be "fixed" by the use of a grayscale layer, blended in luminosity mode - that equates to RGB luminosity levels and does not affect the base image and does affect the edit results. It is generally put forth that simply using luminosity blend mode is all that is required.

This is where "accepted wisdom" is silent. Accepted wisdom is that

simply setting a curve adjustment to luminosity mode is the correct

approach. Lobster shows that there are various issues with this

traditional viewpoint.

I think this is where the confusion has arisen, caused by the

title of the thread. If I read the above correctly, you are comparing

applying a single curve to a single luminosity-based channel to

applying a master RGB curve on a luminosity layer. If that's the basis

of comparison, applying a master curve in that fashion is *not*

generally accepted, and it certainly isn't wisdom--there's no case to

be made for that approach at all. In some cases we may not be

able to tell the difference, but in all the rest the luminosity curve

will be better unless the operator has made an error.

My use of the term "accepted wisdom", be it the for the Photoshop user guide or major published authors or other commentators on Photoshop, none of these sources say to add in a Luminosity "Channel" layer above the colour data and to then clip edits or directly edit the L layer as in the case of filters such as USM or surface blur etc. I have only seen this recommended by Lobster. All the "conventional wisdom" has to say is to simply set the layer data to Luminosity mode with no addition of a monotone Luminosity "Channel" layer.

Whether this is an adjustment curve layer using the composite/master curve or single individual channel curves at luminosity blend or USM or other filtering is beside the base point/claim made by Lobster (I am not dismissing separate individual luminosity curves vs. a master/composite luminosity curve, that is a *further* variable for study). I have not been able to cite any reference that supports the Lobster reasoning. Testing does show that they are onto something though.

The accepted wisdom on luminosity is that since color is no longer

relevant, we are free to apply contrast-enhancing curves to each

channel and also to blend channels as we see fit. Because the whole

point of operating in luminosity mode is to enhance contrast,

applying a master curve, which ordinarily hurts contrast in at least

one channel, doesn't make much sense.

This is "your' accepted wisdom Dan, not what I would call "mainstream". I don't know of anybody else who has made individual channel editing as famous as you.

The mainstream approach loves the speed and simplicity of a single curve over perhaps milking slightly more contrast or detail out of an image by going to the "extreme" of three or more separate curves. This preference was amply demonstrated in the long debate on ACR tone "range opening" moves.

When I beta tested and contributed feature requests on Mike Russell's "Curvemeister 1.0" PC only plug-in, one of my feature requests/contributions was for the preference option to remove the master curve and only display the individual channel curves, so I obviously do appreciate individual channel moves over composite ones thanks to your tireless advocacy against mediocrity.

The educational quality of the information at the Lobster site is

very high, even if some don't like the writing or formatting style. < <

This is quite true. I wish the product was available for Macintosh,

I would give it a try. <

From the Lobster Website front page:

http://www.freegamma.com/lobsterdemo.dmg (Mac)

http://www.freegamma.com/LobsterDemoInstaller.zip (Win)

As this is not the first time that lack Mac support has been mentioned, I can supply layered PSD files converted using the Lobster demo on the PC, if for whatever reasons the Mac download does not work for you or that you don't have access to a Win OS version of Photoshop.

Regards,

Stephen Marsh.

___________________________________________________________________________ .

Re: "accepted wisdom" - RGB Luminosity

Posted by: "George Machen" i

Tue Feb 12, 2008 6:00 pm (PST)

"Howard Smith" wrote:

... At last the whole thing is becoming clear.

By using a Curves Adjustment Layer for the

Luminosity layer, and a separate Curves

Adjustment Layer for the background layer, it is

a simple matter to edit the saturation of

individual colors separately from edits of their hue. ...

Eureka! I think the significance of the Lobster-type technique has gotten through my thick skull now. While my earlier comments below I think remain technically true - that an "average first, correct later" correction cannot *in the same steps* as luminosity-contrast enhancements add saturation-contrast enhancements for even more realistic depiction of scenes as a human would see them - the Lobster-type technique does allow luminosity & saturation to be adjusted separately on different layers. Which could add flexibility and ease-of-correction with many images.

So Dan's famous motto, "once for color, once for contrast," now could be expanded to, "once for color (hue), once for contrast, once for saturation."

- George Machen

___________________________________________________________________________

"Lobsterize" Action

Posted by: Rick Gordon

Wed Feb 13, 2008 5:05 am (PST)

I put together an action that appears, as near as I can tell, to duplicate the functionality of the Lobster droplet (based on the demo). It goes as follows:

---

1) Make layer named "GRAY FILL" set to Saturation mode.

2) Fill with 50% Gray.

3) Stamp Visible.

4) Set name of stamped layer to "LUMINOSITY".

5) Set mode of "LUMINOSITY" layer to Luminosity.

5) Hide "LUMINOSITY" layer.

6) Select "GRAY FILL" layer, and change its mode to Luminosity.

7) Stamp Visible.

8) Set name of stamped layer to "CHROMATICITY COMPOSITE".

9) Make Group named "CHROMATICITY". Within that group...

10) Make layer named "BLUE".

11) Fill "BLUE" layer with Black.

12) Apply the blue channel of "CHROMATICITY COMPOSITE" to the blue channel of "BLUE".

13) Make layer named "GREEN", set to Lighten mode.

14) Fill "GREEN" layer with Black.

15) Apply the green channel of "CHROMATICITY COMPOSITE" to the green channel of "GREEN".

16) Make layer named "RED", set to Lighten mode.

17) Fill "RED" layer with Black.

18) Apply the red channel of "CHROMATICITY COMPOSITE" to the red channel of "RED".

19) Delete "GRAY FILL" layer.

20) Show the "LUMINOSITY" layer.

21) If you want, delete "CHROMATICITY COMPOSITE" layer, although you might want to verify:

a) that the "CHROMATICITY" group, shown by itself is identical to the "CHROMATICITY COMPOSITE" layer.

b) that the "LUMINOSITY" layer, shown together with the "CHROMATICITY" group looks identical to the original image (which should be located underneath the layers created by this action).

22) A little Pouilly-Fuissé would be a nice addition.

___________________________________________________

RICK GORDON

EMERALD VALLEY GRAPHICS AND CONSULTING

___________________________________________________

___________________________________________________________________________

Re: "Lobsterize" Action

Posted by: Rick Gordon

Wed Feb 13, 2008 5:11 am (PST)

A couple more insights on ramifications of this approach:

1) A saturation mask can be generated by calculating the Gray channel of the "GRAY FILL" layer against the Gray channel of the "CHROMATICITY COMPOSITE" layer.

2) A curve set up in Normal blending mode, with a clipping mask to the 'RED" layer, and pulled on the RGB axis, will act very much like an "a" channel curve in Lab, but more vermilion to teal.

3) A curve set up in Normal blending mode, with a clipping mask to the 'GREEN" layer, and pulled on the RGB axis, will act very much like an "a" channel curve in Lab, but more green to red.

2) A curve set up in Normal blending mode, with a clipping mask to the 'BLUE" layer, and pulled on the RGB axis, will act very much like an "b" channel curve in Lab, but more purple to chartreuse.

___________________________________________________

RICK GORDON

EMERALD VALLEY GRAPHICS AND CONSULTING

___________________________________________________

___________________________________________________________________________

Re: "Lobsterize" Action

Posted by: Rick Gordon

Wed Feb 13, 2008 5:11 am (PST)

I couple things to note in playing around with the "Lobsterize" action (another name would probably be more gracious):

It may be useful to hang on to the "CHROMATICITY COMPOSITE" layer, as it makes for quicker experimentation with applying the Red, Green, or Blue channels to the "LUMINOSITY" layer in some overlay mode (although the results of doing it with the green channel of the "GREEN" layer, etc. are identical).

Another useful ploy is to layer a copy of the "CHROMATICITY COMPOSITE" layer above image content is some overlay mode at some percentage of opacity to boost saturation.

(But I've been doing both of these operations for quite a while from the combined a and b layer of a Lab copy of the file.)

___________________________________________________

RICK GORDON

EMERALD VALLEY GRAPHICS AND CONSULTING

___________________________________________________

WWW: http://www.shelterpub.com

___________________________________________________________________________

Re: "Lobsterize" Action

Posted by: Stephen Best

Wed Feb 13, 2008 12:58 pm (PST)

I put together an action that appears, as near as I can tell, to duplicate the functionality

of the Lobster droplet (based on the demo).

I just applied this action, the only change being to set the BLUE layer to Lighten mode, and it shows significant differences to the original (up to 53 levels in the red and green, and 101 levels in the blue). For testing, I used the image available from here:

http://www.brucelindbloom.com/RGB16Million.html

and compared the before & after with Calculations set to Difference mode. If you DON'T see any differences, maybe you could post the action itself as I may have made a mistake in entering mine.

Note that there's a multitude of chromaticity combinations that deliver unchanged results when merged. All that is required is that the deltas between the component channels stay the same as the original. The trick is to compute a distribution that can be edited in a fashion that makes sense.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "Lobsterize" Action

Posted by: Rick Gordon

Wed Feb 13, 2008 4:32 pm (PST)

Stephen,

I'm on my way out of town for a few days, without time to test now, but a couple caveats.

In Lobster, the BLUE layer is set to Lighten, but there is nothing underneath it to cause it to differ from being set to Normal. I have retained the Chromaticity composite layer below as well as the original, so I set Blue to Normal, so that layers below are not mixed into the composite.

I have uploaded the action, with enhancements, to the Files section of the Color Theory group at <http: //f1.grp.yahoofs.com/v1/UFqzR7ALcPYkyM_5p7qtK34ILWW7apjWAEj1SARdCO_YkXIXBKrhBMQcFxXMgSnrd4T_9lSp_puv7Z8S74i6hYzMHUOUb9FJaaQ/LABsterize.atn>.

Additions include:

1) Building a saturation mask channel

2) Using the modified inverted saturation mask to demonstrate saturation boosting (masking a straight curve in overlay mode) and saturation cutting (using the re-inverted mask to mask a black Color Fill set to Saturation mode). See both in the SATURATION MODIFY group.

3) Adding straight curves in Normal mode, clipped to each of the RED, GREEN, and BLUE layers to show the possibilities of making moves on those curves. (They are essentially inactive until modified from their current state.)

Rick Gordon

___________________________________________________________________________

Re: "Lobsterize" Action

Posted by: Rick Gordon

Wed Feb 13, 2008 4:33 pm (PST)

Checking against the Lindbloom test file, I see that the differences exist primarily in the dark blues, and that Lobster provides a match in those areas. So I'm very close, but the cigar is still on hold. Any suggestions?

Rick Gordon

___________________________________________________________________________

Re: "Lobsterize" Action

Posted by: Stephen Marsh

Wed Feb 13, 2008 4:33 pm (PST)

Rick Gordon wrote:

I put together an action that appears, as near as I can tell, to

duplicate the functionality of the Lobster droplet (based on the

demo). It goes as follows

Rick, I am glad that you have explored and posted these steps. The research can be taken further, if one is so inclined.

This is indeed one method to extract the hue and saturation data to a layer (there are multiple methods to strip out the chroma/hue). Some methods are more lossy than others.

Some may not care about data loss and other errors, although that does not mean that one can't strive for perfection! It *is* possible to convert the RGB into a LCH layer file with zero loss of levels or unique image colours, so that it is pixel and level and unique colour perfect to the original - a truly lossless conversion (the file is still in RGB with no conversion like Lab, just expressed differently to regular RGB).

I would suggest that you keep playing or experimenting if you wish to take this further than simply being "perhaps almost visually lossless depending on the source file".

I couple things to note in playing around with the "Lobsterize"

action (another name would probably be more gracious)

To be accurate and fair to Lobster, this method that you note is only a rough, general facsimile or "transvestite" of the overview of Lobster.

The product from Ian Lobb is doing a lot more than these "simple" chromaticity steps. You should note that the same edits with this method compared to Lobster result in different results and that the channel structure and brightness order in Lobster is different.

BTW, Lobster is not lossless either, but it is nearly so. Lobster could have done similar, it may appear similar on the surface - but under the hood much more is going on.

Photoshop Elements users have been doing similar things for years, as they don't have channels and have to use layers for similar tasks. Elements authors such as Richard Lynch described similar ways to separate files in Elements years ago.

I am not going to contribute too much to the Chromaticity side of this discussion at this time - as I made it clear in earlier posts that I did not wish to distract the simpler Luminosity side of the thread and that the colour stuff is deeper. As the Luminosity thread is *far from resolved* I will await it's conclusion.

Regards,

Stephen Marsh

___________________________________________________________________________

Re: "Lobsterize" Action

Posted by: Stephen Best

Thu Feb 14, 2008 3:13 am (PST)

I believe there are over 200 steps in the Lobster routine. The derived chromaticity is designed not only to be lossless, but represented in "a Brightness sequence that can best be used by the major Hue and Saturation editing tools" (the author's words). The value is in understanding the intent and how to apply this rather than trying to duplicate it. I've frittered away many hours on the latter!

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Dan Margulis

Wed Feb 13, 2008 12:57 pm (PST)

George Machen writes,

Yes, Dan discusses the issues surrounding under

what types of particular image characteristics

better benefit from "average first, correct

later" vs. "correct first, average afterward" in

his Lab book, pp. 286+, among other places.

But beyond that, isn't this consideration

confined only to tonality/contrast corrections?

Doesn't steepening the individual color channel

curves in RGB or CMYK (especially the

complementary color) additionally add saturation

to the foreground of the significant interest

object, and desaturate the receding edges,

imparting a more realistic three-dimensional

portrayal as would be seen by a human standing in

place of the camera? (Simultaneous contrast.)

This latter effect cannot arise solely from an

"average first, correct later" correction, no?

This is exactly so and reemphasizes the point that luminosity-only corrections can't operate in a vacuum, but generally require that color be adjusted separately even when there doesn't appear to be a color problem at first glance.

The usual problem when working on luminosity only is that the colors seem too subdued afterward, but in the case mentioned here, it's the opposite: in a brilliant object there has to be a falloff of saturation for it to look realistic. In traditional workflows channel curves sometimes can accomplish that, but more frequently some kind of channel blend is needed.

These operations are easier in CMYK than RGB if that's where the file is headed, but in a workflow that features a luminosity correction, we presumably have to arrange for that saturation falloff in RGB. I demonstrate in the forthcoming video one likely solution: generate an artificial black channel in Custom CMYK with Medium GCR and about a 60% maximum black, then multiply it into the RGB document on a layer set to Color mode.

That would be a variant of what I actually demonstrated, which was using an artificial black to get snappier RGB channels in Luminostiy, not Color, mode. I didn't show the new workflow on images with brilliant colors because I presume that it is not all that effective with them.

So, if we were to correct this particular type of image using a luminosity approach, an RGB master curve would be a disaster area, a set of channel curves much better, and a single luminosity curve best of all. However, my suspicion is that this particular category may handle better if the luminosity move is eliminated or kept to a minimum.

Dan Margulis

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Best

Wed Feb 13, 2008 4:32 pm (PST)

Dan Margulis wrote:

This is exactly so and reemphasizes the point that luminosity-only corrections

can't operate in a vacuum, but generally require that color be adjusted

separately even when there doesn't appear to be a color problem at first

glance.

I don't think anyone was pretending otherwise, other than for minor tweaks in luminosity. The beauty of this approach is that you can make colour adjustments (even drastic ones) without having to worry about the affect on the image's overall luminosity. With channel moves you can't change one without the other. Which is why this technique is ideally suited to late stage adjustments.

Personally I think this area is worthy of significant research ... at least as thorough as you've done for Lab. Note than we haven't even scratched the surface on how best to represent chromaticity as here's a lot of flexibility here.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Sharpening comparison for RGB Luminosity, Luminosity, and LAB

Posted by: "williamtheis"

Fri Feb 15, 2008 6:14 pm (PST)

So far, the Luminescence discussion has been the effect of bare curves versus those applied through a luminescence layer. Stephen, I don't mean to steer the discussion away from this but I was interested in the effects on sharpening. I took a picture similar to Dan's cactus picture (Fig 6.10 in PP5) and made four copies to which I sharpened to the exact same amount (YKW, 1.1 pixels, 0 threshold) in the following way

1) Duplicated the background layer and sharpened it, flatten ("Normal RGB Sharpen")

2) Duplicated the background layer and sharpened it, changed layer blending to "Luminescence" and flatten ("RGB")

3) Make a Labster Luminosity layer by alex kent's technique in message #19048, sharpen, flatten ("LUM")

4) Take the file to LAB, sharpen L, return the file to sRGB ("LAB")

I then took all four sharpened versions and put them over the original. By changing the blending to difference I could see the differences between the sharpening methods, as well as look at the histogram numbers, which were (skipping the "Normal RGB" numbers):

Compare L R G B

LAB-RGB 3.5 4.0 3.2 3.8

LUM-RGB 2.0 2.4 1.8 2.1

LUM-LAB 3.3 4.6 3.2 4.2

There was a larger difference between LAB and either LUM or RGB than between LUM and RGB that seem similar to one another histogram-wise. Putting LAB eyedroppers on the light and dark sides of a typical edge, the L values were (the RGB colors are given in parenthesis):

Light side Dark Side

Original RGB 69 (226/144/167) 32 (127/47/57)

Normal RGB Sharpen 80 (230/186/193) 23 (110/13/36)

Sharpen RGB in lum blend 80 (224/189/19 21 (99/20/29)

Sharpen Labster 78 (211/188/192) 17 (82/17/25)

Sharpen L in LAB 76 (217/175/193) 19 (92/17/29)

Here Labster and LAB seem to be similar, with Labster having noticeably less luminescence on the dark side.

Next, I took the difference layers and increased contrast leaving hue and saturation intact (no AutoLevels or AutoColor... just push contrast to 75 or so to see what channels are most different. The LUM was definitely different as the dark side of the edge really got dark but the look was pretty harsh given that all sharpening was done at the same YKW level. The LAB seemed to distribute complementary colors into the Light side of the halo (perhaps due to the dither in converting color spaces?), which none of the other sharpening techniques did.

The bottom line of course is how they looked. I'm not going to claim any is head and shoulders better than another, just different. However, if you cornered me I would judge the LUM harsher than either RGB or LAB blending, which may be good for images that can stand more sharpening. LUM definitely makes things on the dark side visibly darker than then the other techniques. In this sense, it is akin to Dan's suggestion of making a layer emphasizing darkening more than lightening. The LAB however was my favorite for this image since the white side of the halo still retained color rather than stark white of the LUM or RGB sharpenings.

I'm sure that others will come to some other choices on this image and that other images may lead to a different conclusion.

Bill Theis

___________________________________________________________________________

Re: Lobster

Posted by: "williamtheis"

Fri Feb 15, 2008 6:14 pm (PST)

Peter Leyland" wrote:

This is quite true. I wish the product was available for Macintosh, I

would give it a try.

[INSERTED BY MODERATOR]

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

the Freegamma site says the droplet works with Mac OS X 10.3.9 to 10.4.x and Adobe Photoshop 7 to CS2 (English language version)

CS3 and 10.5 support coming at the end of January 2008

There is nothing to stop you

Bill Theis

___________________________________________________________________________

Re: Lobster

Posted by: Rick Gordon

Sat Feb 16, 2008 3:17 am (PST)

The currently available demo appears to function without complaint with Photoshop CS3.

Rick Gordon

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Dan Margulis

Sat Feb 16, 2008 4:00 am (PST)

Stephen Marsh writes,

Thanks Dan. On your opening sentence, both points are open for debate

and not worth arguing either way at this time, as it would only

detract from the Luminosity thread IMHO. I may introduce the second

half of my thread, on Chromaticity, if the first half on the simpler

Luminosity extraction and non-conventional Luminosity editing proceeds

well.

OK, that seems reasonable.

My point is that before reading the Lobster notes, I was not aware

that Luminosity blend mode is "lacking" and that it can be "fixed" by

the use of a grayscale layer, blended in luminosity mode - that

equates to RGB luminosity levels and does not affect the base image

and does affect the edit results. It is generally put forth that

simply using luminosity blend mode is all that is required.

Few other authors discuss luminosity maneuvering in any depth. Those that attempt to, as with LAB, are generally trying to summarize my work, only occasionally trying to build on it. As with LAB, I was writing extensively about the topic for several years before anybody else jumped on the bandwagon. I may well have written more about luminosity mode and LAB than all other authors put together, and surely have a dominating position in the discussion. So, in these two subdisciplines, nothing can be said to be "generally put forth" unless the person putting it forth is me. And certainly, even when I was just learning the ropes of this mode in the 1990s and was making mistakes in how to apply it, I have never said anything like the above.

My use of the term "accepted wisdom", be it the for the Photoshop user

guide or major published authors or other commentators on Photoshop,

none of these sources say to add in a Luminosity "Channel" layer above

the colour data and to then clip edits or directly edit the L layer as

in the case of filters such as USM or surface blur etc. I have only

seen this recommended by Lobster. All the "conventional wisdom" has to

say is to simply set the layer data to Luminosity mode with no

addition of a monotone Luminosity "Channel" layer.

The conventional wisdom says that with respect to sharpening, true. There is, AFAIK, no such conventional wisdom with respect to curves.

With respect to blurring, I don't believe that there's been much commentary, but I can say that (unlike curves) it is *clearly* better to go channel-by-channel in luminosity mode in this case. The green channel is typically much less noisy than either the red or the blue. Any composite luminosity channel uses around 60% of the green as a base. This masks any noise to a great degree. It's easier to blur that noise out in the channel where it's originally found, and then, if desired, set mode to Luminosity.

This is "your' accepted wisdom Dan, not what I would call

"mainstream". I don't know of anybody else who has made individual

channel editing as famous as you.

"Famous" and "mainstream" are basically synonyms. No techniques have ever become famous because of my good looks and personality. Instead, they have become famous because people, particularly at the high end, have tested them for themselves and found them to be more effective than previously known methods. Generally people who read what I have to say find that they agree with certain parts and disagree with others. When they agree, they often pass the word to others, and if enough people agree, the technique becomes famous.

The mainstream approach loves the speed and simplicity of a single

curve over perhaps milking slightly more contrast or detail out of an

image by going to the "extreme" of three or more separate curves.

There's a difference between "mainstream" and either the words "convenient" or "user-friendly." For purposes of discussions here, I think we should exclude things like Auto Color. Lots of people use it, but that doesn't make it mainstream among our audience. Like many others, I use RGB master curves from time to time. But I do so advisedly, when the move is small enough that it's not worth worrying about the slight technical loss. Others use Levels in the same way. Nevertheless, it has been well understood for more than twenty years that master curves are an inferior way to edit images. If people want to use them as a shortcut that's fine, but here we are speaking about an audience concerned enough about quality that they are considering using a third-party plugin to assist their curves. Such an audience IMHO would be most unlikely to be considering master curves.

As this is not the first time that lack Mac support has been

mentioned, I can supply layered PSD files converted using the Lobster

demo on the PC, if for whatever reasons the Mac download does not work

for you or that you don't have access to a Win OS version of Photoshop.

I will have to plead guilty here. Ian Lobb contacted me in late 2005 to suggest I try the Lobster product. At that time, the demo version was Windows only. He did, however, send me a coupon for a free Mac copy, which I never downloaded due to lack of time. When we get around to discussion of the color treatment, rather than luminosity, we can revisit that if need be.

I'm off on the high seas this morning, so offline for a week.

Dan Margulis

___________________________________________________________________________

Re: Sharpening comparison for RGB Luminosity, Luminosity, and LAB

Posted by: "williamtheis"

Sun Feb 17, 2008 3:22 am (PST)

the tables I posted didn't come out right. let me try again

Compare______L______R_____G_____B

LAB-RGB_____3.5____4.0___3.2___3.8

LUM-RGB_____2.0____2.4___1.8___2.1

LUM-LAB_____3.3____4.6___3.2___4.2

_____________________________Light side_______Dark Side

Original RGB______________69 (226/144/167)__32 (127/47/57)

Normal RGB Sharpen________80 (230/186/193)__23 (110/13/36)

Sharpen RGB in lum blend__80 (224/189/193)__21 (99/20/29)

Sharpen Labster___________78 (211/188/192)__17 (82/17/25)

Sharpen L in LAB__________76 (217/175/193)__19 (92/17/29)

Bill Theis

___________________________________________________________________________

Re: Sharpening comparison for RGB Luminosity, Luminosity, and LAB

Posted by: Stephen Best

Sun Feb 17, 2008 3:22 am (PST)

williamtheis" wrote:

Thanks for passing on your findings. If however you're doing RGB and Lab levels comparisons, ideally the gamma of both spaces should be the same. Photoshop's sharpening algorithms are gamma blind. You may want to convert your original RGB image to a working space based on L* first. Either eciRGB_v2 or the earlier (and identical) LStar- RGB. You can download the former from here:

http: //www.eci.org/eci/en/044_working_colour_spaces.php

I do most of my editing work in spaces based on L*, either a custom one based on the coordinates of Lindbloom's Beta RGB, or QTR - Gray Lab (from the Quad Tone RIP package). The above ECI profile is a good replacement for Adobe RGB (1998) for offset work.

The lack of colour fringing is a plus for me. It means you can sharpen less (lower amount and/or radius) for the same overall effect in the print.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Lobster 2.0 released

Posted by: Stephen Best

Tue Feb 26, 2008 7:10 pm (PST)

For those of you interested in the luminance/chromaticity separation as previously discussed

(not too many judging by the lack of feedback) Lobster 2.0 has just been released. More

details here:

http://www.freegamma.com/

In my own brief testing, the speed has been much improved and now makes it usable on

large files. It's also now completely lossless. I have yet to explore the chromaticity changes

but this looks like a perfect complement to the "Scene Referred Workflow" as outlined here:

http: //www.21stcenturyshoebox.com/essays/scenereferredworkflow.html

According to the web site, the price doubles in a few days time. (I have no affiliation with

FreeGamma other than its author Ian Lobb being a fellow Australian.)

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "dbernaerdt"

Sat Mar 1, 2008 3:39 am (PST)

I have to admit at the time this thread generated the most amount of traffic, I had yet to fully digest it and look at the exact layer structures to realize the variations being discussed.

In light of re-reading and discussing this with local peers, I have put together a brief web page showing the various options being discussed.

http://www.dbphoto.net/techniques/RGBLuminosity

I hope this sparks additional discussion as I have tried the techniques with a couple dozen images now and am quite intrigued by the possibilities, especially as it relates to its use after raw file conversion.

Darren Bernaerdt

___________________________________________________________________________

Alex Kent Luminosity Layer

Posted by: "Howard Smith"

Sun Mar 2, 2008 3:55 pm (PST)

Was Alex Kent the first to propose creating a Luminosity layer by blending 50% gray with the original image? If not, does anyone know who originated the idea?

Strange question, but I'm a firm believer in crediting the originator of any novel new technique when it's being described in a post. This not only gives credit to the originator but also provides information useful for anyone researching the uses for a particular technique.

Howard Smith

___________________________________________________________________________

Re: Alex Kent Luminosity Layer

Posted by: "Alex Kent"

Sun Mar 2, 2008 5:33 pm (PST)

on this list, in the last 6 months, i might have been to first person to mention it.

it was in response to a challenge/teaser posted by Stephen Marsh, who later pointed out several other ways to obtain the same RGB Luminosity result. so, i don't think i can really take any credit. thanks!

alex kent.

___________________________________________________________________________

Re: Alex Kent Luminosity Layer

Posted by: Stephen Marsh

Sun Mar 2, 2008 5:34 pm (PST)

Howard, to be clear, the *key* step is that one must blend in *color/saturation/hue* blend mode (the colour could be any shade of gray, white or black), otherwise one has simple desaturation which has altered luminosity...blending as saturation=0 via color/hue/saturation mode is the critical step for correctly preserving the original luminosity.

There have been many people who have commented on or "published" the idea.

* For example, years ago (no time to research this factoid) either John or Chris Russ from Reindeer Graphics mentioned how to extract luminosity on a retouching/restoration web forum.

* Then there would be Ian Lobb, who appears to be the first to commercialise the concept in his Lobster product.

* On this list, there was Stephen Best who first posted about this in January 2007.

* Then I "discovered" the method and topic for myself a year later after missing the original post from Stephen Best. I then reintroduced it to the list in January, after spending December playing with the various concepts. Rather than simply stating the method in my post to the list, I wanted the list to experiment and to attempt to meet the "Lobster challenge".

* Alex Kent was the first to correctly answer my "Lobster challenge" with one possible variation/approach.

* I cited a link to a 2006 podcast from Greg Apodaca in my confirmation reply to Alex Kent where this was also discussed.

* One should also give credit to the unknown Adobe programmer that included this stuff (was it to plan or is it simply an unplanned result of how other things are designed and integrated?).

As you can see, there is a long list and it hard to know who to give credit to as the originator of this technique.

Regards,

Stephen Marsh

___________________________________________________________________________

Re: Alex Kent Luminosity Layer

Posted by: Stephen Best

Sun Mar 2, 2008 5:34 pm (PST)

The technique has been around for years and is only one of many ways to achieve the same

result. For original writing on the subject, see:

http://www.freegamma.com/

http://www.21stcenturyshoebox.com/

I'd be interested in hearing of further sources.

Note that luminosity editing is only part of the picture. The separation of RGB luminosity and

chromaticity (depending on how the latter is done) opens up a whole Pandora's box of possibilities similar to those for Lab.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: Alex Kent Luminosity Layer

Posted by: "Howard Smith"

Mon Mar 3, 2008 2:27 pm (PST)

I want to thank Stephen Best, Stephen Marsh, and Alex Kent for answering my question about the origin of the creation of a Luminosity layer with the aid of a 50% gray fill. The key parts of their replies are reproduced below.

It's a bit more complicated than I thought. The group of posts that first excited me also seemed complicated in the beginning, especially after visiting the Lobster website and looking at the many layers in the illustration. I tried all kinds of things to figure out how three separate chromaticity layers were being used, then finally gave up on it. Fortunately Stephen Marsh is a remarkably patient fellow who doesn't give up easily when it comes to promoting new ideas. And it was through the generosity of Stephen Best who patiently explained how to simplify the whole thing that I was ever able to make any progress. And in spite of the apparent wealth of information regarding the creation of a Luminosity layer I didn't make the connection until Alex Kent went into detail. There have been many comments made in the past few weeks about differences in luminosity layers and how some are less desirable than others, leading me to believe that just using a Curves Adjustment Layer in Luminosity blending mode was the only realistic approach. Then someone (can't remember who) posted a comment that helped clear that one up by noting that the luminosity layer described by Alex Kent does not affect the Histogram appearance when blended with the original image in Luminosity mode. That was when all the pieces fit together.

As for creating a Luminosity layer, here's a quicker way to achieve the same thing: Create a Solid Color Adjustment Layer. To fill it with black, set L=0, a-0, b=0 in the Color Settings dialog box that pops up. Change the blending mode to Color. Click Shift/Ctrl/Alt-E (Shift/Command/Option-E) to replace the Solid Color Layer with a Luminosity layer. If you drag the Histogram onto the Desktop so it remains visible, then do this with a duplicate image, you will see that there is a tiny change in the Histogram compared to the Histogram for the unedited duplicate. At least to me this does not appear to be anything to worry about. Just out of curiosity I copied the Lightness channel from a Lab conversion and pasted it into a new layer above the background layer of the original RGB image. The image appearance was lighter this time, and the Histogram made a very noticeable shift to the right. This probably has little or no significance, but it does emphasize how little effect the original Luminosity layer has when blended in Luminosity mode. This is just as an observation, not a challenge.

Howard Smith

___________________________________________________________________________

Re: Alex Kent Luminosity Layer

Posted by: Stephen Best

Mon Mar 3, 2008 5:14 pm (PST)

The major difference between Luminosity (as defined/implemented by Photoshop) and Lightness (the L channel of Lab) is gamma. Unless your RGB working space is based on L* gamma, the tonal distribution will be different. There are also subtle differences between Luminosity and Lightness that I think have to do with how the colours are reconstructed.

The simplest method of luminosity extraction is to duplicate the background, do an Edit>Fill of 50% Gray in Color mode (this is a single step) then change the layer to Luminosity blend. For comparisons, duplicate the image and use Calculations of the merged images in Difference mode, save the result as a new channel and view this channel (Alpha 1) in the Histogram. If you've implemented luminosity extraction correctly, there will be NO change. The preferred solution in my mind though is to use Lobster 2.0 as this opens up new possibilities for editing colour as well.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: Alex Kent Luminosity Layer

Posted by: Stephen Marsh

Tue Mar 4, 2008 1:17 am (PST)

Howard Smith wrote:

It's a bit more complicated than I thought. The group of posts that

first excited me also seemed complicated in the beginning, especially

after visiting the Lobster website and looking at the many layers in

the illustration. I tried all kinds of things to figure out how three

separate chromaticity layers were being used, then finally gave up on

it.

Howard, even if Luminosity is thought to be known and colour perhaps more interesting - I wanted to break the topic up into two separate issues, as each can get rather deep (deeper than initial thoughts may indicate).

Thus the emphasis on Photoshop RGB luminosity, before RGB chromaticity...

And in spite of the apparent wealth of information regarding the

creation of a Luminosity layer I didn't make the connection until Alex

Kent went into detail.

I did not explain the method up front on purpose, but held a link explaining it in reserve for "proof" - as I wanted the list to explore and work with things first (the journey often being more critical than the destination). It was after the post from Alex and my confirmation reply to Alex, that the thread really progressed* (up until this point is was just me trying to the coax the list into action).

* Photoshop RGB luminosity clipped/grouped edits are not resolved to my satisfaction yet, the issue has been identified but not answered.

There have been many comments made in the past few weeks about

differences in luminosity layers and how some are less desirable than

others, leading me to believe that just using a Curves Adjustment

Layer in Luminosity blending mode was the only realistic approach.

This is what I have been referring to as "conventional wisdom" or the standard way of doing things. The Lobster author is the first to talk about introducing a monotone luminosity 'channel' layer and clipping the edits to this layer.

As the examples posted show, there is indeed variation between different but similar tone curve moves:

http://www.dbphoto.net/techniques/RGBLuminosity (download and layer stack the crops then compare!) - thanks Darren!!!

http: //members.ozemail.com.au/~binaryfx/act-luminosity-curves.html

Then someone (can't remember who) posted a comment that helped clear

that one up by noting that the luminosity layer described by Alex Kent

does not affect the Histogram appearance when blended with the

original image in Luminosity mode. That was when all the

pieces fit together.

This has been a mystery for me all along...

If adding the luminosity 'channel' layer has *no effect* on the base RGB image - why does clipping edits to this layer have a definite effect? ...#hen the layer makes no difference?! This is where I run in mental circles.

Lobster's stance is that it is due to the errors in RGB edits in Luminosity mode, that Luminosity blends are not correct if one is not using a grayscale Luminosity layer.

Is it simply a bug? Is it an error as Lobster state? As the Lobster notes illustrate, before blaming Photoshop as 'buggy', perhaps one should question *one's own understanding* of the program first, perhaps it is a persons understanding that is 'buggy' and not Photoshop.

Just out of curiosity I copied the Lightness channel from a Lab conversion and pasted it into a new layer above the background layer of the original RGB image. The image appearance was lighter this time, and the Histogram made a very noticeable shift to the right. This probably has little or no significance, but it does emphasize how little effect the original Luminosity layer has when blended in Luminosity mode. This is just as an observation, not a challenge.

Howard, this is of importance and significance, as the Luminosity channel layer should make *absolutely no change* to the original RGB image when blended in luminosity mode (if the goal is to extract the original luminosity).

This indicates that the L channel of Lab (Lightness) is not the same thing as the Luminosity component of RGB data in Photoshop.

The luminosity extraction is simple with the tools provided by the Adobe programmers, there is no mode change, it is a lossless move and one never leaves the original RGB. The conversion (not extraction) to Lab is not lossless and is more complex.

This is also why when folk talk of loading a "luminosity mask" from the composite channel - they are not creating Photoshop luminosity values, they are creating grayscale work space values. Any tone could be considered to have a luminosity value, but this is not the same as thing as the tone being the Luminosity component of the image itself. Now that I know better, I no longer use the term luminosity mask to describe cmd/ctrl~ (tilde) moves, as this is not luminosity.

Now that the concepts are better understood, a review of the thread may lead to some discoveries that were missed the first time.

Stephen Marsh

___________________________________________________________________________

Re: Alex Kent Luminosity Layer

Posted by: "Howard Smith"

Tue Mar 4, 2008 9:37 am (PST)

Thank you once again, Stephen [Best]. For some time I've been intrigued by all the discussions of different kinds of luminosity but this is the first time I can recall reading a relatively non-technical explanation that makes sense. It's going to take time but I may yet come to have a better technical understanding of the whole subject of luminosity.

I tried your suggestion about using a Difference blending mode. I'm not sure if I was doing it right because I didn't see any data at all in the Histogram when I looked at the resulting solid black, though I did see very small effects on the Histogram's tonal values when comparing duplicate images where one had the extracted luminosity layer applied in luminosity mode. Even if there is a difference it's hard to see how this will have any practical effect at least in my own work.

I've given a lot of thought to studying the Lobster program, and probably will do so in the future. Right now all the new ideas are continuously merging to produce so many new ideas and correction approaches that it's even waking me up at night. This has proven to be an unusually interesting area for investigation.

I really appreciate the additional information. All these pieces are fitting together to give me a whole new way of looking at Photoshop.

Howard Smith

___________________________________________________________________________

Re: Alex Kent Luminosity Layer

Posted by: "Howard Smith"

Tue Mar 4, 2008 9:37 am (PST)

Stephen [Marsh], I'm sure you had no idea how much good would come of your initial challenge. With reference to your comments about different kinds of luminosity, all that really matters to me at this point is that the layer created by extracting luminosity from the RGB image with the 50% gray blending has opened up a whole new world for my own color correction. While I don't pretend to understand all the underlying technology, I do see a decided difference in the time savings and improved quality of the images with which I work every day. This new information, along with the routine use of the Blend-If sliders you've promoted for so long, have made a dramatic difference. It actually took far longer to become familiar enough with the Blend-If sliders than it has to become familiar with this separation of luminosity and chromaticity, but both are becoming indispensable.

Thank you for helping expand my knowledge with information one cannot find in reference books. This is an exciting time to be involved with Photoshop.

Howard Smith

___________________________________________________________________________

Re: Alex Kent Luminosity Layer

Posted by: "Alex Kent"

Tue Mar 4, 2008 7:50 pm (PST)

the sources for all this stuff are beginning to blur, but i believe Greg Apodaca's Photoshop Mechanics podcast (episodes 001 and 002) illuminated this for me.

Grouping Tonal Effects (curves etc.) to the extracted RGB Luminosity layer(in Luminosity blend mode) works magic because: When you make a Curve change to the Composite curve in RGB mode, Photoshop makes that change to each R G B component, once that component reaches a limit (maximum or minimum value) it can no longer change. But the other channels will continue to be effected! When you change the layer blend mode of the Curve adjustment layer, Photoshop doesn't put the Curve on the Luminosity data, but instead takes the Luminosity component of the effected RGB data.

so, it's not exactly a bug or an error. but a design decision which makes Layer Blending modes make sense, but not (in this case) do what we want.

...

All layer blending modes (including normal), whether applied to a pixel layer or an adjustment layer (or vector, Smart Object, etc), blend the data of that layer with the data from the composite of the layers below. This blend is done in the working bit depth, colourspace, and with the appropriate math for the selected blend mode.

as a starter for a separate, and much more propellor-head, conversation; why is the bit depth relevant to layer blending / compositing? In other words, why (and when) can you get a better quality of flattened image by switching your 8bit RGB file to 16bit before flattening it, then switching it back to 8bit after flattening ?

regards,

alex kent.

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Dan Margulis

Wed Mar 5, 2008 6:10 pm (PST)

Darren writes,

I have to admit at the time this thread generated the most amount of

traffic, I had yet to fully digest it and look at the exact layer

structures to realize the variations being discussed.

In light of re-reading and discussing this with local peers, I have

put together a brief web page showing the various options being

discussed. http: //www.dbphoto.net/techniques/RGBLuminosity

The example is instructive and deceiving at the same time. We often have discussed photographs of red flowers in these context. This image, however, is not a photograph, at least not a photograph of natural red flowers. Instead, the original source is a *painting* of red tulips.

There's a big difference. Humans see a much more rapid falloff in saturation in a brightly colored object than a camera does. That's why we so often need to blend into the red/cyan channel, or make some move in LAB to partially neutralize the parts of the flowers that are already less red.

Here, we don't need to do that, because the artist, being human, painted the flowers as he perceived them, with the aforementioned rapid falloff. That might cause some people to underestimate one of the points made by several of the posters to the thread: luminosity corrections presuppose that *color* corrections will be needed. Here, they aren't--because the artist has already corrected the color for us. Hence, these versions all look better than they would if this were a photograph of actual flowers. Nevertheless the emphasize the points about channel structure.

In images of red flowers detail in the red channel is found in the highlights and in the green in the shadows. Applying an S-shaped master curve, as Darren does in the first two examples, is very bad for detail because both the highlights and shadows fall in flat parts of the curve and are therefore damaged. The examples show:

1) Applying a straight master curve not only costs detail but increases saturation undesirably. If this had been real flowers they would have turned to red blobs.

2) Applying the same master curve on a layer set to Luminosity mode avoids the saturation increase but hammers the detail just as badly.

3) Applying the same S-curve to a luminosity *CHANNEL* rather than to the three RGB channels set to luminosity doesn't look particularly comparable to the first two, because the result seems lighter. This is because the lighter parts of the flowers are being lightened by the shape of the curve. But when the same shape *master* curve is applied, only the red channel gets lighter: the green channel gets *darker*, and the green carries more weight than the red. So, if we were trying to match the overall weight of versions 1 and 2 without the loss of detail caused by the master curve, we'd need a less aggressive curve than this one--or we could use the superior method described below in #5.

4) And now, the surprise. The same curve is applied to the L channel of LAB. One would think that this would yield a similar result to #3: after all, they're both applied to single channels that theoretically don't affect color. But they aren't equivalent. In #3, the lightest parts of the flowers are no longer as pink as they are in #4.

The reason? In #3, being worked in RGB, making the flowers so light renders it impossible to retain the original color without going out of RGB gamut, which Photoshop can't permit, so the color dies. When the operation is performed in LAB, however, the resulting color is *not* out of LAB gamut--it's merely the imaginary color that is both extremely red and extremely light. In reconverting the LAB file into the RGB necessary to display it to us, Photoshop can't portray this "color" accurately because there isn't any such color, so it splits the difference, giving us neither of the extremes, but rather a soft pink that's more agreeable than the RGB version.

We could get the technique of #3 to get something as nice as #4 by a bizarre workaround: apply the curves to a duplicate, rather than adjustment, layer set to Luminosity mode. Then convert the document to LAB without flattening the layers. That will create the imaginary color that was lacking when the file was in RGB, so the appearance will change considerably. Once in LAB, flatten the image, and return it to RGB without further ado. Ugly procedure, but effective.

An improvement on this (and there are improvements upon the improvement available, too): rather than establish a luminosity channel, stay in RGB. On a curves adjustment layer, apply a curve to the red that steepens the highlights and to the green that steepens the shadows. Then, having already added detail, we can, if we wish, go through step 3.

I hope this sparks additional discussion as I have tried the

techniques with a couple dozen images now and am quite intrigued by

the possibilities, especially as it relates to its use after raw file

conversion.

This is a good point but I think we are a few years away from raw converters with the needed capabilities. It's clear that there is a growing awareness of the importance of luminosity moves, but I think we also all realize that channel blending is if anything more important in establishing better luminosity than curves are. At least two current raw converters, and probably more, allow a true luminosity-channel curve with a separate color adjustment. That's a start, but to match what's available in Photoshop we'd need the ability to apply channel curves in luminosity and in color modes and to interpret the results in LAB rather than RGB; we'd need the ability to blend not just the RGB channels with one another but to construct various types of supplementary channels and blend with them; and we'd need some pretty fancy color maneuverability.

All this can be done. Photoshop itself is rather long in the tooth. Much of its color methodology dates from long ago when nobody knew what we know now, and when even if we did know it there were computing limitations that don't exist today. In 1998 it would have been quite difficult to create a color package to even equal Photoshop but today it would be possible to create something considerably more powerful.

At the moment, those who are skilled with these luminosity moves will get better results by acquiring raw images very conservatively, even in the good raw modules. However, something like the picture-postcard workflow is crying out for integration into somebody's raw module. The workflow is doable in Photoshop fairly rapidly, yes, but it jumps back and forth between colorspaces in a way that could be handled more gracefully in the raw phase, plus it's hard to keep an editing trail with all these colorspace moves in Photoshop.

Dan Margulis

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Best

Wed Mar 5, 2008 8:13 pm (PST)

"Dan Margulis" wrote:

The reason? In #3, being worked in RGB, making the flowers so light renders

it impossible to retain the original color without going out of RGB gamut,

which Photoshop can't permit, so the color dies. When the operation is

performed in LAB, however, the resulting color is *not* out of LAB gamut--it's

merely the imaginary color that is both extremely red and extremely light. In

reconverting the LAB file into the RGB necessary to display it to us,

Photoshop can't portray this "color" accurately because there isn't any such

color, so it splits the difference, giving us neither of the extremes, but rather a

soft pink that's more agreeable than the RGB version.

Strictly speaking, the "colour" is still there, just masked by the (edited) luminosity layer above. As it is with Lab at the tonal ends of the L curve. So I don't see the distinction. It should also be noted that the resultant colour depends on the RGB space chosen when converting back from Lab. This has always struck me as somewhat random.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Best

Fri Mar 7, 2008 4:32 pm (PST)

Dan Margulis wrote:

When the operation is

performed in LAB, however, the resulting color is *not* out of LAB gamut--it's

merely the imaginary color that is both extremely red and extremely light. In

reconverting the LAB file into the RGB necessary to display it to us,

Photoshop can't portray this "color" accurately because there isn't any such

color, so it splits the difference, giving us neither of the extremes, but rather a

soft pink that's more agreeable than the RGB version.

Not so much to labour the point, but more to satisfy my own curiosity I just did the following test.

I started with an sRGB image (16-bit to minimize rounding) and filled it with pure red (255,0,0). The Lab readout for this is (54,81,70) and with a hue angle of 0. I then converted this to Lab and bumped the lightness to 75, leaving the colour components (a and b) unchanged. The Lab value at this stage is (75,81,70). I then converted the Lab image back to a number of RGB spaces and here's the results:

sRGB: RGB=(255,100,59), Lab=(63,58,54), Hue=13 degrees

Adobe RGB (1998): RGB=(255,100,64), Lab=(69,70,62), Hue=11 degrees

ProPhoto RGB: RGB=(251,127,64), Lab=(75,81,70), Hue=20 degrees

This confirms my suspicion that the destination space itself is a governing factor. Also the (not really surprising) result that there has been a hue change as well. Now if the resultant change is pleasing there's not more much to say ... but on the face of it it suffers the same uncontrolled side-effects that one sees with composite RGB moves. Unless I'm missing something here.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Mike Russell"

Fri Mar 7, 2008 8:27 pm (PST)

Most of the discrepancy you are seeing is due to using an artificially pure color for your test, and then bumping it out of the sRGB and Adobe RGB gamuts. Photoshop is forced to punt from the 50 yard line, and the ball veered 13 degrees to the orange side of the goal.

The destination (RGB) space is indeed important, particularly if you switch from one RGB space to another. ProPhoto also has a very different red primary than sRGB and Adobe RGB. Converting pure red from sRGB to ProPhoto, with no brightness change, results in a hue shift of 17 degrees.

Mike Russell - www.curvemeister.com

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Best

Fri Mar 7, 2008 10:12 pm (PST)

Only the Lab coordinates are comparable and we've seen a hue change in all spaces, though less for ProPhoto RGB (17 to 20) ... as one would expect. My point is that you can't dump on RGB composite moves (and justifiably so) but hold such Lab to RGB distortions as OK. Either you want control over the changes you make (no side effects) or you don't.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Best

Sat Mar 8, 2008 8:47 am (PST)

Mike Russell" wrote:

Photoshop is forced to punt from the 50 yard line, and the ball

veered 13 degrees to the orange side of the goal.

Great analogy BTW.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Dan Margulis

Sun Mar 9, 2008 11:16 am (PDT)

Stephen Best writes,

Not so much to labour the point, but more to satisfy my own curiosity I just

did the following test.

I started with an sRGB image (16-bit to minimize rounding) and filled it with

pure red (255,0,0). The Lab readout for this is (54,81,70) and with a hue angle of 0. I

then converted this to Lab and bumped the lightness to 75, leaving the colour

components (a and b) unchanged. The Lab value at this stage is (75,81,70). I then

converted the Lab image back to a number of RGB spaces and here's the results:

Whenever we ask Photoshop to convert a color that's wildly out of gamut in the destination colorspace, we can expect the unexpected. Usually this problem is encountered when converting from RGB to CMYK (and savvy practitioners avoid the issue, by making sure that the RGB file is brought to being at least close to the CMYK gamut before converting) but here you have done it by creating an LAB color that's far outside of the RGB gamut and then going to RGB. There's no correct answer as to how to make this particular conversion.

Nevertheless, sometimes we know that *whatever* happens during the conversion will be better than trying to accomplish the same thing in RGB. That's the theory of retouching with imaginary colors and that's what's happening here.

The above is *not* an example of when or how one would want to do that. The usual case is as in Darren's image of pink tulips, light pastel colors (and, less frequently, rich darks). 255r0g0b is not such a color; it's much too dark. The problem is one of computation space and not destination space.

I chose a typical light pink in Darren's sRGB original. At 251r114g142b, it's the equivalent of 66L55a12b.

Darren now wanted to apply an S-curve, not as a master curve, but rather to a luminosity channel as per the Lobster approach. The curve calls for a sharp lightening of the above color. The setting of luminosity as the layer mode supposedly insures that the color does not change. Unfortunately, while the file is in RGB, both objectives cannot be accomplished simultaneously. The red channel is already virtually as light as it can be. Any lightening necessarily adds more of green and blue components than of red, automatically desaturating that area of the flowers in a manner Darren would be unlikely to approve of.

For better or for worse, when confronted by contradictory demands like this, Photoshop gives priority to the luminosity. That means Darren gets a file as light as he asked for. And, since Photoshop can't construct any color in RGB that can't be constructed in RGB, it has no choice but to cut saturation and probably change hue as well. The new color is a much duller, albeit lighter, 255r184g199b, or 82L28a3b.

This is a limitation of making computations in RGB that does not exist in LAB. To show that is not LAB manipulation as such that is responsible, convert the existing file to LAB without flattening it. That is, it has two layers, the top one being a luminosity channel that has been curved as described above and the bottom is the original image. In principle there should be no change in appearance since the file has not been altered. In practice the file looks much better after conversion.

The "new" color of the LAB file is 83L55a12b. The lightness is established by the top layer; setting it to Luminosity mode preserves the AB values. Thus, we construct a color impossible to construct in RGB, leaving Photoshop with the dilemma of how to interpret an LAB file that calls for a color that, if it exists at all, is wildly out of any RGB gamut. Trying to construct an impossible color in RGB is one thing; trying to derive an RGB equivalent for an already- constructed impossible color is another. Flatten the image in LAB, and the color is now a fair accompli. Convert it to RGB, and Photoshop has to try to interpret it. Not surprisingly, since the color being called for cannot be matched, it chooses something in between, neither as light nor as colorful as Darren was calling for.

After converting to LAB for flattening only and then reconverting to RGB, the new value is 255r162h187b, which is the equivalent of 77L38a2b. This is considerably more colorful than if the file had been flattened in RGB and is surely more appropriate in an image of strongly colored flowers.

This confirms my suspicion that the destination space itself is a governing

factor. Also the (not really surprising) result that there has been a hue change as well. Now

if the resultant change is pleasing there's not more much to say ... but on the face of it it

suffers the same uncontrolled side-effects that one sees with composite RGB moves. Unless I'm missing something here.

Something as described above may be uncontrolled in the sense that we don't know in advance what is going to occur, but it's controlled in the sense that we know it is better than if we do nothing. It is not analogous to anything in the RGB>CMYK conversion.

Dan Margulis

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Francis Corvin

Sun Mar 9, 2008 2:58 pm (PDT)

Isn't the file, whichever space it is in, displayed in RGB? Therefore it should be converted to RGB by the display adapter and subject to the same limitations. Just wondering, not trying to split hair.

Francis Corvin

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Michael Jahn"

Sun Mar 9, 2008 5:25 pm (PDT)

Hi Fancis,

Following your logic, all CMYK files are also "displayed" in RGB.

And, while it is a fact that Photoshop does its best to convert "numbers" through a 'working space' and additionally, can be set up to do this using a specifc CMM and a specific set of display profiles and (in some cases) - send this who dta stream through and output intent Device profile - well, while what is sent to the monitor is indeed RGB data, when you are doing the 'math' or invoking algorythms, it is definely adjusting the data in the mode the image is in at that time (RGB, CMYK or LAB)

So, not to put words in Dans mouth here, but I believe the "display adapter" is past all this, as photoshops computations do not deliver data directly to any 'display adapter' - but to some system level video driver outside of Photoshops control.

Hope this helps

Michael Jahn

Jahn & Associates

PDF Color Conversion Specialist

1824 North Garvin Avenue

Simi Valley

California 93065

Office: (805) 527 8130

Cell: (805) 217 6741

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Best

Sun Mar 9, 2008 5:26 pm (PDT)

Let's be clear what's happening here. The mode change from Lab to RGB is a simple colorimetric conversion, namely these imaginary colours will be clipped to the outside boundaries of destination RGB space. And because the RGB space is a simple matrix profile, you don't get any of the CIECAM02 (or whatever) advances in gamut mapping so Photoshop's implementation will likely be pretty crude. Hence the resultant hue shifts we see and a/b values all over the map. Further, near imaginary colours in Lab will be mapped to the same colour in the destination space so rather than preserving colour differentiation at the tonal extremes, you're losing it.

I understand the desire to maximize colour content rather than letting these highlights blow it away. The colour information is still there with a luminosity layer stack, but masked by the luminosity above (as you've described). So what's required is a two-step edit to juggle both luminosity and colour to achieve the outcome you want. (The luminosity blend guarantees that hue will be preserved.) Unlike Lab you're not working blind and relying on the side-effect of the colorimetric conversion above.

There has been years of work in formulating and implementing Lobster 2's chromaticity extraction (its "unique brightness order") which I've only just started to get my head around ... especially for hue corrections ... but early experiences with this have been positive. Its foundations are very close to Lab actually: just look at the distribution in the chromaticity channels. I think it warrants much further investigation to highlight its practicality or otherwise.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Best

Mon Mar 10, 2008 9:34 am (PDT)

I should add that converting from Lab to a small intermediary RGB space doesn't seem like a good idea because the gamut boundaries are unlikely to match that of the output (printer) space. So you end up with colours outside that have to be moved again, or you've lost differentiation that the output could carry. But I understand the intention in all this. Gamut mapping's roll is to make the best choices for a given image colour, even if imaginary. It's being used as a handy assist here, but targeting the wrong space IMHO. If you were going from Lab directly to the output space (a single pass and using more sophisticated mapping) it would be a different story.

Please excuse my rambling, I hadn't thought this through before. I'd appreciate it if anyone can point out holes in my thinking.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Michael Jahn" l

Mon Mar 10, 2008 3:27 pm (PDT)

@ Stephen

Well, that would assume that the printer might have a small Gamut, as in SWOP Magazing printing or publication printing environment (like a Newspaper)

But there are many Flexography projects that enable one to print with 12 colors. I think this is where the applications fall short - and while I would suggest that most images captured with even the finest digital cameras will be able to be reproduced with 6 or 7 color inkjets with some wide gamut profile conversions, when one gets involved with adding special colors to images - like "Barbie Pink" - where the image will be using a Pantone spot color as a touch plate, for example - well, this is why I think this discussion is both useful and more real world than some might feel it is here on the forum.

How do I capture very saturated colors and retain them ? What is the best camera set up and production workflow when we have a scene that contains fabric that may not be captured accurately (like a florescent Orange Dress) and still retain shape - ?

Michael Jahn

Jahn & Associates

PDF Color Conversion Specialist

1824 North Garvin Avenue

Simi Valley

California 93065

Office: (805) 527 8130

Cell: (805) 217 6741

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Henry Davis

Mon Mar 10, 2008 4:52 pm (PDT)

On Mar 10, 2008, at 1:39 PM, Michael Jahn wrote:

How do I capture very saturated colors and retain them ? What is

the best camera set up and production workflow when we have a scene that

contains fabric that may not be captured accurately (like a florescent

Orange Dress) and still retain shape - ?

In studio settings, you might consider profiling each exposure set-up using a custom target. Even if accurately captured, the problems associated with reproduction remain. There are so many specialty colors possible, and such a mind-numbing number of possible unique combinations of them for any given project. My speculation is that this is the reason there has not been a better solution on the market thus far.

I'll leave it to others on the list to help sort out solutions posed by the unique spectral qualities of fabrics. Sometimes a non- standard approach to lighting can help capture certain colors more accurately.

I'll also leave it to qualified list members to offer you an explanation of the colorimetric difficulties and shortcomings of profiling.

Henry Davis

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Darren Bernaerdt"

Tue Mar 11, 2008 6:07 am (PDT)

The example is instructive and deceiving at the same time. We often have

discussed photographs of red flowers in these context. This image, however,

is not a photograph, at least not a photograph of natural red flowers.

Instead, the original source is a *painting* of red tulips.

Dan,

And just when you think it's really beginning to sink in.you realize there are additional cans of worms to be opened and pondered.

Guess it's time to re-think the example, although this has certainly again brought to bear the concept of "what does Photoshop create" when the color can not exist in RGB?

This is a good point but I think we are a few years away from raw converters

with the needed capabilities. It's clear that there is a growing awareness

of the importance of luminosity moves, but I think we also all realize that channel

blending is if anything more important in establishing better luminosity

than curves are. At least two current raw converters, and probably more, allow a

true luminosity-channel curve with a separate color adjustment. That's a

start, but to match what's available in Photoshop we'd need the ability to apply

channel curves in luminosity and in color modes and to interpret the results

in LAB rather than RGB; we'd need the ability to blend not just the RGB

channels with one another but to construct various types of supplementary

channels and blend with them; and we'd need some pretty fancy color

maneuverability.

Curious what the two raw converters are that you're referencing. I've done a bit of digging and could only find "Raw Therapee" and "Raw Deveoper". Are there others?

Darren Bernaerdt

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Darren Bernaerdt"

Tue Mar 11, 2008 6:07 am (PDT)

Stephen,

I was working with a RAW file that I shot that had some gamut issues due to a very saturated sky captured during a sunrise. I found it very useful to use the soft proofing and gamut warning feature in Photoshop to get a visual cue that I was dealing with an "imaginary color" while in LAB. It's one of those features that I tend to forget about and never originally used it as a "RGB" gamut warning.

If you set View>Proof Setup>Custom to your working RGB space (looks like sRGB in the case of your example), you can then use View>Gamut Warning to get a "heads up" that there is an imaginary color while working LAB. In some cases this might be valuable to get a sense of how far to make adjustments in LAB, other times it's just a helpful reminder even though we wish to make use of imaginary colors.

Darren Bernaerdt

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "George Machen"

Tue Mar 11, 2008 6:07 am (PDT)

A few years ago at a photo studio in High Point, NC (a traditional world market leader in textile & furniture manufacturing, albeit many firms have been fleeing overseas of late), I kept being asked repeatedly to change the color of furniture fabric shots to match a sample provided me. But a sample of the actual fabric photographed, not a sample of a different color to which they wanted to change from what was shot! I asked over and over why the photographers didn't include in some of the shots a grayscale card and color-checker patches to get it right in the first place, which seemed to me to fall on deaf ears. Finally, a sales rep informed me that they tried doing so at first years ago, but quickly abandoned it, because the dyes in the fabrics interacted with the studio lights, invalidating the "calibration" and changing the colors, so every shot had to be color corrected.

- George Machen

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Henry Davis

Tue Mar 11, 2008 11:01 am (PDT)

Their experience led them to the realization that matching the color reference could ruin the color of the real subject in the scene. This is often the case, and is one of the reasons that profiling should be approached with some reality checks. Like fabric, art paintings can be ruined by matching the target. Targets can be useful as a guide, but matching the subject is the goal. My suggestion of profiling each exposure set-up was meant more for establishing a baseline.

Your claim that the subject matter could "invalidate the calibration" is well taken.

Henry Davis

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Ron Kelly

Tue Mar 11, 2008 11:02 am (PDT)

George:

I was an architectural photographer and I worked with interior designers for years. They could not understand why the fabrics they designed with could often not be represented accurately on print materials of the time. They always thought it was excuse making on the photographers part.

Flourescing was a big problem I came to learn. The thing was, the flourescing was outside the visual spectrum, but not outside the films spectrum. No amount of filtering on the camera could fix it, and the spaces were too large to control the lighting in completely.

Trying to get your clients to understand this without a PhD dissertation, and even then, was almost hopeless.

I don't do that work any more, and I don't miss it.

Good luck,

Ron Kelly

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Best

Tue Mar 11, 2008 6:18 pm (PDT)

"Darren Bernaerdt" wrote:

I was working with a RAW file that I shot that had some gamut issues due to

a very saturated sky captured during a sunrise.

I think it's likely that the gamut issues aren't so much due to the original scene, but introduced by the RAW conversion itself.

Going back to your flower painting comparison, it's somewhat misleading to apply the same curve via a number of means and ask which is "best". For a start, the image's gamma won't match that of Lab Lightness (unless you've converted it beforehand). I think a better approach is to have a visual objective and come up with an individual curve for each method that achieves (as closely as possible) that objective then look at the side effects.

I'm still strugglingly here, but according to Dan a Lab Lightness move is better because the conversion back to RGB preserves more of the "colour". In reality though, it's trading some of that lightness increase to bring it back into gamut. So if you ask for a lightness boost of 10 units, maybe you're only getting 6. This contrasts with luminosity moves where you get exactly what you ask for. Hence they can't be compared simply.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Darren Bernaerdt"

Wed Mar 12, 2008 4:37 am (PDT)

George/Henry,

I think we are discussing a couple things here. One, is that our personal preferences override our "perceived reality" and the second is that some fabrics or materials don't photograph the same way we see them.

http: //www.kodak.com/global/en/professional/support/techPubs/e73/e73.jhtml

Changing to a different light source and/or filtering the camera can be effective. Or just fixing it in post-production.

Darren Bernaerdt

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Darren Bernaerdt"

Wed Mar 12, 2008 4:37 am (PDT)

Stephen,

I think it's likely that the gamut issues aren't so much due to the original

scene, but introduced by the RAW conversion itself.

But how do we measure that? By my memory? (I wouldn't trust that as my RAW conversion is an emotional response since I'm the artist.)

I DO agree that the RAW conversion is carrying a certain amount of blame. This was the thrust behind my comparison with the painting. I've been disappointed with the fluorescent green grass created by several raw converters when you apply a "S" curve to increase the contrast (the "Strong Contrast" curve in ACR comes to mind.)

Going back to your flower painting comparison, it's somewhat misleading to

apply the same curve via a number of means and ask which is "best". For a start, the image's gamma won't match that of Lab Lightness (unless you've converted it beforehand). I think a better approach is to have a visual objective and come up

\with an individual curve for each method that achieves (as closely as possible) that objective then look at the side effects.

Right in the intro I state "The purpose of this page is not to state that one method is better than the other, but rather to illustrate the various ways of applying a curve as the result is often different." I don't ask the viewer nor suggest that one method is better than the other. They each produce different results. Your approach sounds interesting as well. Do you have an image in mind to demonstrate this suggestion?

Darren Bernaerdt

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Ron Kelly

Wed Mar 12, 2008 4:34 pm (PDT)

Darren:

Have to disagree with you on your first point.

When you have a sample of the fabric, or you're standing in the space of the area you photographed and you can see, even if you are not the most sophisticated of color perceivers, that there is not even a close resemblance between what you can produce in print (before heroic measures in the digital age) and the source, it's not "perceived reality". The things don't match, and are not even close to matching.

If I was a dedicated color consultant, I would say it's "delta 480-900".

"some fabrics or materials don't photograph the same way we see them." is the answer, and perceived reality doesn't have anything to do with it.

A small point perhaps, but significant to some of us.

Ron Kelly

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Lee Clawson

Wed Mar 12, 2008 4:34 pm (PDT)

Darren,

This paper (from Kodak) is about the design of the dye layers film. Do you suggest that the same limitations (with dye layers) are being carried over into today's digital camera sensors ??

Lee

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Best

Wed Mar 12, 2008 8:33 pm (PDT)

"Darren Bernaerdt" wrote:

I DO agree that the RAW conversion is carrying a certain amount of blame.

This was the thrust behind my comparison with the painting. I've been

disappointed with the fluorescent green grass created by several raw

converters when you apply a "S" curve to increase the contrast (the "Strong

Contrast" curve in ACR comes to mind.)

Contrast moves in ACR just bump saturation. Check out these papers I referenced earlier:

http: //www.21stcenturyshoebox.com/essays/color_reproduction.html

http: //www.21stcenturyshoebox.com/essays/scenereferredworkflow.html

Pair the workflow in the latter paper with luminosity layer moves in Photoshop and you'll have control over the saturation you want (and in which channels you want) rather than it being a side effect beyond your control. I'm with Dan on the limitations of ACR (and Lightroom). Pushing clunky sliders around in an attempt to counter unwanted effects isn't the way to go IMHO.

Right in the intro I state "The purpose of this page is not to state that

one method is better than the other, but rather to illustrate the various

ways of applying a curve as the result is often different." I don't ask the

viewer nor suggest that one method is better than the other. They each

produce different results. Your approach sounds interesting as well. Do you

have an image in mind to demonstrate this suggestion?

This is something you can do with any of your own images, though synthetic images (different hues etc) and colour sample points can highlight side effects.

I've been using luminosity layer moves for my scans for over a year now with great success. I also use custom RGB spaces based on L*. The tonal curves I come up with aren't transferable to other methods. I find it more natural to think in terms of separate tonal and colour adjustments which is what initially attracted me to Lab. Note that most of my work is fine tuning rather than drastic colour correction/recovery.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Dan Margulis

Wed Mar 12, 2008 8:33 pm (PDT)

Stephen Best writes,

Let's be clear what's happening here. The mode change from Lab to RGB is

a simple colorimetric conversion, namely these imaginary colours will be clipped to

the outside boundaries of destination RGB space.

Those boundaries, however, are enormous. Usually when we feed an out-of-gamut color to the destination space at least it's somewhat close to what's available. Here, the color being called for probably doesn't exist at all, and if it does it's so monstrously out of the gamut of typical RGBs that the only thing we can say for sure is that the red value will be 255r. The other two each have at least a 50-point tolerance. So there are thousands of credible possibilities for this conversion. "Colorimetric" is a questionable description of what happens here. "Wild guess" or "random generator color" is more like it.

And because the RGB space is a simple matrix profile, you don't get any of the CIECAM02 (or whatever) advances in gamut mapping so Photoshop's implementation will likely be pretty crude. Hence the resultant hue shifts we see and a/b values all over the map.

Nobody cares. The important thing is that the flower has to be colorful. Hue shifts won't bother anybody. The loss of the sensation of colorfulness when the flower is lightened in any RGB variant, that's a problem.

Further, near imaginary colours in Lab will be

mapped to the same colour in the destination space so rather than

preserving colour differentiation at the tonal extremes, you're losing it.

This effect occurs in RGB>CMYK and RGB>RGB conversions, not LAB>RGB. If there is differentiation in the LAB file there will be differentiation in the RGB after conversion, no matter how far out of gamut these colors are.

I understand the desire to maximize colour content rather than letting these

highlights blow it away. The colour information is still there with a luminosity layer

stack, but masked by the luminosity above (as you've described). So what's required is a two-step edit to juggle both luminosity and colour to achieve the outcome you want.

Somewhat easier said than done. The idea is to lighten non-reds as the curve normally would, but to restrict the lightening of the lightest reds, yet gradually allow the S-curve to have its impact as the flowers get darker. Doing this seems to require a rather complex mask. As with most tasks in Photoshop, there's always a way if we have the energy. If I were asked to approximately match the result of the L curve on these flowers, but to do it in RGB, here's the likely strategy.

1) Make a copy of the image and convert to LAB. Save the resultant A channel as an alpha channel somewhere.

2) To this A channel, Edit: Fill>50% gray, but mode= Lighten (thus being sure that all things neutral or more green than magenta are 50% gray).

3) Auto Levels to this channel.

4) Heavy Gaussian blur.

5) Save a copy of the blue channel of RGB as a second alpha channel. Apply a linear curve that blows out the lightest portion of the flower, disregarding what may be happening elsewhere.

6) Apply Image or Calculations to merge the two alpha channels in Multiply mode.

7) Use the resulting merged channel as the layer mask on an adjustment layer, which could be Selective Color, Hue/Sat, Curves, or a few other things. Darken the image through the mask.

8) Create a luminosity layer a la Lobster from the resulting file.

9) Apply the S-curve.

This procedure, while effective, seems to be not as efficient as the alternative:

1) Convert the file to LAB, apply the S curve to the L channel, and convert back.

Unlike Lab you're not working blind and relying on

the side-effect of the colorimetric conversion above.

That argument is very effective when speaking of an RGB>CMYK conversion. We would *never* want to convert wildly out-of-gamut colors blindly. We would *never* intentionally exaggerate the color in RGB to make it even further out of the CMYK gamut.

But here, that conventional logic doesn't apply. We're pushing the envelope. It doesn't seem to make sense to force Photoshop to take a wild guess as to the color we want--*unless* we believe that the wild guess, however inaccurate, will give a better result than what we could otherwise get. That situation would never occur RGB>CMYK, but it does happen here.

We all realize, I think, that there has been a big trend recently among knowledgeable users to treat color and contrast as separate items. Lobster is an example of that type of thinking, and it appears to be a good one. All such methods, however, rely heavily on working in Photoshop's Luminosity and Color modes, which at present have a limitation.

That limitation is that when we give Photoshop separate instructions as to color and contrast, the two instructions may be contradictory, impossible to fulfill simultaneously. At present, Photoshop treats the contrast instructions as being paramount, so it honors them while consigning to color whatever crumbs may be left over.

That is probably a better way than deciding that the color is to be honored at all costs, but they're both bad ways. Ideally, a mode could be set up that computes the file both ways and allows the user to slide between the two. If that were ever done, my whole chapter on imaginary colors could be ripped out of the book and discarded because, as you note, it isn't as accurate as one would like.

There has been years of work in formulating and implementing Lobster 2's

chromaticity extraction (its "unique brightness order") which I've only just started to get

my head around ... especially for hue corrections ... but early experiences with this

have been positive. Its foundations are very close to Lab actually: just look at the

distribution in the chromaticity channels. I think it warrants much further investigation to

highlight its practicality or otherwise.

Lobster is one of many variants of working in a hue-saturation-luminosity model. This is a seriously effective way of working and does indeed share a lot of characteristics with LAB. In fact, in two editions of PP, I titled three consecutive chapters as follows: "RGB Is CMY", "HSB Is LAB", and "All Colorspaces Are One".

The practicality of working in HSB (or whatever the variant is called) is well known; it was so well established in the professional community that Photoshop actually had a full-blown HSB mode and a lot of experts were working in it. It was unfortunately removed effective with Photoshop 3, and without Photoshop's support, it fell from favor, but it didn't deserve to.

Dan Margulis

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "dbernaerdt"

Wed Mar 12, 2008 11:52 pm (PDT)

Ron,

I'm not saying that having a sample (fabric or otherwise) in front of a viewer and comparing it to a proof (on-screen or printed) is subject to a "perceived reality". It either matches or it doesn't, however who is the judge? The client? The photographer? Let's hope everyone has "perfect" color perception. (I'm not trying to be sarcastic here - it's from experience where I've been left wondering about my client's color perception after listening to their comments while evaluating a proof.)

The point I was trying to make was not the situation where an image capture has to match a particular sample (ie, the fabric scenario), but rather when there is artistic intent. A match according to a target may not produce a photograph that we feel conveys the necessary visual message.

Darren Bernaerdt

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "dbernaerdt"

Wed Mar 12, 2008 11:52 pm (PDT)

Lee,

I believe the section on optical brighteners and anomalous reflectance are still very relevant. It would be wonderful if digital sensors were perfectly matched to our eyes in terms of spectral sensitivity, however this is not the case. (although the on-chip filtering has gotten much, much better)

I also feel we can't ignore the fact that taking the same raw file and processing it through a variety of converters will produce a different result. Which software's rendering is "correct"?

Usually, I don't do much photography that requires a perfect match to the original subject. However, a recent job involved photographing six paintings. Even with a Colorchecker in the first shot that I used to dial in the WB and then to check the neutrality from highlight to shadow, I still had three rounds of color tweaking. Some of the hues in the paintings were reproduced quite accurately, but others were noticeably off.

Darren Bernaerdt

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Best

Wed Mar 12, 2008 11:52 pm (PDT)

"Dan Margulis" wrote:

"Colorimetric" is a questionable description of what

happens here. "Wild guess" or "random generator color" is more like it.

The moves may be large enough to make it seem so, but the mechanism is still technically colorimetric. Photoshop doesn't just throw the colours in the air, it calls on the CMM to do a simple conversion. There's no perceptual tables in (your typical) RGB working space, so it has to be colorimetric. If you route the conversion from Lab through ProPhoto RGB to sRGB you'll get the same results (rounding aside) ... at least for colours that ProPhoto RGB can contain.

That limitation is that when we give Photoshop separate instructions as to

color and contrast, the two instructions may be contradictory, impossible to

fulfill simultaneously. At present, Photoshop treats the contrast instructions as

being paramount, so it honors them while consigning to color whatever

crumbs may be left over.

But this is no different to Lab. You've created coordinates that are out of gamut and it has to trade some of the lightness increase to bring the coordinates back in gamut. The Lab lightness and chroma values are "impossible to fill simultaneously". If you're using a luminosity layer, what you ask for is what you get. But if it lightens the highlight colours too much, you ask for less.

What I think your Lab procedure offers that you find attractive is essentially compression at the gamut boundaries. Compression of highlights is an essential part of adapting the image to the modest contrast range of the output medium. I'm a bit wary though of the two passes of the gamut mapping you get with Lab->working RGB and working RGB>output RGB. I also think you've downplayed the critical role (spelt correctly this time) of the intermediately RGB space itself. Change the intermediary space and you'll get different compression. Gamut mapping also presupposes that you have an output medium in mind, but there's a tendency these days to make the master file as flexibile as possible with regards to output.

Irrespective of the methods I think there's more in common and the aims are the same. The way you get there is just different. I'm prepared to trade the assist of semi-automated gamut compression for fine control and being able to retain the layer stack for future edits ... which staying in RGB allows. I'm also after a methodology that is applicable to any image.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Stephen Best"

Thu Mar 13, 2008 6:56 am (PDT)

"Dan Margulis" wrote:

If there is differentiation in the LAB file there will be differentiation in the RGB

after conversion, no matter how far out of gamut these colors are.

Try converting the following Lab coordinates to sRGB (8 bits/channel):

97 -73 -23

96 -69 -23

98 -58 -23

85 -95 -24

89 -84 -24

91 -73 -25

95 -108 -23

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Ron Kelly

Thu Mar 13, 2008 6:56 am (PDT)

Darren:

I was merely pointing out that, for example, flourescing due to optical brighteners and the like being used in the manufacture of fabrics means that it's not a subtle difference.

When this happens it's far and away above tolerances for a "judicious match'" which still might be contested by hair splitters.

The particular case that drove me around the bend was a burgundy fabric; it was always various shades of brown. There are many other fabrics/materials that would suggest to me that it isn't related to what part of the visible spectrum you're concerned with but the variance between human and camera/reproduction technology.

The only fix for this problem is massive heroic digital manipulation, post capture. Or, as I chose, career change.

Ron Kelly

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "George Machen"

Thu Mar 13, 2008 11:49 am (PDT)

I went through your exercise, creating all seven patches in one Lab document, and upon converting to sRGB, all of the patches were 255 R, but the B & G were all different. So all seven patches' colors were differentiated, both visually and numerically. (Am I missing your point?)

- George Machen

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "J Walton"

Thu Mar 13, 2008 11:49 am (PDT)

OK, I just converted those coordinates and they seemed to convert just fine, except that the first two numbers pretty much blend together. Should I be looking for something in particular?

J Walton

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Les De Moss"

Thu Mar 13, 2008 11:49 am (PDT)

Hummm....

97 -73 -23 0-255-255

96 -69 -23 0-255-255

98 -58 -23 0-255-255

85 -95 -24 0-255-255

89 -84 -24 0-255-255

91 -73 -25 0-255-255

95 -108 -23 0-255-255

Les De Moss

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Rick Gordon"

Thu Mar 13, 2008 1:34 pm (PDT)

Very interesting. If, before the conversion, you turn on the checkbox for "Desaturate Monitor Colors By" you can see the differences evaporate.

Rick Gordon

___________________________________________________

RICK GORDON

EMERALD VALLEY GRAPHICS AND CONSULTING

___________________________________________________

WWW: http://www.shelterpub.com

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "George Machen"

Thu Mar 13, 2008 1:34 pm (PDT)

Correction - my mistake - I thought your Lab colors had listed positive ab values throughout and had used dashes instead of commas to separate the values in each of your seven 3-tuples. (Now I really appreciate why Dan puts negative ab values within parentheses instead of minus signs!) Plus, we previously were talking about a painting of red flowers, so I further lulled myself into inferring you meant positive ab values. Sorry.

Yes indeedy, repeating your exercise with the correct ab values negative throughout yields (0 R, 255 G, 255 B) for all seven. No differentiation.

But the results for my positive ab values as I first reported stand, with the RGB patches all highly differentiated as variations of red. I wonder why there's no symmetry in this behavior. On further reflection, perhaps these blues (more like cyans or teals, actually) are running up against "crooked" edges of the Lab & sRGB gamut shapes such that the conversions of these close colors happen to all coalesce to pure cyan. The two gamuts are not spherical, after all!

Aside from this happenstance anomaly, I think Dan nevertheless still is correct that such variation in principle otherwise must occur when converting from Lab: if the gamuts were spherical, or more generally, symmetrical, the variation would occur for all colors, no?

But now we know that there's a (trivial exception) booby-trap waiting to ensnare us with certain colors.

- George Machen

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: "Rick Gordon"

Thu Mar 13, 2008 1:34 pm (PDT)

Are you (and George Machen) using all negative values for the a and b values? Like Les De Moss, I find them all mapping to 0,255,255.

Rick Gordon

___________________________________________________

RICK GORDON

EMERALD VALLEY GRAPHICS AND CONSULTING

___________________________________________________

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Best

Thu Mar 13, 2008 1:34 pm (PDT)

The a and b have minus values so you'd expect something low in red. Actually, none.

Lab to RGB conversion will map in-gamut colours as is, and those out of gamut to the gamut

boundaries. Because you're mapping the volume of out-of-gamut colours to a surface, you'd

expect substantial losses of individual colours.

Note that this isn't meant to discredit Dan's methods (for which substantial successes have

been demonstrated) but more to understand the mechanism involved.

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Best

Fri Mar 14, 2008 5:36 am (PDT)

Just to show that I'm not singling out a problem hue, try these Lab values:

47 114 122

66 104 122

84 120 122

62 107 118

59 86 118

The losses will be equal across the spectrum. Anyone that wants to play around with this can download the file I created below, set soft proof to sRGB (or whatever space) and change the second info readout to Proof Color.

http: //www.macquarieeditions.com.au/misc/Lab16Million.tif

Stephen Best

Macquarie Editions

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Dan Margulis

Fri Mar 14, 2008 6:25 am (PDT)

Stephen Best writes,

Just to show that I'm not singling out a problem hue, try these Lab values:

47 114 122

66 104 122

84 120 122

62 107 118

59 86 118

Stephen, your posts have been highly constructive and much appreciated. However, the list has a long and annoying history of individuals attempting to prove points about the LAB>RGB conversion by means of analysis of extreme values supported by a passle of worthless histograms and computer- generated gradients.

The thread is threatening to get out of hand, so let me intervene with some suggested ground rules. First, for all those posting about LAB, please remember that because AB values can be either positive or negative, there is the potential for confusion when citing them. This just happened here. Stephen posted some numbers that he intended to represent negative AB values, but because what he intended as a minus sign was interpreted as a hyphen by others, some thought he was speaking of positive values. I'd suggest using the form 40L(30)a20b or some other completely unambiguous notation.

The numbers shown at the top of the file are not of interest because nothing in the method I was discussing can produce anything remotely similar to them. The use of curves to the L channel rather than a luminosity curve in RGB attempts to *preserve* the AB values found in the original, never to *increase* them.

It follows that any numbers that could never have been found in the sRGB original have no relevance to the discussion. As the maximum (255r0g0b) sRGB red equates to 54L81a70b, it is not possible for the subsequent LAB file to contain any AB values higher than these; in fact they would have to be substantially lower because otherwise the sRGB file would have no detail in the affected area.

Similarly, in Stephen's original presentation of numbers, the colors chosen were cyans far too colorful to have originated in sRGB, which is notoriously narrow in that color range. However, this sRGB limitation has little practical importance because extreme cyans are rare in photographs. In PP5E there's an image of a glacier-fed Alpine lake that I identified as being the most cyan object I had found in five years of looking, excluding lighter cyans that are not printable in CMYK. The typical value of this object was 68L(29)a(25)b. Any discussion of how an L curve would affect cyans shouldn't address AB values more intense than that.

The actual original values in Darren's flower image were 66L55a12b. My statement was that detail would be retained as the L value was lightened, and that statement is backed up by the visual appearance of Darren's example. Any attempt to counter this should really use colors in this range. Doubling the A and quintupling the B to see what happens yields the result that all RGB channels are driven to their extremes, whereupon detail disappears. In real life, as a couple of members pointed out, only *one* channel loses detail, leaving two to carry the ball. In Darren's example, the method drives everything to 255r, but there's detail elsewhere.

The losses will be equal across the spectrum. Anyone

that wants to play around with this can

download the file I created below, set soft proof to sRGB (or whatever

space) and change the second info readout to Proof Color.

I have deleted the link because it refers to a computer-generated graphic, and it is my view that computer-generated graphics are completely worthless in discussing conversions of photographs. They can be useful in explaining effects that are readily visible in the photograph, but as a standalone prediction of what will occur they are of no value.

In PP5E I show several examples of how detail is lost when an RGB file is converted to CMYK when a substantial area is out of CMYK gamut. The method is to show side-by-side examples of images that have been slightly desaturated prior to the conversion as opposed to converted directly, and the results are unmistakable. At the request of beta readers I then added computer-generated graphics to assist in understanding why the fully saturated images looked bad. But the images demosntrating a loss have to come first.

It is easy enough to find images to test the concept. The initial paragraph indicates a desire to analyze reds; fair enough. A valid example would be the following:

1) As noted above, the most extreme red found in sRGB is 255r0g0b, equating to 54L81a70b. There cannot be a large area of this value as otherwise it would be completely flat. We would need to reduce the A and B values by, say, 15% apiece to account for the image having detail. So, a typical start point might be 54L70a60b, which is 240r52g26b. This might be a valid color for a carnation.

2) Lightening the L value by as much as 20 points is unthinkable, but for the sake of argument we could follow through. If we attempt to achieve a value of 74L by working in RGB/Luminosity, the color cannot be held because it would be out of the sRGB gamut, since the red channel cannot be increased beyond 255r. Instead, we get 255r147g131b, which equates to 74L40a27b.

3) If the operation is performed in the L channel of LAB, the result is 74a70a60b. Of course, this color cannot exist in sRGB, but if converted, it produces a substantially different result than #2. We get 255r115g75b, which equates to the darker, redder 66L53a49b.

In a picture of a carnation, we would likely, although not necessarily, prefer the LAB version as being more faithful to the colorful feel. Unless, of course, there's some major loss in detail such as that suggested by Stephen. Fortunately, that's easy to test. All we have to do is look at the pictures side by side.

Dan Margulis

___________________________________________________________________________

Re: "accepted wisdom" - RGB Luminosity

Posted by: Stephen Best

Fri Mar 14, 2008 8:18 am (PDT)

"Dan Margulis" wrote:

Stephen, your posts have been highly constructive and much appreciated.

However, the list has a long and annoying history of individuals attempting to

prove points about the LAB>RGB conversion by means of analysis of extreme

values supported by a passle of worthless histograms and computer-

generated gradients.

I was only responding to your surprising assertion that all colours pushed out of gamut will retain differentiation. This isn't the case, as demonstrated. And it won't be for MOST colours pushed out of gamut, not just isolated examples. But I take your point that synthetic examples can get pretty tedious. My interest is in understanding what happens to these out-of-gamut colours. Theory says that they will be mapped to the gamut boundaries and this is confirmed by experimentation. I've never found that an understanding of Photoshop and colour management underpinnings have gotten in the way of working on real world images. In fact the reverse is true.

As for such lightness vs luminosity moves, I've already made the point that the curves aren't comparable because they're doing different things and likely working with different gammas. Side by side comparisons only illuminate differences. I feel a more thorough examination is required to evaluate the strengths (or otherwise) of any new workflow. Either there's interest here or there's not.

Stephen Best

Macquarie Editions

Contact request form

Receive Schedule
and Pricing updates.

If you let us know how to contact you, we will enter you into our monthly drawing for a free 2-day class (A $895 value).

Get free video training
Get free tips, tricks and shortcuts
Get special sale pricing and free seminar invitations

Logo_small

Teach for us

Sterling Ledet & Associates, Inc. 4100 Perimeter Park South Atlanta, GA 30341

work sales@ledet.com work administration@ledet.com work webmaster@ledet.com

P work 770.414.5007 P work 877.819.2665 F fax 312.896.9094

Authorized Training Provider

Receive Schedule and Pricing updates.

Receive Schedule
and Pricing updates.