Welcome to serverless-iiif Discussions!

[mbklein]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[whunter]

Hi, how's it going?
I'm working on an online repository for Univ Libraries at Virginia Tech and we're really interested in this project. I've spun up an instance and have been able to retrieve images, image regions, and the info.json file. It's really slick and it was dead simple.

To date, in our project, we've been pre-generating tiles and manifests, storing it all in s3, w/ links to the manifest files in Dynamo, and rendering it in Mirador.

Are there any institutions out there that are using an "on-demand" tiling server in conjunction with manifest generation to support items with > 1 image file (like a book) in an IIIF viewer? Something like this? https://iawa.lib.vt.edu/archive/0v495c8z
If so, what would that setup look like? It seems like the manifest generation could get very time consuming at runtime

[vchettur]

I'm building a solution in AWS using serverless components (Lambda, Step functions) and S3, Dynamodb, Cloudfront for caching to retrieve all assets from Preservica (using pyPreservica) and generate manifests on-the-fly. We are using serverless-iiif for images and compound image assets like census data. The manifests use pyiiifpres which is a very fast manifest generation library in Python. It takes only 100-200 milliseconds to do the manifest creation with this library. We are not doing pyramidal tiffs at the moment only good quality jpgs.

Audio and video are also going to be converted on-demand to HLS streaming using Gstreamer code deployed in an ECS container on Fargate.

[mbklein]

We have quite a few multi-page works (like this one). Our images are stored as pyramidal TIFF files and served through serverless-iiif. The manifests are generated on the fly via our Digital Collections API. (The manifest for this particular work is here.)

The API is backed by an Elasticsearch index, and we've found our manifest generation to be pretty speedy.

[whunter]

Hey, thanks for getting back to me so quickly.

One of our main motivations for looking into different solutions has been to eliminate the need for pre-generated tiles (for the standard "we're storing all of this stuff that might never be requested" reasons).

My assumption is that in order for that to work each and every image in the object would have to be tiled at runtime before the manifest could be returned. That need to tile everything was what I was thinking would be the bottleneck in generating a manifest on the fly. Is that assumption correct?
Are you aware of anyone who's doing this without pre-generated tiles? Is that realistic?

Thanks again for the response. Hope you don't mind if we cheat off your homework and take a peek at that Dig Collections API. It looks like we could learn a lot from that.

[mbklein]

I don't consider what we do to be fully “on the fly” – we generate an access copy which is a single-file, multi-resolution TIFF with precalculated tile boundaries. We have them stored using S3's Intelligent Tiering feature, which keeps the costs low without impeding performance and also keeps more frequently accessed items in “hot” storage without our having to do anything.

[fitnycdigitalinitiatives]

Hi,

We generate everything on-demand, including multipage items using serverless-iiif for the tiles/info.json and the manifests are generated with our underlying repository (which uses Omeka-S). Here's an example from one of our sites: https://fashioncalendar.fitnyc.edu/item/74509

The manifest generation itself is a pretty negligible part of the process, speedwise. The tile/info.js generation is what holds things up more. We're not on the latest version serverless-iiif so maybe upgrading could speed up the process. But we also use cloudfront in front of serverless-iiif so when things are already cached it's pretty speedy.

-Joe

[fitnycdigitalinitiatives]

Right now, about 20 pages, but we'll go larger than that eventually when we start ingesting more book-type objects. Our source files are Tiff's, which run between 300-400 mb on average, but we generate pyramid tiff's for each as access copies, which is what gets accessed through serverless-iiif. Those are generally between 5-10 mb. Not too big. The compression isn't noticeable to my eye.

To answer to your above question, manifests are not dependent on tiles already existing or the generation to the info.json. The manifest includes all the item metadata and then points to the info.json for each file. It doesn't need to exist yet for that to happen.

[whunter]

Thanks for the response. And that makes sense, you're basically generating the paths in the manifest programmatically to point to where those files will be written.
So when you say you generate pyramid tiles for access, does that happen at runtime also? Or is that a part of your ingest process? That's really the part we're trying to avoid. Or maybe I should say "what we're experimenting with."

[fitnycdigitalinitiatives]

We create the pyramid tiff access copy as part of our ingest process. So that's not done on the fly. But it's built into repository system. I think it's worth considering that if you have an original image at 400 mb, adding an additional 5 mb access copy is almost like a rounding error in terms of your total storage needs. I think it's certainly possible to set up a system where you could just generate that access copy only if that image is ever accessed, but there would be a much bigger delay for the first user that accesses it of course.

I saw an example a while back of doing something similar to what you're thinking with video transcoding on the fly which might be helpful: https://aws.amazon.com/blogs/networking-and-content-delivery/on-the-fly-video-conversion-amazon-cloudfront-lambdaedge-mediaconvert/

[mbklein]

@whunter See my reply to the other comment about "on-the-fly" tile generation. Neither of us (@fitnycdigitalinitiatives or my team at @nulib) generate individual tiles that ever get saved to disk anywhere. The pyramid TIFF file is a single file containing multiple resolutions of the same image arranged so that regions and tiles can be extracted at various sizes incredibly fast. So our images are pre-processed, but into a single file that tiles can be served out of as opposed to a directory tree full of individual tiles.

[whunter]

@mbklein Thanks. I was meaning to ask about that. This is what you're referring to?
https://cantaloupe-project.github.io/manual/3.3/images.html#Multi-Resolution
I'm not very familiar with working with tiffs w/ multiple resolutions. So can you just pass a multi-res tiff to an iiif viewer and it can read it? Or does the tiling server still create tiles and serve those at runtime (albeit more efficiently because of the source format)? Based on that Cantaloupe link it looks to me to be the latter but I get confused easily. haha
That does seem interesting and I think we might look into that further.
I also thought @fitnycdigitalinitiatives had an interesting idea with "tiling (or generating whatever access derivative) and writing to disk on first request" I guess you'd just have to hope that you're not the first person to click on something. haha. It seems like that strategy could be part of some hybrid setup.

[mbklein]

Yes, that's what I'm talking about. The image server pulls individual tiles out of the multi-res TIFF image and serves them up as small, individual tiles. Trying to send the entire multi-res TIFF to the viewer would defeat the purpose of the “just-in-time” image zoom features that grab only the parts of the image needed to display the current viewport at the current zoom level.

Our pyramid TIFFs take about 3½ seconds to generate on average, but can take as long as a couple minutes. So I wouldn't want to depend on an on-the-fly processor that runs on the first request.

[whunter]

Oh yeah, you're right. It wouldn't make sense for the viewer to read the multi-res tiff itself because you'd have to serve it. I guess sometimes I just hit "Reply" w/o fully thinking things through. Sorry about that.

[mbklein]

No problem at all. Whatever helps.