Zoom level issues with IIIF images

[lutzhelm]

In dlfViewerSource.IIIF, a value for maxZoom is calculated that is later used by the source to determine the correct scale for a given zoom level.

kitodo-presentation/plugins/pageview/tx_dlf_ol3_source.js

Lines 93 to 97 in e78f284

	// calculate custom paramters
	var maxZoom = Math.max(
	Math.ceil( Math.log(width / tileSize) / Math.LN2),
	Math.ceil( Math.log(height / tileSize) / Math.LN2)
	);

If the zoom levels from 0 to maxZoom and the reverse values in resolutions (which originate from the IIIF image scale factors) do not correspond, the IIIF tile source will provide tiles for the wrong zoom level.

An Example

• https://api.digitale-sammlungen.de/iiif/image/v2/bsb10081823_00007/info.json has a height of 1883 pixels (which is greater than the width), a tile width of 512 pixels and the scaleFactors [1,2,4,8,16]
• maxZoom would be 2 as 2^2=4 tiles of 512x512 pixels are enough to contain the height of 1883 pixels
• when the viewer displays zoom level 2,
  • OpenLayers expects the tiles for the resolution at index 2 in [16,8,4,2,1] which is 4 (ie. 1/4 of the full image resolution)
  • the IIIF source, on the other hand, provides tiles for resolution 1 (2^(maxZoom-zoomlevel) = 2^(2-2) = 1) (ie. the full image resolution)
    

    kitodo-presentation/plugins/pageview/tx_dlf_ol3_source.js

    Line 142 in e78f284

    var scale = Math.pow(2, maxZoom - z);

Possible solution

• if resolutions are provided, maxZoom should be determined from those resolutions as logarithm to base 2 of the maximum resolution
• but the resolutions are not necessarily provided:
  • for IIIF image API version 1.1, scale_factors is optional
  • for IIIF image API version 2.1, tiles is optional; if tiles is not given scaleFactors is not given either; if tiles exists each entry it must contain scaleFactors
• so if no scale factors are given, they should not be arbitrarily assumed as [1,2,4,8,16] as I had suggested in dlfUtils.buildImageV2() requires "tiles" which is optional according to specification #279 but rather be calculated from the then correctly calculated maxZoom (with values ranging from 2^0 to 2^maxZoom)

I could provide a pull request for that solution.

[lutzhelm]

I've put the example image (and two other random examples with the same problem) into a little demo:
https://lutzhelm.github.io/kitodo-presentation-306.html

The following shows the behaviour with maxZoom calculated from the maximum resolution:
https://lutzhelm.github.io/kitodo-presentation-306-working.html

[lutzhelm]

While the solution I suggested improves the viewers behaviour and using powers of 2 as resolutions if no scaleFactors are given will work smoothly, there remains the problem that the scaleFactors provided by an info.json do not have to be consecutive values of powers to 2. In fact, any positive integer is allowed. This is bound to cause conflicts with OpenLayers whose default zoomFactor 2 will not work together with an arbitrary set of scaleFactors provided by an info.json.

So additionally I'd suggest that the scaleFactors are to be ignored if they are not a consecutive sequence of powers to 2 after sorting. In that case the viewer should provide a set of resolutions calculated from maxZoom. Size by percentage must be supported by all IIIF image servers at level 1 and 2, so the only problem may be performance issues if the calculated resolutions perform worse than the scaleFactors from the image's info.json.

[lutzhelm]

I have updated the working demo with the solution from the pull request.