Support for static or non-IIIF image viewing

[blalbrit]

Mirador should allow the use of static images, as reference in their entirety in the '@id' field of the image resource, instead of requiring a IIIF service to be available.

[azaroth42]

Such as in the simplest possible manifest:
http://iiif.io/api/presentation/2.0/example/fixtures/1/manifest.json

[cubap]

*I can adjust-post this in use cases, if that helps.

This is a big deal and has prevented our adoption of Mirador into T-PEN and Tradamus so far. (These both generate correct and proper Manifests, but they cannot be read unless all the image annotations accidentally have a IIIF service attached.) Another project, Broken Books was begun with the idea of using Mirador as the viewer, but we've had to hack our own to get what feels like a fundamental feature.

Please entertain my ignorance and suppose there are two possible fixes, as I understand the code, which may exist here in Mirador, but also may seep through to Open Sea Dragon. I offer some support from myself and our Center (CDH at SLU) to get this handled, but there may be some low hanging fruit for someone with knowledge of OSD.

1. Accept no-service images in OSD
   • The draw fails because the imgURL is passed into the createOSD() which tries to get imgURL+info.json and has no error handling. Undefineds cascade and the instance is created, but empty and without an osd.canvas to mess with.
   • OSD seems to break on requesting the tile service. Receiving no tiles back, nothing is drawn.
   • OSD should assume that (or failsafe) no tile service is equivalent to one fullsize tile. Instead of building a IIIF request, use the imgURL that is already passed in to load the image asset and paint it bounded onto the canvas.
   • I believe this would instantiate OSD with all its appropriate parts for Mirador to use for pan and zoom (and CSS/canvas filters). It is the cleanest, simplest way, but does not actually involve Mirador.
2. Intercept the OSD service request from Mirador
   • Mirador looks for osd.viewport(.viewer.canvas) for all of its tools, but when createOSD() fails, "viewport" is never injected and only osd.viewer.canvas is available. This means that tools that don't rely on the viewport !(pan, zoom) can still work with a check for osd.viewport first. In this way, we can draw our own image to the canvas if createOSD() fails, but it's hack-tastic and incomplete.
   • The challenge is that the call and the dependency is in OSD, not Mirador, so the tile service (the fail point) is assembled and loaded in the instance rather than any discrete part of Mirador.
   • A more proper way to accomodate it would be to GET imgURL+/info.json before attempting to create the OSD instance and storing the result. When the result is empty, build our own that identifies the image at imgURL as one fullsize tile to be moved around.
   • After that, whenever OSD makes an http request (which I think is always via jQuery) an intercept checks to see if it is calling for a service we've already cached/created and returns that JSON instead of the call.
   • OSD thinks its getting native services and loads like a pro.
   • I'm not actually sure this would work, but it feels right.
   • This is definitely the type of over-engineered solution one applies when they don't have access to the black box, which I think we (the communal we) do.

Thoughts?

[thehabes]

To re-iterate, the closest I can get right now is in hud.js where there 'if(osd.viewport)' checks for the viewport. If I find that there isn't a viewport, all the functionality attached to osd.viewport.viewer.canvas can be attached to ods.canvas since its the same thing. But .panBy() and .zoomBy() are functions that get built with viewport, so doing osd.canvas.zoomBy() or osd.container.zoomBy() or panBy() begets "osd.canvas.zoomBy is not a function".

Without having gone in depth into OSD, I assume...

function createOSD(){
...
_this.osd = $.OpenSeadragon({
'id': osdID,
'tileSources': infoJson,
'uniqueID' : uniqueID
});
...
}
... that OSD builds this circular structure using the tileSources and infoJSON. You only get infoJSON if you have set up a IIIF image server to serve images from so that the service is a part of the image annotation resource.

