getRegion send image with an extra line (JPG)

[arnocertic]

Hi Ruven,

We had meet you at last IIIF event in Paris (march 15th) and we had speak together about our project on the Bayeux Tapestry.

We used Leaflet over your IIPserver to render our huge TIFF64 images (about 483753x5550px each). Images are tiled with libvips (256 px width by tile)

A problem happens at some zoom level : There an unwanted line of 1 pixel at the bottom of the last tile and it's composed of random pixels from the rest of the image... I known it's due to a rounded calculated height but I would have think this line should contain only black pixels.

Here an example, the URL called by leaflet is : my-iiif-server/IIIF=/my-huge-file.tif/10240,4096,2048,1454/256,/0/default.jpg => result is a 256x182 px image (with wrong last bottom line) Here the bottom part of this tile

if I enter by hand this url with a given height (same as a floor calculated height) : my-iiif-server/IIIF=/my-huge-file.tif/10240,4096,2048,1454/256,181/0/default.jpg => result is a 256x181px image (everything is good) Here the bottom part of this tile

I have seen in your code that you made the choice of using Ceil function to found the height of a tile before calculating the image's region. So :

1) Could it be useful/possible to have the choice between Ceil or Floor to calculate tile's size when there's only the width known. (I found a discussion about this problem here)

2) Why there's no only black pixels for the extra line ?

thx by advance

Arnaud

[ruven]

Hi Arnaud,

From your linked discussion, it looks like the IIIF implementation notes say this should be rounded up, which is what most other implementations seem to do also. So, it makes sense that iipsrv follows this convention. But you are right that the bottom line should not contain random pixels. Let me look into this - there must be some uninitialized memory somewhere.

In fact, there is a related issue regarding pyramid sizes https://github.com/jcupitt/libvips/issues/659, but this is dependent on the software you use to generate your TIFF.

[arnocertic]

Hi Ruven,

I effectively used libvips to build my pyramidal tiled TIFF but I think it's come from iipsrv because I opened each raster to verify their integrity and there's no problem at all.

For "my" project, if I force the size calculation of each tile to use floor instead of ceil, it works but it's not a good solution. As you said, I would prefer to respect IIIF recommandations.

[arnocertic]

Hi Ruven,

We made an upgrade this week of our IIPserver because of a bug with Mirador viewer. (It wants thumbnails with specific sizes and IIPServer returns error.)

So we try to test the master branch of this repository (instead of the 1.0 release), It fix this problem but unfortunately we still have our bottom line's problem even if we force the size of the tiles in leaflet viewer (as I explain In my first post). For now, it really sounds that the problem came from IIPserver.

This master release is going really faster than the 1.0 release, and we are thankful of all the work made but we can't use it if there's a extra line in every bottom line each bottom tile ! :(

[ruven]

Hi Arnaud,

Sorry it took so long, but I've added a fix for this in commit: https://github.com/ruven/iipsrv/commit/cabd72aeca6f1cefae7c75c383f541fd7d2cb2cf

There was a subtle rounding issue causing the extra line. Can you please check that this now works with your monster images? Thanks.

[arnocertic]

Hi Ruven, Thanks for replying and proposing a solution ! I download and compile the last code release. Effectively it works for the example previously mentioned, the line disappear in each zoom level.

But...

One mistake appeared, with a particularly image's height, when there's only 2 tiles vertically, a line is missing in the upper one : example : -> image has a height of 346px -> upper tile size should be 256x256px (url is ..../LDJ01.tiled.tif/0,0,4096,4096/256,/0/default.jpg ) but an image of 256x255 is returned -> second tile size is correct : 256x90

I made some tests with a small and reproducible image, the bug appears with a tiled image with an original size of 6000x5550 pixels :

$ identify LDJ01.tiled.tif LDJ01.tiled.tif[0] TIFF64 6000x5550 6000x5550+0+0 8-bit sRGB 139.6MB 0.000u 0:00.000 LDJ01.tiled.tif[1] TIFF64 3000x2775 3000x2775+0+0 8-bit sRGB 139.6MB 0.000u 0:00.000 LDJ01.tiled.tif[2] TIFF64 1500x1387 1500x1387+0+0 8-bit sRGB 139.6MB 0.000u 0:00.000 LDJ01.tiled.tif[3] TIFF64 750x693 750x693+0+0 8-bit sRGB 139.6MB 0.000u 0:00.000 LDJ01.tiled.tif[4] TIFF64 375x346 375x346+0+0 8-bit sRGB 139.6MB 0.000u 0:00.000 LDJ01.tiled.tif[5] TIFF64 187x173 187x173+0+0 8-bit sRGB 139.6MB 0.000u 0:00.000

with the same image cropped at 6000x5450 and then tiled, it works :

$ identify LDJ01.tiled.tif LDJ01.tiled.tif[0] TIFF64 6000x5450 6000x5450+0+0 8-bit sRGB 139.6MB 0.000u 0:00.000 LDJ01.tiled.tif[1] TIFF64 3000x2725 3000x2725+0+0 8-bit sRGB 139.6MB 0.000u 0:00.000 LDJ01.tiled.tif[2] TIFF64 1500x1362 1500x1362+0+0 8-bit sRGB 139.6MB 0.000u 0:00.000 LDJ01.tiled.tif[3] TIFF64 750x681 750x681+0+0 8-bit sRGB 139.6MB 0.000u 0:00.000 LDJ01.tiled.tif[4] TIFF64 375x340 375x340+0+0 8-bit sRGB 139.6MB 0.000u 0:00.000 LDJ01.tiled.tif[5] TIFF64 187x170 187x170+0+0 8-bit sRGB 139.6MB 0.000u 0:00.000

Regarding to the log in attachment for the h=5500 image, the handler CVT is used, while JTL handler is used for the h=5450 image

5550 pixels image => bad_example.log

5450 pixels image => good_example.log

Arnaud

[ruven]

I think I've tracked this problem down and have committed a fix (9192a64a1453c6bde4601f586ea0e5184a7d7aa9). Let me know if you find any other problems!

[arnocertic]

Hi Ruven, Sorry for my late response. I've done some tests and no more problem appeared. Everything looks good. I can close this issue. Many thanks to you. Arnaud