Re: Matchlock Cyan Skies

["Miller Abel" <miller.abel@solopoint.com>]

<x-charset iso-8859-1>I'd still say that even though L*a*b* may not be perceptually uniform, if
sufficient precision is used in numerical calculations, there should be no
problem when going into and out of L*a*b* "as long as L*a*b* can fully
contain device RGB." So I guess it can not and therein lies the problem?

For example, you can apply gamma corrections to a file to achieve perceptual
uniformity of linear image data only if you do so in a high-bit depth
environment. To do these adjustments with 8-bit channels is to invite
round-off errors (which look like combing in the histogram).

The same applies for space-to-space conversions: Unless the calculations
into and out of the reference space are done with increased precision,
round-off errors will occur. Though that, by itself, is resolvable. But if
one uses a reference space which does not completely encompass all colors
that exist in the device spaces, clipping will occur.

For this reason, it would seem prudent for the CMM and profile building
tools to adopt a very large reference color space and use extended precision
on calculations to preserve colors. For example, use 80-bit floating point
CIE XYZ values to describe the reference space rather than 8-bit L*a*b*. You
will then have no hue shifts when going in and out of the reference space.
(It will also take *a lot* longer to complete a color space transformation
on a target image.)

But, as you say, if the working space is poorly chosen (like sRGB), the
relationship between colors in the space may make perceptually accurate
representation in device gamut problematic to impossible.

For those of us working in Adobe RGB 1998, however, there should be no
problem moving to Epson device RGB space (as described by an RGB ICC
profile) if a large enough reference color space (such as CIE XYZ) is used
with sufficient precision during calculations.

But I think I'm hearing that CMM and profile makers are not using CIE XYZ,
but are instead using L*a*b* which either isn't large enough or their
calculations are not including sufficient precision in each of the L*, a*,
and b* channels to represent the differences between Adobe RGB and the
printer's RGB space.

Miller Abel
Santa Cruz, CA

----- Original Message -----
From: <CDTobie@aol.com>
To: <miller.abel@solopoint.com>; <epson-inkjet@leben.com>
Sent: Wednesday, October 25, 2000 6:19 PM
Subject: Re: Matchlock Cyan Skies



In a message dated 10/25/00 8:24:55 PM, miller.abel@solopoint.com writes:

>> Avoiding any LAB based transforms (which are inevitable with ICC
profiles)
>> has the advantage of not invoking the blueshift issue in the first place
>
>Are you claiming that L*a*b* space is the only connection space used by
>all
>CMM's and that it can not fully contain RGB space and thus leads to an
>inevitable blue shift even if the source and destination profiles are
>identical? If that is the case, then it would seem that ICC profiles can
>never be made to work fully unless a different connection space is chosen.

No; LAB as a reference space for conversions has assorted advantages, such
as
being numerically uniform (units on all directions are the same size) but
unfortunately is not *perceptually* uniform, so certain out of gamut colors,
when brought into gamut, are also shifted visually. One thing that helps is
to avoid poor RGB spaces; sRGB is terrible for ICC conversions; there is no
such thing as a bright green in a file that has been converted out of
sRGB...

But profiling software is improving rapidly; as I pointed out earlier the
inability to get saturated greens with Lightjet and Lambda printers through
ICC profiles has virtually been eliminated. So I suggest we don't give up on
the whole system just yet.

C. David Tobie
Design Cooperative
CDTobie@designcoop.com

-
Turn off HTML mail features. Keep quoted material short. Use accurate
subject lines. http://www.leben.com/lists for list instructions.

</x-charset>