[OpenICC] Device Settings in ICC

[Hal V. Engel]

On Monday 04 September 2006 09:18, Kai-Uwe Behrmann wrote:
> Dear readers,
>
> 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.
>
> Goal is to allow easy checking of profile to device/driver matching and
> correct configuring of the device driver. The best matching profile can
> be filtered for a given device/driver combo. Thus the installation of a
> profile, including the new tag, becomes a simple file copy. Everything
> else is configured automatic by the tag.
>
> Technically it is a hybrid approach of well known and interpreted settings
> and a thumb part to keep the structure flexible.
>
> http://www.oyranos.org/wiki/index.php?title=Device_Settings_in_ICC_0.1
>
> I would, as allways, be interessted in opinions and suggestions.
>
> Target is to create an API in Oyranos to support the tag (writing,
> manipulation, searching), and to encourage device driver authors to
> provide the necessary counterpart API's (Gutenprint, Sane, dcraw ...).
> Possibly there is room to standardize corresponding driver API's for
> uniformity?
> Finally applications can adopt the system.
>
>
> regards
> Kai-Uwe Behrmann

I read the spec. and it has merit but I do have some concerns.  Specifically 
with "A profiler should ideally write the tag into the profile it self to 
minimize error prone interactions." (edited to correct spelling and typos)  

How is the profiler going to know anything about the device settings or what 
specific device is being profiled?  For example with input profiles (scanners 
and cameras) the profiler sees an IT8.7, ColorChecker or HCT image that is 
used to generate the profile but does not interact directly with the device 
driver or device interface software in any way.    Monitor profiles may be a 
little simpler in this regard since the profiler does interact with the 
hardware but also the device settings are subject to fewer changes by the 
user.   But printer profiles would appear to have problems that are similar 
to input profiles in the regard.  How does the profiler know what settings 
the user used to print the profiling target for example?  

It also seems problematic to write a UI dialog to allow users to enter this 
information.  For one thing the needed information would be different for 
each type of device and could also be different for the same device types 
with different drivers.  Even if it proved to be not too difficult to write a 
UI dialog for the profiler to allow users to enter this information that does 
not solve the problem since the profiler would not have any way of knowing 
what device was being profiled and would have no way to validate the 
information entered by the user.   Also it seems to me that the "driver 
specific configuration data" and the "drivers signature/encoding" are 
something that a user is very unlikely to know.  So that means that there 
needs to be a well defined device driver to profiler interface for passing 
this information to the profiler from the device driver.

To make things even more problematic both open source profilers are cross 
platform software that run on *nix, Windows and the Mac.  A device driver to 
profiler interface spec for *nix to facilitate getting the correct driver 
information to the profiler would end up being a useless appendage on the 
other platforms since it seems to me that the probability of getting the 
writers of Windows and Mac device drivers to include this in their drivers is 
near zero.  If the interface is simple enough then this is only a minor 
issue.

One possible approach would be for the device driver/device interface software 
to write a file that contained the tag that the profiler could insert into 
the profile without having to know anything about the device in those cases 
where the profiler is not interacting directly with the hardware.  Then the 
interface for the profiler becomes fairly simple (ie. ask the user where the 
device information tag file is located).  Another possibility would be to 
have some type of higher level interface in perhaps Oyranos or X.Org or ?? 
that would allow for the exchange of this information.

I would like to see more detail about this part of the spec. and I would be 
willing to contribute to that effort.  Being the maintainer of one of the 
open source profilers I only represent one part of this interaction (and 
perhaps Graeme has a totally different view of this than I do) and it would 
be useful to have some input from those who support device driver/interface 
software such as guten-print,  DCRAW, xsane, UFRAW and others since, it seems 
to me, that they would have the burden in creating the tag data and would 
also stand to gain the most from such a system.  After all the profiler is 
basically a middle man in this process.

Hal