- move x/y into composite and out of composite base, have separate x/y int
params for composite2
- upsize later for a small speed improvement
- doc comment
- note in changelog
see https://github.com/jcupitt/libvips/pull/934
eg. VImage::width() is now
int VImage::width() const;
ie. it does not alter the image objects. In factr we can mark almost all
members const.
see https://github.com/jcupitt/libvips/issues/983
Add a "background" option to pdfload to help support PDFs with a
transparent background. For example:
vips copy transparent.pdf[background=0] x.png
see https://github.com/jcupitt/libvips/issues/995
We had a global we incremented to allocate property ids, but of course that
won't work with DLLs. Instead, add vips_argument_get_id() and call that to
allocate new prop ids.
See:
https://github.com/jcupitt/libvips/issues/985
You must now include vips7 support explicitly with
#include <vips/vips7compat.h>
in your code just after including `vips.h`.
The old vips7 names, such as `Rect`, were starting to cause problems
with other packages like opencv.
Some magick coders (eg. ICO) don't sniff the filetype from the data, so
when you try to load from a string, imagemagick is unable to pick the
right decode path.
Add a @format option so callers can hint the filetype.
see https://github.com/jcupitt/pyvips/issues/39
libjpeg rounds up on shrink-on-load. In some cases this can leave a dark
line along the right and bottom edge, since it only contains (for
example) 1/4 of a pixel of data.
This change adds a crop after jpeg load so that only complete pixels are
output.
See https://github.com/lovell/sharp/issues/1185
If O_TNMPFILE is available, use it. This is a linux extension that
creates an unlinked file, so it'll be closed by the system when the last
associated fd is closed.
see https://github.com/jcupitt/libvips/pull/930
Before, they could make B_W for one-band output. This caused problems
with (for example) two black image bandjoined: the second band then
looked like an alpha to hasalpha() and enabled premultiply/unpremultiply
for operations like affine.
Now, it's always MULTIBAND. This is the generic multiband image type, so
you don't get any unexpected alpha handling.
The result of hasalpha is used to turn on things like
premultiplication, so we should be rather conservative
about when we signal this. We don't want to premultiply
things that should not be premultiplied.
Check Type as well as bands.
See: https://github.com/jcupitt/libvips/issues/918
libpng has started throwing hard errors if the profile does not match
the image -- this can happen all the time with perofiles inherited from
images that have been processed.
Test profiles before save and drop them (with a warning) if they are
incompatible with the image.
vips__get_bytes() used to fail if the file was too small for the
allocated buffer, which was a problem for svg, since files can be extremely
small.
This change makes vips__get_bytes() return the number of bytes read, so
the is_a testers can work on files smaller than the max header size.
icc_import can take a fallback input profile in case the embedded one is
broken or missing. If we use the fallback profile, this change attaches
it to the output image.
This means that icc_import will always output an image with the icc
profile that was used to import it. This helps to make the behaviour of
`thumbnail` more consistent.
See https://github.com/jcupitt/libvips/issues/152
If a delayed load failed, it could leave the pipeline only half-set up.
Sebsequent threads could then segv.
Set a load-has-failed flag and test before generate.
See https://github.com/jcupitt/libvips/issues/893
We were rounding up with ceil() when intize-ing convolution masks.
However, the vector path has a true range of (1.0, -1.0], so a mask with
1.0 as the max (for example) was actually triggering the overflow detector
and falling back to the C path.
Round up with ceil(x + 1) instead, so 1.0 (for example) will be mapped
to 0.5 and won't overflow.
vips_sink() used to just fire off threads willy nilly -- this could
cause problems with sequential images if a worker fell too far behind
the pack
copy over the area locking mechanism from vips_sink_memory(): new
threads are now stalled if an old thread has not finished
the new window manager code in 8.6.1 changed the prototype of an internal
function which was visible in the public API
this patch renames the function, adds it to an internal header instead,
and adds a stub for the old prototype
see https://github.com/jcupitt/libvips/issues/854
images under the disc threshold opened in random access mode from
sequential loaders would have the seq tag set on them, causing
performance problems with vips_resize()
see https://github.com/jcupitt/libvips/issues/840
make the code for error during jpeg buffer write a little cleaner --
rather than calling the jpeg term method ourselves, have a separate
destroy function for the write buffer
we were repeatedly free-ing and new-ing input mmap windows ... this made
things like zoom out on large images in nip2 much slower than they
needed to be
the deepzoom spec wants tiles to be written along the right and bottom,
even of those tiles contain no new pixels
this patch seems to work, but needs testing
see: https://github.com/jcupitt/libvips/issues/795
we were leaving a few bits of the original image around after
vips_image_copy_memory(), including the progress signal ... if earlier images
were freed, perhaps by a GC in a language binding, we could get a dangling
pointer
thanks Nakilon, see https://github.com/jcupitt/ruby-vips/issues/140
"intent" lets you set the rendering intent for any ICC conversions --
the default is the (more correct) relative, but "perceptual" can look
better
see https://github.com/jcupitt/libvips/issues/714
we were only replacing enumtypes if it had changed, but this meant that
make usually thought it was out of date compared to the source files,
and rebuilt it, which needed perl
now we always replace it, so (hopefully) perl is no longer a
compile-time dependency
we were only failing on libjpeg errors, but libjpeg treats very serious
things thaht we want to be able to catch (like truncated files) as warnings
... we must therefore error out if fail is set and libjpeg issues a warning
see https://github.com/lovell/sharp/issues/793
If VIPS_WARNING is defined, suppress all warning messages from vips by
installing a null log handler.
Libraries should not call g_log_set_handler(), it is supposed to be for
the application layer, but this can be awkward to set up if you are using
libvips from something like Ruby.
This env var hack is a workaround.
see https://github.com/jcupitt/ruby-vips/issues/119
see https://github.com/jcupitt/libvips/issues/544
John Cupitt