[OpenICC] Device Settings in ICC

[Kai-Uwe Behrmann]

Am 05.09.06, 14:24 +1000 schrieb Graeme Gill:

> Kai-Uwe Behrmann wrote:
> > as discussed some time ago and prepared on the ColourWiki pages I finally
> > created a specification on how I imagine a ICC profile could include
> > device driver specific settings.
> 
> Just to address some narrow technical issues first:
> 
> If you're going to introduce a custom ICC tag (which
> seems to be what you are suggesting), then I'm presuming
> that you're suggesting a tag signature of 'DevS'. Are
> you intending to register that signature with the ICC ?
> If not, what's to stop that tag signature being
> used officially by someone else, some time in the future ?

Yes the tag should be registred.
 
> The tagtype you're suggesting, uses the signature 'data',
> but this tag is already reserved by the ICC, and has a
> different layout. Bytes 8..11 contain a flag, indicating
> the type of data (ASCII or binary), and the data payload
> starts at offset 12.

'data' was choosen as an intermediate step. But you are right it should 
fit in the standard. Thanks for pointing out.

> Assuming you fix this problem, then since 'data' is a general
> purpose tagtype, I'd also suggest perhaps adding
> a magic number, and version number at the start of the
> payload data, to provide some error resilience, and
> some allowance for coping with changes in the future.

I would prefer a new type and address the issues this way.

> The allowance for only 6 bytes for various names, seems
> rather restrictive. Many names are likely
> to be longer than this, ie. "Epson 1800" exceeds this.
> A USB serial number is a string, so nothing restricts it
> to being 6 bytes or less either.

6 Bytes is for the company name only. I hope most companies use 
distinguishing names to it might be enough. For Device names I needed more 
letters. So the next entry has 18 letters available.
If you come up with examples of undistinguishable names, I would 
certainly change my mind.
On the other side compactness paired with simplicity is very important.

> A lot of the information I would have expected to be used
> for matching, isn't there, ie.
> type of paper, printing resolution, quality/speed setting,
> inkset (ie. photo black vs. matt black etc.), and so on.

Thats up to the configuration settings. Which way would you expect 
to use such information in standard fields? One approach would be 
using PPD format for the settings information and extract the above 
mentioned from there. Most print dialogs support PPD anyway. It should be 
little additional work to grep through the information.

As media, resolution and ink sets are printer specific, the dont make 
sense for other device types. As well covering all settings would be a 
major investment. The approach is flexible enough to benefit from a new 
PPD format.

> If this is all buried in the driver specific configuration
> data, then it's not clear how it gets from the driver
> into the profile.

The driver must provide its settings. Such a interface must exit or must 
been created. Otherwise it is pointless. In the case of existing 
interfaces with own data structures, they can easily used as is. Just 
write the application that takes advantage of it.

> Addressing some wider issues (and Hal has already raised
> a large number of them), then I'd like to understand
> what alternatives to introducing a private tag were
> considered.
> 
> For instance, the ICC have already standardized
> a number of tags for encoding the device and settings.
> Since they were created for various circumstances, they
> may not address everything necessary, nor will they
> probably map directly into something that is useful
> in your specific circumstances, but they should at least
> be examined, and some attempt made to use standard
> tags if possible.
> 
> Existing tags for this general purpose are:
> 
> icSigCalibrationDateTimeTag

is mentioned as a recommendation in relation to the DevS tag

> icSigColorantOrderTag
> icSigDeviceMfgDescTag
> icSigDeviceModelDescTag
> icSigDeviceSettingsTag
> icSigProfileDescriptionTag
> icSigScreeningDescTag
> icSigScreeningTag
> icSigViewingCondDescTag
> icSigViewingConditionsTag

Thats a fine advice. I will check and can probably drop some of the 
static fields.

> One approach would be to encode the information
> you want as a text string, in (say) the
> icSigDeviceModelDescTag.
> 
> Another possibility is the icSigDeviceSettingsTag,
> which could be expanded in a relatively compatible
> way, without having to worry so much about
> collisions with existing or future use.

I must have overseen. After some reading, the tag seems complex, 
inflexible and is half way finished (too less options, msft only).

> The thing to do would be to register a platform
> signature for *nix with the ICC, and then
> there is a great deal of flexibility to
> create device setting signatures, and device
> setting values in this tag, since they are platform
> specific.

A good point too.

> (A complication is that icSigDeviceSettingsTag
> has been removed from ICC V4.2, but its format
> was standardized in previous versions, and
> therefore will still be recognized correctly
> by all ICC software, for backwards compatibility).
>  
> Another option is not to place this information
> in the ICC profile itself, but to have some
> other sort of record, which points to the ICC profile.
> This isn't as convenient or bullet proof for things
> like installation, but probably wouldn't make things
> any worse (and might be easier in some ways), in
> terms of creating profiles, and would mean the
> whole ICC registration issue goes away.

I had thought of prepending the information and providing compatibility 
through a extraction and embedding function + a commandline tool. See:
http://www.oyranos.org/wiki/index.php?title=Device_Settings#Implementation_Details

> I hope these thoughts are useful.

Of course they are. Thanks!

> Graeme Gill.

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