added VIPS_COUNT_PIXELS(), use like this:
static int vips_shrinkh_gen( VipsRegion *or, ... )
{
VIPS_COUNT_PIXELS( or, "vips_shrinkh_gen" );
}
and on image close, if more than 100% of the pixels have been
calculated, you get a warning
only if you enable debugging, since this hurts perf slightly
vips has built-in support for rad, analyze and ppm ... add configure
switches to disable these readers
useful to reduce the attack surface in some applications
we had a custom wrapper for bandjoin(), but bandrank(), a function with
an almost identical interface, did not ... this was confusing
bandrank() now has a custom wrapper too ... this breaks API
unfortunately, but hopefully very few people were using this thing and
it's better to make this change as soon as possible
before, im.cast(uchar, shift = true) where im was float and tagged as
rgb16 would not shift the image, since it's unclear how much to shift a float
type by
now we do two casts: first, we guess the numeric range from the
interpretation, so rgb16 would be ushort, so we cast float->ushort;
second, we cast to the target type and do the shift on the way
see https://github.com/jcupitt/libvips/issues/397
thanks apacheark
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
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
doesn't seem to slow us down significantly ... before:
$ time vips dzsave CMU-1.svs x --layout google --background "243 243 243 255"
real 1m1.940s
user 2m15.004s
sys 0m37.092s
after:
$ time vips dzsave CMU-1.svs x --layout google --background "243 243 243 255"
strip_work: skipping blank tile 176 x 67
strip_work: skipping blank tile 21 x 112
real 1m3.503s
user 2m16.012s
sys 0m40.328s
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
the tiff saver was writing all five-band images as CMYKA, even if they
were tagged as srgb ... it now follows the interpretation tag and will
write many alpha channels instead
see https://github.com/jcupitt/libvips/issues/348
thanks sadaqatullahn
ruby gobject-introspection is quite fussy about needing a lot of const
declarations ... these changes help vips_image_matrix_from_array()
appear in Ruby
we used to issue a warning and return early, but this can leave garbage
in the *value pointer, I think
ruby gobject-introspection will walk object props during GC and can see
state inbetween init and build when not all objects have been given a
value ... we don't want these warnings
change exif names again: we were storing under @title, but that's both
subject to i18n, and unlookupable in libexif
we now use @name, which is not subject to i18n and can be searched for
... this will break most code which expects certain exif tag names
also, when we update exif, allow any tag, not just updates to existing
tags, see:
https://github.com/lovell/sharp/issues/189
