Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: Robert Ardill on June 29, 2014, 06:37:22 am
-
Hi,
If you have a document in Photoshop in Lab with a single color, black, Lab: 0,0,0 and you change the value to 0,127,0 you get a dark red (RGB 62,0,0). if you change the value to 0,0,-127 you get a dark blue. Changing to 0,-127,0 or 0,0,127 does nothing. However with a small amount of luminance the screen color goes to dark green and dark yellow respectively.
Changing the mode back from Lab to RGB retains the color, so what was Lab 0,127,0 is still RGB 62,0,0; however the Lab value is now 17,60,29.
I assume that what's happening is that with the red and blue that there is a colorimetric remapping to the nearest color in the default working space / monitor space. As 0,x,y is automatically outside the monitor's gamut, the nearest mapping is along the red or blue envelope. Yellow is up near the white so the nearest mapping will remain black. Green is a bit confusing as it does stretch down to black, so I would have thought that 0,-127,0 would be a very dark green (and maybe it is but I can't see it).
Is this correct? If not, what is the reason for this rather weird effect?
Robert
-
Hi
You are travelling around the CIEL*a*b* colour encoding space. There are areas of this encoding space that do not relate to perceived colours, hence the black
-
Hi,
If you have a document in Photoshop in Lab with a single color, black, Lab: 0,0,0 and you change the value to 0,127,0 you get a dark red (RGB 62,0,0). if you change the value to 0,0,-127 you get a dark blue.
Robert
OT, but, as I understand L*a*b*, the negative-most value is -128, not -127. Probably due to signed 8-bit binary arithmetic.
cheers,
-
Hi
You are travelling around the CIEL*a*b* colour encoding space. There are areas of this encoding space that do not relate to perceived colours, hence the black
Well yes, however I think the reason for the shift I describe is not so much that we can't view that color, but because that color does not exist in the working-space. The CMM should map colors like 0,x,y to the working-space black ... and perhaps some CMMs do, but Adobe ACE seems to map them to the nearest point on the working-space gamut envelope: and this nearest point could be blue rather than black ... as here, for example:
(http://www.irelandupclose.com/customer/LL/Lab-mapping.jpg)
I expect we could have similar and unexpected color shifts whenever we go significantly outside the working-space gamut while working in Lab. I guess the good thing is that a) we can see the color shift, and b) when we convert back to RGB the shift is retained. It can be a bit weird to see black becoming blue or red though!
Robert
-
First, the mathematical conversion it's doing is based on the working space. The calculations have nothing to do with the monitor's gamut. On the same OS, using the same version of Photoshop, using the same working space, you'll get identical conversions regardless of the monitor or monitor profile used.
Second, Photoshop's Color Picker just breaks down out of gamut. I wouldn't try to read into why it's giving you the values that it is. As for why, we'd have to see the programming behind Color Picker to see why it comes up with what it comes up with... But, in the end, it's because Adobe didn't build in generating an error out of gamut, and instead producing a garbage answer that someone might mistakenly rely upon.
-
OT, but, as I understand L*a*b*, the negative-most value is -128, not -127. Probably due to signed 8-bit binary arithmetic.
cheers,
As many programs do, Photoshop encodes a* and b* from [-128, 127]. But, unfortunately, there are real-world colors that are outside this range. Some other programs, such as LCMS (sometime between v1.19 and 2.5) allow for a wider a* and b* range.
-
First, the mathematical conversion it's doing is based on the working space. The calculations have nothing to do with the monitor's gamut. On the same OS, using the same version of Photoshop, using the same working space, you'll get identical conversions regardless of the monitor or monitor profile used.
I think both color spaces are relevant, as can be seen from the gamut plot below:
(http://www.irelandupclose.com/customer/LL/argb-mrgb.jpg)
What we see has to be firstly mapped to the working space and then it has to be mapped to the monitor space. If the monitor space is much smaller than the working space (as is the case in the plot above) then the working-space color will be outside the monitor gamut and so it will have to be clipped. What we see is the monitor-space color, not the working-space color. In the above example, the Lab value of 0,0,60 will get mapped to a blue in the working space, but then get remapped to a dark cyan in the monitor space. So with this particular monitor, going from 0,0,0 to 0,0,127 will appear as going from black (actually dark gray) to cyan, not black to blue.
Robert
-
What we see on the monitor does have to do with the monitor's gamut and profile.
But, the mathematical conversions ColorPicker is showing you (between LAB, RGB, HSL, CMYK) don't take the monitor's gamut or profile into consideration at all.
Someone could run the math and prove me wrong, but intuitively, I really think LAB 0,x,y should always map to RGB 0,0,0 (in a sane working space.) With L=0, I just don't see how you can have anything else. Or, alternatively, perhaps it's better to say that LAB 0,x,y is an imaginary/invalid value to begin with, so it's transformations to RGB/other is undefined.
-
Someone could run the math and prove me wrong, but intuitively, I really think LAB 0,x,y should always map to RGB 0,0,0 (in a sane working space.) With L=0, I just don't see how you can have anything else. Or, alternatively, perhaps it's better to say that LAB 0,x,y is an imaginary/invalid value to begin with, so it's transformations to RGB/other is undefined.
The way I do the math, with an L* of 0, CIE 1931 XYZ comes out this way:
Y = 0
X = a* times 257 times 10^-6
Z= -b* times 642 times 10^-6
So there's already some weirdness built into CIEL*a*b*.
From a chromaticity point of view,
x = a* times 257 over (a* times 257 - b* times 642) and
y = 0
So none of those xy values are visible.
Somebody please check my math.
Jim
-
What we see on the monitor does have to do with the monitor's gamut and profile.
But, the mathematical conversions ColorPicker is showing you (between LAB, RGB, HSL, CMYK) don't take the monitor's gamut or profile into consideration at all.
Someone could run the math and prove me wrong, but intuitively, I really think LAB 0,x,y should always map to RGB 0,0,0 (in a sane working space.) With L=0, I just don't see how you can have anything else. Or, alternatively, perhaps it's better to say that LAB 0,x,y is an imaginary/invalid value to begin with, so it's transformations to RGB/other is undefined.
Yes, I think that's correct. For example, using Bruce Lindbloom's CIE Color Calculator, Lab 0,-127,0 converts to RGB -something,+something,-something (the something depends on the Ref White, RGB Color Model, etc). In other words a nonsense color or imaginary color. Perhaps another way of thinking about it is that it's a bug in Photoshop as it should not allow one to specify a color outside of the RGB working space (in the same way that you cannot set an RGB color outside of the working space when working in RGB). Or at least have a warning to say that we've potentially gone out-of-gamut.
What I've learnt from this little aside is that when in Lab mode it's a good idea to soft-proof to the working space (say Adobe RGB), or to the destination space if we are adjusting for print, with Gamut Warning turned on. That way we won't inadvertently stray out of gamut (which is VERY easy to do in Lab!).
Robert
-
It's a good question that reveals some interesting things about CIE colorimetry.
A few observations:
1. The monitor profile is irrelevant as Mike points out. It's just simple math and it will be the same regardless of what display you are using. It would be an odd result indeed if you plugged in a black and white monitor and all your LAB to RGB conversions came out with equal R,G, and B numbers in the color picker to reflect the greyscale monitor.
2. Negative RGB numbers may be, but are not necessarily imaginary colors, they are just out of the gamut of that RGB space. It's quite possible to convert LAB values of real colors into small RGB spaces and end up with negative values — they are still real colors.
3. It's not a bug in photoshop; it's the way the math actually works out. It helps to think about it in terms of LAB -> XYZ rather than LAB ->RGB. You have four conversions:
1. LAB[0, 127, 0] -> XYZ[ 5.7, 0, 0]
2. LAB[0, -127, 0] -> XYZ[-3.1, 0, 0]
3. LAB[0, 0, 127] -> XYZ[0, 0, -8.9]
4. LAB[0, 0, -217] -> XYZ[0, 0, 50.3]
CIE XYZ was specifically designed to avoid negative values. So examples 2 & 3 can be thought of as truly black in XYZ, but examples 1 and 4 are not. When you think about how the math works and how L* in LAB is tied directly to Y in XYZ which roughly corresponds to green/yellows it begins to make a little sense. To go from XYZ to a particular RGB space you will use the colorimetric intent find the nearest value on the solid formed by the primaries of the space. In examples 2 and 3 this will be the black point, but in examples 1 and 4 this will on the face of the solid or the red or blue axis of the solid depending on the space in question. When you then multiply by the conversion matrix will result in a non black RGB number.
You can blame the CIE for the non-intuitiveness of this result, but not Adobe.
4. I'm doubtful that it would be helpful to limit LAB values to a working RGB space. When you are working in LAB mode, you are not in an RGB space and therefor don't have a working RGB space to use as a limit. If you want to work within the limits of an RGB space, use that space as your working space.
-
It's a good question that reveals some interesting things about CIE colorimetry.
A few observations:
1. The monitor profile is irrelevant as Mike points out. It's just simple math and it will be the same regardless of what display you are using. It would be an odd result indeed if you plugged in a black and white monitor and all your LAB to RGB conversions came out with equal R,G, and B numbers in the color picker to reflect the greyscale monitor.
Thank you for your illuminating ( ;D) reply. My understanding is that RGB numbers are device-dependent, which is one of the reasons for working-spaces, that they standardize the numbers for a range of output devices. So the RGB value we read when we are in, say, Adobe RGB, will always be the same, irrespective of what monitor is connected, but the actual RGB numbers sent to the monitor will depend on the monitor. So there's a transform from working-space to output, using the monitor profile.
If that is the case then the RGB numbers that the color picker show will always be the same because these are the working-space numbers, but we will see different colors (or grays) depending on the monitor, as below:
(http://www.irelandupclose.com/customer/LL/argb-mrgb.jpg)
Is that not the case? I know I'm being a bit picky, but it's only in an attempt to understand what's going on.
2. Negative RGB numbers may be, but are not necessarily imaginary colors, they are just out of the gamut of that RGB space. It's quite possible to convert LAB values of real colors into small RGB spaces and end up with negative values — they are still real colors.
I was going to say that I now understand that, but actually I don't. Surely RGB 0,0,0 means black, in whatever working-space you use. So I don't see how negative RGB numbers can make any sense (or indicate an out-of-gamut color). The same applies to devices, surely: RGB 0,0,0 means the blackest black that the device can reproduce and even if the black of device A is less black than the black of device B, going from device A black to device B black does not result in negative RGB numbers: it just results in a darker black (if the mapping allows for this), or in positive RGB numbers (if the mapping does not). Similarly, going from B to A, what will happen is that the A black will be less black and will show a range of device B blacks as 0,0,0.
To me, RGB 0,0,0 means an absence of the 3 primaries: in the physical world it would mean a completely flat spectrum in the visible space. Negative RGB values would mean that the spectrum was negative, which it surely cannot be.
I see no reason why LAB or XYZ should not have imaginary colors, or colors that cannot be seen by us (for example, the models could be extended to the UV or infra-red ranges). But RGB is for the real world, the world that we can see (not the one we can imagine), and the one that we can reproduce. We cannot see or reproduce a negative RGB number, so it cannot exist, real or imagined. We cannot represent UV or IR in any sort of RGB model ... it would have to be URGBI!
The negative RGB component will have to be set to zero or to a positive number.
So ... still confused.
3. It's not a bug in photoshop; it's the way the math actually works out. It helps to think about it in terms of LAB -> XYZ rather than LAB ->RGB. You have four conversions:
1. LAB[0, 127, 0] -> XYZ[ 5.7, 0, 0]
2. LAB[0, -127, 0] -> XYZ[-3.1, 0, 0]
3. LAB[0, 0, 127] -> XYZ[0, 0, -8.9]
4. LAB[0, 0, -217] -> XYZ[0, 0, 50.3]
CIE XYZ was specifically designed to avoid negative values. So examples 2 & 3 can be thought of as truly black in XYZ, but examples 1 and 4 are not. When you think about how the math works and how L* in LAB is tied directly to Y in XYZ which roughly corresponds to green/yellows it begins to make a little sense. To go from XYZ to a particular RGB space you will use the colorimetric intent find the nearest value on the solid formed by the primaries of the space. In examples 2 and 3 this will be the black point, but in examples 1 and 4 this will on the face of the solid or the red or blue axis of the solid depending on the space in question. When you then multiply by the conversion matrix will result in a non black RGB number.
Yes, that makes good sense and is an excellent explanation, thank you! I assume that the XYZ numbers will be set to 0 if they go negative. But what does XYZ 0,0,30 mean? It translates to Lab 0,0,-115 and RGB -25,15,145 (in ProPhoto). So this is a perfectly valid XYZ color, which translates to a perfectly valid Lab color ... but to a strange (read weird) RGB number. What Photoshop does is to set the RGB values to 0,15,145, so it is preventing negative RGB numbers. A more intelligent mapping would be to set the RGB values to 0,0,0 as this would give a black rather than a blue.
It would seem to me that it would have been a sensible and simple mapping algorithm to say that if L or Y is zero then RGB=0,0,0, irrespective of the maths.
I guess this is just the disconnect between maths and the real world ... but surely that means that the model is flawed (in which case it should be possible to correct it - and if the CIE will not, why should Adobe not do so?).
4. I'm doubtful that it would be helpful to limit LAB values to a working RGB space. When you are working in LAB mode, you are not in an RGB space and therefor don't have a working RGB space to use as a limit. If you want to work within the limits of an RGB space, use that space as your working space.
Well there are reasons for working in Lab, simply from an editing point of view (for example, some people think it's advantageous to sharpen only the L channel, color balance is probably easier to do in Lab ...). But in a program like Photoshop, which is used to produce visual output, surely the editing should behave in a rational way ... in other words, even if it makes sense to have colors with no luminance in Lab, it really does not when it comes to visual perception, and it makes even less sense for the color with no luminance to show as red or blue. Simply applying the working-space gamut to the Lab values will ensure that (and making Lab 0,x,y = RGB 0,0,0). This could be an option in Lab, so it would still be possible to work in imaginary colors or weird mappings for those of us who would like to.
At any rate, it is possible to use Photoshop's gamut warning if we soft-proof to the working space, which is at least something ... but not much as it only kicks in at around Lab 0,0,-28 so we can still get dark blues with zero luminance :(
Robert
-
If that is the case then the RGB numbers that the color picker show will always be the same because these are the working-space numbers, but we will see different colors (or grays) depending on the monitor, as below:
Is that not the case?
That is the case.
Well there are reasons for working in Lab, simply from an editing point of view (for example, some people think it's advantageous to sharpen only the L channel, color balance is probably easier to do in Lab ...).
Lab is kind of a crappy working space (you want to go there?) ;D
And no, you don't need to convert to Lab, potentially losing a lot of data just for sharpening, we have the Fade... Luminosity mode which serves the same purpose and provides more control, all while staying in your RGB working space. Lab as an editing space is hugly oversold!
-
I was going to say that I now understand that, but actually I don't. Surely RGB 0,0,0 means black, in whatever working-space you use. So I don't see how negative RGB numbers can make any sense (or indicate an out-of-gamut color). The same applies to devices, surely: RGB 0,0,0 means the blackest black that the device can reproduce and even if the black of device A is less black than the black of device B, going from device A black to device B black does not result in negative RGB numbers: it just results in a darker black (if the mapping allows for this), or in positive RGB numbers (if the mapping does not). Similarly, going from B to A, what will happen is that the A black will be less black and will show a range of device B blacks as 0,0,0.
To me, RGB 0,0,0 means an absence of the 3 primaries: in the physical world it would mean a completely flat spectrum in the visible space. Negative RGB values would mean that the spectrum was negative, which it surely cannot be.
The negative RGB component will have to be set to zero or to a positive number.
So ... still confused.
In an RGB device space, negative numbers almost always make no sense. Zero marks one end of the gamut in each primary. In an RGB working space, if the programs doing the work are set up for it, negative numbers can be very useful, and have well-defined meaning. In fact, with the CIE 1931 rbar, gbar, bbar color matching curves, the red primary spends a lot of time in negative territory as the spectral local is traced. See here (http://en.wikipedia.org/wiki/CIE_1931_color_space#mediaviewer/File:CIE1931_RGBCMF.svg) for the curves.
Plot three RGB primaries in xy chromaticity space. The gamut of colors represented by positive values of each of the primaries is defined by the triangle connecting the three points. Oops, there's no place to put three primaries that covers everything that monitor can present and everything that printers can print! What to do? We can put one or more of the primaries outside the spectral locus and continue to only allow positive amounts of them (that's what ProPhoto RGB does), or we can continue to have physically realizable primaries and allow negative values of some or all (that's what PhotoCD did -- Kodak was not consistent on this point).
You can't build a monitor with primaries outside the horseshoe. You can't build a monitor that emits negative amounts of photons. But in a working space, both constructions are fine. We're just more familiar with one than the other, cause Photoshop and other popular image editors work that way.
Does that help, or just raise more questions? What does it mean when rbar goes negative? Let me know if you want anything more explained on this point.
Jim
-
You can't build a monitor with primaries outside the horseshoe. You can't build a monitor that emits negative amounts of photons. But in a working space, both constructions are fine. We're just more familiar with one than the other, cause Photoshop and other popular image editors work that way.
This is not just an academic point. I do a lot of image manipulation using a computer language called Matlab. When I do processing in RGB, i set the nominal range of colors to be from 0.0 to 1.0 in each primary. Images come in mapped to that range, and images that I write out for further processing by, say, Photoshop, get mapped into that range before being converted to 16-bit integers in the range [0,(2^16)-1]. But in between, I let the numbers do what they will, as long as they're between plus and minus 10^308. No, I didn't pick those huge numbers for the processing limits; they just happen to fall out of my using 64-bit floating point for the calcs.
Allowing these over and undershoots, if you will, allows me to do things that I couldn't do easily if I kept the values at all times in the range [0.0,1.0]. If I sharpen and some values go beyond white or below black, that's OK as long as by the end of the calculation everything's back in that range. I wish Photoshop's layers worked that way.
If I'm working in ProPhoto RGB, I'm working with non-physical primaries and allowing negative amounts of them!
Jim
-
Yes, that makes good sense and is an excellent explanation, thank you! I assume that the XYZ numbers will be set to 0 if they go negative. But what does XYZ 0,0,30 mean? It translates to Lab 0,0,-115 and RGB -25,15,145 (in ProPhoto). So this is a perfectly valid XYZ color, which translates to a perfectly valid Lab color ... but to a strange (read weird) RGB number. What Photoshop does is to set the RGB values to 0,15,145, so it is preventing negative RGB numbers. A more intelligent mapping would be to set the RGB values to 0,0,0 as this would give a black rather than a blue.
It would seem to me that it would have been a sensible and simple mapping algorithm to say that if L or Y is zero then RGB=0,0,0, irrespective of the maths.
I guess this is just the disconnect between maths and the real world ... but surely that means that the model is flawed (in which case it should be possible to correct it - and if the CIE will not, why should Adobe not do so?).
Well there are reasons for working in Lab, simply from an editing point of view (for example, some people think it's advantageous to sharpen only the L channel, color balance is probably easier to do in Lab ...). But in a program like Photoshop, which is used to produce visual output, surely the editing should behave in a rational way ... in other words, even if it makes sense to have colors with no luminance in Lab, it really does not when it comes to visual perception, and it makes even less sense for the color with no luminance to show as red or blue. Simply applying the working-space gamut to the Lab values will ensure that (and making Lab 0,x,y = RGB 0,0,0). This could be an option in Lab, so it would still be possible to work in imaginary colors or weird mappings for those of us who would like to.
It's kind of a long story, but negative tristimulus numbers were needed in the original color matching experiments. In the experiments they were trying to match a stimulus by mixing three RGB primaries. For many colors a match can't be achieved with the three primaries so they polluted one of the primaries with another color which mathematically was the equivalent of "adding" a negative amount.
All negative numbers are a little weird when you try to go from abstract ideas to concrete examples. It seems perfectly normal to have a negative balance in a checking (hopefully not too often) — the negative number is useful and abstracts to the concept of debt, but when you try to withdrawal your negative balance it clips to zero. It would be bizarre to ask somebody for -$1.00, but the negative values are really useful for balancing a checkbook.
As far as handling L* values of zero, simply clipping all RGB conversions to black is one option. But it comes with some downsides that rendering intents attempt to fix. For example in your original question you are dealing with LAB [0, 127, 0]. If you convert to AdobeRGB this will be out of gamut and it might seems sensible to just convert to ARGB[0, 0, 0] rather than photoshop's [95, 0, 13]. So you clip that to black, fine. Now what do you do with LAB[1, 127, 0]? This is still out of gamut, but since L* is not 0, your rule of clipping all L*=0 values to black doesn't apply — you now need a different way to map it to your space. If you use a colorimetric intent it will map to ARGB[97, 0, 18]. What was a smooth gradient in LAB now has a horrible visual disconnect in the RGB - it posterizes from [97, 0, 18] to [0, 0, 0] even though it's only a difference of 1 L* value. Rendering intents are a compromise, but I'm not sure clipping to black just to resolve some of the weirdness is an improvement in actual practice. And in actual practice if you are dealing with LAB values like [0, 127, 0] you are probably doing something wrong. The rendering intents work much better when you are dealing with reasonable LAB values.
-
As far as handling L* values of zero, simply clipping all RGB conversions to black is one option. But it comes with some downsides that rendering intents attempt to fix. For example in your original question you are dealing with LAB [0, 127, 0]. If you convert to AdobeRGB this will be out of gamut and it might seems sensible to just convert to ARGB[0, 0, 0] rather than photoshop's [95, 0, 13]. So you clip that to black, fine. Now what do you do with LAB[1, 127, 0]? This is still out of gamut, but since L* is not 0, your rule of clipping all L*=0 values to black doesn't apply — you now need a different way to map it to your space. If you use a colorimetric intent it will map to ARGB[97, 0, 18]. What was a smooth gradient in LAB now has a horrible visual disconnect in the RGB - it posterizes from [97, 0, 18] to [0, 0, 0] even though it's only a difference of 1 L* value. Rendering intents are a compromise, but I'm not sure clipping to black just to resolve some of the weirdness is an improvement in actual practice. And in actual practice if you are dealing with LAB values like [0, 127, 0] you are probably doing something wrong. The rendering intents work much better when you are dealing with reasonable LAB values.
Yes, that's a very valid point (or points, rather). Your last point ("the rendering intents work much better when you are dealing with reasonable LAB values") really addresses the issue for me (I accept what Jim says regarding the usefulness of negative numbers in computation, but we're talking about Photoshop here, and in particular typical users of Photoshop, not imaging scientists who use Matlab etc). The problem is that most of us (me for sure) don't know what a reasonable Lab value is. How do I know if Lab 40,-40, 50 is 'reasonable' or not? As it turns out, this value is 'reasonable' in ProPhoto RGB, but 'unreasonable' in Adobe RGB: because it is outside the Adobe RGB gamut but inside the ProPhoto RGB gamut. So, for me, not having a mechanism to constrain the Lab values to within the RGB working space used makes it much too dangerous to use (so why is it there?).
On that point, 'why is it there?':
That is the case. Lab is kind of a crappy working space (you want to go there?) ;D
And no, you don't need to convert to Lab, potentially losing a lot of data just for sharpening, we have the Fade... Luminosity mode which serves the same purpose and provides more control, all while staying in your RGB working space. Lab as an editing space is hugly oversold!
I quite agree. So, why is it there? The only good reason that I can think of is that once you've understood the a-b axes, it is quite an intuitive model for manipulating colors. But now that I think of it, the Color Balance adjustment layer does that just as well without the potential out-of-gamut issues: so now I can't think of a good reason to go into Lab! Perhaps it's useful because it gives us a sense of what the PCS is? A slightly abstract usefulness!
So ... can anyone think of really useful uses for Lab (that can't be done just as well in RGB)?
Robert
-
Lab in Photoshop predates RGB working space by many years and was at the time, the only device independent color space one could use (Lab IS useful for that). RGB working space are Quasi-Device Independent in that they are still tied to some theoretical device but behave the same for all users working with the same editing space.
-
Lab in Photoshop predates RGB working space by many years and was at the time, the only device independent color space one could use (Lab IS useful for that). RGB working space are Quasi-Device Independent in that they are still tied to some theoretical device but behave the same for all users working with the same editing space.
Interesting, I didn't know that. I started off with Photoshop 6 which certainly had RGB.
I guess that Lab is useful in that it is more intuitive to use than RGB (at least once one has understood it) ... as it approximates the way we see. Also, it is useful for things like enhancing or desaturating colors, color balance etc. With 16-bit there's not likely to be any loss of information in going from RGB to Lab and back (unless we go out of gamut), so the only real downside to using it is the risk of getting out-of-gamut colors.
A feature like the Melissa RGB/ ProPhoto RGB of Lightroom allowing one to work in Lab but limiting the potential damage to ProPhoto (or to the chosen working space) would be nice. Perhaps nothing's been done with it because it is one of these legacy things that have been sort of forgotten.
What I would really like to see (sort of getting off topic here) is an adjustment layer (or a control in Lab) which would allow the adjustment of both the a and b values simultaneously (and visually) ... like the white point shifting in programs like the Eizo ColorNavigator.
Robert
-
Interesting, I didn't know that. I started off with Photoshop 6 which certainly had RGB.
Photoshop 1.0.9 had RGB but it wasn't until Photoshop 5 we had RGB working spaces.
I guess that Lab is useful in that it is more intuitive to use than RGB (at least once one has understood it) ... as it approximates the way we see.
Kind of, sort of...
With 16-bit there's not likely to be any loss of information in going from RGB to Lab and back (unless we go out of gamut), so the only real downside to using it is the risk of getting out-of-gamut colors.
There's data loss (and time loss) but in high bit it's moot. The question is, what can't you do while in a well behaved RGB working space or better, when rendering the raw that can only be achieved in Lab?
-
Lab in Photoshop predates RGB working space by many years and was at the time, the only device independent color space one could use (Lab IS useful for that).
I dunno. How about CIEL*u*v*? Both Lab and Luv were standardized in 1976, well before Ps. I'd like it if Ps at least had a Luv color picker and Luv readout, if not being a three-quarter-fledged working space like Lab. I agree with Andrew that the sun is setting on Lab's usefulness as a working space. 16-bit color helped it along (it was asking for posterization to use it in 8-bit color), but ProPhoto RGB has gotten rid of one set of reasons to use it.
Luv has the property that, at any L*, the range of the visible colors is easy to figure out and plot. The display even looks familiar to many, since it's pretty close to u'v' chromaticity, with its horseshoe for the spectral locus. Having that spectral locus means that Luv has a measure that Lab lacks: saturation, defined as the ratio of the distance of a color to the white point at the luminance of the color to the distance from the white point to the spectral locus at the hue angle of the color. So, in Luv, we know if any set of values is visible, and how far away it is from not being visible.
Luv is not completely perceptually uniform, and neither is Lab; both are off by about the same amount, but in different places.
I know why Ps picked Lab in the first place; a big part of the target market was the color prepress business, and Lab was a standard there. Luv was used by the people who worked with displays. But today, lots of images are prepared for displays.
I'm not holding my breath, but I'd sure like to see Luv in Ps. Having it there would solve much of the OP's concern.
What would *really* be nice is a cleaned up Luv, kind of like what Bruce Lindbloom did with Lab, so that constant Munsell hues are on constant Luv hue angles.
Jim
-
The question is, what can't you do while in a well behaved RGB working space or better, when rendering the raw that can only be achieved in Lab?
I guess I'm thinking about Lab in Photoshop rather than raw processing in Lightroom.
Perhaps another way of putting your question is: "What can you not do in a well behaved Lab working space that you can only achieve in RGB?". That is, assuming that all of the adjustments available in RGB in Photoshop were also available in Lab in Photoshop.
The answer for me is that adjusting colors by manipulating the R, G and B values is hopeless, whereas it is not at all hopeless doing so by manipulating the L, a, b values. For example, white-balancing a ColorChecker perfectly in Lab is really easy (to get all the gray values balanced, not just the middle gray). Doing that in RGB is certainly possible, but I don't think it's easy.
At the end of the day, the kind of weird colors I started this topic with are not a problem really, because mostly in photography (most of us) are going to stay in a pretty conservative color gamut. Then it's a question of preference, surely: what color space you feel most comfortable in (for certain tasks, perhaps white-balancing, as an example).
And actually I don't see why there has to be a (significant) loss of information in going from an RGB working-space to Lab and back again. There is of course the potential for rounding and truncation errors but these should be minimal in 16 bit. I would certainly have no hesitation in going to Lab for fear of information loss.
Robert
-
You CAN adjust Lab values while in an RGB space. Just set the info palette for Lab.
-
You CAN adjust Lab values while in an RGB space. Just set the info palette for Lab.
Well ....... you can SEE the Lab values, but you can't change the individual L, a or b channels! To change the Lab values you have to manipulate the R, G and B channels.
Robert