vips_math2_const(), vips_boolean_const() and vips_relational_const() had
the const and oper args reversed from the Python/CLI/C++ API
add something to check for arg priority conflicts and resolve the
conflicts it found
we weren't multiplying through alpha in vips_region_shrink(), causing
fringing on pyramids with transparent elements
thanks sickrandir!
see https://github.com/jcupitt/libvips/issues/599
previously the list of maxima or minima found by max/min were in found
order, so essentially random
they now sort equal values by y then x coordinate, so the results are
consistent between runs, provided there are fewer maxima / minima than
are being tracked
vips_hist_local() has a new param, max_slope, which sets the maximum
amount that the local contrast can be boosted by -- CLAHE
see https://github.com/jcupitt/libvips/issues/268
also fix a couple of small range problems
- scale by 255, not 256, to avoid an overflow
- cum hist includes the current value, so sum to <= target, not < target
--vips-cache-max, --vips-cache-max-memory and --vips-cache-max-files were not
working and probably hadn't been for a while
vipsthumbnail.c turns off the operation cache, it's not useful for
the same operation repeated across many files
helps bindings (which struglle with vips_image_map()) get a list of
header fields
works from py, but not ruby, I guess gchar** isn't a supported type for
ruby-gnome
see https://github.com/jcupitt/libvips/issues/533
older libgsfs can't save zip64 and will fail silently for very large
output trees ... improve the slightly sketchy >4gb detection in dzsave
this a a version of the patch in https://github.com/jcupitt/libvips/pull/462
rework header.c
- built-in enum fields, like "interpretation" are handled as enums, not
ints
- vips_image_get_*() functions always convert to the target type if they
can
- rename "field" to "name" in the docs
- clarify docs
the extra check on bandfmt in sizeof() in 8.3.2 was causing some performance
problems ... move the check to file read, so we only do it once
per image, not once per pixel or scanline
thanks Lovell!
- transparency was broken if image had no extension block
- load image to memory, test for transparency and mono/colour, write 1,
2, 3, or 4 band image to output, depending on what we found
vips_resize() uses to just use nearest when upsizing, following standard
practice in repro. This is often unfortunate for image processing, where
small nearest upsizes will produce obvious aliasing.
It now picks a VipsInterpolate which corresponds (roughly) to the
selected VipsKernel and uses that with affine for any upsizing.
vips_resize() used to do most of a downsize with vips_shrink() and the
final 200 - 300% with vips_reduce(). This was correct for lanczos2/3,
but not right for linear/cubic, which need more shrink and less
reduce to avoid aliasing.
This patch makes vips_resize() leave the final 100 - 200% to
vips_reduce() for linear/cubic, and leave everything to reduce for
nearest.
oops, it was missing
also, change the return type from void to VImage. This makes chaining
possible, eg.:
VImage memory = im.write( Viameg::new_memory() );
when you write to a non-partial image, you create a sink ... so
vips_image_write() only needs to ref the input when writing to partials
this change makes it much easier to (for example) combine many images in
bounded space, see for example:
https://gist.github.com/jcupitt/c516325ebef7601b5da610af5619c9b2
We were freeing pixel buffers on thread exit. This was convenient, but
meant that main thread buffers were not freed until program exit. As a
result, long-running programs which created main thread buffers would
slowly fill the operation cache with useless junk, forcing everything else out.
This change also frees pixel buffers on image close. This makes the
cache work much better in long-running programs, and can substantially
reduce memory use.
See https://github.com/jcupitt/libvips/issues/466
threads keep pixel buffers in thread-private storage, and free these
buffers on thread exit ... this means buffers created by the main thread will
only be freed on program exit!
if your program creates any main-thread buffers, these buffers will
eventually fill the operation cache and force everything else out,
making the cache useless
this patch explicitly frees main-thread pixel buffers on image close
when jpg compression is on, tiffsave now converts the input image for
jpg save ... previously, it would try to send a tiff-formatted image
(eg. perhaps with an alpha channel, or float data), which would fail
see https://github.com/jcupitt/libvips/issues/449
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.
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
