00:04 <swick[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:25 <pq> 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:26 <emersion> or a broken EDID? :P

09:26 <pq> sure

09:26 <pq> would be nice to know if EDID has lies...

09:28 <pq> emersion, yeah, monitor manufacturers probably test a few signal configurations and not most possible combinations they claim to support.

09:29 <pq> like my HP monitor engages HDR if (TF=PQ && max_luminance > 100 cd/m²).

09:29 <pq> otherwise it seems like all HDR metadata is ignored

09:31 <pq> but while playing with it, I also found https://gitlab.freedesktop.org/drm/amd/-/issues/3358

09:32 <pq> oh right, that was a HDMI-only bug, and I have it hooked up via DP now

09:33 <pq> but I cannot recall seeing any colorfulness differences between SDR and HDR+BT2020

09:34 <pq> 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:35 <pq> maybe my eyes are right, and I just don't have a WCG monitor to test with yet

09:35 <pq> one that would actually do something with "Colorspace"

10:01 <JEEB> 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:03 <pq> EDID supports codifying both kinds :-p

10:05 <pq> OTOH, if you buy a WCG monitor, why would you run it in sRGB mode which denies access to the WCG.

10:08 <pq> my guess is that all variations exist, and many that we cannot even imagine

16:14 <emersion> so "target color volume" is a more generic term for "mastering display color volume"?

16:15 <emersion> what about the color volume of the display a compositor pushes pictures to?

16:15 <emersion> a display*

16:16 <emersion> is there a reason why the protocol uses "mastering display color volume" in some places, and "target color volume" in others?

16:17 <emersion> replying to myself for the first question: yes, second question: also target color volume

18:31 <emersion> zamundaaa[m]: re libdisplay-info device tag, what is your opinion on the status quo?

18:54 <zamundaaa[m]> emersion: I'm still not super convinced about the special characters thing, but that's not a blocker for me

18:55 <zamundaaa[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:37 <emersion> ack

21:38 <emersion> hm so

21:38 <emersion> i'm trying a simple SDR→HDR conversion

21:38 <emersion> basically just a multiplier

21:39 <emersion> still haven't figured out a good multiplier, but also, it seems like the reds are pink-ish

21:39 <emersion> other colors are fine

21:39 <emersion> i've double-checked my TF and matrices against references

21:40 <emersion> any idea what might be going on?

21:42 <zamundaaa[m]> emersion: my recommendation would be to write a test and check the numbers before anything else

21:43 <zamundaaa[m]> Or at least check with gamescope or Plasma on the same display, to rule it out as the source of the problem

21:44 <emersion> i tested by forwarding directly the HDR video + metadata straight to the display, and it looked fine that way

21:46 <zamundaaa[m]> okay

21:48 <zamundaaa[m]> Without the multiplier, things work fine though, everything's just a bit darker?