Some JPEGs seem to have multiple APP1 chunks. There should only be one,
and it should only contain EXIF data (I think), but some seem to have
many.
This was causing problems: the loader was trying to read exif
from all chunks, and a second chunk with invalid data was zapping the
stored exif meta tag. As a result, things like
vips im_copy a.jpg b.jpg
would appear to lose EXIF info if a.jpg had spurious APP1.
Set the MAP_NOCACHE flags in mmap() if we can. On OS X this stops the
mad super-aggressive disc caching and produces a huge improveemnt in
performance.
--vips-progress now tells you nthreads, tile size and nlines. For
example:
$ vips --vips-progress im_shrink big.v x.v 8 8
vips x.v: 2 threads, 2858 x 1 tiles, groups of 4 scanlines
vips x.v: done in 43s
$
im_dif_std() is another ancient function which I don't want to update.
You can now make this function with a simple combination of other vips
operations.
This patch includes gtk-doc for im_benchamrk.c
The fits reader is now lazy, and reads out whole tiles when it can.
Previously it read a scanline at a time, and used WIO.
We read in planes and combine with a set of im_bandjoin().
Use an im_flipver() at the end to get rows in the right order.
The fits format reader now uses fits_read_subset() to erad pixels
lazilly. There are a few unresolved issues though:
- getting some streaking, try putting a lock around the read
subarea call, perhaps it can't thread?
- add a tile cache, cf. tiff
- test colour read with valgrind
- ask Doug for a test colour image
- read whole tiles, if the alignment is right, again see tiff reader
- test performance
- remove the old scanline reader?
