ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput | register your nick to speak
keir has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
keir has joined #wayland
kts has joined #wayland
kts has quit [Quit: Leaving]
columbarius has joined #wayland
co1umbarius has quit [Ping timeout: 480 seconds]
Satan has quit [Quit: Ping timeout (120 seconds)]
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
Satan has joined #wayland
Sachiel has quit [Remote host closed the connection]
Sachiel has joined #wayland
bindu has quit [Remote host closed the connection]
bindu has joined #wayland
julio7359 has joined #wayland
naveenk2 has joined #wayland
naveenk21 has joined #wayland
julio7359 has quit [Remote host closed the connection]
naveenk2 has quit [Ping timeout: 480 seconds]
molinari has quit [Ping timeout: 480 seconds]
julio7359 has joined #wayland
naveenk21 has quit [Ping timeout: 480 seconds]
vyryls has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
vyryls has quit [Quit: WeeChat 3.8]
junaid has joined #wayland
junaid_ has joined #wayland
junaid_ has quit [Remote host closed the connection]
junaid has quit [Remote host closed the connection]
tzimmermann has joined #wayland
molinari has joined #wayland
julio7359 has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
danvet has joined #wayland
manuel1985 has joined #wayland
julio7359 has joined #wayland
rasterman has joined #wayland
dcz_ has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
mvlad has joined #wayland
inferiormartin_ has left #wayland [#wayland]
rv1sr has joined #wayland
naveenk2 has joined #wayland
junaid has joined #wayland
manuel1985 has quit [Ping timeout: 480 seconds]
junaid has quit [Read error: No route to host]
junaid has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
junaid has quit [Remote host closed the connection]
Company has quit [Quit: Leaving]
pochu has joined #wayland
MajorBiscuit has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
jmdaemon has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
jess has joined #wayland
ofourdan has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
junaid has quit [Remote host closed the connection]
Paul33 has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
devilhorns has joined #wayland
ppascher has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
kts has joined #wayland
kts has quit []
<pq>
swick[m], as it's Friday afternoon here already, I'll get back to the white point discussion next week.
kts has joined #wayland
kts has quit [Remote host closed the connection]
kts has joined #wayland
caveman has joined #wayland
cvmn has quit [Ping timeout: 480 seconds]
<swick[m]>
I love that st2086 is even more vague than me
<JEEB>
xD
<JEEB>
I think I actually never looked into the definitions directly there
<JEEB>
since the SEI contents are in H.274 and the over-the-wire stuff is in CTA-861-H
<swick[m]>
"these parameters describe to color volume of the mastering display" EOF
<pq>
swick[m], one thing in my mind to check if e.g. BT.2100 says anything about mastering, and maybe look if the ITU-T page for it has some additional notes. Or just search ITU for "mastering".
<JEEB>
yea, so basically it's a display hint at how the mastering person saw it. so for example if actual content has like up to 4000 nits
<JEEB>
and the mastering display only was able to show up until 1000 nits
<swick[m]>
yeah, so far so good
<JEEB>
then if you want to show it how it was visible to the mastering person, you can ignore >1000 nits
<JEEB>
in other words, if you have a UHD BD of Mad Max Fury Road with ~9000 nits max brightness in one scene
<JEEB>
you can safely ignore it
<JEEB>
but yes it's kind of dumb, it doesn't describe the actual content
<JEEB>
but rather how it was visible to the mastering person
<JEEB>
ah, white points
<pq>
JEEB, the question is: when in production the movie is displayed on a mastering display, what kind of color mapping is happening from the ??? to the display?
<swick[m]>
JEEB: we already don't completely understand how it should be used when you ignore the luminance stuff
<swick[m]>
it's always white points, isn't it? :)
<swick[m]>
pq: jup, I think we need to understand the mastering process to really get any further here
<pq>
IOW, do we just simply compute the colorimetry of the mastering display, given its primaries and white point, and assume that same colorimetry of the encoded video is the color volume of interest, or does something happen in between?
<pq>
I think the same question applies to primaries as the white point, they are all necessary parts of describing a color space.
<JEEB>
primaries describe the gamut limits
<JEEB>
IIRC
<JEEB>
so in that sense it is clearer for me than white point adjustment
<pq>
if you do white adjustment into mastering display, why stop there and not also do something with the primaries?
<pq>
*white point adjustment
<pq>
or, if adjusting to the mastering display primaries is a no-no, then why is adjusting white point a good thing?
<JEEB>
I think we're stepping a bit too far into it. I think these are just meant to be limiting values when doing gamut/tone mapping to the actual output
<JEEB>
you don't have to do decoded YCbCr->ref display->output display
<pq>
the only thing we want to know is which part of the encoded color space is meaningful, i.e. which part of it was displayed on the mastering display
<JEEB>
yes
<pq>
right, so how do you compute the volume in the encoded color space from the mastering display characteristics?
<JEEB>
haasn is doing it already so clearly it is possible
<pq>
of course, but what is the *right* way to do it? :-D
<JEEB>
I just fed him specs so I'd have to read more about it to properly respond :D
<pq>
haasn, comment?
<haasn>
not sure what the question is
<pq>
I assumed a direct colorimetry conversion from one trichromatic system to another, and swick[m] thinks it could be something else.
<haasn>
primaries conversions commute
<haasn>
encoding -> mastering -> display is the same as encoding -> display
<JEEB>
yea
<haasn>
unless you add some nonlinear step (like clipping) in between
<JEEB>
I think they are jus specifically asking how complex the limiting of gamut and tone mapping should be
<haasn>
but we had this discussion before and I remember advising not to bother clipping in the mastering display volume
<swick[m]>
the mastering display color volume chromatically adapted to the encoded color space white point
<pq>
haasn, but do you do chromatic adaptation when you map the mastering display color volume into the encoding color volume to find out the mastering display limits, or not?
<haasn>
chromatic adaptation also commutes so going from encoding white point to display white point is the same as if you go via mastering white point first
<haasn>
oh
<swick[m]>
:)
<pq>
or actually does the production process do the inverse of that when displaing the product on a mastering display?
Paul33 has quit [Ping timeout: 480 seconds]
<haasn>
no, you don't need to do chromatic adaptation on the mastering display primaries to find the mastering display color volume
<JEEB>
ok, so that is what I assumed :)
<haasn>
well, hmm
<swick[m]>
why not?
<pq>
haasn, would happen to remember any links/docs related to that?
<haasn>
because white point adaptation doesn't touch the primaries, I think
<haasn>
by design
<haasn>
so the gamut volume should stay the same during white point adaptation
<haasn>
but I'm not 100% on this
<swick[m]>
that doesn't sound right...
<pq>
that makes sense to me
<swick[m]>
if you move the white point, the color volume must change
<pq>
no, white point is just the balance between the primaries' power
<pq>
each primary is still ranging from 0 to 100%, defining the extremes of the color volume
<haasn>
hmm
<haasn>
no, I think swick[m] is right, it's just a 3x3 matrix in XYZ space
<pq>
or wait...
<haasn>
so it can only be linear, moving the white point while keeping the primaries the same is impossible
<pq>
yeah, that makes sense
<pq>
white point defines what the 100%, 100%, 100% color is, so naturally that changes if white point changes, and it must an extreme point in the color volume
<haasn>
then I don't really know the answer to the question
<haasn>
but I'm also not sure why it matters
<haasn>
what are you doing with information about the mastering display volume (in encoded space)?
<haasn>
is it to guide tone-mapping?
<pq>
haasn, isn't that volume used to quite gamut and tone mapping?
<haasn>
or gamut mapping
<pq>
*guide
<haasn>
in libplacebo currently no
<haasn>
pq: you know, I would conservatively guess that mastering is probably done without adapting the white point
<haasn>
realize in practice this doesn't matter because 99% of content is mastered on D65 displays with D65 encoding
<haasn>
the only exceptions are, like, what, digital cinema XYZ raws?
<haasn>
of course, that leaves the question open of why the mastering display white point is even signaled
<pq>
right now we want to know what the mastering display primaries and white point mean and how they are used, so that we can put them in protocol and figure out if the concept is compatible what we want to express for scRGB as well, i.e. the relevant part of the container color volume.
<haasn>
we don't use the mastering display white point for anything and I'm not sure what it would even be useful for, tbh
<haasn>
all of this metadata was designed-by-committee in an ad-hoc "let's just add metadata that might be useful later" fashion
<pq>
the mastering display white point tells us what color is the most luminous color possible on the mastering display.
<haasn>
I guess it's useful if you want to clip the input to the mastering display gamut before clipping it to the target display gamut?
<haasn>
to simulate that 1% distortion
<pq>
that's not in my mind, no
naveenk2 has joined #wayland
<pq>
if I want to optimize my gamut and tone mapping, surely knowing what the most luminous color that could ever matter is will help me?
<pq>
and I can map that color to the most luminuous color of my actual display, or something similar
<haasn>
pq: to be clear, when I say "mastering display white point" I don't mean the luminance (brightness) but the CIE x/y chromaticity coordinates
<haasn>
they're signalled separately
<pq>
or to make sure that that color is relatively presentable on my actual display after my mapping
<haasn>
the luminance information is of course very useful
<pq>
yes, I do mean the chromaticity coordinates, not nits
<pq>
maybe the peak luminance on the mastering display is red, and the peak luminance on my actual display is green, to say in an extremely exaggerated example
<pq>
or I should say pink and light greenish
<pq>
surely that matters somehow to what the optimal mapping to the actual display is
<pq>
maybe a mastering display is able to reach up to 1000 nits in a slightly pinkish tone as the highest possible peak nits
<pq>
and maybe an actual display reaches the same 1000 nits peak, but in a slightly greenish tone
<pq>
maybe the actual display can only 800 nits of the same pinkish tone as the mastering display did 1000 nits
[m]peeweep[m] has left #wayland [#wayland]
<pq>
swick[m], am I making sense? :-D
<swick[m]>
yes, very much so
<pq>
cool
<pq>
The thing is, there is only one color (as in one coordinate pair in CIE 1931 xy) that can reach the panel peak nits, and that is when all sub-pixel elements are at 100% intensity each.
<pq>
if you want to shift the chromaticity, then luminance must come down, because they only way to do that is to reduce one or two sub-pixel intensities.
<swick[m]>
practically, what are we going to do about this? My MR currently uses the wp of the encoding color space so it's clear that the primaries of the color volume are relative to that. In that sense we don't have the ambiguity the mastering display concept has.
<pq>
swick[m], but standard HDR metadata has separate white point, and we are not able to carry that.
<swick[m]>
exactly...
<swick[m]>
that would mean we force them to do chromatic adaptation
<pq>
swick[m], I would just add the white point there. We can think more about what to do with it. And assume no chromatic adaptation as the simplest possible appraoch.
<swick[m]>
meh
<swick[m]>
we could also just reuse the mastering display concept and then let compositors figure out how to use it correctly
<swick[m]>
same thing I guess
<pq>
it's just a change of bases from linear algebra
<pq>
yeah
<pq>
I suppose there is no problem applying the mastering display concept to scRGB either?
<JEEB>
yea it's the possible composition space so it wouldn't yet be affected anyways
<JEEB>
then after compositing stuff you convert to output(s)
<JEEB>
and at that point you might or might not want to apply it. afaik windows just ignores it and passes onto displays
<pq>
why convert twice, when you can blend in the optical output space?
<pq>
passes what to displays?
<JEEB>
the metadata
<JEEB>
in case of HDR output
<pq>
but we have multiple windows each with different metadata on the same monitor
<JEEB>
I think windows passthroughs when application == output, and otherwise through scRGB would be my guesstimate. scRGB is just convenient since you map HDR at 203 nits to graphics white (1.0) and with SDR applications you just map 1.0 to 1.0
<JEEB>
and same for output
naveenk2 has quit [Ping timeout: 480 seconds]
<JEEB>
pq: I think windows just goes lalala and either doesn't output metadata, or picks the widest on screen
<pq>
heh
<JEEB>
I think windows might have not output any metadata unless application is fullscreen
<JEEB>
need to check my mpv issues :P
<pq>
then you also need to map scRGB to output space which may be more complicated than KMS can express, so you take the hit of second pass on the GPU - at least Weston will try to avoid that by blending in optical output space to the after-blending operations are few and simple.
<pq>
*so the after-blending
kts has quit [Quit: Leaving]
<pq>
swick[m], btw. as Vitaly has been looking into tone mapping, maybe he has seen something about using the mastering display characteristics?
agd5f_ has joined #wayland
Paul33 has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
<haasn>
14:12 <pq> if you want to shift the chromaticity, then luminance must come down, because they only way to do that is to reduce one or two sub-pixel intensities. -> okay, it makes sense
<haasn>
or paraphrased, if you know that mastering display white point = very blue, mastering display peak nits = 1000
<haasn>
then the actual content might contain blue at 1000 nits
<haasn>
but your display can only show blue at 200 nits
<haasn>
even though your display can show white at 1000 nits
<haasn>
so you might naively think "oh great, I don't need to tone-map", but it would be wrong
jmdaemon has joined #wayland
cool110 has joined #wayland
naveenk2 has joined #wayland
cool110_ has quit [Remote host closed the connection]
caveman has quit [Quit: caveman]
agd5f has joined #wayland
molinari has quit [Ping timeout: 480 seconds]
naveenk2 has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
agd5f_ has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
naveenk2 has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
<pq>
haasn, exactly :-)
<pq>
and that matches your description of a unit cube mapped into XYZ or another through a 3x3 matrix
agd5f has joined #wayland
<pq>
white point affects where the peak goes, and I think it also affects where all the other corners go except the 0,0,0
<pq>
white point even affects where the corners of the primaries go - not their chromaticity but their luminance
<pq>
hmm, an interactive app would a nice visualization for this
adia4 has quit []
adia4 has joined #wayland
pochu has quit []
<swick[m]>
yeah it's kind of weird that there is no interactive tool like that
<swick[m]>
the best we have is python scripts which output some image
<pq>
shouldn't be too hard to write that python to make it interactive with the help colour, numpy and matplotlib.
<pq>
but hard enough that I'd need to put a couple days aside to do that :-)
jmdaemon has joined #wayland
devilhorns has quit []
kts has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
molinari has joined #wayland
agd5f_ has joined #wayland
jmdaemon has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
tzimmermann has quit [Quit: Leaving]
<haasn>
there's a tool for visualizing icc gamuts in argyllCMS
<haasn>
even comes with a fancy WebGL HTML5 thing
Company has joined #wayland
molinari is now known as Guest5159
molinari has joined #wayland
vyivel has quit [Remote host closed the connection]
vyivel has joined #wayland
Guest5159 has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
molinari has quit [Remote host closed the connection]
Paul33 has quit [Ping timeout: 480 seconds]
Paul33 has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
julio7359 has quit [Ping timeout: 480 seconds]
julio7359 has joined #wayland
kts has quit [Quit: Leaving]
MajorBiscuit has quit [Quit: WeeChat 3.6]
jmdaemon has quit [Ping timeout: 480 seconds]
jmdaemon has joined #wayland
agd5f_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
danvet has quit [Read error: Connection reset by peer]
danvet has joined #wayland
fmuellner has quit [Remote host closed the connection]
Paul33 has quit []
mvlad has quit [Remote host closed the connection]
agd5f has joined #wayland
hardening has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
manuel1985 has joined #wayland
junaid has joined #wayland
agd5f_ has joined #wayland
dcz_ has quit [Ping timeout: 480 seconds]
agd5f has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
caveman has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
agd5f_ has joined #wayland
agd5f has quit [Ping timeout: 480 seconds]
agd5f_ has quit [Ping timeout: 480 seconds]
hardening_ has joined #wayland
hardening has quit [Ping timeout: 480 seconds]
danvet has quit [Ping timeout: 480 seconds]
manuel1985 has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
danvet has quit [Ping timeout: 480 seconds]
danvet has joined #wayland
rv1sr has quit []
junaid has quit [Remote host closed the connection]