[Gs-devel] CIE calculation (SourceForge bug #465921)

L. Peter Deutsch ghost at aladdin.com
Sat Nov 24 13:22:19 PST 2001

Regarding Paul Loewenstein's CIE optimization project:

Ghostscript's current CIE code already does these things (although it isn't
as careful about range clamping as it probably should be):

>  + Merge linear transformations with adjacent matrix transformations.
> (Most TransformPQR functions are linear.)

>  + Merge matrices that do not have any functions or range limits between
> them.  Remove all identity matrices.

It could trivially do this one (which I had failed to notice that the PS
spec permitted):

>  + When the rendering and color space black points and white points are
> identical, eliminate the PQR portion of the calculation.  I don't know why
> Ghostscript doesn't already do this as it's easy to detect and is
> specifically permitted in the PostScript specification.

It could easily do this one, by detecting that the Encode/Decode procedures
are simple gamma correction (code for this is already implemented in

>  + Combine the input gamma correction removal with the output gamma
> correction when the intervening transformation reduces to a diagonal
> matrix (as it does when the CIE colorspace/rendering is used solely for
> gamma correction).

As for the rest, all of these functions are sampled, so the time required to
compute the functions is not particularly important: the time required to do
the sampled lookups and interpolations is much more important.  That is
currently done in streamlined C code that takes the above optimizations into

As Paul pointed out, using real functions rather than sampled tables could
produce more accurate results in some unusual non-linear circumstances.
However, it would be vastly slower (requiring running something like the
FunctionType 4 interpreter every time a color had to be mapped, rather than
hard C code), unless it was backed up with a cache that either would have to
be gigantic, or would use some form of interpolation that in turn would
reintroduce some of the same inaccuracies in highly non-linear conditions.

Also, this approach would require completely rewriting -- and I mean
*completely* rewriting -- Ghostscript's current CIE color rendering code.
It would require throwing out the current approach of pre-sampling the
functions and then using hard C code to do the cache lookup.  Instead, it
would require analyzing the various functions and matrices, transforming
them in the way that Paul discusses, and *then* taking any that couldn't be
reduced to FunctionType 4 functions (presumably augmented by matrix
operations, or perhaps with the matrix operations being expanded out into
scalar ops) and sampling them into FunctionType 0.

I'm not opposed to examining such an approach, but I would want to be very,
very careful to understand the pros and cons before adopting it.  For
example, one much simpler approach that might go a long way towards handling
some of the current sensitivities might be to selectively use finer-grained
sampling and/or bicubic interpolation near the extrema of the domains of the
various functions.


L. Peter Deutsch     |    Aladdin Enterprises   |  203 Santa Margarita Ave.
ghost at aladdin.com    |  http://www.aladdin.com  |  Menlo Park, CA 94025

	The future of software is at http://www.opensource.org

More information about the gs-devel mailing list