Draft: Color management architecture: color profiles
This MR depends on !596 (merged).
Roughly speaking, a color profile describes the color space of content or an output. Under the hood, the description includes one or more ways to map colors between the profile space and some standard profile connecting space (PCS).
This object is not called a color space. A color space has a unique definition, while a color profile may contain multiple different mappings depending on render intent. Some of these mappings may be subjective, with an artistic touch.
When a source color profile and a destination color profile are combined under a specific render intent, they produce a color transformation. Color transformations are already presented by
This MR adds the basic API for color profile objects. Everything worthwhile of these objects is implemented in the color managers: color-noop never creates these, and in color-lcms they are basically a container for
cmsHPROFILE, the Little CMS object for color profiles. Color profile objects will not be interpreted outside of the color managers, unlike color transformations.
For a start, the color manager API has one function to create color profiles: from ICC profile data. More creation functions for other sources will be added later. ICC profiles have various types which raises
enum weston_color_profile_kind. Output profiles have different requirements from content profiles.
To exercise the the API, if color management is enabled, Weston will now recognize
icc_profile key in an
[output] section in
weston.ini for DRM, headless, wayland, and x11 backends.
This code is very much based on @swick's earlier work on Weston color management, but structured and named differently.
This MR is a draft until it has been tested with color-lcms actually using an output color profile. The color-lcms implementation may be added to this MR or it may come as another MR on top of this.
Without the color-lcms implementation, Weston will refuse to start if you specify an output color profile.