[PATCH 2/6] Attach input profiles and build corresponding LUTs

[Kai-Uwe Behrmann]

Am 27.11.2014 um 15:58 schrieb Niels Ole Salscheider:
>>>>>  #define WL_HIDE_DEPRECATED
>>>>>  #include <wayland-server.h>
>>>>>
>>>>> @@ -40,6 +41,10 @@ extern "C" {
>>>>>
>>>>>  #include "config-parser.h"
>>>>>  #include "zalloc.h"
>>>>>
>>>>> +#ifdef HAVE_LCMS
>>>>> +#include <lcms2.h>
>>>>> +#endif
>>>>> +
>>>>>
>>>>>  #ifndef MIN
>>>>>  #define MIN(x,y) (((x) < (y)) ? (x) : (y))
>>>>>  #endif
>>>>>
>>>>> @@ -179,6 +184,24 @@ enum weston_mode_switch_op {
>>>>>
>>>>>  	WESTON_MODE_SWITCH_RESTORE_NATIVE
>>>>>  
>>>>>  };
>>>>>
>>>>> +struct weston_clut {
>>>>> +	unsigned points;
>>>>> +	char *data;
>>>>> +};
>>>>> +
>>>>> +struct weston_colorspace {
>>>>> +#ifdef HAVE_LCMS
>>>>> +	cmsHPROFILE lcms_handle;
>>>>> +#endif
>>>>> +	struct weston_clut clut;
>>>>> +
>>>>> +	int destroyable;
>>>>> +	int refcount;
>>>>> +	int input;
>>>>> +
>>>>> +	struct weston_compositor *compositor;
>>>>> +};
>> Note, that compositor.h is a public, installed header. You cannot use
>> HAVE_LCMS, because any external project using this header would then
>> receive the definition based on its own configuration, not how the
>> Weston that is already installed was configured.

Agreed, lcms internals are not nice to get exposed at this level.


Generally speaking, lcms provides a great API for a CMM. On the other
side, lcms is just one CMM and people in the open source world decided
many times to define and implement different API's. E.g. ArgyllCMS
(features, speed), SampleICC (spec playground) and Mozilla/Chrome with
qcms (secuirity, speed). So it is not wise to stick to especially one
CMM, be it lcms or whatever.

A CMM module can register its own functions for their handle type. You
could either wrap the CMM functions or use initial dummy functions
instead for function pointers. The type of the handle is not really
needed to get exposed. As long as the CMM registers its API at startup,
that procedure is simple.

A different approach is to store the data blob of the profile. The lcms
expanded profile handle needs certainly more memory, than the plain
memory block. And loading the profile on the fly is really fast. You
need the CMM profile handle mostly in the weston_build_clut() function
and for the header ID computation in other places. So profile memory
blob and profile header ID would suffice?

Then following might work out for the later approach:

+struct weston_colorspace {
+
+	void * profile_data;
+       int profile_data_size;
+       unsigned char profile_id[16];
+
+	struct weston_clut clut;
+
+	int destroyable;
+	int refcount;
+	int input;
+
+	struct weston_compositor *compositor;
+};


This opens the path to exchange the CMM without much fuzz on start time
depending on the system requirements.

Thanks
Kai-Uwe