RetouchPRO

Go Back   RetouchPRO > Technique > Photo Retouching
Register Blogs FAQ Site Nav Search Today's Posts Mark Forums Read Chat Room


Photo Retouching "Improving" photos, post-production, correction, etc.

Reply
 
Thread Tools
  #1  
Old 09-06-2010, 05:58 PM
Member
 
Join Date: Nov 2009
Posts: 89
L*a*b* question: why can't it be simulated in RGB?

The big benefit I see of Lab is that the luminance is not tied to the color. So you can adjust saturation without clipping the colors as fast. Or darken an image without desaturating the colors as fast.

But why can't adjustments be made in RGB with blending modes such as "color" or "luminosity" to simulate that type of isolated adjustment?
Reply With Quote
  #2  
Old 09-06-2010, 06:14 PM
Moderator
Patron
 
Join Date: Dec 2005
Posts: 2,900
Re: L*a*b* question: why can't it be simulated in

You can perform a couple of moves in RGB to emulate certain effects of LAB but LAB is a very different color model and you can not accomplish most of what LAB does in RGB.
Moving back and forth from RGB to LAB is not visibly destructive unless you do it 10,000 times on the same image. The same is not true of other color spaces, particularly CMYK.
LAB has some unique advantages for certain processes and I have done complete high end retouches from start to finish completely in LAB. I especially like it when doing D&B with separate Curve Adj layers because after you have adjusted the luminosity, you add a color correction adj layer and it will be color exact which is not the case in RGB.
And for retouchers who would like to mix RGB and LAB in the same workflow, nested smart object in PS allow you to do that effortlessly and seamlessly.
Regards, Murray
Reply With Quote
  #3  
Old 09-07-2010, 02:13 PM
andrewrodney's Avatar
RetouchPRO LIVE Guest Artist
 
Join Date: May 2010
Location: Santa Fe
Posts: 530
Re: L*a*b* question: why can't it be simulated in

You can (more or less) without the time and data damage of converting into and out of Lab. You use the Luminance Blend Mode. For example, the idea of converting to Lab to sharpen data is so 20th century. Use the USM in the RGB color space, then Fade using Luminosity giving you the benefit of only dealing with luminance data AND providing you another control, opacity.

Quote:
Moving back and forth from RGB to LAB is not visibly destructive unless you do it 10,000 times on the same image.
Its destructive in 8-bit and depending on the color space. Not a good idea. Every time a conversion to LAB is produced, the rounding errors and severe gamut mismatch between the two spaces can account for data loss, known as quantization errors. The amount of data loss depends on the original gamut size and gamma of the working space. For example, if the working space is Adobe RGB, which has 256 values available, converting to 8- bit LAB reduces the data down to 234 levels for neutrals. The net result is a loss of 22 levels. Doing the same conversions from ProPhoto RGB reduces the data to only 225 values, producing a loss of 31 levels. If you really must convert from RGB to Lab, do so in a high bit file (what Photoshop calls 16-bit).
Reply With Quote
  #4  
Old 09-07-2010, 03:00 PM
Chain's Avatar
Senior Member
 
Join Date: May 2009
Location: Oslo, Norway
Posts: 482
Re: L*a*b* question: why can't it be simulated in

As far as I see it there is nothing during normal image adjustment and retouching that requires LAB. Also worth noting is that many tools only work in RGB.

LAB might have a high gamut; well so does RGB - depending on your profile - but a large gamut is usually doing more harm than good if it is a lot larger than any of your monitors and printers can display (good monitors struggle to display more than ~98% of AdobeRGB). Colors outside this. Well. They are not visible (since they cannot be displayed); and your camera probably didn't capture them either. Those bits are better spent on the important data in your image to reduce banding etc. If you DO work in a high gamut color space, you need (as andrewrodney said) work in 16 bit to avoid the worst issues. Converting to LAB and back does incur a little loss (although it is minor in 16 bit mode).

Some say that LAB is great because you can adjust luminosity separate from color. Well you can do that perfectly well in RGB color mode if you know how to use Photoshop. Luminosity blend mode; as well as hue/saturation/color blend modes let you work with colors and luminosity separately.
Example: a curves adjustment set to Luminosity only affects the Luminosity of the image - not the color/saturation. Likewise if blending is set to color it will affect hue/saturation but not luminosity.

