In case en:Liang Lingzan gets updated, here's a permalink to the current version: https://en.wikipedia.org/w/index.php?title=Liang_Lingzan&oldid=1290769235.

PrimeHunter failed to verify this issue in Firefox 149.0.2 (64-bit), Windows 11 Home version 25H2, but believes that the issue is reproducible.

That wiki page uses the following markup:

{{Panorama
|image      = File:五星二十八宿神形图.jpg
|height     = 200
|dir     = rtl
|caption    = Part of the ''Five Stars and Twenty-Eight Mansions'', by Liang Lingzan (梁令瓒), .
}}

Looking at the HTML:

<img alt="" src="//upload.wikimedia.org/wikipedia/commons/thumb/d/d2/五星二十八宿神形图.jpg/3840px-五星二十八宿神形图.jpg" decoding="async" width="3268" height="200" class="mw-file-element" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/d/d2/五星二十八宿神形图.jpg/6536px-五星二十八宿神形图.jpg 2x" data-file-width="16273" data-file-height="996">

Per https://www.mediawiki.org/wiki/Common_thumbnail_sizes, this likely needs to use a width (not height!) which is one of the common thumbnail widths.

3268px is not a common thumbnail width.

As 3840px is a common thumbnail width, in this case, setting height = 235 on that wiki page may fix this very issue.

See T414805: FY 25/26 WE 5.4.10 Standard Thumbnail Sizes Only for context.

I had thought that the point of the whole Standard Thumbnails system was for MediaWiki itself to fix the size and not require local users to do so.

Per https://www.mediawiki.org/wiki/Common_thumbnail_sizes, this likely needs to use a width (not height!) which is one of the common thumbnail widths.

3268px is not a common thumbnail width.

As 3840px is a common thumbnail width, in this case, setting height = 235 on that wiki page may fix this very issue.

It did not. Even setting the exact height required (235.02980396976587, to machine precision) didn't work.

It is trying to load the image with the width of 8137px which is bigger than largest standard thumbnail size. Meaning the logic short circuits and exposes the non-standard size. There are multiple ways to fix this:

• Serve the original (could be too big)
• Serve the biggest standard size (could make things blurry)
• ?

OTOH, we really shouldn't try to load an image that big. If my estimations are correct, it'd be around 1MB which is a not really nice for readers with bad internet connections.

Test of standard image sizes: https://en.wikipedia.org/w/index.php?title=User:LaundryPizza03/sandbox4&oldid=1350183844.

Width 1920px (height 117.514901984882935 px) works. Should we use this width or 1/2 size?

In T423895#11840139, @Ladsgroup wrote:

It is trying to load the image with the width of 8137px which is bigger than largest standard thumbnail size. Meaning the logic short circuits and exposes the non-standard size. There are multiple ways to fix this:

• Serve the original (could be too big)
• Serve the biggest standard size (could make things blurry)
• ?

OTOH, we really shouldn't try to load an image that big. If my estimations are correct, it'd be around 1MB which is a not really nice for readers with bad internet connections.

I think serve the original file is the most correct thing to do. A 1mb file (Although this file is actually 4mb) is better than no image at all and most long articles have more than 1mb of combined files anyways. Images are loaded async so I don't think it is really that bad for bad internet connections, they can just hit stop on the browser.

There are probably some extreme examples where that doesn't make sense (File:Tapisserie_de_Bayeux.png ) but for the most part, i think most users would prefer a large image over no image, at least up to 20 mb.

(I also encountered the error on a different page where the src image is fine, but the srcset 2x image is not, which seems really bad)

996px is too tall to fit in a typical browser window, so I have opted for 1/2 size.

In T423895#11840594, @Bawolff wrote:

In T423895#11840139, @Ladsgroup wrote:

It is trying to load the image with the width of 8137px which is bigger than largest standard thumbnail size. Meaning the logic short circuits and exposes the non-standard size. There are multiple ways to fix this:

