{"action":"created","issue":{"url":"https://api.github.com/repos/IIIF/mirador/issues/517","labels_url":"https://api.github.com/repos/IIIF/mirador/issues/517/labels{/name}","comments_url":"https://api.github.com/repos/IIIF/mirador/issues/517/comments","events_url":"https://api.github.com/repos/IIIF/mirador/issues/517/events","html_url":"https://github.com/IIIF/mirador/issues/517","id":68167748,"number":517,"title":"Image URLs are returned as .jpg regardless of mime type in manifest ","user":{"login":"pobocks","id":33776,"avatar_url":"https://avatars.githubusercontent.com/u/33776?v=3","gravatar_id":"","url":"https://api.github.com/users/pobocks","html_url":"https://github.com/pobocks","followers_url":"https://api.github.com/users/pobocks/followers","following_url":"https://api.github.com/users/pobocks/following{/other_user}","gists_url":"https://api.github.com/users/pobocks/gists{/gist_id}","starred_url":"https://api.github.com/users/pobocks/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/pobocks/subscriptions","organizations_url":"https://api.github.com/users/pobocks/orgs","repos_url":"https://api.github.com/users/pobocks/repos","events_url":"https://api.github.com/users/pobocks/events{/privacy}","received_events_url":"https://api.github.com/users/pobocks/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-04-13T18:56:21Z","updated_at":"2015-04-13T23:50:23Z","closed_at":null,"body":"According to http://iiif.io/api/image/2.0/#image-request-uri-syntax, format specifiers other than jpg should be handled.  However, in the URL generation code ([hereabouts](https://github.com/IIIF/mirador/blob/master/js/src/utils/iiif.js#L28)), the format specifier is being set to .jpg regardless of anything in the manifest.\r\n\r\nMy theory on the right thing to do: use a hash of mime types that work with OpenSeadragon I'm actively working on this - should have a pull request soon."},"comment":{"url":"https://api.github.com/repos/IIIF/mirador/issues/comments/92538883","html_url":"https://github.com/IIIF/mirador/issues/517#issuecomment-92538883","issue_url":"https://api.github.com/repos/IIIF/mirador/issues/517","id":92538883,"user":{"login":"azaroth42","id":871868,"avatar_url":"https://avatars.githubusercontent.com/u/871868?v=3","gravatar_id":"","url":"https://api.github.com/users/azaroth42","html_url":"https://github.com/azaroth42","followers_url":"https://api.github.com/users/azaroth42/followers","following_url":"https://api.github.com/users/azaroth42/following{/other_user}","gists_url":"https://api.github.com/users/azaroth42/gists{/gist_id}","starred_url":"https://api.github.com/users/azaroth42/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/azaroth42/subscriptions","organizations_url":"https://api.github.com/users/azaroth42/orgs","repos_url":"https://api.github.com/users/azaroth42/repos","events_url":"https://api.github.com/users/azaroth42/events{/privacy}","received_events_url":"https://api.github.com/users/azaroth42/received_events","type":"User","site_admin":false},"created_at":"2015-04-13T23:50:23Z","updated_at":"2015-04-13T23:50:23Z","body":"Still :-1: to guessing a format, based on a potentially unrelated URI's\nformat (static thumbnail in a cache vs a IIIF service driven from a\ndifferent master), rather than selecting from the list of formats available\nfrom the service.\n\nIn this situation, you would need to either:\n a. Eat the cost of requesting info.json for every thumbnail to find out\nwhich formats are supported\n b. Include that information in the manifest for every canvas\n\nBasically, if the implementation doesn't support \"jpg\" in the format slot,\nit's not conformant with the specification.  Every level of conformance\nrequires a jpg formatted version to be available. OpenSeadragon also simply\nrequests JPGs on the same basis, as per:\n\nhttps://github.com/openseadragon/openseadragon/blob/master/src/iiiftilesource.js#L240\n\nSo you're not gaining anything anyway as you won't be able to see the image\nin the main view either, regardless of getting a thumbnail.\n\nFrom a specification perspective, you can't even create a valid info.json\nresponse as the first profile MUST be the minimum supported profile from\nthe compliance levels, and you don't even support level0.  Sorry!\n\nAs a horrific work around you could redirect .jpg to .gif (or whatever) on\nyour server.\n\n\nOn Mon, Apr 13, 2015 at 4:29 PM, pobocks <notifications@github.com> wrote:\n\n> We might be unique, in having significant image resources that don't have\n> jpg deliverables, but it seems like the amount of work is small enough\n> (it's a few lines in iiif.js and two lines in utils.js) that it's worth\n> doing for the benefit of people with large sets of legacy image assets (or,\n> as in our case, services that do cheaper tif->gif conversion) or preferred\n> formats that aren't jpg.\n>\n> After all, even if .jpg is guaranteed by the standard, is silently failing\n> to use alternate formats where available and requested really the right\n> thing to do? And at some point it has to start caring for level 3\n> compliance, unless I'm misunderstanding something?\n>\n> PR added to illustrate, not in expectation of being merged.\n>\n>\n> On Mon, Apr 13, 2015 at 3:31 PM, aeschylus <notifications@github.com>\n> wrote:\n>\n> > I agree with Rob that this would add complexity without much benefit.\n> Jpeg\n> > can be dependably expected from every server.\n> >\n> > —\n> > Reply to this email directly or view it on GitHub\n> > <https://github.com/IIIF/mirador/issues/517#issuecomment-92471415>.\n>\n> >\n>\n> —\n> Reply to this email directly or view it on GitHub\n> <https://github.com/IIIF/mirador/issues/517#issuecomment-92532727>.\n>\n\n\n\n-- \nRob Sanderson\nInformation Standards Advocate\nDigital Library Systems and Services\nStanford, CA 94305\n"}}