I also agree with your assessment Michael. Those Lab numbers at those extremes probably never come in to play with normal images.
Where this comes into play, is when you are trying to read the Photoshop Raw file and convert to Lab values "a" and "b". You would not want to scale the full 16 bit range of 0 to 65535 to the -128 to 127 Lab range. To get the scaling right, you would want to scale it to the -128 to 128 range and then truncate to 127. Otherwise, all the "a" and "b" values would be slightly off over the entire range. The error would have been 0 out of 256 at "a" or "b" at -128 and an error of 1 out of 256 at the high end. Not large yet enough to be noticed that it is off.
Thanks for spurring this topic through. I would not have known this subtlety without your help.
John Wheeler
thebestcpu wrote: You would not want to scale the full 16 bit range of 0 to 65535 to the -128 to 127 Lab range.
|
I would think someone using a script to get the Lab values of each pixel in a 16bit document would want the values in 16bit. But I get what you mean by clipping the range at 65279. However, like I said I am not going to worry about it. It seems that becasue Photoshop will save a and b values in a Ps raw file beyond 65279 that those values are valid even if the info panel clips.
Here is the function I am using now. It works with both 8 and 16bit numbers. Of course the script that read the PS raw file would still need to know wheither to read 8 or 16bit.
function convertNumberToLab(channel,num){
if((num !=0 &&( num >>>8) != 0) ){// is 16bit num
if(channel == 0){
return Math.round(num*(32768/65535));
}else{
return Math.round((num-32768)/2);
}
}else{
if(channel == 0){
return Math.round((num/256)*100);
}else{
return num-128;
}
}
};
I did a Google search and Excel has raised the column and row limit. So unless it is reading very large files a script could create a csv file with a header and each pixel Lab values per row.