Sure; you CAN perform a high end retouch in LAB with great results. You could also do it in CMYK. Or HSL. With one hand on your back. But why would you? I see a bunch of disadvantages just to make a few adjustment layers behave slightly different...

I would like it if someone was able to show me some good use for the LAB color space. Something that I've missed that allows for a quite useful adjustment that would be really hard in RGB... So far i just see people converting to LAB to do color noise reduction because they have not found blending modes (yet somehow found LAB)... -.-
Reply With Quote
  #5  
Old 09-07-2010, 03:41 PM
Junior Member
 
Join Date: Aug 2010
Posts: 16
Re: L*a*b* question: why can't it be simulated in

any color management book by Dan Margulis might be a good place to start,
I've picked up some great color saturation techniques from him as well as a very streamlined color corrections workflow that utilizes both RGB and LAB.
I find both colour spaces very useful. Removing moire patterns and minimizing noise - two things I think are done easier and better in LAB then RGB.
I recommend his books and Lynda tutorials if you are curious.
~Lukas
lukasdp.com
Reply With Quote
  #6  
Old 09-07-2010, 03:50 PM
Member
 
Join Date: Nov 2009
Posts: 89
Re: L*a*b* question: why can't it be simulated in

I think there is a definite use for it. I just finished a 6-hour course at Lynda by Deke McClelland.

http://www.lynda.com/home/DisplayCourse.aspx?lpk2=616

But I'm still having a hard time wrapping my head around the color space. I hope Dan's book will be thorough. The video's I've seen of Dan working on Lab have impressed me.

http://revision3.com/pixelperfect/labcolor

http://www.peachpit.com/podcasts/epi...7-d2cdd6fc9d60
Reply With Quote
  #7  
Old 09-07-2010, 05:05 PM
andrewrodney's Avatar
RetouchPRO LIVE Guest Artist
 
Join Date: May 2010
Location: Santa Fe
Posts: 530
Re: L*a*b* question: why can't it be simulated in

Quote:
Originally Posted by kkamin View Post
I think there is a definite use for it. I just finished a 6-hour course at Lynda by Deke McClelland.
But I'm still having a hard time wrapping my head around the color space.
If Deke has you confused, Dan will positively make your head explode!
Reply With Quote
  #8  
Old 09-07-2010, 06:09 PM
Moderator
Patron
 
Join Date: Dec 2005
Posts: 2,900
Re: L*a*b* question: why can't it be simulated in

Wow, get stuck on a plane for a day and look what happens!
Andrew and Chain, if you argue that the conversion to LAB and back is "very destructive" it ought be easy for you to produce a real photograph showing convincing signs of this serious destruction. That is, something that a skilled person would, with careful observation, perceive as damage, either at the moment after reconversion to RGB or thereafter with any plausible attempt to correct. This should be a real-world demonstration, with a real photograph. Not a histogram. Not a gradient or other computer-generated graphic. Not a demonstration that the file is not pixel-for-pixel identical with the original.
The LAB conversion myth has been circulating for 15 years, and scores of people have done their own careful testing and are unable to come up with such a demonstration on even a single image. It's a safe prediction that if you ask people for an example all you'll get back is a passle of worthless histograms and gradients, together with links to sites that say that conversions to LAB cause catastrophic damage but lack example images to back the claim up.
I have had the discussions with Dan Margulis and am convinced he is right. You can check out the proof and arguymants in chapter 6 of his book.
Whatever the merits of the theory, however, it's contradicted by the practical results with real images.
Kevin, I watched Deke's LAB course at Lynda.com a few years after I learned LAB from Dan Margulis. The Deke course was a big disappointment. Dan's LAB book for me was better written and easier to understand than all of his other books on Color.
Andrew, have you actually read / worked your way through Dan's LAB Color book or are you assuming it is similar to his other works?
Andrew and Chain (forgive me for jumping around) yes, as I pointed out there are some RGB work arounds like Fade to Luminosity, and setting blend modes to Luminosity. I actually never go into LAB if it is just to sharpen.
And yes, there are a number of things you can do in LAB that you can not do in RGB as well as many things that you can not do as quickly or as efficiently in LAB - Try CTRL 4 followed by Ctrl I, followed by Ctr 2
Try creating an asymetric spatial frequency split of an imge RGB.
I am out of time now but will try to post a couple of examples over the next day.
Regards, Murray

