On Mon, 1 Oct 2001, Curtis Veit wrote:
> On Sun, Sep 30, 2001 at 11:54:01AM -0400, Brian S. Julin wrote:
> > On Sun, 30 Sep 2001, Christoph Egger wrote:
> > > The conversion should be as fast as possible, as less overhead as
> > > possible. I think, the roughly way to go is this:
> > >
> > > input sublib -> conversion sublib -> output sublib
> > >
> > > But I don't want to write a conversion sublib for each possible
> > > combination of io-targets as input and output...
> > >
> > >
> > > Any ideas?
> >
> > Do the above, but make it so that you can do:
> >
> > input sublib -> generic conversion sublib -> output sublib
> >
>
> I am assuming that this goes into an intermediate form. This is OK if
> color space characteristics are taken into account...
color space conversion is a must for libgpf. Otherwise it will never work
as intended.
> Each format covers a given color space. Some color spaces are able to
> represent more colors. If you go through an intermediate conversion
> you will always be limited to that color space at best. This could be
> a bad thing unless the intermediate is the most complete space.
That's true. See below.
> > ...in cases where a customized sublib has not been written, like a
> > stubs or generic-* renderer in GGI. You may want to consider how to
> > layer the generic libraries, e.g. in ggi we have:
> >
> > Layer 0: stubs color
> > Layer 1: generic-*
> > Layer 2: fbdev and other accels
Yes, that's GGI's usual overload layer. But this way isn't very suitable
for libgpf, because there is _no_ real common and device independent
colorspace.
Perhaps I should use the Kodak PhotoCD colorspace as the common
one. libgcp's documentation describes why:
----------------------------------------------------------------------
The Kodak PhotoYCC color space was designed for encoding images with the
PhotoCD system. It is based on both ITU Recommendations 709 and 601-1,
having a color gamut defined by the ITU 709 primaries and a luminance -
chrominance representation of color like ITU 601-1's YCbCr. The main
attraction of PhotoYCC is that it calibrated color space, each image being
tracable to Kodak's standard image-capturing device and the CIE Standard
Illuminant for daylight, D65. In addition PhotoYCC provides a color gamut
that is greater than that which can currently be displayed, thus it is
suitable not only for both additive and subtractive (RGB and CMY(K))
reproduction, but also for archieving since it offers a degree of
protection against future progress in display technology. Images are
scanned by a standardised image-capturing device, calibrated accoring to
the type of photographic material being scanned. The scanner is sensitive
to any color currently producable by photographic materials (and more
besides). The image is encoded into a color space based on the ITU Rec 709
reference primaries and the CIE standard illuminant D65 (standard
daylight). The extended color gamut obtainable by the PhotoCD system is
achieved by allowing both positive and negative values for each primary.
This means that whereas conventional ITU 709 encoded data is limited by
the boundary of the triangle linking the three primaries (the color
gamut), PhotoYCC can encode data outside the boundary, thus colors that
are not realiseable by the CCIR primary set can be recorded. This feature
means that PhotoCD stores more information (as a larger color gamut) than
current display devices, such as CRT monitors and dye-sublimination
printers, can produce. In this respect it is good for archieval storage of
images since the pictures we see now will keep up with improving display
technology. When an image is scanned it is stored in terms of the three
reference primaries, these values, Rp, Gp and Bp are defined as follows:
Rp = kr {integral of (Planda planda rlanda) dlanda}
Gp = kg{integral of (Planda planda glanda) dlanda}
Bp = kb{integral of (Planda planda blanda) dlanda}
where Rp Gp and Bp are the CCIR 709 primaries although not constrained to
positive values. kr kg kb are normalising constants; Planda is the
spectral power distribution of the light source (CIE D65); planda is the
spectral power distribution of the scene at a specific point (pixel);
rlanda glanda and blanda are the spectral power distributions of the
scanner components primaries.
kr kg kb are specified as kr = 1 / {integral of (Planda * rlanda)
dlanda} as similairly for kg and kb replacing rlanda with glanda and
blanda respectivly.
Let's stop with the theory and let's see how to make transforms. To be
stored on a CD rom, the Rp Gp and Bp values are transformed into Kodak's
PhotoYCC color space. This is performed in three stages. Firstly a
non-linear transform is applied to the image signals (this is because
scanners tend to be linear devices while CRT displays are not), the
transform used is as follows:
Y (see Luminancy, item 2) and C1 and C2 (both are linked to
chrominancy).
YC1C2->RGB | RGB->YC1C2
- Gamma correction: | Y' =1.3584*Y
Red =f(red') | C1'=2.2179*(C1-156)
Green=f(Green') | C2'=1.8215*(C2-137)
Blue =f(Blue') | Red =Y'+C2'
where { f(t)=-1.099*abs(t)^0.45+0.999 if t<=-0.018 | Green=Y'-0.194*C1'-0.5
{ f(t)=4.5*t if -0.018<t<0.018 | Blue =Y'+C1'
{ f(t)=1.099*t^0.45-0.999 if t>=0.018 |
- Linear transforms: |
Y' = 0.299*Red+0.587*Green+0.114*Blue |
C1'=-0.299*Red-0.587*Green+0.886*Blue |
C2'= 0.701*Red-0.587*Green-0.114*Blue |
- To fit it into 8-bit data: |
Y =(255/1.402)*Y' |
C1=111.40*C1'+156 |
C2=135.64*C2'+137 |
Finally, I assume Red, Green, Blue, Y, C1, and C2 are in the range of
[0;255]. Take care that your RGB values are not constrainted to positive
values. So, some colors can be outside the Rec 709 display phosphor limit,
it means some colors can be outside the trangle I defined in item 5.3.
This can be explained because Kodak want to preserve some accurate infos,
such as specular highlight information. You can note that the relations to
transform YC1C2 to RGB is not exactly the reverse to transform RGB to
YC1C2. This can be explained (from Kodak point of view) because the output
displays are limited in the range of their capabilities.
Converting stored PhotoYCC data to RGB 24bit data for display by computers
on CRT's is achieved as follows;
Firstly normal Luma and Chroma data are recovered:
Luma = 1.3584 * Luma(8bit)
Chroma1 = 2.2179 * (Chroma1(8bit) - 156)
Chroma2 = 1.8215 * (Chroma2(8bit) - 137)
Assuming your display uses phosphors that are, or are very close to, ITU
Rec 709 primaries in their chromaticities, then (* see below)
Rdisplay = L + Chroma2
Gdisplay = L - 0.194Chroma1 - 0.509Chroma2
Bdisplay = L + Chroma1
Two things to watch are:
a) this results in RGB values from 0 to 346 (instead of the more usual 0
to 255) if this is simply ignored the resulting clipping will cause severe
loss of highlight information in the displayed image, a look-up-table is
usually used to convert these through a non-linear function to 8 bit data.
For example:
Y =(255/1.402)*Y'
C1=111.40*C1'+156
C2=135.64*C2'+137
b) if the display phosphors differ from CCIR 709 primaries then
further
conversion will be necessary, possibly through an intermediate device
independedent color space such as CIE XYZ.
* as a note -> do the phosphors need to match with regard to their
chromaticities or is a spectral match required? Two different spectral
distributed phosphors may have same chromaticites but may not be a
metameric match since metarimerism only applies to spectral distribution
of color matching functions. Another point to note is that PhotoCD images
are chroma subsampled, that is to say for each 2 x 2 block of pixels, 4
luma and 1 of each chroma component are sampled (i.e. chroma data is
averaged over 2x2 pixel blocks). This technique uses the fact that the HVS
is less sensitive to luminance than chromaince diferences so color
information can be stored at a lower precision without percievable loss in
visual quality.
----------------------------------------------------------------------
If anyone has a better idea, then shoot.
CU,
Christoph Egger
E-Mail: [EMAIL PROTECTED]
