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
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
The base64 encode limit was 1MB, but some huge profiles can get over
that, so it's now 10MB.
transform_save_string_blob() was incorrectly setting a refstring not a
blob as an error fallback, potentially leaving a dangling pointer.
Thanks Jaume!
See https://github.com/jcupitt/libvips/issues/666
clarify policy on file read errors and warnings:
* if the file format library reports a warning, we log it in vips, but
that's all
* if the file format library reports an error, we log it, but try to
continue
* if the file format library reports an error and fail is set, we log it
and fail
all loaders now implement this
