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
oops! typo ... also an off-by-one issue for larger stencils
more error checking in interpolators
fix rounding in nohalo/lbb ... they were rounding to nearest in the
interpolator, rather than using floor. This broke assumptions about
stencil position elsewhere. The right way to do centre convention is to offset
the whole input by 0.5 pixels.
small improvements to vips_resize() quality:
* turn down the anti-alias filter a little so we don't smudge out texture
* don't do the final sharpening pass if we skipped the anti-alias filter
* fix a >/>= mixup which meant we didn't sharpen for small resizes
Daniel Gasienica
John Cupitt