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
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
