[Openicc] adding informations to ICC profiles

[Kai-Uwe Behrmann]

Am 24.11.05, 19:01 +1100 schrieb Graeme Gill:

> Kai-Uwe Behrmann wrote:

> > My idea is to take a whatever text blob from the device driver and embedd
> > into the profile and give it back to the device driver to convert back to
> > device settings by the driver itself. The idea came me by looking how
> > Gutenprint stores its settings.
> > Thus a driver can write an short identifier only, compress (ok that would
> > be a 'data' tag), xml-ise or use a native format like Gutenprint does.
> 
> You could use this approach, but another way to go would be to make
> it a binary blob, with a leading magic number that identifies the
> environment, so that if a profile ends up somewhere else, the
> system doesn't accidentally use a blob not intended for it.

Binary is good. Ok I understand now, the magic number allow secure parsing 
by the intended driver. Yes seems good to me.

> Anyone can register a custom tag as far as I know - the
> ICC folks have been very good about this sort of thing.
> 
> In a philosophical sense, I'm not entirely convinced that this
> is the way to go. Part of the idea of ICC profiles is that they
> can be useful between different systems.

I hope it will work between systems. For instance separate for the 
above printer. The resulting cmyk image is device and settings dependent 
(+ ink and paper, which we can not automatically detect - no rfid ;)
Producing such a image on linux and sent to say to solaris it should 
simply work provided the driver (Gutenprint-5.0.0rc1) has the correct 
version and the printer too (Epson3000).

> The other approach is that the color system keeps a record itself
> of a particular configuration, and registers the profile in it.

As I understand, that is not embeddable to the image and will not work as 
in the previously described scenario.

> This approach has the advantages that it doesn't require messing
> with the profile, and you can register the same profile for multiple
> system configurations. The alternative for embedding the configuration
> within the profile, is that you have to allow for a list of valid
> configurations (much like the "deviceSettingsTag"), or you have
> to make multiple copies of the profile for each configuration.

Yes, thats really the drawback of my approach. But are multiple system 
configurations that much used? Profiles are often refered as one chain one 
profile.

My hope is all device settings, wich are important for colour, and only 
these are present in the "_deviceSettingsTag_". Thus if something differs, 
it is very likely the profile does not match anyway. On the other side: a 
device driver is allways free to allow for instance alternative media 
like:

[driver settings section]
printmedia = photo shiny {photo shiny gold border; photo shiny paperboard}
other_setting = xxx
# or allow tolerances
gcr = 0.5 <0.05> # 0.45 - 0.55

> Graeme Gill.

regards
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b at gmx.de
                                + http://www.behrmann.name