libvips and nip2

Sequential mode read

2012-02-21T03:31:00.001-08:00

Development libvips has just gained an interesting new feature: sequential mode read. This will be in the upcoming 7.28, due in another month or so.

Many image formats only really support sequential reading. For example, libpng provides png_read_row(), a function which reads the next line of pixels from a file. You call it once for each line in the image to get every pixel.

However, many operations require random access to pixels. For example, a 90-degree rotate will need to read a column of pixels for every output line it writes. If it just used png_read_row() it would need to decompress the input image many, many times in order to create the output.

To prevent this, libvips will first decompress the entire image to a large temporary area and then process from that. This temporary area is in memory for small files or on disc for large files.

Not all operations need random access to their source pixels. For example, thumbnailing, the process of shrinking images for display, can work strictly top-to-bottom. To help speed up operations of this type, libvips has a new hint that you can give to read operations to indicate that you only need sequential access.

$ time vips --vips-leak copy wtc.jpg[sequential] wtc.tif
real    0m4.903s
user    0m1.384s
sys    0m0.512s
memory: high-water mark 70.73 MB

(where wtc.jpg is a 10,000 by 10,000 pixel RGB image and --vips-leak makes libvips print peak memory use)

Here the [sequential] hint means that we will only need top-to-bottom access to the pixels in wtc.jpg. When libvips opens this image it will not decompress to a temporary buffer but, instead, stream pixels from the jpeg decompressor directly through the operation. This saves first writing and then reading the 300 MB temporary area.

The sequential mode reader keeps a few hundred lines behind the current read point in a cache so it can handle some small amount of non-sequential access. If you try something that's very non-sequential after giving the [sequential] hint, you get an error.

$ time vips flip wtc.png[sequential] wtc.tif vertical
VipsSequential: non-sequential read --- at position 0 in file, but position 9344 requested

Without the [sequential] hint you get the current libvips behaviour, which is noticeably slower and of course makes much more disc traffic:

$ time vips copy wtc.jpg wtc.tif
real    0m6.004s
user    0m1.588s
sys    0m1.208s
memory: high-water mark 77.46 MB

Both are faster than ImageMagick:

$ time convert wtc.jpg wtc.tif
real    0m9.357s
user    0m11.393s
sys   0m0.620s
peak memuse 673 MB

The jpeg, stripped tiff and png readers now support sequential mode read. We may add sequential mode support to other readers before release, but these are the main ones.

The libvips thumbnailing utility, vipsthumbnail, now turns on sequential mode for you, so you get this nice behaviour automatically.

$ time vipsthumbnail --vips-leak wtc.tif
real 0m1.612s
user 0m1.160s
sys 0m0.784s
memory: high-water mark 72.57 MB

Again, faster than ImageMagick:

$ time convert wtc.tif -resize 128x128 tn_wtc.jpg
real    0m10.039s
user    0m9.409s
sys    0m0.820s
peak memuse 678 MB

You won't see much of a speedup with jpg images since both systems use libjpeg's handy downsample-on-load feature:

$ time vipsthumbnail wtc.jpg
real    0m0.527s
user    0m0.492s
sys    0m0.024s

$ time convert -define jpeg:size=256x256 wtc.jpg -thumbnail 128x128 -unsharp 0x.5 tn_wtc.jpg
real    0m0.463s
user    0m0.436s
sys    0m0.040s

Update

Rob Hines pointed out that this will help tiff pyramid build as well. You see a modest speedup with a tif source:

$ time vips --vips-leak copy wtc.tif wtc-pyr.tif[compression=jpeg,tile,pyramid]
memory: high-water mark 72.50 MB
real 0m6.604s
user 0m4.820s
sys 0m1.076s

$ time vips --vips-leak copy wtc.tif[sequential] wtc-pyr.tif[compression=jpeg,tile,pyramid]
memory: high-water mark 62.30 MB
real 0m5.379s
user 0m4.648s
sys 0m0.560s

And a very nice speedup with a massive jpg source:

$ time vips --vips-leak copy world.topo.bathy.200405.3x21600x21600.A1.jpg A1-pyr.tif[compression=jpeg,tile,pyramid]
memory: high-water mark 162.58 MB
real 1m12.996s
user 0m22.845s
sys 0m4.552s

$ time vips --vips-leak copy world.topo.bathy.200405.3x21600x21600.A1.jpg[sequential] A1-pyr.tif[compression=jpeg,tile,pyramid]
memory: high-water mark 138.95 MB
real 0m24.218s
user 0m22.277s
sys 0m1.172s

In this case you save writing then reading back a 1.3 GB file.

How libvips handles colour

2012-01-30T09:12:00.000-08:00

I was asked to write some notes on how libvips handles colourspaces. I thought it might be handy to have as a blog post for reference.

libvips started out as a library for very high-resolution colorimetricimaging of old master paintings. So it emphasises efficiency, largefile sizes and high accuracy, it does not think much of being easy touse. It's a low-level, rather manual library.

libvips images are 3D arrays with the dimensions width / height / bands (usually called channels in other packages I think), where each value can be 8, 16 or 32-bit int,signed or unsigned, float, double, complex or double complex. Allvalues in an image must have the same type. All operations (almost)can work on images of any size or type. libvips uses templates soyou (usually) only write one inner loop and the compiler will expandit to the 10 cases for you.

Colour transforms are implemented as a set of functions ontop of this. libvips has D65 XYZ, represented as a 3-band float image,as its core colourspace:

There's no such thing as a LAB image (for example). Instead,operations like im_XYZ2Lab() assume you know what you are doing andthat the array of values you pass in does indeed represent a D65 XYZimage. Operations set a hint field on their output (called"interpretation" -- it'd be set to LAB by im_XYZ2Lab(), for example) thathigher-level libraries can use to help display an image to the usersensibly.

The colour-related operations libvips provides are:

conversion between XYZ, Lab, LCh, Yxy and CMC
a few colour difference metrics: CIELAB 76, CIELAB 2000, CMC
D65 / D50 conversion, based on Bradford
conversion to and from device space and D65 XYZ with lcms and an ICC profile
a fast path to sRGB from XYZ for GUIs

And that's about it.

The file load/save operations (like tiffload, jpegsave etc.) don't doanything with colour. On load they attach any ICC profiles they seeto the vips image as metadata and on save they write any attachedprofile to the file. They aim to give you something very close towhat's actually stored in the file and leave colour processing for youto arrange.

What's good about the way libvips handles colour? It's simple, fast andpredictable. There's no magic and it won't do strange things behindyour back. Because there's no colour knowledge embedded in imagesit's also very easy to extend.

The downsides are: it takes some level of knowledge to drive it,there's not much support for other colour temperatures (better D50support would be useful for printing), and like all of libvips there'sno support for alpha.

