Re: ProPhotoRGB & Ekta Space
Re: ProPhotoRGB & Ekta Space
- Subject: Re: ProPhotoRGB & Ekta Space
- From: Robin Myers <email@hidden>
- Date: Tue, 02 Oct 2001 19:00:33 -0700
- Organization: Robin Myers Imaging
Terry Wyse wrote:
>
on 10/2/01 2:29 PM, Robin Myers wrote:
>
>
> The current standard for L*a*b* encoding only covers 8-bit encoding, which
>
> represents a range of L* (0 min,100 max), a* (-128,127), b* (-128,127) with
>
> integer steps in a* and b*. To encompass the entire range of L*a*b* values
>
> that would contain the entire spectral locus would require an encoding range
>
> of a* (-300,+300) and b* (-200,+200). There are many devices and gamuts, such
>
> as digital cameras and film that can record information outside the 8-bit
>
> ranges. Also, the error built into the 8-bit encoding is a maximum of 1.4 dE.
>
> This is a huge error for achromatic and near-achromatic colors. Therefore, if
>
> you have a need for high quality color archiving, I suggest you avoid 8-bit
>
> L*a*b*.
>
>
At the risk of showing my ignorance:
>
So, if I get what your saying, if I have a 16bit LAB file open in Photoshop,
>
I'm only able to edit it AS IF it's an 8bit file because of the encoding? If
>
this is so, then the same would be true of a 16bit RGB file since I can only
>
edit in a range of 0-255 instead of 0-65,535?
I believe that is currently true. Ask Chris Cox for more details of how Photoshop
handles 16-bit encodings of RGB and L*a*b*. Also, don't forget what Bruce
Lindbloom said about Photoshop converting all your 16-bit files into 15-bit files.
You automatically lose some data just by opening them in Photoshop.
>
If 8bit encoding in LAB is -128,127 (256 steps) when then wouldn't 16bit
>
encoding be -65536, 65535?
The encoding has not been nailed down yet. Also, the range -65536,65535 is
more than needed, so if it is done better than 8-bit, there might be an implicit
decimal point such as an 8.8 encoding giving -256,+255 with steps of approximately
0.004.
>
If 8bit encoding is integer steps in a* and b*, why does my Spectrolino
>
record values to two decimal places?
Because the Spectrolino uses the spectral data to calculate L*a*b* with floating
point values using the full L*a*b* space and Photoshop uses a reduced subset
of the L*a*b* space.
>
> There are many devices and gamuts, such
>
> as digital cameras and film that can record information outside the 8-bit
>
> ranges.
>
>
I'm not sure I get this either. Why would this be true anymore than 0-255
>
does not define the "range" of color, simply the scale that is used in an
>
RGB file? Not that I'm challenging any of this, I simply don't understand
>
it.
I was again referring to the 8-bit L*a*b* encoding and that this encoding is
deliberately restricted to -128,+127 because it uses a signed 8-bit number to
represent a* and b*. It was also defined to be integer steps, no decimals. As I
previously
noted, the range of human vision in L*a*b* space is much larger than the
signed 8-bit encoding allows. I believe it was felt at the time that this encoding
would be sufficient for most devices. However, the advent of digital cameras
and improved colorants for printers has made this assumption false.
So, until a suitable 16-bit encoding for L*a*b* that can encompass the entire
visual range is available, I recommend archiving 16-bit RGB raw images for
the highest image quality.
Robin Myers