Untitled Document

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/

____________________________________________________________________________

Chris Broadhurst wrote:

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?

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.

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.

____________________________________________________________________________

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

____________________________________________________________________________

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:

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.

____________________________________________________________________________

Stephen writes:

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

____________________________________________________________________________

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

____________________________________________________________________________

John Bongiovanni wrote:

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.

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

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.

___________________________________________________________________________

Stephen Marsh wrote:

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

___________________________________________________________________________

Bob Kenedi wrote:

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.

___________________________________________________________________________

Bob Kenedi writes,

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

___________________________________________________________________________

Stephen writes,

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

___________________________________________________________________________ .

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.

___________________________________________________________________________

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

___________________________________________________________________________

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.

___________________________________________________________________________

Howard Smith wrote:

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

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.

___________________________________________________________________________

Prior to taping my latest sessions, I wrote,

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

___________________________________________________________________________

Dan Margulis wrote:

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.

___________________________________________________________________________ .

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

___________________________________________________________________________

Dave Larson wrote:

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.

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

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

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

___________________________________________________________________________

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

___________________________________________________________________________

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.

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

John Robinson

Designer

___________________________________________________________________________

.

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

___________________________________________________________________________

John Robinson wrote:

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.

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.

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

___________________________________________________________________________ .

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

___________________________________________________________________________ .

.

Russell Cowgill wrote:

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!

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

___________________________________________________________________________ .

Stephen writes,

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

___________________________________________________________________________ .

.

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

Wai-hong Chung

___________________________________________________________________________ .

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

___________________________________________________________________________ .

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

___________________________________________________________________________ .

.

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

___________________________________________________________________________ .

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

___________________________________________________________________________ .

.

My own feelings are similar to Andy's. There has been a lot of information posted, none accompanied by visual examples of the advantages