Oyranos/X11 Requirements

From ColourWiki

(Difference between revisions)
Revision as of 11:08, 14 Aug 2010
KaiUweBehrmann (Talk | contribs)
net-color spec - update to CompIcc
← Go to previous diff
Revision as of 16:33, 2 Sep 2010
KaiUweBehrmann (Talk | contribs)
References - add bug reports
Go to next diff →
Line 94: Line 94:
* [https://bugzilla.gnome.org/show_bug.cgi?id=625202 30-bit drawables remain black] (in Gtk) * [https://bugzilla.gnome.org/show_bug.cgi?id=625202 30-bit drawables remain black] (in Gtk)
 +
 +Colour Management and Toolkits
 +* ICC colour management policiy
 +** [http://www.fltk.org/str.php?L2411 FLTK feature request]
 +** [http://bugreports.qt.nokia.com/browse/QTBUG-13370 Qt feature request]
[[Oyranos|back -> Oyranos]] [[Oyranos|back -> Oyranos]]
[[Category:Oyranos]] [[Category:Oyranos]]
[[Category:Standards]] [[Category:Standards]]

Revision as of 16:33, 2 Sep 2010

Oyranos has some requirements to provide colour management related informations through it's APIs. For further reading see Monitor Configuration.

Table of contents

Architectural Overview

Applications need a way to communicate colorimetry of their image content. Applications, which like to handle colour management (CM) on their own, need additional a path to tell the system what to do with the content and what not.

Applications can follow several strategies:

  1. be dumb - The application knows nothing about CM. The system takes content as being in a default RGB colour space and does colour matching. Most applications would fall in this category.
  2. tag content - The application knows about the colorimetry of its content and tells the system about it.
  3. take over control - The application knows best how to handle its content. Tell the system to not match content with following options:
    1. Dont apply colour conversions. This is for proofing and image editing applications.
    2. Dont apply calibration from graphic card gamma tables. This is useful for HDR content.

The "take over control" kind of applications want additionally to know about the screen layout and monitor colorimetry. This is handled by Xinerama alike API's and the _ICC_PROFILE_xxx atom.

Screen Areas and Colour Space tagging

Two things are needed,

  • a ICC profile container attached to window or screen region
  • a opt out flags for colour correction down the path, so applications can handle colour management on their own
    • a "no colour conversions" flag
    • a "no calibration from graphic card gamma tables" flag
  • the virtually thierd is that every other content is expected as sRGB, as is the case today

The above would fit along all the path:

 application -> toolkit -> composite manager -> X11 -> OpenGL -> shader.

There remains to find an endpoint where most paths meet. This could be the composite manager or a additional layer between composite manager and Xorg or inside Xorg itself.

The OpenICC project Colour Management Near X (http://www.freedesktop.org/wiki/OpenIcc/ColorManagementNearX) implemented the idea. As a result the net-color spec was born to describe the basic communication. It covers and continues most of the above outlined ideas.

Multi Monitor EDID in X11

EDID information describes monitor parameters like description, serial number and gives hints about colourimetric behaviour.

Oyranos uses this information to identify a particular monitor and search for a best matching profile, as long as one is stored in the Oyranos device profile database.

You can check independently whether a EDID atom is set by calling in a X11 environment:

xprop -root | grep EDID

Specification

X servers export the EDID inormation typically in the "XFree86_DDC_EDID1_RAWDATA" and "XFree86_DDC_EDID2_RAWDATA" atom. If there are more monitors connected to the root window, the following atoms get a underscore and the monitor number appended, like in

Example

Xinerama_screen_number = 0 => XFree86_DDC_EDID1_RAWDATA

Xinerama_screen_number >= 1 => XFree86_DDC_EDID1_RAWDATA_1 + XFree86_DDC_EDID1_RAWDATA_2 ...

This way compatibility is enshured for existing applications.

Parsing

This section is incomplete. But at least the code can be found here oyranos_edid_parse.c (http://www.oyranos.org/scm?p=oyranos.git;a=tree;f=modules/devices)

The section decribes the EDID parsing in Oyranos.

Oyranos parses EDID information for monitor identification. It uses the 18 byte blocks starting from 54 for a monitor manufacturer, model and serial ID string. In case the manufacturer was omitted, it switches back to scan the 2 byte ID's starting at position 8. The later could be extended to model(10) and serial(12).

References

Versions / Implementations

Oyranos 0.1.5 obtained the oyranos-monitor-nvidia commandline tool to demonstrate the described behaviour.

ICC Profiles in X

References

Further Tasks

(Draft for a ICC Profiles in X Specification 0.4)

  • add xrandr-1.2 porperties per each physical output device

net-color spec

Version 0.2 Draft 1 (http://www.oyranos.org/scm?p=xcolor.git;a=blob;f=docs/net-color-spec;h=a8d46ab8d66a1ecf6776b26af0695d5aeefd3292;hb=master) is public. The goal is to communicate ICC colour regions between a colour server and clients.

Implementations

The implementation is available in libXcm-0.2.x (http://www.spinics.net/lists/xorg/msg50027.html).

The CompIcc ICC colour server for compiz plugin supports the draft. The plugin supports complete desktop colour correction and is multi monitor aware.

Ideas exist to support the spec in a Gnome window manager.

Miscellaneous

References

30-bit visual bugs


Colour Management and Toolkits

back -> Oyranos