Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Sat, 14 Jan 2017 11:52:25 +0100 Kai-Uwe  said:

> Am 14.01.2017 um 03:24 schrieb Carsten Haitzler (The Rasterman):
> > On Fri, 13 Jan 2017 18:08:51 +0200 Pekka Paalanen 
> > said:
> >> Oh, ok, that's why. We could as easily have the compositor show the
> >> color swatch only on a part of the output and leave the rest of the
> >> area for normal use.
> >>
> >> However, if that is done with a special protocol so that the compositor
> >> actually knows this is the profiling color swatch, it can make sure
> >> other windows cannot interfere. It could be like the color swatch was
> >> on an always-on-top overlay. You cannot do that any other way from a
> >> Wayland client.
> >>
> >> And if unform color for the swatch is all you need, the protocol could
> >> simply take 3 numbers for the color instead of an image buffer. Then
> >> people would not get the urge to abuse this interface for e.g.
> >> application splash screens.
> > 
> > i kind of like the idea of a special protocol with 32bit ints per rgb etc.
> > to say "display this exact uncalibrated color as-is without luts or
> > anything else in the way"... but apply it to a separate toplevel
> > window/surface (and put your guided ui controls in another window) or...
> > use a subsurface.
> 
> +1 for subsurface. The compositor can even take over responsibility to
> move the belonging window to the desired output, for the case the
> underlying application can not manage or handle that itself (e.g. for
> mirrored outputs).

indeed as it knows the parent surface etc. and thus can "do the right thing"
without the calibration app needing to know or care at all.

in the end a calibrator really just needs to present some data (unmolested by
gamma luts/color correction/blending etc.) onto a display so some colorimiter
device dangling on the screen can read it and feed back what it sees. using
this dat produce a set of calibration data a compositor (or an app) canuse
later that would be applicable to that monitor.

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[The Rasterman]

On Sat, 14 Jan 2017 10:32:43 +0100 Benoit Gschwind  said:

> Hello Pekka,
> 
> Your idea is mostly correct, but I have few comment. Some element of 
> context: on my side I do not do photo editing at all but I calibrate and 
> profile my monitor often to get a similar visual experience from a 
> computer to another.
> 
> On 13/01/2017 17:03, Pekka Paalanen wrote:
> > On Fri, 13 Jan 2017 15:56:50 +0100
> > Florian Höch  wrote:
> >
> >> [ Bunch of replies to different posts crammed into one, apologies in
> >> advance. ]
> >>
> >> Pekka Paalanen wrote:
> >>> Would it not be simpler to just say "I'm doing calibration now, make
> >>> sure nothing interferes"?
> >>
> >> Sure, I just hope that "I'm doing calibration now, make sure nothing
> >> interferes" still allows conventional application UI (e.g. using UI
> >> frameworks like Gtk3, Qt etc) to be visible, because otherwise it would
> >> effectively block users from interacting with said UI (going by your
> >> comment "I also forgot to mention that surfaces with the
> >> cms_calibration_surface role, when actually presented, would also
> >> guarantee that nothing else will be shown on that specific output"
> >> somehow sounds like it would not, but maybe I'm misunderstanding what
> >> you mean by "output". I would certainly not be enthused if I had to
> >> low-level re-implement parts of the UI I currently have - in fact I can
> >> tell you right now that it would never, ever happen if it's not as
> >> simple as writing for any of the common UI frameworks).
> >
> > Hi,
> >
> > my idea for a user story would be something like this:
> >
> > - user starts a calibration app and clicks "profile output HDMI 2"
> >
> > - optional: the compositor shows a dialog: "Application Foo wants to
> >   profile output HDMI 2. Allow / Deny ? You can press Esc to abort
> >   profiling after it starts."
> 
> optional but recommended, this avoid the abuse of the protocol for 
> splash screen. This dialog should also grant the access to change to the 
> hardware settings (VideoLUT and other things)

