progressive jpg images need loads of memory, we shouldn't cache them by
default ... our called can hold a ref if they want to keep the image
around
see https://github.com/jcupitt/libvips/issues/387
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
works, but is no faster, how odd
john@kiwi:~/pics$ time vips magickload nipguide.pdf[40] x.tif
real 0m0.244s
user 0m0.212s
sys 0m0.040s
$ time vips magickload nipguide.pdf x.tif --page 40
real 0m7.035s
user 0m6.900s
sys 0m0.152s
both give same result
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
