[Pixman] sRGB processing for pixman

[Søren Sandmann]

"Antti S. Lankila" <alankila at bel.fi> writes:

> On 09.06.2012 14:16, Antti S. Lankila wrote:
>
>> Currently the color space processing is just a cheap integer hack
>> with gamma 2.0. It is sufficient for testing purposes, but not
>> production quality. I'm leaning towards tabularizing the official
>> sRGB-to-linear function and its inverse in a future patch.
>
> Just to avoid any future confusion, I found the time to write the
> tabularized conversion. A simple screenshot that shows sRGB (top) and
> non-sRGB (bottom) processing:
> http://bel.fi/~alankila/pixman/difference.png
>
>> http://bel.fi/~alankila/0001-Add-tentative-support-for-sRGB-surfaces.patch 
>>
>
> The URL still works, although I recommend making it
> /~alankila/pixman/0001etc. in the future.

Comments on the patch:

- I think the code that generated the tables should be included, and the
  tables generated as part of the build process.

- We can't break source level compatibility. Instead of adding a new
  field in the formats, how about simply adding

       PIXMAN_TYPE_ARGB_SRGB

  which is #defined to (PIXMAN_TYPE_ARGB | (1 << 5))? That still makes
  it possible to determine quickly whether the format is srgb encoded,
  but doesn't break source compatibility.

- expand/contract seems like the wrong place to do the conversion. It
  makes more sense to me to do it directly in pixman-access.c for the
  format in question. Conceptually, everything pixman does internally is
  with linearly encoded pixels, and so expanding the output of an 8-bit
  fetcher is not subject to gamma conversions.

  Instead, gamma conversions belong as the first thing after fetching
  and the last thing before storing. 

  That also means the 8 bit fetcher for this new format would be done by
  (a) fetching wide, gamma-converted pixels, and then (b) contracting
  them to 8 bit without gamma conversion. This loses a lot of
  information of course, but that's why the format is considered "wide".

- I'm not convinced that we need that pixman_image_get_space()
  accessor. There is already a pixman_image_get_format() that can be
  used to get the information.

- The format should be added to the test suite, at the very least the
  "composite" test.

- There are formatting issues. Please see COPYING.

But other than that, I think this is a useful feature and should
basically go in as proposed. There was some discussion on IRC regard
full color space support. While this may some day happen, I don't think
gamma corrected compositing should block on it.

(If you come up with a new patch, please just mail it to the list instead of
sending a link).



Thanks,
Søren