Safari iOS, images don't display if over the resource limit (and useCanvas = true)

Preamble:

Images in Safari iOS are subject to resources limits

In essence, newer iOS devices have an image area limit of 5,242,880 (5 * 1024 * 1024)

Step to recreate issue:

• Make an image (PNG, JPG, etc) that is over the iOS resource limit, e.g. 2984px x 1757px = 5,242,888px

• open this image in OpenSeadragon via a Legacy Image Pyramid - the image will not load:

{
  "tileSources": {
    "type": "legacy-image-pyramid",
    "levels": [{
      "url": "images/5242888.jpg",
      "width":  2984,
      "height": 1757
    }]
  }
}

• change useCanvas to false - the image will now load.

---

I’m not sure if it’s the canvas limit or the image limit that is causing this issue. But the threshold image area required for it not to display is exactly 5,242,880.

If the same over-limit image is opened directly in the browser, it will be displayed, because the browser automatically reduces the size to bring it under the limit.

Perhaps this is not happening in OpenSeadragon because the image is being opened programatically by JS so it can be drawn to the canvas?

It is possible to work around this issue by setting useCanvas to false, perhaps by including an additional User Agent sniff in the $.supportsCanvas function. But this is quite unsatisfactory of course.

I’ll continue to look into this issue, but thought I would log it here for the community also 😃

[terenceingram]

@nmacd85 we are very happy using DZI. It’s worked a treat on a our historic pictures, digitised books, manuscripts and map collections. I originally was using the legacy image pyramid but once I hooked up DZI we were floored at the result. Here’s an example of a panorama: http://nla.gov.au/nla.obj-151651939 and map: http://nla.gov.au/nla.obj-148371790. The bigger images are around 1 GB TiFF files. So for many images we have lots of detail. And some are huge, like a a panorama that is usualy a few metres wide. Using OSD together with IIP has been a massive win for us. We serve up over 1.3 million images using IIP (it’s growing each week). Of those we use OSD to serve up around 280 000 images. The rest are served up using IIP into the internet archive’s book reader as they are digitised books or ephemera that have been OCR’ed.

However the DZI technology has absolutely wowed our public users and stakeholders. We used the same digitised images - just converted into JPG2000, we digitised some of them 15 years ago, but the detail we can now show online is amazing.

Post up a URL to your application once it’s complete so we can see what you have developed 😃

@iangilman

[monospaced]

Legacy image pyramid, when you only have one tile, is a very useful feature 😃

I’ve made some further investigations into this issue.

Yep, rendering to the offscreen canvas is where the problem occurs. It’s possible to get over-resource-limit tiles to render, just by hacking values for canvas.width and canvas.height (to bring the total area below 5,242,880):

https://github.com/openseadragon/openseadragon/blob/master/src/tile.js#L273

Of course, the tile is then cropped, but in principle @iangilman’s solution would work.

I had a go at adding the fix, but ran into a couple of issues:

Firstly, the maths required to find the maximum (proportional) width/height values to bring the total area below the 5,242,880 limit. This one is solvable of course!

Secondly, once you’ve detected iOS, detected that the image area is over the limit, and found the required dimensions to resize the image to, you then hit a separate issue - that iOS can apply unexpected subsampling and improper stretching to resized images drawn to canvas!

http://stackoverflow.com/questions/11929099/html5-canvas-drawimage-ratio-bug-ios/

Here is a library to resolve this:

https://github.com/stomita/ios-imagefile-megapixel

However, at this point, my quick fix had turned into quite a lot of code, and possibly implementing a third-party library…

Does not seem that reasonable, so I think these are the options to consider:

1. continue on the path of adding this fix, tackling the subsampling issue, tricky maths, etc.
2. perhaps OpenSeadragon doesn’t need to render tiles to offscreen canvas as @iangilman has pondered?
3. stick with a ‘no canvas for iOS’ solution (after all, it seems there are a lot of caveats to iOS canvas support!)

These issues could also impact the viewer canvas if it had a large enough area.

Hope this is helpful info 😃