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

See also our mainBenchmarks page for a more complex benchmark andtimings on a variety of machines. TheWhy is libvips quick page tries toexplain why libvips does well on this test.

This graph was made by runningps very quickly and piping the output toasimple scriptthat calculated total RSS for all processes associated with a task.

This is a fancier one generated byvipsprofile showing the memorybehaviour of libvips. The bottom graph shows total memory, the uppertraces show threads calculating useful results (green), threads blockedon synchronisation (red) and memory allocations (white ticks). There's ablog postwith some more detail on how this was made.

The benchmarks plus a simple driver program are in agithub repository. See the READMEfor details.

Except where noted, all timings are for a 10,000 by 10,000 pixel 8-bit RGB imagein 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'sno attempt to clear the disc cache, so disc speed should not be a factor. Thepeak memory column was found by sampling RES withps usingthisscript.I used the systems as packaged for Ubuntu unless otherwise indicated. Ilast ran these tests on 4 Jan 2023 and used the current stableversion of every package except where otherwise noted.Tracker wasdisabled.

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

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

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

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

1. Pillow is single-threaded, so the fairest comparison for raw processingspeed 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 beingspent in libjpeg, which is slightly unfair to libvips.

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

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

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

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

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

8. The OpenImageIO test usesoiiotool, which may not be the best way totest the library.

Seethe repository.