X Color Management 0.4 DRAFT1

Some days ago on FOSDEM I gave a presentation about Colour Management in Compositors. At that point is was not very clear how to introduce colour management especially into the upcoming Wayland display server core and thus make it wide spread. The answer from Wayland developers is the same as from Xorg ones. They want a small core and colour management does not fit inside this.

As a result of a discussion between several colour management interested people from wayland, toolkits and me on the wayland IRC channel, we found a smallest common denominator. That will be a per window colour correction mechanism. The advantage is, it will be very easy to implement inside compositors and they can even start today about ICC support. The biggest disadvantage for applications is, they need to colour correct the whole window. That is as well the reason, why I did not like the idea in the past. Anyway, hopefully toolkits will jump in at one point and make that easy. Meanwhile we need to focus on example code, which demonstrates how per window colour correction can work.

The spec can be found as usual in the libXcm git repository. The main new part is the _ICC_COLOR_OUTPUTS atom and XcolorOutput structure.

*

6 thoughts on “X Color Management 0.4 DRAFT1

  1. That sounds like a really bad idea. What happens when a window covers more than one screen? What happens when I work with duplicate monitors?
    IMHO the only sane place for color correction is the system compositor.

    • Correct, that’s why the spec highly recommends to support client side profiles. With that a application can convert to a intermediate blending space and let the compositor care about the conversion to each output.

      The according _ICC_COLOR_PROFILES atom is in the spec since version 0.3 and will be supported in the next CompICC colour server release.

      • > With that a application can convert to a intermediate blending space and let the compositor care about the conversion to each output.

        I wonder again if we should allow that intermediate blending space to be a device independent space like L*a*b*.
        Otherwise we would end up with something like “Input Image –(input icc profile)–> Lab –(blending space profile)–> Representation in intermediate blending space –> pass to compositor –(blending space profile)–> Lab –(output device profile)–> Output image” that is less efficient.

        • Ah, you are referring with CIE*Lab to the ICC Profile Connection Space (PCS). The CMM will create one transform object from all profiles and options. So we would end with following two conversions:
          –(input icc profile)–> Representation in intermediate blending space | pass to compositor –(intermediate space profile)–> Output image (monitor device profile)
          I assume here the compositor will colour convert all content prior to it’s own blending to the monitor colour space.

  2. Pingback: X Color Management 0.4 DRAFT1 | Oyranos « Management Fair

Comments are closed.