ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
CME_ has quit []
CME has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
sevz has joined #wayland
maxzor has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
glennk has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
nerdopolis has joined #wayland
Company has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
Company has quit [Quit: Leaving]
Brainium has quit [Quit: Konversation terminated!]
gildekel has quit [Quit: Connection closed for inactivity]
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
julio7359 has quit [Ping timeout: 480 seconds]
mblenc1 has joined #wayland
mblenc has quit [Ping timeout: 480 seconds]
mblenc has joined #wayland
mblenc1 has quit [Ping timeout: 480 seconds]
mblenc has quit [Ping timeout: 480 seconds]
glennk has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
leon-anavi has joined #wayland
rv1sr has joined #wayland
qaqland is now known as Guest7068
Guest7068 has quit [Read error: Connection reset by peer]
qaqland has joined #wayland
qaqland is now known as Guest7069
Guest7069 has quit [Read error: Connection reset by peer]
qaqland has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
<pq>
JoshuaAshton, precisely that, yes.
<JoshuaAshton>
pq: Yeah, very visually noticable in the darks/shadows.
<pq>
good to know
<JEEB>
:)
<JoshuaAshton>
We tested this a bunch for Deck OLED and the way we want to show SDR/sRGB content on HDR
<pq>
so what's the expected behaviour and according to whom?
<JoshuaAshton>
We went with G2.2 as the EOTF to be consistent with the intent (given it is going to be mastered on a G2.2 display, also the ref display spec for sRGB calls for G2.2 curve), and what consumers have been seeing for the past 25 years or whatever
<pq>
ok, so you believe that sRGB displays internally implement G2.2 even today? Has that been verified?
<JoshuaAshton>
Every consumer desktop display these days is G2.2, yes.
<JoshuaAshton>
Including your phone
<JEEB>
so that's for display, but what if you then are taking in an sRGB image and need to convert it to something else? would you still utilize a different transfer than the one that was utilized to go from linear to sRGB?
<JEEB>
I know there are some fun transfers like BT.709 which is BT.709 one way, and BT.1886 the other way. but is then sRGB considered one of those, too?
<JoshuaAshton>
I would say only for the Display EOTF
<pq>
JEEB, as it turns out, yes, it seems so.
<JoshuaAshton>
I would use piecewise for all other operations
<JoshuaAshton>
Another way to think of it is there's an implicit tonemapping that happens at the toe of the curve for display.
<JoshuaAshton>
Another reason we went with this, is for example if you have one display that is HDR (HDR10 PQ), and another that is SDR (G2.2), you would want the SDR content to look the same on both displays.
<JEEB>
also it's kind of hilarious that if it is considered such, then stuff like how iOS currently lets you passthrough values with sRGB transfer would not be correct
<pq>
for BT.709, if you undo the spec defined encoding function, you have no idea what you get. What you get may not have even existed at all, if people have been tuning the encoded values directly to look fine on the reference display. That's display-referred in definition.
<JEEB>
(and match the handling between macOS and iOS, for example)
mblenc has joined #wayland
<pq>
the applies to sRGB apparently, people pick hex color codes or equivalent tuning, and just see what looks best on their (supposedly) reference display.
<pq>
*the same
<JEEB>
since BT.709 transfer was implemented before BT.1886 existed in macOS, and iOS matches BT.1886 apparently. so the current way of "how to make video look the same between these two" is to utilize sRGB transfer :)
<JEEB>
which seems to be passthrough on both
<JEEB>
or at least handled the same
<JoshuaAshton>
It's also worth noting that the Deck OLED screen's curve is G2.2 (as is Deck LCD and all the other handhelds), but we decided on G2.2 for SDR back when I was only focusing on external display and experimenting there and noticed these differences.
<pq>
JEEB, but pass-through of sRGB encoded values *is* correct, because an sRGB display uses G2.2, not two-piece.
<JEEB>
ok, so you are talking of display EOTF as well :)
<pq>
yeah, in the end it's the light that matters
<JEEB>
so as an application that needs to convert between linear and sRGB (say swscale or zimg), both ways should then utilize the sRGB knee'd version
<JoshuaAshton>
Yeah, if you are not dealing with light/display, use the piecewise curve
<JoshuaAshton>
And that is only to preserve intent of currently authored materials
<pq>
the curve you need to pick for encoding depends on *how* you define your content
<pq>
do you want to encode specific "original" colorimetry, or do you want to produce a specific displayed image, knowing that if you tag pixels as sRGB they will be decoded with G2.2.
<pq>
...in display pipeline
<pq>
do you want to be operating in the source or destination "linear" space
<JEEB>
but yea I think this "specific to display EOTF" thing is what I wanted to earlier figure out if that was what you were limiting to, since it did not sound correct that sRGB signal that you just encoded then has to be linearized by G2.2 if you want to go back there.
<pq>
the choice depends on what you're doing
<pq>
if you're editing an sRGB image, and need to temporarily decode and then re-encode it, then re-encode function should be the exact inverse of the decode function you choose
<JoshuaAshton>
ye
<JEEB>
yup
<pq>
and for that, you have the choice: two-piece or G2.2
<pq>
so you want to operate in the hypothetical source colorimetry, or in the reference display colorimetry
<pq>
*do you
<JEEB>
so this is higher level decision making than definition of EOTF/OETF for a specific thing. as a library you make both G2.2 and the sRGB transfers available and you pick what is applicable to your use case in the application logic
<pq>
yes
<JEEB>
the thing I had issue with was that encode(transfer=sRGB).decode(transfer=sRGB) would not lead to the same linear image, but thankfully that's not what you're advocating for at all :) it was just all mentioned as "EOTF"
rasterman has joined #wayland
<JoshuaAshton>
I mean the very physical sense of EOTF :frog:
<JoshuaAshton>
Literal zappy zappy -> photon :P
<JEEB>
(since that is already true for the BT.709 transfer already in various libraries, but since that's actually explicitly mentioned in the specs that's just something you deal with as part of "it's old" - and then point at something that is generally supported and round-trips like sRGB transfer if someone wants to generate new content)
mvlad has joined #wayland
<JEEB>
well, round trips in the sense that if you have an sRGB image and you encode it with BT.709, that image will be slightly different when you then play that in a player following BT.1886 :)
<pq>
yeah, I think we need to dedicate "sRGB" to mean two-piece, and G2.2 to mean G2.2, and the protocol carries the content *encoding* convention, leaving the compositor to figure out the correct display decoding convention which for sRGB input is G2.2.
<JoshuaAshton>
There's also *a lot* of games that also tag themselves as sRGB but are also delivering G2.2 to be displayed as G2.2
<JoshuaAshton>
I guess it's less about them tagging themselves, a lot of them pre-date any form of ColorSpace tagging stuff, but just knew what they were targeting hehe
<pq>
JoshuaAshton, that sounds like a problem.
<JoshuaAshton>
It isn't *really* given we are displaying them as G2.2
<JoshuaAshton>
The problem ends up cancelling itself out
<JoshuaAshton>
Either way the artistic/mastering intent is preserved
<JEEB>
and untagged windows surfaces I would expect get handled exactly the same when the windows desktop is in PQ mode
<JoshuaAshton>
Windows uses sRGB piecewise for everything sRGB or untagged
<JEEB>
yea
<JoshuaAshton>
It looks really 'off'
<JoshuaAshton>
Lots of people complain about Windows' HDR given it tries to be as close to spec as possible, but without realising that violates the artistic intent of all previously authored media given the G2.2 thing and that people generally don't like their SDR content being limited to 709
<JEEB>
at least they do the SDR graphics white to 203 nit boosting
<pq>
you're right, it does cancel out, because a compositor would decode claimed-sRGB with G2.2 before converting to e.g. PQ.
<JoshuaAshton>
Yep
<JEEB>
oofff, so a pipe line of a video player would for a sRGB PNG look like: G2.2 and then output transfer encoding?
<JoshuaAshton>
Yeah, that would match how stuff has b
<JoshuaAshton>
*stuff has been displayed for 25 years
<JEEB>
ouch
<JoshuaAshton>
Why ouch?
<JEEB>
since I'd say most software currently treats sRGB tagged content as sRGB transfer, linearizes and then outputs PQ for example
<JoshuaAshton>
Yeah, I mean even Windows is doing that right now, and it just looks really off compared to putting displays in SDR mode where they act as G2.2
<pq>
*bzzzt* :-D
<JEEB>
or at least most stuff that I've been around, such as zimg or mpv or libplacebo. if you say your input is sRGB and output is PQ, you're not going to get G2.2 in the middle
<pq>
with Troy's reply included, sounds like we have an answer I can go write up in color-and-hdr
<emersion>
why do that instead of putting it above?
<Company>
there's a pink line going through my app now
<Company>
emersion: so I can draw stuff on top - we put it above if we don't
<emersion>
yes, that's a known limitation of the fractional scaling protocol
<Company>
so what do I do in that case? Not offload?
<emersion>
hm, rather
<Company>
get somebody to define stuff properly?
<emersion>
subsurfaces can only be placed at logical coords
<Company>
yeah
<Company>
and then they get snapped by the compositor
<emersion>
so it may be that someone got the rounding wrong
bim9262 has joined #wayland
<Company>
there might be rounding issues that make this more visible than it should be, but the problem does exist - compositors snap surfaces to the pixel grid
kts has quit [Ping timeout: 480 seconds]
<Company>
I also used 125% because that's more visible than 150% would be
<Company>
but it means if I use a coordinate that's not a multiple of 4, the compositor will adjust the subsurface position somehow
<Company>
if I know how it adjusts, I can of course prepare for that in advance and punch the hold accordingly
molinari has joined #wayland
<Company>
*the hole
<Company>
it's also slightly relevant because of opaque regions, though I'm not sure how compositors handle that
<Company>
but I need to punch the hole into the opaque region, too and I want the (fully opaque) subsurface to fit it exactly
molinari has quit [Remote host closed the connection]
molinari has joined #wayland
molinari has quit [Remote host closed the connection]
<kennylevinsen>
Currently, the only way to handle subsurface rounding errors is to have more compliant geometries - e.g., rather than a hole, having a black background so any rounding still just reveals black.
<Company>
yeah, but that doesn't work
<Company>
because I need to punch a hole as long as the subsurface is below the surface
<kennylevinsen>
the only way to handle this with logical coords in a stable manner is somewhat complex rounding rules, and fractional-scaling-v1 ended up leaving it undefined. Solutions for this is what v2 discussions are about.
<Company>
I mean, it's kinda trivial to turn off the offloading for fractional scales
<Company>
but that's of course unfortunate
<kennylevinsen>
indeed
<Company>
fwiw, it's also somewhat sad that I can't position at 0.5 on 200%
<Company>
because everything uses logical coords
<kennylevinsen>
yeah, that's also part of what v2 discusses
<Company>
I guess I should comment on the relevant issues/mrs that GTK implements this stuff now
<Company>
so that it moves from theoretical issues to practical problems
<kennylevinsen>
It was always practical, it was just also hard with no one agreeing on a solution :)
<kennylevinsen>
but please do comment - the original discussions made it sound like Gtk support would not happen anytime soon
<zamundaaa[m]>
Company: the problems are already practical; with some panel sizes and scale factors, we get a line between the panel and maximized apps for example
<Company>
oh
<Company>
yeah, that makes sense
<zamundaaa[m]>
If we can get a more complex client implementation going, I'd be glad to update the KWin implementation and push the protocol forward again. I haven't seen a big reason to so far because implementing the protocol in Qt takes more time than I had for this problem lately
<Company>
kennylevinsen: when the original discussions happened, nobody had any clue how to make anything like this happen in GTK
<kennylevinsen>
that's fair
<Company>
kennylevinsen: there were like 3-5 pretty fundamental ideas that happened in the last few months
bim9262 has quit [Ping timeout: 480 seconds]
bim9262 has joined #wayland
nerdopolis has joined #wayland
<pq>
JoshuaAshton, do you have a github.com account? I'd like to mention you in a Khronos issue about sRGB.
ErrorNoInternet has joined #wayland
<zamundaaa[m]>
about the sRGB stuff, the conclusion there is to use gamma2.2 as inverse EOTF and as EOTF, but only when targeting a display, right?
<zamundaaa[m]>
So, what about screenshots?
<zamundaaa[m]>
I guess because (with sufficient resolution) it's an identity transform in total it's ok?
maxzor has quit [Ping timeout: 480 seconds]
bim9262 has quit [Ping timeout: 480 seconds]
<pq>
I think screenshots should be true to their (parametric) image description. They are still pictures intended to be displayed, so displaying them should happen by the usual rules. So you have to pick the TF in the image description such that the re-display is the same as original display.
bim9262 has joined #wayland
<pq>
Presumably an sRGB display would be characterized as using gamma 2.2 EOTF, because that's what it does by definition.
ErrorNoI1ternet has quit [Ping timeout: 480 seconds]
<pq>
I say "presumably" because ICC practises are... inconsistent about that.
<JEEB>
so the CICP value should be sRGB, which then for the display would get passed through on a G2.2 display
<zamundaaa[m]>
well, currently screenshots don't have an explicit image description
<zamundaaa[m]>
If I encode them in gamma2.2 and image viewer software assumes it's sRGB, then sRGB content shown in that screenshot will look correct
<pq>
anyway, if you characterize your screenshot images as sRGB, then decoding them with gamma 2.2 should produce the correct image. The same effect if you tag it with gamma 2.2 instead.
<zamundaaa[m]>
But PQ content shown in that screenshot will not look correct because of the implicit change of the response curve
<pq>
JEEB, yes, sRGB encoded data is meant to be passed as-is to a gamma 2.2 display by sRGB spec.
<pq>
zamundaaa[m], your screenshot "target buffer" is just another display with its own image description. Do all the usual color management instead of scraping some real output's framebuffer with a different image description.
<pq>
that gives you the freedom to arbitrarily pick the screenshot image description
<zamundaaa[m]>
I suppose we could and should do that for screenshots, yeah
<zamundaaa[m]>
For screen casts though that might be a bit resource intensive
<zamundaaa[m]>
I guess the real solution is to plumb image descriptions through the screenshot and screencast infrastructure anyways
<pq>
if you want anything non-sRGB through, yeah :-)
bodiccea has joined #wayland
maxzor has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
danshick has quit [Read error: Connection reset by peer]
tlwoerner_ has joined #wayland
bim9262 has joined #wayland
tlwoerner has quit [Ping timeout: 480 seconds]
danshick has joined #wayland
privacy has quit [Quit: Leaving]
privacy has joined #wayland
mohit8158 has quit [Quit: mohit8158]
AnuthaDev has joined #wayland
mohit8158 has joined #wayland
bim9262 has quit [Ping timeout: 480 seconds]
<clamps>
i've never been able to find a clear answer on when it's appropriate to use the straight power 2.2 function vs. the more complex function with the linear piece at the bottom end