[Gs-devel] CIE calculation (SourceForge bug #465921)
L. Peter Deutsch
ghost at aladdin.com
Sat Nov 24 13:08:26 PST 2001
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
+ 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
+ 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
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
I would appreciate an acknowledgment of receipt, even if any final reply
takes some time!
More information about the gs-devel