Last edited by mistermonday; 09-08-2010 at 01:40 PM.
Reply With Quote
  #9  
Old 09-07-2010, 06:25 PM
andrewrodney's Avatar
RetouchPRO LIVE Guest Artist
 
Join Date: May 2010
Location: Santa Fe
Posts: 530
Re: L*a*b* question: why can't it be simulated in

Quote:
Originally Posted by mistermonday View Post
Wow, get stuck on a plane for a day and look what happens!
Andrew and Chain, if you argue that the conversion to LAB and back is "very destructive" it ought be easy for you to produce a real photograph showing convincing signs of this serious destruction.
At what stage in the files life? The beginning? Towards the end? Shown on output to what device? After how much additional editing?

Throwing away good data, for no reason is a bad idea. Working with an 8-bit file and making such conversions leads to data loss, its simple math. Simply work in high bit, and now you’re just converting for little reason and pretty much wasting your time, but the data loss argument is now moot.

Quote:
That is, something that a skilled person would, with careful observation, perceive as damage, either at the moment after reconversion to RGB or thereafter with any plausible attempt to correct. This should be a real-world demonstration, with a real photograph. Not a histogram.
Are you channeling Dan Margulis now? Are you aware of his bogus “16-bit challenge?” If not, start here:
http://www.brucelindbloom.com/index....nMargulis.html

Quote:
I have had the discussions with Dan Margulis and am convinced he is right.
Well then lets move on and agree to disagree.

Quote:
You can check out the proof and arguymants in chapter 6 of his book.
I have the book, its not proof.

Quote:
Andrew, have you actually read / worked your way through Dan's LAB Color book or are you assuming it is similar to his other works?
Yup, I find his still confusing and very long winded. I’ve sat in on his seminars on several occasions as well at PSW. I find his style of wiggling out of specifics (this will work unless it doesn’t), irritating. I find his analysis of images (this area of the image is supposed to be neutral) silly (yes, cement is always neutral right? Unless its lit by sunset).
Reply With Quote
  #10  
Old 09-07-2010, 06:28 PM
andrewrodney's Avatar
RetouchPRO LIVE Guest Artist
 
Join Date: May 2010
Location: Santa Fe
Posts: 530
Re: L*a*b* question: why can't it be simulated in

Quote:
Originally Posted by mistermonday View Post
Moving back and forth from RGB to LAB is not visibly destructive unless you do it 10,000 times on the same image. The same is not true of other color spaces, particularly CMYK.
Now why would that be?
Reply With Quote
  #11  
Old 09-07-2010, 07:15 PM
Moderator
Patron
 
Join Date: Dec 2005
Posts: 2,900
Re: L*a*b* question: why can't it be simulated in

Andrew, OK while tying to make a point I was over the top with the 10,000 times comment. For the purposes of how many times you would actually make practical conversions back and forth with LAB, you visibly will not see destruction. To some extent the point is moot because often the reason you go into LAB are to make significant changes to the image that are intended to enhance it. If the results are better than the original, the the damage done to the image was positive.
Having put LAB to a lot of practical application over the past few years, I will repectfully agree to disagree with you on this topic. And by the way, it is so far the only one of your views expressed in these forums that I disagree with.
Regards, Murray
Reply With Quote
  #12  
Old 09-07-2010, 07:28 PM
andrewrodney's Avatar
RetouchPRO LIVE Guest Artist
 
Join Date: May 2010
Location: Santa Fe
Posts: 530
Re: L*a*b* question: why can't it be simulated in

Quote:
Originally Posted by mistermonday View Post
Andrew, OK while tying to make a point I was over the top with the 10,000 times comment.
Just a bit when the facts are, the image data loss is produced almost entirely on the first conversion.

Quote:
For the purposes of how many times you would actually make practical conversions back and forth with LAB, you visibly will not see destruction.
Visually see where, when and on what device?

Quote:
If the results are better than the original, the the damage done to the image was positive.
Only if you didn’t enhance it earlier in the workflow when you should (when you scan it, or when you render the raw data). Or by avoiding the issue at capture. Forgive me, I’m a classical trained photographer. I try to nail it in capture, not like Dan, after the fact to demonstrate how well I can polish a turd.

Of course. That’s why Photoshop exists. Its sole job is to alter existing RGB values. but I’m a huge believer in GIGO:GARBAGE IN GARBAGE OUT!

Its funny why those that spend so much time teaching you how to fix an awful original pay no attention to not getting an awful original in the first place. But again, my job for years was to produce good originals. Or to scan good data (not necessarily to match an ugly original unless asked to do so). Or today, to capture and render the raw data as cleanly as possible before Photoshop ever enters the picture.
Reply With Quote
  #13  
Old 09-07-2010, 07:41 PM
Moderator
Patron
 
Join Date: Dec 2005
Posts: 2,900
Re: L*a*b* question: why can't it be simulated in

Andrew, somewhere along the line I seem to have conveyed the wrong message. Being a photographer first and foremost, with an embarassingly long number of years behind the lense, I can appreciate as much the importance of getting it right on the shoot. There are a great many applications of LAB not directed at fixing poor photographs. It was largely those I was referring to. Although LAB can be an excellent assist in retouching as well. I was not selling LAB as a miracle cure for poor photography. I agree with GIGO and the concept that you can polish poop.
Regards, Murray
Reply With Quote
  #14  
Old 09-08-2010, 09:06 AM
DJSoulglo's Avatar
Senior Member
 
Join Date: Jan 2006
Location: Amsterdam
Posts: 410
Re: L*a*b* question: why can't it be simulated in

I love LAB as a tool to use. My main editing mode is always in RGB (although I started out in CMYK), I don't think it's that destructive, but I only use it for immense color shifts (anything to black/white).

Also a curves layer in luminosity and doing that same curves adjustment in LAB isn't quite the same thing. The RGB version isn't a perfect translation of that process. It's close, but no cigar.
Reply With Quote
  #15  
Old 09-08-2010, 11:49 AM
andrewrodney's Avatar
RetouchPRO LIVE Guest Artist
 
Join Date: May 2010
Location: Santa Fe
Posts: 530
Re: L*a*b* question: why can't it be simulated in

Quote:
Originally Posted by DJSoulglo View Post
Also a curves layer in luminosity and doing that same curves adjustment in LAB isn't quite the same thing. The RGB version isn't a perfect translation of that process. It's close, but no cigar.
I would expect the math to be different. If you tried both approaches and using Calculations you subtracted the two, I would expect we would see some differences. The question I have is, how would one test the two and examine that the RGB version isn’t a cigar? What test files and steps would one follow and what would they see that would show that the Lab conversion was superior?

A question to Murry. Where are you finding the conversion to Lab is necessary (what problem and technique are you finding warrants a Lab conversion)?
Reply With Quote
  #16  
Old 09-08-2010, 12:42 PM
Chain's Avatar
Senior Member
 
Join Date: May 2009
Location: Oslo, Norway
Posts: 482
Post Re: L*a*b* question: why can't it be simulated in

I might as well toss some more fuel on the fire.

Attached is an image showing simply what happens to your image data if you convert an 8-bit image to LAB in Photoshop (dithering). Additional conversions makes it worse. See image for more info.
Ps: I never said that converting to LAB was "very destructive", and in 16-bit any loss would be negligible (but would it really be worth the hassle?).
Edit: I should have seen this, but by not going through Image > Mode but instead going through Edit > Convert to Profile... you can turn off the dithering. This way you can avoid the dithering shown in the example (trade-off is more visible banding in some situations). A bit cumbersome though.

To be honest, the definition of "Luminosity" in Photoshop is way closer to human perceived brightness than the Lightness channel of a LAB image. So I do not see why LAB would be better for adjusting perceived brightness and color separately...
Photoshop uses a weighted sum of R, G and B to calculate the "Luminosity". The weighting choice is an attempt to compensate for the sensitivity of the human eye to each color.
Example attached (although it is best to overlay the images in Photoshop and turn them on/off to see how the brightness shifts).
Just to wrap this post up with another interesting piece of information; I would like to point out how simply desaturating the image in Photoshop does not use any such weighting of the colors and thus results in a change in brightness. In my example image the blue sky would end up brighter (our eyes are not that sensitive to blue) and the grass would turn too dark (we are quite sensitive to green).
Note; in this post when i say "brightness" i mean how bright the image appear to the human eye.
Attached Images
File Type: png LAB-test.png (30.3 KB, 54 views)
File Type: jpg luminosity.jpg (97.7 KB, 60 views)

