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 weston_color_transform.

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 and have turned the experimental color management option on.

Cc @vitalyp

libweston/renderer-gl/fragment.glsl

@@ -53,6 +53,7 @@ precision mediump float;
  * snippet.
  */
 compile_const int c_variant = DEF_VARIANT;
+compile_const bool c_input_is_premult = DEF_INPUT_IS_PREMULT;
 compile_const bool c_green_tint = DEF_GREEN_TINT;
 
 vec4
@@ -79,7 +80,6 @@ yuva2rgba(vec4 yuva)
 	color_out.g = Y - 0.39176229 * su - 0.81296764 * sv;
 	color_out.b = Y + 2.01723214 * su;
 
-	color_out.rgb *= yuva.w;
 	color_out.a = yuva.w;
 
 	return color_out;
@@ -141,16 +141,31 @@ sample_input_texture()
 	return yuva2rgba(yuva);
 }
 
+vec4
+pipeline_premult(vec4 color, compile_const bool input_is_premult)
+{
+	/* Ensure premultiplied alpha, apply view alpha (opacity) */
+	if (input_is_premult) {
+		color *= alpha;
+	} else {
+		color.a *= alpha;
+		color.rgb *= color.a;
+	}
+
+	return color;
+}
+
 void
 main()
 {
 	vec4 color;
 
-	/* Electrical (non-linear) RGBA values, pre-multiplied */
+	/* Electrical (non-linear) RGBA values, may be premult or not */
 	color = sample_input_texture();
 
-	/* View alpha (opacity) */
-	color *= alpha;
+	color = pipeline_premult(color, c_input_is_premult);
+
+	/* color is guaranteed premult here */
 
 	if (c_green_tint)
 		color = vec4(0.0, 0.3, 0.0, 0.2) + color * 0.8;