nip2 tries to provide a slightly higher-level way of working with colour. It has simple menus which flip between colour spaces and temperatures, buttons for calculating distance maps, and fairly automatic import and export features.

Task of the day: resize an image with the "align centers" and "align corners" image size conventions

2011-12-31T07:51:00.000-08:00

There are two main image size conventions. Both are based on imagining pixels of the "original" image to be squares of unit area. Each leads to different results when resizing.

Note: In this post, I won't address the issue of preserving the aspect ratio exactly.

Suppose that
input.img is the image to be resized. input.img has m rows and n columns.
output.img is the resized image. output.img has M rows and N columns.

In VIPS, the center of the top left corner of any image is understood to be at position (0,0) by default, and pixels are indexed starting at 0 (the C convention). So, the top left pixel has index (0,0) and is centered at (0,0). The bottom right pixel of input.img has index (n-1,m-1) and is centered at (n-1,m-1).
In other words, positions match C-style indexing.

Align corners (generaly better for reducing size): This is the image size convention which is ideal for reducing the number of pixels in each direction by an exact fraction (with box filtering, for example). With this convention, there is no extrapolation near the boundary when downsampling. It is used by ImageMagick by default ~~(recent versions of ImageMagick can be compiled to use the other convention instead)~~.

The corners of input.img are located at (-.5,-.5), (-.5,m-.5), (n-.5,-.5) and (n-.5,m-.5).
The corners of output.img are located at (-.5,-.5), (-.5,M-.5), (N-.5,-.5) and (N-.5,M-.5).

The affine transformation that sends each input corner to the corresponding output corner is
X = (N/n) x + (N/n-1)/2
Y = (M/m) y + (M/m-1)/2

Consequently, you can resize with the command:

vips im_affinei input.img output.img interpolator a b c d dx dy ox oy ow oh

where
interpolator is your choice of method used to interpolate. The current options are bilinear, bicubic, lbb, nearest, nohalo or vsqbs.
a = N/n
b = 0
c = 0
d = M/m
dx = (N/n-1)/2
dy = (M/m-1)/2
ox = 0
oy = 0
ow = N
oh = M

Warning: Compute everything in floating point arithmetic unless the divisions have no remainder.

Warning: With the current crop of interpolators, this approach will not give high quality reductions of images. Use vips_thumbnail for that.

Align centers (generally better for enlarging): With this image size convention, there is no extrapolation near the boundary when enlarging. Instead of aligning the outer corners, we align the centers of the corner pixels.

The affine transformation that does this is
X = ((N-1)/(n-1)) x
Y = ((M-1)/(m-1)) y

Consequently, you can resize with the command:

vips im_affinei input.img output.img interpolator a b c d dx dy ox oy ow oh
where
interpolator is as above
a = (N-1)/(n-1)
b = 0
c = 0
d = (M-1)/(m-1)
dx = 0
dy = 0
ox = 0
oy = 0
ow = N
oh = M

Task of the day: convert a jpg image to 8-bit png

2011-12-30T17:42:00.000-08:00

vips im_copy input.jpg output.png

If you want to set the png compression type (to 9, say, instead of the default 6):

vips im_copy input.jpg output.png:9

new file format system

2011-12-23T04:45:00.000-08:00

vips8 slowly creeps closer. A new system for loading and saving images has just arrived.

You used to specify file formats and give them options like this:

$ vips im_vips2tiff myfile.v newfile.tiff:jpeg

meaning load the file myfile.v, then write it to newfile.tiff in TIFF format with jpeg compression.

The vips8 equivalent is called tiffsave. If you run it with no arguments you get a nice help display:

$ vips tiffsave
usage:
   tiffsave in filename
where:
   in           - Image to save, input VipsImage
   filename     - Filename to save to, input gchararray
optional arguments:
   compression - Compression for this file, input VipsTiffCompression
   Q            - Q factor, input gint
   predictor    - Compression prediction, input VipsTiffPredictor
   profile      - ICC profile to embed, input gchararray
   tile         - Write a tiled tiff, input gboolean
   tile-width   - Tile width in pixels, input gint
   tile-height - Tile height in pixels, input gint
   pyramid      - Write a pyramidal tiff, input gboolean
   squash       - Squash images down to 1 bit, input gboolean
   resunit      - Resolution unit, input VipsTiffResunit
   bigtiff      - Write a bigtiff image, input gboolean

and you can do the equivalent of the old vips7 command above like this:

$ vips tiffsave myfile.v newfile.tiff --compression jpeg

You can also embed options in the filename using the standard vips8 syntax. For example:

$ vips invert fred.jpg jim.tif{compression=jpeg}

Which will load fred.jpg, invert it, then save as a jpeg-compressed tiff.

The old vips7 system is still there and working, though it's now just a thin skin over the new system, so it's fully backwards-compatible.

There's a very similar C API and it's also easy expressed in Python and C++. It's also easy to add support for new formats. We have preliminary documentation and source code available.

Task of the day: autodetect CMYK and convert to sRGB JPEG

2011-12-14T20:40:00.000-08:00

Adam Turcotte, John Cupitt and I have written a C driver for libvips that produces an sRGB JPEG version of an image detected to be CMYK (and does nothing otherwise). The program is called cmyk2srgbjpeg.

USAGE: cmyk2srgbjpeg input_image output_image_name_before_extention

First, cmyk2srgbjpeg checks whether input_image is CMYK. If not, it exits without further ado. Otherwise, cmyk2srgbjpeg imports the input image using the embedded ICC profile (with im_icc_import_embedded) and converts the result to sRGB (with im_icc_export). If there is no embedded ICC profile, or importing with the embedded profile fails (because the ICC is not compatible with CMYK, for example), cmyk2srgbjpeg substitutes a default and uses im_icc_transform, which combines the above two operations. The result is saved in output_image_name_before_extension.jpg.

You need to compile this program. See the source code for pointers.

Several options can be set through #defines:

The path to the backstop ICC colour profile (current default: /usr/local/share/nip2/data/HP5000_UVDuraImageGlossMaxQ.icc);
The path to an sRGB colour profile (current default: /usr/local/share/nip2/data/sRGB.icm);
The return codes (current default: 0 if nothing was done (not CMYK), 1 if the program failed, 2 if conversion was performed with the backstop ICC because the embedded one "didn't work", 3 if this was done because there was no embedded ICC, and 4 if conversion was performed with the embedded ICC);
The JPEG quality setting (current default: 99);
The JPEG extension to be used for the output_image (current default: jpg); and
The color conversion "intent" (current default: relative colorimetric).

I could have had these set with command line options instead, but the program was written for a high volume server environment for which speed of execution (and a small executable) matter more than on the fly configurability.

Code comments hopefully make everything clear.

It should be easy to modify this driver to perform similar tasks.

The code can be downloaded from http://web.cs.laurentian.ca/nrobidoux/misc/cmyk2srgbjpeg.c. It is distributed under the Simplified BSD License. Improvements/bug reports/criticisms are welcome.

