The way to do this, in my opinion, would be to support easy set-up of a IIIF endpoint, with appropriate cache integration etc https://phabricator.wikimedia.org/T89552 and also to reflect the kind of information being presented by MediaViewer, eg for all the images on a particular page, into the form of an IIIF manifest, that could be browsed using any of the increasing universe of IIIF viewers out there.
IIIF is gaining real momentum in the GLAM community.
The Internet Archive for example just this week announced full IIIF provision, with descriptions of how they had achieved it.
http://blog.archive.org/2015/10/23/zoom-in-to-9-3-million-internet-archive-b...
Lots of GLAMs on both sides of the Atlantic are moving towards it as their key image-server protocol; and for example the National Gallery in London has expressed a very strong wish that wiki could support IIIF for their internal wiki.
As well as serving zooms and tiles to clients, the advantage of an IIIF service is that different endpoints are compatible and interoperable, so it is possible to create documents (manifests) bringing together images from multiple sources, that can be eg zoomed together and presented together in any IIIF-compatible application. It is also very much designed to be part of the Open Linked Data ecosystem.
If anyone wants to work tile-based backend or frontend, I would therefore strongly recommend IIIF as the API between the two, for compatibility for the rest of the world.
And if we are serious about serving the sum of the world's images, it is frustrating that we're not taking more steps to make them available compatibly with the API that much of the rest of the GLAM world is moving towards.
-- James.
On 27/10/2015 05:55, Brian Wolff wrote:
Volunteers are free to do whatever they want, including collaborating with people...
If you mean splitting over multiple gsoc/opw projects. Such projects have to be mostly self-contained, although theoretically you could probably split it between a backend project -> having an api to return tiles, and a frontend project of doing all the media viewer stuff.
Assuming there were mentors and students who wanted to do that, and we decide we want mediawiki to be able to serve tiles of images (Not entirely clear if we do). Anyways lots of if on that, and would require someone really interested to push it forward and do some analysis if it was to actually become a gsoc/opw project.
-- -bawolff
On 10/26/15, Pine W wiki.pine@gmail.com wrote:
Maybe the tile viewer project could be segmented in a way that it could be spread over multiple volunteer developer tranches. Quim, what do you think?
Pine On Oct 26, 2015 10:37 PM, "Brian Wolff" bawolff@gmail.com wrote:
On 10/26/15, Pine W wiki.pine@gmail.com wrote:
Assuming that this image will be released with a Commons-compatible license, sooner or later (maybe many years later), there will be a use
case
for increasing the Commons file size limit to 194GB:
http://www.dpreview.com/articles/5817599570/astronomers-create-46-gigapixel-...
That's not going to happen.
Perhaps in a timeframe in the nearer future, could MediaViewer be tweaked to download and show only small portions at a time of large images and/or tiled sets of of images? I think this feature might get a lot of use from the moment of deployment.
Commons currently uses tool labs for this (See the interactive large image viewer like, on e.g.
https://commons.wikimedia.org/wiki/File:South_Station,_Elevated,_and_Dewey_S... ). I'm sure this would be a cool feature for media viewer. I doubt its going to happen in the near future based on current priorities (Obviously, its open source, so anyone could submit a patch. Maybe it would make a cool gsoc project to have a tile viewer in media viewer, albeit that's kind of on the large size for a gsoc project.
-- -bawolff
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia