Presentation API: Rotate, Mirror and Crop use cases.

117 views
Skip to first unread message

william...@gmail.com

unread,
Sep 6, 2018, 8:33:02 AM9/6/18
to IIIF Discuss
A recurrent problem that someone raised informally in the manuscript call is that it's not evident how to specify rotation in a manifest, which we need when dealing with manuscript material. And we need it in the ranges.

Take the following case:


The Bavarian State Library published on their site (MDZ) a 1491 print of the Corpus Iuris Civilis, and made it available via IIIF (here's the manifest: https://api.digitale-sammlungen.de/iiif/presentation/v2/bsb00049967/manifest).
Now, our project (Fragmentarium) is interested in manuscript fragments, and we know from a catalog that this book has parts of a twelfth-century missal glued to the binding (as in the picture there), so we decided to import it (this was actually done as a classroom exercise in Macerata). On Fragmentarium, we used IIIF to publish the results; send off a few press releases, and Munich, Macerata, and Fribourg are well-pleased.

Here's the problem: the Munich IIIF series is for the 1491 book, and they don't care much about the manuscript fragments. So their photographs are oriented the way they should be, right-side up according to the book. Now, we want to present the fragments, which in this case are glued both right-side up and upside-down, on the same photo. We would like to present them:
  1. As they appear in the book
  2. Right-side up, as bifolia of manuscripts.
  3. Page by page, in reading order
1. is no problem: that's what you're looking at in the case above. We just point at the canvas being served from Munich.
2. and 3., however, are in our current system (Presentation 2.1), not fully implemented. As I understand it, we have a rotation/mirror hack that allows us to specify that IIIF-imported images are to be shown rotated, or (in another very common fragment case, that of offsets) mirrored on our viewer; on the IIIF manifest that we provide, of course, such niceties are not included (compare: https://fragmentarium.ms/overview/F-pono with the IIIF manifest that it produces).
The solution that we employ, then, is to host the images locally and serve them up as distinct canvases (as you can see from the example above). This defeats the purpose of IIIF, since the owning institution no longer serves the images and we have to add an offline component to our workflow.

So, as I prepare the next set of specifications for our application, we are going to be specifying rotation, mirror, and crop at the range level. For our project, these are not edge cases, but regular occurrences. We would like as much of this as possible to work with IIIF.
Am I correct in assuming that, to do this within Presentation API 3.0 (as currently specified), it would require (in 3.0) not just using FragmentSelector from WebAnnotation, but also transform from CSS3Selectors, which is something that WebAnnotation explicitly discourages?
Is there a way to make this work?

William Duba
Fragmentarium (http://fragmentarium.ms)

Jon Stroop

unread,
Sep 6, 2018, 9:13:12 AM9/6/18
to iiif-d...@googlegroups.com

William,

If I understand your use case correctly, this is described in the second example here:

 

http://iiif.io/api/presentation/2.1/#rotation

 

which leverages the iiif:ImageApiSelector. I would be a little surprised to find viewer that supports it, however.

 

I’m not finding an example of the ImageApiSelector in the 3.0 beta draft, and can’t think of why that would be, other than that we perhaps intend to move the example to a cookbook entry.

 

-Jon

 

From: "iiif-d...@googlegroups.com" <iiif-d...@googlegroups.com> on behalf of "william...@gmail.com" <william...@gmail.com>
Reply-To: "iiif-d...@googlegroups.com" <iiif-d...@googlegroups.com>
Date: Thursday, September 6, 2018 at 8:33 AM
To: IIIF Discuss <iiif-d...@googlegroups.com>
Subject: [IIIF-Discuss] Presentation API: Rotate, Mirror and Crop use cases.

 

A recurrent problem that someone raised informally in the manuscript call is that it's not evident how to specify rotation in a manifest, which we need when dealing with manuscript material. And we need it in the ranges.

 

Take the following case:

 

 

The Bavarian State Library published on their site (MDZ) a 1491 print of the Corpus Iuris Civilis, and made it available via IIIF (here's the manifest: https://api.digitale-sammlungen.de/iiif/presentation/v2/bsb00049967/manifest).

Now, our project (Fragmentarium) is interested in manuscript fragments, and we know from a catalog that this book has parts of a twelfth-century missal glued to the binding (as in the picture there), so we decided to import it (this was actually done as a classroom exercise in Macerata). On Fragmentarium, we used IIIF to publish the results; send off a few press releases, and Munich, Macerata, and Fribourg are well-pleased.

 

Here's the problem: the Munich IIIF series is for the 1491 book, and they don't care much about the manuscript fragments. So their photographs are oriented the way they should be, right-side up according to the book. Now, we want to present the fragments, which in this case are glued both right-side up and upside-down, on the same photo. We would like to present them:

1.       As they appear in the book

2.       Right-side up, as bifolia of manuscripts.

3.       Page by page, in reading order

1. is no problem: that's what you're looking at in the case above. We just point at the canvas being served from Munich.

2. and 3., however, are in our current system (Presentation 2.1), not fully implemented. As I understand it, we have a rotation/mirror hack that allows us to specify that IIIF-imported images are to be shown rotated, or (in another very common fragment case, that of offsets) mirrored on our viewer; on the IIIF manifest that we provide, of course, such niceties are not included (compare: https://fragmentarium.ms/overview/F-pono with the IIIF manifest that it produces).

The solution that we employ, then, is to host the images locally and serve them up as distinct canvases (as you can see from the example above). This defeats the purpose of IIIF, since the owning institution no longer serves the images and we have to add an offline component to our workflow.

 

So, as I prepare the next set of specifications for our application, we are going to be specifying rotation, mirror, and crop at the range level. For our project, these are not edge cases, but regular occurrences. We would like as much of this as possible to work with IIIF.

Am I correct in assuming that, to do this within Presentation API 3.0 (as currently specified), it would require (in 3.0) not just using FragmentSelector from WebAnnotation, but also transform from CSS3Selectors, which is something that WebAnnotation explicitly discourages?

Is there a way to make this work?

 

William Duba

Fragmentarium (http://fragmentarium.ms)

--
-- You received this message because you are subscribed to the IIIF-Discuss Google group. To post to this group, send email to iiif-d...@googlegroups.com. To unsubscribe from this group, send email to iiif-discuss...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "IIIF Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iiif-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

william...@gmail.com

unread,
Sep 6, 2018, 9:55:01 AM9/6/18
to IIIF Discuss
Jon,

Thanks for the quick reply!
The lack of viewer support probably explains why it's currently hacked in there.
Indeed, I was trying to figure out how this would work in 3.0 with Web Annotation, when I came across this line:

Implementers should use only commonly supported features of CSS that directly contribute to selection of an element or content, rather than styling or transformation, in order to maximize interoperability between systems.

I suppose that a modest transformation shouldn't infringe the principle of the advice.

Cheers and thanks,
Bill

Robert Sanderson

unread,
Sep 6, 2018, 11:26:40 AM9/6/18
to iiif-d...@googlegroups.com

For 3.0 all of the features currently described in 2.1's section 6 (including rotation) are being moved out to cookbook entries, as there's a LOT of possible functionality in there of which section 6 is just a small (but commonly asked about) selection.  With the native adoption of Web Annotation, we also don't want to re-write that entire specification into the Presentation API but instead reference it and provide IIIF specific guidance (thus the cookbook!).

There's still a need to reference any newly defined Selectors (such as the ImageApiSelector), which is captured rather briefly in https://github.com/IIIF/api/issues/1593.

I agree that the CSS Selector is a good way to get rotation and mirror. Not sure which viewers support it, nor to what degree, however.

Rob

--
-- You received this message because you are subscribed to the IIIF-Discuss Google group. To post to this group, send email to iiif-d...@googlegroups.com. To unsubscribe from this group, send email to iiif-discuss...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
---
You received this message because you are subscribed to the Google Groups "IIIF Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to iiif-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049

Robert Casties

unread,
Sep 6, 2018, 11:37:27 AM9/6/18
to iiif-d...@googlegroups.com
On 06.09.18 17:26, Robert Sanderson wrote:
> There's still a need to reference any newly defined Selectors (such as the
> ImageApiSelector), which is captured rather briefly in
> https://github.com/IIIF/api/issues/1593.

I think it would be nice to have a reference to the selector spec in the
prezi spec. (I had forgotten that there was an ImageApiSelector :-)

> I agree that the CSS Selector is a good way to get rotation and mirror. Not
> sure which viewers support it, nor to what degree, however.

I would think that for a viewer that already deals with IIIF Image API
it would be easier to parse an ImageApiSelector than to parse CSS3
rules. I always prefer to have a more explicit API.

Best
Robert


> On Thu, Sep 6, 2018 at 6:55 AM <william...@gmail.com> wrote:
>
>> Jon,
>>
>> Thanks for the quick reply!
>> The lack of viewer support probably explains why it's currently hacked in
>> there.
>> Indeed, I was trying to figure out how this would work in 3.0 with Web
>> Annotation, when I came across this line:
>>
>> Implementers *should* use only commonly supported features of CSS that
>> directly contribute to selection of an element or content, rather than
>> styling or transformation, in order to maximize interoperability between
>> systems.
>>
>> I suppose that a modest transformation shouldn't infringe the principle of
>> the advice.
>>
>> Cheers and thanks,
>> Bill
>>
>> --
>> -- You received this message because you are subscribed to the
>> IIIF-Discuss Google group. To post to this group, send email to
>> iiif-d...@googlegroups.com. To unsubscribe from this group, send email
>> to iiif-discuss...@googlegroups.com. For more options, visit
>> this group at https://groups.google.com/d/forum/iiif-discuss?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "IIIF Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to iiif-discuss...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>


--
Dr. Robert Casties -- Information Technology Group
Max Planck Institute for the History of Science
Boltzmannstr. 22, D-14195 Berlin
Tel: +49/30/22667-342 Fax: -299

KANZAKI Masahide

unread,
Sep 7, 2018, 12:40:23 AM9/7/18
to IIIF Discuss
Hello,

For example, IIIF 2.1 Test Case #39 has "Image with CSS Rotation" manifest:

Image Annotator handles this CSS (transform: rotate(180deg)):

Since this manifest doesn't use "service" in images/resource, Mirador and UV do not accept it. Here is a modified (service added) version of Test 39 manifest to check CSS rotation in other viewers:

cheers,


2018年9月7日金曜日 0時26分40秒 UTC+9 Rob Sanderson:
Reply all
Reply to author
Forward
0 new messages