How to get a square with the aspect ratio preserved?

[jpstroop]

i.e. make square thumbnails without getting the info.json first. SUL and Klokan have the use case. There isn't a way to do this presently.

[jpstroop]

Some follow up thoughts:

• Does the server get to choose the region, or can x,y in the region be assumed to be 0,0?
• Presently, at a minimum, the client needs to know the length of short dimension, e.g.: /0,0,{min(width,height)},{min(width,height)}/
• /0,0,s,s/? /square/?

[zimeon]

I think that the sensible default (as done by photo printing companies) is to distribute the crop evenly between the two ends of the long side

[zimeon]

... but probably we should have the discussion in IIIF-Discuss first...

[jpstroop]

If 0,0 can be assumed, why not just use CSS (suggested by @sdellis):

http://www.princeton.edu/~jstroop/squares.html

[azaroth42]

Why can't the client request info.json? -1 to inventing URI patterns that all servers need to implement for a few clients in specific situations. Use case description would be helpful (though I guess it was discussed on the call, which I missed)

+1 to using CSS with overflow:hidden as per @jpstroop's example.

[jpstroop]

I tend to agree, but can also sympathize with the use case of wanting to create a big page of thumbnails without having to check the info for each one, and then load them separately.

[azaroth42]

That's what !300,300 is for.

[jpstroop]

Right, but I think the idea is to always fill out the whole square, AND to preserve visibility of the entire short dimension. Which you actually can't do with my CSS approach either.

[jpstroop]

(potentially cropping off some of the long dimension)

[azaroth42]

Scrolls will break any pattern regardless -- a 300x300 of a 1000x45000 scroll isn't going to be as useful as something that shows it's a scroll.

How did the client find the identifier for the image? From a manifest that could include a thumbnail link, thereby solving the problem?

[jpstroop]

Funny...was making the scroll point here at exactly the same time :smile:

[zimeon]

It seems that they key question is whether such a thumbnail facility is justified outside of the link-came-from-manifest case

[azaroth42]

And not only any thumbnail, which we already have, but a square thumbnail that preserves the aspect ratio without having to retrieve the info.json. Perhaps we take the current solutions (above) to iiif-discuss?

[jpstroop]

+1. I can send.

[azaroth42]

A one liner of javascript to do it: http://www.fredparke.com/blog/cropping-images-using-simple-css-and-js Or from stack overflow: http://stackoverflow.com/questions/16891467/how-to-calculate-whether-an-image-is-landscape-or-portrait

You need to get a big enough image that you can be confident the shorter size will be your intended thumbnail size... which could be tricky for scrolls, for example, but 3:1 probably works for 99% of images

[cubap]

This seems like a fruitless path to travel as a service with no knowledge of its content. It is nearly trivial for a developer to use CSS to control this sort of small tile layout and the developer of a specific application will know better which piece of the image is most relevant (top center for a statuette, center center for a coin, top left for a manuscript). Here's a fiddle showing the squares in comparison. Background-size is useful and has both 'cover' and 'contain'. The latter may be more helpful to visualize scrolls, for example.

The biggest problem in getting the best quality thumbnail (though not breaking) is that the current spec allows for asking for a long side ,200 or a less than ,!200, but you must know whether w or h is needed. A solution that may have other applications is for a parameter that applies to either h or w. Perhaps without the "," this would work.

"500"

Returns the long side at 500. Equivalent to either "500," or ",500"

"-500" (to avoid reusing the "!")

Returns the short side at 500. Not equivalent to either "!500,!500" which limits the long side, but is equivalent to either "!500,Infinity" or "Infinity,!500".

"-500,300"

Equivalent to "!500,300"

