00:04swick[m]: JEEB emersion the colorimetry infoframe affects primaries+wp, YCbCr conversion and transfer characteristics. the HDR metadata can overwrite the transfer characteristics. the colorimetry infoframe is often implemented badly and only serves for the manufactures to claim HDR.
09:25pq: zamundaaa[m], if EDID claims no HDR support, but has BT2020 support, wouldn't that be a worthwhile hint that SDR BT2020 might actually work?
09:26emersion: or a broken EDID? :P
09:26pq: sure
09:26pq: would be nice to know if EDID has lies...
09:28pq: emersion, yeah, monitor manufacturers probably test a few signal configurations and not most possible combinations they claim to support.
09:29pq: like my HP monitor engages HDR if (TF=PQ && max_luminance > 100 cd/m²).
09:29pq: otherwise it seems like all HDR metadata is ignored
09:31pq: but while playing with it, I also found https://gitlab.freedesktop.org/drm/amd/-/issues/3358
09:32pq: oh right, that was a HDMI-only bug, and I have it hooked up via DP now
09:33pq: but I cannot recall seeing any colorfulness differences between SDR and HDR+BT2020
09:34pq: hard to tell - but hey, I have a colorimeter now, I could measure. But more important things first. OTOH, do I even care about this one monitor, it seems kinda broken anyway.
09:35pq: maybe my eyes are right, and I just don't have a WCG monitor to test with yet
09:35pq: one that would actually do something with "Colorspace"
10:01JEEB: I know that there are display p3 non-hdr wcg displays at the very least, but I have no idea if they actually take that value for primaries in via the pipe, or was it always a case of the signal over the pipe being unmapped and the configuration of the interpretation of the signal on the display and the OS compositor output just need to be manually matched
10:03pq: EDID supports codifying both kinds :-p
10:05pq: OTOH, if you buy a WCG monitor, why would you run it in sRGB mode which denies access to the WCG.
10:08pq: my guess is that all variations exist, and many that we cannot even imagine
16:14emersion: so "target color volume" is a more generic term for "mastering display color volume"?
16:15emersion: what about the color volume of the display a compositor pushes pictures to?
16:15emersion: a display*
16:16emersion: is there a reason why the protocol uses "mastering display color volume" in some places, and "target color volume" in others?
16:17emersion: replying to myself for the first question: yes, second question: also target color volume
18:31emersion: zamundaaa[m]: re libdisplay-info device tag, what is your opinion on the status quo?
18:54zamundaaa[m]: emersion: I'm still not super convinced about the special characters thing, but that's not a blocker for me
18:55zamundaaa[m]: We do still have the fallback for EDID hashes if everything else fails, so I think we could still use that as is
21:37emersion: ack
21:38emersion: hm so
21:38emersion: i'm trying a simple SDR→HDR conversion
21:38emersion: basically just a multiplier
21:39emersion: still haven't figured out a good multiplier, but also, it seems like the reds are pink-ish
21:39emersion: other colors are fine
21:39emersion: i've double-checked my TF and matrices against references
21:40emersion: any idea what might be going on?
21:42zamundaaa[m]: emersion: my recommendation would be to write a test and check the numbers before anything else
21:43zamundaaa[m]: Or at least check with gamescope or Plasma on the same display, to rule it out as the source of the problem
21:44emersion: i tested by forwarding directly the HDR video + metadata straight to the display, and it looked fine that way
21:46zamundaaa[m]: okay
21:48zamundaaa[m]: Without the multiplier, things work fine though, everything's just a bit darker?