08:30 kennylevinsen: pq: random question, any colorimeter recommendations? :)
08:41 pq: kennylevinsen, I don't know yet. I've been meaning to figure out one to buy myself.
11:54 pq: Kinda eye-opening and the opposite of enlightening to see that a shade of cyan stimulus looking cyan in isolation, and red when in the context of a specific picture.
11:57 pq: Likewise the immediate surrounds causing gradient patterns to be perceived where there is none.
12:54 kennylevinsen: pq: Reminds me of brown vs. orange, which is entirely contextual
12:54 kennylevinsen: although cyan to red seems more extreme
12:58 pq: https://mathstodon.xyz/@TonyVladusich/112356248281984632
14:36 kennylevinsen: pq: hmm, feel like there's some trickery - the parts of the left image that match the truly red sections in the right are actually neutral grey according to my browser's color picker
14:36 kennylevinsen: #808080 and slight variations thereof
14:40 pq: quite possible, I'm just going by what they said
14:43 kennylevinsen: yeah just got curious as the illusion felt too strong, and then got confused by the actual colors present not really matching what the post said :/
14:44 pq: maybe *that* was the illusion :-D
14:50 Company: or your browser does color correction wrong ;)
14:52 kennylevinsen: If it is doing color correction it is definitely doing it wrong right now, without any color management support in my compositor, without a calibrated screen and most importantly, with a known trash screen that doesn't even cover sRGB :P
14:52 Company: that reminds me
14:53 Company: taking screenshots - how are you doing that with HDR?
14:53 kennylevinsen: but "the whole image has an even blue tint that the human white balance management at least partially cancels" makes a lot of sense explanation-wise
14:53 Company: add the icc profile to the PNG? or the cicp?
14:53 pq: luckily color precision does not matter much, the relativity of color is still observable: it depends a lot on the surroundings i.e. context
14:54 kennylevinsen: which of course explains the context dependence - you need enough *other* blue tint to percieve a white balance rather than just a color...
14:54 kennylevinsen: But in his cropped hand with can, I still see a (tinted) red can, not a cyan one, so the hand seems to be enough.
14:55 pq: Company, I don't know yet what file format would be nice for HDR screenshots. Could also map to sRGB for wider consumption.
14:55 Company: pq: the problem with mapping to sRGB is that it makes bug reporting hard
14:55 JEEB: PNG has CICP at least nowadays
14:55 pq: ah, bug reporting
14:55 Company: I had a discussion about that with swick at some point
14:56 Company: and I think we agreed on using PNG and the relevant chunks
14:56 Company: but I think we didn't check browser support yet
14:56 pq: PNG+CICP sounds nice, maybe add also some comment fields to give more details of the display for debug purposes
14:57 pq: your HDR metadata should be somewhere
14:57 Company: ideally you want to see in gitlab screenies what the other people see, assuming you both have HDR with the same (or very similar) gamut
14:57 JEEB: CLL+MDCV are also in PNG
14:58 Company: https://w3c.github.io/PNG-spec/ exists these days
14:58 Company: but I have no clue how wide all those new chunks are supported
14:59 pq: Company, I suspect that ideal might be ways off still. I'd recommend your own inspection tool to be sure.
14:59 Company: yeah
14:59 Company: I just want to make sure we agree on the goal
14:59 Company: so that all our tools converge
14:59 JEEB: FFmpeg at least seems to have read/write support for those so decoded frames via it should have the necessary metadata
14:59 Company: and then we can go pester browser authors
15:00 JEEB: browsers etc are a separate discussion, o' course
15:00 Company: I use gimp for most of my render debugging, that's gonna be a challenge
15:00 JEEB: ah
15:00 Company: not mthe file format, but getting it to render correctly
15:02 JEEB: yea, at least CICP is standardized so the only thing that's not-really is how to map that to your screen 8) (gamut, tone mapping). although there's that ITU document, but still everyone has their own favourite way of doing it (D and Samsung also came up with their own things for ST 2094 dynamic tone mapping metadata specs)
15:03 Company: I'm actually not too worried about that - we're probably all gonna agree on something and then implement it
15:03 JEEB: yeh
15:03 pq: it's kinda impossible to see what they saw on their monitor, because it's impossible to know what their monitor did to the pixels
15:03 JEEB: more or less, yea
15:04 Company: because it's more practical to agree on something than everyone doing something else
15:04 JEEB: yea, having a baseline mode that's available is a good thing
15:04 Company: pq: they're gonna take smartphone photos!
15:04 JEEB: and I want to stab display manufacturers for not including a simple clip-like mode
15:05 Company: I worry more about getting consistent output to the cable
15:05 pq: Company, that could go horribly distorted, or it could be quite good in demonstrating a problem. Or anything in between. A screenshot is different, not necessarily better.
15:06 Company: so that users don't end up with "looks good on fullscreen in kde, but not gnome and if not fullscreen it's okay in gnome but in kde it looks washed out and in sway it's both kinda red-tinted and hyprland is too blue"
15:06 pq: JEEB, SBTM is coming, right?
15:07 zamundaaa[m]: Company fullscreen or not doesn't make any difference in KWin. I'd be surprised if you do something else in Mutter
15:07 JEEB: pq: it's a thing but I have no idea what the effectively means
15:07 zamundaaa[m]: about capturing the HDR output of a screen with a phone camera, that really doesn't work well at all
15:08 zamundaaa[m]: I've tried it before
15:09 pq: btw. about browsers: https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1758462103
15:09 JEEB: right, that ticket where browser people notice the wonders of wide gamut and HDR
15:09 pq: it's about css colors, so not quite about png
15:10 JEEB: yea, but related. trying to map gamut/tone
15:10 pq: well, forgetting to map :-)
15:10 JEEB: 8)
15:11 Company: zamundaaa[m]: I don't know what Kwin does, but I was thinking that it's possible that the preferred colorspace for apps changes between direct scanout and not and then things might change about who does tone mapping
15:11 Company: and I have no idea what mutter does, that's in some branches I haven't looked at
15:12 zamundaaa[m]: If any visual thing changes between putting a client buffer on a plane and compositing it, then that's a pretty bad compositor bug
15:12 Company: dunno
15:13 pq: zamundaaa[m], it could be desireable for transition to/from fullscreen, though.
15:13 Company: if the compositor decides to advertise some well known colorspace and then tone-map to the one supported by the monitor
15:13 pq: some people seem pretty interested in HDR metadata pass-through
15:13 Company: that might be different when fullscreen and advertising the monitor's colorspace directly to the app and letting the app tone-map
15:14 zamundaaa[m]: pq: yeah, but I like to pretend those people don't exist
15:14 pq: haha
15:14 pq: I've already been asked to do that on Weston at some point.
15:15 pq: as much as it pains me, but it'll be an option
15:15 Company: if you pass through the metadata, who does the conversion then? The kernel? The monitor itself?
15:15 pq: the monitor itself
15:15 JEEB: ^
15:15 Company: hahahahaha
15:15 pq: which means... yes, exactly that
15:15 Company: yeah, that's not gonna look different at all
15:16 JEEB: that goes for all HDR outptu at this point on the display :
15:16 JEEB: :D
15:16 pq: well, if that change coincides with the window state transition to/from fullscreen which is visually jarring anyway, it might not be that visible
15:16 JEEB: output the same BT.2020 + PQ RGB to three displays and find all of them mapping it differently
15:17 Company: pq: for moving images, maybe not - if I'm authoring/debugging an image, I'm gonna notice
15:18 Company: also, there's always 3 types of users: the 95% who don't notice, the 4% who think they notice something when nothing happens, and the 1% of actual experts
15:18 pq: sure
15:19 pq: if you're authoring an HDR image, you're screwed in all cases, right? Because HDR monitors are different, and you didn't buy a mastering device.
15:19 Company: usually those 1% have such a device - or they calibrated their monitor with a colorimeter
15:19 pq: right
15:20 JEEB: I'm still not 100% clear how you calibrate HDR displays, lol
15:20 pq: they know how to buy a monitor that *can* be calibrated
21:09 colinmarc: the factorio devblog (maybe the most high-profile game with a native linux version?) recently did a post about switching from X11 to wayland: https://factorio.com/blog/post/fff-408
21:46 Arnavion: They're not switching. They use SDL which supports both, and the game specifically has run under Wayland just fine for many years via setting the SDL env var. What they did is make a UI to select the SDL backend instead of needing an env var, and remove a different dependency that was explicitly linking to x11 libs
21:48 alice: iirc they added wayland to their sdl build about exactly a year ago
21:48 alice: setting the env before that didn't do anything
21:52 dwfreed: the post mentions the 1.1 version that started supporting wayland
21:52 dwfreed: March 3, 2023 is when that version was released
21:53 Arnavion: Huh, I was sure it was older than that
21:53 Arnavion: Guess I misremembered
21:54 colinmarc: > They're not switching.
21:54 colinmarc: Just used the wrong word. Should've said they wrote a blog post about the challenges they faced adding wayland support
21:55 colinmarc: * > They're not switching.
21:55 colinmarc: Just used the wrong word. Should've said they wrote a blog post about the challenges they faced adding wayland support
23:50 Company: colinmarc: I was most confused about what they did to their text rendering
23:55 Company: I suppose they do integer rounding for the text metrics and positions, but that seems to be an awful lot of difference between scaled up 100% and 125%