ol.source.Zoomify initiates immediate image load bypassing setTileUrlFunction()

[ChrisHSandN]

Describe the bug
ol.source.Zoomify initiates an image load to the default URL template on initialization

openlayers/src/ol/source/Zoomify.js

Line 272 in 2a6dd0f

const testTileUrl = tileUrlFunction(tileUrl, 1, null);

This bypasses the use of setTileUrlFunction() to handle URL generation manually and immediately fires a request to the wrong URL scheme which will fail, (reverting to tileWidth = tileSize).

To Reproduce
Steps to reproduce the behavior:

1. Go to https://jsfiddle.net/chris_h/f7tdx5sp/
2. Click on Run
3. See in network tab that initial load is made without the modifications made in setTileUrlFunction()

Expected behavior

Given that tilePixelRatio is a constructor option, I am not sure why the Zoomify class is taking it upon itself performing this check, especially as it is causing an unnecessary XHR request.

If it must be retained for backwards compatibility could the check be disable-able via a constructor option flag e.g. serverRetinaTileDetection: true|false?

Specially I am using the Zoomify class to load DeepZoom source image which have additional pyramids at the top so the URLs have to be altered to account for this offset in the {z} direction.

[mike-000]

setTileUrlFunction and setTileLoadFunction are inherited by all subclasses of ol/source/TileImage but may not be compatible where there are not equivalent options in the subclass constructors.

Allowing a less restrictive url for Zoomify would be useful as not all sources are standard compliant, see #14760 (comment)

To property handle DZI sources I think a minSize option (as well as an XML parser for the other options) would be needed, allowing zoom 0 to be defined by a minSize of 1 (single pixel) instead of the tile size for a single tile.

[ChrisHSandN]

While getting Zoomify to work for DeepZoom I was thinking how it could better support it, I would maybe suggest:

1. tierSizeCalculation can be default or truncated currently. An extra option of deepzoom could be added?
   

   openlayers/src/ol/source/Zoomify.js

   Line 139 in 2a6dd0f

   switch (tierSizeCalculation) {

2. DeepZoom pyramids tiles are oversized with an overlap of (usually) 1px around their edges to minimise edge rendering artefacts. This makes a 256px tile, 257px for edge tiles, and 258px for middle tiles.

ol/source/TileWMS contains an almost identically used option called gutter so I would propose adding the same named option to Zoomify.

It should just be a case of setting dx & dy in the call to context.drawImage() With the slight complexity that where the tile touches the edge of the extent, there is no offset in that direction.

openlayers/src/ol/source/Zoomify.js

Line 68 in 2a6dd0f

context.drawImage(image, 0, 0);

3. I don't think support for dzi XML is required within OL. While DeepZoom metadata was conventionally contained in these files nowadays the metadata is usually served via JSON and it should be up to the user to provide the width/height/tilesize etc. as is done for Zoomify.

[mike-000]

Zoomify uses a custom tile class to handle oversized tiles which works regardless of the actual size served - artefacts would only be noticeable using the source with a WebGL tile layer. Using a gutter would avoid that, however gutter is also used to allow interpolation across tile edges #15478 (comment) and assumes all tiles are equally oversized. Maybe the custom tile class should, instead of truncating tiles, ensure all tiles are equally oversized?

[ChrisHSandN]

As I understand it, the line context.drawImage(image, 0, 0); in Zoomify would render an oversized tile (with overlaps) from:
Source: 0, 0, width, height -> Destination: 0, 0, width, height

However we would actually want it rendered
Source: overlap, overlap, tilesize, tilesize -> Destination: 0, 0, tilesize, tilesize

E.g. currently a 258x258 (256 + 1px on all sides) will show the duplicate line of pixels at the start from the previous tile and every subsequent line will be 1 line too far over.

Current origin used for sx, sy (0,0)

Actual origin point for sx, sy (e.g. 1,1)

For locations where the tile meets the edge, sx or sy (or both in corners) is 0: