01:37ezzieyguywuf: whot: ah sounds good thanks for the clarification
10:09pq: Color-management is about land today. I'll get lunch now, and hope my suggestion for the commit message is ok.
10:09pq: *about to
10:10JEEB: nice
10:10pq: swick[m], emersion, zamundaaa[m], Drakulix, ^
10:10emersion: \o/
10:11emersion: yeah completely fine by me
10:11MrCooper: would make my day!
10:14pq: I want to keep swick as the patch author, will see how gitlab agrees. hmm... maybe I should do everything locally rather than try my luck with the gitlab UI.
10:15pq: I'll update the history branch before squashing
10:15swick[m]: mh, can you give me like half an hour to prepare for this occasion? :)
10:15emersion: yeah, probably safer to do everything locally
10:16pq: swick[m], my lunch takes like an hour, so sure :-D
10:16pq: bbl
10:16swick[m]: nice! I'll have to prepare something :D
10:23Drakulix: now that is truly special occasion! how are we celebrating? :D
11:00dwt: Nice work :-)
11:08wlb: wayland-protocols/history/color-management: Pekka Paalanen * color: TF bt1886 implies BT.2035 lum https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/b2d34dd61de6 staging/color-management/color-management-v1.xml
11:08wlb: wayland-protocols/history/color-management: Pekka Paalanen * color: define global_remove behavior https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/f284a0cb8518 staging/color-management/color-management-v1.xml
11:09pq: That's the history branch complete now.
11:12wlb: weston Issue #994 opened by John Frankish (juanitotc) Weston gives multiple broken pipe errors in terminal emulators https://gitlab.freedesktop.org/wayland/weston/-/issues/994
11:13zzag: pq: depending how much other people were involved, Co-authored-by: can be also added to preserve some authorship information
11:13zzag: but it's a minor thing I guess
11:14pq: zzag, I was thinking of collecting all the S-o-b's, that's fine, right?
11:15pq: there have been tons of people involved who just didn't write a patch though, and I don't think I can collect them all fairly
11:16zzag: I believe signed-off-by has different semantics.. https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors
11:17zzag: pq: I assume that the color management protocol is mainly a brainchild of Sebastian, you, and Xaver?
11:18pq: it is different, I can check the author list, too. There 13 unique person S-o-b's.
11:18pq: zzag, depends on how one counts. It all started years before Sebastian opened the MR we are now landing.
11:56pq: swick[m], squash done and pushed.
11:56swick[m]: I've got my baklava and saffron chai ready
11:57pq: Clicked "rebase"... now's the time to fail CI.
11:58pq: zzag, do you think the attributions are fair enough?
12:03swick[m]: Co-Authored would be more appropriate IMO
12:05pq: I checked the commit author list, and it matches the s-o-b list, so I can replace those, but what about those who are in neither list?
12:05pq: We have Erwin Burema in the copyrights at least.
12:13pq: swick[m], updated.
12:16swick[m]: yup, looks great
12:17pq: Thanks!
12:17swick[m]: commit message: It's using # for the heading, but the history heading isn't
12:18pq: I noticed, forgot, and too late :-p
12:19wlb: wayland-protocols/main: Sebastian Wick * staging: add color-management protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/452e943b4991 staging/color-management/README staging/color-management/color-management-v1.xml meson.build
12:20llyyr: \o/
12:20wlb: wayland-protocols Merge request !14 merged \o/ (staging: add color management protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14)
12:20llyyr: congrats everyone
12:20zamundaaa[m]: 🎉
12:20pq: swick[m], you have quite some merged branches left over in your repo. :-)
12:21llyyr: new release to go with it?
12:21swick[m]: yay
12:22pq: let's see what last minute boogs we find first now that's landed ;-)
12:29pq: 820 comments on the MR itself, and that's surely just a fraction of all the related gitlab discussions.
12:32pq: swick[m], did you have a blog post ready and waiting?
12:34swick[m]: no
12:35swick[m]: thought about doing it but kind of forgot
12:40pq: I kinda knew I should have, but didn't.
12:40pq: for Collabora
12:43mupuf: pq: what's a one day delay for a 5 year old MR anyway :D
12:44mupuf: jokes aside, this is fantastic news guys! Congrats!
12:45pq: Thank you swick[m] for starting the MR that finally made it.
12:46swick[m]: we were in this together :)
12:47pq: I recall that was a time period when I couldn't afford to do it myself.
12:47swick[m]: but yeah, the 5 years doesn't capture the entire journey
12:48daniels: time for a new window system now
12:49bl4ckb0ne: can we work on client position now /s
12:50Ermine: Yay, congrats!
12:51pq: Is there a better search interface to wayland-devel mailing list archive than the Google link of mailman?
12:51vyivel: i wish
12:57pq: eh... specifying a timespan of 2000-2026 has practically no google hits
12:57pq: remove the timespan and there are tons of hits
12:58MrCooper: congrats everyone! I remember thinking "HDR / colour management is just around the corner" before I left AMD some 6 years ago :)
12:58pq: gradient fields
12:59daniels: pq: things sure got complicated from the glory days of https://people.collabora.com/~pq/wayland-color-management-proposal.png
12:59daniels: from https://lists.freedesktop.org/archives/wayland-devel/2012-May/003410.html
13:01daniels: https://lists.freedesktop.org/archives/wayland-devel/2014-March/013959.html:
13:01daniels: > Compared to that, I see your protocol adds the option for clients to provide a custom ICC profile to the server, and expects the server to process it properly.
13:01daniels: > Is that a reasonable requirement for all compositors that support per-output ICC profiles?
13:01pq: 2012, eh. Huh. Not even the first full year at Collabora even, and I knew nothing of Wayland before joining.
13:02daniels: https://lists.freedesktop.org/archives/wayland-devel/2014-November/018585.html
13:02daniels: > The protocol looks simple and clean, like it should be. I can't really comment on the deeper semantics on color management, though.
13:03swick[m]: heh, who can anyways :P
13:05daniels: you've been on the internet right
13:09pq: Niels Ole Salscheider should really have been credited.
13:12daniels: yeah, maybe a retroactive update for Niels would be good, given all his work which sadly went nowhere
13:13swick[m]: pq: btw, css-color-hdr got updated recently https://github.com/w3c/csswg-drafts/commits/main/css-color-hdr-1 https://github.com/w3c/csswg-drafts/issues/10460#issuecomment-2654704770
13:13swick[m]: didn't yet have time to take a closer look
13:13pq: daniels, maybe mentioning him in the protocol README file?
13:15pq: let's see what I can type up
13:18karolherbst: just want to say big congrats to everybody involved with the protocol, glad to see it landing, hopefully when I buy my next display with proper HDR support I can make good use of it
13:32wlb: wayland-protocols Merge request !382 opened by Pekka Paalanen (pq) staging/color-management: credit Niels https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/382
14:13Drakulix: 🎉
14:27soreau: so in the future, monitors are broken and they need software fixes? :P
14:27soreau: at least something made it past the finish line, hopefully it works out 👍
14:29daniels: *in the present and in fact always
14:31pq: all printers and scanners and cameras have already needed them for as long as they have existed
14:33vsyrjala: i don't think any non-broken monitors have existed since we gave up on crts
14:33pq: only computer monitors specifically had an era when practically all of them were close enough to sRGB that the differences didn't matter, unless you worked in the print industry.
14:34DemiMarie: pq: Is that because of the physics of CRTs?
14:35daniels: always and forever: https://www.mail-archive.com/devel@lists.fedoraproject.org/msg32635.html
14:36kennylevinsen: vsyrjala: also not before
14:36pq: DemiMarie, I guess partly that, and partly the industry wanting to standardise around sRGB, because managing color was expensive.
14:36DemiMarie: Expensive?
14:37pq: CPU time, memory
14:37DemiMarie: Are those still issues?
14:37pq: they can be if you use high enough resolution and low enough hardware - but at least capable hardware exists
14:38pq: unlike, say, in 1998
14:38pq: AFAIU, sRGB was born from the desire to show images through the Internet.
14:43kennylevinsen: huh, didn't know that NTSC is closer to P3 in volume than it is to sRGB - although I doubt many monitors existed that could get near that
14:46JEEB: I did laugh out loud as I noticed recently display companies instead of sRGB started talking about NTSC gamut capabilities
14:47JEEB: NTSC... in <current_year>
14:47pq: xvYCC next? or how does that compare?
14:47pq: old is the new new
14:48JEEB: oh right, xvYCC was the thing where they noticed that in video they were not utilizing all the value range in digital video
14:49JEEB: so they allowed chroma to go 1-254 :D
14:50JEEB: also this probably is from where the definition of full range chroma comes from in BT.2100
14:50JEEB: although technically that maps to 1-255 in 8bit
14:51JEEB: and yea, according to wikipedia it literally keeps the same primaries definition as BT.709
14:52JEEB: so the only difference is that you flag the content as limited range, but actually expect chroma to be full range
14:52JEEB: so BT.709 [0,1] map to limited range of 16-240
14:52JEEB: and then 1-15 and 241-254 were utilized to widen the gamut
14:52pq: the chroma breaks out of its old boundaries
14:52JEEB: yea
14:53JEEB: how on earth would you even signal such a coded signal according to H.273
14:53JEEB: since apparently this stuff was put on disc media :D
14:57JEEB: OK, so they gave it a transfer function value indeed
14:58pq: yeah, it's obviously a TF thing, sure
14:59pq: the TF table is more like a systems table
14:59JEEB: not sure, I would have possibly put it into the full/limited range stuff. since the only difference is that you utilize a different range for chroma.
14:59JEEB: but probably the range is a boolean in so many contexts
15:01JEEB: and yes, the TF does affect f.ex. in which order steps should be done
15:14swick[m]: pq: https://drafts.csswg.org/css-color-hdr-1/ small-ish changes (https://github.com/w3c/csswg-drafts/commit/e8f95bd3a33748592d2803905d66e67fc1c58260, https://github.com/w3c/csswg-drafts/commit/60689665e5cdf343bd0f459db870d857dfc7cbbb). Media white anchoring for compositing is defined now; PQ isn't treated as "absolute" anymore. re-rendering for the actual viewing environment is explicitly allowed.
15:14swick[m]: their PQ min luminance still has a non-0 value
15:18pq: swick[m], thanks. I hope next week I might have enough brain to digest that.
15:44wlb: wayland-protocols/main: Pekka Paalanen * staging/color-management: credit Niels https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/b3e507b102ef staging/color-management/README
15:44wlb: wayland-protocols Merge request !382 merged \o/ (staging/color-management: credit Niels https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/382)
17:50wlb: weston Issue #3 closed \o/ (weston_surface_damage does it wrong https://gitlab.freedesktop.org/wayland/weston/-/issues/3)