[Openicc] [Gimp-print-devel] [Printing-architecture] Colour

[Graeme Gill]

Michael Sweet wrote:
> The API for setting up an identity transform isn't public but *is* available through
> developer technical support. Basically this hasn't been included in public
> documentation because even the "experts" writing profiling software have used the API
> incorrectly (for various reasons the API is semi-complicated), and we don't want to
> encourage the use of device color on Mac OS X except when it is actually needed (which
> is basically only when printing a target or doing application color management...)

It has an another important use, which is to verify a calibration or profile
without invoking the system or printer CMM.

	Print the profile chart to device space.
	Read it and create profile
	Convert verification chart to device space using
	         a standalone tool you trust (ie. cctiff)
	Print verification chart out to device space.

This is one important diagnostic step, to make sure that
the profiling has worked correctly, before deciding if something
is going wrong in application, system or print driver CMMs.

> ... and thus more likely to be used.  It is hard to turn off ColorSync on purpose -
> there are very few scenarios that actually require it.

This could be solved very simply. Don't label it "DeviceRGB" or "DeviceCMYK",
label it "calibration test chart mode".

> The problem is that DeviceRGB was being used for everything, not just for those cases
> that needed it, so it was basically impossible to know what the intent was and get
> consistent output from applications.

I'm sympathetic to this issue, since we did exactly that sort of thing when
dealing with PostScript at Colorbus. Many applications used Device colorspaces as
a default, and expected reasonable behavior. But we provided an escape
for profiling and calibration (these are separated for systems that
provide both), so there was no issue or ambiguity about test charts.
A test chart could be printed at any time, as is, and the print
driver would do the right thing. There did not need to be any software
for figuring out what the device profile was.

> Epson (and all of the other printer vendors) work closely with Apple engineering, but
> there are still problems that slip through our combined testing.  The problem I
> described has come and gone for specific drivers many times, and often re-appears in
> new drivers the first time we get an update from them - we reject any that we catch,
> but as you can imagine we can't test every driver and printer so problems *do* slip
> through.

The fact that such a problem keeps re-occurring is an indication that there is something
fundamentally wrong here. What's fundamentally wrong is the lack of a "calibration test 
chart mode" flag.
This has not been a minor stuff up :- it has been talked of many times over the
course of the CIC for instance.

Graeme Gill.