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:
The original picture shows mountains and a garden with colourful
flowers.
The low quality picture still shows the same scenery but there are
visible artifacts obscuring many details and the sky shows a few
stripes of blue instead of a smooth blue gradient.
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?
A similar low quality picture
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:
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.
A dithered image where the light and dark blue pixels used to
reproduce the different shades of blue in the sky are clearly visible.
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.
#Pictures #Oddμ #Archives #JPG #SVG
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.
#Pictures #Oddμ #Archives #JPG #SVG