P.S. ~~Crashes~~ Now runs correctly on the apparently broken CMYK JPEG found at http://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=19903&p=78647&hilit=cmyk#p78647. The ICC profile embedded in this image does not match its content: 3 band profile VS 4 band image. cmyk2srbgjpeg returns 2 and the result looks fine.

P.S. II You can poke around an image by loading it into nip2, left clicking on the bar on the left of its thumbnail, menuing Toolkits -> Colour -> ICC -> Import, and tinkering with the options after having double clicked on the thumbnail of the result to see it full size. Even if using Toolkits -> Colour -> ICC -> Export on the result with an sRGB profile (or going to Toolkits -> Colourspace -> sRGB), you generally will not get exactly the same results as cmyk2srgbjpeg, especially if the CMYK image has an embedded ICC profile which is understood by VIPS, because in this case the conversion is done in one step by cmyk2srgbjpeg instead of two separate steps that go through a linear float image format as it's done in nip2.

P.S. III Adobe source of ICC profiles: http://www.adobe.com/support/downloads/detail.jsp?ftpID=4075.

P.S. IV Best way to find CMYK images to test with AFAIK: google "cmyk.jpg" or "cmyk.jpeg" (taking the period out also works, as well as just googling "cmyk" or "cmyk images").

P.S. V Finally found a CMYK image (TIFF, not JPEG) that does not look good when passed through the program. It has no embedded ICC and appears to have been produced with a rather whacked one. It is discussed here: http://imagemagick.org/discourse-server/viewtopic.php?f=1&t=19717&p=79318#p79318.

P.S. VI It's likely a TIFF ("Thousands of Incompatible File Formats") issue. See http://imagemagick.org/discourse-server/viewtopic.php?f=1&t=19717&p=79318#p79332.

vips8 progress

2011-11-17T04:09:00.001-08:00

vips8 is coming along quite quickly now. The core was done (more or less)in the last stable release so now in git master we are working through theoperations rewriting them as classes. We've done about 25% of the operationsin the last couple of months.

One of the big new features is optional output arguments. For example,VipsMin is an operation that finds the minimum value of an image. You canrun it from the command-line like this:

$ vips min fred.jpg
12

Very similar to the old im_min. But now there are also optional outputarguments to get the position of the minimum:

$ vips min --x --y fred.jpg
12
2345
245

and you get the same API in Python, Ruby, Javascript, nip2, C and C++:

>> m = im.min()
>> print m
12
>> m, x, y = im.min("x", "y")

VipsImage *fred;
double m;
int x, y;

vips_min( fred, &m,
  "x", &x,
  "y", &y,
  NULL );

Args only need a few of lines of code to add to a class and everythingelse is generated for you automatically at runtime. For example, theoptional --x arg for VipsMin is declared like this:

VIPS_ARG_INT( class, "x", 2,
  _( "x" ), _( "Horizontal position of minimum" ),
  VIPS_ARGUMENT_OPTIONAL_OUTPUT,
  G_STRUCT_OFFSET( VipsMin, x ),
  0, 1000000, 0 );

That binds an optional int arg with the range locked to 0 to10000000 to the member x of the class VipsMin. Your bit of Cjust needs to assign that member and the value will appear in alllanguages and all interfaces.

VipsJoin has one of the fanciest ones. At a minimum it's:

$ vips join left.v right.v out.v horizontal

to join two images left-right, but there are also extra optional arguments, for example:

$ vips join --expand --background 0,255,0 --align centre --shim 50left.v right.v out.v horizontal

to join left-right with a 50 pixel gap, the output expanded to holdall of both left and right, and the background painted green.

You can get a summary of the options by running with no args:

$ vips join
VipsJoin (join), join an image
  join in1 in2 out direction
where:
  in1 :: VipsImage (input)
  in2 :: VipsImage (input)
  out :: VipsImage (output)
  direction :: VipsDirection (input)
optional arguments:
  align :: VipsAlign (input)
  expand :: gboolean (input)
  shim :: gint (input)
  background :: VipsArrayDouble (input)

join: too few arguments
VipsObject: parameter in1 to VipsJoin not set
VipsObject: parameter in2 to VipsJoin not set
VipsObject: parameter direction to VipsJoin not set

vips8 includes full vips7 compatibility. The old interface:

$ vips im_lrjoin left.v right.v out.v

is still there and still works well.

Streaming intro to VIPS video

2011-10-01T08:35:00.000-07:00

Streaming river-valley.tv video of a seminar giving an overview of VIPS.

Major new stable version, 7.26

2011-09-02T05:39:00.000-07:00

The new version is finally officially out. Here's what's new:

New operations: nip2 has a few new menus for drawing, ImageMagick operators and matrix conversion. There's a new approximate convolution operator that can be more than 100x faster than standard convolution, see below.

More permissive operators: All vips operators will now convert their inputs if necessary. This means you can add two images of different sizes, for example, without having to expand one of them first, see below.

Better file format support: The TIFF, JPEG, PNG and FITS readers and writers have all seen useful improvements, see below.

Faster nip2: nip2 now starts quickly enough to not need a splash screen, and should feel more responsive when in use.

VIPS rewrite: The whole of vips has been cleaned up and reorganised. There's now gtk-doc documentation for the whole library. The vips core, iofuncs, has been replaced and is 5,000 lines smaller, simpler, and much more flexible. There's full source compatibility with the old API, but not binary, you will need to recompile, see below.

Plus the usual minor speed-ups, portability improvements, enhancements and bug fixes.

New operations

nip2 has a new menu: Filter / Magick. This has a number of simple ImageMagick filters wrapped up as nip2 operations. On Windows and OS X, nip2 includes its own copy of ImageMagick, so there are no other packages to install.

There's a new Histogram / Convert to Histogram menu item which makes moving between images, matrices and histograms simpler.

There are a set of new items in Matrix / New which make building matrices easier.

Filter / Convolution / Custom Blur/Sharpen has a new precision setting, Approximate. This is slightly less accurate, but typically 10x faster. There's a lot of machinery behind the scenes to support this which needs writing up. It can actually do arbitrary 2D convolutions, though this isn't exposed yet.

Another new menu, Image / Draw, lets you use the paintbox operations like flood, rectangle and circle from menus. This can be very handy for making masks.

More permissive operators

libvips operators used to be rather strict. When adding two images, for example, they had to be exactly the same size. This seemed like a good idea, since it forced users to think about these issues, but it was also very annoying and caused endless mysterious error messages.

libvips has a new philosophy: only fail with an error if you really have to. All operations will now do their best to do something, even if the images are not quite correct. All operations now automatically format-alike, band-alike and size-alike as much as they can.

File formats

The file format support has had quite a bit of work:

Better JPEG handling, including support for embedded thumbnails and decompression from memory.
Better PNG handling, including support for image resolution tags, 1, 2, 4 bit palette images, and the libpng-1.5 API.
Better TIFF handling, including faster loading and support for 1, 2, and 4 bit palette images.
Much faster FITS load and save, much lower memory use, better metadata support, FITS write.

VIPS rewrite

The vips rewrite has been going on for a few years now. 7.26 is probably the largest change so far: the old vips core has been removed and the whole library is now sitting on top of the new system we've been building. There's full compatibility with the old API, but the bones of a new, much better system are there.

The next stage is to start rewriting all the operators to use the new API, and to expose the new system to C++, Python and other languages. There's a little more work necessary on the new C API as well.

Animated clustering

2011-08-12T04:58:00.000-07:00

I made this fun animation of protein clustering:

It uses nip2 to make the frames for the animation, I thought I'd write it up.

Background

This is an experiment with a line of cultured cells. The cells were split into eight batches and each batch given a different treatment. We used proteomics to find the abundance of the most interesting 1000 proteins in each batch. You get a table with 1000 columns and 8 rows, one row for each of the conditions, with the number at each point representing abundance.

Proteins which are related in some way (perhaps they are part of the same bit of biological machinery) ought to rise and fall together as conditions for the cells vary, so we calculated a correlation coefficient for every column against every other column. This gives you a 1000 by 1000 matrix with numbers between -1 and 1. Proteins which are related should have a large number of high values in common.

Clustering

We wrote a small program in Ruby to search for the closest two proteins (proteins are closer if they share a larger number of highly correlated proteins), join them, and loop until there are no proteins that are close together. The results were interesting but it was hard to get much insight into what the patterns the program had found meant.

Animation

To make the animation, we got the Ruby program to write out an interesting part of the matrix every time it joined two proteins. To make the images, start nip2, click File / Open. click on the first frame0001.csv, shift-click on the last, and click Open. This will make a large group of images and should be almost instant since it will only process the first few elements.

Each pixel will have a value in -1 to 1, no good for false colour which needs pixels in 0 to 255. Enter "255 * A1 ** 2" to square each pixel and multiply by 255. Now select Filter / Enhance / False Colour to turn the frames into RGB heat maps. You can see one of the frames by selecting Object / Group to List to make a plain list out of the group, and then selecting Math / List / Head to get the first element (alternatively, enter "A3.value?0" as I did here).

Right-click on the group of RGB images and select Save. Enter "frame00001.png" for the filename and click OK. This will take a minute or so, since nip2 will actually have to process all the images.

You can use ImageMagick to make a GIF of the clustering like this:

$ convert -delay 20 -loop 1 frame*.png cluster.gif

Or mencoder to make an mpeg4 like this:

$ mencoder "mf://frame*.png" -mf fps=10 -o cluster.avi -ovc lavc -lavcopts vcodec=mpeg4

Assembling Marble Earth

2011-08-09T08:02:00.000-07:00

NASA have a wonderful image of the earth on their website:

http://visibleearth.nasa.gov/view_detail.php?id=7104

However it's split into eight 21,600 by 21,600 pixel jpeg images. This blog post builds the image in nip2.

Download all 8 and load them into nip2:

The tiles join in a simple grid. You can use the Image / Join / Left to Right and Image / Join / Top to Bottom menu items to make a set of pair-wise joins. Click A1 to select it, hold ctrl and click A2 to select that as well and click Image / Join / Top to Bottom. Repeat for all the vertical pairs, then use Left to Right to join those strips to make the final image.

You could also use Image / Join / Array to build the mosaic. This menu item expects a 2D array of images and joins them in the obvious way. In the expression box, enter:

[[A1, A3, A5, A7], [A2, A4, A6, A8]]

To make the 2D array, then click Image / Join / Array to make the same image as above.

You can't save this monster as a jpeg, sadly, since jpeg has a limit of 65535 pixels horizontally or vertically. The best option is probably jpeg-compressed tiled tiff. VIPS format also works well, but of course not many other packages can read it.

First beta of major new version, 7.26

2011-07-26T07:27:00.000-07:00

The first beta of the next major version of libvips and nip2, 7.26, has gone up on the development download page. It seems to pass all the tests and work for all our projects, but more testing is very welcome please. If all goes well, this will be released properly before the end of August.

A new philosophy

libvips operators used to be rather strict. When adding two images, for example, they had to be exactly the same size. This seemed like a good idea, since it forced users to think about these issues, but it was also very annoying and caused enless mysterious error messages.

libvips has a new philosophy: only fail with an error if you really have to. All operations will no do their best to do something, even if the images are not quite correct. All operations now automatically format-alike, band-alike and size-alike as much as they can.

A new core

This version has a completely new core for libvips. It's smaller, simpler, and much more modern. See History below for some background on this.

Large, crusty areas of libvips have been formally deprecated. Many fewer command-line programs are installed. Goodbye, cooc_features! The old vips7 API is still supported, but you will need to recompile.

nip2

nip2 hasn't changed that much, but there are a few new things:

Faster startup. It should start more quickly, so the annoying splashscreen has gone.
ImageMagick filters. There's a new menu, Filter / Magick, containing a selection of simple ImageMagick (or GraphicsMagick, depending on how you configure it) effects.
Draw menu. There's a new menu, Image / Draw, containing the paintbox functions as menu items. You can use them to do things like flood-fill images programmatically.
Added many new items to the Matrix / New menu, added Convert to Matrix.
Various small fixes and speedups.

File format support

The file format support has had quite a bit of work:

Better JPEG handling, including support for embedded thumbnails and decompression from memory.
Better PNG handling, including support for image resolution tags, 1, 2, 4 bit palette images, and the libpng-1.5 API.
Better TIFF handling, including faster loading and support for 1, 2, and 4 bit palette images.
Much faster FITS load and save, much lower memory use, better metadata support, FITS write.

Approximate convolution

We've added im_aconv(), approximate convolution. For large masks this can be more than 100x faster than im_conv(). This needs writing up in it's own post, I'll try and get to it.

Minor improvements

Full gtk-doc documentation for all operations.
And as a consequence, no more man pages for libvips operations.
Updated German translation.
Various bugfixes, speedups and portability improvements.

History

About 5 years ago, when nip2 was more-or-less done, we began work fixing up libvips, which had rotted somewhat during nip2's development. There were a couple of false starts but for the last few years we've had a clear plan and we've been making progress on a large-scale modernisation leading up to what should become vips8.

Here's what vips7 looked like inside:

With nip2 in about the same place as the command-line interface. The big problem with this design is that a lot of useful things were added to higher levels of the system which could then not be shared. For example, the C++ binding added automatic reference counting which was then used by Python. nip2 in a separate branch was unable to use this and had to have it's own reference counting system. Equally, nip2 has a very nice recent operation cache which can't be used from Python.

The aim in the vips8 redesign is to improve the core so that these useful features can be pushed down into it and shared between all the interfaces. At the same time, the vips7 core was mostly unchanged since the early 1990s, so we wanted to clean it up and modernise it.

Here's what libvips looks like inside now:

The new system is based on GObject, Gnome's object system. We have a class on top of that with some extra features, then all libvips types are subclasses of that, including all operations. Some interfaces hang directly off VipsObject, others are bound via GObject introspection, a system that lets almost any language use any GObject-based library.

A post back in April introduced the new API, though it's actually changed a bit since then.

New stable version, 7.24.7

2011-07-08T05:51:00.000-07:00

We have a new stable version, 7.24.7. This has three small fixes:

im_conv(), the vips convolver, could lose accuracy with some masks
CMYK JPEG images were not being written correctly, thanks Ole
the TIFF reader can now also read 1, 2 and 4-bit palette images; previously it could only read 8-bit palette

There is a new source tarball and a new win32 binary. There's a new nip2 as well, though the only change is a larger set of self-tests.

http://www.vips.ecs.soton.ac.uk/supported/7.24

Using ImageMagick from nip2

2011-06-23T09:41:00.000-07:00

The development version has an experimental link to ImageMagick in now, built more-or-less in the style of this earlier blog post. There's a Filter / Magick menu with five sample operations, the most complex of which is Annotate, the ImageMagick operation for adding text to an image.

The sourcecode for the Annotate menu item is pretty simple:

Annotate_item = class
Menuaction "_Annotate" "add text annotation" {
action x = class
    _result {
    _vislevel = 3;

    text = text_widget;
    font = Font_widget;
    geometry = Geometry_widget;
    gravity = gravity_widget;
    foreground = foreground_widget;
    antialias = antialias_widget;
    command = magick_command (join_sep " " [
      font._flag,
      antialias._flag,
      gravity._flag,
      foreground._flag,
      "-annotate", geometry._flag, "\"" ++ text.value ++ "\""]);

    _result = system command x;
}
}

But goodness me it turns into a beast when you click it:

It can probably be made a little prettier, but it does need all those options. I suppose sections could be folded away until you needed them.

The menu item supports nip2 Groups, so you can select a set of images and operate on them all at once. There's a toggle in Preferences that lets you switch between ImageMagick and GraphicsMagick (it just prepends "gm" to the command line that gets run). The "command" item shows the command that nip2 is running to generate the image. It knows about adding a ".exe" to the end of the executable name on Windows, though I've not tested that yet.

It seems unlikely that much of the wrapping could be generated automatically: it's just too hard to work out which options modify which operations. Someone would have to go through the docs and make a class for each major command. At least the things are fairly brief.

Image annotation with libvips and Python

2011-05-23T03:10:00.000-07:00

I had a mail asking how to replace a bit of ImageMagick with libvips and Python. Here it is, wrapped up as a blog post.

First, here's the ImageMagick:

#!/bin/sh

convert $1 \
    -background Red -density 300 \
    -font /usr/share/fonts/truetype/msttcorefonts/Arial.ttf \
    -pointsize 12 -gravity south -splice 0x150 \
    -gravity southwest -annotate +50+50 "left corner" \
    -gravity southeast -annotate +50+50 'right corner' \
    +repage \
    $2

This adds a 150-pixel-high red banner to the bottom of an image, for example:

And here's the same thing in Python using libvips. It is rather fiddly, unfortunately:

#!/usr/bin/python

import sys
from vipsCC import *

im = VImage.VImage(sys.argv[1])

zero = VImage.VImage.black(im.Xsize(), 150, 3)

Next we make a red image from the black (zero) image. im.lin(a, b) calculates (im * a + b), that is, it does a linear transform (hence the name). You can pass a number for a and b, or a list. If you pass a list, one list element is used for each image band. So therefore this adds 255 to the first band. The result of lin() is always float, so you need to cast back to 8-bit afterwards.

red = zero.lin([1, 1, 1], [255, 0, 0]).clip2fmt(VImage.VImage.FMTUCHAR)

text(string, font, width, slignment, dpi) renders text with Pango. The text is rendered to fit to a maximum width (-1 meaning no width limit). The image is always one band, 8-bit, with 0 meaning background, 255 meaning text, and intermediate values being used for anti-aliasing.

txt = VImage.VImage.text("left corner", "sans 12", -1, 0, 300)

im.embed(type, left, top, width, height) 'embeds' im within a larger image of size (width, height) at position (left, top). The 'type' field sets how the new background pixels are created: 0 means 'fill with zero'.

txt = txt.embed(0, 50, 50, im.Xsize(), 150)

txt2 = VImage.VImage.text("right corner", "sans 12", -1, 0, 300)
txt2 = txt2.embed(0, im.Xsize() - txt2.Xsize() - 50, 50, im.Xsize(), 150)

txt = txt.orimage(txt2)

condition.blend(a, b) uses the condition image to blend between images a and b. Here we are using the text mask to blend between the red background and the black foreground.

txt = txt.blend(zero, red)

Finally, big.insert(small, left, top) pastes image small into image big at position (left, top), expanding the image as necessary.

im = im.insert(txt, 0, im.Ysize())

im.write(sys.argv[2])

And we're done.

On the plus side, because it's done with a 'real' programming language, you have a lot more flexibility in the way you do the layout. You could write a set of little functions to do the layout for you, and perhaps do a better job of centering the text.

Benchmarking with a 5,000 by 5,000 pixel RGB image on my desktop machine, I get:

$ time ./try70.sh wtc_small.tif test2.tif
real    0m1.179s
user    0m0.880s
sys    0m0.650s
peak RSS 400m
$ time ./try71.py wtc_small.tif test2.tif
real    0m0.549s
user    0m0.290s
sys    0m0.330s
peak RSS 25m

So libvips is about twice as fast in this case and needs a lot less memory. Repeating with a 10,000 x 10,000 pixel RGB TIFF image, I get:

$ time ./try70.sh wtc.tif wtc2.tif
real    0m4.050s
user    0m2.770s
sys     0m2.200s
peak RSS 1.3g
$ time ./try71.py wtc.tif wtc2.tif
real    0m3.206s
user    0m0.970s
sys     0m1.530s
peak RSS 25m

So vips needs roughly constant memory regardless of image size. The speed gain becomes smaller as the images become larger, since less time is spent processing and more time is spent reading and writing tiff.

Using groups in nip2

2011-05-16T03:46:00.000-07:00

nip2 lets you group objects so you can use the menus to operate on many images at the same time. This post will try to explain how to use the grouping system and how it works.

Overview

Let's start with a quick example. Launch nip2, click File / Open, and navigate to a directory of images. Click on the first, shift-click on the last and click Open. You can open up to about 500 images at once, but please don't for this example, five is plenty. The main window should now look something like this:

Right-click on the row button and click Ungroup to open the group. This creates a new row for every group element. It will be unbearably slow for 500 images, but for five it works fine.

Remove the extra rows you made (click on A2, shift-click on the last row, click Edit / Delete). Now click Filter / Convolution / Custom Blur/Sharpen, and set the parameters to be a Gaussian blur. You could pick any other operation, or any combination of operations.

Finally, right-click on the row button for the processed group and select Save As. Enter a filename of the form fred001.jpg and nip2 will save the processed images to fred001.jpg, fred002.jpeg, and so on.

Grouping and ungrouping

There are several ways to form groups. You can make them directly in the file chooser as above, but you can also form them from objects already in the workspace. Click on the first row, shift-click on the last, and select Edit / Group.

Groups can contain any other object, even other groups.

You can also form groups by typing. Enter (for example):

Group [1 .. 4]

You can turn lists into groups and back again, see Object / List to Group and friends. Once a group has been turned to a list, you can use any of the usual list-processing operations to operate on them.

Saving a group will save each of the group elements in turn. You can also ungroup with Edit / Ungroup, though that won't work very well for large groups. For large groups it's usually better to turn the group to a list, then pick out a particular element with list index. This is easy to type:

A15.value?1

Will extract element 1 from a group.

Processing

Almost all of nip2's menu items will automatically loop over groups, as we saw in the introductory example. Almost all of the built-in operations will automatically loop as well. For example, try typing:

12 + Group [1 .. 4]

and you'll see

Group [13, 14, 15, 16]

The system is very general. Going back to the example in the screenshot above typing A15 + 99 gives this:

Groups can have NULL elements, meaning 'skip this item'. This is handy in complex workspaces where not every group element may be valid. If you operate on a pair of groups and one contains a NULL element at some point, the result will also be NULL at that point.

If one group is longer than the other, the results is as long as the shortest group.

A convenient way to develop a workspace is to start out processing a single image, then when everything is working, edit the first row to drop in a group instead.

Limitations

Very large groups don't work very well: you'll find you start to run out of file descriptors if you have more than about 500 source images open at once. For very large jobs you'll be better off using nip2's command-line interface to run a workspace over a set of files.

For technical reasons, nip2's list processing operations don't work well with groups. You'll find you can't type hd A1, where A1 is a group of lists, for example. Fixing this would take a large rewrite of nip2's programming language, sadly.

You also can't use Region on groups, annoyingly. This means that if your workspace includes any regions dragged out with the mouse, you won't be able to just drop a group in. Use Image / Crop instead.

Building VIPS for Windows

2011-05-03T06:52:00.001-07:00

[Update 25/2/11: Rob's improvements have been merged back into the main win32 build system, with some small changes, and I've updated this post to reflect this]

VIPS (as well as NIP) has an excellent history of providing executables to the Windows users of the world with regular stable releases.
Yet there always seems to be one individual who does not desire to wait for the next stable release, and would really like to see a windows executable with the latest patch built sooner.
That guy is usually me! Particularly once John resolved the n-bit palette tiff reader bug recently. However, there is no Visual Studio build for VIPS, and the normal ./configure && make && make install commands tend to fail horribly on a non-UNIX platform.

Why No Visual Studio Build?

It is all about the dependencies. VIPS has approximately thirty libraries that it depends on, and all of those libraries are native *nix libraries. In order to compile VIPS in Visual Studio, you would need to find win32 Dynamic Linked Libraries (DLLs) compiled for each. No easy task, as many of them do not provide a supported win32 build.
Your other option is build each of the libraries yourself and thus provide your own win32 DLL for linking with VIPS. While a noble idea, and one I would love to see someone else make happen, this quickly becomes complicated by the fact that the libraries that need to be compiled have other dependencies themselves. You quickly find that the number of builds you must support in order to manage building VIPS grows to something even more daunting than the dependencies VIPS is directly linked against.

Cross Compiling - MinGW

MinGW provides a complete Open Source programming tool set which is suitable for the development of native MS-Windows applications, and which do not depend on any 3rd-party C-Runtime DLLs. (It does depend on a number of DLLs provided by Microsoft themselves, as components of the operating system; most notable among these is MSVCRT.DLL, the Microsoft C runtime library. Additionally, threaded applications must ship with a freely distributable thread support DLL, provided as part of MinGW itself).
Although primarily geared towards developers working on the MS-Windows platform itself, we run a cross-compiler variant of the MinGW tools on Ubuntu to generate win32 applications for deployment to MS-Windows.

What About Those Libraries?

The GNOME project has us covered, given that they do quite a bit of work with WINE and other windows emulators, they need a large number of libraries compiled as DLLs as well!
Someone very clever is about to ask, “Why don’t we just use the GNOME DLL’s as our Visual Studio Links?” Unfortunately, it's difficult to target MSVCRT.DLL in VS, unless you start doing tricks with the driver development toolkit. It is sort-of possible to mix C runtimes in one program, but really not advisable.
The more appropriate answer is that John already had a JHBUILD setup to take advantage of MinGW on Ubuntu, and it worked. Certainly far easier than tackling the creation of a Windows Build.

Getting Started

Head over to github and grab the latest from the jcupitt/build-win32 repository. From there, take a quick peak at the README information that shows up at the bottom of the page. For the 7.24 build, it looks something like this:

7.24/README.md

VIPS WIN32

We use jhbuilder to git, mingw to compile, and good old zip to package the vips source code for WIN32.

JHBuild

JHBuild is a tool designed to ease building collections of source packages, called “modules”. JHBuild uses “module set” files to describe the modules available to build. The “module set” files include dependency information that allows JHBuild to discover what modules need to be built and in what order.

MinGW

MinGW, a contraction of "Minimalist GNU for Windows", is a minimalist development environment for native Microsoft Windows applications.

MinGW provides a complete Open Source programming tool set which is suitable for the development of native MS-Windows applications, and which do not depend on any 3rd-party C-Runtime DLLs. (It does depend on a number of DLLs provided by Microsoft themselves, as components of the operating system; most notable among these is MSVCRT.DLL, the Microsoft C runtime library. Additionally, threaded applications must ship with a freely distributable thread support DLL, provided as part of MinGW itself).

PREREQUISITES

Ubuntu Desktop - This doesn't mean you can't get the process to work on anything else. This is simply what we are using and know to work. Tested on 10.10 and 11.04, 32- and 64-bit. Though you can only make a 32-bit Windows binary for now.

OPTIONAL

VMware Player - Bubba runs his Ubuntu Desktop in a VMWare Player on a Windows 7 Ultimate x64 Desktop host.

DEPENDENCIES

It is possible that you already have some of these installed on your Ubuntu Desktop; however, it is not likely that you have all of them. Better safe than sorry, install them all. You might even want to update the whole kit, just for the heck of it.

Build/Tool Related Dependencies