Last edited by Chain; 09-08-2010 at 03:02 PM. Reason: Solved the unwanted dithering issue...
Reply With Quote
  #17  
Old 09-08-2010, 12:52 PM
andrewrodney's Avatar
RetouchPRO LIVE Guest Artist
 
Join Date: May 2010
Location: Santa Fe
Posts: 530
Re: L*a*b* question: why can't it be simulated in

Excellent visual presentation, it sure does appear that the method Photoshop is using produces, to my eye, a more “pleasing” rendering!

Quote:
To be honest, the definition of "Luminosity" in Photoshop is way closer to human perceived brightness than the Lightness channel of a LAB image.
Quote:
Note; in this post when i say "brightness" i mean how bright the image appear to the human eye.
Also nice to see Luminosity (incorrectly labelled in Photoshop since it was implemented) and Brightness (what we perceive) differentiated here. My partner, a true color scientists would be SO happy to see this post, as the term Luminosity as defined in Photoshop is a major pet peeve of his.

Gang, there’s so very useful info in that last post that anyone using Photoshop should study.
Reply With Quote
  #18  
Old 09-08-2010, 01:20 PM
Moderator
Patron
 
Join Date: Dec 2005
Posts: 2,900
Re: L*a*b* question: why can't it be simulated in

Andrew, here is one reason - Color correcting Dodge and Burn Curve Adj layers. I use the two sample files attached. Please excuse the simplicity - solid colors, no texture, to illustrate the point, also an exaggerated color difference to illustrate the reason.
Please open the RBG file with just the bg layer active. Add a dodge curve, dodge the top right corner until the luminosity of it equals the left side iof the image (eyedropper samplers are there). Add a blank layer set to color and paint with the left side color. Turn off the visibility layer.
In a typical D&B on a portrait, the D/B curves shift the saturation as well as the lightness. Trying to color correct is not that easy or quick. You can add a Hue/Sat layer with a layer mask copied from the D/B curve but that has its issues.
In LAB, 2nd file, it doesn't matter where the A and B values go when you move the curves. The luminosity can be match very quickly. Add a blank color layer and you can paint in any color and get a perfect match because the L channel won't move.
I am NOT saying that this is a necessary part of the workflow. It just happens to add speed, works smoothly, and intuitively. Moreover I find more lattitude in the base brightening and lightening curves which can have an impact on how many times you need to brush over a pixel to brighten or lighten it.
Regards, Murray
Attached Files
File Type: zip MM Dodge Test RGB.zip (39.0 KB, 18 views)
File Type: zip MM Dodge Test LAB.zip (180.2 KB, 13 views)

Last edited by mistermonday; 09-08-2010 at 01:39 PM.
Reply With Quote
  #19  
Old 09-08-2010, 01:22 PM
Chain's Avatar
Senior Member
 
Join Date: May 2009
Location: Oslo, Norway
Posts: 482
Post Re: L*a*b* question: why can't it be simulated in

(my above post is the "important" one)

I've attached a more extreme example here to show that "Luminosity" in Photoshop is way better than LAB's Lightness channel at representing the apparent brightness of the image, and thus better at separating brightness/color when doing adjustments.

Note on the related blending modes:

In Photoshop the "Color" blend mode is the inverse of "Luminosity" (it affects only the color, but not perceived brightness).
The "Hue" and "Saturation" blending modes are also based on the same calculation but further divide "color" into the two components "Hue" and "Saturation".
Notice that "Saturation" blending thus works different (more visually accurate) than the desaturation (or hue/saturation) adjustments.
To see this yourself add a hue/saturation adjustment layer, set saturation to -100 (desaturate). Then change blending mode to Saturation and see how this restores the original brightness.
This is why you always want to change your hue/saturation-adjustment's blending mode (also for hue adjustments).
Attached Images
File Type: jpg maintaining-brightness.jpg (65.0 KB, 28 views)
Reply With Quote
  #20  
Old 09-08-2010, 01:29 PM
Chain's Avatar
Senior Member
 
Join Date: May 2009
Location: Oslo, Norway
Posts: 482
Re: L*a*b* question: why can't it be simulated in

