What's_New_in_7.22
This page summarises the changes for version 7.22. We have a detailed VIPS ChangeLog and nip2 ChangeLog, but as headlines:
VIPS rewrite : We've redone five more packages, just another 9 to go. See the API docs for the new stuff.
New threading system : VIPS has a new threading system. You should notice a good performance improvement, especially on machines with more than two processors. See below for some details.
New image repaint system in nip2 : The nip2 image repaint system has been rewritten and should feel a lot faster and look a lot prettier. These changes really help the paintbox. See below for details.
New command-line program, vipsthumbnail : VIPS has a new command-line program called vipsthumbnail. It makes high-quality image thumbnails quickly and uses little memory, see below.
Improved interpolators : The bilinear and bicubic interpolators are slightly faster and quite a bit more accurate. The more experimental non-linear interpolators have moved on another generation, see below for details.
New Windows and Mac build systems : We have all-new Windows and Mac build systems, based on jhbuild. See Build on OS X and Build on windows for details.
German translation : libvips (but not yet nip2, sadly) now has a German translation. This is our first attempt at a translation file, so there are probably some rough edges. See below for details.
PFM (portable float map) image format read and write : This image format is sometimes used for HDR photography. VIPS can now read and write it.
Much lower VM use with many small images open : You should notice a dramatic reduction in virtual memory use if many small images are open at once.
Rewritten flood-fill : The flood-fill family of functions have been rewritten and are about 4 - 5x faster. You can now use them for labelling image regions.
Plus the usual minor speed-ups, enhancements and bug fixes. What's New in 7.20 is still there if you're interested.
libvips has a new distributed threadpool. In this model, rather than having a manager thread handing out work parcels, threads assign themselves work under a pool mutex. This produces a dramatic drop in the number of synchronisations operations needed to keep everything in step, and as a result, a good improvement in scaling as you add more processors.
Here's a not-very-real-world-demo:
$ time vips --vips-concurrency=1024 --vips-tile-width=16 --vips-tile-height=16 im_rot90 wtc.v wtc2.v
real 0m10.155s
user 0m7.940s
sys 0m2.400s
$ time vips --vips-wbuffer2 --vips-concurrency=1024 --vips-tile-width=16 --vips-tile-height=16 im_rot90 wtc.v wtc2.v
real 0m6.067s
user 0m1.450s
sys 0m0.890s
So we've probably doubled the efficiency of the threading system, though unfortunately the threading stuff is not a bottleneck at the moment for most users.
There are two more related improvements: first, libvips now automatically detects the number of available processors and uses all it can. You can override the detected setting with --vips-concurrency and IM_CONCURRENCY, as before. Secondly, im_render(), the screen sink operation, has been rewritten to use the new threading system and is much, much faster. You should see a noticeable improvement in screen repainting in nip2.
nip2 has a new image repainting system. It should feel a lot better:
- nip2 always repaints images in sections following tile borders. If a tile is not yet ready, it defers that section of the paint action. This means it will never paint a black tile and then a moment later repaint with pixels.
- Invalidation is handled cleanly. If you paint on an image, downstream caches, including image tile caches, are all marked invalid. When vips later tries to reuse one of these cached areas, it knows to drop cache and recalculate. Invalidation is used no more frequently than necessary.
- The system for propagating changes through an image and its views has been rewritten and tuned. It should only need the minimum number of paint actions to update a view.
The new changes really help the nip2 paintbox. You can open a complex workspace, paint on one of the images, and it should keep up with your changes and never error or mispaint.
VIPS has a new command-line program, vipsthumbnail.
This is a simple program to make image thumbnails. It's fast and needs very little memory. Run it like this:
$ time vipsthumbnail wtc.jpg
real 0m0.452s
user 0m0.410s
sys 0m0.040s
That makes tn_wtc.jpg, the original 10,000 x 10,000 pixel RGB image sized down to fit inside 128 x 128. It needs about 5MB of memory. By contrast, ImageMagick is slower:
$ time convert -define jpeg:size=256x256 wtc.jpg -thumbnail 128x128 -unsharp 0x.5 tn_wtc.jpg
real 0m3.772s
user 0m3.230s
sys 0m0.510s
And needs about 700m of memory.
Features:
- can thumbnail any image format supported by vips
- colour management
- three-stage resample: block average by integer factor to size above final dimensions, bilinear (by default) resample to final size, sharpen
- if the decompressed image is below a certain size, vipsthumbnail will decompress to memory before thumbnailing. Above this threshold, it decompresses to a temporary disc file and then shrinks from that. You can use this to limit the maximum memory that vips needs to thumbnail an image
- command-line options to control colour management, threading, file formats, thumbnail name, location and size, maximum memory use, interpolation scheme, and so on, see the man page for details.
In order to minimize interface changes when a new generation is introduced, nip2 now identifies novel interpolators with descriptive names:
- upsize is (and always will be) a good all-purpose resampler.
- upsmooth is a resampling filter which minimizes staircasing ("jaggies") at the expense of additional blur, to be used, for example, with "text-like" images. Upsmooth is also a decent method for mild downsampling (image shrinking by a factor of up to about 3).
- upsharp is a "sharper" resampler to be used when blur is particularly undesirable. Use, for example, with slightly blurry photographs.
In vips-7.22:
- nip2 upsize links to the novel method LBB (Locally Bounded Bicubic; lbb in the VIPS library),
- nip2 upsmooth links to the novel method VSQBS (Vertex Split subdivision with Quadratic B-Splines smoothing; vsqbs in the VIPS library),
- nip2 upsharp links to second generation Nohalo (nohalo in the VIPS library), a sharpening subdivision method finished with LBB instead of bilinear as was done in the first generation.
LBB, VSQBS and Nohalo resample without introducing (significant) haloing. In addition, VSQBS and Nohalo minimize staircasing by "straightening diagonals."
The nonlinear LBB and Nohalo (nip2 upsize and upsharp) are fairly complex; they run 2-5 times slower than bilinear. VSQBS (nip2 upsmooth), on the other hand, is an extremely fast linear method, faster even than classical (linear) bicubic methods. Caveat: Unlike vips bicubic, vips vsqbs always computes in double precision; for this reason, vips bicubic may run faster than vips vsqbs on a computer with a weak FPU even though the VSQBS method is intrinsically cheaper.
Only one of these brand new methods is published: First generation Nohalo is discussed in http://doi.acm.org/10.1145/1557626.1557657. For more information, see the VIPS source code. (Side comment: Templates.h contains a novel method for calculating Catmull-Rom cubic coefficients which computes each group of four weights with only 10 flops (4 multiplications, 1 addition and 5 subtractions).)
The future: LBB is likely to become the next upsharp, Jacobian-adaptive VSQBS is likely to become the next upsize, and Jacobian-adaptive Snohalo ("smooth no halo") is likely to become the next upsmooth.
We've been sent a translation to German by Chris Leick. For example:
$ LANG=de_DE.utf8 vips --help
Aufruf:
vips [OPTION …] - VIPS-Treiberprogramm
Hilfeoptionen:
-?, --help Hilfeoptionen anzeigen
--help-all Alle Hilfeoptionen anzeigen
--help-vips VIPS-Optionen anzeigen
......
Nice!