[Openicc] GoSoC 2011: CPD and target printing

[Chris Murphy]

On May 13, 2011, at 12:03 AM, Michael Sweet wrote:

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

I'm still not understanding.

Even DeviceN DCS formatted targets are canned for all of the profiling apps I've used.

In any event the context is RGB printers because that's the color mode the driver expects to receive. Those RGB profiling targets are static targets, they aren't customized based on an initial reading of device behavior. You'd go to a folder, find the RGB testchart folder and find a bunch of prebuilt test charts with different numbers of patches supporting various measuring devices, typically as TIFF files. That's been the primary use case for years - with a handful of exceptions.

Monaco Profiler has the option to save it's static (canned) targets out as TIFF or print them from the app, as does Eye One Match, ColorMunki and now i1 Profiler. But none of them use kPMApplicationColorMatching which means a malformed print driver that announces its ICC profiling mode with a media profile, rather than as sRGB, will totally f*ck up the target. And these drivers are still occurring in the wild. Therefore it's unreliable to use any application that does not use kPMApplicationColorMatching.

ProfileMaker never had the ability to directly print.

The point is, Apple is in the vicinity of 7 years late in providing a utility and an API to disable ColorSync when needed. So I don't see how things could have been a better experience.



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

Ahh well there was UI and documentation at one time early on prior to 10.3 that implied a 3rd party CMM could be used for printing. I was told that was dropped in 10.3. We certainly had the ability to use 3rd party CMM's for printing prior to OS X.

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

I've had explicit, lengthy email conversations with those who decided on these behaviors with intent. They're not considered bugs so I never filed a bug for them.

As for black point compensation, I'm not a software developer, I have no idea with the API is for calling BPC. Developers have told me these things I've told them to file bugs, but the biggest complaint they have is the lack of documentation on how to use it correctly.



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

A RIP is a dedicated app. Are you seriously suggesting that rendering intent control and black point compensation belong on a RIP, and not in the print driver and not in Photoshop? That's a total non-starter for a meaningful conversation about sticking to Mac OS as a platform.

If, in order to  use Mac OS, we'd have to abandon application level color management, still not get the functionality we need in the print driver instead, and have to buy a RIP to print - then that directly translates into wholesale abandonment of Mac OS as a platform.

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

a.) Most applications do not use kPMApplicationColorMatching. Only two use it right now as far as I know. I'm not suggesting all applications be capable of producing /DeviceRGB in PDF print spools, just those applications that call kPMApplicationColorMatching for the express purpose of disabling ColorSync for printing profile targets and prematched image data.

b.) There is no user or application access to the pdf print spool file. It is only consumable by Quartz 2D. There is no possible ambiguity to a PDF print spool that is exactly conforming to PDF/X-3 (or X-4). You can still soft proof it on-screen. And when printed *all* objects would be exempt from ColorSync, which is the entire reason why kPMApplicationColorMatching even exists. And yet right now, today, it is possible for an application to use that SPI, and yet for some objects to be color managed by ColorSync and others not. There is ZERO use case for mixing transforms on and off per object. Exactly zero. Yet the SPI enables this possibility by design.

c.) If an application tags data Generic RGB and submits it to the OS, it's changed by the Quartz PDF Context into sRGB. So even if Generic RGB  were the correct tag, there is, only in Snow Leapard, a rewriting of history to get apps that previously used Generic RGB to use sRGB even if they don't want to. So I'd call this a pretty ugly hack.


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

Well here we are still waiting for it, with oodles of problems and it's very unclear to me who has benefited from the choices thus far. It's even unclear to me that Windows users have not had a superior experience just by virtue of their land mines all staying in the same consistent location year after year whereas on Mac OS we've endured a random mind field, not any one of them an apparent improvement over the opt-in system on Windows or Mac OS 9 and older.


Chris Murphy