Wrong zoom tiles retrieval for specific image sizes

[domenico-stragliotto]

Working with lots of images we're encountering a strange behaviour on tiles retrieval for an image when it has specific image sizes, specifically power of 2 ( 1024/2048/4096 and so on). The thing happening is instead of retrieving all the tiles of a single zoom level ( 10 for example) , it retrieves tiles for different zoom levels ( 8/9/10 ) in what seems a random selection and this causes a wrong display of the image.

For the same image, with width and height changed of just 1 pixel reducing them to 4095 everything is ok

We were on version 4.1.0 but upgrading to 5.0.0 didn't change anything

[iangilman]

OSD loading tiles from different levels isn't unusual, and I can imagine that a small change in the aspect ratio of an image can push you over a threshold. That all sounds normal. But you say the image displays wrong? Can you share a snap of that?

For that matter, a link to a repro would be great.

Btw, it looks like you're using the HTML renderer rather than the canvas or WebGL ones... I'm curious why, as it's good to know what scenarios that renderer is good for!

[AlbertoFardin]

I answer to @iangilman ,

yes, we (I and @domenico-stragliotto) use HTML render and no canvas because canvas render create some gap between tiles for some big images (we use image of 7333x5221px and 24.59MB)

So, now we use this configuration:

OpenSeadragon({
      ajaxWithCredentials: false,
      crossOriginPolicy: false,
      defaultZoomLevel: 0,
      gestureSettingsMouse: {
        scrollToZoom: true,
        clickToZoom: true,
        dblClickToZoom: true,
        pinchToZoom: true,
      },
      minZoomImageRatio: 1,
      maxZoomPixelRatio: 1,
      navigatorPosition: "TOP_RIGHT",
      navigatorHeight: "100px",
      navigatorWidth: "130px",
      referenceStripScroll: "vertical",
      showFullPageControl: false,
      showNavigator: true,
      showNavigationControl: true,
      showHomeControl: true,
      visibilityRatio: 1,
      loadTilesWithAjax: false,
      immediateRender: false,
      useCanvas: false,
      tileSources: tileSources,
      element: refAnchor.current,
      prefixUrl: false,
      navImages: navImages,
    });

You can see the problem in this video: https://github.com/user-attachments/assets/6f308779-6767-412f-ab45-88e90cb683fc

You can try the problem in this page: https://seecommerce.wardacloud.com/sharepage?tenantId=DEMO&token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.ewogICJ0ZW5hbnRJZCIgOiAiREVNTyIsCiAgImFjY2Vzc0NvZGUiIDogImFmOWZjOTViLTIzYTEtNDM5Ny1hOTgwLTc4ZGYxYWU5NDE2ZSIKfQ.7IE6E7vsQBp-Ekzwh31shMIixqyDH7q6_pNMeGPVtso

You can find the react component in this zip: PyramidZoom.zip

[iangilman]

Thank you for the additional information!

Good to know why you're using the HTML drawer. The reason for those lines is because you're using PNG tiles; if you used JPEG you wouldn't see them. This is because with PNG tiles there might be transparency, so things are handled differently. There may be a way to tell it that your PNG tiles don't have transparency if you want to try. The real fix, though, is to update to version 5.0.0 which uses the new WebGL drawer which doesn't have those seams even with PNG tiles.

At any rate, that won't affect the tile loading issue you're having. It looks like maybe your DZI was created incorrectly. What tool are you using to convert your images?

[domenico-stragliotto]

For converting the images we're using https://github.com/VoidVolker/MagickSlicer , i checked the generated tiles and to me it seems like they were correctly generated. Here's a zip with the dzi and the generated tiles ( couldn't upload since it was too big for github) https://demo.seecommerce.wardacloud.com/original/acb35ce3-73c6-4f5d-85cf-9d6768b58b16

[iangilman]

Thank you for sharing the tiles! Looks like you've found an edge case bug in MagickSlicer. It's usually a fine tool, but evidently with these power of 2 images it's got an off by 1 error. In the case of this image it created 13 levels when it should have created 12. You can see that 0/0_0.png and 1/0_0.png are both 1x1 px; this shouldn't be the case.

It would be good to file an issue on MagickSlicer to let people know this problem exists.

As for your image, you have a number of options:

• Don't use exact powers of 2.
• Take the output from MagickSlicer, throw away level 0, and rename all of the other folders by subtracting 1 from their name so you end up with folders 0 through 12.
• Switch to another tool. I personally use VIPS.