Speed and Memory Use
From VipsWiki
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.
Contents |
Results
i5-3210M CPU @ 2.50GHz (Dell Vostro laptop)
| Software | Run time (secs real) | Memory (peak RSS MB) | Times slower |
|---|---|---|---|
| VIPS C++ 7.32 | 0.33 | 10 | 1.0 |
| VIPS Python 7.32 | 0.35 | 12 | 1.06 |
| ruby-vips 7.32 | 0.37 | 12 | 1.12 |
| VIPS command-line 7.32 | 0.55 | 12 | 1.82 |
| VIPS nip2 7.32 | 0.95 | 39 | 2.88 |
| OpenCV 2.3.1-11ubuntu2 | 1.40 | 185 | 4.24 |
| RMagick 2.13.2 (ImageMagick 6.7.7.10-2ubuntu4) | 1.98 | 670 | 6.00 |
| ExactImage 0.8.5 | 2.13 | 110 | 6.4 |
| ImageMagick 6.7.7.10-2ubuntu4 | 2.46 | 480 | 7.45 |
| GraphicsMagick 1.3.16-1.1ubuntu1 | 2.50 | 240 | 7.58 |
| PIL 1.1.7-4build1 | 2.53 | 188 | 7.66 |
| FreeImage 3.15.1-1 (incomplete) | 3.17 | 180 | 9.61 |
| NetPBM 10.47.42 | 3.38 | 70 | 10.24 |
| ImageScience 1.2.4 (based on FreeImage 3.15.1-1, incomplete) | 4.14 | 260 | 12.55 |
| Octave 3.0.1 | 64 (est.) | 8500 (est.) | 200 |
Notes
All timings are for a 5,000 by 5,000 pixel 8-bit RGB image in uncompressed tiled TIFF format, 128 by 128 pixel tiles. Each test was run with something like:
time ./vips.sh wtc_tiled_small.tif wtc2.tif
On a quiet system with the quickest real time of three runs recorded. I didn't try to clear the disc cache so the disc speed should not be a factor. The peak memory column was from watching RSS on "top". I used the systems as packaged for Ubuntu, unless otherwise indicated. I last ran these tests on 17 Feb, 2013 and used the current stable version of every package.
I don't know much about OpenCV and I'm sure it could be made to run this benchmark faster. OpenCV is also not (very) threaded, so on a single-core machine it would be much closer.
Some systems, like ImageScience and nip2, have relatively long start-up times and this hurts their position in the table.
The VIPS command-line generates a huge amount of disc traffic which makes it unsuitable in certain applications. This is not really considered in this table.
ExactImage will not read tiled tiff, so the benchmark uses a strip tiff for this test.
Octave aims to be a very high-level prototyping language and is not primarily targeting speed. I timed a 2,000 by 2,000 pixel monochrome JPEG and extrapolated from that.
FreeImage does not have a sharpening or convolution operation so I skipped that part of the benchmark.
ImageScience is based on FreeImage and therefore does not support sharpening, so I've skipped that part of the test. The resize() method is always bicubic which is a little unfair as the other benchmarks here use bilinear.
Why is VIPS quick
We have a How it works page which goes into some detail, but briefly:
- Threaded image input-output (IO) system
- Most image processing libraries have threaded operations. Each operation has code, generally using a framework like OpenMP, to run the operation over all the available processors. VIPS instead puts the threading into the image IO system, so all operations are automatically threaded. Additionally, this type of "horizontal" threading makes much better use of processor caches and dramatically reduces the amount of locking you need.
- Fast operations
- The VIPS primitives are implemented carefully, and some use techniques like run-time code generation. The convolution operator, for example, will examine the matrix and the image and write a short SSE3 program to implement exactly that convolution on exactly that image.
- Demand-driven
- VIPS is fully demand-driven, so it only needs to keep a few pixel buffers in memory, it doesn't need to load the whole image. This reduces memory use.
Implementations
The benchmarks plus a simple driver program are in a github repository. See the README for details.
Here it is in a variety of image processing systems.
VIPS Python
#!/usr/bin/python
import sys
from vipsCC import *
im = VImage.VImage (sys.argv[1])
im = im.extract_area (100, 100, im.Xsize () - 200, im.Ysize () - 200)
im = im.affinei_all ("bilinear", 0.9, 0, 0, 0.9, 0, 0)
mask = VMask.VIMask (3, 3, 8, 0,
[-1, -1, -1,
-1, 16, -1,
-1, -1, -1])
im = im.conv (mask)
im.write (sys.argv[2])
ruby-vips
#!/usr/bin/ruby
require 'rubygems'
require 'vips'
include VIPS
im = Image.new(ARGV[0])
im = im.extract_area(100, 100, im.x_size - 200, im.y_size - 200)
im = im.affinei(:bilinear, 0.9, 0, 0, 0.9, 0, 0)
mask = [
[-1, -1, -1],
[-1, 16, -1,],
[-1, -1, -1]
]
m = Mask.new mask, 8, 0
im = im.conv(m)
im.write(ARGV[1])
VIPS nip2
#!/home/john/vips/bin/nip2 -s
main
= error "usage: infile -o outfile", argc != 2
= (sharpen @ shrink @ crop) (Image_file argv?1)
{
crop x = extract_area 100 100 (x.width - 200) (x.height - 200) x;
shrink = resize Interpolate_bilinear 0.9 0.9;
sharpen = conv (Matrix_con 8 0 [[-1, -1, -1], [-1, 16, -1], [-1, -1, -1]]);
}
VIPS command-line
#!/bin/bash width=`header -f Xsize $1` height=`header -f Ysize $1` width=$((width - 200)) height=$((height - 200)) set -x vips im_extract_area $1 t1.v 100 100 $width $height vips im_affinei_all t1.v t2.v bilinear 0.9 0 0 0.9 0 0 cat > mask.con <<EOF 3 3 8 0 -1 -1 -1 -1 16 -1 -1 -1 -1 EOF vips im_conv t2.v $2 mask.con rm t1.v t2.v mask.con
VIPS C++
#include <vips/vips>
int main (int argc, char **argv)
{
vips::VImage in (argv[1], "rs");
vips::VIMask mask (3, 3, 8, 0,
-1, -1, -1, -1, 16,-1, -1, -1, -1);
in.
extract_area (100, 100, in.Xsize () - 200, in.Ysize () - 200).
affine (0.9, 0, 0, 0.9, 0, 0,
0, 0, in.Xsize () * 0.9, in.Ysize () * 0.9).
conv (mask).
write (argv[2]);
return 0;
}
PIL
#!/usr/bin/python
import Image, sys
import ImageFilter
im = Image.open (sys.argv[1])
im = im.crop ((100, 100, im.size[0] - 100, im.size[1] - 100))
im = im.resize ((int (im.size[0] * 0.9), int (im.size[1] * 0.9)),
Image.BILINEAR)
filter = ImageFilter.Kernel ((3, 3),
(-1, -1, -1,
-1, 16, -1,
-1, -1, -1))
im = im.filter (filter)
im.save (sys.argv[2])
Octave
#!/usr/bin/octave -qf
pkg load image
im = imread(argv(){1});
im = im(101:end-100, 101:end-100); % Crop
im = imresize(im, 0.9, 'linear'); % Shrink
myFilter = [-1 -1 -1
-1 16 -1
-1 -1 -1];
im = conv2(double(im), myFilter); % Sharpen
im = max(0, im ./ (max(max(im)) / 255)); % Renormalize
imwrite(argv(){2}, uint8(im)); % Write back again
ImageMagick
#!/bin/bash
# we crop on load, it's a bit quicker and saves some memory
# we can't crop 100 pixels with the crop-on-load syntax, so we have to
# find the width and height ourselves
width=`header -f Xsize $1`
height=`header -f Ysize $1`
width=$((width - 200))
height=$((height - 200))
set -x
convert "$1[${width}x${height}+100+100]" \
-resize 90x90% \
-convolve "-1, -1, -1, -1, 16, -1, -1, -1, -1" \
$2
GraphicsMagick
#!/bin/bash
set -x
# GraphicsMagick does not have crop-on-load so we use -shave instead
gm convert $1 \
-shave 100x100 \
-resize 90x90% \
-convolve "-1, -1, -1, -1, 16, -1, -1, -1, -1" \
$2
ExactImage
#!/bin/bash width=`header -f Xsize $1` height=`header -f Ysize $1` width=$((width - 200)) height=$((height - 200)) # set -x econvert -i $1 \ --crop "100,100,$width,$height" \ --bilinear-scale 0.9 \ --convolve "-1, -1, -1, -1, 16, -1, -1, -1, -1" \ -o $2
FreeImage
/* Compile with:
gcc freeimage.c -lfreeimage
*/
#include <FreeImage.h>
int
main (int argc, char **argv)
{
FIBITMAP *t1;
FIBITMAP *t2;
int width;
int height;
FreeImage_Initialise (FALSE);
t1 = FreeImage_Load (FIF_TIFF, argv[1], TIFF_DEFAULT);
width = FreeImage_GetWidth (t1);
height = FreeImage_GetHeight (t1);
t2 = FreeImage_Copy (t1, 100, 100, width - 100, height - 100);
FreeImage_Unload (t1);
t1 = FreeImage_Rescale (t2, (width - 200) * 0.9, (height - 200) * 0.9,
FILTER_BILINEAR);
FreeImage_Unload (t2);
/* FreeImage does not have a sharpen operation, so we skip that.
*/
FreeImage_Save (FIF_TIFF, t1, argv[2], TIFF_DEFAULT);
FreeImage_Unload (t1);
FreeImage_DeInitialise ();
return 0;
}
NetPBM
#!/bin/bash cat > mask <<EOF P2 3 3 32 14 14 14 14 48 14 14 14 14 EOF tifftopnm $1 | \ pnmcut -left 100 -right -100 -top 100 -bottom -100 | \ pnmscale 0.9 | \ pnmconvol mask | \ pnmtotiff -truecolor -color > $2
ImageScience
#!/usr/bin/ruby
require 'rubygems'
require 'image_science'
ImageScience.with_image(ARGV[0]) do |img|
img.with_crop(100, 100, img.width() - 100, img.height() - 100) do |crop|
crop.resize(crop.width() * 0.9, crop.height() * 0.9) do |small|
small.save(ARGV[1])
end
end
end
RMagick
#!/usr/bin/ruby
require 'rubygems'
require 'RMagick'
include Magick
im = ImageList.new(ARGV[0])
im = im.shave(100, 100)
im = im.scale(0.9)
kernel = [-1, -1, -1, -1, 16, -1, -1, -1, -1]
im = im.convolve(3, kernel)
im.write(ARGV[1])
OpenCV
/*
g++ -g -Wall opencv.cc `pkg-config opencv --cflags --libs`
*/
#include <cv.h>
#include <highgui.h>
using namespace cv;
int
main (int argc, char **argv)
{
Ptr < IplImage > t1;
if (!(t1 = cvLoadImage (argv[1])))
return 1;
Mat img (t1);
Mat crop (img, Rect (100, 100, img.cols - 200, img.rows - 200));
Mat shrunk;
resize (crop, shrunk, Size (0, 0), 0.9, 0.9);
float m[3][3] = { {-1, -1, -1}, {-1, 16, -1}, {-1, -1, -1} };
Mat kernel = Mat (3, 3, CV_32F, m) / 8.0;
Mat sharp;
filter2D (shrunk, sharp, -1, kernel, Point (-1, -1), 0, BORDER_REPLICATE);
CvMat cvimg = sharp;
cvSaveImage (argv[2], &cvimg);
return 0;
}
GEGL
I've not included a timing for gegl in the table at the top since this sort of batch processing is not what gegl was designed for and gegl has not yet had much optimisation. It's interesting to see the code though. Gegl doesn't seem to have a general convolve operator yet, so I used usharp with a very small radius instead.
For reference, gegl-0.1.6 with default settings takes about 50s and needs about 300mb of memory. You can get this down to 40s by tuning a few environment variables. Bear in mind that gegl uses PNG (rather slow), writes 16-bits by default (again, rather slow), maintains an alpha channel (including a lot of work in pre-multiplying), and caches calculated tiles on disc for reuse (unnecessary in batch processing) making the speed comparison very unclear.
/* compile with
gcc -g -Wall gegl.c `pkg-config gegl --cflags --libs`
*/
#include <stdio.h>
#include <stdlib.h>
#include <gegl.h>
int
main (int argc, char **argv)
{
GeglNode *gegl, *load, *crop, *scale, *sharp, *save;
g_thread_init (NULL);
gegl_init (&argc, &argv);
if (argc != 3)
{
fprintf (stderr, "usage: %s file-in file-out\n", argv[0]);
exit (1);
}
gegl = gegl_node_new ();
load = gegl_node_new_child (gegl,
"operation", "gegl:load",
"path", argv[1],
NULL);
crop = gegl_node_new_child (gegl,
"operation", "gegl:crop",
"x", 100.0,
"y", 100.0,
"width", 4800.0,
"height", 4800.0,
NULL);
scale = gegl_node_new_child (gegl,
"operation", "gegl:scale",
"x", 0.9,
"y", 0.9,
"filter", "linear",
"hard-edges", FALSE,
NULL);
sharp = gegl_node_new_child (gegl,
"operation", "gegl:unsharp-mask",
"std-dev", 0.1,
NULL);
save = gegl_node_new_child (gegl,
"operation", "gegl:png-save",
"path", argv[2],
NULL);
gegl_node_link_many (load, crop, scale, sharp, save, NULL);
gegl_node_process (save);
g_object_unref (gegl);
gegl_exit ();
return (0);
}
