[Openicc] Re: Hello *and* (was): LINUX, Gutenprint / CUPS / Color policies

[Chris Murphy]

First, thanks Hal for taking the time to write out that overview. That 
was quite helpful.

On May 12, 2005, at 5:33 PM, Hal V Engel wrote:
> At
> this point I don't think that we have a clear understanding of what 
> needs to
> be done.  In fact I don't think we have a clearly documented set of 
> user
> requirements which is the first thing that a systems analyst tries to 
> nail
> down in the process of designing a system.

There are a number of ways to implement a color management system. The 
devil, as they say, is in the details. Most of my gripes with Windows 
and Mac OS CMS is not in the overall architecture, or the theory in how 
it ought to work, but rather the details of UI, UE and how it actually 
does work (or does not).

> Chris you are now sitting in front of a clean sheet of paper - How do 
> you want
> an ideal CMM system to work?

To get to a point where users have to do and think about it as little 
as possible. When things "just work" is when you know you're doing 
something right. What non-experts want tomorrow is what the experts 
have today. Maybe it's possible to overbuild a CMS, but I suspect that 
there are development limitations that will inherently prevent that 
from happening.

>  What does an ideal CMM workflow look like and
> what data elements are needed to support that workflow?

Unambiguous device data is an obscenity. :) Untagged RGB is ambiguous 
and everything that can be done to purge it from the planet is a good 
thing. Untagged CMYK on the other hand has its place, and will take 
more discussion, especially when it comes to more high-end applications 
such as printing to a press where things like 100%K only text is 
required. Even though four-color black text could still be 
colorimetrically the same (and is a frequent result of color 
management), it's a disaster on press. I'll table that for further 
discussion, or until someone else brings it up again.

Anyway, I want this stuff to be as simple as possible.

>   What things would
> you like to see that would allow you to setup a CM workflow for 
> non-expert
> users or users with no CM training at all?

The less the user has to think and do things, the better. Automatic 
generation of a display profile using DDC is already important now, and 
as next generation displays come onto the market, it will be necessary. 
Even if it's not based on custom measurement data, it's better than 
nothing. Eventually I expect technology to get to a point where devices 
profile themselves, including printers and digital cameras.

The CMS should do a better job of associating profiles with particular 
devices, so that users don't have to keep doing this all the time when 
they want to print, or scan something. In a networked environment this 
becomes particularly important. If the network laser printer has a 
profile that gets updated, it would be great if the CMS could push the 
updated profile for that printer to all workstations. It would be even 
better if this was done "on demand". If I want to print to a color 
laser printer in New York, when my system makes the initial connection, 
it should ask if I want my local driver/PPD and ICC profile for that 
printer updated - and then used automatically from that point forward 
when printing to that printer.

>   What are the roles that exist in
> a CM workflow and what is needed to support those roles?  Is there an
> administrative role of some sort?  If so what is needed to support 
> that role?
> These are just some of the questions that need to be answered.

Possibly. I can imagine company wide settings for applications, that 
define certain behavior (boolean type policies) in certain instances, 
or default profiles to use, etc. And it would be great if those 
settings for applications could be locked so that clueless end-users 
can't change them. There would need to be exceptions to this rule, for 
a "local admin", such as the art director for a group of designers, or 
their remote color management consultant. Having these settings locked 
by a system admin, especially in a corporate IT department, would be a 
PITA.

> We should be trying to nail down what the high level user
> requirements are.   After we understand that we can start looking at 
> the
> implementation details.

Even thought this is an open icc list, and I am an advocate of ICC 
workflows, I freely discuss the limitations of the ICC formats. It 
inherently prescribes a certain path for workflow that isn't 
necessarily the easiest to implement: previous examples would be the 
need for multiple destination profiles for a single output condition in 
order to account for different amounts of GCR. Likewise we need 
different output device profiles for different lighting conditions. 
This to me is wholly absurd. Is there a way to use ICC profiles and 
package them in such a way that this is not a burden on the users? I'd 
like to see that. All users would like that, not just the high level 
ones. I'm also not opposed to color management that is not ICC-based. 
Clearly it's a good idea to support ICC profiles also, but nothing says 
this group can't create something better, along with ICC support.



Chris Murphy
Color Remedies (TM)
www.colorremedies.com/realworldcolor
---------------------------------------------------------
Co-author "Real World Color Management, 2nd Ed"
Published by PeachPit Press (ISBN 0-321-26722-2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 5518 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/openicc/attachments/20050512/f07c00b3/attachment.bin