[Openicc] CUPS Color Management under Linux... (what is to do ?)

[Chris Murphy]

Anyone have Fedora 14 running on a machine? Check out the five network related GUI options:

Network Authorization
Network Connections
Network Proxy
Network
Network Device Control

And if you read the documentation many are referred to by a different name, like Network is referred to as Network Manager even though you won't find Network Manager in the GUI at all. It's called Network.

The clusterF*ck that is terminology and consistency when it comes to something like networking, is exactly what will happen to color management if everyone has different preferences and this stuff diverges from common ground. Most users find these kinds of fiefdoms irritating as hell. I certainly find it annoying to have to spend hours figuring out how something as basic as networking is supposed to work. And while networking can certainly be complex, it doesn't have to be in five different panels, each with multiple tabs, some of which don't appear to do anything, others which overlap and seemingly contradict, on and on.

We've had this already with Mac OS in a smaller version. Remember the ColorSync control panel, and then the first few ColorSync Utility attempts? You could set default color spaces for RGB, CMYK, etc. 99% of applications ignored the panel. The panel didn't make this clear. People thought it did something and didn't realize that applications had to explicitly be written to honor the settings in the panel, that they weren't really system level settings. So the settings were considered useless/unreliable and now they're gone (finally, thank you Apple).

So if there will be fiefdoms, and the lords won't cede or compromise any of the domain in favor of logical, coherent behaviors and interfaces, then open color management will be a clusterF*ck worse than anything Microsoft or Apple have ever come up with. It won't just be different among distributions. It will be a visual, irrational mess on the same distribution. That's a prediction, hopefully I'm wrong.

Chris


On Feb 18, 2011, at 3:29 AM, Kai-Uwe Behrmann wrote:

> Am 11.02.11, 15:39 -0700 schrieb Chris Murphy:
>> On Feb 11, 2011, at 6:39 AM, Leonard Rosenthol wrote:
>>> On Fri, Feb 11, 2011 at 2:05 AM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
>>> Yes, in that order. Any following PDF processor can add a new OutputIntent but can not replace a existing OutputIntent. Only one OutputIntent is allowed per PDF, according to the PDF spec.
>>> 
>>> 
>>> Actually, PDF supports an array of OutputIntents - but no one has ever used more than one.
>> 
>> Could come in handy to enable proofing at a system level. But still guys, I think we need to keep this implementation constrained and realistic, not overly complicated. There's enough going on as it is, and still some pretty basic considerations need to be agreed upon. Basic considerations about system architecture, library dependencies, databases, etc., that I know nothing about.
> 
> The best we can do, is to adhere to the PDF spec and discuss eventual cirumventions of shortcommings in that spec. The single OutputIntent allows us to provide a pass through mode for calibration and early colour binding, e.g. for simulation/proofing.
> 
> I think its realistic not to assume that the first release will support already the OutputIntent. But we really want it once the vendor profiles come in effect through pdftoraster. Its needed for a relyable opt out and PDF spec compliance.
> 
>> I think it's fine to think about a 1.0, 2.0 and 3.0 version so that your 1.0 implementation doesn't box you into an impossible rewrite when it comes to 2.0 and 3.0. But really, unlike many things, there is an "end in sight" for color management implementation. But the biggest impediment is getting agreement about components. If everyone starts making their own implementation, then it will be yet another fractured color management system that won't work very well except with very specific distributions. I don't think that's very interesting. I think fixing the problems most people have is interesting.
> 
> Code sharing was rejeted. I am especially sorry about that. But preferences differ, so we have to live with that. I think adhering to existing specifications and creating new recommendations if interoperatibility is needed is the way to go. These recommendations should be as simple as possible to support at least a flexible and extensible core of functionality.
> 
> 
> kind regards
> Kai-Uwe Behrmann
> -- 
> developing for colour management www.behrmann.name + www.oyranos.org
> 
> PS: greetings to Edmund
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc