11:16 <dnkl> rnd: ifreund: benchmark results for the srgb branch compared to the master branch: https://0x0.st/8TWE.txt

11:17 <dnkl> too slow to be useful atm. But if we can offload the final linear -> sRGB translation to the GPU, via the compositor, then I think it'll be useable

11:23 <ifreund> nice, at some point I should try and learn enough about color management to help push things forward on the wlroots side

12:02 <emersion> dnkl: the reason one usually wants to send electrical values instead of optical, is precision

12:03 <emersion> with an 8-bit buffer and optical values you can notice banding

12:06 <emersion> you should be able to tag your content with the "ext_linear" TF if you want to try it out

12:16 <OtzmaVindicus> how does foot choose fonts? does it respect ~/.config/fontconfig/font.conf?

12:16 <OtzmaVindicus> /.config/fontconfig/fonts.conf?

12:16 <OtzmaVindicus> ~

12:17 <dnkl> emersion: thanks! I see there's an open wlroots PR for color management? I assume that's the one I need?

12:17 <dnkl> OtzmaVindicus: via fontconfig, so yes it should respect that. You should be able to verify with e.g fc-match

12:18 <emersion> there is this, but it doesn't support the feature you need: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4962

12:18 <emersion> i can try to hack up something if you want to try it out

12:18 <emersion> (it only supports the HDR toys)

12:18 <emersion> how difficult would it be to use 10-bit, or fp16?

12:19 <OtzmaVindicus> "fc-match x" would tell me the font that letter "x" is displayed in?

12:20 <dnkl> emersion: for the basics, not too hard I think, depending on which pixman primitives are available. There are a few places that write 32-bit ARGB directly, but not a lot.

12:21 <dnkl> if "all" I need to do is set a tag, then yes, I would be interested :)

12:21 <dnkl> it would at the very least tell me if this is something worth pursuing for real, or something I should just drop

12:22 <dnkl> OtzmaVindicus: no, fc-match tells you which font is returned, named x

12:53 <OtzmaVindicus> how to test how a particular symbol is rendered in a particular font?

12:56 <dnkl> assuming it's not part of the primary font, the easiest solution is maybe to run foot with -d info. It'll log the font when it's loaded on demand (i.e the first time a glyph is displayed)

14:13 <emersion> dnkl: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4988

14:13 <emersion> requires WLR_RENDERER=vulkan, and untested

14:17 <dnkl> emersion: thanks, will hopefully be able to test it next week

14:17 <emersion> let me know if you have more questions or run into issues :P

14:18 <dnkl> will do! can't imagine any issues though :)

14:19 <emersion> lol

15:21 <dnkl> emersion: I'm able to create an image description object, with the ext_linear named TF set (and validated by the compositor, since I got a protocol error when I forgot to set the primaries). But later, when trying to get a color_management_surface (to set the description on), I get disconnected. Nothing obvious in the sway logs, and no visible protocol error (could still be one though)

15:21 <dnkl> I'm using wp_color_manager_v1_get_surface()

15:21 <dnkl> it's complex protocol and I'm sure I'm doing something wrong, I just don't see what...

15:22 <emersion> hm, weird that you don't get anything

15:22 <emersion> can you share a WAYLAND_DEBUG log? and to your code?

15:22 <emersion> s/to//

15:25 <dnkl> emersion: wayland log https://0x0.st/8Ty-.log

15:25 <dnkl> binding + image description: https://0x0.st/8Ty-.log

15:25 <dnkl> https://0x0.st/8Tyo.patch

15:25 <dnkl> getting the surface: https://0x0.st/8TyH.patch

15:26 <dnkl> sorry, the patches are out of context...

15:26 <dnkl> I create the image description object at startup, right after binding the color-manager global

15:26 <dnkl> the color-manager-surface is created (or I try to...) when rendering.

15:27 <dnkl> Oh, wait, could it be that I render a second frame and thus try to create a second manager-surface? That's not allowed, right?

15:29 <dnkl> right, that was it. Now it's at least running

15:29 <emersion> hmmm

15:29 <dnkl> and look like it's working!

15:29 <dnkl> that was easier than I thought

15:30 <emersion> i'm still confused why you don't get the protocol error

