IIIF image format in manifest

[Falteri]

I’ve found some problems testing many different IIIF clients where some of them are not able to open some omeka media.
Going deep in that issues I’ve found that the problem depends on the format field value in the metadata of the media.
In fact I saw that when I load by Tiler a tif image instead of a jpeg, even if the tile version of the media is made by jpegs, the format stored in metada is “image/tiff” and this seems to be the reason why those clients fail.
If I force that format to image/jpeg, those IIIF clients work as a charm.
So I’m wondering if “image/tiff” is incorrect for those tile images coming from a master file in tiff format, and if the right image format for a tile image is always “image/jpeg” indipendently from the original master file format?

[Daniel-KM]

Yes, it's a true issue. I need to fix it, so to set jpeg anywhere. No standard browser understands the tiff.

[Daniel-KM]

I updated Universal Viewer to last version and the same for Mirador and Diva. I think the issue is fixed. Could you check ? Thanks.

[Falteri]

Hi Daniel, yes sure, I'll check asap and let you know. I'll try to do it by today. Simone

…

_________________________________________________ Simone Falteri [email protected] +39 335 7871641 Il giorno mar 12 feb 2019 alle ore 10:06 Daniel Berthereau < [email protected]> ha scritto:

I updated Universal Viewer <https://github.com/Daniel-KM/Omeka-S-module-UniversalViewer> to last version and the same for [Mirador]( https://github.com/Daniel-KM/Omeka-S-module-Mirador and Diva <https://github.com/Daniel-KM/Omeka-S-module-Diva>. I think the issue is fixed. Could you check ? Thanks. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE5DamOOIy5RPpRNa8HarU8TGYcx9_2nks5vMoQegaJpZM4ZelYT> .

[Daniel-KM]

If it's not workiing, I have a fix that add an option to replace the media type in branch fix/tiff. The option will be removed if it is the true issue.

[regisrob]

I am not able to reproduce this bug... I have imported a TIFF image via Tiler and it is displayed fine by Mirador and UV (both inside and outside Omeka-s, even though I have not tested the Mirador plugin for Omeka-s... but I guess it would be the same as an external Mirador instance). As far as I know Mirador does not care about the value of format properties in the Manifest (in "images.resource.format" of each canvas), it only relies on what it finds in service (i.e. information on the IIIF Image service).
Nevertheless, there is a IIIF spec conformance issue in the Manifests generated by IiifServer:
The Presentation API 2.1 says that "The image must have an @id field, with the value being the URI at which the image can be obtained" (https://iiif.io/api/presentation/2.1/#image-resources), which is not the case in the Omeka-s Manifests: the resource['@id'] points to the base URI of the IIIF Image service (which itself redirects to the info.json). It should instead point to an image (most implementers give the "full" IIIF Image accessible at "full/full/0/default.jpg"). This version of the spec is not really explicit about that, but it assumes the format should correspond to the mime type of the image given in resource['@id'], which will be in most cases "image/jpeg". The Presentation API version 3 is more precise in this regard (https://iiif.io/api/presentation/3.0/#57-content-resources):

• "Content resources must have an id property, with the value being the URI at which it can be obtained"
• "The format of the resource should be included and, if so, should be the media type that is returned when the resource is dereferenced"
• "If the content resource is an Image, and a IIIF Image service is available for it, then the URI may be a complete URI to any particular representation made available, such as https://example.org/image1/full/1000,/0/default.jpg, but must not be just the URI of the IIIF Image service."

[Daniel-KM]

Ok, thanks. So my fix/tiff is useless, but I'm going to fix the id.

[Falteri]

Sorry Daniel, I was not able to try the fix yet, but it sound very strange to me that regisrob can’t reproduce the bug! I’m wondering if it really loaded a tiff...
Anyway the Id topics can be the solution but I think that without that fix the bug should be real and don’t make sense to me that someone do not have it.
I will deepen the bug next days but if I can do something to help you debugging please ask.

[Daniel-KM]

Yes, try first with the last versions of the modules IiifServer and universalviewer. Then, if not working, I'll push the fix/tiff that add an option.

[regisrob]

I may have introduced a small confusion here. I may be wrong but I assume the "id" issue (in images.resource['@id']) has nothing to do with the initial bug: I just noticed it while looking at the Manifest in detail, but I should have filed a separate ticket for that...

As for the initial image format issue, my understanding is that images.resource.format should always be "image/jpeg" since, as Daniel pointed out, a web browser will not be able to render a tiff in any case (even if this format is supported by the IIIF Image API https://iiif.io/api/image/2.1/#format). As mentioned in my previous comment, the format should correspond to the MIME type of the image provided in images.resource['@id'], which will always be a JPG image since this is what IiifServer is delivering by default to the IIIF clients and this is what the browsers are able to render (it could be a PNG too but I've never seen this before in any IIIF implementation...). To sum up, there is no relation between the original image format you load as an Omeka media on the one hand (whether it is a TIFF, a JP2 or a regular JPG), and on the other hand the image that will actually be delivered dynamically by the IiifServer module to be consumed by the IIIF viewers.

I wonder whether it makes any sense, and I am curious about the reason why I did not have the same problem with the TIFF I tested (which was a Pyramidal TIFF...).

[Falteri]

Regisrob: if you upload a pyramidal TIFF and not a “standard” tiff, that should be a collection of jpegs. Could it be seen as a a jpeg (in terms of mine type) by the tiler during the update transformation in Omeka? Or did you upload it without using the tiler? What is the mime type of the original image in Omeka?

[regisrob]

Yes I uploaded my Pyramidal TIFF using the Tiler. And I see that the mime type is "image/tiff" in the right panel of the Omeka media page (in the admin interface). The image displays fine here (in OpenSeadragon, using the DeepZoom protocol).

Now in the IIIF Manifest of the Omeka item, the "format" in images.resource.format for this image is "image/tiff" as well. But it displays fine in UniversalViewer on the public item page, since I assume UV only deals with the IIIF service information in images.resource.service to interact with the image (load the thumbnail, perform the zoom etc.)

[Falteri]

Is that item public? Can you give the uri of the manifest?

[Daniel-KM]

Ok, so I keep the fix/tiff and I ll add the fix for id in the next days.

[regisrob]

Is that item public? Can you give the uri of the manifest?

It was just a test, but I've created a copy and loaded it in myjson: https://api.myjson.com/bins/176t4a, which works fine both in UV and Mirador

While performing various tests, I've found a few other issues in the IIIF implementation of IiifServer, nothing that is really blocking for the most basic use (i.e. view an object in a IIIF viewer), but could be a problem for third-party tools or libraries making use of the IIIF resources provided by an Omeka-s instance.
I also faced problems loading JP2 images with the Tiler, but at this point I did not figure out why some JP2images are loaded and processed correctly, and some are not. I'm still investigating on this...

[Daniel-KM]

I just pushed some commits that fixes the two points. So now, I use the iiif image url, so it's always jpeg, and we don't care of the original format, since it's an image server, even for non-tiled images.
Can you confirm that the manifest is working for you, so I can release a new version? Thanks.

[Daniel-KM]

So if you know some other issues, I can fix them. For jp2, it's probably related to imagemagick, Omeka doesn't know it.

[Daniel-KM]

Last version of Iiif Server probably fixed this issue. Tell me if it is still existing.