Error in Lab conversion in PS?

[Guillermo Luijk]

Some time ago I read something about this topic, but didn't pay too much attention. A user complained on how erroneus is the conversion from any colour profile to Lab mode in PS and back, for instance to do sharpening over the Luminance channel in Lab which is very common not to create colour artifacts.

Recently I did this on an image of mine and felt that the blue sky turned more blue and less red, and I could notice this on my screen. I am using PS CS2 and I have compared the histograms of these two pieces of sky, left original in Adobe RGB, converted to Lab and back to Adobe RGB (without any additional action):



It's similar to a white balance re-adjustment. Zooming the histogram the differences are clearer:




These changes in hue are slight but visible (left is the original and displays a more red sky, while the two conversions turned it more blue):




Anyone has more information about this issue? could just 16-bit rounding errors produce such a difference? Is a problem of PS or there is something more?
I wonder then if it would be better to do sharpening in normal RGB mode.

BR

[Schewe]

I wonder then if it would be better to do sharpening in normal RGB mode.

Uh, yes...

Conversions from RGB to Lab is NOT lossless...there are rounding errors and a tendency of certain colors (notably blues as you've noted) getting changed (for the worse).

For this (and other reasons) the concept of converting from RGB>Lab merely for the purpose of sharpening the luminance data is flawed. One can easily either do a sharpening application and then Fade>Luminance or pop a duplicate layer set to a luminance blend and then apply the sharpening. That's also why Camera Raw and Lightroom both only sharpen the luminance data but without a color space change.

That's not to say there aren't legitimate reasons for going into Lab for image corrections that can't be done in RGB, but doing so for the sole purpose of applying sharpening should not be done.

[Guillermo Luijk]

Conversions from RGB to Lab is NOT lossless...there are rounding errors and a tendency of certain colors (notably blues as you've noted) getting changed (for the worse).

I understand these conversions are not lossless since rounding errors are unavoidable working with limited precision, but I didn't expect such a big error which even becomes visible to the eye.

So I wonder if it's a limitation of the bitdepth (16-bit integer rounding errors) or a fault of the tool (Photoshop's particular math implementation).

BR

[Schewe]

So I wonder if it's a limitation of the bitdepth (16-bit integer rounding errors) or a fault of the tool (Photoshop's particular math implementation).

It's a problem with the Lab space and certain color deficiencies in Adobe's implementation of Lab (as far as I know) and it's been an issue for many versions...nothing new here.

[bjanes]

It's a problem with the Lab space and certain color deficiencies in Adobe's implementation of Lab (as far as I know) and it's been an issue for many versions...nothing new here.

It is true that Photoshop's integer implementation of L*a*b does not cover the the full gamut of L*a*b, but the major loss of information when converting from RGB to LAB results from rounding errors as explained by Bruce Lindbloom and demonstrated by his 8 bit RGB image containing 16 million colors. With this image assigned to sRGB, there are 16,777,216 colors; converting to L*a*b, one gets only 2,186,578 colors in the resulting image. There is no gamut clipping, since the image contains no colors outside of the Adobe L*a*b implementation.

As Bruce explains here (click the second HERE in this screen--direct links don't work), if you start out in a very wide color space with saturated colors (e.g. ProPhotoRGB), you can get gamut clipping with loss of color.

If you are working in a wide space such as L*a*b or ProPhotoRGB, you really need to use 16 bits per pixel. However, it you start out in 8 bit sRGB and perform a round trip conversion to L*a*b and back (as done by Dan Margulis). much of the loss can be prevented if you first convert to 16 bpp.

For example, if you download Bruce's image and look at the histogram in Guillermo's Histogrammar, you see this image:

[attachment=9077:RGB16Million_HIS.gif]

If you convert to L*a*b, and look at the histogram, you see many missing levels:

[attachment=9078:RGB16Mil...oLAB_HIS.gif]

Here is the full screen capture of the program, which may help those not familiar with this powerful program:

[attachment=9081:Histogra...rScrnCap.gif]

Converting back to sRGB, one gets this histogram: (added to edited post 20 Oct 2008, 11:47 GMT)

[attachment=9094:RGB16Mil...Trip_HIS.gif]

However, if you convert the 8 bit sRGB to 16 bits, perform the conversion to L*a*b and back to sRGB, you get this histogram:

[attachment=9079:RGB16Mil...Trip_HIS.gif]

Hopefully, Guillermo will respond with further analysis and any necessary corrections. If you use Photoshop's RGB histogram on Bruce's image, you see nothing, since the Y-axis is not scales high enough to see any lines. With the luminosity histogram, you get a bell shaped curve, and this isn't what you want either.

Bill

[Guillermo Luijk]

Well I think I have something. I was surprised looking at your results Bill, and repeated the conversion: sRGB -> Lab -> sRGB, both in 8-bits and with a pre-conversion to 16-bits, and got these histograms:

Microsoft ICM conversion engine:



The 16-bits pre conversion slightly improved the result, but it's clear that bitdepth was not the main reason for the disagreement. The conversion trip seemed to increase a lot the R channel in the low end of the histogram (shadows), and reduced it in the right end (that's was the case of my sky sample).

Then I realized I was using the Microsoft ICM engine for profile conversion and changed to the Adobe ACE engine, getting much better results:

Adobe ACE conversion engine:



There are some level shifts that produced aggregations in the histogram, but the histogram shape was now much closer to the expected result. I tried then to convert my picture of the sky to Lab and back, and in that case (i.e. with the Adobe ACE Engine instead of the Microsoft ICM) there was no visible hue change. So I think it's all about the Microsoft ICM conversion engine. I would simply not use it, no idea why it performs such big mistakes when converting to Lab.

BR

[laughfta]

There are some level shifts that produced aggregations in the histogram, but the histogram shape was now much closer to the expected result. I tried then to convert my picture of the sky to Lab and back, and in that case (i.e. with the Adobe ACE Engine instead of the Microsoft ICM) there was no visible hue change. So I think it's all about the Microsoft ICM conversion engine. I would simply not use it, no idea why it performs such big mistakes when converting to Lab.

BR

Amazing if this explains the lack of consensus about problems with RGB to Lab conversions. I wonder how the Colorsync engine impacts the conversion process. BTW, I love your animated illustration above, Guillermo!

[bjanes]

Well I think I have something. I was surprised looking at your results Bill, and repeated the conversion: sRGB -> Lab -> sRGB, both in 8-bits and with a pre-conversion to 16-bits, and got these histograms:

Microsoft ICM conversion engine:



The 16-bits pre conversion slightly improved the result, but it's clear that bitdepth was not the main reason for the disagreement. The conversion trip seemed to increase a lot the R channel in the low end of the histogram (shadows), and reduced it in the right end (that's was the case of my sky sample).

Then I realized I was using the Microsoft ICM engine for profile conversion and changed to the Adobe ACE engine, getting much better results:

Adobe ACE conversion engine:



There are some level shifts that produced aggregations in the histogram, but the histogram shape was now much closer to the expected result. I tried then to convert my picture of the sky to Lab and back, and in that case (i.e. with the Adobe ACE Engine instead of the Microsoft ICM) there was no visible hue change. So I think it's all about the Microsoft ICM conversion engine. I would simply not use it, no idea why it performs such big mistakes when converting to Lab.

BR

Guillermo,

Your results are somewhat different from mine. Did you have black point compensation and dithering on during the conversion. See this note by Joseph Holmes, where he notes in (2):

"A 24-bit image in a smaller RGB working space such as ColorMatch or sRGB could lose more than 75% of its discreet image values when making one such trip from RGB to Lab and back. If dithering is enabled in the Color Settings dialog in Photoshop 6 or later, it is used for RGB to Lab and Lab to RGB conversions and masks the underlying quantization fairly effectively by introducing noise. Conversions of data in 16-bit form, even if they were originally 8-bit data, are well protected from quantization damage in the RGB to Lab to RGB round trip and dithering is therefore never used."

Mr. Holmes concurs that performing the conversion if 16 bit mode even with an 8 bit source will protect the 8 bit data from quantization damage. In my tests, I had both turned off.

Bill

[Guillermo Luijk]

Mr. Holmes concurs that performing the conversion if 16 bit mode even with an 8 bit source will protect the 8 bit data from quantization damage. In my tests, I had both turned off.

I had the dither option ON, not sure about the black point compensation (I think I tried it ON and OFF and the difference was negligible). The dither for sure explains the difference with your results. Anyway, the problem was on the conversion engine so the mistery was solved.

BR

[Czornyj]

Interesting... Seems like L* TRC based RGB space gives better results (8bit sRGB vs 8bit ECI v.2):