Views
850
Replies
6
Status
Closed
The subject of Adobes quasi 15-bit math has been discussed in the forums before. In addition, errors in the Lab mode histograms and in the JavaScript SolidColor object have been posted in the scripting forums and acknowledged by Adobe. Since I have some new information, I would like to re-open the discussion.
The fact that RGB-LAB-RGB conversions will alter colors has also been discussed. I agree that this will happen if the image contains out of gamut colors in one or both of the color spaces. And that 8-bit rounding can destroy any image. But in 16-bit mode, with all image colors in gamut, any rounding errors should be minimal. This does not seem to be the case.
While doing some color testing, I discovered some simple cases that demonstrate the situation.
With ProPhoto RGB as your default RGB color space and with an image open in ProPhoto RGB, if you enter the RGB values 238, 203, 0 in the Color Picker the corresponding Lab values will show as 88, 19, 127. If you then paint with this color, or place the eyedropper over the foreground color the Info panel will show Lab values of 88, 19, 128. The range of Lab ab values is 128 to +127. The Color Picker will not allow you to enter an ab value of +128. This +128 shows as 16384 in the 16-bit display, which is +127 in Adobes quasi 15-bit math.
For another example, set the Info panel to display both RGB and Lab in 16-bit. Avoid, the Actual Color or you can get confused since the display will change dynamically. If you enter the Lab values 100, 0, 0 the L channel shows as 32768 in the 16-bit display. And the RGB values are 255 at 32737. But if you enter RGB 255 it shows as 32768 and the equivalent L value is 100 at 32768. Clearly the math is not symmetric.
Open a small new image in Lab mode. Set the histogram to the all channels view. Then paint with lab colors. You will see that ab 1 and 0 are at levels 127 and 128 respectively. Then use ab +1 and 0. They are both at level 128. Level 254 will correspond to +127. This should have been level 255. So, the mid-point is ambiguous and the max highlight is wrong. Actually, every positive value is wrong.
One might make an argument that the Info displays are the only errors. But I have seen enough to convince me that the math is just plain wrong. Since Lab is the Adobe reference space, these errors are being propagated throughout the color space conversions. I see them in the scripting interface, in the histograms, and now in the Info panels. It looks to me like there is a mixture of true 16-bit math and some quasi 15-bit math in the Adobe Lab routines. Not consistent!
That said, I believe it is time for Adobe to drop the quasi 15-bit math. Leaf Aptus has cameras that shoot true 16-bit math already. One half of this dynamic range is lost simply by converting to 15-bit math. How long will it be before 16-bit cameras are affordable to more of us? Some have suggested that these are not true 16-bit in the first place. But both Leaf and Dalsa (the sensor manufacturer) insist it is.
I sincerely hope that Adobe is going to address this in CS3 if not sooner.
Cheers, Rags 🙂
The fact that RGB-LAB-RGB conversions will alter colors has also been discussed. I agree that this will happen if the image contains out of gamut colors in one or both of the color spaces. And that 8-bit rounding can destroy any image. But in 16-bit mode, with all image colors in gamut, any rounding errors should be minimal. This does not seem to be the case.
While doing some color testing, I discovered some simple cases that demonstrate the situation.
With ProPhoto RGB as your default RGB color space and with an image open in ProPhoto RGB, if you enter the RGB values 238, 203, 0 in the Color Picker the corresponding Lab values will show as 88, 19, 127. If you then paint with this color, or place the eyedropper over the foreground color the Info panel will show Lab values of 88, 19, 128. The range of Lab ab values is 128 to +127. The Color Picker will not allow you to enter an ab value of +128. This +128 shows as 16384 in the 16-bit display, which is +127 in Adobes quasi 15-bit math.
For another example, set the Info panel to display both RGB and Lab in 16-bit. Avoid, the Actual Color or you can get confused since the display will change dynamically. If you enter the Lab values 100, 0, 0 the L channel shows as 32768 in the 16-bit display. And the RGB values are 255 at 32737. But if you enter RGB 255 it shows as 32768 and the equivalent L value is 100 at 32768. Clearly the math is not symmetric.
Open a small new image in Lab mode. Set the histogram to the all channels view. Then paint with lab colors. You will see that ab 1 and 0 are at levels 127 and 128 respectively. Then use ab +1 and 0. They are both at level 128. Level 254 will correspond to +127. This should have been level 255. So, the mid-point is ambiguous and the max highlight is wrong. Actually, every positive value is wrong.
One might make an argument that the Info displays are the only errors. But I have seen enough to convince me that the math is just plain wrong. Since Lab is the Adobe reference space, these errors are being propagated throughout the color space conversions. I see them in the scripting interface, in the histograms, and now in the Info panels. It looks to me like there is a mixture of true 16-bit math and some quasi 15-bit math in the Adobe Lab routines. Not consistent!
That said, I believe it is time for Adobe to drop the quasi 15-bit math. Leaf Aptus has cameras that shoot true 16-bit math already. One half of this dynamic range is lost simply by converting to 15-bit math. How long will it be before 16-bit cameras are affordable to more of us? Some have suggested that these are not true 16-bit in the first place. But both Leaf and Dalsa (the sensor manufacturer) insist it is.
I sincerely hope that Adobe is going to address this in CS3 if not sooner.
Cheers, Rags 🙂
How to Improve Photoshop Performance
Learn how to optimize Photoshop for maximum speed, troubleshoot common issues, and keep your projects organized so that you can work faster than ever before!
