in threaded mode, tilecache could deadlock if the downstream pixel
source raised an error
senario:
- thread1 starts working on tile A and flags it as a CALC
(calculation in progress)
- thread2 needs tile A, sees it is being worked on, and blocks
until computation is done
- thread1 hits an error ... it correctly remarks the tile as
PEND (calculation pending), but does not broadcast a wake-up
signal
- thread2 stays blocked!
threads now broadcast a wakeup on tile error as well as on tile success
Thanks to Todd Patrick
with --centre turned on, in google maps mode dzsave will centre tiles
rather than placing them at the top-left
also, make sure blank.png is set to @background
The vips driver program was parsing options in a single pass. This
failed if an option came in two parts, for example:
vips --plugin x.plg list
the argument to --plug would be picked up as the action for "vips",
since actions were selected before option parsing
Now we parse in two passes: the first pass picks up options for vips
itself and for the libvips library, then we select the action, then we
parse again, including any options created by the action
google maps output needs threaded create / destroy of VipsArea (used to
hold the background colour). We need a lock on VipsArea::count.
Fixes https://github.com/jcupitt/libvips/issues/46
Thanks fuho
nearest-neighbour interpolation now strictly rounds down rather than
rounding to nearest
round to nearest caused strange half-pixels along top/left image edges
during enlargement, and extra 1.5 sized pixels everywhere else
instead we should fix the thing that round to nearest was supposed to fix by
adding an extra pair of params to the affine transform which displace in
input space (dx/dy displace in output space)
We were not capturing warnings from libtiff until we used libtiff
ourselves. Other libraries whcih we call, such as ImageMagick, could use
libtiff and generate an uncaptured warning.
On Windows these warnings each produced a popup.
just use one table, since all colour channels are the same now
have more points in the float -> int direction, fewer in int -> float
faster out of range detection
