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

[L. Peter Deutsch]

From: Paul Loewenstein [mailto:Paul_Loewenstein at SoftHome.net]
Sent: Sunday, November 18, 2001 3:25 PM
Subject: Ghostscript bug item #465921

I've written in PostScript the beginnings of what could become a CIE
simplification package.  It minimizes the CIE calculation by algebraic
simplification.  This would be performed for every call to setcolorspace
(to a CIE color space) and setrendering (neither of which are called
particularly frequently in typical PostScript code).

It is always possible for a PostScript programmer to make the
simplification ineffective, but for most likely CIE color spaces and
rendering dictionaries the simplification should:

 + 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.

 + Eliminate the arrays of constants in TransformPQR, retaining just
those constants used in the function (achieved by symbolic execution of
the functions).  I have written and tested prototype code that performs
this.

 + Simplify the functions as much as possible (TransformPQR in
particular will tend to have additions of 0 and other operations that
can be removed).

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

 + Eliminate range limits that cannot be reached because of earlier
range limits.

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

 + 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).

Although I have made sufficient of a start to be satisfied that it can
be coded in PostScript, it will require considerable work to finish the
task.  I wish to continue only if I can obtain buy-in from the
GhostScript team, so that there is every likelihood that it will be
incorporated into the official release.

I do not plan to address table lookup (rendering tables or the front-end
tables in the DEF etc spaces).  Other concerns are:

 - The code is highly recursive, so it should monitor the recursion
depth and bow out of the optimization should the interpreter limit be
approached (this should be rare).

 - There is no way to simplify everything that a PostScript programmer
can theoretically code.  Untreatable cases must be detected, and the
optimization abandoned so that at least correctness is maintained if not
execution speed.

I would appreciate an acknowledgment of receipt, even if any final reply
takes some time!

        Paul.