Change #1287887 had a related patch set uploaded (by Simon04; author: Simon04):

[mediawiki/core@master] Improve imageinfo API to return a set of thumbnail URLs

https://gerrit.wikimedia.org/r/1287887

Just a note, that @Mooeypoo is working on a rest api for imageinfo. There might be overlap between those.

Please note that depending on how the wiki is configured, imageinfo might be generating thumbnails, so returning URLs for all permissible options is not free.

The older task (T56035: API imageinfo should allow fetching multiple thumbnail sizes) and patch (gerrit 542775) about multiple size support got bogged down in discussions of the syntax - there can be multiple images batched into the same request; often you'd want different sizes for the different images; there are different ways to specify the size (width vs. height vs. bounding box) which again, based on the dimensions of the image, you might want to combine in the same request; you might want to provide other, handler-specific parameters (like quality or page number) for some of the thumbnails. Would be easy in JSON, but a bit of a pain in the action API's flat input format.

I'm also confused as to why we are guessing urls to begin with ?

IIRC MediaViewer needed it because it implemented its own bucketing logic, and the buckets were width-constrained (maybe unwisely, but we have now reproduced that problem via core thumbnail steps). That means you'll need to pass a width rather than a bounding box to the API, and that width might be different for tall images even if all images are being resized to fill the current viewport.

In T426246#11947740, @Tgr wrote:

Please note that depending on how the wiki is configured, imageinfo might be generating thumbnails, so returning URLs for all permissible options is not free.

Ack. My recommendation is to limit this on stock installs to 2 preferred thumbnail sizes (default wgThumbLimits preference + the 2x HiDPI variant for wgResponsiveImages) and upto 4 preview sizes (wgImageLimits default upto original width). These are chosen for being what is likely already generated on-disk for third-party installs. The default thumbnails as used on any page, and the preview sizes used/linked from the File-description page.

In WMF prod these 6 would be normalized to the next nearest thumbnail step and de-duplicated.

Simon pointed out in code review, that the Action API already has a built-in cost limit (TRANSFORM_LIMIT). Note that MediaWiki's ping limits for renderfile-nonstandard/renderfile are specific to the optional 404 handler via thumb.php. Thumbnails via wikitext or imageinfo API, are deterministically limited based on parser options and API permissions, which makes sense I suppose to ensure a deterministic result without poisoning shared caches.

Consumers like MediaViewer, ForeignAPIRepo (InstantCommons), and mobile apps can then use this and choose the size(s) they want.

Change #1292874 had a related patch set uploaded (by Simon04; author: Simon04):

[mediawiki/extensions/MultimediaViewer@master] Use imageinfo iiprop=thumburls and HTMLImageElement.srcset+sizes

https://gerrit.wikimedia.org/r/1292874