[Openicc] Minimal X Color Management

[Chris Murphy]

It sure would be nice to sit down with a wayland/xorg developer and see if they really understand the color problem at all. In my experience, most people, including developers, simply are not aware of such differences. When explained, they're relatively unsurprised by the effect of different materials and gamuts, but when they see a web browser that contains products for sale on two different displays, then they really start to understand that this is not just a problem for "color critical"  people.

I might be wrong, but I seriously think that the problem is simply not well understood or experienced. If it were, I'd like to believe this would be better prioritized. I also don't think the industry as a whole understands how display technologies are diverging from sRGB, after a decade of converging (or attempting to converge) on it.

It may also be that I don't understand something about how much can even be done about this problem, because of unreliable EDID information. The vast majority of the market is not going to measure their displays. And the display manufacturers appear to regularly insert theoretical aimpoint primaries into EDID, rather than actual primary xy values based on some pre-manufacturing sampling...

And of course the primaries can change, in some cases not insubstantially, between batches (batches 1-10 might be reasonably consistent, but then suddenly there's a supply side change and batches 11-13 are quite different), yet EDID primary information is not updated to account for this. There's just not really an incentive for manufacturers to do this.

Since the display's color behavior isn't really well known, it can't really be well compensated for. So it's an interesting dilemma. With mobile, there are in some ways fewer excuses since an arbitrary 3rd party isn't the supplier of the display. But the time frame to production and production itself is much shorter so that can cause more problems and difficulties with keeping EDID up to date.

Chris


On Feb 17, 2012, at 5:09 AM, Kai-Uwe Behrmann wrote:

> We had recently a long discussion on the wayland IRC channel about colour management inside wayland. The standard answere is not different to that from Xorg. Colour management will not be part of the core protocol.
> In the first place a was little disappointed, but people taking the topic serious and discussed a way how to provide a extension to wayland, which can be implemented by each compositor. It is now a good time to make plans for that, as wayland is relatively young.
> 
> We have so far several strategies, each with their own set of advantages and disadvantages.
> 
> a) The desktop is one document
> approach fits to what we see on Quartz Extreme.
> + architectural and technical wise very good
> - X11 and Wayland architecture does not fit into this model, as the
> - scene graph is cut off at handing over textures or bitmaps to
>  compositing managers/wayland
> 
> b) The region based colour correction
> was implemented inside the CompICC colour server for Compiz
> + it best fits into the existing environment
> + low memory footprint
> + nice fallback to sRGB
> - some artefacts remain
> - complex and demanding to implement
> 
> c) Window based colour correction
> is a natural way how to do things in wayland, as that is the kind of object, which are seen by the wayland core protocol.
> + easy to implement in compositors
> + nice fallback to sRGB
> - toolkits need to colour correct the whole window
> +- memory footprint to this client side solution to be explored (shm)
> 
> d) Desktop based colour correction
> assumes that the whole desktop is in sRGB and colour corrected.
> + can be done on display side
> - all or nothing approach (no device colour, no calibration API)
> - does not allow for extra colours of wide gamut technology
> +- assumedly deployed on Android internal displays.
> 
> Obviously a) falls outside our possibilities. d) has too many disadvantages for desktop graphics. b) needs lot of recources. Only few window managers supports that.
> 
> Last hope in my eyes is approach c). And Pekka Paalanen created a nice scheme [1], which would be almost ready for implementation.
> There are some additional minor server side issues to be solved for implementing that scheme in X11 compositors. Namely window decorations need special care. So the good news is, we can start to implement that scheme right now and prepare today for a smooth transition towards a fully colour managed desktop. That is feasible as most wide spread window managers are already compositors with OpenGL shader support.
> 
> The X Color Management[2] spec is updated accordingly.
> 
> kind regards
> Kai-Uwe
> 
> [1] http://people.collabora.com/~pq/wayland-color-management-proposal.png
> [2] http://oyranos.org/scm?p=xcolor.git;a=blob;f=docs/X_Color_Management.txt
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc