Passing maxWidth to the processor

[fitnycdigitalinitiatives]

Is there a way to pass a maxWidth to the iiif-processor from this application?

Thanks,

Joseph

[mbklein]

You mean to limit the maximum width of an image the client can request? There is not currently an option for that, though I can see a case for it. It could also be done by a viewer-request function in the CloudFront-enabled setup.

[fitnycdigitalinitiatives]

Hi, I was referring to the maxWidth option of the processor itself, which now that I'm looking closer at it would only set that limit within the info.json file, but it doesn't seem like that would reject any request to a size larger than that.

I'm thinking of a set up that's similar to the way you would do authentication, where there's viewer-request function that could check a database to see if there's any size limits for an image, and restrict any requests over that size, but then you would still need a way to pass it to the processor to include it in the info.json (though, I suppose you could could insert into the info.json via a viewer response function). I think I get all that in concept, but I admit I don't understand iiif enough to know how to decode when a request would be greater than a size limit in the case of tiles. For instance, if you have a 2000px width limit, I think I get how one could reject any full size image greater than that, but not in the case of requesting individual tiles that would add up to something larger than 2000px.

Our use case is that we have specific student work that we don't want to the public have high res access to. I think the surefire way is these cases is just to create lower res pyramid tiff derivatives. But it would be nice if authenticated users could get the high res stuff and non-authenticated would get lower res for specific items in our collection.

[mbklein]

I think I understand. Just to clarify: You'd like serverless-iiif to be able to pass along a maxWidth property (indicating the advertised max resolution of the image), and you'd like the option to have that value enforced as the largest width the server will provide. What would be the response to a larger request? The correct image but sized down to maxWidth, or a 400 Bad Request error?

As for the “total tile resolution” issue, the math is pretty easy. Let's say you have an image that's 10000 pixels wide, and the maximum resolution the current user is allowed to request is 2000 pixels wide.

The user requests /0,0,500,500/200,/0/default.jpg (i.e., a 500 pixel square from the upper left corner, sized to 200 pixels wide).

500 / 10000 = 0.05 (e.g., cropped width / full width = % of image requested) 200 / 0.05 = 4000 (e.g., requested size / % of image requested = width if full image were requested at this scale) 4000 <= 2000 = false (bad request)

This involves a little more parsing and math if either the crop or size parameters is expressed as a pct:, and especially if the size is expressed as a constrained max fit like !x,y. Since iiiif-processor already does this for you, maybe there's a way to expose that functionality. I'm going to give this some thought.

[fitnycdigitalinitiatives]

Yes, I think we're on the same page here.

I'm really not sure what the best way to handle the larger requests, whether to reject or just scale down. It seems like canteloupe just returns a sized down image. That seems probably fine.

I think there's also the issue when iiif 'max' parameter is used—it would need to size down there too.

Then, I wonder how this would play nice with an image viewer like openseadragon or mirador. I assume if there's a max width listed in the info.json it's just not going to make those requests for larger images in the first place?

[mbklein]

@fitnycdigitalinitiatives The latest release of node-iiif adds the Calculator functionality I was talking about above. I haven't had time to document it really well, but there is now code in there that will let you pass in the dimensions of a source image, perform some virtual transformations on it, and get a bunch of data back about the resulting image – including what it would be at full frame (i.e., non-cropped). That would allow you to set the kinds of limits we've been talking about in this issue without a lot of overhead. It's still not fully integrated into serverless-iiif as a max-width handler, but it opens up a bunch of options.

[fitnycdigitalinitiatives]

Cool—I'lll take a look!