![]() |
| |||||||
| Photo Retouching "Improving" photos, post-production, correction, etc. |
| | Thread Tools |
|
#1
| |||
| |||
| 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? |
|
#2
| |||
| |||
| 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 |
|
#3
| ||||
| ||||
| 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:
|
|
#4
| ||||
| ||||
| 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)... -.- |
|
#5
| |||
| |||
| 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 |
|
#6
| |||
| |||
| 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 |
|
#7
| ||||
| ||||
| Re: L*a*b* question: why can't it be simulated in If Deke has you confused, Dan will positively make your head explode! |
|
#8
| |||
| |||
| 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. |
|
#9
| |||||
| |||||
| Re: L*a*b* question: why can't it be simulated in Quote:
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:
http://www.brucelindbloom.com/index....nMargulis.html Quote:
Quote:
Quote:
|
|
#10
| ||||
| ||||
| Re: L*a*b* question: why can't it be simulated in Now why would that be? |
|
#11
| |||
| |||
| 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 |
|
#12
| ||||
| ||||
| Re: L*a*b* question: why can't it be simulated in Quote:
Quote:
Quote:
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. |
|
#13
| |||
| |||
| 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 |
|
#14
| ||||
| ||||
| 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. |
|
#15
| ||||
| ||||
| Re: L*a*b* question: why can't it be simulated in Quote:
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)? |
|
#16
| ||||
| ||||
| 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. Last edited by Chain; 09-08-2010 at 03:02 PM. Reason: Solved the unwanted dithering issue... |
|
#17
| ||||
| ||||
| 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:
Quote:
Gang, there’s so very useful info in that last post that anyone using Photoshop should study. |
|
#18
| |||
| |||
| 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 Last edited by mistermonday; 09-08-2010 at 01:39 PM. |
|
#19
| ||||
| ||||
| (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). |
|
#20
| ||||
| ||||
| 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. 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. |
|
#21
| ||||
| ||||
| Re: L*a*b* question: why can't it be simulated in 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. |
|
#22
| |||
| |||
| 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 |
|
#23
| ||||
| ||||
| 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. |
|
#24
| ||||
| ||||
| 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... |
|
#25
| |||
| |||
| Re: L*a*b* question: why can't it be simulated in Quote:
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 |
|
#26
| ||||
| ||||
| 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. |
|
#27
| |||
| |||
| 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:
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 |
|
#28
| ||||
| ||||
| 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. |
|
#29
| ||||
| ||||
| 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. |
|
#30
| |||
| |||
| 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. |
| Thread Tools | |
| |
| | ||||
| 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 |