search

IIIF / api

Source for API and model specifications documents (api and model)
http://iiif.io/api
107 stars 54 forks source link

Return padding for negative region requests #1183

Closed methodog closed 6 years ago

methodog commented 7 years ago

Could we allow region requests that extend beyond the bounds of the full image, to optionally return a padded image? e.g. when the region requested starts at < (0,0), or extends to > (w,h)

Presumably we'd want this only as an option, and for the default response to be unaffected. Most usefully, for formats supporting transparency, the added padding should be transparent. More generally, added padding could be treated in the same way as with non-90 degree rotations.

Use case: To allow simple (embedded) positioning of images within a fixed display area, in the absence of a presentation layer. e.g. for the alignment of overlayed images, relative to each-other, when printed to transparencies.

under-cropped-padding_use-case

Or see my Compariscope demo for an illustration of the use-case. It currently has the limitation that every layer must be cropped such that no other layer is under-cropped. It would useful to be able to crop images in superimposition, so that the rendered regions will display in the same configuration when re-layered, in the absence of a presentation layer, and without the absolute need to store positional data separately.

tomcrane commented 7 years ago

Current (2.1) spec says:

If the request specifies a region which extends beyond the dimensions reported in the image information document, then the service should return an image cropped at the image’s edge, rather than adding empty space.

If the requested region’s height or width is zero, or if the region is entirely outside the bounds of the reported dimensions, then the server should return a 400 status code.

I think the second para is not in question - an image server doesn't need to do double duty as an arbitrary transparent png generating service - but does the first one break anything? .../-2000,-300,3000,1000/...

Servers would need to guard against being asked to generate huge images, which they can do with maxWidth and friends.

azaroth42 commented 7 years ago

Unfortunately, it breaks tiling clients when applied to the edges of the image. If I ask for the bottom right corner, and my implementation doesn't calculate the exact size, it just relies on the cropping behavior of the server, then the display will be distorted if it tries to squash it into the available space.

I could see an explicit flag in v3 of the Image API to turn this feature on, but would like to hear support from other organizations with their use cases.

azaroth42 commented 7 years ago

Other considerations:

It seems easier to fulfill the described use case on the client side with CSS positioning, rather than materializing a lot of empty pixels.

methodog commented 7 years ago

Certainly agreed the default behaviour should be preserved; it's logical, tidy, and the fact that tiling clients use and expect this behaviour is reason alone.

I also realise it might not be desirable to start introducing positioning parameters, effectively, although that would only be a side-effect of introducing padding, technically, which might be more acceptable.

I do think it would have to be optional, and restricted by use of maxWidth etc, as @tomcrane points out.

I also hope the complication of added pixels could be dealt with in the same way as for pixels created by non-90 degree rotation requests already, and that both could return transparent pixels for supporting formats.

Re. the confusion that might arise from the result of non-90 rotation with negative region requests, I'm not sure I see how the angle of rotation being a non-90 multiple complicates things. In the simpler e.g. .../-2000,-300,3000,1000/full/90/default.png we'd expect the same result as .../0,0,3000,1000/full/90/default.png So with the proposed optional padded-region flag set, e.g. .../!-2000,-300,3000,1000/full/90/default.png would the result be any more complicated than an image which has been padded, then rotated in the same way as usual, about its resultant centre?

jpstroop commented 7 years ago

Unfortunately, it breaks tiling clients when applied to the edges of the image. If I ask for the bottom right corner, and my implementation doesn't calculate the exact size, it just relies on the cropping behavior of the server, then the display will be distorted if it tries to squash it into the available space.

I don't buy this argument--the client has everything it needs to make the correct request.

jpstroop commented 7 years ago

And the transparent pixels issue already comes up w/ rotation.

tomcrane commented 7 years ago

This would be regionAboveFull, compare with the existing sizeAboveFull

azaroth42 commented 6 years ago

Agreement on 2018-01-31 community call to defer this issue, pending further use cases.

zimeon commented 6 years ago

I note that different from #1161, this one is actually bandwidth wasteful - it is more efficient to do it on the client side

azaroth42 commented 6 years ago

Community call of 2018-03-14: Discussed. No use cases, and the first sentence quoted by Tom Crane prevents it from being an extension. Without that sentence it's not deterministic in the simple case of requesting content greater than height/width, which is more important to the API than allowing the potential for materializing a bunch of non-existent pixels. Closing, wontfix.