Last modified: 2014-09-29 21:51:50 UTC
To support high-density displays, we generate or fetch media thumbnails at three resolutions: standard 1x, 1.5x, and 2.0x density. When going over InstantCommons, this currently requires us to make three separate thumbnail lookups over the internet, which are done in serial and can product quite some latency. (For the more general issue that each image is looked up separately during parsing, see bug 54033.) If the imageinfo API were extended to allow requesting multiple sizes, we could do a single request and retrieve all three thumbnail URLs at once. Will file a second bug to enhance ForeignAPIRepo to support this...
It might be simpler to include all three size options in the output rather than requesting them explicitly from the client side... This would require the updated version to be running on Commons, but that's something we can coordinate obviously. :)
I think I agree that it might be more straightforward just to export thumburl, thumburl15, thumburl20, etc, but this may not scale well if different densities are required in the future.
I'd lean towards making the relevant parameters (iiurlwidth, iiurlheight, iiurlparam) multi-value parameters and letting clients request what they actually want, rather than special-casing to always return certain predefined density options.
Client-defined multivalue will be needed by a lot of applications including bug 54033 and bug 67323. The current syntax looks like this: https://commons.wikimedia.org/w/api.php?action=query&titles=File:Example.jpg&prop=imageinfo&iiprop=url&iiurlwidth=100 There can be a height parameter as well along with (or possibly instead of) the width, and also a parameter containing everything else: https://commons.wikimedia.org/w/api.php?action=query&titles=File:Example.jpg&prop=imageinfo&iiprop=url&iiurlwidth=100&iiurlheight=100&iiurlparam=qlow-100px Turning iiurlwidth into a multivalued field is nontrivial because it might have corresponding heigh/param values. This would fit some-sort of tree-based input format (such as JSON or XML, or even PHP-s GET array notation) nicely, but doesn't sit so well with the MediaWiki API's flat input syntax. Some possible solutions: 1) make iiurlwidth & co. multivalue, use empty values to match up the values: iiurlwidth=200|300||500&iiurlheight=200||400|500&iiurlparam=|||qlow-500px The returned value could use the same syntax to preserve backwards compatibility: <ii thumburl="https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/194px-Example.jpg|https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/300px-Example.jpg|https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/388px-Example.jpg|https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/qlow-485px-Example.jpg" thumbwidth="194|300|388|485" thumbheight="200|303|400|500" url="https://upload.wikimedia.org/wikipedia/commons/a/a9/Example.jpg" descriptionurl="https://commons.wikimedia.org/wiki/File:Example.jpg" /> This is fully BC but extremely hacky. 2) Deprecate iiurlwidth/iiurlheight/iiurlparam, come up with a new, multivalued parameter which can combine them (maybe use a wikitext-like dimension notation: '100', '100x100', 'x100', 'x100-qlow-100px') and a corresponding new response element which is also properly multivalued: iiurlsize=200x200|300|x400|500x500-qlow-500px <ii url="https://upload.wikimedia.org/wikipedia/commons/a/a9/Example.jpg" descriptionurl="https://commons.wikimedia.org/wiki/File:Example.jpg"> <iithumb url="https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/194px-Example.jpg" width="194" height="200" /> <iithumb url="|https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/300px-Example.jpg" width="300" height="303" /> <iithumb url="https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/388px-Example.jpg" width="388" height="400" /> <iithumb url="https://upload.wikimedia.org/wikipedia/commons/thumb/a/a9/Example.jpg/qlow-485px-Example.jpg" width="485" height="500" /> </ii> 3) instead of using imageinfo, make a new prop=thumbnails module. Leave the old syntax for the (atypical but existing) use case of showing thumbnails of older revisions, use the new module for other thumbnail operations. The syntax could be the same as in 2). This would get around the problem with imageinfo that it is awkward to use it to get a list of contributors and other image data at the same time since it would return all data for all revisions, while e.g. thumbnail URLs or extmetadata are rarely needed for an old revision. OTOH a prop module which throws an error when called with no extra parameters (size) feels weird. Thoughts? I am leaning towards 2) at the moment.
(In reply to Tisza Gergő from comment #4) > 1) make iiurlwidth & co. multivalue, use empty values to match up the values: [...] > This is fully BC but extremely hacky. Extremely. -2. > Deprecate iiurlwidth/iiurlheight/iiurlparam, come up with a new, multivalued > parameter which can combine them (maybe use a wikitext-like dimension > notation: '100', '100x100', 'x100', 'x100-qlow-100px') and a corresponding > new response element which is also properly multivalued: In general, yes. I see no reason for this to be not only wikitext-like but actually be exactly what's used in the image syntax, if at all possible. The only difficulty might be if any media handler needs multiple image-syntax parameters to fully characterize the thumbnail. In specific, see below. > 3) instead of using imageinfo, make a new prop=thumbnails module. We already have too many image-related prop modules, IMO: imageinfo, videoinfo, and stashimageinfo all do basically the same thing, just for slightly different cases. > Thoughts? I am leaning towards 2) at the moment. I like option 4: Deprecate prop=imageinfo entirely in favor of something that isn't so full of warts. Details at https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Rewrite_prop.3Dimageinfo_from_scratch_as_prop.3Dfileinfo Although my proposal there includes option 2 when it comes to thumbnails. Fleshing out that proposal and even help with coding it would be very welcome.
(In reply to Brad Jorsch from comment #5) > I see no reason for this to be not only wikitext-like but > actually be exactly what's used in the image syntax, if at all possible. The > only difficulty might be if any media handler needs multiple image-syntax > parameters to fully characterize the thumbnail. All media handlers which take nontrivial parameters need that: the size will be one parameter, and all else (page number, quality, language etc) > We already have too many image-related prop modules, IMO: imageinfo, > videoinfo, and stashimageinfo all do basically the same thing, just for > slightly different cases. I don't see why multiple image-related modules would be a problem. We have half a dozen link-related modules; it's actually a lot less problematic than stuffing all the functionality in a single module. If anything, imageinfo should split up further IMO. (As a matter of fact, I would like to split out extmetadata into a separate module, with significant changes. I hope to put up an RfC about that in a couple days.) The problem with imageinfo/videoinfo/stashimageinfo is that they are split the wrong way: instead of providing different functionality for the same file they provide the same functionality for different file types. > I like option 4: Deprecate prop=imageinfo entirely in favor of something > that isn't so full of warts. Details at > https://www.mediawiki.org/wiki/Requests_for_comment/API_roadmap#Rewrite_prop. > 3Dimageinfo_from_scratch_as_prop.3Dfileinfo > > Although my proposal there includes option 2 when it comes to thumbnails. > > Fleshing out that proposal and even help with coding it would be very > welcome. The proposal sounds good but also sounds like a long-term thing. It would be nice to have a solution for the single-size-per-request limitation right now, MediaViewer development is inconvenienced by it. If I understand correctly, code written for option 2 could be reused when implementing option 4, so going with that option now would not be wasted effort, right? (As a side note, my dream API would have JSON instead of string inputs so that attributes can be set per-file instead of globally; in the case of thumbnail URLs, this would lift the current limitation that the same thumbnail size(es) have to be returned for all files (and all revisions of them). Something like [{ "title": "File:Foo.jpg", thumbs: [ { width: 220px }, { width: 640px } ] }, { "title": "File:Bar.jpg", thumbs: [ { revision: 123456, width: 100px } ] }] would make more sense to me. Consider an interface similar to the file page, with a large image of the current revision and small images of the old ones, or a collection interface like [1] - wanting different sizes for different images / different revisions is a fairly natural use case.) [1] https://www.mediawiki.org/w/index.php?title=File:Media_viewer_designs_-_media_support.pdf&page=3
Per IRC discussion with Brad, I'll add a new mode to imageinfo (since I need a patch for this soonish) and try to make it compatible with the eventual format of the future fileinfo API: * use an iiwikitextparam parameter which takes parameters in the same format as wikitext images; since those use | as a parameter separator, use || as a parameter group separator * use the output format described in comment 5 2)
