[Openicc] GoSoC 2011: CPD and Color Management

[Chris Murphy]

> On Mon, May 2, 2011 at 10:43 PM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>> I am searching a way to unambigously pass settings from the print client
>> (CPD, lpr) to the CUPS server and print driver (rastertoprinter).
>> There are two ways possible. Embedd the device calibration settings always
>> into the print ICC profile. Or pass these settings independently.

On May 2, 2011 at 11:39 PM, edmund ronald wrote:

> I would recommend finding a way to pass the ink settings independently
> of a profile.
> 
> Because:
> The settings describe device linearisation and used choices (eg. dpi
> setting) and thus PRECEDE the profile in time.
> In this way the first prints -Targets- will be made with a given
> setting by printing to DeviceSpace for profiling.
> Many profiles can be made for a given set of settings, indeed some of
> these can refer to different paper types for which it is convenient to
> reuse a given ink setting.
> 
> My Reasoning
> Is that settings are quite independent of profiles, and should thus
> not be bound to any one setting.
> Indeed Robert generates settings but AFAIK has never made a profile.
> 

Fred Bunting, one of the RWCM co-authors, made a compelling argument against the vcgt tag in ICC display profiles - the idea that the profile describes the device behavior, not establishing device behavior. That is characterizes a device, does not calibrate it.

On Windows vcgt is still not supported AFAIK. All monitor calibration/profiling tools write out calibration information in a proprietary file of some sort (preference file I guess) and a startup application reads that, and applies the calibration to the display and makes sure the proper corresponding profile is set as the default display profile. The thing is, it is much more likely on Windows that you can get a calibration and profile mismatch because of this separation. So in practice, vcgt is probably a good thing, even though it is conflating two different things: calibration and characterization, in an ICC profile.

I'm not immediately concerned whether the print settings are included in the profile or not. If it were possible to envision a day when al gutenprint driven printers, on Mac OS, Windows, Linux, could read these settings from the profile and know how to configure the print dialog correctly (either by choosing a print condition profile; or by choosing certain media types and settings which would then cause the correct profile to be automatically chosen) then this would be very good indeed. And it would make sharing profiles and settings much simpler if they were in a single file per print condition.

Now that immediately raises the issue of sharing ICC profiles, which all commercial products have varying license restrictions on how they get shared. There is common practice which probably will not really be punished under EULA's but in effect users are agreeing to ICC profile sharing behavior that is problematic with respect to those EULA's. In my view an ICC profile is not any different than a Word, Excel, TIFF or JPEG document. I'm not restricted in any way from sharing such files, although I am restricted from reverse engineering their transforms - baked into those files. There is a practical problem with a EULA that's as permissive as Microsoft's or Adobe's (or countless others) when it comes to the "output file" produced from an ICC profiling app, mostly because of the incentives surrounding the baked in transform needing to be protected. If it's not, one company (any company) could buy a copy of a profiling application and then start selling profiles for $5 each. This would cost Microsoft and Adobe very little, if any money, it might even make them money as people want to read the contents of these files. Whereas with the ICC profile, it's never a meaningful input file for the application that created it.

So I think relying exclusively on embedding print settings metadata in ICC profiles could be a problem, even though I like the idea. One file makes things unambiguous and easy for users to share. But there is a practical problem, possibly, with that sharing.



Chris Murphy