sudo apt-get install build-essential \
wine \
mingw32 \
jhbuild \
autoconf \
automake1.4 \
automake1.7 \
automake1.9 \
autotools-dev \
docbook-utils \
docbook2x \
gtk-doc-tools

Library Dependencies

sudo apt-get install libatk1.0-0 \
libatk1.0-dev \
libglib2.0-0 \
libglib2.0-dev \
libgtk2.0-0 \
libgtk2.0-dev \
libglade2-0 \
libglade2-dev \
libgsf-1-114 \
libgsf-gnome-1-dev \
libpango1.0-0 \
libpango1.0-dev \
libcairo2 \
libcairo2-dev \
libexpat1 \
libexpat1-dev \
libfontconfig1 \
libfontconfig1-dev \
libfreetype6 \
libfreetype6-dev \
gettext \
libpng12-0 \
libpng12-dev \
libxml2 \
libxml2-dev \
tango-icon-theme \
libcxxtools6 \
libcxxtools-dev \
zlib1g \
zlib1g-dev \
zlibc

These are Ubuntu binaries and of course we will be building a Windows binary. However, some of the packages we build are not very good at cross-compiling and builds can fail unless they can find a native library as well.

CONFIGURATION

You will need to first check out this repository, if you haven't already.

git This

mkdir ~/dev
cd ~/dev
git clone git://github.com/jcupitt/build-win32.git
cd build-win32/7.24

GNOME win32 Packages

As we are building a win32 executable, we need some DLLs to link against, and the GNOME project kindly provides us with a large number of these ready to use!

Run this script to create some directories for zips, tarballs and the build tree and download all the zips you need from Gnome:

./get-win32-packages.sh

If you desire to modify the packages used, just open up the script and edit the list near the end. This is completely optional though, as the ones checked out "should" work just fine for you needs.

After downloading, run the unpack script to unzip the files to your build area:

./unpack.sh

JHBUILD VERIFICATION

We just want to make sure that jhbuild has everything it needs. If all steps have been properly followed up to this point, this should be a no brainer.

jhbuild --file=jhbuildrc sanitycheck

This will most likely complain that it couldn't find automake-1.8 which is fine, we didn't install that. If it complains about anything else, let me know.

BUILD

jhbuild --file=jhbuildrc --moduleset=vips.modules build libvips

PACKAGE

./package-vipsdev.sh

BUILD NIP2

jhbuild --file=jhbuildrc --moduleset=vips.modules build nip2

./package-nip2.sh

UPLOAD YOUR PACKAGE

Assuming everything has worked perfectly up to this point, you will find vips-dev-7.24.5.zip all packaged up and ready to go. You might upload it to your favorite server via scp like this:

scp vips-dev-7.24.5.zip <YOURID>@<YOURSERVER>:/your/favorite/directory

scp nip2-7.24.5-setup.exe <YOURID>@<YOURSERVER>:/your/favorite/directory

CLEAN UP

It is always good to clean up after yourself. Be careful though, this command will delete the package you just created! You did upload it to your favorite server didn't you?

./clean.sh

You'll need to run the unpack script again if you clean up. You won't need to redownload the zips though.

OTHER NOTES

Version Numbers

The scripts currently default to a versioning system of package-major.minor.micro-release like so 7.24.5-1 in order to make everything drop dead simple.

However, it is really preferred for you to version your own package micro-releases.

You can modify the versions by editing these scripts:

clean.sh
package-vipsdev.sh
package-nip2.sh

Patching

A primary reason one might desire to build their own executable, you simply want to make a few changes to the code, or otherwise control how it was compiled.

First, build as described above:

./unpack.sh

jhbuild --file=jhbuildrc --moduleset=vips.modules build libvips

Now go to checkout/vips-7.24.5 and make any source changes you want. Build again to compile your changes.

jhbuild --file=jhbuildrc --moduleset=vips.modules build libvips

And package your new version.

./package-vipsdev.sh

I suggest you rename your zip to avoid confusion. Call it something like vips-dev-7.24.5-rob1.zip.

Conclusion

We have made it as simple as we possibly can to get your win32 build whenever you want it! There is also something a little bit tantalizing about building for Windows on Ubuntu, it’s like forbidden fruit or something. If nothing else, you should build vips.exe simply so that you can say you have cross-compiled an application!

nip2 as a GUI for ImageMagick

2011-04-26T05:05:00.000-07:00

VIPS has an operation, im_system_image(), that lets you run a command-line program on an image. You can use it to run ImageMagick commands from nip2's menus.

im_system_image() writes the image to a temporary file, creates another filename for the output, uses popen() to run a command on it, loads the output file and returns that image. It arranges for the temporary files to be deleted when they are no longer needed.

You can call this function from nip2. Load a test image (perhaps A1) and click Toolkits / Widgets / Scale to make a slider (perhaps A2). Now at the bottom of the column, type:

"convert %s -swirl " ++ print A2.value ++ " %s"

This will make A3, the template for the command-line we want to run. The first %s will soon get substituted for the input filename and the second for the output filename. If you drag the slider, you'll see that your command-line updates.

(You may need to edit this a bit. For example, on Windows, you might need to give the full path to the convert program, and you'll need a .exe suffix as well. You might want to use GraphicsMagick instead, in which case you'll need "gm" at the front)

Now type this:

im_system_image A1.value "%s.tif" "%s.tif" A3

This will run im_system_image on the VIPS image underlying the nip2 object A1, with "%s.tif" as the template for the input and the output filename. The %s in the input and output filename templates will be substituted for something like /home/john/.nip2-7.24.1/tmp/348963498523-, depending on your platform. You can use the filename templates to set the file format that is used to pass your image to the program you are running.

If everything works, you'll get a two-element list back with the first element being the processed image and the second being all the output that the program sent to stdout while it ran. To view the processed image, you need to wrap it up in nip2's Image class. Just run the constructor on it:

Image A4?0

That is, pull element zero out of A4 (the result of im_system_image) and use it to build an instance of Image.

Now drag your slider, and the image should update! The scale widget defaults to the range 0 to 255, which is not really right for swirl. Doubleclick on the A2 button and set the range to -360 to +360. You could set the caption to something like "Swirl angle" too.

You can make a menu item that does all this with a click. Click Toolkits / Edit, select the Filter toolkit (this seems like a good place for it) and copypaste this code in:

Swirl x = class _result {
_vislevel = 3;
angle = Scale "Swirl angle" (-360) 360 0;
_result
= Image (im_system_image x.value fmt fmt cmd)?0
{
prg = "convert";
options = "-swirl " ++ print angle.value;
cmd = join_sep " " [prg, "%s", options, "%s"];
fmt = "%s.tif";
}
}

Select File / Process to get nip2 to update. Now you can select any image and click Toolkits / Filter / Swirl to swirl it. It would be pretty easy to make menu items for all the ImageMagick commands this way. You could even write a tiny bit of Python or Ruby to generate the code for you from the ImageMagick website.

