ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
yrlf has quit [Quit: Ping timeout (120 seconds)]
yrlf has joined #wayland
yrlf has quit [Read error: Connection reset by peer]
yrlf has joined #wayland
ryanneph_ has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
garnacho has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
mahkoh has quit [Ping timeout: 480 seconds]
mahkoh has joined #wayland
nniro has joined #wayland
feaneron has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
tiffanylarsson has joined #wayland
gallo has quit [Ping timeout: 480 seconds]
gallo has joined #wayland
vincejv has quit [Ping timeout: 480 seconds]
tiffanylarsson has quit [Remote host closed the connection]
blueberrysnake7 has joined #wayland
blueberrysnake has quit [Ping timeout: 480 seconds]
vincejv has joined #wayland
coldfeet has joined #wayland
sima has joined #wayland
kts has joined #wayland
alarumbe has quit []
tzimmermann has joined #wayland
kts has quit [Quit: Konversation terminated!]
tzimmermann has quit []
tzimmermann has joined #wayland
glennk has joined #wayland
glennk has quit [Remote host closed the connection]
<mahkoh>
Do weston, mutter, kwin support direct scanout of non-opaque buffers?
olivial has quit [Read error: Connection reset by peer]
olivial has joined #wayland
glennk has joined #wayland
rasterman has joined #wayland
diego has joined #wayland
dviola has quit [Read error: Connection reset by peer]
diego2 has joined #wayland
diego has quit [Read error: Connection reset by peer]
AJ_Z0 has quit [Ping timeout: 480 seconds]
nniro_ has joined #wayland
nniro has quit [Ping timeout: 480 seconds]
garnacho has joined #wayland
vincejv has quit []
<pq>
zamundaaa[m], yes, I totally expect that ICC-absolute and relative rendering intents make no difference for a matrix-shaper style ICC profile. It's how ICC works.
<pq>
zamundaaa[m], I don't think we should second-guess the ICC workflow. It is what it is. It specifically relies on people *crafting* ICC profiles to suit their needs.
<JEEB>
yea :/
<pq>
The rendering intent just chooses between different transformations in both source and destination ICC profiles, and if any profile lacks a transformation for a specific rendering intent, the ICC spec says what to fall back to.
<pq>
Shaper-matrix (TRC-matrix) ICC profiles simply have only one transformation recorded, so there are no options.
vincejv has joined #wayland
<MrCooper>
mahkoh: mutter can, if it's either a fullscreen window (which are defined to have solid black background) or the opaque region covers it
<mahkoh>
I think this is only correct if the blend space is the output color space. Otherwise composting and direct scanout will produce different results. For example, if you blend in linear space, the composites result would be brighter in places where alpha < 1.
blueberrysnake7 has quit []
blueberrysnake7 has joined #wayland
<mahkoh>
It's another argument for blending in 2.2 space. But I don't know how often you want to direct scanout buffers with alpha.
<MrCooper>
mutter currently does direct scanout only if the surface color state matches the output's
blueberrysnake7 has quit []
<mahkoh>
As you say, but that is not sufficient. You also have to blend in that space if you want composting and DS to look identical.
blueberrysnake has joined #wayland
<MrCooper>
good point
<pq>
mahkoh, I think Weston does support direct scanout of non-opaque buffers, and it also supports KMS plane alpha (whole surface opacity).
<mahkoh>
Eg if you blend in linear, the composited result will be multiplied by a per-pixel factor of alpha^(-0.5454)
<MrCooper>
then again, the protocol currently doesn't define at all how blending works
<MrCooper>
making it inconsistent between compositing and direct scanout is still bad though
<mahkoh>
MrCooper: yes but it would be jarring if you switch between DS and compositing
<mahkoh>
I wonder how many vulkan applications say that they use premul alpha but then never actually have any translucency. Not being able to DS them would be annoying.
<pq>
Weston also maintains the same blending between GL and KMS. It won't off-load blending to KMS unless it cana off-load the blend-to-output color transformation first. Or at least should, and when color management is enabled.
<pq>
I'm not sure if there are unused opportunities, like DS of a fullscreen window that claims to have a non-opaque alpha channel while the alpha channel would make no difference.
<pq>
The alpha channel would make no difference because of the fullscreen state which mandates a (black) background.
<mahkoh>
It does make a difference if you don't blend in electrical space.
<mahkoh>
Unless you mean transparent black.
<pq>
opaque black, and I don't see how it would make a difference.
<MrCooper>
pq: blending non-opaque pixels on black gives different results depending on the blending color state
<pq>
the source color is already pre-mult, and adding (a weighted) zero won't change the value.
<pq>
the zero is still zero, be it optical or electrical
mvlad has joined #wayland
<MrCooper>
correct blending involves un-premultiplying, transforming to the blend color state, premultiplying again
<pq>
or that's my assumption
<pq>
MrCooper, yes, but just to add a zero, and then undoing all that again.
<mahkoh>
The problem is that after blending your alpha channel is 1 everywhere.
<mahkoh>
So you can divide by the alpha before applying the inv_eotf
<MrCooper>
pq: the premultiplication gives different results depending on color state
<pq>
yes, our displays tend to be opaque
<pq>
MrCooper, yes, but they get cancelled when converting back to the output space.
<MrCooper>
can't be, per mahkoh
<pq>
then I'm not following
<pq>
hmm, you're right
<pq>
the chosen blending space defines the "strength" of the effect that alpha has
<MrCooper>
yep
mahkoh has quit [Read error: Connection reset by peer]
mahkoh has joined #wayland
mripard has joined #wayland
coldfeet has quit [Remote host closed the connection]
coldfeet has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
<zamundaaa[m]>
<pq> "zamundaaa, yes, I totally expect..." <- Not just shaper matrix, all v2 profiles.
<zamundaaa[m]>
<pq> "zamundaaa, I don't think we..." <- You can't do color proofing with the ICC-absolute rendering intent as per spec though
<zamundaaa[m]>
Which is a major problem, and lcms provides a way to control the adaptation state (between 0 and 1) to fix the issue
<zamundaaa[m]>
If we keep the absolute rendering intent useless, then we need to add the same to the protocol
<pq>
Why is ICC-absolute rendering intent doing any adaptation?
<pq>
It shouldn't, right?
<pq>
IIRC, the color matrix in the profile is adapted to D50, but then there is another tag that gives the adaptation matrix in order to undo the adaptation.
<pq>
so yeah, I misremembered that they'd be equivalent - but the adaptation tag needs to exist
<zamundaaa[m]>
Read "D.6.1 Relative and Absolute Intents" in the icc spec for how the absolute intent is applied per spec
<zamundaaa[m]>
It says to first apply relative colorimetric, then multiply the resulting XYZ value by XYZ_mediawhite/XYZ_pcswhite
<zamundaaa[m]>
Media white is always D50, and so is PCS white, so that just does nothing
<pq>
Why is media white always D50?
<zamundaaa[m]>
It's mandated for display profiles
<zamundaaa[m]>
Lcms even patches profiles that get it wrong
<pq>
uhh
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
<pq>
so how did things work before Wayland?
<zamundaaa[m]>
Lcms provides cmsSetAdaptationState, which you can use to work around the ICC spec
<pq>
IOW, we are just holding LittleCMS wrong?
<zamundaaa[m]>
If you set adaptation state to zero, the absolute rendering intent does what you'd expect, yes
<pq>
Let's just do that?
<zamundaaa[m]>
Just not what the ICC spec says, which is why I think we should specify the protocol one would be without adaptation
<pq>
hmmm
<zamundaaa[m]>
The alternative is to add a new request, which can be used to set the adaptation state on the surface
<zamundaaa[m]>
Though I would still like to default to "no adaptation" - it's both what KWin does already, and what's needed by applications
<pq>
I'm just surprised we should do something opposite to the ICC spec, and I want to know more about that.
coldfeet has quit [Quit: Lost terminal]
<pq>
There are three white points: medium, PCS, and viewer.
<pq>
Arguably the viewer adapted (a.k.a illumination) white point should be a compositor setting, because it depends on the environment.
<zamundaaa[m]>
The ICC requires the viewer to be fully adapted to the display white point for display profiles
<pq>
Good.
<zamundaaa[m]>
It does however recommend color management systems to provide a way to change the adaptation state for the cases that require it
fmuellner has joined #wayland
feaneron has joined #wayland
<pq>
Hmm, so the difference between ICC-absolute than media-relative intents is just the absence or presence of scaling based on the media color. Both do full chromatic adaptation between the adopted (chosen) white points by default.
<pq>
s/than/and/
<zamundaaa[m]>
yes
<pq>
White point is not a property of CIE XYZ space, while it is a necessary detail of any RGB space encoding. There is the *assumption* that RGB space white point carries also a perceptual meaning, being equal to the viewer adapted white point.
<zamundaaa[m]>
CIE XYZ does also have a white point
<pq>
you mean the trivial 1/3, 1/3?
<zamundaaa[m]>
Yes, it's just implicitly assumed rather than explicitly passed around
<zamundaaa[m]>
More importantly of course, you still need to know the viewer adapted white point
<pq>
But the ICC spec talks about *adopted* white point instead, because... they need a number and cannot know the actual adaptation?
<pq>
well, a scanner doesn't adapt, it adopts something.
<pq>
I guess proofing is not "normal" use of ICC per the ICC spec.
<zamundaaa[m]>
Afaik v2 profiles once had media white point = display white point (as you'd normally expect) and the chromatic adaptation matrix for the actual adaptation
<zamundaaa[m]>
But everyone messed it up, so a lot of profiles were just wrong and so they added this assumption
<zamundaaa[m]>
pq: I can see why, it goes directly against the normal assumptions of white point adaptation
<pq>
I thought the "once had" was the misunderstanding, and v4 "fixed" it by hardcoding D50?
<zamundaaa[m]>
I'm not entirely sure tbh. Either way, lcms switches out media white point of v2 display profiles to D50, so that's what we have now
<pq>
As in, even in v2 originally, mediaWhitePoint tag was supposed to be the media white adapted to D50, which by definition is D50. Only the luminance would vary (maybe?).
nerdopolis has joined #wayland
<pq>
too bad the ICC spec does not discuss prrofing at all, apart from saying "use ICC-absolute rendering intent" which sounds like is not enough.
<pq>
*proofing
<pq>
zamundaaa[m], does the problem arise only when the picture color encoding white point is different from the monitor white point, or is it more universal?
<pq>
hmm, I suppose in proofing, the "picture" is actually the (soft) print, which very likely has a different medium white point.
<zamundaaa[m]>
If the white point is already the same, then absolute and relative colorimetric are always the same anyways
<zamundaaa[m]>
I can also see why the ICC considers that a niche use case
karolherbst has quit [Read error: Connection reset by peer]
karolherbst has joined #wayland
<pq>
What does Krita actually do in that case? What's the pixel data and what ICC profile does it attach to the surface?
<pq>
I would expect Krita to use LittleCMS to render the proof itself for the given display profile, and then attach the display profile to the surface.
<pq>
Meaning that the compositor wouldn't actually touch the pixels at all.
<pq>
We've already forbid using output class profiles on Wayland surfaces, so one cannot off-load the proof rendering to the compositor.
<pq>
Nor should one - it's not the compositor's job.
__0x1eaf has joined #wayland
<pq>
We've specified that all pictures given to the compositor must be rendered for some display.
mohit81582263530690 has quit [Quit: mohit81582263530690]
<zamundaaa[m]>
<pq> "What does Krita actually do in..." <- It sets some form of the recommended image description (parametric in KWin's case) on the surface, and indeed does the transformation itself
mohit81582263530690 has joined #wayland
<zamundaaa[m]>
That will work fine in the most common case - preferred white point matches the display - but if you have display cloning or other more messy situations, you want to avoid the compositor doing whitepoint adaptation
<pq>
oh!
<zamundaaa[m]>
There is of course also another interesting tradeoff with screenshots, if the compositor doesn't do any whitepoint adaptation for a surface
<zamundaaa[m]>
Taking a screenshot and then viewing it on the display won't necessarily look the same as the original
<pq>
You assume the screenshot comes with some standard profile and not the display's profile?
<zamundaaa[m]>
Yeah, screenshots currently are assumed to be sRGB with the portal
<pq>
I guess that's an example of what not doing chromatic adaptation will break.
<zamundaaa[m]>
Screencasts have the same problem too, where we'll always have some standard profile
<pq>
Maybe we should have another rendering intent in the protocol, rather than muck with ICC terminology?
<zamundaaa[m]>
Yes, or copy the lcms approach
<zamundaaa[m]>
Add another request to set the adaptation state (0-1) for absolute colorimetric. Or add a new colorimetric intent with partial adaptation that applies this value
<pq>
one that is "chromatically absolute": no chromatic adaptation, no media relativity; just stimulus to stimulus as-is. But what about luminance?
cmichael has joined #wayland
<pq>
btw. this means I implemented ICC-absolute wrong for parametric :-)
AJ_Z0 has joined #wayland
<zamundaaa[m]>
I did too!
<zamundaaa[m]>
pq: That is a fair point, to avoid clipping, the compositor may have to reduce luminance if no white point adaptation is done
<pq>
I was more thinking, should the new rendering intent also show nit-for-nit, overriding compositor luminance settings? I guess not.
<zamundaaa[m]>
I don't think they need or want that
<pq>
I'd go with a new rendering intent with a fixed definition. We don't have use for variable adaptation state at any other value, do we?
<zamundaaa[m]>
The ICC stuff apps dealt with so far is all relative after all
<pq>
oh yeah, no nits with ICC
<zamundaaa[m]>
Krita has a slider for it, though IIRC Dmitry wrote likely noone uses the intermediary values
<zamundaaa[m]>
Just doing "no adaptation" also means we can avoid having to define what exactly the values in between mean
<pq>
"I am half-adapter to these two different monitors, not between the two, but between Dnn and each monitor individually" :-P
<pq>
*half-adapted
<zamundaaa[m]>
I'll ask again, but I think it should be fine
<pq>
I don't see that making sense.
<pq>
cool
kts has joined #wayland
<pq>
That's an interesting question: if I have two monitors with different white point, what am I adapted to?
<pq>
If we wanted to support such a use case, there would need to be a compositor setting.
<pq>
Do I look at them both together? Or, do I look at them individually?
<zamundaaa[m]>
Right now, I assume you're adapted to the one you're looking at
<pq>
yup, that's the easiest to implement.
<zamundaaa[m]>
I don't intent to support that in the long run though, there will be a white point setting that changes the white point of all displays to be the same in software
<pq>
makes sense for a desktop
<zamundaaa[m]>
Can you think of a case where it doesn't make sense?
<pq>
between a laptop panel and a projector
<pq>
or a computer and a livingroom TV
<pq>
or perhaps any two displays that use wildly different technologies, so they wouldn't match anyway
<zamundaaa[m]>
With a projector, arguably you'll adapt to its white point, so it should be fine in most situations
<zamundaaa[m]>
But that is a fair point, with enough distance between the displays, there could be a difference
<pq>
yeah, but might lose a little bit of capability on the projector
<zamundaaa[m]>
True
<zamundaaa[m]>
Someone may want to keep them different just for the extra brightness
<zamundaaa[m]>
pq: Dmitry said ignoring the intermediary adaptation states is fine
<zamundaaa[m]>
I'll make a MR
<pq>
awesome
<pq>
....should we take the (monitor's chosen) MDCV white point as the adapted white point?
<zamundaaa[m]>
I'm not sure
<pq>
I've been thinking of matching my monitors by setting a target MDCV that is within every one's capability.
<zamundaaa[m]>
With SDR screens, if the user has selected the EDID profile, I do take the white point from that
<pq>
I wouldn't use EDID much, that another topic. :-)
<zamundaaa[m]>
I suppose you could adapt the BT2020 primaries to the native white point of the display, and then work with that
<zamundaaa[m]>
But the monitor may also do white point adaptation from BT2020 to its actual white point, so it could also backfire
<pq>
the target MDCV would be manually crafted, ideally based on measurements
<pq>
it's just that the target MDCV is a second set of primaries and white point that by default matches the signal encoding, but that already exists and could be modified manually.