CS 15 bit Lab calculations are incorrect

After 15 posts you don’t have to leave the thread and start a new.

And he’s wrong on all counts.

But he is quite convinced that he is correct.

Reading in the manual for PS v7, I found that PS scaled the L values to lie between 0 and 100 (as integers) while the a and b values lie between -127 and 128 (or maybe it was -128 and 127). These values for a and b are signed 1 byte integers.

Jim
wrote in message

And he’s wrong on all counts.

Here is the algorithm to change XYZ to CIELab:

var_X = X / 95.047 //Observer = 2°, Illuminant = D65
var_Y = Y / 100.000
var_Z = Z / 108.883

if ( var_X > 0.008856 ) var_X = var_X ^ ( 1/3 )
else var_X = ( 7.787 * var_X ) + ( 16 / 116 )
if ( var_Y > 0.008856 ) var_Y = var_Y ^ ( 1/3 )
else var_Y = ( 7.787 * var_Y ) + ( 16 / 116 )
if ( var_Z > 0.008856 ) var_Z = var_Z ^ ( 1/3 )
else var_Z = ( 7.787 * var_Z ) + ( 16 / 116 )

CIE-L* = ( 116 * var_Y ) – 16
CIE-a* = 500 * ( var_X – var_Y )
CIE-b* = 200 * ( var_Y – var_Z )

note that the var_X, var_Y, var_Z are all limited to a maximum value of 1.0 and that occurs when the signal is from the D65 assigned source. Notice also that if the values of these variables are > 0.008856 they are replaced by their cube roots. Now look at the equation for CIE-L* and replace var_Y by 1.0 and we immediate see that the L value has a maximum of 100. Since both var_X and var_Y are limited to maximum values of 1.0 we can examine CIE_a* and say that its maximum value is no greater than 500 and if we consider the else clause in each of the if statements we can see that each variable has a minimum of 16/116. Thus the maximum value of CIE-a* is 431.0344828 and the minimum value is -431.034428. Similarly for the CIE-b* value we have a maximum of 172.4137931 and a minimum value of -172.4137931. Notice we are not talking about whether the image is 24 or 48 bits. The value for the significant bits of a 24 bit color image derived from a 48 bit color image should be identical. When looking at a 48 bit color image the the presentation of L and a* and b* should be the same as that for a 24 bit image but with added precision.

Daniel,

I´m appreciating your contribution. It´s of course very hard to follow the mathematical derivation.

My first impression is:

The formulas are correct but the white point is wrong.

CieLab has traditionally Reference White at D50. I don´t know why, but it´s simply a fact – let´s say an agreement of the industry.

In the suggestion of the PostScript Language Reference
Manual about the Lab to XYZ conversion is a severe bug – the limitations are wrong. But this might be another dis- cussion …

More about CieLab is here (about 1.2 MByte):
<http://www.fho-emden.de/~hoffmann/cielab03022003.pdf>

Best regards –Gernot Hoffmann

Gernot,
I found it difficult to understand your comments after I had checked the document you referenced. I presume you are the author or complier of that document and as such are intimately familiar with the above simple equations which are identical to the equivalent equations in the referenced document. In any event I shall assume, however naive, that your comments are honest.

I found the referenced document interesting and if it is possible I would like to see a mapping of the XYZ, perhaps in the mappable form Yxy, on to a La*b* 3d presentations similar to the ones in this document. I know that page 38 has three slices through that plot and I know you indicate ref. 2 has the full plot but unfortunately I don’t have that reference and I will order it. I question the three values of L attached to the referenced graphs because they seem to be based on a maximum value of L*=1.0 rather than 100. I base this on the my understanding that values of L less than 1, as these are are, are in the almost dark area and it would seem to me they would display little to no color.

