Hello Graeme Gill
I read many comments on this topic including yours, and I agree with you
about some points in particular about the calibration and profiling
procedure, but I very puzzled by your position about some points. It's
look like you hate display managers[1] because they are not able to
produce accurate color from a given specification/definition/encoding.
I would like to point out that colorspace with pixel values is just an
encoding for the color you would like produce on the monitor. That mean
the compositor is capable to perform the translation to the monitor
accurately as good as the given client application. He can do it even
better because he has the hardware under-control and may have a wider
community to support this feature.
I think you should drop the idea that the compositor cannot do something
better than a specific application, by definition the compositor is an
application.
Some comment about the reality you describe are following inline.
On 21/12/2016 01:08, Graeme Gill wrote:
Richard Hughes wrote:
On 20 December 2016 at 07:22, Graeme Gill <grae...@argyllcms.com> wrote:
Or be prepared to re-visit Wayland's fundamental design decisions
if they turn out to be based on a false premise.
I don't think that's fair. I think Wayland is the opportunity to upset
the status quo with color management and do correctly what what never
possible with X11.
I think it is fair - a lot of push back is along the lines of
"that's impossible - Wayland doesn't work that way", which
if taken to a logical conclusion, (maybe) implies that Wayland is
incapable of sporting color management.
Assumption: "Applications are oblivious to the output their
pixels are rendered to"
Reality: An application needs to know the output it's pixels
land on if it is to present them in the correct output specific
colorspace.
I disagree, an application need to know what they want show then they
need a way to tell the compositor what they want. An application that
want have a pixel in 40 cd.m-2 of red with wavelength 750 nm, must know
how to tell that to compositor, it may be 240,2,4 RGB in the color space
sRGB (totally random conversion). But once the encoding is agreed the
compositor can do the same as any color-managed-aware software. In other
hand I can agree that a client may want to know monitor capability to
adapt their display, for example if the display isn't wide-gamut I just
fallback to a normal gamut rendering, because rendering wide gamut is a
waste of effort.
In any case please drop this reality. And help to define how the client
should tell to the compositor which color he want to show, and what is
useful to know for an application.
Assumption: "The compositor is able to do all the transformations
necessary to render applications pixels to the output device"
Reality: It may not be practical for a compositor to have the
color conversion machinery capable of doing the transformations
in the manner and to the precision that an application requires.
This reality is correct because you used 'MAY' but just assume the
compositor can do all the transformations necessary to render
applications pixels to the output device as good as any
color-managed-aware software, even better because he will have a broader
community. And also think that kind of transformation can probably be
included in a library, which all compositors will be able to reuse. A
little bit like libinput is currently used by a lot of compositor out-there.
Assumption: "Graphical system API's can be divided into
application operational API's, and Management API's.
Wayland need only cover the former".
Reality: Some graphical functions are both operational
for one type of application, and management for other types
of applications.
I do not understand this assumption, and obviously the related reality.
Assumption: "All management functions can be incorporated in
the compositor"
Reality: Some management functions require full blown applications,
and can't practically be incorporated in each compositor,
nor tailored to each compositor.
So if the realities challenge the assumptions, then
either clever means need to be invented to get things
to work within the assumptions, or the assumptions need
to be softened. Saying "it's impossible" doesn't progress
things, nor help bring Wayland up to having the capabilities
of other existing systems.
[ The above of course is, as best I grasp it from preceding
conversations. ]
I agree with you, because I understand the context but out of context
the assumption "All management functions can be incorporated in the
compositor" is valid, nothing forbid any software to be included within
a compositor, if you want a compositor with Tetris inside, it's up to
you. That say I will explain why I agree with you: because I agree that
it would be nice to split the software that find the calibration value
and build profile from the compositor, and I think we should find a
privileged protocol to enable this design. In other hand I don't think
that the configuration must be allowed to separate software. i.e. the
privileged software has granted privilege for the calibration and the
profiling, once they are done, he produce configuration files that
should be feed to compositor by his 'specific' configuration system.
Lets be honest for a moment. How many applications support color
management on the Linux desktop? We're asking application authors to
understand things like blending spaces, source and destination
profiles, vcgt, overlapping windows on different crtc's and horrible
concepts like that.
Agreed. Easier to access, and default color management framework
is desirable (and for that reason was included in my sketch). But
this shouldn't be at the expense of applications that need more
than that, nor at the expense of color management applications
needed to set things up so that all this can work in the first place.
As a framework guy, _and_ an app developer I just want to tag one
surface with a colorspace and then let the compositor figure out all
the grotty details.
And you should be able to. But what about applications that need
far more than that ? (Ordinary CMM's of the type that are likely
to be practical in a compositor, lack a lot of capabilities
that some applications will need).
Anything more and the application author will just
decide it's not worth the bother. To calibrate we just ask for a
surface that's not going to be tampered with, but we don't want to
optimize for this super-uncommon case.
I disagree - leave it to be an afterthought, and it will be
done badly or left out completely, crippling the practicality
of color management for the system.
Graeme Gill.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Another thing that seems misleading you and the wayland community is
that you use 'standard' protocol, when you use this words in the wayland
mailing-list it's read as wayland 'standard' protocol, in other world a
standard that wayland community is responsible of. But an other path
exists, you can build your own 'standard' protocol (understant wayland
extension, like xrandr is an extension of X11 protocol), maintain it and
lobby the compositor developers to implement it. This how the xdg-shell
or wayland-wall are managed.
Before closing my email, I would like that we separate discussion of how
regular client share color data with the compositor and the topic about
how a software can perform calibration and profiling, even if I agree
that both are needed to have color-managed-monitors, both topic are
mostly orthogonal, imo.
my suggestion of title: "Enable color managed clients" and "Enable color
calibration and profiling"
I hope this e-mail is constructive and will help for further discussions.
Best Regards
[1] a generic name that include X11/Wayland or any others of that kind.
--
Benoit (blocage) Gschwind
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
