00:19 Company: Riolku: in terms of graphics it has a few advantages over unsigned 16bit
00:19 Company: first: 16bit is better than 32bit (and real floats) because you only need half the bandwidth
00:20 Company: but you need better than 8bit if you do HDR graphics, because with 8bit errors get too big
00:20 Company: float naturally fits, because GPUs operate with floats, so you don't need to do the mapping between 0..1 and 0..65535
00:21 Company: and you have the benefit that you can over- and underflow floats (again, useful with HDR)
00:22 Company: and you get the benefit that you don't need the gamma correction that's usually done to get more values in the dark regions
00:22 Company: because small numbers in float representations are closer
00:36 Riolku: oh, huh
00:36 Riolku: ty for the explanation 😄
01:34 danieldg: it's particularly useful if you want to operate in a linear colorspace (most drawing algorithms assume that) instead of srgb which is normal for 8bit things
01:35 danieldg: ah, you already said that, nvm
02:24 Riolku: ah, because it's a closed field over multiplication?
02:33 RAOF: No (it's not closed over multiplication), but because the gamma function is used to make the 8-bit range approximately _perceptually_ linear (so you don't lose perceptual precision in the dark bits). You don't need to make a float representation perceptually linear to do that, because it naturally has more precision close to 0 _and_ it's got enough precision that you don't have to care.
02:37 Company: and perceptually linear means that it's not linear, so all the math operations are slightly off
08:06 pq: Gamma *correction* is a different operation than gamma encoding AFAIU. I believe correction is about adjusting values, while encoding is just a form of data compression to use less bandwidth for the same level of visible errors.
08:07 pq: both can be applied with the same mathematical formula with just a different exponent, but the semantics are very different.
08:08 pq: "Linear" is always relative to something else. We just tend to use a shorthand "linear" for "radiometrically/optically linear".
08:10 pq: Perceptually linear is linear wrt. perception, but perception is not linear wrt. radiometry (measured energy).
08:12 pq: If you want to learn about "gamma", see the link at https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/learn.md#frequently-asked-questions-about-gamma
08:15 pq: yes, it does define gamma correction as encoding, but see also the mentions of end-to-end power function.
08:16 kennylevinsen: sometimes I just think color screens were a mistake
08:17 pq: good that this gamma thing is not about color, it applies to black&white images :-)
08:17 pq: or gray-scale
08:17 kennylevinsen: true, but imagine how much easier CMS would be in monochrome :)
08:18 pq: that would certainly put some hard limits in what can be done at all
08:21 pq: if you think gamma of today is confusing, look at question 14 "How is gamma handled in video, computer graphics, and desktop composuting?" ;-)
08:23 pq: Then notice the sentence: "It is conventional in computer graphics to store linear-light values in the framebuffer"
08:24 emersion: yikes
08:25 pq: Yeah, that was forgotten over the decades because in 8 bit would look kinda bad in today's, or event the 00s, standards.
08:27 pq: Definitely good to keep in mind that the GammaFAQ was written in the 90s. :-)
08:29 pq: Do you happen to remember issues like "Quake on X11 looks far too dark" from the 90s?
08:29 pq: or was it already 00s
08:31 pq: I can guess that the game rendered in linear light and expected the winsys to do the gamma encoding for display. Which would make all other apps that were authored directly into display-compatible pixels look washed out and wrong.
08:54 Ermine: So, GammaFAQ is irrelevant?
08:57 pq: No, it's not.
08:57 JEEB: pq: oooh, so that is why there were those differences. some APIs letting you leaving the transfer function handling to the OS and letting you just handle linear
08:57 pq: History is important in trying to understand what different people and writings could mean with "gamma".
08:58 pq: also the principles of physics and human perception have not changed
08:59 pq: JEEB, and some APIs implying you apply *part* of the transfer function, the OS applying another part, and the display more or less undoing both.
09:00 JEEB: that sounds like fun.jpg
09:00 pq: JEEB, see that question 14. :-)
09:00 pq: it has diagrams
09:02 JEEB: nice PDF :D
10:12 wlb: wayland-protocols/main: Sebastian Wick * security-context-v1: Make sandbox engine names use reverse-DNS https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/999e4437730f staging/security-context/ engines.md security-context-v1.xml
10:12 wlb: wayland-protocols Merge request !253 merged \o/ (security-context-v1: Make sandbox engine names use reverse-DNS https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/253)
12:19 pq: swick[m], I still don't know what timezone carlosg used for the Wayland governance meeting time poll for Oct 31 / Nov 1. Do you?
12:29 swick[m]: pq: just talked with carlos and we're going with CET ;)
16:06 nniro: Hello, I've seen in the docs that it is possible to output the "Flight recorder" data in weston using some keyboard entry. I have tried to do it but never got any special output as a result. I basically want to debug kiosk-shell and see what events are triggered.
16:10 nniro: I really don't know what to expect from this "Flight recorder"... I just wanted to avoid having to put fprintf calls all over the code to figure what is happening during various events
16:11 mvlad: nniro, the flight recorder logs in by default two log scopes, log (the weston logs), and the drm-backend.
16:12 mvlad: you can use weston_log() instead of fprintf and everything will go to the "log", log scope - which is also dumped by default.
16:13 nniro: mvlad: ok, thanks
16:13 mvlad: nniro, if can create a dedicated log scope, (like kiosk-shell-debug-scope) where and you can tell weston just to display that. weston_log() will basically disseminate the messages to all log scopes that you have subscribed to.
16:14 mvlad: nniro, there's some docs at https://wayland.pages.freedesktop.org/weston/toc/libweston/log.html
16:14 mvlad: alternative search for other log scopes and see how those are created.
16:19 nniro: mvlad: I've been working on my MR #1374 and as I was switching virtual terminal, I noticed the focus is not regained. The only way I manage to recover focus is by using my mouse and click anywhere. I thought I could try to help and fix that issue
16:23 mvlad: nniro, btw, seems like you need to re-push your changes. fdo org had some issues yesterday and some of commits/push have been lost.
16:26 mvlad: nniro, wrt to input focus maybe that due to enter/leave events? What backend do you run weston on? For wayland protocol there's a dedicated log scope, called proto. If you start weston with --debug then you can weston-debug -a which would basically subscribe to all log scopes currently available, maybe one of that might be useful to you (alternative you'd have to create one yourself).
16:26 nniro: mvlad: oh, ok thanks
16:26 nniro: mvlad: I'm on a raspberry pi, using the drm backend
16:27 mvlad: so you basically switch between ttys?
16:27 nniro: yes
16:28 mvlad: and you loose input focus when you get back... more like something related to input.
16:30 nniro: [2023-10-24 12:30:11.301][proto] client 0xaaaafda90f50 (PID 1958741) ev wl_seat@9.capabilities(0)
16:30 nniro: [2023-10-24 12:30:11.301][proto] client 0xaaaafda90f50 (PID 1958741) rq wl_keyboard@14.release()
16:30 nniro: [2023-10-24 12:30:11.301][proto] client 0xaaaafda90f50 (PID 1958741) ev wl_display@1.delete_id(14)
16:31 nniro: I didn't expect to see a "delete" there :)
16:35 nniro: ok so it seems when I clicked after losing the focus, it re-enabled seat and activated the session
16:35 nniro: mvlad: I always figured how to use weston-debug, thanks for the pointers :), it's great
16:35 nniro: figured/wondered