We've written programs using number of different image processing system to load a TIFF image, crop 100 pixels off every edge, shrink by 10% with bilinear interpolation, sharpen with a 3x3 convolution and save again. It's a trivial test, but it does give some idea of the speed and memory behaviour of these libraries (and it's also quite fun to compare the code).

See also our main Benchmarks page for a more complex benchmark and timings on a variety of machines. The Why is libvips quick page tries to explain why libvips does well on this test.

This graph was made by running ps very quickly and piping the output to a simple script that calculated total RSS for all processes associated with a task.

This is a fancier one generated by vipsprofile showing the memory behaviour of libvips. The bottom graph shows total memory, the upper traces show threads calculating useful results (green), threads blocked on synchronisation (red) and memory allocations (white ticks). There's a blog post with some more detail on how this was made.

The benchmarks plus a simple driver program are in a github repository. See the README for details.

Except where noted, all timings are for a 10,000 by 10,000 pixel 8-bit RGB image in uncompressed tiled TIFF format. Each test was run with something like:

time ./vips.sh tmp/x.tif tmp/x2.tif

On a quiet system with the quickest real time of five runs recorded. There's no attempt to clear the disc cache, so disc speed should not be a factor. The peak memory column was found by sampling RES with ps using this script. I used the systems as packaged for Ubuntu unless otherwise indicated. I last ran these tests on 4 Jan 2023 and used the current stable version of every package except where otherwise noted. Tracker was disabled.

The benchmark hardware has 16 cores, so systems like Pillow, ymagine, OpenCV and ImageScience, which do not thread automatically, are lower in the table than they should be. On a single-core machine the table would look quite different. There's a separate entry for libvips with a single worker thread for comparison, although even when running with just a single worker libvips will still use a separate write-behind thread.

This test does a lot of file IO and relatively little processing, which flatters libvips.

Some systems, like ImageJ, GEGL and nip2, have relatively long start-up times and this hurts their position in the table.

The libvips command-line version generates a huge amount of disc traffic which makes it unsuitable for certain applications. This is not really considered in this table.

1. Pillow is single-threaded, so the fairest comparison for raw processing speed would be against vips-1thread.

2. libgd will not read tiff, so I used jpeg. Their "times slower" column is against libvips with a jpeg source. A lot of time is therefore being spent in libjpeg, which is slightly unfair to libvips.

3. ExactImage will not read tiled tiff, so the benchmark uses a strip tiff for this test.

4. GEGL does not really focus on batch-style processing -- it targets interactive applications, like paint programs. It was run with JPEG images, with 16 threads, and timed against a pyvips program which exactly matches GEGL's processing.

5. Octave aims to be a very high-level prototyping language and is not primarily targeting speed.

6. FreeImage does not have a sharpening or convolution operation so I skipped that part of the benchmark.

7. Imlib2 is spending almost all its time in image input and output.

8. The OpenImageIO test uses oiiotool, which may not be the best way to test the library.

See the repository.