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

[Roy Harrington]

On Sat, Nov 14, 2009 at 9:08 PM, Michael Sweet <msweet at apple.com> wrote:
> On Nov 14, 2009, at 5:15 PM, Roy Harrington wrote:
>>> I humbly suggest that what you want is a utility that allows the user to print targets and generate/install ICC profiles for a > > particular combination of printer, media, and other settings. If you have to select a profile at print time, then the printing > > workflow is broken.
>>>
>>> ___________________________________________________
>>> Michael Sweet, Senior Printing System Engineer
>>
>> While a separate utility might be a useful thing, I think you are
>> missing the point of view of the higher
>> end people printing.  Most have Photoshop and print from Photoshop.
>> Most use various different papers,
>> not just printer manufacturer supplied papers.
>
> I think you are missing my point - if you are profiling for your own media and ink, then those profiles and corresponding media settings should be savable so that the *only* thing you do in the print dialog is choose that custom media/ink combination and *not* choose the media, ink, and profile separately.  Why complicate the user interface with profile controls that are only useful when you have created a custom profile, something that will require a separate program and UI in order to print the target, read it, and generate the profile in the first place?!?
>
> In short, why make the user select everything every time and clutter the UI with unnecessary information?
>

I agree that a lot of this cluttered with too many options.  But all
the major high end applications have
a preview page -- this includes Photoshop, Lightroom and even Apple's
Aperture.   Its the one and only
place where you can see the image layout, potentially a soft-proof,
the print profile, and the rendering intent.

Neither the Color Matching PDE nor the Epson driver's PDE provide this
"all on one screen" view of what
the user wants to happen.   At least the Photoshop preview screen
provides place to document what a
user should do.

This is mainly a philosophy issue to answer:  "how should this all
work? "   There may be other (possibly
better) ways to design the workflow, but I think the long history of
how it has been done should be
weighted very high.


>>   So if you want to use
>> various papers and the Epson
>> driver you need to download ICC profiles from somewhere or create your
>> own custom ones.
>> When you print you've got to be able to select which profile will be
>> used -- during the printing process.
>> From a user point of view the natural thing is to do this in Photoshop
>> -- its right there in the Print Preview
>> screen.  If you are doing soft-proofing you must do it in Photoshop.
>> Creating custom ICC profiles
>> is the other major difficulty -- this used to work just perfectly.
>> Why break the existing workflows?
>
> Why not when they are already broken?

I don't think it was broken.  I'm OK with evolving new ideas, better
ways.  But lets
get the new things working and satisfying all the needs before breaking
the old way.

>
>> The OS centric point of view that the OS will handle it means you have
>> to go into ColorSync Utility
>> and try to find out how to associate a custom ICC profile with a
>> device.   There's no straightforward
>> way to do this.
>
> I'm not arguing that Linux duplicate Apple's current ColorSync user experience - that much is clearly broken since users and vendors regularly have so many problems.
>
> I'm similarly not advocating a continuation of the current "application color management" experience because that is similarly broken for anyone but a professional, and even then individual driver and application issues make it problematic.
>
> Instead, I'm suggesting that a different user experience be employed: when printing, the user sees no color controls. Color profiles are auto-selected based on the print settings - users can install new profiles, media types, and ink sets separately as needed. These profiles can be "canned" profiles the user downloads from somewhere or custom profiles the user creates using profiling software.
>
> Applications that need to do their own color management (hopefully few and far between) can specify so using an API, which disables color management and profile selection so that the color data the application provides is treated as device color all the way through to the printer.
>
>> ...
>> I've asked quite explicitly via ADC what is the protocol to print with No Color
>> Management and Application Color Management but haven't gotten answers.
>> I was able to crawl through header files and find the AP_ColorMatchingMode
>> flag but there is no documentation.
>
> Whom did you talk to at ADC?
>
>> ...
>> I've used the bug report system.  See bug 6503221 that I submitted in Jan 2009.
>> After quite a few emails back and forth, all seemed to agree that there was a
>> problem.  "Apple and Adobe are working on it" is all since then.  It just
>> sits as an open issue.
>
> Keep in mind that when there is a problem that requires coordination between multiple vendors, a solution inevitably takes longer.
>
>> Simple question:  As an "Apple Senior Printing System Engineer" can you find out
>> how the No Color Management should work?
>
> Within Mac OS X, the only way to disable color management is to associate the device profile with the colors you draw with - this doesn't actually disable color management but *does* short-circuit it.
>
> However, that is only 1/2 of the equation - you also need to tell the driver to go into "application color matching mode", and pray that the driver actually implements it properly.  This is the kPMColorMatchingModeKey (AP_ColorMatchingMode) setting, which is described in the PMPrintSettingsKeys.h header along with the supported values: kPMVendorColorMatching or kPMApplicationColorMatching. If not set, ColorSync is used.

This is the basic info that I was able to get.  If there was a
document and example that showed this
it would be easier to argue whether this works or not.   My particular
interests are primarily B&W printing
and the grayscale color models.   That probably puts me in a minority
but grayscale is supported in Photoshop,
ICC profiles, CUPS, and print drivers so it ought to be able to work.

My take on how (1) above should work is you get the default device
profile (CMGetDeviceDefaultProfileID)
and assign this to your data.  What about when the default profile and
the data are mis-matched -- one
grayscale and one RGB?   It seems like this is doomed to fail.

(2) is easy to set in an application -- it would be nice if it were
documented.  If this overrided the
above (1) this could be the master "no color management" switch that
people want.

-----------

Changing hats for a moment to my print driver role:   I've been told
several times that there are
"new requirements for print driver implementations"  but I've never
been able to get any specs on this
either.  I've read all the CUPS docs -- APSupportsCustomColorMatching
and cupsICCProfile -- but
it's counter-intuitive (at least to me) to need to add
color-management issues to the driver in order
to disable color-management there.

Roy

>
>> Thanks,
>> Roy Harrington
>>
>> ps:  I do a third party print driver for Epson printers and various
>> ICC profiling for this.
>> I'm familiar with the printing system from the driver point of view as
>> well as from
>> application point of view.
>
>
> Prior to joining Apple, I wrote and sold commercial printer drivers and RIPs for 13 years, and did printer software for 6 years before that "just for fun".  My company was a member of the ICC...
>
> ___________________________________________________
> Michael Sweet, Senior Printing System Engineer
>
>
>
>