Previously vips just called Mat_Open() to test if a file was a Matlab
save file, but this is rather unreliable. For example, some JPEG files
can crash libmatio, and it can incorrectly think that at least some JP2
files are Matlab save files.
Instead, look for "MATLAB 5.0" at the start of the file. This is really too
specific, the first 116 bytes of a Matlab save file are freeform text,
but in practice all Matlab writers use the first few bytes to record the
file type.
See https://github.com/jcupitt/libvips/issues/385
We had exception specs on the C++ interface, but C++11 does not support
them and some compilers have never honoured them. Remove all specs.
Thanks Lovell.
See https://github.com/jcupitt/libvips/issues/362
we had both a class member bandjoin, and an instance member
Vips.Image.bandjoin([i1, i2, i3..])
i1.ibandjoin([i2, i3..])
this was confusing and annoying ... get rid of the class one and just
use bandjoin everywhere, so this is now the way to do it:
i1.bandjoin([i2, i3..])
oh argh class and instance methods are in the same namespace, so we have
to rename the instance one as ibandjoin
also, start adding a test for arrayjoin
takes a copy of a memory area when making an image ... this helps bindings
for languages which don't have much control over memory
see https://github.com/jcupitt/libvips/issues/346
dzsave now uses :strip => true for all tiles. There's no point adding
all the metadata to every tile, so hopefully this won't break anything.
Thanks Benjamin, see: https://github.com/jcupitt/libvips/issues/349
small improvements to vips_resize() quality:
* turn down the anti-alias filter a little so we don't smudge out texture
* don't do the final sharpening pass if we skipped the anti-alias filter
* fix a >/>= mixup which meant we didn't sharpen for small resizes
sizealike() / formatalike() and bandsalike() used to just vips_copy() if
the image didn't need any changes ... this was fast, but left a
vips_copy_gen() in the pipeline, wasting a lot of space on the C stack
during recursion.
They now vanish completely if the image is already in the right format.
Since we call them before most image processing operations, and
often all three of them, this saves a lot of C stack, more than x2 even
in simple cases.
There might also be a measureable CPU saving if the operations are very
simple (eg. insert).
See:
http://stackoverflow.com/questions/33658795/difficulty-with-handling-very-large-image-using-vips
