[09:56:01] Hi @lucaswerkmeister. What is exactly what you're trying to use the thumbnails for? I need to understand it before I can give suggestions (or change something on our side) [11:14:55] I guess that means “no, there is no useful documentation” [11:15:00] anyway, the use case is https://pagepile-visual-filter.toolforge.org/ [11:15:14] which wants to show thumbnails of all the files in a PagePile, e.g. https://pagepile-visual-filter.toolforge.org/pagepile/25439/ [11:17:57] and the tests at https://gitlab.wikimedia.org/toolforge-repos/pagepile-visual-filter/-/blob/d8dfd750bd/test_app.py#L34 got broken by all sorts of changes to the API (different responsiveUrls, new thumbattribs, different domain, UTM params, and in the case of the small file, different width/height) [11:25:21] (and of course I can just write the new response into the hard-coded expected data, but when I see the new response claiming that a 23x22 file is 230x250, I start to wonder what I’m supposed to make of this output) [11:37:44] The API reflects what the Parser does for wikitext. When you provide an exact width or height, this means you have an HTML or CSS layout dictating that dimension, the API honors that and matches the other dimension. If you embed a 10x10px PNG with wikitext as thumb 200, it'll be 200x200. It would violate the usefulness of this contract to return dimensions where [11:37:44] neither matches t [11:37:45] he input. (re @lucaswerkmeister: the other confusing part is that the API just seems to lie about the size of the “thumb” – compare what [11:37:47] https://commons.wikimedi...) [11:40:34] So the general framework is that, now and before, it is expected if you explicitly request a size larger than the original it will inform upscaled dimensions. [11:40:35] Unlike before it now follows thumb steps and provenance but that's supposed to be limited to the blackbox src string. (re @Krinkle25: The API reflects what the Parser does for wikitext. When you provide an exact width or height, this means you have an HTML or CS...) [11:41:38] That's not to say there aren't weird edge cases or bugs to fix, but I hope the above framework helps recognise what part is buggy and what part is expected. [12:00:24] Exactly. On top of what Timo said. The width and height parameters are supposed to be used as the HTML/CSS attributes but the URLs to the image are dependent on many factors and mediawiki tries it best to provide the most appropriate thumbnail given the requested url. So when you ask for a 250px thumbnail of a 25px png, of course you're gonna get a crappy image. [12:00:24] Overall that url constantly changes due to many factors (migration to thumb.wm.o, standard thumbsize, provenance and maybe more). That's the point of the API. You ask for "what is the most appropriate thumbnail of file X, in size Y" and the API points you to the URL to the thumbnail we can provide. i.e. I think the underlying problem is that the mentioned tests [12:00:24] are basically test [12:00:26] ing our API not your tool. [12:30:00] no? you can see what the API used to return in the test’s expected data – the thumbwidth and thumbheight used to be the actual width and height of the small image (re @Krinkle25: So the general framework is that, now and before, it is expected if you explicitly request a size larger than the original it wi...) [12:35:24] if “the reported width and height are not the actual width and height of the thumbnail” is the expected behavior, it would be nice if this was documented, because it’s not obvious [12:36:07] ditto for what I’m supposed to do with the thumburl/width/height/attribs in the response anyway (just guessing: ignore the -url/width/height because they’re only there for legacy reasons, and splat all the thumbattribs into an `` without looking closely at them?) [12:37:57] It really never was. Many cases the actual size of the image was a couple of pixels larger then one advertised in the URL (e.g. 250px-...) and that was the case way before the standardized thumb sizes. You should never rely on the size of the image itself. That's why the width and height existed in the API response (re @lucaswerkmeister: if “the reported width and [12:37:57] height are no [12:37:57] t the actual width and height of the thumbnail” is the expected behavior, it would be ni...) [17:59:19] also, is there an API call that will give me “downscaled thumbnail if original is larger, original at real size if original is smaller”? which I think is how the imageinfo API used to behave [17:59:50] in the context of my tool, I don’t want to blow up small images if they’re below the space I’ve reserved for them, I just don’t want them to be too large [18:00:36] (which I guess is different than an editor consciously putting |250px “I want this to be big and damned be the consequences” into the wikitext – in the tool, this isn’t a per-file decision) [18:03:50] Dear Wikimedians around the world, [18:03:50] We are thrilled to announce that scholarship applications for Wikimanía 2027 are now open! The final deadline to submit your application is October 31, 2026. [18:03:50] Scholarships cover travel and accommodation in Santiago, Chile, as well as registration and limited travel insurance fees. More detailed information on the application process can be found on the Scholarships section of the Wikimanía wiki, as well as this Diff post. [18:03:50] Successful applicants will be notified starting in January 2027. [18:03:50] Best of luck to all! [18:03:50] Wikimanía 2027 Core Organizing Team : https://tools-static.wmflabs.org/bridgebot/16fbc8e6/file_84046.jpg [18:04:01] FYI (re @Soylacarli: Dear Wikimedians around the world, [18:04:02] We are thrilled to announce that scholarship applications for Wikimanía 2027 are now open! T...)