tell buffer and target savers the file format
Currently, buffer and target savers are not told the format they should
write.
This is usually OK (the JPEG saver already knows it should write JPEG),
but some savers can write several formats, and these currently need an
extra parameter.
For example:
```ruby
buf = x.write_to_buffer ".bmp", format: "bmp"
```
The first ".bmp" gets libvips to pick magicksave, the second
`format:` param is necessary to tell magicksave to write BMP.
This patch adds stub subclasses so that the savers know the exact format. It also improves PPM save.
remove shutdown from atexit
Because atexit() can be called at almost any point during process termination,
including after worker threads have been force-quit, we can't use it for
cleanup.
New policy: use vips_shutdown() explicitly if you need to clean up,
though it's optional. Only use atexit() for leak checking.
Prior to this commit, MSB-ordered vips images were always byte swapped
on both little- and big endian systems. And LSB-ordered vips images
were loaded without a byte swap. This works correctly on little endian
systems, but will not work on big endian systems where the byte swap
must be done vice versa.
This commit ensures that the byte swap only takes place when needed.
See https://github.com/libvips/libvips/issues/1847.
new_from_memory_steal() will create a new image with the input
buffer and will "move" the data into the image. The buffer is then
managed by the image, and will be freed when it goes out of scope.
We were attempting to load images in new_from_file using the new source
API first, then only falling back to the file loaders if that failed.
However, this meant that we did not respect the priority ordering on
loaders, so openslide iamges (for example) were being loaded by the tiff
loader.
We had a half-baked idea that RGB could mean generic RGB space and sRGB
would mean strict sRGB interpretation.
Unfortunately, this did not work well in practice. For example,
`icc_transform("srgb")` would tag the result as RGB rather than sRGB
(the converter didn't know it was writing sRGB pixels, it just saw
conversion to RGB with an ICC profile), and then later stages would do
unnecessary icc_imports, or worse, fail.
This patch makes RGB and sRGB strict synonyms. If you want to treat an
RGB image as something other than sRGB, you'll need to do it by hand
with the icc_ functions.
See
https://github.com/libvips/pyvips/issues/14446212e92b1 (r34904985)https://github.com/libvips/libvips/issues/1494
vips_image_new_from_memory() allowed you to use length == 0 to mean
"don't check memory length". This was part of some very old vips7
compatibility.
The ppm loader could pass length == 0 if header size was equal to file
size, bypassing the length check.
If the stream-based loaders fail, vips_image_new_from_stream() now falls
back to the old file and buffer loaders.
The file and buffer loaders already try the stream loaders first.
vips_image_temp_name can be called concurrently and thus
the usage of the static "name" array is not thread safe.
-fsanitize=address complains about heap-buffer-overflow due to this.
Kleis Auke Wolthuizen
John Cupitt
Kyle Schwarz
Leonard Hecker