vips_unpremultiply() always outputs float. If you save the output of
vipsthumbnail to a format that supports float files, like tiff, it won't
ever get cast back to the source format.
Example:
$ vipsheader Opera-icon-high-res.png
Opera-icon-high-res.png: 3056x3325 uchar, 4 bands, srgb, pngload
$ vipsthumbnail Opera-icon-high-res.png -o x.tif
$ vipsheader x.tif
x.tif: 117x128 float, 4 bands, scrgb, tiffload
This change makes it note and restore BandFmt aropund pre/unpremultiply.
See https://github.com/jcupitt/libvips/issues/447
GM is still using the old page interface of subimage/subrange, IM has
deprecated that in favour of scene/number_scenes
we were accidentally just supporting the new IM system ... this change
adds support for GM as well, plus a configure test to pick one
see https://github.com/jcupitt/libvips/issues/423
jpeg write is more careful about removing exif tags that have been
removed from the image metadata
it failed previously if there were multiple Orientation tags
you can now put options like [scale=2] at the end of out_format ...
these are stripped before running the command, but use to load the
output image back into libvips again
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.
