image quality issues

[guijan]

JPEG uses BT.601 colormatrix and YCbCr colorspace.

Conversion between the RGB of an X server and the YCbCr of JPEG will run into rounding error. To improve image quality, you can do the conversion at a higher bit depth, and then dither the result down to 8bpc (JPEG is always 8bpc). Imlib doesn't do this, and is unlikely to do so because it uses 8bpc internally. And if we ever add support for interfaces other than X11 (the Linux fb, Wayland, etc), then Imlib can't help us either because maybe Imlib can be made to dither a 10bpc or more image it receives from an X server down to its 8bpc internal format as it receives the image, but it can't do that with other user interfaces it doesn't support.

Additionally, computer screens don't use BT.601 colormatrix, and converting color matrices is a very complex problem, I doubt Imlib uses one of the better algorithms for it, and this task also benefits from doing the conversion at a higher bit depth and then dithering down the result to improve image quality.

This isn't only because of JPEG. WEBP is also an 8bpc only format. AVIF maxes out at 12bpc and HDMI supports 16bpc, even a 12bpc format could benefit from dithering down at some point.

We might want to look into replacing Imlib someday to be able to follow the latest in video and to screenshot it well. Possibly, writing our own code to get images from X11/Wayland/Linux fb/Haiku/Windows/etc, libplacebo for colorspace conversion and dithering where beneficial, then ffmpeg for encoding? That more or less means rewriting most of scrot someday.

[N-R-K]

That more or less means rewriting most of scrot someday.

Yes it's pretty much a complete rewrite, since scrot's code base is very much entangled with both X and imlib2.

And it'll also add a bunch of fairly heavyweight library dependency which not all user might benefit from nor want. And you'd also have to keep compatibility with all of scrot's existing features while doing it.

IMO, at that point it's better to just write something new from scratch with those goals in mind if you're really interested in pursuing it.

[N-R-K]

Closing due to the above reasons.

---

Although if someone does want to pursue it, I think it'd be a mistake to get involved with the encoding business. IMO, it's much better to follow the unix philosophy and have the screenshotter produce a simpler "intermediate" format (e.g farbfeld, pbm, etc) and then let specialized tools (such as optipng and similar) take care of the final encoding.

It'd also be a mistake to add selection into the screenshot tool itself. Since selection is a more generic task that is useful outside of just screenshotting - it's better to leave it to a separate tool as well (eg. sx4 or slop).

Usability may be a concern, since now you need 3 tools (selection + shot + final encoding) instead of 1. But that's where the shell shines, gluing processes together. So it's easily possible to provide an (example) wrapper script that glues these tools together and provides an easy-to-use interface.

---

For me at least, that's a more ideal workflow - composing multiple specialized tools that do one thing and do it well - instead of one giant tool that tries to do everything.