Now that Wayland compositors are slowly moving toward supporting color management and HDR, having swaybg provide color-managed buffers to the compositor will soon start to become possible. Implementing color management would ~permit cooler wallpapers~ allow for better representation of a wider range of images, specifically those with saturated colors and bright spots.
Swaybg would also be a decent client to test color management protocols on, because it is relatively simple and directly uses Wayland protocols. Support for specific input/output features can be added piece by piece, without needing to wait for toolkit support.
The main challenge appears to be that, at the moment, image library support for color management is weak, and support for color management would need to be added format by format; or one would need to move away from gdk_pixbuf+Cairo; a few alternatives, none particularly great, are noted in #32. On the other hand, just adding support for PNG images would probably be good enough to start.
One route to incrementally add color management is to start by adding support for image formats providing their colorspace as CICP, and to test with the very restricted color management protocol currently being used by Kwin and VK_hdr_layer. I've made a test branch that does this, for PNG formats; see mstoeckl/frog-v1 .
The branch [mstoeckl/frog-v1](https://github.com/mstoeckl/swaybg/tree/frog-v1) is based on top of the current 10-bit output support PR.
It takes as input PNG files which have the (draft) [cICP](https://www.w3.org/TR/png-3/#cICP-chunk) chunk set, _and_ furthermore use one of the few primary/transfer combinations from frog-color-management-v1 (i.e, BT709 or BT2020 primaries, and sRGB, gamma2.2, PQ, or linear transfer function.) Such images can be created with ffmpeg from a video or from a `.hdr` file. For example, applying the following command to one of the files from https://hdri-haven.com/
```ffmpeg -i input_file.hdr -vf "libplacebo=color_primaries=bt2020:color_trc=smpte2084" -pix_fmt rgba64be output_file.png```
would produce an image with a cICP chunk, like the following :
Other notes:
Computing eotf/transfer functions takes energy, and to minimize this when drawing backgrounds the compositor should ideally be working from a (linear space, f16) buffer with the transfer function already applied. However, there is also an energy cost from reading larger buffers. If compositors do not opt to cache transformed buffers, it might still be worth it for swaybg to do this part of the color transformation itself, and then submit buffers in the compositors preferred format (most likely linear/f16).
Now that Wayland compositors are slowly moving toward supporting color management and HDR, having
swaybgprovide color-managed buffers to the compositor will soon start to become possible. Implementing color management would ~permit cooler wallpapers~ allow for better representation of a wider range of images, specifically those with saturated colors and bright spots.Swaybg would also be a decent client to test color management protocols on, because it is relatively simple and directly uses Wayland protocols. Support for specific input/output features can be added piece by piece, without needing to wait for toolkit support.
The main challenge appears to be that, at the moment, image library support for color management is weak, and support for color management would need to be added format by format; or one would need to move away from gdk_pixbuf+Cairo; a few alternatives, none particularly great, are noted in #32. On the other hand, just adding support for PNG images would probably be good enough to start.
One route to incrementally add color management is to start by adding support for image formats providing their colorspace as CICP, and to test with the very restricted color management protocol currently being used by Kwin and VK_hdr_layer. I've made a test branch that does this, for PNG formats; see mstoeckl/frog-v1 .
Other notes: