This patch makes "insert" issue minimise signals for inputs in sequential
mode. This can drop memory use in some programs, for example:
```python
import sys
import random
import pyvips
image = pyvips.Image.black(20000, 20000)
for filename in sys.argv[2:]:
tile = pyvips.Image.new_from_file(filename, access='sequential')
x = random.randint(0, image.width - tile.width)
y = random.randint(0, image.height - tile.height)
image = image.insert(tile, x, y)
image.write_to_file(sys.argv[1])
```
Before this patch:
```
$ for i in {0..1000}; do cp ~/pics/k2.jpg $i.jpg; done
$ /usr/bin/time -f %M:%e ../manyjoin.py ../x.jpg *.jpg
5456256:4.34
```
With this patch:
```
$ /usr/bin/time -f %M:%e ../manyjoin.py ../x.jpg *.jpg
2475324:3.38
```
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.
* Add jpeg restart_interval option.
This allows saving a jpeg with MCU restarts.
* Fix code style. Add description of restart_interval.
* Add a basic test based on output length.
* Update main change log.
We used to assume (in several places) that any source with a filename was
seekable. This patch adds a is_file test, and makes all the loaders use it.
see https://github.com/libvips/libvips/issues/2467
* fic gtk-doc typenames in cgif
* fix flatten clipping
flatten could produce out of range values if max_alpha was less than
the limit of the numeric range of the format
https://github.com/libvips/libvips/issues/2431
By making the sequential line cache non-persistent, and only minimising
when the read point is well past the image.
On large arrayjoin operations, this saves many GB of memory.
See https://github.com/kleisauke/net-vips/issues/135
arrayjoin with a sequential pipeline will now minimise inputs when they
are no longer being used. This drops the number of open file handles
needed to construct large arrays.
Sadly, memory savings are minimal.
see https://github.com/kleisauke/net-vips/issues/135