Finally, that was the simplest, but not the best way to make a menu item. Here's a slightly fancier version:

Swirl = class
Menuaction "_Swirl" "swirl an image" {
action x = class
_result {
_vislevel = 3;
angle = Scale "Swirl angle" (-360) 360 0;
_result
= map_unary swirl x
{
prg = "convert";
options = "-swirl " ++ print angle.value;
cmd = join_sep " " [prg, "%s", options, "%s"];
fmt = "%s.tif";
swirl x = Image (im_system_image x.value fmt fmt cmd)?0;
}
}
}

This version will work correctly with Groups (so you can automatically loop over sets of images) and have a mnemonic and a tooltip.

Gegl with libvips as the back end (updated)

2011-04-14T10:09:00.000-07:00

(since first making this post I've done a bit more work on gegl-vips, so this is version 2.0)

I've put up a quick hack of gegl-0.1.6 which uses libvips to process images. It might be a way to put numbers on various possible optimisations of gegl.

https://github.com/jcupitt/gegl-vips

It has some severe limitations. First, it will not work efficiently with interactive destructive operations, like "paint a line". This would need area cache invalidation in vips, which is a way off. Secondly, I've only implemented a few operations (load / crop / affine / unsharp / save / process), so all you can do is some very basic batch processing. It should work for dynamic graphs (change the parameters on a node and just downstream nodes will recalculate) but it'd need a "display" node to be able to test that.

Test program

Here's the test program I've been benchmarking with:

#include <stdio.h>
#include <stdlib.h>

#include <gegl.h>
#include <vips/vips.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", 1.2, // diameter 7 mask in vips
                               //"std-dev", 1.0, // diameter 7 mask in gegl
                               NULL);
  save = gegl_node_new_child (gegl,
                              "operation", "gegl: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);
}

ie. load, crop 100 px off the edges (you need to give it a 5k x 5k RGB image), bilinear 10% shrink, sharpen, save.

See:

http://www.vips.ecs.soton.ac.uk/index.php?title=Speed_and_Memory_Use

for results with other libraries.

Compile with:

gcc -g -Wall gegl.c `pkg-config gegl vips-7.25 --cflags --libs`

and run with something like:

$ time ./a.out wtc_small.png wtc2.png

Results
If I run the test program linked against gegl-0.1.6 on a 5,000 x 5,000 pixel RGB PNG image on my laptop (a c2d at 2.4GHz), I get 96s real, 44s user. I tried experimenting with various settings for GEGL_SWAP and friends, but I couldn't get it to go faster than that, I probably missed something. Perhaps gegl's disk cache plus my slow laptop harddrive are slowing it down.

Linked against gegl-vips with the operations set to exactly match gegl's processing, the same thing runs in 27s real, 38s user. So it looks like some tuning of the disc cache, or maybe even turning it off for batch processing, where you seldom need pixels more than once, could give gegl a very useful speedup here. libvips has a threading system which is on by default and does double-buffered write-behind, which also help.

I investigated some other optimisations:

If you use uncompressed tiff, you can save a further 15s off the runtime. libpng compression is slow, and even with compression off, file write is sluggish.
The alpha channel is not needed in this case, dropping it saves about 5s real time.
babl converts to linear float and back with exp() and log(). Using lookup tables instead saves 12s.
The gegl unsharp operator is implemented as gblur/sub/mul/add. These are all linear operations, so you can fold the maths into a single convolution. Redoing unsharp as a separable convolution saves 1s.
Finally, we don't really need 16-bit output here, 8 is fine. This saves only 0.5s for tiff, but 8s for PNG.

Putting all these together, you get the same program running in 2.3s real, 4s user. This is still using linear float light internally. If you switch to a full 8-bit path you get 1s real, 1.5s user. Gegl is committed to float, but it's interesting to put a number on the cost.

TODO
A screen output node would be fun to experiment with.

The tests ought to be repeated on a faster machine, especially one with a faster hard disk.

New stable version, 7.24.5

2011-04-04T09:57:00.000-07:00

We have a new stable version, 7.24.5. This has two small fixes:

The gamma was not being set correctly on png write, causing images to appear washed out in programs like Firefox. This is an error introduced in the previous version.
The tiff reader was confused by strip images where the entire image was one strip and there was no rows_per_strip field, or the rows_per_strip was set to UINT_MAX.

Anyway, both these small problems are fixed. There is a new source tarball and a new win32 binary.

http://www.vips.ecs.soton.ac.uk/supported/7.24

New API takes shape

2011-03-30T04:28:00.000-07:00

libvips has had the same interface for C programmers since 1990, with just a few additions. We've been trying to make a fresh start for a while and it seems to be finally happening.

The current development version has a new core rebuilt on top of GObject. Everything is stripped down, cleaned up and much more consistent. All types are created and destroyed with the same few functions, we have reference-counting everywhere (so object lifetime management is mostly automatic), and VipsObject includes a simple layer which adds full runtime introspection (so all interfaces to libvips can always present all the available features).

The old, busted IMAGE and REGION types have become the fresh, new VipsImage and VipsRegion classes. Like all GObject classes, you create them with g_object_new() (or a convenience function, like vips_image_new_from_file()) and unreference them when you're done with g_object_unref().

Image-processing operations, like "add image1 to image2", are also classes. You run them with on images with something like:

vips_operation_new ("add", image1, image2, out, NULL);

Where the NULL marks the end of a list of name / values pairs listing optional arguments defined by VipsAdd or one of its superclasses.

Internally, vips_operation_new() searches the class hierarchy below VipsOperation for a class whose nickname is "add", makes an instance of that class with g_object_new(), loops over the required construct-time properties setting them from the arguments to the C function, then loops over the rest of the C args up to the NULL setting optional named construct-time properties.

Sadly there's therefore no type safety. So there's also a convenience function:

int vips_add (VipsImage *in1, VipsImage in2, VipsImage *out, ...);

And a macro which provides vips7 compatibility:

#define im_add(IN1, IN2, OUT) (vips_add(IN1, IN2, OUT, NULL))

The Python binding works at the vips_operation_new() level and overrides ".", so you can write:

out = image1.add (image2)

and it turns into the call to vips_operation_new() above. Since almost the whole Python binding is generated at runtime, it's very small and will adapt automatically as new operations are added.

So far only one operation has been redone in the new API. The other 299 are all there and working via a set of macros which implement the old vips7 API on top of the shiny new vips8 one. The vips7 compatibility macros are good enough that nip2 also works on the new system with no changes.

The next stable release, due rather soon now, will include this new core. We see vips8 as emerging slowly over the next year or so as, one by one, the old vips7 operators are moved to the new API. When everything is swapped over, we'll document the new API, bump the version number to vips-8.0, and have a large party.