[Openicc] Linux CM ideology, was: meta data in test chart

[Chris Murphy]

On Jan 28, 2011, at 1:34 PM, edmund ronald wrote:

> On Fri, Jan 28, 2011 at 9:24 PM, Chris Murphy <lists at colorremedies.com> wrote:
> 
>> So yes, I think we already need this. And look at all the effort Mozilla has gone through to get Firefox color managed. I think this should be centralized. Apps should not have to do this individually. It's a service. Their role should be merely to pass through EXIF and/or ICC profiles, and the image stream, and then the system manages color appearance transforms. That's how we get it highly optimized and consistent.
>> 
>> Chris Murphy
> Maybe if we could agree exactly what a color appearance transform is,
> we could move from there. Because a simple way to deal with things
> would be to require apps to use a big space eg.  Lab, XYZ, or even
> (gasp!) ProphotoRGB and then transform from there into display space.
> But Graeme tells us this cannot be done ...

The pipeline is all RGB. So unless an engineer says differently, I'm working under the assumption at best we could have applications supplement RGB streams with an ICC or EXIF tag.

Conversion by an application into 8bpc Wide-Gamut RGB before handoff is ill advised if we want a quality conscious pipeline. And requiring apps to submit 16bpc WG-RGB, when the actual data may not even be encoded that way in the app, is also ill advised.

And also, unless an engineer tells me otherwise, I think it's an error to ask applications, even smart ones, to do their own transforms. I know this is how it's done by GIMP today, but I think we're better off optimizing display compensation centrally, and not asking applications to do this on their own because what they have to do will be different depending on the hardware they're on. I wouldn't require applications to be aware of what the current display profile is, or where the window is presently located, or whether and what intermediate space they need to convert to.

For 8bpc Display RGB does not make a good compositing space for professionals. In some instances it's not even good enough for consumers with good hardware. For mobile and netbooks, fine use 8bpc Display RGB. But as soon as that OS is on something with a capable GPU, the compositing should be done in a floating point space and then the primaries don't even matter because you can define points outside that gamut boundary. You can allow sRGB and ProPhoto RGB and eciRGB, all inside of this compositing space handled by the window manager, an once compositing is done (flattened), then it converts pixels from floating point to Display RGB in the highest practical bitdepth supported by the hardware/drivers and cable to the display.

If you yank that display and put on another, the window manager should become aware of the new transform needed. Not every application. *shrug* Just my two cents. If it works some other way, I shouldn't care, just as long as it works. 

But it seems centralization is a lot less complicate to make it work correctly, fast, and consistently. Reinventing the display compensation wheel for every application seems very heavy weight for application developers and both platforms have already gone down that road and we can see where things are. Very inconsistent, especially on Windows which manages nothing.

Ideally we want all applications to not opt-out, right? So it needs to be made easy to do that. If I drag and drop an eciRGB JPEG from the desktop to my email application, of course the JPEG should look correct. If I drop it into OpenOffice for a presentation, of course it should look correct. If I put it into the simplest application, it should look correct.

An application that drops the ICC profile or EXIF data in an image (or any object), and instead assuming the object to be sRGB is data loss. And the sooner we treat this as a form of data corruption/loss, and ways to make it EASY for developers to do the right thing, I think the better path we're going to be on for the long haul.


Chris Murphy