I am currently working through modernizing the HaikuDepotServer (HDS) image processing tooling.
This post is a question around screenshots. Screenshots are supplied by users as PNG. There are 234MB of images in HDS with an average size of 121KB. There’s 96 images over 512KB.
One option I have been looking into is to apply the pngquant tool to the screenshots as they are uploaded and then again later when thumbnails are produced. The pngquant tool is fast enough and reduces images from 8 bits per channel down to a palette of 256 colors which, in turn, means the images are approximately 30-40% of their original size. The output from pngquant is impressive in the way it is able to retain good quality despite the reduction in fidelity.
Although there isn’t a problem with data volumes (234MB of images is not a lot in 2024) the reduction in size would benefit application memory usage, transmission volumes, database volumes, backup volumes etc… Doing this feels aligned to the Haiku vibe of being light on resources.
I have some examples of outputs from the tool here.
The question is; do people feel that a reduction in the screenshot images to a 256 palette is a good idea given the quality of these sample outputs or it is better to stick to the full 8 bit per channel pixel format for these images?
8 bits per pixel is 256 colors…? You must mean 8 bits per channel (24bit color.)
I don’t really see a reason to reduce things further than they already are. Full-size high-quality screenshots are what I would expect when clicking on the screenshot view. Generating a tiny preview image so the full-size one isn’t loaded all the time (if we don’t already do that) sounds sensible, however.
I was thinking… converting down to 256 colors might work for GUI, but surely will look ugly for photos. But then saw that example03_pngquant_90.png file. Quite impressive! For the intended usage, seems really good to my eyes.
There is no currently available tool to do this. In theory it would be nice, but suggesting non-existing solutions may not be a great approach here. Also it would mean redoing all the screenshots, while converting the existing one to a better compressed bitmap format is easily done.
I would add AVIF to the list of things to try. And indeed, using some slighly lossy compression from WebP or AVIF may lead to even smaller results and still very good quality.
Yes, true. However the question is also what problem is beeing solved. For me the question in this case to solve a bit pf RAM seems like a micro optimization, and saving on color space seems like a bad tradeoff (i.e mostly fine for most cases but likely has some very icky edge cases we don’t know about yet)
A BPicture could also allow previewing a view with system colors somewhat, and atleast some of the tech required to aconplish this exist. It is indeed not off-the-shelve, but still a possible option for the future, even if not the immidieate future.
If we are talking existing formats we should use JpegXL insteaf
FWIW, I used to apply “optipng” to all screenshots I upload to HDS or use when creating documentation. Since @apl mentioned “pngquant”, I use that and “oxipng” in a script I run via TrackRunner. This shaves off another 60% over “optipng”.
If there are unacceptible losses in the result, I either only do a lossless “oxipng” or simply choose a more suitable subject to screenshoot…