not sure the app should directly change the lut ... but should provide the
calibration data it gathered and let the compositor figure out how to program
the lut to do the correcting. compositor could now store that data in any wayit
likes for future re-use (next time it starts auto apply this correction as long
as that monitor is attached to that output etc.)

> >
> > - The output HDMI 2 gets filled with the profiling pattern according
> >   the application requests, and literally nothing else will show up on
> >   that output.
> >
> 
> As explained in another e-mail[1] the user may want to use unused space 
> to do something else, I do it often because: (1) calibrating take quite 
> a long time, (2) my requirement are not very high in term of accuracy 
> and (3) the software that perform the calibration may want to show some 
> calibration/profiling progress and/or feedback or (4) the software that 
> perform the calibration may want show GUI button to pause/resume the 
> calibration.
> 
> Another random remark is that, as far as I understand, the calibration 
> process may affect all monitors, depending on hardware because they may 
> expose only one VideoLUT shared for all outputs.

this is why i think the video lut should be hidden from client view entirely as
above. :)

> > - If the user wants to abort the profiling run before it completes, he
> >   presses Esc, which the compositor grabs and restores HDMI 2 to normal.
> >
> > - If the profiling finishes by itself, HDMI 2 is restored to normal
> >   automatically.
> >
> > - The profiling application will know what happened in all cases.
> >
> > How's that sound? I'm running blind here, because I've never used a
> > profiling app.
> >
> 
> You are mostly correct in the approach, imo.
> 
> > Would you really need the user to interact with the UI while the
> > profiling pattern is shown?
> >
> > If you show any UI bits on the profiled output, how do you avoid the UI
> > affecting the profiling results? Keep in mind the window positioning
> > limitations in Wayland desktop.
> >
> > Other outputs should remain normal during profiling, but of course
> > there might be only one output connected.
> >
> >> Put bluntly, but I agree as well. A "calibration/profiling/measurement"
> >> application is not more of a "special-purpose client" than, say, a CAD
> >> application, a code editor, or an application that lets you create 3D
> >> scenes of rotating bunnies wrapped around bunnies (scnr), ... etc.
> >
> > Graeme just managed to explain to me why the profiling app needs access
> > to the VideoLUT (see [1]) which is a global resource. That makes the
> > profiling app a very special case on Wayland, because on Wayland we
> > very very carefully avoid unconditional access to such global
> > resources, so that apps cannot take the user or the desktop hostage or
> > mess it up even if they tried 

Re: [RFC wayland-protocols] Color management protocol

[Kai-Uwe]

Am 14.01.2017 um 03:24 schrieb Carsten Haitzler (The Rasterman):
> On Fri, 13 Jan 2017 18:08:51 +0200 Pekka Paalanen  said:
>> Oh, ok, that's why. We could as easily have the compositor show the
>> color swatch only on a part of the output and leave the rest of the
>> area for normal use.
>>
>> However, if that is done with a special protocol so that the compositor
>> actually knows this is the profiling color swatch, it can make sure
>> other windows cannot interfere. It could be like the color swatch was
>> on an always-on-top overlay. You cannot do that any other way from a
>> Wayland client.
>>
>> And if unform color for the swatch is all you need, the protocol could
>> simply take 3 numbers for the color instead of an image buffer. Then
>> people would not get the urge to abuse this interface for e.g.
>> application splash screens.
> 
> i kind of like the idea of a special protocol with 32bit ints per rgb etc. to
> say "display this exact uncalibrated color as-is without luts or anything else
> in the way"... but apply it to a separate toplevel window/surface (and put 
> your
> guided ui controls in another window) or... use a subsurface.

+1 for subsurface. The compositor can even take over responsibility to
move the belonging window to the desired output, for the case the
underlying application can not manage or handle that itself (e.g. for
mirrored outputs).
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC wayland-protocols] Color management protocol

[Benoit Gschwind]

Hello Pekka,

Your idea is mostly correct, but I have few comment. Some element of 
context: on my side I do not do photo editing at all but I calibrate and 
profile my monitor often to get a similar visual experience from a 
computer to another.


On 13/01/2017 17:03, Pekka Paalanen wrote:

On Fri, 13 Jan 2017 15:56:50 +0100
Florian Höch  wrote:


[ Bunch of replies to different posts crammed into one, apologies in
advance. ]

Pekka Paalanen wrote:

Would it not be simpler to just say "I'm doing calibration now, make
sure nothing interferes"?


Sure, I just hope that "I'm doing calibration now, make sure nothing
interferes" still allows conventional application UI (e.g. using UI
frameworks like Gtk3, Qt etc) to be visible, because otherwise it would
effectively block users from interacting with said UI (going by your
comment "I also forgot to mention that surfaces with the
cms_calibration_surface role, when actually presented, would also
guarantee that nothing else will be shown on that specific output"
somehow sounds like it would not, but maybe I'm misunderstanding what
you mean by "output". I would certainly not be enthused if I had to
low-level re-implement parts of the UI I currently have - in fact I can
tell you right now that it would never, ever happen if it's not as
simple as writing for any of the common UI frameworks).


Hi,

my idea for a user story would be something like this:

- user starts a calibration app and clicks "profile output HDMI 2"

- optional: the compositor shows a dialog: "Application Foo wants to
  profile output HDMI 2. Allow / Deny ? You can press Esc to abort
  profiling after it starts."


optional but recommended, this avoid the abuse of the protocol for 
splash screen. This dialog should also grant the access to change to the 
hardware settings (VideoLUT and other things)




- The output HDMI 2 gets filled with the profiling pattern according
  the application requests, and literally nothing else will show up on
  that output.



As explained in another e-mail[1] the user may want to use unused space 
to do something else, I do it often because: (1) calibrating take quite 
a long time, (2) my requirement are not very high in term of accuracy 
and (3) the software that perform the calibration may want to show some 
calibration/profiling progress and/or feedback or (4) the software that 
perform the calibration may want show GUI button to pause/resume the 
calibration.


Another random remark is that, as far as I understand, the calibration 
process may affect all monitors, depending on hardware because they may 
expose only one VideoLUT shared for all outputs.



- If the user wants to abort the profiling run before it completes, he
  presses Esc, which the compositor grabs and restores HDMI 2 to normal.

- If the profiling finishes by itself, HDMI 2 is restored to normal
  automatically.

- The profiling application will know what happened in all cases.

How's that sound? I'm running blind here, because I've never used a
profiling app.



You are mostly correct in the approach, imo.


Would you really need the user to interact with the UI while the
profiling pattern is shown?

If you show any UI bits on the profiled output, how do you avoid the UI
affecting the profiling results? Keep in mind the window positioning
limitations in Wayland desktop.

Other outputs should remain normal during profiling, but of course
there might be only one output connected.


Put bluntly, but I agree as well. A "calibration/profiling/measurement"
application is not more of a "special-purpose client" than, say, a CAD
application, a code editor, or an application that lets you create 3D
scenes of rotating bunnies wrapped around bunnies (scnr), ... etc.


Graeme just managed to explain to me why the profiling app needs access
to the VideoLUT (see [1]) which is a global resource. That makes the
profiling app a very special case on Wayland, because on Wayland we
very very carefully avoid unconditional access to such global
resources, so that apps cannot take the user or the desktop hostage or
mess it up even if they tried to(*). Changing the VideoLUT will mess up
all other windows on that output, and the profiling app will not even
tolerate any other windows on that output at the same time.

Any application you listed does not require similar access to a global
resource. A profiling app OTOH cannot use the normal content delivery
paths because as Graeme explained they often do not reach the full
precision without changing the VideoLUT.

Another example of where Wayland denies access to global resources is
that an application cannot make an input grab at will. Input grabs are
always conditional, and breakable. We should have similar behaviour
also with "screen grabs" like these.

[1] 
https://lists.freedesktop.org/archives/wayland-devel/2017-January/032616.html

(*) The classic example of messing up the user's desktop is games
changing the X server video mode,