[OpenICC] Device Settings in ICC

[Kai-Uwe Behrmann]

Am 05.09.06, 00:13 +0200 schrieb Gerhard Fuernkranz:

> Robert L Krawitz wrote:
> > I'd suggest adding a field specifying the highest allowable driver
> > version also.  For example, a profile made against Gimp-Print 4.2.7
> > should not be used with Gutenprint 5.0.0 (of course, these can be
> > disambiguated by name, but that's only because we renamed the package
> > -- we certainly won't be making a habit of that!)
> >   
> 
> Why the highest allowable driver version? For instance, when I create
> now a profile for 4.2.7, how can I know in advance, which future driver
> versions will exist at all, and which future version will be the highest
> color-compatible "allowable" one? IMO it must work vice versa, i.e.
> rather the driver version used to create the profile should be recorded,
> and future driver versions should know about older driver versions, and
> they should know, whether they are still "color-compatible" to
> particular earlier driver versions or not (note, even if the native
> color rendering has changed in a new driver version, the new driver
> still may support legacy rendering modes for backwards compatibility).
> Only the (new) driver can know whether it can still cooperate with the
> (old) profile, or whether it needs to refuse the profile.
 
Yes, I agree here.
Well the idea is to query the driver for a compatibility version for a 
special device and decide if the profile is useful at all? So the system 
would not rely on guessing and could preselect matching profiles, which 
are useful to the user.

Functions for this could look like:

 const char* getDriverName()
 int isDeviceColourCalibrationSupportedByDevice (
                   const char*  device_manufacturer,
                   const char*  device_name,
                   const char*  driver_compatibility_version )


> I'm also wondering whether such a compatibility information needs to be
> recorded in the fixed part of the data structure? As only the driver can
> interpret this info and can know, whether it can still cooperate with
> the (old) profile, or not, I'd tend to record it in the driver-specific
> blob, together with the other driver settings (which may be version
> specific as well).

In your scenario the system must rely mostly on the driver. With the 
current approach at least a 1:1 match is possible with dumb or old 
drivers, provided they tell about their version.

> In fact I'm even wondering, which information in the suggested "DevS"
> tag needs to be interpreted by an instance != driver? Is there really a
> need for all the fixed fields, or would probably even a tuple
> [driverID,driverSpecificSettingsBlob] be sufficient?

The idea is to gather informations about devices and drivers from 
different sources or at different stages.
If a application wants for instance to interprete a incoming digital photo 
it can query for the according device, which is driver independent and 
then select a appropriate driver and query for its compatibility version 
for that device. After that the application (or Oyranos) searchs for a 
matching profile.

The compact version you ask for would be something like a deviceDriverID,
which is not standard on Linux. Device handling is spread over various 
API's currently. It would be harder to maintain.

On the other hand a ID as the suggested can be easily created from the 
field in a os-specific fashion. Thus the fields stay os independent.

> I also tend not to use a fixed structure as suggested, but rather a
> tagged format, which allows variable length parameters, and which can be
> easily extended in the future with new tags if needed. Personally, I'd
> even prefer an ASCII format for the whole contents of the "DevS" tag,
> for instance simple identifier=value\n pairs, or XML, etc. For
> maintaining the tag in profiles there could be a simple utility program
> which dumps the DevS tag to a file, or vice versa, reads a file and adds
> its contents as DevS tag to a profile (or replaces an existing tag).
> This would give the opportunity to maintain the DevS tag, even if the
> profiler is not aware of this tag (for instance, if an arbitrary
> commercial profiler is used). And if the contents of the tag is ASCII
> text, a file with the DevS contents can be easily edited with a text editor.

Well, I plan to create a command line utility to dumb from and embedd the 
tag into existing profiles.
For the variable lenght I have to think about. My concern was to keep it 
as simple as possible. Comparing the first 11 bytes of a string should
suffice in most cases to find a match.
The ICC took the shell approach to leave old tags and create new ones as 
necessary. It seems reasonable to me.

Maybe some more bytes could be reserved for future use.

> Regards,
> Gerhard
> 

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