I remember @benvanik, a friend and colleague, who worked on our DZI renderer (Seadragon) told us that, I believe, it’s better for GPUs to have power of two sized tiles, so 254px + 2 x 1px tile overlap will give you 256 pixel.s
> To keep my tiles nicely sized, I shrink in instead of expand out – that means my tiles are really 254×254 with a 1px border, so the images are 256x256px with 254×254 of useful imagery. If you wanted larger tiles, you’d go 510×510 with 1px border making 512×512 tiles.
> — Source: http://www.noxa.org/blog/2009/11/29/megatextures-in-webgl-2/
There was a mixup with the previous fix to dzsave overlap handling,
correct it and update the test suite.
In the previous revision, dzsave overlapped tiles by overlap and sized
them by tile_size. In fact, tiles should be sized as (tile_size + overlap
* 2), ie. tile_size refers to the number of unique pixels per tile.
See https://github.com/jcupitt/libvips/issues/357
oh argh class and instance methods are in the same namespace, so we have
to rename the instance one as ibandjoin
also, start adding a test for arrayjoin
we now have VIPS_MAX_COORD for maximum image dimension, set to 10m
pixels ... we could go up to 2bn, but 10m seems a reasonable max, at
least for now
see https://github.com/jcupitt/libvips/issues/355
takes a copy of a memory area when making an image ... this helps bindings
for languages which don't have much control over memory
see https://github.com/jcupitt/libvips/issues/346
dzsave now uses :strip => true for all tiles. There's no point adding
all the metadata to every tile, so hopefully this won't break anything.
Thanks Benjamin, see: https://github.com/jcupitt/libvips/issues/349
doesn't seem to slow us down significantly ... before:
$ time vips dzsave CMU-1.svs x --layout google --background "243 243 243 255"
real 1m1.940s
user 2m15.004s
sys 0m37.092s
after:
$ time vips dzsave CMU-1.svs x --layout google --background "243 243 243 255"
strip_work: skipping blank tile 176 x 67
strip_work: skipping blank tile 21 x 112
real 1m3.503s
user 2m16.012s
sys 0m40.328s