08:53 ukiran: pq, this is regarding the color management protocol
08:53 ukiran: we are planning to work on the color space conversion except HDR. we dont want to do any tonemapping.
08:54 ukiran: current plan is to do the colorimetry conversions
08:56 ukiran: i had gone through the color-management protocol and based on my understanding, image-descriptor is used either by the clients or compositor to know about the color properties.
08:56 ukiran: this image-descriptor can be created from the output or from the icc file or the parameters provided by the client
08:58 ukiran: I have some questions related to this \n 1. What is pending in the protocol implementation w.r.t colorspace ( not including HDR here)
08:58 ukiran: 2. Any clients implemented using this protocol ?
09:03 ukiran: 3. In the last discussion, you said that though the monitor EDID says "it claims the display support HDR, but fails to provide *any* HDR parameters." What is the decision to take in this case ?
09:44 ukiran: could someone please help to clarify my doubts ?
11:20 pq: ukiran, I don't remember off the top of my head. Rendering intent might be one of the missing things, but for ICC workflow, I don't think it's missing much. Maybe something in the image description events is missing.
11:21 pq: ukiran, no implementations have appeared in the past couple of weeks, no.
11:23 pq: ukiran85, well, if the monitor EDID is lacking, we have to guess something and let the end user override. There may or may not be some best practices documented by ITU-T or something, but I suppose it usually falls to just picking a video standard and hoping the monitor does something sensible with it.
11:24 pq: ukiran85, FWIW, color-representation Wayland extension is ready for implementors, while color-management is not.
11:25 pq: obviously it doesn't do the same thing at all, but it's really useful for video content
12:17 ukiran: pq, hello
12:20 pq: ukiran, yes?
12:21 ukiran: we are planning to work on the color space conversion except HDR. we dont want to do any tonemapping.
12:21 ukiran: hope you have see my earlier msgs
12:22 pq: yes, I replied
12:22 ukiran: am really sorry
12:22 pq: https://oftc.irclog.whitequark.org/wayland/2023-02-08
12:22 ukiran: let me go through them
12:23 JEEB: ukiran: i would consider clip() a method of tone/gamut mapping ;)
12:24 ukiran: JEEB, sorry, i did not get you :)
12:27 JEEB: basically if you are dealing with just wider or narrow gamuts (leaving out transfers since you said no HDR), some sort of mapping still needs to happen, and clipping on out of gamut is 100% valid as a method
12:27 JEEB: pretty sure also windows only does clip based mapping :)
12:28 JEEB: (as far as compositor goes)
12:28 pq: valid and valid... it does produce displayable numbers at least :-D
12:30 ukiran: JEEB, Noted it..
12:32 ukiran: pq, how does color represetnation wayland extension is different from color management ?
12:32 ukiran: any reference to go through ?
12:34 pq: ukiran, it's completely orthogonal.
12:34 pq: ukiran, https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/183
12:34 JEEB: pq: it was fun to see the difference coding the same content as just wide gamut P3 and then adding a HDR transfer into the mix 8)
12:34 JEEB: image viewers usually do clip()
12:34 JEEB: then for the HDR tone/gamut mapping started to happen
12:37 pq: JEEB, heh. Going from "RGB is just RGB, huh?" to "hmm, this actually needs some processing..."? :-)
12:43 JEEB: pq: more or less yea :)
12:44 JEEB: mastering people usually want their displays to clip since trying to master content with a dynamically changing result can be challenging
12:45 pq: haha, yeah, obvious once you say it out loud
12:46 pq: Do they like to highlight out-of-gamut pixels as well?
12:46 JEEB: yea, I think someone wrote a shader for that for mpv
12:47 pq: or will they actually rely on the clipping so much that out-of-mastering-gamut values end up in the final product?
12:47 JEEB: yes. they do
12:47 JEEB: mad max fury road is a good example
12:47 JEEB: max brightness in one scene is ~9000 nits
12:47 JEEB: a really small bit but still
12:47 pq: soo... video players need to hard-clip to the mastering display parameters?
12:48 JEEB: essentially that's used as tone/gamut mapping hint yea
12:48 JEEB: "the mastering person didn't see this either, so let's not care"
12:48 JEEB: which is why content colour volume and mastering display colour volume are two different things
12:48 JEEB: I would have loved for the metadata being called display hint
12:49 pq: I mean literally clip to get the visuals from the mastering process, and not just a hint
12:49 ukiran85: pq, i will go through the given MR
12:49 JEEB: pq: well yea, that is what I mean as a hint. :)
12:50 JEEB: also the name of that metadata confused me for a good few years
12:50 JEEB: "why do we care about the mastering metadata"
12:50 JEEB: *mastering display
12:50 JEEB: also I'm pretty sure I wasn't alone since someone used that metadata block as description for custom primaries etc in the FFmpeg decoder
12:50 JEEB: *FFmpeg png decoder
12:51 JEEB: while it is not a description for content interpretation but content display
12:51 pq: JEEB, if everything needs to be clipped to the mastering color volume, what do we need the content color volume for? After we clip, we can only have up to the mastering... oooh
12:52 pq: nope, didn't get it :-)
12:53 pq: what colorspace do you clip in and how?
12:58 JEEB: plain output clip can be thought as when doing the final part of conversion to output space (f.ex. keeping values between your output's 0,1 instead of values outside that range). then for doing general nit etc based stuff you probably want to do that during the transformation.
12:59 JEEB: been a good while since I last checked libplacebo's handling of this stuff :)
13:08 ukiran85: pq, looks like there is no support for color-representation protocol in weston compositor
13:08 ukiran85: who wants to use that, they need to add the support
13:40 pq: ukiran85, I said color-representation is ready to be implemented, meaning that we happy with its design right now. It has not been implemented yet, and color-management we are not even happy with yet.
14:02 emersion: jadahl, daniels: any objections to this? https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/220
14:02 emersion: to landing this*
14:06 daniels: emersion: if it looked good to me a month ago, it probably doesn't look bad a month later :P go for it
14:40 swick[m]: JEEB: so the metadata jsut describes the mastering display but the stream might still contain content exceeding the mastering display capabilities?
14:58 pq: swick[m], that's what they said. Would be interesting to know if it's supposed to clip in a specific way, not clip if the display can show it, or is it just undefined/dontcare what happens.
14:59 pq: or, a bug in the production
15:41 swick[m]: the question really is if there is metadata for the actual content and not just for the mastering display then
15:42 swick[m]: if there isn't we would have to assume that the entire encoding space could contain data or analyse the data to figure out what is contained which is also horrible
15:43 swick[m]: so really just clipping at the mastering display seems the right thing to do for desktops but TVs and video players could analyse the content if they want ti
15:50 haasn: swick[m]: this is what HDR10+ dynamic metadata is for
15:50 haasn: It contains a histogram and measurements of the maximum and average
15:50 haasn: And also more information about how it appeared on the mastering display
15:51 swick[m]: ahhh, right. already forgot most of that...
15:51 haasn: And a reference tonemapping curve provided by the mastering engineer
15:51 haasn: No information about the gamut content though
15:51 haasn: But for that at least the handling is more straightforward
15:51 haasn: (Just clip)
15:52 JEEB: there is content colour volume SEI defined as well as an mp4 structure for it
15:52 JEEB: not sure what utilizes it at all
15:52 JEEB: has both brightness as well as primaries
15:54 JEEB: the actually utilized content light level SEI message contains max and max average
15:55 swick[m]: btw do any of you know about the SMBT mode in HDMI 2.1a and if VESA has something similar?
16:40 jadahl: emersion: the only disappointing part of that mr at its current state is that one can't reconfigure a xdg_toplevel and set a new preferred scale atomically (e.g. to move a maximized window to another monitor)
16:41 emersion: jadahl: there is another MR which does this
16:41 emersion: the ordering doesn't matter much, one can come before the other
16:41 emersion: the wl_surface.configure MR has unanswered questions
16:41 jadahl: ah, we decided to deal with that with wl_surface.configure
16:42 kennylevinsen: yeah that would be good as it can affect the fractional scaling protocol as well
16:42 jadahl: then at least there is a path towards atomicity then, so no objection from me
16:42 emersion: well, that's my suggested solution at least
16:42 emersion: if you have other ideas, or think wl_surface.configure is a bad idea, then we can always discuss
16:44 jadahl: i think wl_surface.configure is a good idea
16:44 jadahl: just need to figure out the details
16:45 emersion: yeah, the devil is always in the details
16:45 emersion: ok cool, thanks for the feedback
16:46 marler8997: well I've got an update on the "input shape region" bug I was seeing. Looks like the gromit-mpx app was working because they just so happen to change their "app indicator" icon whenever they update the "input shape region" which causes the wayland compositor to take the new input shape region. If you don't update your app indicator icon, the "input shape region" update won't take affect. Bleh
17:15 kennylevinsen: app indicator icon?
17:58 wlb: wayland Issue #271 closed \o/ (Introduce wl_surface.configure_scale https://gitlab.freedesktop.org/wayland/wayland/-/issues/271)
17:58 wlb: wayland/main: Simon Ser * protocol: add wl_surface.preferred_buffer_scale https://gitlab.freedesktop.org/wayland/wayland/commit/9afab91d2121 protocol/wayland.xml
17:58 wlb: wayland/main: Simon Ser * protocol: add wl_surface.preferred_buffer_transform https://gitlab.freedesktop.org/wayland/wayland/commit/d443241635cf protocol/wayland.xml
17:58 wlb: wayland Merge request !220 merged \o/ (protocol: add wl_surface.preferred_buffer_scale and transform https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/220)
18:12 ifreund: \o/