Quote:
Originally Posted by mistermonday View Post
Please open the RBG file with just the bg layer active. Add a dodge curve, dodge the top right corner until the luminosity of it equals the left side iof the image (eyedropper samplers are there). Add a blank layer set to color and paint with the left side color. Turn off the visibility layer.
I will look closer at the files you supplied now but a quick look tells me that the "Visualize" layer on the RGB file should probably have been set to blending mode Color or Saturation to give a correct result?
And if you want the RGB version to not shift the color the curves (dodge) layer should be set to Luminosity blending.
Edit: Also the RGB image is a bit blurry in the transition between the left and right side (it has been resampled i think).
Edit: The hue/saturation layer might be problematic for visualisation in LAB as the blend modes do not work... I'm a bit unsure here.

Last edited by Chain; 09-08-2010 at 01:42 PM.
Reply With Quote
  #21  
Old 09-08-2010, 01:38 PM
andrewrodney's Avatar
RetouchPRO LIVE Guest Artist
 
Join Date: May 2010
Location: Santa Fe
Posts: 530
Re: L*a*b* question: why can't it be simulated in

Quote:
Originally Posted by Chain View Post
And if you want the RGB version to not shift the color the curves (dodge) layer should be set to Luminosity blending.
I too will look at the files (thanks) but the idea mentioned above is what I would have initially thought of too; using the Luminosity blend mode to avoid the color change.
Reply With Quote
  #22  
Old 09-08-2010, 01:42 PM
Moderator
Patron
 
Join Date: Dec 2005
Posts: 2,900
Re: L*a*b* question: why can't it be simulated in

Chain, setting the curves' blend modes to luminosity doesn't prevent the shifts nor does the correction work the same.
Regards, Murray
Reply With Quote
  #23  
Old 09-08-2010, 01:58 PM
Chain's Avatar
Senior Member
 
Join Date: May 2009
Location: Oslo, Norway
Posts: 482
Re: L*a*b* question: why can't it be simulated in

mistermonday:
I have looked at those files and I found the test a bit faulty (or did i misunderstand the purpose?). I noted some of my issues with it in the edits of the above post.

That said, it was very easy in both LAB and RGB to match the brightness of the two colors using a gentle curves adjustment (brightening/dodging).
* In RGB the color did not visibly shift if blending was set to Luminosity.
* In LAB the color did shift (a bit more purple).
Note: when using Normal blending the RGB did shift the color more.

Attached are my improved files with my results so you can have a closer look.
Attached Files
File Type: zip LAB and RGB test.zip (30.8 KB, 13 views)
Reply With Quote
  #24  
Old 09-08-2010, 03:19 PM
Chain's Avatar
Senior Member
 
Join Date: May 2009
Location: Oslo, Norway
Posts: 482
Re: L*a*b* question: why can't it be simulated in

I'm still trying to finding a useful use for LAB worth the flattening/multiple conversions.

For adjusting brightness or adjusting brightness/color separately it does not perform as good as RGB w/blending modes.

Still, I will have to research it a bit more but it seems it might prove an interesting alternate way of playing with color and doing heavy color saturation.
Although with Vibrance, Hue/Saturation (allowing you to selectively adjust different color hues) combined with saturation/hue/color blending modes and all the other tools for adjusting color I think that if it has an advantage it would be in very special cases... For some artistic expression it could be fun to play with either way...
Reply With Quote
  #25  
Old 09-08-2010, 04:06 PM
Moderator
Patron
 
Join Date: Dec 2005
Posts: 2,900
Re: L*a*b* question: why can't it be simulated in

Quote:
And if you want the RGB version to not shift the color the curves (dodge) layer should be set to Luminosity blending.
Chain, I may be missing something, otherwise no way. What I would like you to do in the RGB image is to change both eyedropper points in your info palette from RGB to LAB (not the image just the eyedropper samples), all layers on except the color correct layer, make active the visibility layer, and now look at the L values. Both are 58. Now set the Curve blend mode to Luminosity. Make active the Visibility layer and you will see that the Dodged area has changed value to 56. On my monitor there is a very significant change in the lightness of the two gray areas. Now turn the visibility layer OFF and turn on the recolor layer. On my monitor there is a very significant difference in color between the dodged area and the left side of the image. When you are dodging and burning a portrait, a difference in a few points of lightness is extremely noticeable and in most cases an unsuccessful dodge or burn. Shifts in saturation caused by D&B curves must be corrected as they are very noticeable. Small color differences are also not acceptable.
Now play with the LAB file. Feel free to also change the curvve blend mode to Luminosity - it has no affect whatsoever. In LAB, you adjust the luminosity and when you have it right, you can recolor with any color including this case where you go from 11/-58 (A/B) to +38/46 with zero change in luminosity 54/54 and a perfect color match.
While this example is extreme, the principal functioning and implementation is exactly the same for a portrait D&B where the lightness and color differences are equally noticeable.
Regards, Murray
Reply With Quote
  #26  
