Use `thumbnail`, not `thumbnail_image`

[jcupitt]

There's (potentially) a big performance win if you can use thumbnail rather than thumbnail_image.

The thumbnail operation combines load and resize in a single step, so it can exploit the various shrink-on-load hacks that many image format libraries support. These can give dramatic speedups and improve quality.

For example, with a typical 6k x 4k RGB JPG from a smartphone:

$ /usr/bin/time -f %M:%e vips thumbnail_image theo.jpg thumb.jpg 512
230976:0.19

ie. 231mb of ram, 0.2s of elapsed time, on this Ubuntu 24.10 machine with libvips 8.16. If I use thumbnail I see:

$ /usr/bin/time -f %M:%e vips thumbnail theo.jpg thumb.jpg 512
79880:0.09

Now it's 80mb of ram and 0.09s of elapsed time, three times less memory and twice as quick.

In fact it's better than that, since the vips CLI uses some ram and takes some time to start and stop:

$ /usr/bin/time -f %M:%e vips > /dev/null
30728:0.03

So 30mb of ram and 0.03s to start and stop. If we subtract this overhead and compare, thumbnail needs 4x less memory and is 4x faster.

For a possible implementation, you could:

• in FilePathImageDecoder.php, as well as opening the image with newFromFile, you could also save the input filename in some secret member variable
• in all processing steps except resize, you could clear this secret filename member
• in ResizeModifier.php, you could see if the filename was set and call thumbnail rather than resize

The idea being that intervention could recognise the magic open, resize sequence (surely very common) and substitute thumbnail in this case. I expect there's a better way to implement this!

You can do something similar for memory and pipe sources with thumbnail_buffer and thumbnail_source.

[jcupitt]

... I meant to say, quality gains come with vector formats like PDF and SVG.

With PDF (for example), using thumbnail will directly render the page at exactly the right size, and with the correct settings for antialising.

If you use thumbnail_image, you need to render at a high resolution and then downsample to the target size. This can be very slow, and give noticeably worse quality.

[olivervogel]

Thanks for the suggestion @jcupitt. I had already read your guidelines on this, but hadn't thought of your idea with the hidden filename. But it might make sense since simple resizing is probably the most used feature.

The file name is even saved already.

[jcupitt]

Oh, nice! So you only need to detect when resize is the first operation after open.

You could make it work for the other decoders as well, potentially, though I suppose it'd be a bit harder.

[olivervogel]

I will address this at a later date. Maybe even with a new major release of Intervention Image.

The current architecture of the parent library Intervention Image is designed to immediately load the image into memory and perform actions at each subsequent step. This is in contrast to the approach that thumbnail requires.

I find the idea of buffering the calls to Intervention Image first and only executing them when a real image is expected as a result (encoding) or image data must be available in memory (reading colors of pixels) very exciting.

I think with this approach I can also flexibly switch internally to thumbnail if the buffered stack only contains reading and resizing, for example.

[jcupitt]

A few image processing libraries delay executing imaging operations until their result is needed. Sun had one that worked like this, I forget the name.

One of the advantages is that you can search the tree of operations for small, local optimisations, a bit like a peephole optimiser in a compiler, if you remember those. As well as load,resize->thumbnail, you can do things like add(const1),mul(const2)->linear(const3, const4). One of most useful ones is to replace all arithmetic operations on one image with a lookup table.

• You repeatedly scan the operation tree with the set of rewrite rules until no further rewrites are possible.
• The set of rewrite rules will be specific to each backend.
• Some kind of database of typical pipelines is very helpful when generating a good set of rewrite rules.
• The libvips dataflow architecture is not like this, of course.

[binaryfire]

Was just about to open an issue about this :) We switched from thumbnail_image to thumbnail with php-vips a while back and noticed a huge difference in an app that handles a lot of images. We're talking 300-400% performance improvement and resource usage reduction.

[jcupitt]

Exactly, with larger JPEG images I would expect about a 4x speedup and 4x less memory use, it's potentially a very significant improvement.

[Gruven]

No progress here? 👀