What's New in 7.32
- Save as Zoomify and Google Maps formats
- The DeepZoom pyramid builder can now also save images in Zoomify and Google Maps formats, plus the whole thing is much faster, see below.
- Rewritten colour and resample packages
- The libvips packages for colour work and for image resampling have been rewritten for vips8. They are faster, more accurate, easier to use and a lot more flexible. See below.
- Arithmetic improvements
maxnow have an option to track the top (or bottom) n points. The last few operators have been vips8-ed, or deprecated.
- Image load and save improvements
- The JPEG load and save operators are much better at preserving image metadata. They also now preserve IPCT data. Openslide read is now threaded and the vips tile cache aligns with the openslide one, for a good speedup.
- New nip2 stuff
- Much better colour temperature support, better definition browser, better matrix display, better matrix creators.
Plus the usual minor speed-ups, portability improvements, enhancements and bug fixes. What's New in 7.30 is still there if you're interested.
Save as Zoomify and Google Maps
The DeepZoom writer can now also write Zoomify and Google Maps formats. There are also options to centre the image, to write just a single pyramid layer and to control the background colour. It's now threaded for read as well as write, so for source images with a complex compression type, such as jpeg2000, you get a very nice further speedup.
Write in google maps format like this:
$ vips dzsave huge.tif my_google_maps_dir --google
Or zoomify like this:
$ vips dzsave huge.tif my_z_dir --zoomify
Openslide read is now threaded, which gives a good speedup for jpeg2000 images. For example, here's vips-7.30 processing a 60,000 x 60,000 jp2k image on my laptop:
$ time vips dzsave 50310.svs x real 23m37.055s user 25m19.183s sys 1m34.958s
Although my laptop has several cores I didn't get any benefit here --- the very slow single-threaded jp2k read dominated the test. There was also an issue with cache alignment that caused repeated decompression.
With vips-7.32 we have read threading and as a result there's much more speed:
$ time vips dzsave 50310.svs x2 real 6m2.108s user 14m31.050s sys 0m58.168s
No repeated decompression plus full threading give almost a 5x speedup. It really is very, very fast now. It should work on images of any size too.
New colour package
This libvips has a rewritten package of colour operators --- this rewrite has been talked about on the libvips blog back in November.
The colour package in libvips has operations to move images between colourspaces, import and export to and from device spaces, and calculate various colour difference metrics.
A new operator called
colourspace knows about all the converters and will use the right sequence of them to perform any conversion you need. For example:
$ vips colourspace wtc.jpg wtc.v xyz
will convert the JPEG file
wtc.jpg to CIE XYZ and save it to wtc.v. JPEG files are assumed to be in sRGB colourspace; use the ICC import operation if you want to go via a profile.
The conversions to and from sRGB have been improved. They are now very accurate, support 8- and 16-bit images, and are about twice as fast. There's also support for scRGB images: this is sRGB unpacked to linear float.
They will now work on just the first three bands. If you run sRGB2XYZ on a four-band image, for example, the fourth band will be removed, the first three converted, and the fourth band reattached. This makes it easy to work with PNG images with an alpha channel.
The colour difference operations will use
colourspace to do automatic conversions for you. For example, you can do:
$ vips dE00 a.tif b.jpg c.v
And vips will turn both the two input images to CIELAB for you before calculating the dE 2000 metric.
New resample package
The resample package has been vips8-ed as well. This has things like
affine in. The new
affine operator has a fair number of options and replaces the whole family of
im_affine* operators we had previously.
All operators now use corner convention for interpolation. The affine opertor now supports input space coordinate displacement, so you can easily roll up other conventions if you wish.