If a view could request by narrow dimension, then a wide _or_ tall scroll could come back with a reasonable resolution and be squared off by CSS. An additional parameter suggestion that may be broadly helpful would be for the service itself to have some "sample" `region` of each image (defaulting to "full", perhaps) that is seen as most representative. The `size` parameters could then be enacted on this `region`, allowing an application to request `/sample/-100/0/default.jpg` and get back a squareable text block or folio from a [manuscript](http://static.guim.co.uk/sys-images/Guardian/Pix/pictures/2013/1/28/1359393833605/Mali---Travel---Tradition-010.jpg) which isn't close-cropped, a headshot on an [asymmetric statue](http://www.digitalsculpture.org/laocoon/chronology/chronology-figure10.jpg), or a closeup on a complex and [large-format painting](http://www.nga.gov/feature/pollock/lm1024.jpg). I believe this is already possible to expose in the info, but since we're trying not to ask for it...

[klokan]

I suggest syntax w,h! which would probably fit to the existing standard most.

My arguments and real-life examples of use are in the iiif-discuss mailing list. CSS-only solution with existing IIIF Image API cannot guarantee pixel density of the thumbnail. JavaScript calculation of URL for every thumbnail on page from known width + height is not efficient. Server side calculation often impossible.

Update: ~w,h is better - as discussed in mailing list

[mejackreed]

This seems like it also might be a use case for tiling where a specific w,h is expected to be returned. It doesn't seem like there is a way to get a tile with an explicit width and height if it is at the edge of an image.

[zimeon]

Discussion on IIIF Discuss call:

• Want to be able to get square thumbnail without having to first get info.json
• Proposal: have named region ‘square’ which preserves short edge, server choice of position on long image (probably centre if no better info available on server)
• Question about why current !w,h does not meet the need for a good square thumbnail: can’t do nice CSS to get a good square for unknown source, and bad results with very long-thin images like scroll.
• Discussion on better use of background-size:cover in CSS to give good results… not clear that this can get around not getting inso.json
• Would have to be level2+ compliance to avoid being a breaking change
• Some +1’s, no -1s => agreed to add in Image API 2.1

[klokan]

This ticket is suggesting to:

Extend the Region (http://iiif.io/api/image/2.0/#region) paragraph of the Image API with:

Form	Description
square	Return a square image that preserves the short edge of the content. The square is centered at a point of the server's choosing.

The alternative approach changing Size via ~w,h is described at: https://github.com/IIIF/iiif.io/issues/450

[azaroth42]

Slightly different wording, but the same idea: http://image-auth.iiif.io/api/image/2.1/#region

[jpstroop]

Tech meeting @ GW approves. What level of compliance?

[azaroth42]

I propose required at level 2.

[zimeon]

I'm torn between level 1 and level 2. Perhaps required at level 2 for now with the option to reconsider later if this turns out to be widely used.

[jpstroop]

Making it anything other than optional is a breaking change. I'm OK w/ level 1 in 3.0.0

[azaroth42]

Hrm. I guess this is the trouble with only having MUST at different levels and not SHOULD.

Perhaps we can clarify our interpretation of semver a bit. We're not breaking anything backwards ... everything that you could do in 2.0 is the same in 2.1, you just have another requirement that 2.1 servers MUST support at level x compliance. So I don't think it's a breaking change, as everything is backwards compatible ... just not forwards compatible in that a 2.0 server will not fulfill all of the requirements that a 2.1 server has.

We could annotate new requirements in the compliance doc as to which version they were introduced at.

[zimeon]

@azaroth42 - yes, this is the way I like to think about what a breaking change is: In going from x.y to x.(y+1) we expect that any x.y client will work with any x.y or x.(y+1) server. I think this is what our statement "MINOR version increment indicates addition of functionality in a backwards-compatible manner" means. Any addition of functionality means that a client assuming/needing the new functionality will not work with an older server.

In this model, adding a requirement for support of the new feature doesn't seem breaking, but somehow the notion of changing the compliance levels perhaps still is...? or is at least fuzzy?

[azaroth42]

Pinging thread...

@azaroth42: 2 @zimeon: 1 or 2 @jpstroop: Optional in 2.x, 1 in 3.0

@mikeapp @tomcrane Others?

[jpstroop]

@jpstroop reiterates that anything other than optional in the 2.x.x series introduces a breaking change.

[azaroth42]

Re-reading #470 where we agreed on Optional due to compliance being major only... and thus changing my opinion to follow @jpstroop. From that thread @zimeon also seemed okay with it too.

Barring additional input, I propose that we run with it.

[barmintor]

Just wanted to thank the editors for taking this up: We've been using a local extension to the 2.0 spec for this (we call the named region 'featured', but it's the same). In addition to scrolls, it's been useful to name algorithmically generated thumbnail regions for smaller objects photographed on light tables, book pages with large amounts of whitespace, etc.

[jpstroop]

Closed in 9ac188dc31259acd133e2181f2536adb7c46c17a