• Serve the original (could be too big)
• Serve the biggest standard size (could make things blurry)
• ?

OTOH, we really shouldn't try to load an image that big. If my estimations are correct, it'd be around 1MB which is a not really nice for readers with bad internet connections.

I think serve the original file is the most correct thing to do. A 1mb file (Although this file is actually 4mb) is better than no image at all and most long articles have more than 1mb of combined files anyways. Images are loaded async so I don't think it is really that bad for bad internet connections, they can just hit stop on the browser.

Of those two options, I agree, a large file is better than a broken image.

A better third option would be to allow larger thumbnail sizes. For example, the list currently ends with 1920 and 3840, which are 960×2 and 960×4. Perhaps continue that progression by allowing thumbnails sized at 960×2^n for any integer n, up to the limits of the relevant data type.

In T423895#11840594, @Bawolff wrote:

In T423895#11840139, @Ladsgroup wrote:

It is trying to load the image with the width of 8137px which is bigger than largest standard thumbnail size. Meaning the logic short circuits and exposes the non-standard size. There are multiple ways to fix this:

• Serve the original (could be too big)
• Serve the biggest standard size (could make things blurry)
• ?

OTOH, we really shouldn't try to load an image that big. If my estimations are correct, it'd be around 1MB which is a not really nice for readers with bad internet connections.

I think serve the original file is the most correct thing to do. A 1mb file (Although this file is actually 4mb) is better than no image at all and most long articles have more than 1mb of combined files anyways. Images are loaded async so I don't think it is really that bad for bad internet connections, they can just hit stop on the browser.

There are probably some extreme examples where that doesn't make sense (File:Tapisserie_de_Bayeux.png ) but for the most part, i think most users would prefer a large image over no image, at least up to 20 mb.

(I also encountered the error on a different page where the src image is fine, but the srcset 2x image is not, which seems really bad)

The width of content in the new vector is around 1000px, the width of viewport for virtually all screens won't exceed 2000px and if you count the retina/high dpi, having more than images more than 4,000px won't be useful. Plus larger thumbnails and images put an undue burden on the infra (can't be cached on varnish and/or take a pretty large space displacing many smaller more hit images and takes a lot more bandwidth in backhauls, something that has been causing issues (when combined with scrapers, we live in a different internet) and as such I think allowing thumbs larger than 3840px is too risky for the infrastructure. Originals have a lot of different rate limits and we are working on splitting them to a dedicated infrastructure (and QoS in network, etc.) so they can't be compared with thumbnails.

Change #1275921 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/core@master] Media: Fallback to the largest standard size if an overly large one is requested

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

Change #1275921 merged by jenkins-bot:

[mediawiki/core@master] Media: Fallback to the largest standard size if an overly large one is requested

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

In T423895#11844017, @Ladsgroup wrote:

[…] I think allowing thumbs larger than 3840px is too risky for the infrastructure. Originals have a lot of different rate limits and we are working on splitting them to a dedicated infrastructure (and QoS in network, etc.) so they can't be compared with thumbnails.

In T423895#11845111, @gerritbot wrote:

Change #1275921 merged by jenkins-bot:

[mediawiki/core@master] Media: Fallback to the largest standard size if an overly large one is requested

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

FYI: This essentially re-applies part of my reverted patch (patch one, patch two).

While I agree with the premise and intention to disallow thumbnails beyond 3840px, that is not what the patch does. The patch also disallows thumbnails at the original size for non-websafe formats such as PDF and TIFF, which means it re-introduces the regression at T419927: PNGs are being displayed at a too-low, blurry resolution. This is now being discussed at T424114: Optimal thumbnails for size vs. quality optimized book pages are not available.

In T423895#11849140, @Krinkle wrote:

While I agree with the premise and intention to disallow thumbnails beyond 3840px, that is not what the patch does. The patch also disallows thumbnails at the original size for non-websafe formats such as PDF and TIFF, which means it re-introduces the regression at T419927: PNGs are being displayed at a too-low, blurry resolution. This is now being discussed at T424114: Optimal thumbnails for size vs. quality optimized book pages are not available.

Can you describe it in more details because that is not my reading of the code at all. The for loop in line 196 in ImageHandler has only return statements (explicitly, no break statement). That means the only way to reach line 220 is that the requested size must be bigger than the largest standard size (3840px). For which, the regression mentioned in T419927 does not trigger and thus it's not being re-introduced. I will backport the patch tomorrow and you can see the image in https://en.wikipedia.org/wiki/File:Psikyo-Koyori_artwork.png will look normal (the problem reported). The only cases that it could happen is that the requested size is bigger than 3840px which again, shouldn't be requested in the first place. Plus virtually all cases that it could show up is in 2x which won't make it blurry as long as 1x stays below 3840px.

In T423895#11849488, @Ladsgroup wrote:

In T423895#11849140, @Krinkle wrote:

[…] The patch also disallows thumbnails at the original size for non-websafe formats such as PDF and TIFF, which means it re-introduces the regression […] now discussed at T424114: Optimal thumbnails for size vs. quality optimized book pages are not available.

[…] I will backport the patch tomorrow and you can see the image in https://en.wikipedia.org/wiki/File:Psikyo-Koyori_artwork.png will look normal (the problem reported). […]

PNG is web-safe so it won't happen for that one. T424114 is about PDF and TIFF.

However, I'm wrong about your patch being the cause. Your patch hasn't been deployed yet. This is actually a regression from a bit longer ago. This bug is actually a side effect of the loop preferring to round down in this case by selecting a previous step, even when between two small steps at low resolutions. This is something we implemented previously, and may be worth handling differently. Anyway, let's discuss at T424114.

Change #1276731 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):

[mediawiki/core@wmf/1.46.0-wmf.24] Media: Fallback to the largest standard size if an overly large one is requested

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

Change #1276731 merged by jenkins-bot:

[mediawiki/core@wmf/1.46.0-wmf.24] Media: Fallback to the largest standard size if an overly large one is requested

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

Mentioned in SAL (#wikimedia-operations) [2026-04-23T16:20:36Z] <ladsgroup@deploy1003> Started scap sync-world: Backport for [[gerrit:1276731|Media: Fallback to the largest standard size if an overly large one is requested (T418745 T423895)]]

Mentioned in SAL (#wikimedia-operations) [2026-04-23T16:22:11Z] <ladsgroup@deploy1003> ladsgroup: Backport for [[gerrit:1276731|Media: Fallback to the largest standard size if an overly large one is requested (T418745 T423895)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-04-23T16:26:29Z] <ladsgroup@deploy1003> Finished scap sync-world: Backport for [[gerrit:1276731|Media: Fallback to the largest standard size if an overly large one is requested (T418745 T423895)]] (duration: 05m 53s)

Change #1277086 had a related patch set uploaded (by Reedy; author: Ladsgroup):

[mediawiki/core@REL1_45] Media: Fallback to the largest standard size if an overly large one is requested

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

Change #1277087 had a related patch set uploaded (by Reedy; author: Ladsgroup):

[mediawiki/core@REL1_44] Media: Fallback to the largest standard size if an overly large one is requested

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

Change #1277088 had a related patch set uploaded (by Reedy; author: Ladsgroup):

[mediawiki/core@REL1_43] Media: Fallback to the largest standard size if an overly large one is requested

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

Change #1277088 merged by jenkins-bot:

[mediawiki/core@REL1_43] Media: Fallback to the largest standard size if an overly large one is requested

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

Change #1277087 merged by jenkins-bot:

[mediawiki/core@REL1_44] Media: Fallback to the largest standard size if an overly large one is requested

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

Change #1277086 merged by jenkins-bot:

[mediawiki/core@REL1_45] Media: Fallback to the largest standard size if an overly large one is requested

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