[OpenICC] Device Settings in ICC

Tue Sep 5 00:14:39 PDT 2006

Hal,

thanks for your answere and the points you mentioned.
I will go into detail inside your text.

Am 04.09.06, 12:02 -0700 schrieb 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?  

Thats not covered in the device settings tag. It would be more 
appropriately considered in an other spec. I can think of a number of 
conventions, lets say a workflow or more specific an API, to do a 
calibration process plus profiling.

legend for type of interaction:
  'M - full Manual'  'O - select Options (semimanual)'  'A - Automatic'

Something like:
o start of calibration [M,A]
o query what kind of device (including media...) [O+M]
o query what kind of driver [A,O]
o query what kind of driver settings (Cmyk/Rgb/...) [O]
o query what kind of IT8... (standard, generate, user supplied) [O]
o create the device settings tag (save to file is a option) [A]
o calibration (print a sheet + measure, measure monitor, photo of IT8...)
  probably stop the process and save the settings to continue later [A,M]
o profile + include the device settings tag and others [O+A]
o copy the profile to the destination [A,O,M]

Please note the above scenario can happen with minimal interaction. Most 
user decissions come by selecting options or providing or generating a 
file. Just things like specifying a paper type or do the calibration would 
need a full manual interaction.

> 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.

Yes, you are right. The information should be automatically interchanged.

> 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.

I expected here handling of device profiles only. The tag is usefull only 
for the drivers the profile was measured with. If the driver is identical 
crossplatform, why should it not recognise. Of course a application has to 
support the tag. For instance CinePaint, and shurely others as well, does 
colour management in the static way with lcms on unix. It does it the same 
way on osX with all advantages and disadvantages. So the tag would be used 
there as well for printing with Gutenprint or raw conversion with DCraw 
independent of the os.

> 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 think starting with a file dialog is the currently easiest option. Later 
a dedicated API to handle this through Oyranos can follow. It would 
include registration of profiler (name, capabilities, preferences...) and 
other components. But I'd need more capabilities in Oyranos first.

> 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.

Fine. Lets make it an other spec, as it can be independent of the ICC 
part.

> Hal

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