Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: G* on April 24, 2013, 11:42:14 am
-
One common technique for boosting color saturation is manipulating channel A and B in LAB color mode, for example with "curves" in Photoshop. It seems to be a question of personal preference whether people use
A) an S-curve for this or
B) just move the edges of the adjustment panel inward to get a straight line.
I would like to know how many of you are following "A" or "B" (or "C": use completely different approaches to increasing color saturation), and most importantly on what rationale you base your curves, lines, values etc.
Thanks for letting me learn!
-
To increase colour saturation using the a and b channels of Lab, you must move each curve the same distance from the corners top and bottom, linear (no S, no other shape) and both curves must pass through the middle creating a uniform symmetrical "X". Anything else will muck-up your colour balance big time. These are very sensitive adjustments with large impacts.
All that said, this is most often a needless process. For 99% of all practical purposes, it will do just fine to increase the saturation of an RGB file by leaving it in RGB colour space and using the conventional tools provided in Lightroom, Camera Raw or Photoshop for increasing saturation globally or selectively. They are more than adequate.
-
Thanks for your reply, Mark.
Wouldn’t a symmetrical S-curve that hits the middle keep the balance, too?
My experience is that most images which need a boost in saturation have values in A in B that are not far away from the middle. To stretch those near-neutral values I have to build a curve that has a steeper slope where those values sit. In theory I could move the lines’ beginnings as far in as the most extreme value in one of the four colors (that is, stop just before cutting something off). So the most extreme color value determines the manipulation in both channels, on both sides of the middle.
Of course these curves are likely to have such an impact that we won’t like the image afterwards anymore, but on this basis we are free to decrease the opacity of our curves layer.
My guess is that most people prefer to make this kind of adjustments based on actions that move the four end points in, so they don’t have to go to each channel all the time, click and move or type in values fout times, control the values, perhaps do some mental arithmetic. And then find out that the change was not what they had hoped for.
Anyway, what made me start this thread was to find out the rationale behind the values people chose (maybe just values they start the process with, something based on profound experience?).
Now about the S-curve: It does not seem to harm the image too often, probably because most A/B values are close to the middle where the S-curve is hardly any different from a straight line. Only relatively extreme values (in the unaltered image file that is) will experience a different adjustment: they will not be boosted as much. But, and this might be a good reason to use an S-Curve in the first place, they also will not be cut by moving the ends too far as might happen in the "straight line workflow".
So the S-curve might work as a more comfortable way of working on a lot of images?
-
No, it is not just a matter of personal preference - it is technical. ANY departure from linearity will impact colour balance because you are altering the relationship between green and magenta on the a curve and blue and yellow on the b curve at different luminosity levels depending on where the non-linearity sets in, and if those linear curves do not intersect in the middle the colour balance of the whole image is thrown-off. Lab conversion is a needless and cumbersome complication from the get-go for 99% of the image editing the great majority of us ever need to do. There are many things in Photoshop that don't work in Lab mode, so most often you will need to convert back to RGB, and once you do this your Lab adjustments are baked-in and non-reversible, unless you have a separate duplicate image copy with the Lab adjustments converted back to RGB but layered-in. Lab has certain specialized uses that justify its inclusion in the Photoshop arsenal, but making simple adjustments to saturation is not one of them when there are much more straightforward ways of doing this in RGB.
-
All that said, this is most often a needless process. For 99% of all practical purposes, it will do just fine to increase the saturation of an RGB file by leaving it in RGB colour space and using the conventional tools provided in Lightroom, Camera Raw or Photoshop for increasing saturation globally or selectively. They are more than adequate.
Amen to that! Plus if there is an unattractive color shift, just Fade using Luminosity. Better yet, do all this in the raw processor like ACR or Lightroom.
-
In addition to all the wonderful discussion points, I believe that any conversion to and from different colour spaces is going to result in conversion/rounding errors, even if at a very minute amount. Therefore this alone may negate any potential slight benefit of increasing saturation via Lab instead of RGB.
Cheers,
Jay
-
Anything else will muck-up your colour balance big time. These are very sensitive adjustments with large impacts.
It's a relief someone else notices this besides me. I used to edit my scanned color negatives in Lab and I liked how it gave me strange, glorious colors very quickly until I noticed after some lengthy tweak sessions I virtually destroyed the natural color constancy and color palette of the original scene to where it now looked cartoonish.
For instance forest green shrubs/trees lit by golden hour sunlight shouldn't look cooler with added cyan but warmer with a bit of added orange. If you aren't careful and aware of the human visual system's adaptive nature to cool and warm colors editing in Lab space, you can end up reediting the entire image after taking a break and returning to something butt ugly you thought before looked great.
Guess that's why Lab isn't thought of as a real "working space" but more a scientific color description model with unintuitive color editing tools.
RGB by its very three letter description follows a color sensibility with regard to color constancy that more closely follows the behavior of the the rods and cones of our eyes to how humans perceive color changes due to changing light on a scene.
-
Jay’s worry about conversion/rounding errors made me do a little experiment this morning. I built a Photoshop document filled with neutral gray (128,128,128) and did some conversions back and forth. I'll only report my most significant results here:
sRGB 8bit > LAB 8bit > sRGB 8bit
= rounding errors already after one conversion back and forth, increasing noise after 20, 40, 60, 100 conversions (yes, it’s a rather academic experiment). Might be an interesting method to create a grainy image …
sRGB 16bit > LAB 16bit > sRGB 16bit
= no error even after 200 circles of converting back and forth
Same result in ProPhoto RGB for those who wonder. So I guess with a 16bit workflow there is no need to worry about rounding errors.
Then I was curious about what exactly happens with luminosity when increasing color saturation in RGB or LAB. Not color shifts, just luminosity. So I took an image and added a layer of +30 saturation in RGB. On four random points with different luminosity and color I measured what happened to the values, then had a look at the individual points as well as at the average deviation. This is my ranking of methods in sRGB according to deviation in luminosity from the greatest (A) to the smallest amount (D):
A) sRGB 8bit, blending mode "normal"
B) sRGB 16bit, blending mode "normal"
C) sRGB 8bit, blending mode "saturation"
D) sRGB 16bit, blending mode "saturation"
Interesting: Even the last workflow in the list, the one with the least amount of deviation in luminosity produced some deviation. That being said, I guess that nobody would notice any of the measured amounts of deviation in luminosity in real life and no matter how aesthetically sensible.
Now for the LAB workflow. I did not try to boost saturation the exactly same amount as in RGB. Actually I am lacking the knowledge how to relate between "+30 saturation" in RGB and the slope of a curve in a/b channels in LAB. But nevertheless I could see something interesting in my experiment:
1) LAB 8bit, curves a/b channels, blending mode "normal"
= Well, some increased saturation, no change in L channel. Everything else would have been a miracle.
2) LAB 8bit, curves a/b channels, blending mode "saturation"
= a third of the measured a/b-values deviated from the workflow above. I really did not expect this.
3) LAB 16bit, curves a/b channels, blending mode "normal"
= same as 1)
4) LAB 16bit, curves a/b channels, blending mode "saturation"
= same as 1) and 3)
I guess I have learned a lesson about the importance of a 16bit workflow.
Well, last but not least I converted my LAB images 1)–4) back to sRGB:
Luminosity had changed in all cases. The values are not really comparable to the RGB workflow due to the lack of consistency, but the deviation values where somewhere between the (B) and (C) values.
I will think about what all this means for my workflow. My feeling is that all the measured deviations are much smaller than the difference between my motives’ colors and what I get from my RAW developers as a tif file. So as long as I like the result of a certain manipulation in Photoshop, it might be okay for me to work in whatever color space available. As long as it’s 16bit, that is.
:-)
-
I will think about what all this means for my workflow. My feeling is that all the measured deviations are much smaller than the difference between my motives’ colors and what I get from my RAW developers as a tif file. So as long as I like the result of a certain manipulation in Photoshop, it might be okay for me to work in whatever color space available. As long as it’s 16bit, that is.
Hi,
You may also want to consider that converting to Lab, and back to RGB, will change/lose colors, even in a 16-bit workflow. Here (http://www.brucelindbloom.com/RGB16Million.html) is a test file that contains 'all' possible colors to test with (although not all images will have those colors that will be affected). One particular problem that can hurt is a shift of Blue to Purple (http://www.brucelindbloom.com/MunsellCalcHelp.html#BluePurple) (will create ugly looking skies).
You may additionally want to consider that the "RGB to Lab to RGB" conversion is often avoidable, by staying in RGB and use dedicated tools that avoid perceptual color shifts.
Cheers,
Bart
-
Small point.
One must remember that 16777216 "colours" in RGB are in fact not unique colours, but all possible combinations of the encoding space.
ie there are not 16777216 perceivable colours in the sRGB space
LAB space on the other hand is based on perceived colours and is used to calculate Colour Difference. It is an attempt to represent Human Colour Vision in perceptually uniform manner.
sRGB etc is not based on human colour vision but on a real or ideal device.
Hence the reduction from 16777216 to '2,186,578 unique colors' as Bruce states.
Iain
-
Small point.
One must remember that 16777216 "colours" in RGB are in fact not unique colours, but all possible combinations of the encoding space.
ie there are not 16777216 perceivable colours in the sRGB space
Hi Iain,
When the sRGB colorspace is concerned, then all of the 16+ million color combinations are well within the gamut that human vision can see, and as such are colors. When we assign a different colorspace, e.g. ProPhoto RGB, to the same test file, then a number of those coordinates fall outside the human range of perception, and as such they cannot be called colors.
LAB space on the other hand is based on perceived colours and is used to calculate Colour Difference. It is an attempt to represent Human Colour Vision in perceptually uniform manner.
CIE Lab is not perceptually uniform, unless a theoretical transformation is performed as Bruce describes here (http://www.brucelindbloom.com/UPLab.html). As he states, Lab "was not designed to have the perceptual qualities needed for gamut mapping". It was indeed "designed to measure color differences". Using Lab for anything else than measurements is fraught with difficulties.
sRGB etc is not based on human colour vision but on a real or ideal device.
Hence the reduction from 16777216 to '2,186,578 unique colors' as Bruce states.
That's not what Bruce states though, he says that "All of the loss may be attributed to quantization, that is, multiple unique RGB colors collapsing into a single Lab color". Besides, sRGB is only a small sub-set of all humanly visible colors, that's one of the reasons it was used as a lowest common denominator for various hardware devices (camera and scanner files/displays/printers/etc.).
I did mention that not all of the color coordinates in the test file are present in an average image, so some images will lose more color precision (multiple colors collapsing in a single coordinate) than others.
Cheers,
Bart
-
Hi
As Srgb is device space the 16million + coordinates do not represent unique perceived colours. There are a lot of rgb triplets that produce the same colour perception or 'holes'. The holes are already there is srgb its that you just dont 'see' them until you convert to say LAB
So to go from device space to perceptual space of course there will be a reduction.
I said that LAB as an attempt to produce a uniform color space. CIECAMUCS is a better attempt.
iain
-
Converting from RGB to Lab and back in 8-bit, depending on the original color space will lose a decent amount of values and it's unnecessary. In 16-bit, the same is true but the rounding errors are so tiny, we don't detect them. Partially thanks to the lack of precision of Photoshop's number read-out <g>. If you feed color lists to ColorThink, you'd see this. Keep in mind the role of Dither on 8-bit per color data (check the color settings)! One way to 'see' the effect of this kind of conversion is to use the Apply Command to subtract two iterations, the role of dither here should be visible:
http://digitaldog.net/files/Apply_Image.pdf
CIE Lab is not perceptually uniform although that was the idea <g>. The creators of Lab probably couldn't imagine the use of the color model today in app's like Photoshop and would probably question some of those use as well.
-
As Srgb is device space the 16million + coordinates do not represent unique perceived colours. There are a lot of rgb triplets that produce the same colour perception or 'holes'. The holes are already there is srgb its that you just dont 'see' them until you convert to say LAB
In perusing Bruce's page on RGB working space information, I see that the gamut of sRGB is 832,000 ΔE3 units. a ΔE of 1.0 is the smallest color difference the human eye can see. If I interpret this correctly, this means that sRGB contains 832,000 perceivable colors. The RGB file in question contains 16M values, and many adjacent values are not differentiated by the human visual system and therefore are not unique colors in the strictest sense, since color is a perceptual phenomenon and not a physical entity. If the round trip retains 2,186,578 colors, perhaps this is sufficient. The L*a*b gamut is 2,381,085 ΔE3 units.
Regards,
Bill
-
In perusing Bruce's page on RGB working space information, I see that the gamut of sRGB is 832,000 ΔE3 units. a ΔE of 1.0 is the smallest color difference the human eye can see. If I interpret this correctly, this means that sRGB contains 832,000 perceivable colors.
Hi Bill,
I don't think that is the correct way of looking at it. It is more that many colors fall below the JND (just noticeable difference) threshold, but that's only in a side by side attempt to differentiate between them. They are all unique colors.
It's most certainly not the reason for the encoding precision losses that Bruce mentioned.
The RGB file in question contains 16M values, and many adjacent values are not differentiated by the human visual system and therefore are not unique colors in the strictest sense, since color is a perceptual phenomenon and not a physical entity.
It is indeed the adjacent colors that cannot be discriminated from each other, but they are unique (in fact they are practically infinitely analog). The colors themselves can be perceived, but not discriminated between when seen side-by-side.
The encoding losses have to do with the differences in gamut size and an encoding in integer coordinate space.
Cheers,
Bart
-
Hi Bart
Remember that colour is a perception. it is wrong to think of device values as separate colours unless each individual triplet is produces a different perception ie a unique colour. In sGB this is not the case.
"adjacent colors that cannot be discriminated from each other, but they are unique" - no they are the same colour!
Device vales and encoding values are just that, values, not colours until the device is viewed.
Dont forget that the PCS is either LAB or XYZ and to go from sRGB to CMYK inkjet for example you pass through LAB so the sRGB gets mapped to the LAB values anyway.
As for the OP, working in LAB is maybe not as intuitive as a RGB space, but can be done with a bit of care. Most of the time working in RGB will suffice.
Iain
-
Hi,
You may also want to consider that converting to Lab, and back to RGB, will change/lose colors, even in a 16-bit workflow. Here (http://www.brucelindbloom.com/RGB16Million.html) is a test file that contains 'all' possible colors to test with (although not all images will have those colors that will be affected). One particular problem that can hurt is a shift of Blue to Purple (http://www.brucelindbloom.com/MunsellCalcHelp.html#BluePurple) (will create ugly looking skies).
You may additionally want to consider that the "RGB to Lab to RGB" conversion is often avoidable, by staying in RGB and use dedicated tools that avoid perceptual color shifts.
Cheers,
Bart
Below is a screengrab in Photoshop off my calibrated sRGB-ish Dell 2209WA LCD of a 100% cropped view of an image of a decorative deep blue glass crystal ball captured in Raw under outdoor daylight shade and processed in 16bit ProPhotoRGB ACR to demonstrate why sRGB sucks as a technical quantitative comparator and even a working space no matter how many perceptual levels of colors it encompasses.
It shows what happens when I convert from ProPhotoRGB to sRGB in both ACR and Photoshop (same thing happening converting to Lab and then to sRGB). Converting to AdobeRGB shows noticeably less results but still a shift from blue to purple. Editing in ACR in sRGB would not let me correct the blue to purple color shift. None of the hue/saturation tools made a dent. ProPhotoRGB made it easy.
ACR/LR has so many tools that can bring out saturated facets like in the blue crystal that Lab tools can't even come close to...
1. Camera Profiles...several options-Adobe Standard, custom DNG single and dual illuminant profiles. (They can really effect blue colors). I used a custom dual illuminant on the blue crystal.
2. Saturation sliders in "Camera Profile" panel. Don't underestimate their power when editing vibrant jewelry such as the blue crystal. They act upon color quite differently than HSL, Vibrance and Saturation sliders.
3. HSL, Vibrance and Saturation.
All of them are immediate and quickly accessed. All you have to do is play with them like your playing a video game. It's that fast. Working in Lab requires going into and saving out of too many dialog boxes, not to mention having to deal with layers.
-
Below is a screengrab in Photoshop off my calibrated sRGB-ish Dell 2209WA LCD of a 100% cropped view of an image of a decorative deep blue glass crystal ball captured in Raw under outdoor daylight shade and processed in 16bit ProPhotoRGB ACR to demonstrate why sRGB sucks as a technical quantitative comparator and even a working space no matter how many perceptual levels of colors it encompasses.
You may be correct, but your demonstration is a bit lacking in detail. This is what happened in the Unconverted image:
1) opened a raw file in humongous ProPhoto
2) automatic/manual adjustments were applied in the raw converter spinning colors around
3) color management then tried to squeeze these wide ranging ProPhoto colors into your monitor's presumed color space using unspecified parameters
4) the video card driver and LUT performed more squeezing - a screen capture was taken
5) the monitor displayed its best (sRGBish) rendition of such corrected colors
In the Converted image you went back to step 2) and inserted step 2a) after it in the list:
2a) conversion to sRGB color space using unspecified parameters.
The two screen shots were compared, but there are many unknowns for the comparison to be meaningful.
Since in 99% of cases people are either printing or viewing in sRGB, it would be interesting to know whether it makes a practical difference in day to day use to work in it from the very start or rather convert to it at the end of PP. Squeeze at the beginning or at the end, but always squeeze we (non-pros) must. My feeling is that most of the color differences/shifts are introduced during conversion into the final color space (sRGB), and that the more and the more extreme adjustments one makes in a larger color space, the more the chances that final colors will be wild guesstimates (http://graphics.stanford.edu/courses/cs178-13/applets/gamutmapping.html) - which may then need to be corrected for (again if converted later) after conversion. On the other hand when there are minimal adjustments, there is no reason why Camera Space --> XYZ --> ProPhoto --> XYZ --> sRGB at the very start should not result in very similar values to Camera Space --> XYZ --> sRGB, assuming proper conversion parameters. If I understand correctly this is what is shown in your attachment (the conversion to sRGBish in the left image capture performed by your CM system). So where do the differences come from? The first suspect that comes to mind is the chosen intent/compensation, the second are adjustments performed in ProPhoto. BTW, the more direct approach should in theory result in less noise.
To check this with your difficult test file, you could open the Raw file directly into sRGB with an sRGBV4 profile (Nikon's is good) using a variety of intents with/without blackpoint compensation and produce a series of comparisons to ProPhoto+sRGB in the same conditions. Better yet you could post the Raw file and let us have a go at it with our own raw converters and CM workflows.
Jack
[EDIT]
I viewed this page in Chrome, which is not color managed. Here is a screen capture of tlooknbills' message and thumbnail in Chrome, superimposed with the relative file open in color-managed CS5. Lost some of its purpliness already. I wonder what it would look like if originally opened in sRGB direct from Raw by a well behaved Raw converter other than LR.
(http://i.imgur.com/DO7tXM6.jpg)
-
Thanks to all contributors for this enlightening discussion. Although I have to admit that some arguments are beyond my fullest understanding. But that’s okay because I’m here to learn.
Two thoughts of mine on the recent posts:
- I think I do not care too much if my eyes can differentiate between colors/values. I would appreciate it if those different values are there in the first place and stay in my file as long as possible, because you never know, one day you might want to stretch, bend or blow up those values until they are perceivable as different colors.
- I have experienced the blue-purple shift quite often when I tried to desaturate images in CaptureOne Pro 7 ("saturation -30" for example). Is this due to CO working in some LAB-ish colorspace that is not perceptually uniform? Or could it be just an effect on my monitor (sRGB-ish, profiled with Spyder3)? What would be a save workaround?
-
- I have experienced the blue-purple shift quite often when I tried to desaturate images in CaptureOne Pro 7 ("saturation -30" for example). Is this due to CO working in some LAB-ish colorspace that is not perceptually uniform? Or could it be just an effect on my monitor (sRGB-ish, profiled with Spyder3)? What would be a save workaround?
It was explained by Bart's posted link above of Bruce Lindbloom's (Blue turns Purple) graphical analysis of the non-uniform definitions of color within Lab space and the mathematics involved in mapping certain colors that follow an arch rather than Euclidean math (straight line) mapping of one color definition (blue) within one color space (Lab) and into another (sRGB/AdobeRGB) and the errors that show up on an 8bit video preview.
Like it was said in this thread by other contributors Lab space was created as a color "difference" description model and is now used as a mathematical reference point "Profile Connection Space" PCS operating under the hood of color management processes. It was never designed to be an editing space though tools have been built for it because before color management with digital processes that (and Monitor RGB) was the only intuitive space to work in for commercial press color correction. The scanner was also a color space for source media such as film.
Everything was proprietary back then and so everyone had their own secret sauce for maintaining quality color reproduction. Now color reproduction integrity is controlled with math and algorithms so WYSIWYG is assured across a wide range of devices, not controlled by one company with their own secret sauce. Blue turns purple is just some of the imperfections we have to cope with in signing on to color management processes.
You may be correct, but your demonstration is a bit lacking in detail. This is what happened in the Unconverted image:
1) opened a raw file in humongous ProPhoto
2) automatic/manual adjustments were applied in the raw converter spinning colors around
3) color management then tried to squeeze these wide ranging ProPhoto colors into your monitor's presumed color space using unspecified parameters
4) the video card driver and LUT performed more squeezing - a screen capture was taken
5) the monitor displayed its best (sRGBish) rendition of such corrected colors
Jack Hogan, I'll go with Bruce Lindbloom's explanation. The limiter editing in any color space be it Raw or Jpeg is the display. There's no such thing as twisting, distorting and squeezing color on a display. To test view Photoshop Color Picker for each of two new docs, one in ProPhotoRGB and then switch to an sRGB document. They will look drastically different. In ProPhotoRGB Color Picker select the most intense blue and fill a selection and then convert to sRGB. Turns purple even in a simple color fill. It has nothing to do with getting crazy with color in ProPhotoRGB. It's just about finding the easiest way to get all the color a display can deliver and ProPhotoRGB is the space to do it. It's that simple.
-
I viewed this page in Chrome, which is not color managed.
And you're giving me tips on the technicalities of color management? :o
I wonder what it would look like if originally opened in sRGB direct from Raw by a well behaved Raw converter other than LR.
As I said above, I actually edited that blue crystal switching to sRGB output space in ACR and not only did I get the same results posted in the screengrab, but attempting to get those colors back made ACR's color slider tools worthless. No adjusting could get the vibrance, luminance and hues back. To get those insane looking blues from my cheap $300 sRGB-ish Dell LCD I also used ACR's Camera Calibration Panel Saturation and Hue slider along with Vibrance, Saturation and HSL. I used all the tools.
Switching to working in sRGB in ACR greatly limited their effect.
-
To test view Photoshop Color Picker for each of two new docs, one in ProPhotoRGB and then switch to an sRGB document. They will look drastically different. In ProPhotoRGB Color Picker select the most intense blue and fill a selection and then convert to sRGB. Turns purple even in a simple color fill.
Perhaps, but if your final color space needs to be sRGB what advantage have you had starting off in ProPhoto? Deal with it sooner rather than later.
The limiter editing in any color space be it Raw or Jpeg is the display. There's no such thing as twisting, distorting and squeezing color on a display....It has nothing to do with getting crazy with color in ProPhotoRGB. It's just about finding the easiest way to get all the color a display can deliver and ProPhotoRGB is the space to do it. It's that simple.
Thanks for your opinion, tlooknbill, but I'd like to see for myself, ideally with a difficult file like your blue ball one. And so far I have not yet seen a practical advantage to going through ProPhoto when the final output space is sRGB - in a Raw file to sRGB monitor/print workflow.
In fact I have seen disadvantages to a ProPhoto working color space: sometimes I only realize that some colors are out of gamut or weird at the very end of a lengthy PP session, when I convert to sRGB just before output. Had I noticed it before (as one would if starting off in sRGB), I may not have wasted a lot of time with fine adjustments that now would need to be undone and redone. So unless there are some practical visible advantages to a non-pro like me, I am going to let my output device determine working color space: in 90% of the cases it's sRGB, 10% aRGB.
I am willing to change my ways on the basis of tangible evidence, which your blue ball Raw file could provide. Care to share it?
Jack
-
I am willing to change my ways on the basis of tangible evidence, which your blue ball Raw file could provide. Care to share it?
Sure, I'll share it as long as you find me an upload sharing site other than "Yousendit.com". That site has changed since years I last used it where it now gives me a bunch of confusing information request and dialog boxes to navigate through on top of the ensuing email alerts I didn't ask for.
-
Sure, I'll share it as long as you find me an upload sharing site other than "Yousendit.com". That site has changed since years I last used it where it now gives me a bunch of confusing information request and dialog boxes to navigate through on top of the ensuing email alerts I didn't ask for.
Grand. If you have a gmail account you also get access to google drive. Next to the black Gmail menu at top click on 'Drive' and sign in with your email address and pw. Upload the file to it (you may have to .zip it, I can't remember), set sharing to 'anyone who has the link' and copy/paste the link here. Alternatively Microsoft sky drive.
Jack
-
Grand. If you have a gmail account you also get access to google drive. Next to the black Gmail menu at top click on 'Drive' and sign in with your email address and pw. Upload the file to it (you may have to .zip it, I can't remember), set sharing to 'anyone who has the link' and copy/paste the link here. Alternatively Microsoft sky drive.
Jack
I have a yahoo email account. Will that suffice? I'm not opening a Gmail account for this.
-
I have a yahoo email account. Will that suffice? I'm not opening a Gmail account for this.
Don't think so. I have sent you a private message with my email address. If you mail it to me I'll share it with the group.
[EDIT] Here is Tim's Blue Ball file: https://docs.google.com/file/d/0BzGif7iQ1sgla090XzNGT0p0M2c/edit?usp=sharing
-
Perhaps, but if your final color space needs to be sRGB what advantage have you had starting off in ProPhoto? Deal with it sooner rather than later.
In my workflow, it would be the master RGB space, sRGB is just an iteration to send to the web (where as you've seen, folks with non color managed browsers might be viewing the image. IOW, the old wild west of color <g>).
Short of screen viewing on the web, sRGB has no use for a sophisticated user who's starting their process with raw! So don't throw the baby out with the bath water even if one of your output goals is sRGB to the web. For print, the only time sRGB is useful is when you're handing that data off to clueless end users.
-
Don't think so. I have sent you a private message with my email address. If you mail it to me I'll share it with the group.
Check your email, Jack. I sent it through my yahoo account as an attachment. Let me know if you got it or whether or not you want to proceed by this method of file transfer.
-
G*,
Sometimes color variation is more important than hue fidelity.
man from mars technique (http://www.peachpit.com/podcasts/episode.aspx?e=49a4bdde-6795-4ac9-9265-0abea3978e41)
Also, it's easy to go into lab mode from an rgb document by creating a stamp of all layers (shift-ctrl-alt-e) and converting the layer into a smart object. Double click on the smart object and convert to lab mode.
-
Sometimes color variation is more important than hue fidelity.
Hi,
As Dan says in the video; "there's no accounting for taste in these matters". And that's also coming from the man who says that 16-bit/channel editing is not necessary, which then comes as no surprise.
Also, it's easy to go into lab mode from an rgb document [...]
Which already loses some of the color precision, and that's even before the inevitable conversion back to RGB colorspace. Why go there? What's it supposed to solve? Why not address the issue one might have with an image directly, and predictably?
I think in general it is bad idea to promote a technique that works out differently on each picture (it becomes a gimmick), and it prohibits learning to get true control over the specific things one wants to control.
Cheers,
Bart
-
Starting from Raw, when you know your final image needs to be in sRGB, does it make more sense to
1) open it and perform PP in a much larger color space like ProPhotoRGB, converting to sRGB at the very end; or
2) open the Raw file directly in sRGB and stay in it throughout?
A few years ago I used to use Melissa D65 as my primary working color space, fine tuning images in that large space and only converting to sRGB at the end of the worlflow if needed. Often in these cases the sRGB version required additional fine tuning but at least the original with all my adjustments would be in Melissa D65 for archival purposes and I wouldn't have to revisit it in the future if/when monitors/media improved. Or so went the theory.
It worked well, except when I realized that I was spending a lot of time re-fine tuning most of my keepers because the vast majority of them needed to be turned into sRGB after all. Statistics to the rescue: 90+% of my keepers need to be in sRGB because someone wants a copy via email or because someone wants to make a wallmart print today - only 1 or so a month get the special fine-art treatment, eventually being printed large to perfection.
And I started thinking that if red flowers clipped when going straight to sRGB, they probably still will when ending up in sRGB after ProPhoto: except that in the latter case you'd only realize that you are clipping them at the end of your session, adding additional PP time to get them the way you want them. So I now do it the other way around: sRGB throughout for most keepers and only start in aRGB or a larger space with the very few images that I print large. CNX2, which I use on 100% of my captures (90% of the time ending it there, without needing a trip to CS5), makes it easy to make this change after the fact leaving all other adjustments intact. This thread gave me the impulse to revisit this decision.
Thanks to Tim's Blue Ball (https://docs.google.com/file/d/0BzGif7iQ1sgla090XzNGT0p0M2c/edit?usp=sharing), gollywop (on DPR)'s sunset (https://docs.google.com/file/d/0BzGif7iQ1sglaFdlX3JtbFFsVGc/edit?usp=sharing) and a flower (https://docs.google.com/file/d/0BzGif7iQ1sglcjMtcEgwdUFjeGs/edit?usp=sharing) Raw files, all of which have clipped histograms in sRGB that are not clipped in ProPhoto in the areas of interest, I used ACR 6.7 and CS5 to investigate the differences to be expected when (1) opening a Raw file in ProPhoto, applying adjustments and converting to sRGB at the end (perceptual, no black point compensation) vs opening the same file directly into sRGB and (2) sticking with it throughout.
If opened with the neutral camera profile and no adjustments are applied between opening and converting, the images resulting from the two workflows are virtually indistinguishable. Here Tim's blue ball is shown with workflow 2, 1 and just ProPhoto :-) left to right on my calibrated/profiled Dell U2410 monitor run by Win7, which covers 95% of aRGB.
(http://i.imgur.com/dRbwZKI.jpg)
http://imgur.com/dRbwZKI
Very slight differences between the two workflows became apparent when adjustments were introduced. Something as simple as changing the ACR 6.7 camera profile from Camera Neutral to Camera Landscape caused some slight but visible differences to appear in the two resulting images, neither necessarily better than the other. Switching back to Camera Neutral and pushing a more aggressive adjustment (CEP3 Tonal Contrast at default settings) resulted in this comparison:
(http://i.imgur.com/QgMIufn.jpg)
http://imgur.com/QgMIufn
There are tiny localized differences (sRGB only to the left, ProPhoto converted to sRGB to the right). I know where they are, so I can spot them easily. But neither image is clearly more accurate or preferable to the other in my view.
So unless someone has a good argument for otherwise, I think I am going to stick with my current approach: sRGB as my day-to-day working color space, and aRGB/MelissaD65 for the few occasions when I feel it is necessary. As opposed to the other way around.
Cheers,
Jack
PS For those who are wondering, ProPhoto/aRGB from start to finish give clearly better colors on my U2410 monitor than the sRGB/ProPhoto+sRGB workflows discussed above. This is especially evident in gollywop's sunset image.
-
Starting from Raw, when you know your final image needs to be in sRGB, does it make more sense to
1) open it and perform PP in a much larger color space like ProPhotoRGB, converting to sRGB at the very end; or
2) open the Raw file directly in sRGB and stay in it throughout?
Jack, today's inkjet printers and high-end displays occupy either just about all of or in certain hue areas more than ARGB(98), so to confine your gamut to sRGB is a serious technical and aesthetic limitation on the potential value of the images you produce.
-
Starting from Raw, when you know your final image needs to be in sRGB....
Just that bit alone is something to seriously consider! I can't imagine why you'd shoot raw only to then funnel that data into sRGB which pretty much has only one use (web or on-screen viewing using today's technology).
In the case of an Adobe raw workflow, you're working with high bit ProPhoto primaries, why not just stick with that as the master?
-
Jack, today's inkjet printers and high-end displays occupy either just about all of or in certain hue areas more than ARGB(98), so to confine your gamut to sRGB is a serious technical and aesthetic limitation on the potential value of the images you produce.
Hi Mark,
Thanks for your comment but it answers a different question than mine, which is more practical in nature. Why not choose the color space required by the vast majority of my images (>90%) - with no apparent IQ penalty - and use the wider color space only when needed (<10%), rather than the other way around?
Cheers,
Jack
PS I agree with you (and Andrew and others) that aRGB and ProPhoto are better overall. But if you need to end up in sRGB...
-
Jack, no, my response addresses exactly your question. Let me put it this way: if it is now the case, AND will forever after be the case, that the output devices you and others use for viewing photographs do not have gamut capacity exceeding sRGB, then sure, no one will ever see what can't be seen and working in sRGB would be just fine. But even now, that is manifestly not the case. We can easily see beyond sRGB. My NEC PA271W display and Epson 4900 both see WAY beyond sRGB. You only need to put up a wide gamut photo and dumb it down to sRGB to see the dilution of image quality before your very eyes. Modern technology has greatly by-passed sRGB and will continue evolving to ever expanded gamut capacity. By losing all that valuable information in every photo you process that has intrinsic gamut beyond sRGB, you are sacrificing a lot for no reason.
-
Just that bit alone is something to seriously consider!
I hear you, Munsell is stirring in his grave :)
I can't imagine why you'd shoot raw only to then funnel that data into sRGB which pretty much has only one use (web or on-screen viewing using today's technology).
Is that right? I was under the impression that if you didn't print your own most labs still want sRGB these days.
In the case of an Adobe raw workflow, you're working with high bit ProPhoto primaries, why not just stick with that as the master?
That makes sense, if the end point is not sRGB. But what if it is?
-
What I'm suggesting to you is that your "end-point" SHOULD NOT be sRGB, for solid technical and aesthetic reasons.
-
Jack, no, my response addresses exactly your question. Let me put it this way: if it is now the case, AND will forever after be the case, that the output devices you and others use for viewing photographs do not have gamut capacity exceeding sRGB, then sure, no one will ever see what can't be seen and working in sRGB would be just fine. But even now, that is manifestly not the case. We can easily see beyond sRGB. My NEC PA271W display and Epson 4900 both see WAY beyond sRGB. You only need to put up a wide gamut photo and dumb it down to sRGB to see the dilution of image quality before your very eyes. Modern technology has greatly by-passed sRGB and will continue evolving to ever expanded gamut capacity. By losing all that valuable information in every photo you process that has intrinsic gamut beyond sRGB, you are sacrificing a lot for no reason.
I understand the archival value of working in a larger (although not necessarily the largest) color space, but that's not what the question is about. Keep in mind that I am an amateur photographer with the objective to print one fine (to me :) print a month or so - not every day.
Capture NX2 allows you to reopen an old file, even after extensive global and local editing, and change the original color space in a couple of clicks. It reloads the original Raw data in the new working color space and re-applies each and every single adjustment step in the original sequence in a matter of a seconds. Then I check the histogram and make sure that nothing desirable is clipped. If it is I try to fix it.
If I start in sRGB I need to do this re-opening in less than 10% of the files. If I start in ProPhoto, I need to do it for 90% of the files. There is no question that the image looks a little better in ProPhoto/aRGB on my monitor. But which is better from a practical standpoint for my uses?
-
What I'm suggesting to you is that your "end-point" SHOULD NOT be sRGB, for solid technical and aesthetic reasons.
Ok, what should it be then?
-
OK Jack - I hear you - from a purely personal/practical standpoint it depends on what output devices you use and will use, what you see, whether you care about what you don't see and what you are happy with.
-
Ok, what should it be then?
Minimum ARGB(98).
-
Jack, while I understand your approach I think your initial presumption is not quite right:
Since in 99% of cases people are either printing or viewing in sRGB
first, we see more and more wide gamut monitors (even in offices ... mostly not calibrated/color managed, though). Secondly one of the classical targets of a photo is a print. Sure, many mass printer services require sRGB... but there is a growing number of photo enthusiasts printing at home and using the canned profiles paper vendors provide. Printers/papers produce a larger gamut than sRGB.
sRGB is just the lowest common denominator but even as such it is pretty dated.
Ok, what should it be then?
it depends on the RAW converter you are using ... but generally at least AdobeRGB or better ECI-RGB.
-
I viewed this page in Chrome, which is not color managed. Here is a screen capture of tlooknbills' message and thumbnail in Chrome, superimposed with the relative file open in color-managed CS5. Lost some of its purpliness already. I wonder what it would look like if originally opened in sRGB direct from Raw by a well behaved Raw converter other than LR.
One can test his/her browser by viewing an image (http://color.org/version4html.xalter) in the ICC site. I viewed this site using the latest versions of Chrome, Firefox, Internet Explorer, and Safari. Chrome is partially color managed and the other browsers now appear fully managed as judged by this test. With wide availability of color managed browsers, there is little need to post images in sRGB if your audience is at least slightly sophisticated in color management (which I think would apply to most members of this forum).
Regards,
Bill
-
Bill, regardless of browser, what one sees still depends on the constraint of the display gamut. Many people are using displays that don't "see" more than sRGB, notwithstanding the increasing preference - in the photographic community - for wide gamut displays that see almost all of ARGB(98).
-
@ tlooknbill
Do you mean that there is no way to avoid blue-purple shifts because programs like RAW converters are based on a not perceptively uniform color spaces? There’s this little thingy on Bruce’s website that looks like a cure for LAB’s perceptive shortcomings. It’s downloadable for free. But maybe I got it all wrong.
@ new_haven
Thanks for the link. Looks like fun. I’ll play around with that method one of these days.
@ the general public
I see two main paths:
#1 - Go to the smallest color space as soon as possible. Most probably that’s your monitor’s sRGB-ish gamut. Others may have a little more territory like 98% of AdobeRGB(1998). Look for your weakest link. Only this can give you some sort of WYSIWYG during adjustments. And you might find that most of your output profiles are sRGB anyway.
#2 - Go to a really huge color space for adjustments. Play around and maybe even jump from one space to another, because errors from conversion are likely negligible. If you don't agree, then don’t jump. But in the end you will have to have faith in your last conversion. The one that compresses your files’ most extreme values for output into what your printer, your mother’s monitor or your client’s web browser can handle. Could be that it’s sRGB most of the time.
Any which way you choose, you will have to live with something that looks almost like a blue crystal, but surely isn‘t one if you take a closer look.
-
Bill, regardless of browser, what one sees still depends on the constraint of the display gamut. Many people are using displays that don't "see" more than sRGB, notwithstanding the increasing preference - in the photographic community - for wide gamut displays that see almost all of ARGB(98).
Mark,
Users whose monitor gamut is limited to sRGB or thereabouts, would experience clipping if the gamut of an image with a tagged color space exceeded their monitor's gamut, but at least an image in ProPhotoRGB would not appear washed out.
Regards,
Bill
-
@ the general public
I see two main paths:
#1 - Go to the smallest color space as soon as possible. Most probably that’s your monitor’s sRGB-ish gamut. Others may have a little more territory like 98% of AdobeRGB(1998). Look for your weakest link. Only this can give you some sort of WYSIWYG during adjustments. And you might find that most of your output profiles are sRGB anyway.
#2 - Go to a really huge color space for adjustments. Play around and maybe even jump from one space to another, because errors from conversion are likely negligible. If you don't agree, then don’t jump. But in the end you will have to have faith in your last conversion. The one that compresses your files’ most extreme values for output into what your printer, your mother’s monitor or your client’s web browser can handle. Could be that it’s sRGB most of the time.
Or you can do what Michael and I do, shoot in raw, do the heavy lifting for tone/color correction in the raw processor (and only go to Photoshop for specific retouching, compositing needs) and maintain images in ProPhoto RGB, 16-bit as RGB Master images and transform to specific output profiles for prints or web/multimedia. Considering my ink jet printers can print colors outside of Adobe RGB, let alone outside of sRGB, I think it's a mistake to cut your gamut early in processing. Both printers and displays are increasing their ability to reproduce colors, so I think it's foolish to not take advantage of larger color gamuts for as long as you can. ProPhoto RGB is the only color space (currently in ACR/LR) can can keep all the colors your camera can capture and the colors your printer can print.
As for L*a*b*, it's an interesting color space that allows some unusual color manipulations not possible in RGB, but it's not interesting enough for me to make me move out of RGB processing...but hey, do whatever it takes to get your images they way you want them.
-
If I start in sRGB I need to do this re-opening in less than 10% of the files.
You are not starting with sRGB if you are working with raw data and some processor working in some RGB processing space. Think of sRGB as just another one of many possible color spaces you can end up with.
sRGB is not a print output color space. There are no sRGB printers. There are printers you can feed sRGB and then that data is converted into another color space for that output device. Today, the only reasonable use of sRGB is to show an image to someone on a display. That's what sRGB is based upon (albeit a very old CRT circa early 1990s).
Your final may be sRGB or Epson 3880 Luster RGB. You treat this process the same. The data doesn't have to be in sRGB or Epson 3880 to do 95%+ of the work while maintaining the widest gamut data you are forced to use in the converter.
IF you really want sRGB, at least the closest in terms of what can be produced on your end, set the camera to sRGB.
This video might help you see why targeting an sRGB "output space" isn't a good idea using real images and gamut maps:
High resolution: http://digitaldog.net/files/ColorGamut.mov
Low Res (YouTube): http://www.youtube.com/watch?v=n0bxSD-Xx-Q
-
Quote
The limiter editing in any color space be it Raw or Jpeg is the display. There's no such thing as twisting, distorting and squeezing color on a display....It has nothing to do with getting crazy with color in ProPhotoRGB. It's just about finding the easiest way to get all the color a display can deliver and ProPhotoRGB is the space to do it. It's that simple.
Thanks for your opinion, tlooknbill, but I'd like to see for myself, ideally with a difficult file like your blue ball one. And so far I have not yet seen a practical advantage to going through ProPhoto when the final output space is sRGB - in a Raw file to sRGB monitor/print workflow.
PS For those who are wondering, ProPhoto/aRGB from start to finish give clearly better colors on my U2410 monitor than the sRGB/ProPhoto+sRGB workflows discussed above. This is especially evident in gollywop's sunset image.
I can see from your statement that we share the same opinion about large color spaces giving better colors on our displays.
I can also see I wasted my time uploading the blue crystal ball Raw image so you could see the blue to purple shift in what I thought you were going to process the Raw to get similar results as I showed in my screengrab. You just did a screengrab of an unprocessed Raw file which isn't going to show anything. I don't even understand or see the point of you posting the screen shots.
-
IF you really want sRGB, at least the closest in terms of what can be produced on your end, set the camera to sRGB.
This video might help you see why targeting an sRGB "output space" isn't a good idea using real images and gamut maps:
High resolution: http://digitaldog.net/files/ColorGamut.mov
Low Res (YouTube): http://www.youtube.com/watch?v=n0bxSD-Xx-Q
Thanks for the suggestion and intreresting video Andrew.
-
I can also see I wasted my time uploading the blue crystal ball Raw image so you could see the blue to purple shift in what I thought you were going to process the Raw to get similar results as I showed in my screengrab. You just did a screengrab of an unprocessed Raw file which isn't going to show anything. I don't even understand or see the point of you posting the screen shots.
I thought I was clear in my obective: comparing images processed/rendered in sRGB only versus opened and processed in ProPhoto and converted to sRGB at the end. The differences appear to be minimal as I mentioned, at least with the three example files and adjustments I tried. In the case of your file, the purple shift was there in both workflows, so I would have had to correct for it either way - except that in the ProPhoto workflow I would have realized it only at the end of the session.
Thank you for sharing your file, it was useful at least to me. Apologies if I have wasted your time.
Jack
-
Hi
I think what we need and maybe Adobe will include this at some-point in their development of LR or ACR is the ability to preview or predetermine the image colour gamut. The user then could select the appropriate colour space dependent on the image colour gamut if so desired.
The image is in XYZ at some point in the pipeline so a quick subsampling to LAB for gamut comparison would be quite straight forward.
For example if an image contains a very small colour gamut would it need to be rendered to prophoto or would sRGB suffice? or vice versa.
Either way I think it is important to match as best as possible image gamut space to rendered colour space.
Iain
-
Hi
I think what we need and maybe Adobe will include this at some-point in their development of LR or ACR is the ability to preview or predetermine the image colour gamut. The user then could select the appropriate colour space dependent on the image colour gamut if so desired.
The image is in XYZ at some point in the pipeline so a quick subsampling to LAB for gamut comparison would be quite straight forward.
For example if an image contains a very small colour gamut would it need to be rendered to prophoto or would sRGB suffice? or vice versa.
Either way I think it is important to match as best as possible image gamut space to rendered colour space.
Iain
What is the purpose of having a bunch of Raw/Jpeg files saved in various output color spaces. Schewe, Rodney and others have already given the simplest workflow solution and that is to just keep it in ONE COLOR SPACE and that being 16bit ProPhotoRGB.
You don't need to know about gamut compression. You've got a preview to tell you all you need to know. The "Blue Turns Purple" issue is not a deal breaker. It was just a demonstration to show how editing in sRGB hobbles your color you paid good money for in the form of capture device and wide gamut display.
Raw images are nothing but grayscale luminance representation of voltage measurements from charged photo cells. The display and the color space gives the photographer the means to deciding what colors to turn those grayscales into. sRGB is the worst place to find that out.
-
Adobe could improve the accuracy and usefulness of an OOG overlay. ColorThink has been doing it better than the old PS OOG overlay for years. It would be useful to see in real time, what's out of your current display gamut as you edit and you don't have to cover the image with one color at 100% opacity either.
-
I think what we need and maybe Adobe will include this at some-point in their development of LR or ACR is the ability to preview or predetermine the image colour gamut. The user then could select the appropriate colour space dependent on the image colour gamut if so desired.
The image is in XYZ at some point in the pipeline so a quick subsampling to LAB for gamut comparison would be quite straight forward.
For example if an image contains a very small colour gamut would it need to be rendered to prophoto or would sRGB suffice? or vice versa.
I don't know what type of tool you would like to have, but both ACR and LR have the capability to determine if the gamut of the image fits into a selected color space for the final rendered image. In ACR you can set the preference to render into sRGB. If gamut clipping is apparent as in the histogram of the first image below, select AdobeRGB or ProPhotoRGB to eliminate the saturation clipping.
In LR, the rendering into the selected color space is deferred until the export stage. One can use soft proofing to see if there is clipping when exporting into the final color space as shown in the second image below.
Either way I think it is important to match as best as possible image gamut space to rendered colour space.
If you use 16 bits per pixel, I see no disadvantage in using ProPhotoRGB. If 8 bit output is desired, then a smaller space would be preferable. Personally, I would not take the trouble to go through dozens of images, selecting the appropriate space for each, but would simply use ProPhoto as Jeff recommends. Otherwise, you could use a space that contains the real world surface colors that occur in nature. The size of such a space is shown in the third image below, courtesy of Gernot Hoffmann (http://www.fho-emden.de/~hoffmann/gamuts08072002.pdf). Bruce Lindbloom's BetaRGB might fit the bill.
Regards,
Bill
-
@tlooknbill
Could not sleep after what had been said and did some research. The color-space/-conversion basis of Photoshop indeed seems to be screwed up. For example I found quite informative what Rags Gardner wrote (http://www.rags-int-inc.com/PhotoTechStuff/ColorCalculator/AdobeMath.html). Funny to read that he hopes that Adobe will finally get things straight in CS3 – we're at CS6 right now.
So my understanding is that even if CIELab might not be perceptively uniform (Wikipedia claims it is: "Lab color is designed to approximate human vision. It aspires to perceptual uniformity") it takes just a bit of math to change that and meet with the Munsell criteria. The know-how is there and also the computational capacity of our Macs/PCs would manage to do that trick. It’s a shame that Adobe does not seem to care.
Furthermore the biggest player is unable to get some rather primitve value conversions right, which altogether makes changing color spaces between RGB and LAB in Photoshop so lossy that you better don’t do it, no matter at what bit rate.
None of this has to be this way, and I am waiting for a software that does it right, because I still prefer how changing saturation in LAB is not affecting luminance (color-psychological effects aside). In RGB my images lighten up when boosting saturation and I need to apply another curve to bring those values down again.
-
@tlooknbill
Could not sleep after what had been said and did some research. The color-space/-conversion basis of Photoshop indeed seems to be screwed up. For example I found quite informative what Rags Gardner wrote (http://www.rags-int-inc.com/PhotoTechStuff/ColorCalculator/AdobeMath.html). Funny to read that he hopes that Adobe will finally get things straight in CS3 – we're at CS6 right now.
So my understanding is that even if CIELab might not be perceptively uniform (Wikipedia claims it is: "Lab color is designed to approximate human vision. It aspires to perceptual uniformity") it takes just a bit of math to change that and meet with the Munsell criteria. The know-how is there and also the computational capacity of our Macs/PCs would manage to do that trick. It’s a shame that Adobe does not seem to care.
Furthermore the biggest player is unable to get some rather primitve value conversions right, which altogether makes changing color spaces between RGB and LAB in Photoshop so lossy that you better don’t do it, no matter at what bit rate.
None of this has to be this way, and I am waiting for a software that does it right, because I still prefer how changing saturation in LAB is not affecting luminance (color-psychological effects aside). In RGB my images lighten up when boosting saturation and I need to apply another curve to bring those values down again.
First, human visual perception is non-linear. I don't know what you mean by "perceptually uniform".
Second, if you want to separate luminance from color in RGB you can do it with Photoshop's Blend Modes and don't need conversion to Lab. But every time you do it you will find that after changing contrast in Luminance mode, you will need to add saturation to make the image look "natural". So it's largely pointless for most intents and purposes.
Third, working in 16-bit, the mathematical rounding errors from RGB>Lab conversion will most likely be un-noticeable 99% of the time. But that's not the point.
The main issue is reversibility of image editing. Lab conversion complicates reversibility and creating these complications is largely needless. Yes, there are certain ways of using Lab to make selections based on manipulation of the channels that don't require selection tools, but this isn't the workaday requirement for most intents and purposes. It's good to use when nothing else works as well, but that has been decreasingly the case since years back. No-one should make a theology of this. It's just another tool to use - selectively - when nothing else can do as well more easily.
-
So my understanding is that even if CIELab might not be perceptively uniform (Wikipedia claims it is: "Lab color is designed to approximate human vision. It aspires to perceptual uniformity")
That might have been the goal, but it isn't the reality. CIELAB was 'recommended' by the CIE in 1976, to address a specific problem, namely, while identical XYZ values could tell you when two stimuli would be experienced as the same 'color' by most observers, it did not tell you how 'close' two colors were if they were not exactly the same XYZ value. Where Lab is useful is for predicting the degree to which two sets of tristimulus values will match under defined conditions thus it is not anywhere close to being an adequate model of human color perception. It works well as a reference space for colorimetrically defining device spaces, but as a space for image editing, it has many problems. There are a slew of other perceptual effects that Lab ignores. Lab assumes that hue and chroma can be treated separately, but numerous experimental results indicate that our perception of hue varies with the purity of color. Mixing white light with a monochromatic light does not produce a constant hue, but Lab assumes it does! This is seen in Lab modelling of blues. It's the cause of the dreaded blue-magenta color issues or shifts. Lab is no better, and in many cases can be worse than a colorimetrically defined color space based on real or imaginary primaries.
Furthermore the biggest player is unable to get some rather primitve value conversions right, which altogether makes changing color spaces between RGB and LAB in Photoshop so lossy that you better don’t do it, no matter at what bit rate.
That's simply not accurate. Rather, the need to convert to Lab has been over sold and most just accept this rather than investigate how and why the tools we have work they way they do!
-
None of this has to be this way, and I am waiting for a software that does it right, because I still prefer how changing saturation in LAB is not affecting luminance (color-psychological effects aside). In RGB my images lighten up when boosting saturation and I need to apply another curve to bring those values down again.
Hi,
Topaz Labs "Adjust" could be what you are looking for. It's a Photoshop plug-in, but can also be used without Photoshop in Topaz Labs "photoFXlab", which is a kind of command central for all plugins, but it also offers e.g. layers and masking functionality. 'Adjust' offers, amongst others, Adaptive Saturation, regular saturation, and low Saturation Boost controls, while attempting to leave Luminosity alone.
Cheers,
Bart
-
I am waiting for a software that does it right, because I still prefer how changing saturation in LAB is not affecting luminance (color-psychological effects aside). In RGB my images lighten up when boosting saturation and I need to apply another curve to bring those values down again.
Combinations of Saturation, Vibrance, HSL and Calibration Panel sliders in ACR/LR can do the same Sat/Lum disconnect as in Lab.
The Blue channel Saturation slider in Calibration Panel really is the worst while Sat slider in Basic Panel is the best. No need to go into Lab in Photoshop to apply something as simple as increased saturation. What a cumbersome workflow to have to go into Lab just to add saturation.
I couldn't imagine having to do that on my 3000 Raw shots.
Mixing white light with a monochromatic light does not produce a constant hue, but Lab assumes it does! This is seen in Lab modelling of blues. It's the cause of the dreaded blue-magenta color issues or shifts. Lab is no better, and in many cases can be worse than a colorimetrically defined color space based on real or imaginary primaries.
Interesting. Never heard of monochromatic light, Andrew. What is it and how does it change hue perception that's different from "White Light" Lab doesn't take into account? How does that fit into Bruce Lindbloom's "Blue turns purple" analysis posted earlier? Or are you referring to something different from Bruce's explanation.
-
Combinations of Saturation, Vibrance, HSL and Calibration Panel sliders in ACR/LR can do the same Sat/Lum disconnect as in Lab.
.................. No need to go into Lab in Photoshop to apply something as simple as increased saturation. What a cumbersome workflow to have to go into Lab just to add saturation.
Exactly right, and this has been the case since years back.
-
I don't know what you mean by "perceptually uniform".
It means that moving moving similar distances within the color space will result in similar perceptions of color difference regardless of where in the color space you are. Or to put another way the distance in the color space is uniformly correlated with the magnitude of the color difference.
-
OK, so this goes back to the CIE measurement experience deployed back in the 1920s to delineate and characterize human visual perception. A whole subject on its own, and probably fundamental to much of the colour work we do today, but its specific relevance to the use of the Lab space vs RGB for saturation editing in Photoshop remains somewhat elusive to me.
-
Mixing white light with a monochromatic light does not produce a constant hue, but Lab assumes it does! This is seen in Lab modelling of blues. It's the cause of the dreaded blue-magenta color issues or shifts. Lab is no better, and in many cases can be worse than a colorimetrically defined color space based on real or imaginary primaries.
Interesting. Never heard of monochromatic light, Andrew. What is it and how does it change hue perception that's different from "White Light" Lab doesn't take into account? How does that fit into Bruce Lindbloom's "Blue turns purple" analysis posted earlier? Or are you referring to something different from Bruce's explanation.
Monochromatic light is light of one wavelength, i.e spectral colors.
I think Bruce and Andrew are saying the same thing. It's very easy to see the problem if you plot your working or monitor's color space in LAB. Do it and look at the blue primary. Imagine drawing a vertical line (parallel to the L* axis) through that blue point. As you move up that line you move out of the gamut of your monitor. No look over that closest point on the surface of your monitor's space. What hue do you see? Purple right? If you take the route from the out-of-gamut LAB color directly to face you end up with hue shifts. I've attached a rudimentary (eye-balled) graph.
I also attached a TIF in LAB space that illustrates the problem. In the file the a* and b* numbers are constant. The only thing that changes is L*. The hue change is obvious. It's very easy to think you are simply changing luminosity when working in LAB but you're often unintentionally moving out of gamut and changing hue. You can add a Hue/Saturation adjustment layer to this image and move the hue slider to this and see how different colors exhibit this problem in varying degrees.
-
One can test his/her browser by viewing an image (http://color.org/version4html.xalter) in the ICC site. I viewed this site using the latest versions of Chrome, Firefox, Internet Explorer, and Safari. Chrome is partially color managed and the other browsers now appear fully managed as judged by this test. With wide availability of color managed browsers, there is little need to post images in sRGB if your audience is at least slightly sophisticated in color management (which I think would apply to most members of this forum).
Regards,
Bill
FWIW – I viewed the linked image in Safari v5.1.9 and Firefox v19.0.2 and 20.0. The Safari image looked like what is illustrated for a system supporting ICC version 4 and 2 profiles. The Firefox image looked like what is illustrated for a system supporting ICC version 2 profiles only. This was on a Mac running OS X 10.6.8 using a NEC PA271W monitor. I didn't try Chrome or any other browser.
-
No, it is not just a matter of personal preference - it is technical. ANY departure from linearity will impact colour balance because you are altering the relationship between green and magenta on the a curve and blue and yellow on the b curve at different luminosity levels depending on where the non-linearity sets in, and if those linear curves do not intersect in the middle the colour balance of the whole image is thrown-off. Lab conversion is a needless and cumbersome complication from the get-go for 99% of the image editing the great majority of us ever need to do. There are many things in Photoshop that don't work in Lab mode, so most often you will need to convert back to RGB, and once you do this your Lab adjustments are baked-in and non-reversible, unless you have a separate duplicate image copy with the Lab adjustments converted back to RGB but layered-in. Lab has certain specialized uses that justify its inclusion in the Photoshop arsenal, but making simple adjustments to saturation is not one of them when there are much more straightforward ways of doing this in RGB.
This is not correct. You're thinking about how RGB curves work. In LAB mode, the the 'a' curve does not have a luminosity component, it only adjusts red/green saturation. A symmetrical 'S' curve that isn't so extreme as to have inversions will not throw off the color balance in the way you're suggesting. It will just increase saturation of the less-saturated colors affected by the steep section of the curve more than already-saturated colors that fall along the flatter section of the curve.
Having said that, I think an easier to way to boost just the less-saturated colors is to bring the end-points in, and then adjust the blend-if sliders of the layer properties to feather out the effect on the more saturated colors.
Lab conversion is a needless and cumbersome complication from the get-go for 99% of the image editing the great majority of us ever need to do.
Agree to disagree, I find it sometimes useful and just because you don't use it doesn't mean nobody should be using it.
-
A whole subject on its own, and probably fundamental to much of the colour work we do today, but its specific relevance to the use of the Lab space vs RGB for saturation editing in Photoshop remains somewhat elusive to me.
RGB is essentially based on our eye's ability to see trichromatic color. L*a*b* is a different color theory based on opponency of our eye's receptors. In fact, both theories are correct as our eyes have both trichromatic and opponency aspects.
In terms of using Lab for color correction, there's a school of thought that adjusting the tone curve of the lightness is better then adjusting the curves in RGB because with lightness, the color component is completely removed. There's a fellow with the initials DM that claims that adjusting curves in RGB destroys color hue and saturation. Another fellow whose initials are TK feels adjusting contrast in curves SHOULD modify the saturation (while trying to preserve the hue accuracy).
In Photoshop you can do either...and you don't need to convert to Lab to do so. You can simply set the blend mode of a curves layer to luminance–which while not EXACTLY the same as lightness in Lab, is close enough for the purposes of adjusting the tone curve without effecting hue and sat.
DM think's TK is wrong and as a result doesn't think Camera Raw nor Lightroom can be used for "professional" color correction. On the other hand, TK kinda started this whole digital imaging thingie...and DM is a "grumpy old white guy" still trying to be relevant.
L*a*b* can be useful...but I can't remember that last time I had to resort to converting to Lab in Photoshop for any corrections I could only do in Lab.
-
Combinations of Saturation, Vibrance, HSL and Calibration Panel sliders in ACR/LR can do the same Sat/Lum disconnect as in Lab.
Gee that doesn't sound "cumbersome" at all. ::)
No need to go into Lab in Photoshop to apply something as simple as increased saturation. What a cumbersome workflow to have to go into Lab just to add saturation.
It's not just a simple saturation bump. A/B curves allow you to increase both saturation and separation of colors that need it without over-saturating colors that don't, and without screwing up the luminosity/contrast of the image. It works quite well for images that need it and is easier and more effective than trying to achieve the same effect in RGB mode.
I couldn't imagine having to do that on my 3000 Raw shots.
I can't imagine having to do anything on 3000 Raw shots. You and I are obviously different types of photographers. Doesn't mean I'm doing anything wrong just because I spend more time on individual images than you do.
-
Now look over that closest point on the surface of your monitor's space. What hue do you see? Purple right?
Excellently explained, MarkM.
So this "Blue To Purple" shift in the color managed display preview has nothing to do with the gamut size of the display. I tended to think my sRGB-ish small gamut display was amplifying this effect but seeing others with wider gamut display see the same thing corrected that assumption.
All those blended color curves represented in that 3D color model actually shows how mapping errors occur using a straight line A-to-B approach converting from one color space to another. Looks to me like a lack of precision in plotting just where these primaries blend together to form other colors within each 3D model representation of a color space.
-
This is not correct. You're thinking about how RGB curves work. In LAB mode, the the 'a' curve does not have a luminosity component, it only adjusts red/green saturation. A symmetrical 'S' curve that isn't so extreme as to have inversions will not throw off the color balance in the way you're suggesting. It will just increase saturation of the less-saturated colors affected by the steep section of the curve more than already-saturated colors that fall along the flatter section of the curve.
Having said that, I think an easier to way to boost just the less-saturated colors is to bring the end-points in, and then adjust the blend-if sliders of the layer properties to feather out the effect on the more saturated colors.
Agree to disagree, I find it sometimes useful and just because you don't use it doesn't mean nobody should be using it.
Yes correct - after I wrote that I realized I should have been talking saturation, not luminosity.
And I didn't say it wasn't ever useful. It can be. It's just that most of the time there are easier ways.............I think there is a broad level of experienced support to this perspective.
-
RGB is essentially based on our eye's ability to see trichromatic color. L*a*b* is a different color theory based on opponency of our eye's receptors. In fact, both theories are correct as our eyes have both trichromatic and opponency aspects.
In terms of using Lab for color correction, there's a school of thought that adjusting the tone curve of the lightness is better then adjusting the curves in RGB because with lightness, the color component is completely removed. There's a fellow with the initials DM that claims that adjusting curves in RGB destroys color hue and saturation. Another fellow whose initials are TK feels adjusting contrast in curves SHOULD modify the saturation (while trying to preserve the hue accuracy).
In Photoshop you can do either...and you don't need to convert to Lab to do so. You can simply set the blend mode of a curves layer to luminance–which while not EXACTLY the same as lightness in Lab, is close enough for the purposes of adjusting the tone curve without effecting hue and sat.
DM think's TK is wrong and as a result doesn't think Camera Raw nor Lightroom can be used for "professional" color correction. On the other hand, TK kinda started this whole digital imaging thingie...and DM is a "grumpy old white guy" still trying to be relevant.
L*a*b* can be useful...but I can't remember that last time I had to resort to converting to Lab in Photoshop for any corrections I could only do in Lab.
That was the whole discussion in a nutshell. Very well summarized.
-
FWIW – I viewed the linked image in Safari v5.1.9 and Firefox v19.0.2 and 20.0. The Safari image looked like what is illustrated for a system supporting ICC version 4 and 2 profiles. The Firefox image looked like what is illustrated for a system supporting ICC version 2 profiles only. This was on a Mac running OS X 10.6.8 using a NEC PA271W monitor. I didn't try Chrome or any other browser.
That is interesting. I was using Windows8 and a NEC wide gamut monitor calibrated with Spectraview.
Bill
-
This is not correct. You're thinking about how RGB curves work. In LAB mode, the the 'a' curve does not have a luminosity component, it only adjusts red/green saturation.
This is right in principle, but not so in practice. When photoshop finds super light or super dark (saturated) colors it tries to make them displayable, which can affect the luminosity.
For my part, I like to be able to adjust luminosity / contrast separately from color as controlling one "variable" at a time is easier to my mind. That can, of course, be done as Schewe suggest, in RGB, but this curve steepening technique can produce more pleasing results (probably because it separates the colors more, as someone else has pointed out).
-
That is interesting. I was using Windows8 and a NEC wide gamut monitor calibrated with Spectraview.
Bill
My monitor was also calibrated (using Spectraview II).
-
First of all, don't sweat the small stuff. Conversions between different color modes won't destroy your images if you know what you're doing. As there are more than fifty ways to leave your lover, there are more than fifty ways to fiddle the curves in LAB mode. Want to learn more. Read this:
The Jacob’s Ladder Color Correction Technique (http://www.hcs.harvard.edu/~jrus/colortheory/jl.html)
also check out this Yahoo discussion thread (http://www.curvemeister.com/forum/index.php?topic=2056.0)
-
First of all, don't sweat the small stuff. Conversions between different color modes won't destroy your images if you know what you're doing.
It sure could if you're silly enough to do this in 8-bit per color!
A keeper on the sillyness of conversions not needed by the late great Bruce Fraser in response to the Lab conversion craze started years ago. What Bruce wrote then is as true today. Plus I don't see anything in your link that couldn’t be achieved faster, with no data loss in a good raw converter.
Let me make it clear that I'm not adamantly opposed to Lab workflows. If
they work for you, that's great, and you should continue to use them.
My concern is that Lab has been oversold, and that naive users attribute to
it an objective correctness that it does not deserve.
Even if we discount the issue of quantization errors going from device space
to Lab and vice versa, which could be solved by capturing some larger number
of bits than we commonly do now, (though probably more than 48 bits would be
required), it's important to realise that CIE colorimetry in general, and
Lab in particular, have significant limitations as tools for managing color
appearance, particularly in complex situations like photographic imagery.
CIE colorimetry is a reliable tool for predicting whether two given solid
colors will match when viewed in very precisely defined conditions. It is
not, and was never intended to be, a tool for predicting how those two
colors will actually appear to the observer. Rather, the express design goal
for CIELab was to provide a color space for the specification of color
differences. Anyone who has really compared color appearances under
controlled viewing conditions with delta-e values will tell you that it
works better in some areas of hue space than others.
For archival work, you will always want to preserve the original capture
data, along with the best definition you can muster of the space of the
device that did the capturing. Saving the data as Lab will inevitably
degrade it with any capture device that is currently available. For some
applications, the advantages of working in Lab, with or without an LCH
interface, will outweigh the disadvantages, but for a great many
applications, they will not. Any time you attempt to render image data on a
device, you need to perform a conversion, whether you're displaying Lab on
an RGB monitor, printing Lab to a CMYK press, displaying scanner RGB on an
RGB monitor, displaying CMYK on an RGB monitor, printing scanner RGB to a
CMYK press, etc.
Generally speaking, you'll need to do at least one conversion, from input
space to output space. If you use Lab, you need to do at least two
conversions, one from input space to Lab, one from Lab to output space. In
practice, we often end up doing two conversions anyway, because device
spaces have their own shortcomings as editing spaces since they're generally
non-linear.
The only real advantage Lab offers over tagged RGB is that you don't need to
send a profile with the image. (You do, however, need to know whether it's
D50 or D65 or some other illuminant, and you need to realise that Lab (LH)
isn't the same thing as Lab.) In some workflows, that may be a key
advantage. In many, though, it's a wash.
One thing is certain. When you work in tagged high-bit RGB, you know that
you're working with all the data your capture device could produce. When you
work in Lab, you know that you've already discarded some of that data.
-
First of all, don't sweat the small stuff. Conversions between different color modes won't destroy your images if you know what you're doing. As there are more than fifty ways to leave your lover, there are more than fifty ways to fiddle the curves in LAB mode. Want to learn more. Read this:
The Jacob’s Ladder Color Correction Technique (http://www.hcs.harvard.edu/~jrus/colortheory/jl.html)
also check out this Yahoo discussion thread (http://www.curvemeister.com/forum/index.php?topic=2056.0)
Jacob and I don't share the same sense of color balance and color aesthetics just as it's always been every time I see mages edited in Lab space. Folks who work this way are more enamored with their own cleverness in their command of the process over getting color that doesn't look butt ugly or distorted in some way as defined not only from a color constancy aspect but from a color design sensibility that was established 100's of years ago by renaissance artists like Rembrandt and Vermeer onto Kodak color scientist's development of the photo chemical silver halide process.
Now I know why mathematicians, scientists, engineers and your general gear head don't make very good visual artists.
-
It sure could if you're silly enough to do this in 8-bit per color!
A keeper on the sillyness of conversions not needed by the late great Bruce Fraser in response to the Lab conversion craze started years ago. What Bruce wrote then is as true today. Plus I don't see anything in your link that couldn’t be achieved faster, with no data loss in a good raw converter.
I have seen some great work by those only use 8-bit GIMP as their chosen pixel manipulation tool. What's the orthodox here? Perhaps you can lecture them on 8-bit vs 16-bit as it has turned out pretty religious these days.
For me, JEPG capture works fine since I am very happy with what I can get in camera, and what I can do in post. 16-bit JPEG? I am not so sure?
Jacob and I don't share the same sense of color balance and color aesthetics just as it's always been every time I see mages edited in Lab space. Folks who work this way are more enamored with their own cleverness in their command of the process over getting color that doesn't look butt ugly or distorted in some way as defined not only from a color constancy aspect but from a color design sensibility that was established 100's of years ago by renaissance artists like Rembrandt and Vermeer onto Kodak color scientist's development of the photo chemical silver halide process.
Now I know why mathematicians, scientists, engineers and your general gear head don't make very good visual artists.
You sound like you know what you're doing since you are not one of those who do things by numbers as you mentioned above.
For me, when it comes down to color inside Photoshop, I can't really see things that others can easily spot. The Info Panel is my guiding star because it reveals helpful numbers in all sorts of revealing ways to help me getting things done, even tho I am no scientist/engineer/math/gear head. I admire those, such as Amy Dresser, who were born with innate ability to tell even slightest change in hue, saturation, and brightness levels just using their naked eyes. You sound like you're one of those who I admire. Does that mean you're better and I am inferior because I have to reply on the numbers revealed by the Info Panel? Secondly, Photoshop gives us more than just three channels natively. Why throw away all the possibilities we're given?
-
Here's some color corrections I performed on "downsized for web" jpegs in Adobe Camera Raw. The first link below shows how I corrected for the contrast/saturation "distortion" many complain about working in RGB space and end up turning to Lab to fix. I'm well aware of this kind of distortion and thus figured out a simple way that doesn't involve a long drawn out, convoluted editing routine to remedy.
http://photo.net/digital-darkroom-forum/00Toub
This correction of the green rock wall image below was also done in ACR, but even though the poster preferred my version over the others he didn't seem to want the ACR edits which are MUCH easier to convey and post screengrabs for than a bunch of complicated layer blending mode and Lab curve instructions.
http://photo.net/beginner-photography-questions-forum/00YmG4
I'll take those results over what I'ld get doing it in Lab. The color design of the original image was preserved to boot.
-
I have seen some great work by those only use 8-bit GIMP as their chosen pixel manipulation tool. What's the orthodox here?
For one, to separate aesthetics of images from the technical realities of image processing in terms of workflow, best image quality, flexibility and so forth. Now do you want to bring up great work which is an aesthetic discussion? Or continue on with the realities of image processing on data and it's effect?
-
It sure could if you're silly enough to do this in 8-bit per color!
A keeper on the sillyness of conversions not needed by the late great Bruce Fraser in response to the Lab conversion craze started years ago. What Bruce wrote then is as true today. Plus I don't see anything in your link that couldn’t be achieved faster, with no data loss in a good raw converter.
"One thing is certain. When you work in tagged high-bit RGB, you know that
you're working with all the data your capture device could produce. When you
work in Lab, you know that you've already discarded some of that data."
If I recall correctly, Bruce also once pointed out that whenever you edit an image, data are thrown away as pixels that were originally at different levels are compressed into one level. This creates spikes and holes in the histogram. However, we choose to make the edit anyway, as it improves the image. As you imply, working with 16 bit data minimizes the holes and they are usually visually loss-less. With 8 bit data, posterization may occur with edits, but this is much less likely when one is dealing with a 16 bit space. IMHO, too much is being made of this data loss, which is visually loss-less in a 16 bit space. There may be good reasons to avoid trips to and from L*a*b, but data loss is not one of them in most cases.
Bill
-
For one, to separate aesthetics of images from the technical realities of image processing in terms of workflow, best image quality, flexibility and so forth. Now do you want to bring up great work which is an aesthetic discussion? Or continue on with the realities of image processing on data and it's effect?
For centuries, what really matters for any visual arts has been the final work. Do viewers really care if one has used 64-bit or 8-bit in his workflow? Or do they really care whether or not one has made some trips back and forth between RGB, LAB and CYMK color modes? I hate to sound cynical but I was led to believe great art comes from artists' internal worldview and their creativity/innovation. In the age of digital tools, that's not true anymore?
-
For centuries, what really matters for any visual arts has been the final work. Do viewers really care if one has used 64-bit or 8-bit in his workflow? I hate to sound cynical but I was led to believe great art comes from artists' internal worldview. In the age of digital tools, that's not true anymore?
It is true and totally immaterial to this discussion about increasing color saturation and the use of Lab.
-
With 8 bit data, posterization may occur with edits, but this is much less likely when one is dealing with a 16 bit space. IMHO, too much is being made of this data loss, which is visually loss-less in a 16 bit space.
Agreed. So we have high bit data. Where did it come from? Could the original input controls have provided the color appearance desired or did someone have to use Photoshop after the fact to get the look they wanted?
-
Hi,
Topaz Labs "Adjust" could be what you are looking for. It's a Photoshop plug-in, but can also be used without Photoshop in Topaz Labs "photoFXlab", which is a kind of command central for all plugins, but it also offers e.g. layers and masking functionality. 'Adjust' offers, amongst others, Adaptive Saturation, regular saturation, and low Saturation Boost controls, while attempting to leave Luminosity alone.
Cheers,
Bart
I 'd suggest (not sure if that already suggested up the thread) CurveMeister ( http://www.curvemeister.com/ ) , that is the proper tool.
-
@ Mark D Segal
Totally agree about the reversibility issue. But my understanding is that sooner or later Photoshop sends every image file through CIELab, even with RGB>RGB conversions, so you could apply LAB-adjustments to the file (not the preview) at that later stage, for example together with conversion to output color space.
@ digitaldog
CIELab probably isn’t even close to perceptually uniform, but that CIELab_to_UPLab.icc by Bruce Lindbloom doesn’t seem to be such a bad workaround. I think RPP is using this file, and to good success. I don’t think adjustments in RGB don’t work at all, and maybe its construction has a lot of advantages, but I am a little more comfortable with a clear separation of L* and a*/b* curves. Furthermore blending modes in RGB do not seem to work to the same effect (see also posts by Schewe and jrp) – which is funny since to my understanding under the hood Photoshop is somehow going back to something LAB-ish anyway. I also like the effect of color separation.
@ BartvanderWolf
Thanks for suggesting Topaz Adjust. I will have a look at the trial version.
@ tlooknbill
I am more of a Capture One guy and never got used to LR/ACR. Nothing based on facts, just personal liking.
@ JeffKohn
Thanks for your posts.
"and then adjust the blend-if sliders of the layer properties to feather out the effect on the more saturated colors"
Didn’t try that before but works like a charm. Again thanks a lot!
@ Vladimirovich
Thanks for the link. I will have a look at that tool. (And I really don’t care whether it’s connected to "DM" or not since I’m too young to remember when those LAB/RGB wars took place).
-
But my understanding is that sooner or later Photoshop sends every image file through CIELab, even with RGB>RGB conversions, so you could apply LAB-adjustments to the file (not the preview) at that later stage, for example together with conversion to output color space.
Not so! An old urban legend. Not necessary, time consuming. Photoshop does NOT convert to Lab to make such conversions, it uses Lab as a profile connection space to convert between color spaces. What happens is that when you ask for a color conversion, Photoshop builds a conversion table from source to destination using LAB to find the equivalent values. It's done in 20-bit precision resulting in fewer quantization errors than you would actually converting the pixels to Lab!
-
Aha. Thanks. So I learned something again.
That’s probably good news for RGB>RGB conversions – but makes me wonder why not the same precision is used when converting RGB>LAB/LAB>RGB.
-
@Andrew:
For some reason I thought the icc spec mandated XYZ to be used as the profile connection space with matrix profiles (I haven't tried to look it up again). This would seem to be computationally easier than using LAB. I'm sure it's inconsequential, but I'm curious—do you know for sure that LAB is used as PCS for everything under the hood in photoshop?
-
I believe Lab is used whenever a 'perceptual' intent is called and the profile allows it.
-
For some reason I thought the icc spec mandated XYZ to be used as the profile connection space with matrix profiles (I haven't tried to look it up again).
As far as I know, v2 color space (display class) has PCS in XYZ, but v4 profiles can be in Lab. The sRGB v4 ICC preference beta has a PCS of Lab.
-
For some reason I thought the icc spec mandated XYZ to be used as the profile connection space with matrix profiles (I haven't tried to look it up again). This would seem to be computationally easier than using LAB. I'm sure it's inconsequential, but I'm curious—do you know for sure that LAB is used as PCS for everything under the hood in photoshop?
One can easily check the PCS for a given profile with the freeware Profile Insepctor (http://www.color.org/profileinspector.xalter) from the ICC.
AdobeRGB is a matrix profile and the PCS is XYZ. The profile for my Epson 3880 shown in the illustration is a lookup type profile as indicated by the large size (compare to the AdobeRGB size) and it is LAB. This information might be of interest to some, but I don't know what to make of it.
Bill
-
AdobeRGB is a matrix profile and the PCS is XYZ. The profile for my Epson 3880 shown in the illustration is a lookup type profile as indicated by the large size (compare to the AdobeRGB size) and it is LAB. This information might be of interest to some, but I don't know what to make of it.
Input and output class profiles generally use Lab and are table based profiles. Display class (as in working spaces) are generally matrix based, not table based and generally use XYZ although since v4 display profiles can have multiple rendering intends, the PCS can be Lab.
-
Something promising I found a little after the death of this thread:
Vibrance correction in RawTherapee (currently 4.0.10.72 for Mac).
Looks promising, sounds well done.
You migth want to have a look at this for further details:
http://jacques.desmis.perso.neuf.fr/RT/vibrance2.html
Only pity: RT 4.0.10.72 runs on my Mac at work (Mac OS 10.6.8.) but not at home (Mac OS 10.8…). Will have to figure out where the fault is …
-
Only pity: RT 4.0.10.72 runs on my Mac at work (Mac OS 10.6.8.) but not at home (Mac OS 10.8…). Will have to figure out where the fault is …
The RT blog/download has compilations for 10.7 and 10.8 (i run 10.7 and the current 10.7 compilation works for me). One thing I have run up against previously that has caused older compilations to crash during launch has been the pesky "libcups.2.dylib" issue. The OS library seems to be in conflict with the one contained within the RawTherapee.app. The workaround that I have used with success is to copy libcups.2.dylib from my OS and paste a copy into the RawTherapee.app/Contents/MacOS/lib folder of the Raw Therapee application (replace the RT version with the OS version). This will get it to launch and run. Try the OS appropriate (10.8 ) version on your newer OS machine and see if it works before attempting this kludge.
I noticed in the most recent OS X 10.7 application that the libcups.2.dylib library is not present in the lib folder within the application, so maybe that clears up some of the problems on 10.7 and >.
kirk
-
Thanks, Kirk, I’ll have a look at that.
In my case the app launches but does not output converted tifs. I see that the process starts but it does not come to an ending. First I thought that my machine might well be a bit lame (1.8 GHz Intel i7 with 4 GB DDR3 @ 1333MHz), but after an hour or so and nothing further happening … No error message though.
-
Thanks, Kirk, I’ll have a look at that.
In my case the app launches but does not output converted tifs. I see that the process starts but it does not come to an ending. First I thought that my machine might well be a bit lame (1.8 GHz Intel i7 with 4 GB DDR3 @ 1333MHz), but after an hour or so and nothing further happening … No error message though.
Oh. That's a horse of a different color.
good luck,
kirk
-
I think RPP is using this file, and to good success.
RPP does certain postdemosaick (note that WB, curves, expocorrections, etc - are predemosaick in RPP) adjustments like saturation in UPLab, yes...