The protocol does not carry target primaries by enumeration, but in
weston.ini I want to be able to use a name rather than raw values.
Adding this API makes that possible.
main.c cannot look up the enumeration itself, because color-properties.h
is private. As it should be.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This error gets sent to clients or into the Weston log. Print the name
rather than the meaningless number.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The target luminance range is implied when not explicitly set, so maxCLL
and maxFALL should be checked against target luminances regardless of
whether target luminances are explicit.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Make sure the given values are finite, positive, and non-zero where
appropriate.
Because these validations are not mandated in the color-management
protocol, they are not immediate failures. They will fail the final
image description creation.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Statements phrased positive are easier to understand than phrased
negative. Use "must" instead of "should".
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
The old code checked x for low limit and y for high limit, rather than
checking both for both limits. Fix this.
Check all value pairs rather than the first one four times. Don't stop
at the first error, record them all.
While at it, we might as well print exactly what value was the problem.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
At first I wanted to wrap
float tf_params[MAX_PARAMS_TF]
into a struct, so that it would become type-safe to pass into functions,
and it could be copied with a simple assignment. Then I noticed that for
tf_params to be operable, it must always be accompanied by struct
weston_color_tf_info. Hence, struct weston_color_tf was born.
The need for #define MAX_PARAMS_TF got eliminated.
Because struct weston_color_tf is a member of struct
weston_color_profile_params, now both need to not contain implicit
padding.
This patch makes the internal enumerated TF structures follow the
current protocol requests: all color channels use the same curve.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
We didn't have many Weston assert macros in place, but now we do.
Make use of a few of the newer macros where they make sense. No big
difference, but just to exercise using the correct ones now that they
exist.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Currently weston-test-assert.h has a better naming style than
weston-assert.h: more concise and standardized.
So let's copy the same style to weston-assert.h
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
First of all, we make it work for NaN CIE xy values.
We also improve the error message a bit. It was only printing that the
color gamut was invalid, but it didn't explain why. This adds the
explanation (out of valid range).
And finally, we make the code a bit shorter.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The internal API to create parametric color profiles should be available
not only to libweston, but also to frontend. WL_EXPORT was missing from
the functions, so add that.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
A counter instead of a boolean should be useful when we add code
printing the parameters. This should help us to avoid printing unused
parameters.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
If a certain feature is unsupported, return UNSUPPORTED instead of
BAD_TF, BAD_PRIMARIES, etc.
Also, up to now cm->get_color_profile_from_params() would return
UNSUPPORTED. But this is different from the other UNSUPPORTED usages, so
return a new error.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In the parametric builder API, which is used by our color management
protocol implementation, we have errors that may be translated to
protocol errors or graceful failures. As we return a single err code
to the protocol implementation, let's prioritize the protocol error.
We do that by inverting the order of checks, as the first error code
caught is the one prioritized.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This follows a recent change in the CM&HDR protocol (more specifically,
v4 of the experimental version). Now users of the API can set luminance
parameters for the primary color volume.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
The CM&HDR protocol extension spec relaxed the requirements for the
max_fall and max_cll setters. Now we accept such values even when the
transfer function is not PQ.
This also fixes an issue in which we'd not accept target_luminance
for transfer function different from PQ, which was not on the spec.
INCONSISTENT_SET is not being used in any other errors, so remove that
from enum weston_color_profile_param_builder_error.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In the experimental color-management protocol v3
(xx-color-management-v3), we had only the luminance parameters that were
defining the luminance range targeted by the image description. But in
v4 a way to specify luminance parameters for the primary color volume
has been added.
In order to avoid confusion, rename existent luminance variables to
target luminance.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This is problematic as we don't have namespacing for these and some of
the macros can interfere with other defines.
This reverts commit 8634c7e349.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
As weston_windowed_output_get_api needs ARRAY_LENGTH() move helpers to a
libweston/ so other users can re-use that instead of re-defining these
all over. Easier for other front-ends to make use of them.
With this change windowed-output-api.h also includes the helpers header.
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Add API to create color profiles from parameters. It is a public API
that should be used by the frontend and also by the color management
protocol implementation.
Currently our protocol implementation does not support clients that want
to create color profiles from parameters, and this is a step towards
supporting that.
As warned in "color: add get_color_profile_from_params() to color
managers", we still do not fully support creating color profiles from
parameters. This just creates a boilerplate color profile that we're
planning to extend later.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
