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
- rename compression_level as deflate_level to match libgsf convention
- use libgsf enums for GSF_ZIP_STORED, etc.
- configure-time checks for zip64 and deflate-level
- off-topic: rename NEED_TYPE_INIT as HAVE_TYPE_INIT for consistency
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
don't run travis for pushes to branches other than master and stable ...
without this, we can't push non-passing changes to any branch without
breaking our travis badge
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
This improves the checks on when to abort dzsave due to lack of ZIP64
support in libgsf. ZIP64 is required for archives/files larger than 4GB
and if more than 65535 files need to be stored, which is the more likely
limit to hit when saving zoom images.
* Add check to abort when exceeding the 64k file limit
* Modify size check to account for per file and directory overhead
The previous estimation was ways off, subtracting only 100k for overhead
when the actual overhead would be several megabytes for file counts near
the limit.
Estimation Basis:
Per file overhead: 30B fixed size fields + filename + extras
Central directory overhead: 46B fixed size fields + filename + extras
End of central directory: 22B fixed size fields
ZIP64 specific header sizes are not estimated, because the checks are
only done if zip64 support is lacking.
In order to estimate the variable space for filenames we need to track
the total length of all filenames and double that, because the filename
is stored in both the local file header and the central directory.
Because we don't know how big the blank tile and metadata files will be,
we subtract 64k from the max size and also leave room for up to 3 more
files (blank tile, metadata, vips properties).
The following environments are used:
* Ubuntu Precise (only cli tests are run)
* Ubuntu Trusty (cli and python tests)
* Mac OS X 10.11 / Xcode 7.3 / mozjpeg (cli and python tests)
John Cupitt
Felix Bünemann