we were not setting the access hint on arrayimage args, so
arrayjoin "$(echo *.jpg)" x.tif[bigtiff] --across 10
would open all the jpg images to memory, usually, in random mode
now arrayimage args see the operation's access hint (seq in this case),
for much better behaviour
also, we allow any whitespace as an arg separator in arrayimage from
string
it was a bit granular (since it was designed for offset work), make sharpen
easier to adjust for smaller effects
- new 'sigma' parameter
- greater parameter range
- more self-tests
- Remove the nocache stuff for prog jpg images. There was no saving in
practice, since operations downstream could be cached.
nocache is for objects that can change, not for memory saving
- Call _destroy on the decompress object much earlier, it frees a huge
amount of memoey for prog jpg images.
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