For your information the non-informational comment from Chris Cox reflects on him and no one else, nevertheless, I felt compelled to response and prove the accuracy of my statement. It my belief that any rational person who simply examined the L*, a*, and b* values in the INFO pallete would note that they are orderes of magnitude different when measuring from a 24 bit image and a 48 bit image and ask the simple question, "What is the nature of a measurement system that changes the values it reports as the accuracy of the measurement increases?" It would obviously have absolutely no value therefore one must conclude that one or both of these measurements are incorrectly calculated. I believe his answer was simply a "gut" feel that this God given program could not be wrong and any attempt to point out an error was sacrilegious and at best deserving of a curt non-informational response. Fortunately, this is not a God given program and thus I am free to point out this error and to state there are other errors and poor judgements used by the programmers and these errors will show up in time. If I am wrong then please do me the courtesy to respond in a way in which I can improve my knowledge base.

Rob, I have no idea of what you are trying to tell me or anyone reading these posts. I did try a search on the engine provided by this forum and it failed to find any references. I suggest an informational response would be more appropiate and useful since not everyone has followed all the forum comments as you evidently have.

Daniel,

thanks for the correction (p.38). I´m using normalized values in PostScript: L=0..1. It would be better to show everything as usual: L=0..100.

Yes, I´m the author of the doc and the programmer of the graphics.

For me it´s quite useless to continue the discussion about PhS without having the specifications for all data formats. And I´m probably not willing to buy CS.

But I wanted to say that minor deviations might be caused by your wrong white point.

Please contact me directly if you should be interested in 3D illustrations for CIE XYZ (clicking on my name in the post here).

Best regards –Gernot Hoffmann

Daniel – that’s correct ONLY if you assume the encoding of L* is 0 to 100.

That would be a real waste in 8 bits, and pretty stupid in 16 bits.

Normally, L* is encoded so that full scale (100 in your case) occupies the entire available range (0..32768 in Photoshop, 0..65535 elsewhere).

The a and b ranges are also scaled so that +-127 in your encoding fit within the available range. That works well for 8 bits (signed or offset by 128), and gets scaled when you go to 16 bits.

The 16 bit value readouts in Photoshop are the internal values — only available for the experts that need them. And they are correct.

Also, it’s far easier (and more common) to use 0..1.0 for XYZ and LAB calculation so that you remove any dependency on the precision and encoding.

I was really hoping that you would find your obvious mistakes yourself.

Chris,
The encoding of L* is discussed by the International Color Consortium in Specification ICC.!:2001-12 entitled, "File Format for Color Profiles (Version 4.0.0)" Although there are several examples I will copy one that shows my assumption is consistent with the International Color Consortium and since this is a copywrited publication I would hesitate to use L* or a* or b* in a manner other than what they specify because it is an internationally defined quantity and also I would not like to look stupid. On page 81 of this document the encoding for a value of L* = 0 is 00h for 8 bits and 0000h for 16 bits and for L*=100 encoding is FFh for 8 bits and FFFFh for 16 bits. To continue table 96 on page 93 of the referenced document specifically says the L* = 100 has an 8 bit encoding of 255 and a 16 bit encoding of 65535. It further states that a* =0 has an 8 bit encoding of 128 and a 16 bit encoding of 32896.
You statement that the 16 bit values readouts in CS are internal values only available to experts is strange because it is contradicted by the facts. Namely the L* , a* , and b* values are available to anyone who uses CS and looks at the INFO pallete. When the color picker is used on a 48 bit image it produces values as I originally described. Thus L* is equated to values as high as 32767 which is clearly in conflict with the referenced document. Your next statement is equally strange. The defined range for XYZ is 0..1.0 and that is how it should and is used. The defined range for other internationally accepted variables should also be use. What is strange is that you equate precision with the range 0..1.0 when in fact range has nothing to do with precision.

Daniel – yes, and the ICC uses multiple encodings for L* in 16 bits (0..65535 and 0..65280). And that document only refers to the ICC profile format – it has no bearing on other imaging, other encodings, etc.

In Photoshop, L* has a maximum value of 32768, as I already mentioned.

No, there are no facts contradicting what I say — the 16 bit display is there FOR the experts (I dind’t say it was exclusive to them, but for them). Anyone can turn it on, but they’re going to get confused unless they know what they’re doing.

Overall, you’re very confused – partly because you’re trying to impose inappropriate standards everywhere.