[Openicc] Re: LINUX, Gutenprint / CUPS / Color policies

[Stefan Döhla]

Hi List,

> What is needed to get beyond the limitations of color space
> dependent policies - and is becoming 
> at least conceivably practical - is metadata that records what
> has been done to color objects - and 
> is carried with those color objects.

This would really simplify things for intelligent devices, where image
data passes through. I have another idea, that is little more complex,
but possibly worth thinking about it.

In the following, I'm talking about "devices", that can be real
hardware devices or apps or whatever is dealing with the image in the
workflow.

Just imagine, every color-management aware device can signal to the
device, that called this device, what capabilities it has. Example:
the printer tells the printer driver: I have A4 paper and a glorious
CMM built-in. This information can be used by the printer driver to
tell the app (e.g. Gimp, Photoshop, whatever ...) that there's no need
to do the color-conversion in software, because the printer can handle
it (at least it claims, that it can do it better and faster, ...).

On the other hand, the current device passes the history of already
done conversions to the next device, including commands, which device
in the chain should do the color-conversion.

Since the first device in the chain knows everything, that's coming,
it can decide, what to do - even, which devices are needed in the
chain to handle everything properly. This applies to every device in
the chain. The only rule is: A following device must do, what the
preceding device (or any other device before) wants, given a fixed
command - or the history, by which the device can decide, what to do.

Devices can be either dumb (do nothing with the metadata (history and
capabilities)) or intelligent (allow building the command chain, add
history entries, execute commands). Color-managed devices must be
intelligent, whereas any other device is usually dumb. Devices that
are already color-management aware can not use this approach directly,
but must have a device in front of it, like a printer-driver-proxy
that sends and receives metadata, whereas the old device does the
color-transform and passes metadata through.

> I hope the above is not too far off topic.  If it is possible to
> move in the direction of such metadata,
> it seems practically conceivable to encode such metadata in something like xml, for example.
> Such file formats as VDX, and PDF now support such xml metadata - and there are probably others?
> Also, certain job control - such as JDF - allows for xml extensions.

The approach above must use any other transport for the
capability-metadata transport but not image data. The image does
only contain the history and commands. A method for building the
reverse chain could be everything from a broadcast of the capabilities
to a webserver, that discloses the capabilities.

Does this seem reasonable?

Stefan

-- 
Stefan Döhla
mailto:color at doehla.de