search

Daniel-KM / Omeka-S-module-IiifServer

IIIF Server is a module for Omeka S that adds the IIIF specifications to serve any images and medias.
Other
17 stars 11 forks source link

IIIF image format in manifest #4

Open Falteri opened 5 years ago

Falteri commented 5 years ago

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 commented 5 years ago

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

Daniel-KM commented 5 years ago

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 commented 5 years ago

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

Simone Falteri s.falteri@ifnet.it +39 335 7871641

Il giorno mar 12 feb 2019 alle ore 10:06 Daniel Berthereau < notifications@github.com> 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 https://github.com/Daniel-KM/Omeka-S-module-IiifServer/issues/4#issuecomment-462676658, or mute the thread https://github.com/notifications/unsubscribe-auth/AE5DamOOIy5RPpRNa8HarU8TGYcx9_2nks5vMoQegaJpZM4ZelYT .

Daniel-KM commented 5 years ago

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 commented 5 years ago

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):

Daniel-KM commented 5 years ago

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

Falteri commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

Daniel-KM commented 5 years ago

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

regisrob commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 4 years ago

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