Old 09-09-2010, 04:09 AM
Chain's Avatar
Senior Member
 
Join Date: May 2009
Location: Oslo, Norway
Posts: 482
Re: L*a*b* question: why can't it be simulated in

In this post are you referring to your original images, or my fixed versions? The test seemed a bit flawed to me (especially the original).

Yes, in LAB when adjusting the Lightness channel the a/b channels are not affected and vice versa. And in RGB if i change the red channel it does not affect the blue channel. And...? My point is that the Lightness channel is not a good analoge for the apparent brightness of the image, and the L-value can thus not be trusted to give good enough feedback on the brightness when comparing two different colors. This has to be done visually or with appropriate weighting of the RGB components.
Two colors might have the same L-value but different brightness.

I'm assuming that the purpose of your "dodging" was to increase apparent brightness without affecting color. In that case Luminosity blending mode in RGB triumphs over the L-channel in LAB.

In the test (my version) you can see that adjusting lightness in LAB shifts the blue color slightly towards more purple while in RGB using Luminosity it does not. However it is a bit tricky to compare the results and check them in a fair manner because you have to convert between the color spaces to do this, and also in LAB the Luminosity blending mode does not work.

To digress a bit; that the blue-purple shift is a known weakness in LAB and I believe it is for the same reason that you see the effect when converting out-of-gamut blue tones from RGB to CMYK. The rendering intent tries to move the blue colors into gamut (apparently in the LAB color space) – causing an unintended hue shift. Soft-proofing and manually tweaking the problematic blues is the only good way i know around it.

And back on topic:
"Luminosity" in Photoshop is way better at matching correct brightness then the Lightness channel in LAB. I pointed this out in my previous posts with a couple of clear visual examples and this is still my point.

Ps: Please do not say "Luminosity" when referring to the LAB Lightness-channel. It might confuse people.
Reply With Quote
  #27  
Old 09-09-2010, 06:59 AM
Moderator
Patron
 
Join Date: Dec 2005
Posts: 2,900
Re: L*a*b* question: why can't it be simulated in

Chain, my last post comments were based on my image, not your modified version, which I just found. Your modified version just proves my point and perhaps I did not explain the goal clearly enough.

Quote:
I'm assuming that the purpose of your "dodging" was to increase apparent brightness without affecting color. In that case Luminosity blending mode in RGB triumphs over the L-channel in LAB.
Not exactly. Like RGB, a dodge or burn curve can NOT alter the lightness without affecting the color / saturation. LAB has the same problem but it varies the color / saturation somewhat differently. The net effect for both LAB and RGB is that after you dodge an area in a real image to brighten a frckle or wrinkle or darker area of skin, and lets say you dodge it to exactly match the lightness of the adjacent area, the color / sat shift will mean that the dodged area does not match its surroundings and you almost always need to perform a correction, usually by painting on a color layer or adding a Hue/Sat adj layer or both.

In LAB, this is not the case. Once you have matched two areas in lightness, you can paint on a color layer with an adjacent color and there will be a perfect match. If you do that in RGB it will NOT. Moreover, if you change the Dodge curve blend to Luminosity, it will be close but it will NOT match.

That was the purpose of my last post, to walk you through it. I understand the difference in lightness and luminosity and the only reason I asked you to change your eyedroppers to L in the RGB image was to help you visualize and ensure that the brightness of the dodged area was the same as the left side of the RGB image with the desaturated / visualization layer is turned on.

Andrew Rodney asked for a real life example. In real life D&B you need a reliable, fast, and simple way to dodge or burn an area up or down to where it is within range of adjacent area (not always exact but sometimes). The fastest easiest method is to do it visually and that usually requires a desaturated view sometimes coupled with a contrasted view to accentuate the difference in brightness. After all the work on the D&B layers is done, you almost always require color / saturation correction. In LAB you can paint away and you have perfect match. In RGB you can not do the same as you can see in my sample image. Not even if you change the curve to luminosity blend. In RGB its more work and time to clean things up and the results rarely look as good.

