[OpenICC] Device Settings in ICC

[Robert L Krawitz]

(Again copying printing-summit, since this bears directly on one of
the main subjects for discussion on that forum.)

   From: "Hal V. Engel" <hvengel at astound.net>
   Date: Mon, 4 Sep 2006 12:02:17 -0700

   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?

Drivers would need to provide a mechanism to allow querying this
information.  This, of course, would require the profiler to interact
directly with the driver.  Gutenprint is already designed for this
model of interaction; all that would need to be added is a way to
determine whether a particular setting influences color or not.  I'd
like a bit more of Kai-Uwe's take on what he sees the driver doing
here.

I'm discussing printing here because that's what I care about and it's
also likely to be the most complex.  In addition, most of the existing
ways of interacting with printer drivers in Linux/UNIX block any
direct interaction between the driver and the application (which in
this case would be the profiler).  Applications basically specify
options based on static PPD files; there's no back channel, which is
what this proposal really needs.

Another approach here would be to allow the printer driver to specify
part of the printing dialog.  If the driver owned all parts of the UI
that pertain to color, this would considerably simplify the high level
API; all that would be required would be a way for the driver to
return the required settings (as a blob) to the profiler to stick into
the profile.  The driver would need access to the profile in order to
read the blob.  This isn't hard with a locally-attached printer, but
in a networked environment this whole thing becomes very difficult.
It requires either some very fancy footwork for the server-side driver
to specify the UI, or alternatively for the matching driver to be
installed client-side to provide the UI.

A possible compromise here would be for the server to supply a dynamic
PPD file to the client.  We would need to figure out how to tell the
server what profile is desired so that the server could ask the driver
to create an appropriate PPD file.

I'd still like to see a more flexible approach for the driver even if
we can't solve all of the network issues right away.

   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.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gutenprint   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton