arraysize: 0
IIIF API for local and remote MediaWiki image files: demo
Images files used for the demo
- File:Bg-gospel-ccc-ox-122.jpg (page id: 44730)
- File:Bg-StGall-St-John.jpg (page id: 44736)
- File:1617197682.png (page id: 51926)
1. Using parameter for file names
Delimited through semi-colons:
- https://codecs.vanhamel.nl/api.php?action=iiif-mw-pres&format=json&files=Bg-gospel-ccc-ox-122.jpg;File:Bg-StGall-St-John.jpg;1617197682.png&source=local
- Accepts page titles both with and without namespace prefix
File:(I left one in).
Now see this manifest in action in Mirador
2. Using parameter for page IDs
Delimited through commas though for consistency's sake, we might want to switch to semi-colons instead:
Now see this manifest in action in Mirador
3. Using SMW query parameter
Fetching a list of files based on a query condition in Semantic MediaWiki (SMW). @todo.
Image API
For each file, there is e.g. https://codecs.vanhamel.nl/api.php?action=iiif-mw-img&format=json&source=local&pageid=19133
Redirect for thumbnails
Using images from Wikimedia Commons and other MediaWiki sites
So far we have been looking at ways of using the local MediaWiki repository, which relies on internal PHP methods to create JSON-LD output and thumbnail images. It is also possible to retrieve images from Wikimedia Commons and from other MediaWiki sites if the site admin has configured the site settings to trust those repositories. This approach differs from the local one in that it relies on MediaWiki's API services to retrieve our data, in particular the Imageinfo API.
Wikimedia Commons
Wikimedia Commons is supported by default so no configuration is necesssary. Where the above examples use local in the URL, replace this with commons. You can still use either page IDs or filenames (in which case, you shouldn't forget the namespace prefix).
For example, let's use a couple of images from Wikimedia Commons, which we've identified by their page IDs, and generate a manifest.
https://codecs.vanhamel.nl/Special:IIIFServ/presentation/commons/pageids/6228718,1230085,44768586 (redirect URL)
Note that Wikimedia (not MediaWiki) uses Thumbor, which potentially, also enables other features that would be useful within a IIIF context, including "on-demand crop, resizing and flipping of images".
Other external MediaWiki sites
This works in much the same way but requires that the site admin registers any additional external MediaWiki repository through $wgForeignFileRepos with the ForeignAPIRepo class and API base url. For instance, if we were to add Wikivoyage, we could add the followng in our LocalSettings.php file:
$wgForeignFileRepos[] = [ 'class' => ForeignAPIRepo::class, // Required 'name' => 'wikivoyage', // Required. A simple, unique name to identify the repo, without spaces and punctation 'apibase' => 'https://en.wikivoyage.org/w/api.php', // Required. Must be HTTPS 'hashLevels' => 2, 'fetchDescription' => true, 'descriptionCacheExpiry' => 43200, 'apiThumbCacheExpiry' => 86400 ];
The rest of the procedure is identical except for the name of the repository, which is taken from the 'name' parameter above. Where previously we used commons, we now use wikivoyage.
One manifest, multiple repositories
So far so good but what if you want to include images from different repositories in a single manifest? This is currently supported for use with the pageids option. For each file from a different repository, prefix its page ID with the repository identifier and a colon, e.g. local: or commons:. If no identifier is used as a prefix, it will default to the main one.
Example: Special:IIIFServ/presentation/local/pageids/44736,commons:1230085,44730,commons:44768586
On the @todo list
- Add support for the revision ID as an optional suffix to the page ID (now only partly done).
- Add support for IIIF v3. The examples above use IIIF v2 only. Maybe rename Special:IIIFServ subpages accordingly, e.g. IIIFServ/image2/...
- In view of the above, construct identifiers as
<repo>:<pageid>-<revid>, e.g. commons:34344-434534 (imaginary example) - Wikimedia:
- Having access to InstantCommons probably does not come with relevant benefits, but we might want to look into this.
- Maybe suggest that the API should be able to create/return multiple thumbnails in a single API request. Might not be much of an issue. Past suggestions that look relevant: https://phabricator.wikimedia.org/T56035 ("API imageinfo should allow fetching multiple thumbnail sizes") and https://phabricator.wikimedia.org/T66214 ("Define an official thumb API").
- wd-image-positions...
- Maybe add support for image rotation ([1]), although this may not be within the scope of level 0 specs.
- Consider whether or not a proxy is to be preferred to a redirect in some cases
- Consider adding other metadata
- To support deep zoom on low-resolution images, the software should be able to create thumbnails that are larger than the original image. MediaWiki does not support this currently, but in time, a ticket could be submitted to Phabricator.
