The primaries and the white point are the fundamental definition of the
color spaces in these tests. Instead of hard-coding mat2XYZ, use
LittleCMS to derive the result from the fundamental definition.
This removes derived hard-coded constants, which is a benefit in itself.
How these constants were originally produced was not mentioned in
0c5860fafb but I was able to reproduce
them with python3:
import colour
import numpy as np
x = colour.RGB_COLOURSPACES['sRGB']
w_d50 = np.array([0.34567, 0.35850])
print(x.chromatically_adapt(w_d50, 'D50', 'Bradford'))
It's identical to 3-4 decimals of the hardcoded values, and also for
Adobe RGB. I printed the LittleCMS generated values as well, and they
are the same as with python up to roughly 4 decimals.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
On commit "color: add support to parametric curves in
weston_color_curve" we've added support for some parametric curves in
Weston. This helped us to be more precise in some cases in which we'd
have to fallback to LUT's otherwise.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Until now, all the curves would be represented with 3x1D LUT's. Now we
support LINPOW and POWLIN curves (arbitrary names that we've picked).
We can use these curves to represent LittleCMS curves type 1, 4 and
their inverses -1, -4. The reason why we want that is because we gain
precision using the parametric curves (compared to the LUT's);
Surprisingly we had to increase the tolerance of the sRGB->adobeRGB MAT
test. Our analysis is that the inverse EOTF power-law curve with
exponent 1.0 / 2.2 amplifies errors more than the LUT, specially for
input (optical) values closer to zero.
That makes sense, because this curve is more sensible to input values
closer to zero (i.e. little input variation results in lots of output
variation). And this model makes sense, as humans are more capable of
perceiving changes of light intensity in the dark.
But the downside of all that is that for input values closer to zero, a
little bit of noise increases significantly the error.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
When we don't have cmsGetToneCurveSegment() at disposal, we are not able
to inspect the LittleCMS color curves and convert them to Weston's
internal representation of color curves. In such case, we need to
fallback to a more generic solution (using LUT's).
For now we always fallback to the LUT's, but in the next commits we'll
add support to inspect the curves and convert them to the internal
representations that we'll add.
This will allow us to tweak the tolerance in the color-icc-output tests.
But if we continue running these tests for systems without
cmsGetToneCurveSegment() at disposal, they may fail.
We already have a LittleCMS version in the CI that has
cmsGetToneCurveSegment(). So skip color-icc-output when we don't have
this function.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The test suite is throttled by the headless backend repaint
timer. This commit uses the headless refresh rate option to speed up
runtime by using the immediate repaint-only-on-capture mode by
default. Tests which don't support that mode yet override the refresh
value to use the highest rate possible.
Fixes#682
Signed-off-by: Loïc Molinari <loic.molinari@collabora.com>
Start to use the helpers introduced in "tests: add helpers to create
unique filenames".
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Pekka: Dropped program name from output_filename_for_test_case() calls
as it is already added automatically.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We'll need to craft ICC profiles in the CM&HDR protocol implementation
tests. So move it from color-icc-output-test.c to the LittleCMS helper
in our test suite.
This also removes some unused headers from color-icc-output-test.c, as
we've moved a bunch of code to the LittleCMS helper.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
There are some ICC profiles that contain something named VCGT tag. These
are usually power curves (y = x ^ exp) that were loaded in the video
card when the ICC profile was created. So the compositor should mimic
that in order to use the profile.
Weston already has support for that, but our ICC profile tests were
missing this case. This adds such tests.
For testing purposes, we have added tests with different exponents per
color channel.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Without that we may crash when trying to create a PTYPE_CLUT ICC profile
with dimension zeroed. This would be wrong, so with this change we are
basically validating the test case arguments.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
For now we have some tests with the same name. Differentiate them based
on the ICC profile type that they build: CLUT vs matrix shaper.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Now that we have color profile, transformation and optimizer debug
scopes, make use them in this test.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In preparation of having multiple outputs available we should be able to
specify by its name. We just use the default one if none was set-up at all.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Now that enum weston_renderer_type is public, there is no need for a
local enum renderer_type in the tests.
Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com>
Here are more tests for output decorations drawing, this time through
the color-lcms plugin. This is the only practical way to exercise the
input-to-output category of color transformations.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Only the 'image' field of struct buffer is ever used here, so just
pass pixman_image_t instead of struct buffer.
This allows a future test to mangle a screenshot (e.g. convert pixel
format) before feeding it in.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Not a functional change. The replacement of const
dump file to use suffix of appropriate sub tests
(sRGB->sRGB, sRGB->adobeRGB, etc).
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
This is adding basically a copy of alpha-blending-test.c. The difference
is that here we use ICC files to set up the output color profile, and
then test light-linear blending only. BLOCK_WIDTH is set to 1 to fit
inside the output size used by the fixture setup, which is smaller than
in the original, but does not change the results.
The test is aimed at testing how color-lcms module succeeds in
linearizing the output of different ICC output profiles. Incorrect
linearization should cause changes in blending results.
The tolerance is taken from the currently achieved error statistics
(1.40908) and rounded up a little to achieve a suitable margin.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Switch from per-channel max error tolerance to max two-norm (Euclidean
distance) error. Geometrically this means that previously the accepted
volume was a +/- tolerance cube around the reference point, and now it
is a sphere with tolerance radius.
The real benefit is simplifying the code.
The error tolerance are also changed to float. Integers cannot represent
values between 1 and 2, and the jump from 1 to 2 would have been too
much. AdobeRGB tolerance gets relaxed a bit, while BT2020 tolerance
becomes stricter. The new tolerance values are the reported achieved
two-norm max errors plus a bit of margin.
Surprisingly the sRGB case tolerances remain strictly at zero, and
that's no bug in the test.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
compare_float() was an ad hoc max error logger with optional debug
logging.
Now that we have rgb_diff_stat, we can get the same statistics and more
with less code. It looks like we would lose the pixel index x, but that
can be recovered from the dump file line number.
This patch takes care to keep the test condition exactly the same as it
was before. The statistics print-out has more details now.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The recently introduced rgb_diff_stat value dumping feature logs the
"position" where the value or error was measured. The reference value
was used as the position, but the problem with the reference value is
that it is an output value and not an input value. Therefore mapping
that back to which input values promoted the error is not easy.
Fix that problem by passing the position explicitly into
rgb_diff_stat_update(), just like it is already passed in to
scalar_stat_update().
Currently the only user simply passes the reference value as position,
because there the input value is also the reference value. This is not
true for future uses of rgb_diff_stat.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Seems it will be common to print all four min/max/avg sets of errors, so
move the printing code into a shared place.
While 0.0-1.0 is the natural range for color values, people are often
accustomed to working with 8-bit or even 10-bit pixel values. An error
of +/- 1 in 8-bit is more intuitive than +/- 0.004 in floating-point.
Hence 'scaling_bits' is added so the caller can determine the value
scaling. This will scale both the reported error numbers, and the
recorded error positions (rgb-tuples), so they are all comparable.
I'm happy to get rid of those two macros as well.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Move the struct image_header and get_image_prop() into a header where we
can share these useful helpers between more test code. While doing that,
drop the unused field 'depth', rename into image_header_from(), and
introduce a helper to get u32 pointer to the beginning of a row. These
helpers should make pixel iterating code easier to read and safer (less
room for mistakes in address computations, and asserts).
Use the shared 'struct image_header' instead of the local one. The
intention is to make the code easier to read by using the same helpers
everywhere.
Width, height and stride use type 'int' because Pixman API uses that
too.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Move gen_ramp_rgb() down in the file where the TEST() specific code
begins. This way we first have a big block of fixture setup code which
creates an ICC profile, and the next big block is the actual test client
code. gen_ramp_rgb() belongs with the latter.
This makes the file structure slightly more logical.
This is a pure code move, no changes at all.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This name describes better what this test does. In the future another
TEST() for alpha blending will be added. Both of them will be using
matrix-shaper and cLUT output profiles.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The new name better matches the contents of the test.
Currently the test creates output ICC profiles with matrix-shaper and
cLUT forms, and tests that basic color conversion from input to output
color space is correct.
The common theme in this test program is to create ICC profiles to be
used as output profiles. In the future this can include more kinds of
testing, e.g. linear blending. OTOH, this test program will always be
limited to SDR because HDR testing probably will not use ICC files.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Pekka Paalanen