[Openicc] GoSoC 2011: CPD and target printing

[Chris Murphy]

On May 12, 2011, at 9:15 PM, Michael Sweet wrote:

> On May 12, 2011, at 1:44 PM, Chris Murphy wrote:
>> ...
>> That's not how profiling applications have worked, historically. They came with pre-built targets, and the apps have functioned on a legacy of opt-in color management so an app to print the target wasn't needed.
> 
> A couple things:
> 
> 1. Opt-in color management has never existed on Mac OS X, and Windows and Linux have implicitly used sRGB with no common/well-defined opt-in *or* opt-out mechanism.

No, Mac OS X for years was opt-in for display color management. If the developer did not opt-in, there was no conversion (i.e. Display RGB/ Monitor RGB). For print, prior to 10.3.9, in effect it was opt-in because if the application did not tag anything, the system assumed Generic RGB for source and destination and we'd (usually) get a null transform pretty consistently.

For Windows, it's very clearly opt-in for ICC based color management. The idea that it's sRGB is a bit of a misnomer, since everything is assumed to be sRGB, you in effect have a bunch of no ops occurring without any involvement of APIs. Only by explicit use of APIs would ICC/WCS transforms occur. 

> 
> 2. Canned targets have always been of limited usefulness when profiling, particularly for printers that go beyond the basic 1-level-per-color CMYK ink set.

I don't understand this. If the profiling workflow is to print a single target, non-iterative, which is the vast majority use case, the target is standardized, often proprietary, whether RGB or CMYK.


> 
>> With the advent of opt out color management, Apple very ridiculously failed to provide either an application for printing these targets reliably, and also to provide key developers with a reliable, documented, or publicly available means of opting out for the purpose of printing targets and printing prematched images. Both of these were necessary from the beginning once an opt-out system was implemented.
> 
> You'll get no argument from me that the current system for printing targets or doing app-based color management is broken. However, I also don't buy that app-based color management is the right long-term solution - it is just a band-aide until we can fix things properly.

?

There has been a net retraction in color management by Apple, not progress or innovation. Support for 3rd party CMMs in the print path, removed several OS revisions ago. Scripting support has been reduced, not enhanced. Intentional deviation from PDF/X-3's requirement that when source=destination that source object's color space be set to /DeviceXXXx, not ICCBased. There have been three major OS releases attempting to implement Black Point Compensation, none of them work, none are well documented, and once the OS ships no effort is made to fix it.

Until there is an 100% effective automatic rendering intent selection algorithm, or a CMM using dynamic and spacialy adaptive gamut mapping, including the use of black point compensation, in the print dialog UI - I don't see how we get rid of app-based color management. 


I see exhibits A, B, C, and D that Apple does not care about color management at best, and at worst would like to return to a closed loop system, and lock it in place unmodifiable by anyone and if we don't like it, please use another OS. That is the apparent direction based on actions.


> 
>> My primary suggestion is that we don't need more UI in print dialogs, things should just work. The use case isn't there so long as there is a utility and API that are reliable and freely available. But Apple has provided neither. Instead there is a private SPI that has largely been denied to exist until very recently, still is private, undocumented, and not locatable on the dev web site, and one which doesn't actually ensure ColorSync's transforms are disabled. And on top of it, Apple deferred to Adobe to create the utility for printing profile targets. I find that quite inappropriate to kick the can of responsibility down the road to some 3rd party who has no control over the SPI on which the utility depends.
> 
> I wouldn't quite characterize it that way, however we certainly have failed to deliver on a target printing application. I keep pushing for it (or a simple API) internally...

As do I, but PDF/X-3 (4 or 5)  provide a rather clear mechanism in the print path to get what's needed. If Quartz PDF Context were compelled by the use of kPMApplicationColorMatching to accept only *one* ICC profile, which would become the OutputIntent, and all objects in the PDF were set to /DeviceRGB (the most common output devices being RGB), suddenly we wouldn't need a convoluted null transform scheme. The objects would be exempt from even being inspected by ColorSync, they'd all be set to /Device space, we wouldn't have to worry around malformed print drivers doing the wrong thing (two of which I've found are going to be in shipping products, ergo the problem of malformed print drivers is not going away, it's obviously too complicated for certain companies to get right in our lifetimes).

And it would require no UI change. And it would make kPMApplicationColorMatching a whole lot easier to implement, as the developer wouldn't have to tag every object with an unnecessary source profile. The correct space is /DeviceRGB for all of those objects, not ICCBased. This is a very old argument, I continue to be surprised by the resistance I get for the suggestion, and the extreme hatred Apple has for /DeviceRGB. Therein lies most of our problems.


> 
>> So regardless of verbal intentions, the actions to me demonstrate something between disinterest and hostility toward ICC based workflows that require custom profile generation and usage without ColorSync.
> 
> Please don't confuse inaction with hostility or disinterest towards the workflows - everyone involved in printing and color management at Apple wants ICC-based workflows to "Just Work", but there is a lot of (very passionate, at times) disagreement over how to get there. :)

It's not just inaction, it's active retraction of features and function.

And you know, we are all mortal, we're going to die one day in the not too distant future, and it seems Apple will still be passionately disagreeing internally on how to implement something that isn't really all that difficult to make infinitely more reliable than it is now. If this were a priority, it would simply have happened. The very fact it hasn't absolutely means one of two things: it is not a priority, or Apple is unaware of the immense user pain at the amateur/professional level who need a working ICC-based workflow, which also requires the disabling of ColorSync (most of the time) due to its lack of features INCLUDING the one to reliably disable it.


Chris Murphy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110512/49729f6b/attachment.htm>