2025-12-05 Low image resolution archive
I'm sitting on a cushion, a tiny laptop on the stool in front of me,
legs folded, the lower back is hurting, and my fingers too, if I'm
honest. Why do I keep doing this. Then again, I do like to be able
to look up and see my wife on the sofa, reading. I don't want to sit
at the desk by myself, until it's time for bed.
I added a new feature to Oddμ: A `-shrink` option to the subcommand to generate a static web site from the working directory. Ordinarily, the static site is generated by translating all the Markdown files to HTML and linking all the other files. The *shrink* option attempts to shrink all the images. I only have the ability to encode JPEG, PNG and WebP images, so it won't work on any other image or video formats.
JPEG, PNG and WebP images wider than 800 pixels are scaled down to a width of 800 pixels.
JPEG and WebP images are encoded using a quality of 10. This is super low quality. Per default, I use a quality of 75. Below that, encoding artifacts start showing up.
In any case, compare:
This reduces the file size from an already pretty good 346 KB down to 30 KB.
It's eleven times smaller.
The effect is that my source directory containing about 3.5 GB of files (of which only 23 MB are actually Markdown files!) shrinks to about 567 MB. Sadly, that's not quite 11 times smaller but it is pretty cool.
Let me try `convert -scale 800x` followed by `jpegoptim --max=10` on the file. The result is even smaller: 23 KB. I'm not quite sure what else it does. Does my code keep EXIF data that it should drop?
I could try shrinking files even more dramatically and SVG filters via SVG as explained by Owl in Low-bandwidth images on the web. When I tried it, however, my browser was really struggling with scrolling. This is not good for my low-energy laptops. I experimented a bit with it but ended up not liking it.
Here's the result, if your browser can render SVG:
image { filter: url(#dither) } The low quality picture from above overlaid with a bitmap pattern, giving it a pixelated look.
It does cleverly disguise the JPEG artifacts in the mountains. On my regular laptop scrolling is not a problem. On the MNT Pocket Reform with the i.MX8MP chip, however, it's noticeable.
The all-in one solution:
If I wanted to do this always, I could have a single hidden SVG as part of my template and then refer to its filter from the CSS used to style regular HTML images. That's how Owl does it, in Low-bandwidth images on the web.
For myself, I think the amount of resources it takes to render the filter is a killer. Perhaps, if I want to do a fancy low-resolution day for my site, I might resort to SVG filters. But to me, the perceived improvement over the bare, low-quality picture is minimal and the client-side resource use contravenes the reasons for the entire exercise: the archive is supposed to be small so that it can be stored *and viewed* on low resource computers. To have a small archive and but require a big reader-laptop is not the point.
Note that using GNU IMP to scale the image, dither it using Floyd-Steinberg with 4 red levels, 4 green levels and 4 blue levels, and saving it as a PNG using 8 bpc RGB pixel format results in a file size of 282 KB. This is closer to the original 346 KB and far from the 30 KB it's competing with. Running `pngcrush` on this image gets it down to 204 KB.
This is clearly too big.
Where does that leave me? I feel the result of this is that I am going to stick with the current solution:
- scale images down to 800 pixels wide;
- reduce JPEG (and WebP) quality to 10.
I should also investigate how to get the filesize closer to what `jpegoptim` creates.
Another thing I've been wondering: Perhaps scaling the image down, leaving the quality high, and then scaling the image up as required is an option? Let's try: `convert -scale 400x -quality 75` shrinks the image to a quarter but keeps the quality relatively high. This image is 33 KB, just 10% more than the terrible quality 10 image above.
Not bad, actually. In terms of a static export, however, I now have a problem. The Markdown files and the HTML files generated from them do not know whether they're showing a small image that should stay small or a small image that they should scale up using CSS.
⁂
For my future self, here's how to compute the sizes of stuff:
# du -sh .
3.2G .
# find . -iname '*.md' -printf '%s\n' | awk '{SUM+=$1} END {print SUM/1024000, "MB"}'
23.5279 MB
# find . -type f -printf '%s %f\n' | awk '
{
i=match($0,/\.[^.]+$/);
if (!i) next;
k=substr($0,i);
sum[k]+=$1
}
END {
for (k in sum) {
mb=sum[k]/1024000;
if (mb>1) print mb, "MB\t", k
}
}' | sort -n
1.556 MB .db
8.11878 MB .rss
9.46637 MB .gz
23.5279 MB .md
51.1257 MB .mov
52.6012 MB .jpeg
110.732 MB .mp4
150.291 MB .png
2880.61 MB .jpg
So yeah, it's true: 2.9 GB of JPEG files and everything else is peanuts.
I'm not quite ready to reduce the quality of the pictures on the blog. But at least now I know I can downsize pretty easily. Maybe one day I can upload a smaller edition of the blog to a archive elsewhere.