On 2019-03-04 12:27, Pekka Paalanen wrote:
On Mon, 4 Mar 2019 19:04:11 +1100
Graeme Gill <grae...@argyllcms.com> wrote:
Pekka Paalanen wrote:
> My failing is that I haven't read about what ICC v4 definition actually
> describes, does it characterise content or a device, or is it more
> about defining a transformation from something to something without
> saying what something is.
The ICC format encompasses several related forms. The one
that is pertinent to this discussion is ICC device profiles.
At a minimum an ICC device profile characterizes a devices color
response by encoding a model of device values (i.e. RGB value
combinations)
to device independent color values (i.e. values related to device
independent CIE XYZ, called Profile Connection Space values in ICC
terms). A simple model such as color primary values, white point
and per channel responses is easily invertible to allow transformation
both directions.
For less additive devices there are more general models (cLut -
multi-dimensional color Lookup Table), and they are non-trivial
to invert, so a profile contains both forward tables (device -> PCS
AKA A2B tables) and reverse tables (PCS -> device AKA B2A tables).
Then there is intents. The most basic is Absolute Colorimetric
and Relative Colorimetric. The former relates the measured
values, while the latter one assumes that the observer is adapted
to the white point of the devices. Typically the difference is assumed
to be a simple chromatic adaptation transform that can be encoded
as the absolute white point or a 3x3 matrix. The default intent
is Relative Colorimetric because this is the transform of least
surprise.
cLUT based profiles allow for two additional intents,
Perceptual where out of gamut colors are mapped to be within
gamut while retaining proportionality, and Saturation where
colors are expanded if possible to maximize colorfulness. These
two intents allow the profile creator considerable latitude in
how they achieve these aims, and they can only be encoded using
a cLUT model.
Hi Graeme,
thank you for taking the time to explain this, much appreciated.
I'm still wondering, if an application uses an ICC profile for the
content it provides and defines an intent with it, should a compositor
apply that intent when converting from application color space to the
blending color space in the compositor?
I think the correct approach would be to first convert from
application color space to the output color space using the intent and
then to blending color space. That way all colors in the blending
color space will fit in the output color space.
Should the same application provided intent be used when converting the
composition result of the window to the output color space?
When all blending color sources are in the output color space so is
the resulting color. No intent required.
What would be a reasonable way to do those conversions, using which
intents?
So in summary an ICC profile provides device characterization, as well
as facilitating fast and efficient transformation between different
devices, as well as a choice of intent handling that cannot typically
be computed on the fly. Naturally to do a device to device space
transform
you need two device profiles, one for the source space and one
for the destination.
Do I understand correctly that an ICC profile can provide separate
(A2B and B2A) cLUT for each intent?
That's my understanding as well.
> What is the use for a device link profile?
Device link profile use was a suggestion to overcome the previously
stated
impossibility of a client knowing which output a surface was mapped
to.
Since this no longer appears to be impossible (due to
wl_surface.enter/leave events
being available), device link profiles should be dropped from the
extension.
It is sufficient that a client can do its own color transformation
to the primary output if it chooses, while leaving the compositor to
perform
a fallback color transform for any portion that is mapped to a
secondary output,
or for any client that is color management unaware, or does not wish
to
implement its own color transforms.
This greatly reduces the implementation burden on the compositor.
Btw. wl_surface.enter/leave is not unambigous, because they may
indicate multiple outputs simultaneously. I did talk with you about
adding an event to define the one output the app should be optimizing
for, but so far neither protocol proposal has that.
Niels, Sebastian, would you consider such event?
My proposal has the zwp_color_space_feedback_v1 interface which is
trying to solve this issue by listing the color spaces a surface was
converted to in order of importance.
Thanks,
pq
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
