Stop assuming that NULL represents the stock sRGB color profile. From
now on, query the stock sRGB color profile from the color manager.
This should be internal to libweston (core and the color plugins), and
users of the libweston public API should not be affected by this. They
are still allowed to set an output color profile to the stock sRGB using
NULL.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
cmlcms_get_hdr_meta() returns early if the output has a color profile
set. That makes sense, because we should be able to get the color
characteristics from the color profiles.
But in the next commits, every output will have a color profile set. To
allow the color-metadata-parsing test, do not return early when
output->color_profile != NULL in cmlcms_get_hdr_meta() anymore.
In the future we'll adjust this function in order to always extract the
color characteristics from color profiles, as output->color_profile
should always be set.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
In the next commit we'll stop using NULL as the stock sRGB color
profile, so add a function to the color manager to allow libweston core
to have access to the stock sRGB profile.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Directly destroying the cprof is not ideal, because it may hide issues
that we have in the code. If we are destroying a cprof with ref_count
bigger than 1, there's something wrong that we need to fix.
Instead, assert that the stock sRGB cprof has ref_count == 1 when we are
destroying the color manager. And use unref() instead of destroy().
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
There are some cases in which we are seeing segment breaks like this in
the debug scopes: (0.00, 0.00]. A segment whose domain goes from 0 to 0
makes no sense.
This happens because we are printing the breaks with only two decimal
places. Increase that to four, in order to have more accurate
information in the debug scopes.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
There's a case we were missing when printing the tone curves: the ones
with zero segments.
These are 16-bit sampled curves. Start taking them into account.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
This will help us to debug our color pipeline optimizer without the
need to craft special ICC profiles for that. In this initial patch,
we are able to add matrices and curve sets to the pipeline and assure
that the optimizer is doing the right thing.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
At the moment, when we merge two curve sets it becomes a sampled one.
With this change, we start merging power-law curve sets and keeping them
as parametric, as we'd rather have a parametric curve than a sampled
one.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
At the moment, when we merge curves we transform them into sampled
curves, even if they were parametric before.
If we have two inverse parametric curve sets in sequence in the color
pipeline, we can drop them both, as merging them would result in the
identity curve. If we don't do that and merge the resulting identity
with another curve set, we'll end up with a sampled curve.
Start dropping inverse curve sets in sequence. This change help us in
the following scenarios:
pipeline:
curve set A, curve set B (inverse of A), curve set C (parametric)
Merging A and B results in identity, and merging that with C results in
a sampled curve. With our changes, we end up with curve set C intact,
and we'd rather end up with a parametric curve than with a sampled one.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Move code that depend on cmsGetToneCurveSegment() to a new file:
color-curve-segments.c
This help us to eliminate #if HAVE_CMS_GET_TONE_CURVE_SEGMENT scattered
around color-transform.c, making the code clearer and helping to avoid
mistakes.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
We were printing only the matrices (cmsSigMatrixElemType) up to now.
Start printing the curve sets (cmsSigCurveSetElemType) as well.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Function matrix_print() is called only by pipeline_print(), which
already checks if the log scope is enabled. So remove the repeated
check from matrix_print().
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
Whenever a color transformation is being created, this debug scope
prints its pipeline before and after being optimized. It should be used
with the color-lcms-transformations scope.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
It prints the existent color profiles for new subscribers. Also prints
any creation/destruction of color profiles.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
It prints the existent color transformations for new subscribers. Also
prints any creation/destruction of color transformations.
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
We have a string describing the ICC profile. cmsGetProfileVersion()
returns a float value, and we are converting that to string with "%f"
and saving to this description. Instead, use "%.1f" to restrict it to a
single decimal value, which is enough. With this change we have e.g.
"version 4.4" instead of "version 4.4000000".
Signed-off-by: Leandro Ribeiro <leandro.ribeiro@collabora.com>
LCMS API cmsStageAllocToneCurves uses cmsDupToneCurve which internally
re-allocates a new table of points. As a result, we have to free the old
table returned from lcmsJoinToneCurve.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
This patch adds the essential LittleCMS color pipeline optimizations and
analysis that is necessary for extracting matrices from pipelines
correctly. When we can extract a matrix and 1D curve sets, we can use
those with GL-renderer without needing an inherently heavy and imprecise
3D LUT. This should improve color transformation precision and
performance when a 3D LUT is not necessary.
The core of the optimization and analysis is a custom plugin for
LittleCMS. The optimization step comprises of repeatedly merging
sequential matrices and sequential curve sets into one and eliminating
identity elements which may allow for more merging. The analysis step
takes the optimized LittleCMS pipeline and attempts to fit all of its
elements into the weston_color_transform model. If it fits, we have an
optimized color transformation and do not need a 3D LUT. If it does not
fit, we use a 3D LUT as before.
Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Restructing cmlcms_color_transform_create for readibility.
Also dropped zalloc() check in favor of xzalloc() as per the recent
Weston development policy.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Right now this function only creates a CMM pipeline and produces a 3D
LUT from it, but in the future it can produce other types of
transformations. The function is renamed to xform_realize_chain()
because it creates a chain of profiles, forms a multi-profile-transform
from them, and fits that into weston_color_transform.
The further refactoring supports the future changes, and attempts to
make the code more readable.
There is provision for easily adding more profiles into the chain.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Relax the types of color transformations categories where this function
can be used. Yes, it is only useful for BLEND_TO_OUTPUT, but that is for
the user of this function to take care of. This function always works as
named regardless. The only condition is that output_inv_eotf_vcgt has
been populated, so fill_in_curves() may as well assert that.
While at it, make the code a little more concise. The 'len' assertion
belongs in fill_in_curves() because that is where the problem would
appear if the assertion failed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Rename cmslcms_fill_in_pre_curve to cmlcms_fill_in_output_inv_eotf_vcgt
due to importance what the function is fetching:
profile->output_inv_eotf_vcgt.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Eotf is the transfer function whose inverse must be used for
converting from output light-linear space to sink electrical space.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
It's bad form to set the same variable in multiple places, and not all
of them were even equivalent.
Move lcms2 finding to the root level build file only. It is still an
optional dependency like before, and the if-not-found checks are still
in place where actually needed.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This is the beginnings of creating composited content HDR metadata for
the ST2084 HDR mode. The immediate goal is to allow essentially setting
the HDR metadata from weston.ini, so that it can be experimented with.
Setting an output ICC profile will stop weston.ini metadata from taking
effect, but using an ICC profile in HDR mode is an open question anyway.
maxDML, maxCLL, and minDML are set based on the assumption that we want
to make use of the full sink/monitor dynamic range.
This also adds several TODOs about how we should handle output profiles,
basic output color characteristics, and HDR metadata. Implementing these
properly will take more thought and effort.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This adds hdr_meta field in weston_output_color_outcome. This field is
intended to be set by color manager modules, and read by backends which
will send the information to the video sink in SMPTE ST 2084 mode a.k.a
Perceptual Quantizer HDR system.
Such metadata is essential in ST 2084 mode for the video sink to produce
a good picture.
The validation of the data and the group split is based on the HDR
Static Metata Type 1 definition in CTA-861-G specification.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
To me, the use of setup_search_param() makes the code harder to
understand than it needs to be. Replacing that function with open-coding
the struct cmlcms_color_transform_search_param initialization makes it
more clear that:
- get_surface_color_transform is the only one that actually uses a
surface to initialize it
- get_blend_to_output does not use an input profile at all
- get_sRGB_to_output and get_sRGB_to_blend hardcode the sRGB profile
like they should
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
I am going to need to add yet another output property to be set by a
color manager: HDR Static Metadata Type 1. With the old color manager
API design, I would have needed to add the fourth function pointer to be
called always in the same group as the previous three. This seemed more
convoluted than it needs to be.
Therefore collapse the three existing function pointers in the API into
just one that is resposible for setting up all three things.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
A reminder that this variable needs to be taken into account when
crafting color transformations.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Fix a typo. No CM functional change, just redirect LCMS error
into created cmsContext which output into weston log.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Use 3D LUT for color mapping.
For category CMLCMS_CATEGORY_INPUT_TO_BLEND use transform which has
3 profiles: input, output and light linearizing transfer function.
For category CMLCMS_CATEGORY_INPUT_TO_OUTPUT use input and output profiles +VCGT.
For category CMLCMS_CATEGORY_BLEND_TO_OUTPUT use output inverse EOTF + VCGT.
Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Graeme sketched a linearization method there:
https://lists.freedesktop.org/archives/wayland-devel/2019-March/040171.html
Sebastian prototyped there:
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14/commits
Thanks to Pekka for great simplifications in implementation, like the xyz_dot_prod()
Quote: "should help untangle lots of the multiplications and summations by saying
we are computing dot products, etc".
The approach was validated using matrix-shaper and cLUT type of profiles.
If profile is matrix-shaper type then an optimization is applied.
The extracted EOTF is inverted and concatenated with VCGT, if it is availible.
Introduce function cmlcms_reasonable_1D_points which would be shared between
linearization method and number of points in 1DLUT for the transform.
Co-authored-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Add to search parameter cmlcms_category, input and output profiles,
and render intent for output which would be used for both profiles.
Add common function setup_search_param for every category.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
The stock profile would be used when client or output
do not provide any profile or unaware of color management.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
1. The cmlcms_category is used to identify the purpose of transform:
- CMLCMS_CATEGORY_INPUT_TO_BLEND
- CMLCMS_CATEGORY_BLEND_TO_OUTPUT
- CMLCMS_CATEGORY_INPUT_TO_OUTPUT
2. Added following fields to cmlcms_color_profile:
- output_eotf - If the profile does support being an output profile and it
is used as an output then this field represents a light linearizing
transfer function and it can not be null. The field is null only if
the profile is not usable as an output profile. The field is set when
cmlcms_color_profile is created.
- vcgt - VCGT tag cached from output profile, it could be null if not exist
- output_inv_eotf_vcgt - if the profile does support being an output profile and it
is used as an output then this field represents a concatenation of inverse
EOTF + VCGT, if the tag exists and it can not be null.
3. Added field cmsHTRANSFORM to cmlcms_color_transform.
It is used to store LCMS optimized pipeline.
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Add API to set an output's color profile. This new function can also be
called while the output is enabled. This allows changing the output
color profile even at runtime if desired.
color-noop has no way of creating weston_color_profile objects, so it
just asserts that no color profile is set.
color-lcms does not yet implement taking the output color profile into
account, so for now it just fails everything if a profile is set.
weston_surface_color_transform_fini() was previously used only prior to
freeing the struct, but now it is used also to just clear the struct,
hence it needs to reset the fields.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Roughly speaking, a color profile describes the color space of content
or an output. Under the hood, the description includes one or more ways
to map colors between the profile space and some standard profile
connecting space (PCS).
This object is not called a color space. A color space has a unique
definition, while a color profile may contain multiple different
mappings depending on render intent. Some of these mappings may be
subjective, with an artistic touch.
When a source color profile and a destination color profile are combined
under a specific render intent, they produce a color transformation.
Color transformations are already preresented by weston_color_transform.
This patch adds the basic API for color profile objects. Everything
worthwhile of these objects is implemented in the color managers:
color-noop never creates these, and in color-lcms they are basically a
container for cmsHPROFILE, the Little CMS object for color profiles.
Color profile objects will not be interpreted outside of the color
managers, unlike color transformations.
For a start, the color manager API has one function to create color
profiles: from ICC profile data. More creation functions for other
sources will be added later.
The API has errmsg return parameter for error messages. These are not
simply weston_log()'d, because CM&HDR protocol will allow clients to
trigger errors and the protocol handles that gracefully. Therefore
instead of flooding the compositor logs, the error messages will
probably need to be relayed back to clients.
Color-lcms is expected to create a cmsHPROFILE for all kinds of color
profiles, not just for those created from ICC profile data. Hence,
color-lcms will fingerprint color profiles by the MD5 hash which Little
CMS computes for us. The fingerprint is used for de-duplication: instead
of creating copies, reference existing color profiles.
This code is very much based on Sebastian Wick's earlier work on Weston
color management, but structured and named differently.
Co-authored-by: Sebastian Wick <sebastian@sebastianwick.net>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
Initialize LittleCMS and use it to generate the sRGB EOTF and inverse
curves. Use these curves to define the blending color space as optical
(linear) sRGB by assuming that both content and output color spaces are
sRGB.
As a consequence, this causes Weston to do "gamma correct blending", as
in, blend in light linear space which should avoid distorting colors in
alpha gradients, when color-lcms is active.
This makes use of the 3x1D LUT support added in gl-renderer earlier, and
shows how the color manager is responsible for re-using existing color
transformation objects.
Co-authored-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
This creates the color-lcms plugin that in the future will be using
Little CMS as the color matching module, processing ICC profiles, and
producing HDR tone mappings.
Right now, this new plugin is functionally equivalent to the no-op color
manager, except it already links to lcms2 and checks that the renderer
supports color operations.
Color-lcms is a libweston plugin that is loaded with explicit
weston_compositor API. This does not currently allow loading alternative
color manager plugins. External color manager plugins might be
considered in the future when the libweston APIs around color management
stabilize.
This libweston plugin uses the same build option as the old cms-static
Weston plugins, as they both need lcms2. The minimum version for lcms2
was chosen by what Debian Buster provides today and for no other reason.
This plugin intends to support the Wayland CM&HDR protocol extension and
hence sets supports_client_protocol to true. This will expose the
protocol extension to clients when it gets implemented.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
