Should IIIF image tiles be displayed in their original size?

[lutzhelm]

IIIF images sometimes appear blurry in the viewer.

The cause is that the original size of a single loaded tile and it's displayed size on the screen do not correspond. The cause for that is that the resolutions in the tile source and the resolutions used by ol.View are independent from each other. OpenLayers calculates a resolution for the view which is not a power of 2 and then looks for the closest match in the tile source's resolutions. Depending on what the closest resolution is, the tile image will be stretched or shrinked on display. In the former case, the image will appear blurry and of seemingly less quality.

I don't know if the views are reproducable but I'll try to give an example:

The tile https://iiif.ub.uni-leipzig.de/fcgi-bin/iipsrv.fcgi?iiif=/j2k/0000/0132/0000013222/00000005.jpx/0,0,1012,1024/pct:25/0/color.jpg is clearly smaller than displayed in this view: https://lutzhelm.github.io/kitodo-presentation-resolutions-view-source.html . While the tile has a width of 253 pixels, it is displayed with a width of ca. 333 pixels on the screen.

In my opinion, the tiles should be displayed on the screen in their original size without stretching to avoid any quality losses. An alternative would be to make OL always use the next smaller tile source resolution (original image pixel/current zoom level pixel) instead of the closest matching so that the tiles may be shrinked but never stretched but I have not checked how to do that yet.

Pinning the view resolutions to the source resolutions would be possible by passing defined resolutions to the view. To view resolutions with more than 1 screen pixel per image pixel, additional resolutions smaller than 1 would have to be provided. For the above example, the result would be the following: https://lutzhelm.github.io/kitodo-presentation-resolutions-view-source-matching.html

I've only looked at IIIF images yet but I guess the problem will be similar for IIP and Zoomify.

[sebastian-meyer]

In my opinion, the tiles should be displayed on the screen in their original size without stretching to avoid any quality losses. An alternative would be to make OL always use the next smaller tile source resolution (original image pixel/current zoom level pixel) instead of the closest matching so that the tiles may be shrinked but never stretched but I have not checked how to do that yet.

I'd prefer this solution over using fixed view resolutions.

[lutzhelm]

Some thoughts on the problem:

The resolutions are already kind of fixed as OpenLayers will always zoom by factor 2 - so any other view resolution are only shown during zoom animations. It would be possible to provide not only the resolutions given in the scalefactors but also some intermediate resolutions to provide a "smoother" zooming experience.

There is currently no way to set an option to change the behavior of always using the nearest matching resolution without changing the OpenLayers code. However, these changes would not be too extensive as there is already a method hidden in the ol.tilegrid.TileGrid code which can control that behavior: https://github.com/slub/ol3/blob/15ede943801f21e201a628f2cfe42219c0e8c779/src/ol/tilegrid/tilegrid.js#L471-L483 The method is used for our purposes in the WebGL TileLayer renderer: https://github.com/slub/ol3/blob/15ede943801f21e201a628f2cfe42219c0e8c779/src/ol/renderer/webgl/webgltilelayerrenderer.js#L164 and in the Canvas TileLayer renderer: https://github.com/slub/ol3/blob/15ede943801f21e201a628f2cfe42219c0e8c779/src/ol/renderer/canvas/canvastilelayerrenderer.js#L95 https://github.com/slub/ol3/blob/master/src/ol/renderer/canvas/canvastilelayerrenderer.js#L246

The option opt_direction=-1 can't currently be used, not even in newer OpenLayers versions. There is neither a documented way nor do I see any possibilities in the code. It does, however, work as expected - at least I tested it with the canvas renderer.

[lutzhelm]

I raised an issue with OpenLayers: openlayers/openlayers#9343

For ol3 in Kitodo.Presentation, i'll provide a pull request for the fork in the SLUB repo.