15:30 <emersion> maybe you don't read the socket until EOF when it hangs up?

15:30 <dnkl> I've had issues before where it seems I don't dispatch everything in the wayland queue after a read error (broken pipe)

15:30 <dnkl> I thought I had fixed that, but I'm not sure anymore

15:31 <emersion> see e.g. https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4235

15:31 <dnkl> I do have one question though... the primaries; I just guessed, and set it to PRIMARIES_SRGB. Is that right or wrong?

15:31 <emersion> that's a good question

15:32 <dnkl> :)

15:32 <emersion> ah, no, sRGB primaries are completely fine

15:33 <emersion> the TF is a more blurry area

15:33 <emersion> rn wlroots advertises the srgb TF, but i think we should advertise bt1886 instead

15:33 <dnkl> thanks. Other than that, is there something else I should be doing? I'm thinking I should listen for advertised TFs, and not just blindly set ext_linear? Anything else?

15:34 <emersion> check for the parametric feature

15:34 <dnkl> ah, ok, will do

15:34 <emersion> other than that, i think it should be fine

15:34 <emersion> also check for the srgb primaries, just in case

15:35 <emersion> (check whether the compositor supports that)

15:35 <dnkl> awesome, thanks a bunch! Got to go now, but I'll try to clean up my quick POC in the next couple of days

15:35 <emersion> nice :)

15:36 <emersion> yeah, the protocol is easy to use if all you want is push content with fixed primaries/TF

15:37 <j`ey> so before this, foot just gives a single surface, but after this.. it gives a surface for the text and bg and asks to blend?

15:37 <j`ey> or is it more granular

15:38 <dnkl> no, still a single surface. just differently encoded

15:39 <j`ey> oh I thought it was asking the compositor to blend stuff or somethingsomething

15:39 <emersion> also i'd suggest to try to paint a gradient via sixel or sth and check for banding

15:56 <dnkl> will try that. Right now it's still 8-bit only, but after landing initial support, I hope to be able to test higher resolution buffers too

15:58 <dnkl> j`ey: no, we need to blend ourselves. But that's nothing new. The really compute intensive part is doing a color space translation for every modified pixel. This is what's being offloaded with the color management protocol

15:58 <emersion> is premult alpha getting in your way, or does that not matter?

16:00 <emersion> it would be really nice to dust off that wlroots MR to upload shm buffers in a separate thread to not block the compositor…

16:00 <dnkl> emersion: not yet... but I've not spent a lot of time verifying transparency. It _looks_ ok, at a quick glance

16:01 <emersion> there's a difference between doing the premult before vs after srgb encoding

16:02 <emersion> wayland assumes premult after srgb encoding

16:02 <emersion> IOW: premult on electrical values

16:02 <emersion> none of that matters if you're using ext_linear TF :P

16:03 <emersion> i was mostly wondering if you were doing alpha premult as a post-processing step

16:04 <dnkl> https://codeberg.org/dnkl/foot/src/branch/srgb/render.c#L247-L268

16:04 <emersion> i suppose you're just working with srgb-encoded (ie. electrical) values atm ("gamma-incorrect blending")

16:04 <dnkl> it's done after converting to linear

16:04 <dnkl> https://codeberg.org/dnkl/foot/src/branch/srgb/render.c#L247-L268

16:04 <dnkl> sorry, double paste

16:05 <emersion> right, but when you need to blend, you're using these values directly?

16:06 <dnkl> the linearly translated and pre-multiplied values, yes :)

16:06 <emersion> that function lgtm

16:06 <emersion> "linearly translated"?

16:07 <dnkl> all input colors (from config, or ANSI escapes) are treated as sRGB, and translated before being used in any pixman calls (be it to fill the background, it blend glyphs or sixels)

16:08 <emersion> oh

16:08 <emersion> we call it "encoding"

16:08 <dnkl> new to this 😅

16:08 <emersion> yeah it's a whole lot of new words

16:08 <dnkl> still figuring out what everything is supposed to be called

16:08 <emersion> i really recommend https://gitlab.freedesktop.org/pq/color-and-hdr

16:09 <emersion> there is a glossary, and "A Pixel's Color" is a great intro

16:09 <dnkl> thanks, will read that