[Gs-devel] RE: [Gs-code-review] callback for tint transform in shading fill

[Dan Coby]

Peter,

> ...  Then we can eliminate the callbacks from
>the PostScript interpreter entirely, which would be a big relief.

I agree that the callbacks are a pain but I am worried about efficiency.
(See next item.)

>The sampling could be done with a special operator, so that it would be as
>efficient as the current code for sampling transfer functions, BG, UCR, CIE
>functions, etc.

I am worried about the execution time with sampling data for a color cube.
The Adobe documentation gives examples of color spaces with 6 and more
components.  A full cube with only 10 elements to a side and 6 components
would have 1,000,000 values. I assume that even with a special operator,
the tint transform function would have to be executed the full one million
times.  In theory the size of cube can be drastically reduced by trying to
determine which components interact and which do not but this requires
considerable development work.  (On the positive side, the examples with
large numbers of components all convert into type 4 functions.  Many real
cases only have one component.)

The easiest way to implement the color cube would be to have the DeviceN
code sample the cube data when a DeviceN color space is created if the
tint transform function cannot be converted into a type 4 function.  This
could result in considerable overhead if there are a large number of
components or if many DeviceN color spaces are created.  The cube data is
only needed in a few places.

The overhead could be reduced by only sampling the cube before starting
something like the shading fill logic that will require the cube
information.
This approach requires putting hooks for sampling the cube into several
places (see Ray's list).

My current opinion is to implement the first idea since the implementation
is likely to be much less error prone.  This would also mean that the cube
data would be available to the pdfwrite device.

Dan

-----Original Message-----
From: L. Peter Deutsch [mailto:ghost at aladdin.com]
Sent: Thursday, October 18, 2001 5:08 AM
To: dan at artifex.com
Cc: gs-devel at ghostscript.com
Subject: Re: [Gs-code-review] callback for tint transform in shading
fill


Dan, please note that I've moved this discussion to gs-devel, since it
raises larger issues than the specific fix.

> This problem is that the shading fill cannot handle the interpreter
> callback needed if the current color is a DeviceN color and the tint
> transform function cannot be converted into a type 4 function.
>
> For a longer term solution to this problem, the use of a color cube has
> been proposed.

This depends partly on what Raph is going to do about rewriting the shading
code.

It is already the case that some code (transfer function?  CIE functions?)
detects Function procedures (Function objects wrapped in a procedure with a
%execfunction) and handles them efficiently.  For tint transform procedures,
and perhaps eventually for other places that currently do PostScript
callbacks, I think PostScript code (setcolorspace, shading setcolor, shfill,
etc.) should look at the procedure and determine whether it is a Function
(do nothing), a PostScript procedure that can be represented as a
FunctionType 4 function (convert it), or some other procedure (sample it and
create a FunctionType 0 function).  Then we can eliminate the callbacks from
the PostScript interpreter entirely, which would be a big relief.

The sampling could be done with a special operator, so that it would be as
efficient as the current code for sampling transfer functions, BG, UCR, CIE
functions, etc.

--

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