| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Simple sRGB color blender test can be used to determine if the sRGB processing
works as expected. It blends alpha ramps of purple and green together such that
at midpoint of image, 50 % blend of both is realized. At that point, sRGB-aware
processing yields a result close to #bbb rather than #888, which is the linear
light blending result.
The demo also contains the sample computation for sRGB premultiplied alpha.
|
|
sRGB format is defined as a new format type, PIXMAN_TYPE_ARGB_SRGB. One form of
this type is provided, PIXMAN_a8r8g8b8_sRGB. Use of an sRGB format triggers
wide processing, and the pixel fetch/store functions handle the relevant
conversion between color spaces. Pixman itself is thought to compose in the
linearized sRGB color space.
sRGB conversion is tabularized. For sRGB to linear, we are using only 256
values because the current source format uses 8 bits per component precision.
For linear to sRGB, it turns out that only 4096 brightness levels are required
to generate all of the 256 sRGB color values, and therefore only 12 bits per
component are considered during store. As a special case, a no-op
sRGB->linear->sRGB conversion is constructed to be lossless by adjusting the
sRGB->linear conversion table where necessary.
|
|
|
|
|
|
Signed-off-by: Matt Turner <mattst88@gmail.com>
|
|
|
|
This test exercises a bug in pixman_region32_translate(). The function
clips the region to int16 coordinates SHRT_MIN/SHRT_MAX.
|
|
Generalize to catch all .pc files. Add more tests.
Signed-off-by: Guillem Jover <guillem@hadrons.org>
|
|
|
|
The complete new API here makes available compile-tim version checks:
PIXMAN_VERSION
PIXMAN_VERSION_STRING
PIXMAN_VERSION_ENCODE
as well as run-time version checks:
pixman_version()
pixman_version_string()
|
|
|
|
|
|
|
|
|
