DRAFT: An imgix tile source

[jrochkind]

https://www.imgix.com/

I think we are leaning against using this for the use case we developed it experimentally for. For the 100MB+ TIFF original files we have, it's hard to make imgix latency good. imgix isn't really designed for giant-original use case, although it does work fine if slowly with them. (imgix does have a a 512MB max for source file size though). And the options for non-public/secured images are somewhat limited on imgix.

However, I think this OSD tile source actually works fine, within the limitations of the imgix service itself. (which is a pretty good and well-priced service when you are dealing with less insanely large source images).

It does not yet have any tests. I am not neccesarily proposing this be incorporated into OSD source. In fact, without being in OSD source, it's easy enough for an end-project to just load this
single file into their JS, and it'll work fine with OSD. (Which is what we were doing for testing).

I am mostly submitting it in case this work is of interest to someone else. I'm myself probably done working with it at this point. Although I think this tile source code submitted here is actually working fine and production-ready.

[iangilman]

Beautiful! Thank you for sharing this.

I'm thinking we probably shouldn't include this as part of OSD, since Imgix is a proprietary service. It would be great to have it published somewhere as a plugin, though! @jrochkind Any interest in publishing it under your GitHub account? Or perhaps @imgix would be interested in publishing it under their account?

[jrochkind]

Honestly, I'm probably not going to be using it, and have no interest in implying any maintenance of it, or really doing anything further with it at present.

I don't see why you can't include it (or publish as a plug-in yourself under @openseadragon) just because it points to a proprietary service. All the code here is open source. If I actually wanted to use it, I might argue harder to convince you of this, but I currently have no horses in this race. :)

Are there examples of other third-party plugins hosted elsewhere? Do you list them in OSD docs? If not, nobody's ever gonna find it or realize OSD can do it, heh.

If my plans change and we end up using this in production, my opinions on these various things my change. :)

[iangilman]

Yes, we've actually got a great collection of plugins, listed on our front page:

http://openseadragon.github.io/#plugins

Anyway, I definitely want it to be available! I think it might be ideal if @imgix adopts it, but we can adopt it if need be. Either way, we'll be sure to point people to it.

[jrochkind]

Cool. I don't think any existing plugins are tile sources? If you have a plugin listed that's a tile source, I'd mention in the "Supported Tile Sources" section at https://openseadragon.github.io/#examples-and-features that people should check the plugins page for more, and link to it. (and/or just list them there in a plugin section, and/or in a separate 'tile sources' section on the plugins page).

That "Supported Tile Sources" section is where I always end up when trying to figure out "wait, what types of tile sources does OSD support?" I wouldn't have noticed if there were more in the plugins list.

[iangilman]

Yes, absolutely, good point!

I think I'll leave this PR here for now while we think about next steps. Thank you again for building it!

[jrochkind]

I'm still not planning on using this, but it occurred to me you might be able to get a better balance of performance by making the tile size a lot bigger than the current default. The same is probably true of the IIIF tile source, or anything that's asking for tiles to be generated on demand instead of accessing pre-generated tiles.

[iangilman]

@jrochkind Good point... I'm generally suggesting 512 or even 1024 pixel tiles these days.

@jpstroop @azaroth42 I'm not familiar enough with the IIIF tile source to know... does it do any sort of choosing for how big to request the tiles? Should we update it to a bigger number? Looks like we might already be supporting 1024, so maybe it's all good?

[jrochkind]

The back-end server is literally making tiles on demand, so can support whatever tile sizes the front-end asks for. I am not completely sure how the front-end works, but I think I saw a tile-size configuration property.

[azaroth42]

IIIF has the following information that is processed for generating the tile requests:

"tiles": [
    {"width" : 512, "scaleFactors" : [1,2,4,8,16]}
 ],

With an optional height if the tiles are not square. So the server can advertise the appropriate size for the particular instance, or even image. If it's not supplied the IIIF TileSource picks a sensible (hopefully) default.

HTH

[iangilman]

@azaroth42 Great... sounds like we're already doing the right thing; thank you for confirming!

[jrochkind]

Interesting. I have no idea if the various IIIF servers we were trying to use allowed us to set this in the info response the OSD plugin would get. I do think a larger tile size would have improved responsiveness for the tests we were doing. It might be nice to allow this to be overridden on the OSD end.

But for now, we're not going with an IIIF server either where i am -- we're just generating straight static DZI.

[azaroth42]

I suggest that if you would actually use an override for IIIF tile size in OSD (and it sounds like you probably wouldn't), then a new issue would be the appropriate place to discuss that.

[linruicheng1997]

The back-end server is loaded on demand, and my needs are the same, but what I see now are basically static dzi local files. Did not find the example I wanted. Finally I saw a little partner who was related to my thoughts.