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
nullpointer128 has joined #wayland
nullpointer128 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nullpointer128 has joined #wayland
paulk-ter has quit [Ping timeout: 480 seconds]
thevar1able has joined #wayland
nullpointer128 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nullpointer128 has joined #wayland
nullpointer128 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vyryls has joined #wayland
Brainium_ has quit []
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
nullpointer128 has joined #wayland
nullpointer128 has quit []
nullpointer128 has joined #wayland
nullpointer128 has quit []
julio7359 has joined #wayland
cool110 has quit [Remote host closed the connection]
cool110 has joined #wayland
naveenk2 has joined #wayland
naveenk21 has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
naveenk22 has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
molinari has quit [Ping timeout: 480 seconds]
naveenk21 has quit [Ping timeout: 480 seconds]
vyryls has quit [Ping timeout: 480 seconds]
vyryls has joined #wayland
naveenk22 has quit [Ping timeout: 480 seconds]
naveenk2 has joined #wayland
naveenk21 has joined #wayland
julio7359 has quit [Remote host closed the connection]
naveenk2 has quit [Ping timeout: 480 seconds]
nullpointer128 has joined #wayland
julio7359 has joined #wayland
junaid has joined #wayland
nullpointer128 has quit [Ping timeout: 480 seconds]
<pq>
d_ed, sorry, that's a too complicated topic for me to dig in this year I think.
naveenk21 has quit [Ping timeout: 480 seconds]
dcz has joined #wayland
<d_ed>
I'm happy to spend time going through anything. It's not too complicated after that
<pq>
Sorry, I don't think I can invest the time for that.
Company has quit [Quit: Leaving]
<pq>
things can change, but not any time I can see yet
naveenk21 has joined #wayland
naveenk2 has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #wayland
nobiz has joined #wayland
naveenk21 has quit [Ping timeout: 480 seconds]
kts has joined #wayland
paulk has joined #wayland
vyryls has joined #wayland
vyryls has quit []
vyryls has joined #wayland
vyryls has quit []
naveenk2 has joined #wayland
devilhorns has joined #wayland
pochu_ has joined #wayland
pochu has quit [Ping timeout: 480 seconds]
agd5f has joined #wayland
agd5f_ has quit [Ping timeout: 480 seconds]
pochu_ has quit [Read error: Connection reset by peer]
pochu has joined #wayland
vyryls has joined #wayland
nerdopolis has joined #wayland
kts has quit [Quit: Leaving]
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #wayland
droidbittin has joined #wayland
droidbittin has left #wayland [#wayland]
MajorBiscuit has quit [Remote host closed the connection]
MajorBiscuit has joined #wayland
pochu has quit [Ping timeout: 480 seconds]
<swick[m]>
pq: I have the feeling you're over complicating chromatic adaptation for color space conversions
<pq>
I don't know what it is.
Net147_ has joined #wayland
<swick[m]>
the appearance of a specific chromaticity is different when adapted to different white points
Net147 has quit [Ping timeout: 480 seconds]
<swick[m]>
so when you do a color space conversion where the color spaces have different white points you chromatically adapt the colorimetry to the new white point (with relative colorimetric and perceptual intents)
<pq>
but we are not talking about *those* rendering intents
<pq>
why would we?
<swick[m]>
all the video signal always implicitly assume a perceptual intent
<pq>
really? even for a mastering display?
<swick[m]>
that's what I'm not entirely sure about
<swick[m]>
someone must have specified this somewhere...
<pq>
perceptual intent is arbitrary, and I cannot imagine a mastering display would do random arbitrary things to the signal
<swick[m]>
I mean, to me it makes sense for it to be relative colorimetric
<swick[m]>
because otherwise you loose information...
<swick[m]>
if you assume the wp of the mastering display to be different from the encoding wp and you do not chromatically adapt it, then the appearance on a reference monitor will be different than that from the mastering display
<swick[m]>
(assuming the viewer is mostly adapted to both the mastering and reference display each time)
<pq>
I don't understand reference monitor.
<swick[m]>
in this case it's only relevant that the reference monitor has the white point of the color space
<pq>
so let's talk only about the colorspace and not a reference monitor?
<swick[m]>
sure, but the argument I made was about appearance and for that you need some media
<swick[m]>
let's try to make this a bit simpler...
<pq>
it sounds like you are talking about adapted white, but then you say you are not talking about adapted white.
<pq>
adapted white is connected to appearance
<pq>
color space white point is not about appearance
<swick[m]>
if you have two monitors, each with a different white point, and when the viewer is viewing one of the monitors and is adapted to the monitor white point, then the same colorimetry will look different on the different monitors, right?
<swick[m]>
and yes, this is about adapted white
<pq>
yeah, and my big gitlab comment was all about adapted white
<swick[m]>
now you describe the monitors with a color space. the color spaces will have different white points.
<swick[m]>
pick a color, encode it in one of the color spaces. encode the same colorimetry in the other color space. do the colors appear the same, when viewed on the monitors?
sozuba has joined #wayland
<pq>
if the environment is the same, and both monitor can actually display that color, then yes, I think they do, because they both emit the same colorimetry.
<swick[m]>
even if the viewer is adapted to the monitor?
nerdopolis has quit [Ping timeout: 480 seconds]
<pq>
adapted to *what*?
<pq>
the viewer does not magically see the monitor white point, something needs to give it away
<pq>
I'm assuming the chosen color is the only thing showing on the monitors
<swick[m]>
ah... in that case you're probably right
<swick[m]>
but let's assume there is/was enough content on there for the viewer to be adapted to the monitor white point
<pq>
if you had monitor-white background on each monitor, then I'd say they do not appear the same, because the monitor-white is not the same and it is being displayed
<pq>
however, where would that monitor-white content come from?
<pq>
if you take an image instead of a single color, and do the same thing, and not show anything else on each monitor, then again there is nothing giving away the actual monitor white point
MajorBiscuit has quit [Ping timeout: 480 seconds]
<swick[m]>
true, but if you have an avergae scene then our hvs will adapt to the white point of the monitor so some degree
<swick[m]>
I guess that's just implicitly assumed
<pq>
no, because the whole image has gone through the same conversion to the monitor's trichromatic system
<swick[m]>
mh, I see
<pq>
if you had some literally other content on the monitor that did not go through that conversion, then yes, the adaptation would be, well, ruined
<swick[m]>
yeah, I get it now
<pq>
cool - are we any closer to an answer? :-)
<pq>
btw. this is going to hurt floating window color appearance, as you always have something else on screen too :-p
<pq>
but that's not our problem, and it probably should not even be attempted to be fixed, because that would imply static screen content to shift in color when just one window is animating, which would probably be even more disturbing
<pq>
and it certainly won't be on any mastering display
<swick[m]>
I think there are two good reasons why chromatically adapting still makes sense
<swick[m]>
1. as you said, when you combine content they now have different white points and the adaptation will be screwed
<swick[m]>
2. when you chromatically adapt, the color volumes will match better and you'll be able to reproduce more colors in the other color space
Cyrinux9 has quit []
<swick[m]>
so I think you're technically correct but everyone just chromatically adapts when doing color space conversions, except for when you want something very specific like softproofing
Cyrinux9 has joined #wayland
MajorBiscuit has joined #wayland
vyryls has quit [Quit: WeeChat 3.8]
MajorBiscuit has quit [Ping timeout: 480 seconds]
<pq>
swick[m], in what context are we talking about now? Mastering displays specifically, or in general?
<swick[m]>
in general
<pq>
yes, I agree
<swick[m]>
hence my question, do we chromatically adapt the mastering display volume to the encoding volume?
<swick[m]>
I think so, but I'm not entirely sure
<pq>
I'd say no, that's what the production should be doing already
<swick[m]>
but it literally describes the mastering display, not a chromatically adapted mastering display
<pq>
exactly
<pq>
asking from another angle: if the mastering display did chromatic adaptation, why would we need HDR static metadata to describe the mastering display?
kts has joined #wayland
devilhorns has quit []
<pq>
why does HDR static metadata carry a white point explictly?
rasterman has quit [Quit: Gettin' stinky!]
<pq>
JoshuaAshton, do you know? :-)
<swick[m]>
well, I'm not saying the display does any chromatic adaptation, I'm saying the mastering process does, when converting between the mastering display and the encoding color space
<pq>
that's indistinguishable from the mastering display doing it
<swick[m]>
the way I see it, they need the white point to describe the mastering display color space, but they could have also chosen to chromatically adapt the primaries of the mastering display white point and then only store that (but naming this is harder)
<pq>
primaries of the white point?
<swick[m]>
ehh, chromatically adapt the primaries of the mastering display to the encoding color space white point
<pq>
but then it would not describe the colorimetry of the mastering display color volume anymore?
<swick[m]>
yes, only the volume in the encoding color space which is relevant
<pq>
I see
<pq>
but then, what do you use as the "unit cube" ranges to actually find the volume?
<swick[m]>
no idea. that's why I'm starting to really like the idea of the mastering display color space
<pq>
which idea? just switch the name from color volume to colorspace?
<swick[m]>
kind of...
<pq>
what about scRGB?
<swick[m]>
same deal, right? if you choose a white point that matches sRGB then it's exactly like the color volume concept right now...
<pq>
scRGB kinda does not have the unit cube though
<pq>
I mean, nothing forces one to pick sRGB white point for scRGB content colorspace