Perhaps you have some other modules loaded? I tried:

#!/usr/bin/env python3

import sys
import pyvips

pyvips.cache_set_max(0)
thumb = pyvips.Image.thumbnail(sys.argv[1], 500)
thumb.write_to_file(sys.argv[2])

Then with your test image:

$ VIPS_CONCURRENCY=1 /usr/bin/time -f %M:%e ./thumb.py ~/pics/big.png x.png
108848:0.93

So 33mb for libvips, 60mb for pixel buffers, 15mb for python.

I think my previous test I'd forgotten to set VIPS_CONCURRENCY - I can indeed get your results from that script, which is great!

Is there any way to optimise the ~100MB down any further? Or is it just a fact of life for optimising images this large? I was hoping for something in the ~10MB range, which is clearly possible when explicitly limited.

python itself is 15mb, so you're not going to get lower than that heh.

You can remove a bit of buffering by dropping the tile height:

$ VIPS_LEAK=1 VIPS_CONCURRENCY=1 /usr/bin/time -f %M:%e vips thumbnail big.png x.png 500 --vips-tile-height=1
vips_threadset_free: peak of 3 threads
memory: high-water mark 16.81 MB
48632:0.76

So libvips is only allocating 17mb now. But this is just a thing for testing, it's not exposed in the API.

I think I'll stick to the stable APIs ;) 100MB is still a lot better than what I have currently from Pillow, so I'll keep looking through the docs and probably accept that this is just a constraint to deal with.

Your test image is 275mb, so it's a big saving already.

It does, but only if you have full access to what's running the container, which we don't.