In most of our situations, I do not get the infoJSON, so I pass an empty in tileSources. Then I never get osd.viewport. I do still get osd.container and osd.canvas, so my image tools work and I can make rotation work by not using the osd.setRotation() and instead using html transform. Page forward and backward works, clicking on the thumbnails to load them in a slot works, so on and so forth. The only piece that has trouble is pan and zoom. An added bonus is that I can have fully compatible IIIF images live alongside non-IIF images in canvases in the sequence (related #536). The ones that have the service get all the functionality and work, while the ones that don't only lack zoom and pan. Another bonus, It has also made it very easy to assign an "img not available" image for when canvases do not have images (related #577).

[azaroth42]

+1! It has been on the roadmap since before Mirador 1.0, is not a difficult problem, and would open up access to every image on the web

[edsu]

👍 I definitely see this as a useful feature to have. Being able to annotate, transcribe any image with a URL, and to create sequences of them, would make Mirador useful in a lot of contexts. It would promote the IIIF Presentation API independent of the Image API.

[azaroth42]

Wellcome use case, including authentication: IIIF/api#547

[thehabes]

I believe this was a duplicate for #660, which has been closed.

[tomcrane]

Just crossing streams here (as the solution is probably the same): UniversalViewer/universalviewer#78. Note about buildPyramid may be handy.

[azaroth42]

Ping. Needed in hundreds of museums.

[blalbrit]

@azaroth42 Agree! Who has this on their development roadmap? Does the Getty have resources to contribute?

[thehabes]

I have a version of Mirador supporting static images that we use for Broken Books. It is hacky so I never pushed anything upstream, but I did find a way to make static images in a manifest work along side IIIF images in that same manifest. The main trick was passing the correct tileSources off to the OpenSeaDragon instance in createOpenSeadragonInstance(imageURL). I did not have an info.json or a tiling service, so it looked like this

_this.osd = $.OpenSeadragon({
          'id':           osdID,
          'tileSources':  [
              { 
              'type': 'legacy-image-pyramid',
              'levels':[{ 
                'url': non-iiif-imageUrl,
                'height': currentCanvasHeight,
                'width': currentCanvasWidth
              }
              ]
            }], //This is the consequence of not getting the JSON.  It creates the viewport on which the OSD functions are called.  Without it, OSD does not work.
          'uniqueID' : uniqueID
        });

instead of this

_this.osd = $.OpenSeadragon({
          'id':           osdID,
          'tileSources':  infoJson,
          'uniqueID' : uniqueID
        });

The switch for which one to go to is whether or not you can successfully getJSON(infoJsonUrl) for a given imageURL. Since this happens on an image by image basis, I could combine IIIF and non-IIIF images in the same manifest and everything works as it should.

However, this is in an old Mirador and I have not updated to the most recent version, so I am not sure this solution holds any merit anymore.

[cubap]

It seems the code must already exist to just put this functionality into the instance of OSD being used in Mirador, right? The OpenSeadragonizer browser extension just picks up any image and (without looking at the code, I assume) checks to see if it recognizes a tileSource and inserts the default if it is missing. Looking quickly in the code, it seems this is the family of what needs to be pulled over? https://github.com/openseadragon/browser-extension/blob/master/common/openseadragon/openseadragon.js#L13182 Patrick Cuba Walter J. Ong S.J. Center for Digital Humanities Saint Louis University 314-977-4249

…

On Wed, Apr 12, 2017 at 3:52 PM, Bryan Haberberger ***@***.*** > wrote: I have a version of Mirador supporting static images that we use for Broken Books. It is hacky so I never pushed anything upstream, but I did find a way to make static images in a manifest work along side IIIF images in that same manifest. The main trick was passing the correct tileSources off to the OpenSeaDragon instance in createOpenSeadragonInstance(imageURL). I did not have an info.json or a tiling service, so it looked like this _this.osd = $.OpenSeadragon({ 'id': osdID, 'tileSources': [ { 'type': 'legacy-image-pyramid', 'levels':[{ 'url': non-iiif-imageUrl, 'height': currentCanvasHeight, 'width': currentCanvasWidth } ] }], //This is the consequence of not getting the JSON. It creates the viewport on which the OSD functions are called. Without it, OSD does not work. 'uniqueID' : uniqueID }); instead of this _this.osd = $.OpenSeadragon({ 'id': osdID, 'tileSources': infoJson, 'uniqueID' : uniqueID }); The switch for which one to go to is whether or not you can successfully getJSON(infoJsonUrl) for a given imageURL. Since this happens on an image by image basis, I could combine IIIF and non-IIIF images in the same manifest and everything works as it should. However, this is in an old Mirador and I have not updated to the most recent version, so I am not sure this solution holds any merit anymore. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ProjectMirador_mirador_issues_520-23issuecomment-2D293704161&d=DwMFaQ&c=Pk_HpaIpE_jAoEC9PLIWoQ&r=Ob88fw3QcoIhBawyjgurXw&m=IDzUJ7f7WfMxolFn41n72XseHGbqOe8EZknDgydkG0s&s=CSBPB4BT1hMIR31PY0mOC04vxiH-jqPb410xIUaMH6Y&e=>, or mute the thread <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_ABETvag7KTrPnn2rUzctiWKZ-2DGP7p53Pks5rvTmJgaJpZM4EAmkE&d=DwMFaQ&c=Pk_HpaIpE_jAoEC9PLIWoQ&r=Ob88fw3QcoIhBawyjgurXw&m=IDzUJ7f7WfMxolFn41n72XseHGbqOe8EZknDgydkG0s&s=82oadRAnHhCjFY-xjJuU3Y1S-iLlfKt8M-nhzTCo5kE&e=> .

[tomcrane]

OSD also has a single image tilesource (not even a legacy pyramid of size 1):

https://openseadragon.github.io/examples/tilesource-image/

Something like UniversalViewer/universalviewer#78 (comment)

[tomcrane]

Looks like this is now done/merged? Works in current Mirador!

[moritzschepp]

Yes it does work for canvases that include thumbnails. Without a thumb, mirador tries the resource service object which doesn't exist:
https://github.com/ProjectMirador/mirador/blob/develop/js/src/manifests/manifest.js#L107

The presentation API recommends (SHOULD) thumbnails for multi-image canvases:
http://iiif.io/api/presentation/2.1/#thumbnail

[DiegoPino]

Related, same/similar need but on Mirador 3. For now just a comment on an existing issue but can open a new one if needed.

#2616 (comment)

Thanks