[Openicc] [Printing-architecture] Colour

[Chris Murphy]

I'm not sure to which list it's best to respond. So I will reply to all and we'll see what happens.

I've considered print architecture issues quite a bit dealing with the multitude of problems we have on Mac OS with various print drivers and applications. Linux is in a unique position to learn from the mistakes made on Mac OS and Windows, and also avoid their legacy baggage as well. So I'm interesting in engaging on a discussion on these issues and perhaps come up with a model architecture that is superior to any platform. A major hinderance on Mac OS is poor documentation for developers, something which perhaps Linux can do much better on, regardless of the architectural details.

An added complexity is that printer manufacturers are most interested in default print behavior being set to proprietary driver enabled color management rather than either application or system level color management. Yet something must be done to normalize color modes and color spaces prior to such hand off as the driver itself is ignorant when it comes to the multitude of color spaces that potentially exist in a document let alone the world. Yet this default behavior is desirable from their point of view because they want to have parity in print behavior on various platforms. Again, documentation and possibly even reference implementations for them to model, is key.

I'm not particularly stuck on having really explicitly "application color management, system color management, no color management" options with a modern operating system. This is just how it is on Windows and and Mac OS. If the architecture is smart about things, the user should not even need to make such duplicative choices in the print dialog. Now, perhaps some of these things cannot be avoided, but I'd like to think if we had an early enough start to really think about an "end goal" for how a printing architecture would function, it wouldn't force the user into confronting duplicative choices. Examples:

1. Application level page setups that do not interface with operating system/driver provided page setups (i.e. paper size, margins, number of copies)
2. The selection of an ICC output device profile for a particular device condition (implying a specific media, specific printer color mode, and resolution) in the application, and yet then having to specify all of this yet again in the system/driver print dialog.


Also, consider that a big part of why Windows and Mac OS have "application color management" is due to legacy limitations of system level color management. The system and/or driver would not reliably choose the correct ICC profile for the user selected media type, color mode, and resolution. So it was decided to allow the user to manually disable the system color management, and the print driver color management, and enable application color management and manually choose an output device profile. Very tedious, and complex and prone to user error.

One way do to this instead of considering really specific UI elements, is to list things most any applications need to do, a list of things users want to do, and a list of things drivers need to do. Then once the pieces are there, plot out an architecture that can elegantly handle these requirements.

Now, maybe due to CUPS on Mac OS X already having a lot of these capabilities, it might just be easier for me to describe the basic of the OS X print architecture, and then I can point out the flaws with that system (in my opinion, obviously). And then the engineers reading this who know CUPS and Linux can consider ways they can possibly avoid those problems, rather than completely reinventing a whole new architecture.

Anyway, my point is, I don't think we need to involve the user in choosing application color vs system color vs no color management. The user is in a poor position to know what to choose. This is really up to the application correctly tagging its various objects (whether or not it has converted those objects to a different color mode/space), and then the system normalizing that data into a single color mode/space prior to handoff to the driver.

So really the color options for the driver would be:

(*) Manufacturer named default color matching method. Example: "Epson Standard (sRGB)" and possibly provide a popup menu for additional manufacturer defined color matching methods, again example: "Epson Vivid" and "Adobe RGB (1998)" which are typical of various Epson CUPS drivers on Mac OS X.

( ) System color matching. Example: "Oyranos"


That's really it. The user needs to pick between a proprietary color matching method just because that default is what the major print manufacturers tend to want. If that's not a consideration at all then no UI even required. Just normalize correctly behind the scenes (and I can go through various combinations of all of this from very simple to very complex).

And I'd definitely avoid having a No Color Management or Off option in the driver UI. That's even more confusing. An application that needs a completely raw path needs to request that path, that way it's consistently chosen correctly rather than depending on the user to do it. Plus such an application is a very special use case, and is a huge hurt me button for most users, best not directly exposed in the UI. Document the off switch that's under the hood, and have an application that explicitly asks for that behavior.

My 2 cents.



Chris Murphy
Color Remedies (TM)
New York, NY
----------------------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"


On Nov 10, 2009, at 8:32 AM, Till Kamppeter wrote:

> Cross-posting to the OpenICC and Gutenprint mailing list, to get more 
> input from the color experts.
> 
> Anyone of the color printing/management experts can help Kate?
> 
>    Till
> 
> P. S.: OpenICC mailing list info page:
> http://lists.freedesktop.org/mailman/listinfo/openicc
> 
> Gutenprint mailing list info page:
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> 
> kate price wrote:
>> 
>> I am working on the UI design of the CPD and  looking at the controls  
>> and parameters for colour, both as presets/profiles and as more  
>> detailed controls. Therefore, I'll need to get a good understanding of  
>> how this all works.
>> 
>> Including:
>> the workflow from application to printer
>> colour profiles
>> color management; in applications, and printer colour management.   
>> what happens where?
>> detailed user interaction: what controls need to be there?
>> 
>> 
>> Can someone point me in the right direction? Provide some useful  
>> information or sources of information?
>> 
>> Thanks in anticipation,
>> 
>> 
>> Kate
>> 
>>     man + machine interface works
>> _______________________________________________
>> Printing-architecture mailing list
>> Printing-architecture at lists.linux-foundation.org
>> https://lists.linux-foundation.org/mailman/listinfo/printing-architecture
>> 
> 
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc