10:21wlb: weston/main: Biswapriyo Nath * build: add option to disable tests https://gitlab.freedesktop.org/wayland/weston/commit/51eea1f2657c meson.build meson_options.txt
10:21wlb: weston Merge request !1569 merged \o/ (build: add option to disable tests https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1569)
11:01Company: zamundaaa: stupid matrix bridge has you gone here, and I wanted to just ping you - does this work?
11:05zamundaaa[m]: Company: yes
11:07Company: zamundaaa[m]: 1. I assume you're aware that GTK git main has merged initial support for the color management stuff
11:07Company: zamundaaa[m]: 2. Did I ever ask you about you do screenshots so that the color information is correctly included in them?
11:08Company: because PNG doesn't do float16
11:08Company: and even if, I'm not sure if a screenshotting tool should add cICP chunks to pngs and break 90% of existing apps?
11:09Company: and if there was a solution, I'd want to make sure GTK and the Gnome apps deal with those properly
11:13zamundaaa[m]: 1. yes, and 2. yes
11:13mclasen: make a new mimetype
11:14mclasen: 'png-with-proper-color'
11:14zamundaaa[m]: KWin just maps screenshots and screencasts to sRGB
11:14mclasen: and offer both, 'plain old pn' and 'fancy png'
11:14zamundaaa[m]: But that's mostly out of laziness and not what we want
11:14Company: yeah
11:14Company: I'm trying to write testcases
11:15Company: and we create reference images to compare our rendering against
11:15Company: and I still have no format to create those...
11:15mclasen: have you looked for a cicp tiff chunk ?
11:15Company: briefly
11:16Company: google linked me to color.org pdfs a few times and then I decided I don't wanna know
11:16Company: names like "meeting minutes of..." or "Proposal to..."
11:17Company: but I'm not in the mood to end up in situations where I can't debug the screenshots of my HDR rendering because those screenshots don't describe what's on my screen
11:18Company: so compositors not taking proper screenshots is kind of a blocker to me
11:18Company: it was bad enough with the small bugs that Mutter had with screenshots on fractional scaling
11:19Company: "my text is blurry" - "please post a screenshot" - "here" - "that screenshot isn't blurry" - "it looks blurry on my screen"
11:23Company: I mean, for the GTK testsuite I might be able to get by with PNGs for a while, but that won't work for screenshots
11:23wlb: wayland/main: meltq * src: switch asserts to wl_abort https://gitlab.freedesktop.org/wayland/wayland/commit/0cecde304f4f src/ connection.c event-loop.c wayland-client.c wayland-server.c wayland-shm.c
11:24wlb: wayland Merge request !399 merged \o/ (src: switch asserts to wl_abort https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/399)
11:24Company: zamundaaa[m]: I filed https://github.com/w3c/png/issues/458 btw but it seems nobody is much concerned there
11:25wlb: wayland Issue #230 closed \o/ (Switch asserts to wl_abort https://gitlab.freedesktop.org/wayland/wayland/-/issues/230)
11:27zamundaaa[m]: Company: it's certainly a very annoying issue. Feels like modifier negotiation all over again, but in worse
11:27Company: to me it's somewhat trivial to fix
11:28zamundaaa[m]: Because we can't assume that existing apps don't support any colorspaces or ICC profiles
11:28Company: hdr-enabled PNG providers offer image/png and image/png-with-hdr
11:28mclasen: mime types during dnd are certainly a better negotiation protocol than modifiers
11:28Company: and for image/png they map to srgb and for iamge/png-with-hdr they export full everything
11:29Company: and hdr-enabled readers accept every combination for both mimetypes
11:29mclasen: what you would really want is image/png;colorspace=rec2100-pq, I guess ?
11:29Company: oh god no
11:29Company: now you have a naming game going on
11:30Company: where you need to extend the list every time someone comes up with a new colorspace
11:30mclasen: what exactly would '-with-hdr' indicate ? 'not necessarily srgb' ?
11:30Company: is it dci-p3 or display-p3?
11:30zamundaaa[m]: If you don't do that, you have to add a new mime type each time someone comes up with a new colorspace too
11:30Company: "reader must be capable of understanding and correctly interpreting cICP and iCCP chunks
11:31mclasen: then it should probably be image/png-with-cicp ?
11:31zamundaaa[m]: Because apps wouldn't immediately all add support for all new cicp codes
11:31Company: zamundaaa[m]: not really, you cn read the with-hdr version and fall back to the srgb one if you can't understand it
11:31Company: not optimal, but good enough I'd think
11:34Company: what I'd like to see is an extensions of https://www.w3.org/TR/png-3/#15ConformanceConf that adds a 2nd layer with a new mime type
11:34Company: or image/png?conformance-level=2 or whatever
11:35wlb: wayland Merge request !405 opened by Derek Foreman (derekf) src: Finish assert() clean-up https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/405 [IPC library]
11:35Company: and then you can spec what cicp values are (not) included there and do a level=3 later
11:40Company: mclasen: we're running into this right now I'm realizing - because our to_png() code encodes the colorstate as reliably as possible, and our dnd/copypaste code just calls to_png()
11:40Company: well, after I finish this branch
11:41Company: we'll throw around rec2100-pq pngs from node-editor if you run it in hdr mode I suppose
11:41Company: I wonder what imgur does - I bet it just strips the unknown tags
11:41mclasen: yes
11:56swick[m]: you can add cicp and icc
11:56swick[m]: but at the end of the day, all of that can be ignored by any app
11:57swick[m]: but you could use a false-color ICC profile and the cicp tag if you want to make sure you're looking at something that's actually using the cicp stuff
12:00Company: swick[m]: I mostly want to come up with a solution that doesn't break the world
12:00Company: ie works in practice
12:01Company: where I get a screenshot of the actual contents Mutter creates
12:02Company: like, my assumption is always that when I screenshot the whole screen, I get what Mutter actually composites - or would composite on a one-plane hardware device
12:02Company: I'm aware that this goes wrong for the cursor already
12:02swick[m]: that won't really work because CICP allows you to set e.g. PQ but it doesn't imply any reference white so you just kind of have to assume things follow the bt2100 rec and set it to 203
12:03Company: well yeah, that's where the "png works in the short-term, but..." thing comes in
12:03JEEB: swick[m]: reminds me of the other way, people getting angry FFmpeg nowadays writing CICP into PNG ("why do you do this if nothing reads it?")
12:03JEEB: or well, thankfully it seems to be just one very vocal person
12:03JEEB: who has no other reason than "I hate my PNG headers getting larger :<"
12:04swick[m]: you can either get tiff with all the metadata that won't be displayed correctly by anything except maybe a tool you write for it
12:04Company: which is *better*
12:04Company: because at least I *can* get at the data
12:04Company: I don't mind if it's image/mutter-screenshot-tool
12:04swick[m]: or can get a png with some pre-defined image descriptions that the compositor will have to convert things into
12:05Company: I do mind that it's the actual representation so I can debug it
12:05Company: and attach it to gitlab issues
12:05swick[m]: got it, but the standard png stuff won't cut it then
12:05Company: yeah
12:05Company: I mean, I expect that gitlab will display the images wrong
12:05Company: but it does that already
12:06Company: because stupid browsers scale images
12:06Company: that trips me off so much, that they use linear scaling on 200% screens
12:06JEEB: so what would be wrong with PNG + CICP? I mean, applications that don't support CICP will mis-show it, but at least the coded values should be correct? (unless PNG had some bit depth limitation, but I think >8bit was possible)
12:07swick[m]: JEEB: yeah, a bit painful but a lot of image viewers also ignore ICC, so I'm not sure we should stress too much about bad apps ignoring vital metadata
12:07Company: JEEB: it does 16bit integer, but no float
12:07Company: JEEB: but my concern is literally that you cannot paste a screenshot into gimp
12:07Company: JEEB: without getting busted colors
12:07swick[m]: JEEB: so, what is white in a png tagged with PQ and BT.2020?
12:08JEEB: swick[m]: if you are talking about the interpretation/display of HDR content, that's not defined anyways
12:08JEEB: every application will either leave it to your display hardware, or have its own opinion on how it should be done
12:09JEEB: gamut & tone mapping etc
12:09swick[m]: well yeah, that's the point here. we had to define it in the wayland protocol so we can get a uniform white level
12:09swick[m]: so we have opinions about where the referece/diffuse white level is
12:10swick[m]: and we'll adapt it before we put it on screen because people want to adjust brightness
12:10JEEB: yea, adapting to environment
12:10swick[m]: so if you just put the end result into a png, how does anyone know about all of that?
12:10JEEB: there are some people who don't understand that and then yell if you don't show PQ of 450 nits exactly as 450 nits
12:10swick[m]: yes, one of the worst things about HDR is that exact brainworm
12:12JEEB: right, so there is a difference between application output which is at least some sort of CICP (although already right now if someone has an ICC profile configured in an application it becomes nonstandard), and then compositor or whatever interprets it for display and that's another image that you may or may not want to screenshot.
12:13Company: JEEB: that's possible though, just tell your compositor to do no adjustments?
12:15Company: JEEB: also, compositors can be nested, so if your VM compositor does adjustments to the image, those need to be communicated to the host compositor
12:15Company: so it doesn't (or does) brighten things twice
12:16Company: do we need a cicp tag for the nightlight transfer function and matrix?
12:17zamundaaa[m]: No, night light should not be applied in screenshots
12:17Company: if you use autonightlight, do you actually get it twice - inside the VM and inside the host?
12:17swick[m]: why not?
12:17zamundaaa[m]: and not in nested compositors. Virtual machines are a special case
12:17swick[m]: nightlight just changes the white point
12:18Company: zamundaaa[m]: virtual machines are always how I make sure the stuff anyone comes up with covers all use cases
12:18swick[m]: I've had discussions about this with pekka where he argued it's an "effect" on top of the normal color managed stuff, but for me night light is simply an adjusted white point
12:18zamundaaa[m]: swick: it changes the white point of the output, to do that you need to change the rgb balance
12:18swick[m]: yes
12:18zamundaaa[m]: It doesn't just change the whitepoint of the image
12:18swick[m]: it does
12:20zamundaaa[m]: No, it's not just a change in the color management properties. You can't represent night light with the color management protocol
12:20swick[m]: ofc you can
12:20zamundaaa[m]: Nope. I've implemented this in practice, it does not work
12:20swick[m]: then you did something wrong
12:20zamundaaa[m]: When you apply the chromatic adaptation matrix to change the whitepoint of an image, you don't actually change the whitepoint of the output
12:21zamundaaa[m]: You can only do that by applying factors to the r, g and b channels
12:21mclasen:has a dreadful sense of v5 appearing on the horizon
12:21swick[m]: yes, you change the whitepoint of the image then
12:21swick[m]: but what's the point?
12:22zamundaaa[m]: The point is that if a compositor in a VM applies night light, that's not something the host compositor can take into account
12:22zamundaaa[m]: If both VM and host compositors apply night light, you get it applied twice
12:22swick[m]: that's all true but missing the point
12:22swick[m]: night light changes the white point of the output
12:23Company: so just put it in the icc profile!
12:23zamundaaa[m]: What I'm saying is that you can write the whitepoint of the image into a screenshot, but you can't put the rgb factors in there as well if you want the image to be presented correctly afterwards
12:23swick[m]: if you have a nested compositor, it will either target the adjusted white point of the host compositor or the host compositor will chromatically adapt the output from the nested compositor
12:24swick[m]: what rgb factors?
12:24zamundaaa[m]: The ones you need to make "white" on the actual physical display be a different value
12:24zamundaaa[m]: That's how you change the whitepoint of a display
12:25zamundaaa[m]: Also how it works with ICC profiles and the "calibration" profiling apps do fwiw
12:25swick[m]: why would anyone need to know about them? you change the maximum strength of the green and blue primaries to shift the white point towards red. the image description need to be updated to reflect the new white point.
12:26swick[m]: everything else literally falls out naturally from the color management workflow
12:27zamundaaa[m]: That's exactly what I'm saying - screenshots must not contain these factors, they must only be applied as a post-processing step in the compositor that drives the actual display in the end
12:27swick[m]: yes
12:27zamundaaa[m]: And as long as they don't contain these factors, it all works out
12:27swick[m]: s/post-processing/calibration
12:27zamundaaa[m]: As long as you're not in a VM
12:27Company: it depends on what you want to screenshot really
12:28Company: but usually the assumption is that screenshots look identical on the same monitor
12:28swick[m]: zamundaaa: what factors? the image is encoded according to the image description which has the new white point.
12:28swick[m]: like yes, you're not doing the "calibration" in the image encoding, that's a property of the "display"
12:29swick[m]: but night light means that the image has a different white point
12:29zamundaaa[m]: The "calibration" of the display, yes
12:30zamundaaa[m]: Company wants a data dump of the framebuffer afaiu, not really a screenshot
12:30swick[m]: no, he wants the thing before calibration
12:31zamundaaa[m]: doesn't sound like it
12:31Company: I sometimes want either - but usually I want pre-nightlight, but in the memory format chosen for the output\
12:31Company: ie I'd like 1010102
12:31swick[m]: i.e. a screenshot with the adjusted white point, without the night light calibration
12:31Company: over float16
12:32Company: (or 8888 if that's what the monitor uses)
12:32Company: because when people file issues about banding, I want to see them right there
12:32swick[m]: that's why it's so important to be clear about the concepts. night light should ideally be in the monitor but we basically have to emulate that in the compositor but it still conceptually is part of the monitor calibration
12:33swick[m]: if you're aware of that, things become much clearer and simpler
12:35Company: my assumption is that window screenshots give me what the compositor got from the app (so I can use it to verify what I send)
12:36swick[m]: yeah no
12:36Company: and that screen/monitor screenshots give me something as close to what the compositor sends off
12:36swick[m]: screenshots are tools for users
12:36swick[m]: what you want is a debug interface
12:36Company: so that I can verify what the compositor does with the data
12:37swick[m]: also, if you just want to get the window contents that were send, then why not just take that from the client?
12:37swick[m]: round-tripping through the compositor for that isn't useful
12:38Company: the simple reason is that the compositor can offer that feature for all clients
12:38Company: and the debug reason is that I can verify that the compositor and client actually agree on what was sent
12:39Company: like if GTK thinks it sent RGBA and the compsositor think it receives BGRA, I will get a different screenshot from the compositor than from the client
12:39Company: and the compositor one will be closer to what's displayed on screen
12:40swick[m]: for the output stuff, yes, I agree that could be useful
12:40Company: and again, with fractional scaling it was useful to verify that GTK didn't send blurry text, but something went wrong on the Mutter side
12:40swick[m]: but just sending back the window that you just send us isn't
12:40Company: because the window screenie wasn't blurry
12:42Company: and I imagine the same would be helpful with colorstates - ie if a window screenshot included the cicp data from the client with original data, not the one used by the compositor with some transformation
12:43zamundaaa[m]: That's assuming the client only uses one colorspace
12:43Company: well, one per surface
12:43Company: so as long as you don't composite, send back the original
12:43swick[m]: a window is multiple surfaces, so what now?
12:43Company: that gets tricky with popovers or subsurfaces ofc, but it gets tricky like that already
12:44Company: if I send you 200% surface + subsurface on a 150% screen - do you save that as a 150% screenshot or as a 200% screenshot?
12:45Company: (and I didn't even start yet with the multi-monitor surface examples)
12:47Company: I would expect single-surface screenshots to match the source data as closely as possible, and single-screen screenshots to match the output as closely as possible
12:47Company: ideally with the asumption that displaying the screenshot on the same monitor produces the same output
12:48Company: (that's not what happens with scaled stuff usually though, because PNG encodes no scale)
12:48Company: (or because nobody respectes the dpi tag, if any compositor uses that)
12:50Company: but as an app developer (or toolkit developer to be exact), I have to verify that what the compositor receives from my app is what I expect it to be
12:50Company: and be able to reproduce what the user sees, so I can understand their bug reports
12:52Company: and I don't mind telling them to Ctrl+Alt+PrntScrn if that enables a debug mode to actually get the images I need to do that - but I do need a way to get those images from users
12:52Company: or it will be a lot harder and more frustrating
12:56Company: but it might be useful to come up with a GTK inspector API to show what buffer is attached to the wl_surface
12:57Company: I suppose we haven't done that because it's a GL buffer we don't even have access to
12:57Company: (and in GTK3 X11 doesn't have buffers anyway)
13:59Company: mclasen: swick[m] invited us to spam the protocol issue - with the new features appearing kinda daily, we can write updates all the time :)
13:59swick[m]: hey now, only if they are relevant :P
14:01Company: mclasen: do we actually have a plan about what will be in 4.16 from the protocol side?
14:01mclasen: the default plan is always: whats currently in main
14:02Company: we have our default colorstates, but with the cicp stuff, we're gonna go parametric
14:02Company: because GStreamer will hand us whatever
14:02mclasen: sure, but thats not much more difficult
14:02Company: from a protocol pov it's different
14:03Company: icc profiles is a question of somebody doing a shader for cmsTRANSFORM
14:03Company: and then hooking up everything
14:18Company: JEEB: you having some experience with this ffmpeg cicp png stuff: Do you prefer if apps not knowing about cicp tags would reject the png, or just open it with bad colors?
15:43JoshuaAshton: swick[m]: https://gitlab.freedesktop.org/swick/wayland-protocols/-/merge_requests/78
15:47wlb: wayland-protocols Issue #204 opened by Simon Zeni (bl4ckb0ne) drm-lease-v1: specify withdrawn event for client leasing the connector https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/204
16:36dottedmag: How about .png in sRGB plus a private chunk containing the image in the proper colorspace? trollface.jpg
23:37wlb: weston Issue #935 opened by Linsy King (linsyking) weston fails to start drm session https://gitlab.freedesktop.org/wayland/weston/-/issues/935