[Openicc] GoSoC 2011: CPD and target printing

[Michael Sweet]

On May 12, 2011, at 9:00 PM, Chris Murphy wrote:
> 
> 
> 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.

ColorSync has always been there for printer drivers, it is just that most drivers use the default RGB "connection space". And to make matters worse, many Mac drivers used sRGB-based color tables but specified the old Generic RGB color space so you got consistently wrong color.

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

Canned test images don't allow you to properly characterize the real DeviceN color space of the printer. Imagine generating a color profile "backwards" from DeviceN - the target image would be based on the number of colors and levels per color, and the profiling app would then pick a set of "best" patches for desired color values.

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

I don't remember us ever supporting third-party CMMs in Quartz. You can still plug in your own RIP.

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

Please send me the bugs you have filed for these things...

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

None of these things requires a dedicated app - RIPs already provide them on Mac OS X.

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

The issue we (Apple) have with DeviceRGB is that too many applications (read: almost all of them) only generate DeviceRGB, mainly because CG makes it really easy to create a DeviceRGB color but really hard to make a GenericRGB color... Since the change to map DeviceRGB to GenericRGB, the only way to get DeviceRGB with CG is to define an identity mapping - the old DeviceRGB support is gone for good.

I personally think we can provide a simpler API for application color matching that works consistently for RGB-based drivers.

________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20110512/1230b22c/attachment.htm>