If you need to see this done on real skin I can put something together, however if you have done any detailed skin work you should already have an appreciation if the issues. If you or Andrew have a better way of doing things in RGB, I would be pleased to see it. I am open. I have am not polarized, biased, or bigotted toward either color model. For both RGB and LAB I find things which are more intuitive, faster, more effective, that produce excellent results. In the end, there is a lot of "realworld" work that must be completed.
Regards, Murray
Reply With Quote
  #28  
Old 09-09-2010, 08:16 AM
andrewrodney's Avatar
RetouchPRO LIVE Guest Artist
 
Join Date: May 2010
Location: Santa Fe
Posts: 530
Re: L*a*b* question: why can't it be simulated in

To digress a bit, in terms of dodge and burn (and then some), the technique I’ve used, taught to me by JP Caponigro and modified by Mac Holbert is:

Make a new layer, name it Dodge & Burn, set the mode to Overlay. If you then paint on it with black you burn, paint with white, you dodge. You control opacity with the keyboard. Eraser removes what you didn’t want applied. JP paints a bit hot, then tweaks using the Fade Command which does a nice job of allowing control over that last brush stroke (problem is, its just the one stroke*).

JP also paints in warmness or coolness by setting the colors either to warm or cool (blue or yellow), using a new layer with the blend mode set to Hue. On that new layer, the brush paints warm/cool, not that actual color. To increase or decrease saturation, one more layer, blend mode set to Saturation. Pick a very saturated or muted color (the actual color itself doesn’t matter). Thanks to the blend mode, the brush only adds or reduces saturation.

*I find Lightroom’s selective brushes to work really well because you can paint in a dodge or burn, adjust at any time the strength much like the Fade command. I paint very hot so I can see exactly where I’m brushing the dodge or burn, (or any other edit using brushes) then I can move the appropriate slider to get exactly the density I want. Even weeks later since the beauty of a parametric editor is, history is always accessible and the edit never burns an edit into pixels until you render the data. I wouldn’t do this for tiny areas of an image. That’s a job for a pixel editor. Lots of brush strokes can slow LR down a great deal.But for decent sized areas, dodging and burning in Lightroom or ACR work really well for me and provide all the controls I need, no issue with color, layers making the file larger etc. I also like rendering out as much of the “corrections” as possible at the raw stage.
Reply With Quote
  #29  
Old 09-09-2010, 08:54 AM
Chain's Avatar
Senior Member
 
Join Date: May 2009
Location: Oslo, Norway
Posts: 482
Re: L*a*b* question: why can't it be simulated in

It would be nice if you could put up some examples together using problematic images that we can use to compare the methods discussed here.

I just tried dodging some skin in LAB and RGB and comparing. Both color spaces were equally easy for this task, and both provided good results.
I made it nice and tidy, and my files are here (I couldn't get it all in the silly 100 KB retouchpro limit).
Additional comments are inside the files as notes.

My conclusion after the test is that in this example, there was absolutely no need flatten and convert to LAB just for the dodging.

Note: Personally i would probably also have attacked this with the healing brush to clean up the remaining texture, and maybe even a frequency separation, but I focused only on the dodging.
Reply With Quote
  #30  
Old 09-09-2010, 10:39 AM
Senior Member
 
Join Date: Apr 2009
Posts: 653
Re: L*a*b* question: why can't it be simulated in

Great thread guys, keep it up.

mistermonday, I'm curious about how typically you do go into LAB for beauty D&B and your workflow to do it.
Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Converting CMYK to RGB and back to CMYK. xxxmen Input/Output/Workflow 23 01-06-2011 10:56 AM
my 1st post..red cast on Lacie 324/CS4 RGB to CMYK nadaman Hardware 47 03-10-2010 01:31 PM
Adobe RGB (1998) profile problem * Sinisa Software 7 07-10-2009 10:08 PM
RGB Help PSE JohnTravers Salon 5 10-13-2008 06:28 PM
silly question Tinkerbella197 Photo Restoration 5 09-15-2008 10:46 AM


All times are GMT -6. The time now is 05:20 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.3.2
Copyright © 2008 Doug Nelson. All Rights Reserved