ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
fmuellner has quit [Ping timeout: 480 seconds]
karenw has quit [Ping timeout: 480 seconds]
DemiMarie is now known as Guest12662
Guest12630 is now known as DemiMarie
feaneron has quit [Ping timeout: 480 seconds]
Moprius has quit [Remote host closed the connection]
feaneron has joined #wayland
tokyo4j_ has joined #wayland
tokyo4j has quit [Ping timeout: 480 seconds]
tokyo4j_ is now known as tokyo4j
glennk has joined #wayland
Company has quit [Ping timeout: 480 seconds]
Company has joined #wayland
garnacho has quit [Ping timeout: 480 seconds]
kts has joined #wayland
user21 has quit [Quit: Leaving]
agd5f has quit [Remote host closed the connection]
agd5f has joined #wayland
FreeFull has quit []
feaneron has quit [Ping timeout: 480 seconds]
eluks has quit [Remote host closed the connection]
eluks has joined #wayland
kts has quit [Ping timeout: 480 seconds]
kts has joined #wayland
tzimmermann has joined #wayland
rasterman has joined #wayland
sima has joined #wayland
kts has quit [Ping timeout: 480 seconds]
bodiccea has quit [Remote host closed the connection]
<swick[m]>
that was on my list for a while now, so I'm happy I can just point people at this :)
<swick[m]>
but I also wonder if we can add it to the color-and-hdr repo somehow
<paulk>
swick[m]: I'd be interested to know if it's actually correct to convert sRGB to Rec.709 with a linear operation that doesn't account for the gamma 2.2 to gamma 2.4 change
<paulk>
because that's apparently what is done most of the time
<Company>
that depends on your definition of "correct"
<Company>
mathematically correct: no
<Company>
good enough so people don't see the difference on an average monitor: yes
<swick[m]>
also I guess you mean decoding a sRGB signal with BT.1886?
<paulk>
well BT.1886 is used for both sRGB and Rec.709
<paulk>
Company: yes I mean mathematically correct :)
<Company>
good enough so people doing this for a living don't see this on a modern HDR monitor: uh oh
sqwishy has quit [Ping timeout: 480 seconds]
<paulk>
hehe
<swick[m]>
if you do decode sRGB with BT.1886 then there is a mismatch. it can be intentional.
<paulk>
that being said it could be implemented with a LUT with little cost
m5zs7k has joined #wayland
<paulk>
swick[m]: IIRC BT.1886 is the EOTF, not the OETF
<swick[m]>
yes...?
<Company>
(LUT works as long as you use 8bit or 10bit)
<paulk>
swick[m]: well it's implied in sRGB that it's shows on BT.1886 monitor, isn't it?
<paulk>
shown*
<paulk>
so it's not about "decoding sRGB" it's really about the screen that's plugged in
<paulk>
or did I misunderstand something?
<swick[m]>
it's more subtle than that. you can't just decode any signal with any EOTF and expect it to produce something sensible
<swick[m]>
i.e. if you decode a bt2100 signal with bt.1886 you get a pretty bad result
<paulk>
right so that's why both sRGB and Rec.709 specify both the OETF and EOTF
<paulk>
well bt2100 doesn't specify that that bt.1886 should be used
<paulk>
so yeah if you're mixing two specs it's a mismatch
<paulk>
we agree I think :)
<Company>
best thing to do: get a bunch of bytes and a tool that can convert stuff correctly and then tag that data with all the different options
<Company>
and see how much the results differ
<swick[m]>
I'm unsure if sRGB specifies bt.1886 as possible EOTF
<paulk>
swick[m]: AFAIK it's the only one that's specified
<JEEB>
H.273 only mentions BT.1886 as the EOTF for specific ones that are video related, sRGB is not one of those values.
<swick[m]>
but yeah, there can be multiple EOTFs to use for one signal. the important point then however is that they can have different reference viewing environments.
<JEEB>
not to mention that previously the only interpretations for sRGB were piecewise VS gamma 2.2 (reference display)
<paulk>
oh I see, didn't think about viewing environments
<swick[m]>
which is why I'm saying that the mismatch between encoding and (different) decoding can be intentional to adjust the signal to the viewing environment
<paulk>
okay, good to know!
<swick[m]>
but it should indeed be specified that an encoding and decode can be used together
<swick[m]>
and JEEB probably knows better which ones are specified to work together than me
<swick[m]>
right, that suggests that using BT.1886 to decode sRGB is not specified and you probably shouldn't do that
<JEEB>
the only place where I've heard of where sRGB might get decoded as BT.1886 is apple's "SDR content transfer function" override, which does indeed let you set BT.1886 as one of the EOTFs
<JEEB>
but that is just an override
<paulk>
so sRGB has its own EOTF then?
<swick[m]>
gamma 2.2, yes
<JEEB>
which definitely has not been clear to people since even MS implemented it piecewise ;)
<swick[m]>
MS also implemented PQ without adapting it to the actual viewing environment
<JEEB>
that's another common mis-thought ;)
<JEEB>
"no the signal says it's 413 nits, so it must be delivered to display as 413 nits signal!!!!"
<swick[m]>
you can almost do the opposite what MS is doing with color and you're on the right track
fmuellner has joined #wayland
___nick___ has quit [Remote host closed the connection]
sqwishy has joined #wayland
karenw has joined #wayland
<zamundaaa[m]>
swick: thank you! Took a while to write :)
karenw has quit [Remote host closed the connection]
karenw has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
riteo has quit [Ping timeout: 480 seconds]
eroc1990 has joined #wayland
feaneron has joined #wayland
feaneron has quit []
feaneron has joined #wayland
<karenw>
There's now so many compositors on wayland.app, the `Compositor Support` section has a horizontal scrollbar. That's a lot of compositors
<kennylevinsen>
the list is still very much incomplete
<psykose>
why is louvre the library there when the others are compositors
<davidre>
karenw: you need a wider monitor^^
<karenw>
In the words of wikipedia "[This list] may never be able to satisfy particular standards for completeness."
<karenw>
davidre: I don't think wider in the sence of a larger physical screen size, aspect ratio (16:10), or logical resolution (i.e. after DPI scaling) would meet my requirements for usability.
<karenw>
I could set the dpi to some arbitary low figure though ;)
<davidre>
Seems to fit at least on my bog standard 1080p one
<davidre>
of course fonts also matter probably
<karenw>
1920x1080 at whatever dpi "125%" is in kwin.
<karenw>
*1920x1200
<davidre>
kentrl is now just copy pastaing old comments...