Comparing sRGB to L*a*b*

Hi everyone, thanks for having me.

I have a nerdy question, and I think I'm in the right place

I am wondering about the level of quantization that occurs when converting from 8-bit sRGB to 8-bit LAB. I'm aware that it's probably bad practice, but I'd like to know just how bad.

Is it possible to quantify? Can you say "256 levels per channel in 8-bit sRGB = ?? levels per channel in 8-bit LAB"? Or "16.7 million colours in 8-bit sRGB = ?? colours in 8-bit LAB"?

Cheers,

Damien.

Depends on the RGB color space.

Bruce Lindbloom, a well-respected color geek and scientist, has a very useful Levels Calculator,which allows you to enter values to determine the actual number of levels lost to quantization (see the “Calc page”at http://www.brucelindbloom.com).

Adobe RGB reduces the data down to 234 values from 256. Doing the same conversions from ProPhoto RGB reduces the data to only 225 values, producing a loss of 31 levels.

Hi Andrew, thanks for your reply, and the link.

Well, I was particularly interested in sRGB, as I stated.

Andrew Rodney said:

Adobe RGB reduces the data down to 234 values from 256. Doing the same conversions from ProPhoto RGB reduces the data to only 225 values, producing a loss of 31 levels.

Click to expand...

Why does ProPhoto end up with fewer levels than Adobe RGB? I guess I need to read and learn more.

Damien Symonds said:

Hi everyone, thanks for having me.

I have a nerdy question, and I think I'm in the right place

I am wondering about the level of quantization that occurs when converting from 8-bit sRGB to 8-bit LAB. I'm aware that it's probably bad practice, but I'd like to know just how bad.

Click to expand...

Really, really bad. 'Don't ever do that' bad. Always promote your sRGB to 16 bits first, then convert to LAB.

RGB spaces are succeptible to some quantisation, at 8 bits. With sRGB you can, just, get away with it. Wider RGB colour spaces really need 16 bits. (This is why, for 8 bit processing, sRGB may be a better bet).

From memory, the colour volume of the LAB gamut is around three times that of sRGB. As the visible colour portion of that is only a part - so lots of the total code space is used up on values that don't correspond to a colour at all.

Damien Symonds said:

Is it possible to quantify? Can you say "256 levels per channel in 8-bit sRGB = ?? levels per channel in 8-bit LAB"? Or "16.7 million colours in 8-bit sRGB = ?? colours in 8-bit LAB"?

Click to expand...

That does depend to an extent on the rendering intent used for the conversion. The metrics which you suggest might not be ideal because it depends in which direction across the colour space you measure (the visible volume is not a cube).

IIRC there is a synthetic image which contains all 16.7million colours from 8 bit RGB space. Converting this to 8 bit LAB, converting it back, and then usig software to count the number of unique colours would be an empirical method to determine this. The netpbm toolkit has tools to determine the number of unique colours in an image (again, from memory).

Damien Symonds said:

Why does ProPhoto end up with fewer levels than Adobe RGB? I guess I need to read and learn more.

Click to expand...

Headroom and footroom, I suspect. But I was wrong

Andrew Rodney said:

Depends on the RGB color space.

Bruce Lindbloom, a well-respected color geek and scientist, has a very useful Levels Calculator,which allows you to enter values to determine the actual number of levels lost to quantization (see the “Calc page”at http://www.brucelindbloom.com).

Click to expand...

That converter only tells you the loss in the number of unique levels caused by a gamma (transfer) function. Its unrelated to the volume of the colour gamut.

Suppose you assign the sRGB color space profile to this image. It would then contain 16,777,216 unique sRGB colors. If you changed its color mode to Lab (in Photoshop using a Relative Colorimetric rendering intent) and analyzed the Lab result, you might be surprised by what you find. The number of unique Lab colors has been substantially reduced, down to 2,186,578 unique colors — only 13% (about one-eighth) of what we started with

Click to expand...

http://www.brucelindbloom.com/index.html?RGB16Million.html

So there we are, Ralph has already done the experiment which I described above and the answer is, you are throwing away 87% of your data. Ralph doesn't note whether the conversion used black point compensation or not. I suspect it did.

Chris Lilley said:

http://www.brucelindbloom.com/index.html?RGB16Million.html

So there we are, Ralph has already done the experiment which I described above and the answer is, you are throwing away 87% of your data. Ralph doesn't note whether the conversion used black point compensation or not. I suspect it did.

Click to expand...

Wow. I knew it would be nasty, but I had no idea it would be that severe. Thanks for the link!

Chris Lilley said:

Really, really bad. 'Don't ever do that' bad.

Click to expand...

Oh, don't worry, I don't. Most of my work is done on 8-bit sRGB files (enhancing other people's cruddy images), so I don't take too many risks.

The reason I ask is because I see hundreds of people on other forums recommending converting into and out of LAB for various edits, particularly sharpening on the L* channel. I always had a feeling this was dangerous, so I use the Dupe Layer>Luminosity Mode method instead. The folk recommending these conversions might only be doing it on high-bit files, but they certainly don't say so, so it worries me that eager newbies might be performing these conversions recklessly on their own 8-bit files.

Chris Lilley said:

Always promote your sRGB to 16 bits first, then convert to LAB.

Click to expand...

Ok, have I got this right?:

1. Convert 8-bit sRGB to 16-bit sRGB (no improvement to quality of file - visually, still 256 levels of colour per channel)

2. Convert 16-bit sRGB to 16-bit LAB (negligible, in fact imperceptible quantization)

3. Make an edit in 16-bit LAB (ok, this is where I'm a bit hazy. If I make a Curves adjustment on this file, will I get similar banding as to the original 8-bit sRGB file? To my mind, I will, because the colour levels are still "in blocks", as it were, despite being in 16-bit.)

4. Convert 16-bit LAB file back to 16-bit sRGB file (again, negligible quantization)

5. Convert 16-bit sRGB file back to 8-bit sRGB file (and again, negligible quantization)

So it's step 3 where I'm unclear. I doubt the original 256 levels per channel are suddenly going to magically smooth out into a wonderful 65536 levels during a Curves adjustment.

However, I'm aware of the importance of your advice. Converting to 16-bit before other conversions at least ensures the original 256 levels are mostly maintained, whereas a plain sRGB-to-LAB 8-bit conversion gives us about 33 levels per channel (13% of 256). Yeesh!

Chris Lilley said:

That converter only tells you the loss in the number of unique levels caused by a gamma (transfer) function. Its unrelated to the volume of the colour gamut.

Click to expand...

I don't really understand what you just said, but at least it confirms what I thought - ie, that the calculator didn't answer my original question.

Andrew Rodney said:

Adobe RGB reduces the data down to 234 values from 256. Doing the same conversions from ProPhoto RGB reduces the data to only 225 values, producing a loss of 31 levels.

Click to expand...

I found the sidebar in your book that mentions this as well, but I still can't understand it, I'm afraid. To my (almost completely ignorant) mind, there seems to be a striking conflict between this information, and that which Chris posted above.

Obviously I'm wrong, and I'd like to know why. If you have time to explain it further, I'd appreciate it a great deal.

I would have thought that converting from 8-bit sRGB to 8-bit Adobe RGB might result in 234 Adobe RGB values. Likewise, a conversion from 8-bit sRGB to 8-bit ProPhoto RGB might result in 225 values. But that figure also seems rather high, considering the difference between sRGB and ProPhoto RGB (in my limited understanding).

Damien Symonds said:

The reason I ask is because I see hundreds of people on other forums recommending converting into and out of LAB for various edits, particularly sharpening on the L* channel.

Click to expand...

Yes, and thats a good strategy. I do it myself. No problem as long as you go

8bit RGB -> 16bit -> LAB, edit, -> RGB -> 8bits

Damien Symonds said:

I always had a feeling this was dangerous, so I use the Dupe Layer>Luminosity Mode method instead. The folk recommending these conversions might only be doing it on high-bit files, but they certainly don't say so, so it worries me that eager newbies might be performing these conversions recklessly on their own 8-bit files.

Click to expand...

Having the file originate as 8 bits is not a problem, provided computation is done at a higher bit depth. Of course, its better to retain the 12 or 14 bits data from the camera, and work with that at 16 bits.

Damien Symonds said:

Ok, have I got this right?:

1. Convert 8-bit sRGB to 16-bit sRGB (no improvement to quality of file - visually, still 256 levels of colour per channel)

Click to expand...

Yes. But it prevents the folowing step causing data loss. Bythe way, this is still worth doing even if you are editing in RGB and doing, say, curves adjustments. it prevents roundoff error.

Damien Symonds said:

2. Convert 16-bit sRGB to 16-bit LAB (negligible, in fact imperceptible quantization)

Click to expand...

yes

Damien Symonds said:

3. Make an edit in 16-bit LAB (ok, this is where I'm a bit hazy. If I make a Curves adjustment on this file, will I get similar banding as to the original 8-bit sRGB file? To my mind, I will, because the colour levels are still "in blocks", as it were, despite being in 16-bit.)

Click to expand...

No, you wont get the banding, because the results wont be rounded off (if it helps, think of the extra 8 bits as 'decimal places, so instead of working on integers from 0..255 you are working on floats from 0.000 to 255.000)

Damien Symonds said:

4. Convert 16-bit LAB file back to 16-bit sRGB file (again, negligible quantization)

5. Convert 16-bit sRGB file back to 8-bit sRGB file (and again, negligible quantization)

Click to expand...

Right.

Damien Symonds said:

So it's step 3 where I'm unclear. I doubt the original 256 levels per channel are suddenly going to magically smooth out into a wonderful 65536 levels during a Curves adjustment.

Click to expand...

The inputs to the curve are not 'magically smoothed out'. The outputs are. Actually you can see this clearly in the histogram, which is smooth. Doing this in 8 bts with a substantial curve shows a 'grass' histogram, with spikes, where roundoff has happened.

Damien Symonds said:

I don't really understand what you just said, but at least it confirms what I thought - ie, that the calculator didn't answer my original question.

Click to expand...

The calculator performs a useful, but unrelated, calculation. It tells you what happens to 0..255 when you put it through a curve.
Conversion from one colour space to another is a different calculation, and can't be described as a curve. So ths calculator doesn't give us any answers.

Hi, Damien,

The "deterioration" that occurs in the transformation of color information from one color space to another is not basically because one space has fewer distinct values available along one axis than another but because of either:

- the "quantization error" that occurs in doing the transformation (the point of the Lindbloom "demonstration"). This can be especially grievous if there are nonlinear definitions involved for the color space axes (which is true of the ones in which we are generally intersted).

- a difference in the "range" of one of the axes (so that the smallest step corresponds to a different actual amount).

We can get a simplistic understanding of the quantizing error (in a metaphor in which we convert from one number base to another) by realizing that the precise decimal quantity 0.3 does not have an exact binary equivalent.

Damien Symonds said:

I found the sidebar in your book that mentions this as well, but I still can't understand it, I'm afraid. To my (almost completely ignorant) mind, there seems to be a striking conflict between this information, and that which Chris posted above.

Obviously I'm wrong, and I'd like to know why. If you have time to explain it further, I'd appreciate it a great deal..

Click to expand...

I'm on the road all week so I'm going to keep it short...

The Lindbloom page provides a metric of quantization loss in my example, based on available neutrals. For example, Adobe 1998 (gamma = 2.2) has 256 available levels for neutrals. Converting to 8-bit Lab reduces these 256 unique levels down to 234, a loss of 22 levels.

Moving into and out of Lab in 8-bit isn't a good idea. I don't know that I'd suggest converting an 8-bit into 16-bit provides much added benefit (despite the histogram). A bigger question becomes, do you want to spend the time and suffer the data loss for something that may be achievable without the round trip into Lab? In the case of sharpening, the suggestions of Dan's are ancient and one can achieve the desired results (although not identically), by simply using the Fade Luminosity controls with the added Opacity slider as a control.

Chris Lilley said:

Of course, its better to retain the 12 or 14 bits data from the camera, and work with that at 16 bits.

Click to expand...

Agree 100%. But like I said, I usually don't have that luxury.

Chris Lilley said:

No, you wont get the banding, because the results wont be rounded off (if it helps, think of the extra 8 bits as 'decimal places, so instead of working on integers from 0..255 you are working on floats from 0.000 to 255.000)

Click to expand...

Granted, but there will still only be 256 unique levels. That number won't be reduced, but neither will it be increased by working in high-bit.

Therefore, I would have thought that visible banding would still occur if the Curves adjustment was significant enough ... ?

Damien Symonds said:

Granted, but there will still only be 256 unique levels. That number won't be reduced, but neither will it be increased by working in high-bit.

Click to expand...

Sorry - but, it will be increased, as soon as you do any non-linear operation on the data. It will be increased if you do an unsharp mask, or a blur.

Damien Symonds said:

Therefore, I would have thought that visible banding would still occur if the Curves adjustment was significant enough ... ?

Click to expand...

Banding caused by repeated round-off error will not occur, no. But yes, if you take sparse data and stretch the contrast over some portion of it, you will see banding. Insertion of some low-level dither will help with that, once the data is in 16 bits.

Chris Lilley said:

Sorry - but, it will be increased, as soon as you do any non-linear operation on the data. It will be increased if you do an unsharp mask, or a blur.

Click to expand...

Gotcha. So Curves and Levels are referred to as "linear operations", is that right? Sorry, I'm forever learning ...

Andrew Rodney said:

The Lindbloom page provides a metric of quantization loss in my example, based on available neutrals. For example, Adobe 1998 (gamma = 2.2) has 256 available levels for neutrals. Converting to 8-bit Lab reduces these 256 unique levels down to 234, a loss of 22 levels.

Click to expand...

Thank you.