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(a)gmail.com> wrote:

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

This seems to be related to existing unclaimed tasks: https://phabricator.wikimedia.org/T7614 https://phabricator.wikimedia.org/T105789 -- brion On Tue, Oct 27, 2015 at 6:55 AM, Quim Gil <qgil(a)wikimedia.org> wrote:

On 10/27/15, Gergo Tisza <gtisza(a)wikimedia.org> wrote: I was more thinking, we might want to take a moment to consider the future of thumbnail naming before adding lots of complexity to how we specify thumbnail options. I've heard some people complain about our thumbnail option naming system Then again maybe not. I haven't really put much thought into if that's even an issue or not. -- -bawolff