As the first part of FY 25/26 WE 5.4.7 Standardize thumbnail sizes, we want a list of canonical thumbnail sizes in use. This task is an attempt to produce that.
Starting with the easy bits, the set of thumbnail sizes that users can choose are set per-wiki as `wgThumbLimits`, with the default being set by `wmgThumbsizeIndex`:
```lang=php
// Do not add more exceptions.
// Thumbnails must be shared between wikis.
'wgThumbLimits' => [
'default' => [ 120, 150, 180, 200, 220, 250, 300, 400 ],
'+itwikiquote' => [ 360 ],
'svwiki' => [ 120, 200, 250, 300, 360 ],
# nlwiki uses 260 instead of 250 (T215106)
'nlwiki' => [ 120, 150, 180, 200, 220, 260, 300, 400 ],
],
// Do not add more exceptions. Default should stay the same between wikis.
'wmgThumbsizeIndex' => [
'default' => 5,
'svwiki' => 2, // T18739
],
```
So the default is 250 everywhere except nlwiki where it's 260 (per T215106). **UPDATE**: after [[https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1201584 | change 1201584]] was merged, it is now 250 everywhere. In any case, whichever of these sizes the user chooses, they in fact download the thumb of greater-or-equal size in `$wgThumbnailSteps` and the browser scales it down.
The set of thumbnail sizes that are used by default are in `wgThumbnailSteps` (so MW will take other sizes (in all circumstances?) and serve the next-largest one of these instead):
```lang=php
$wgThumbnailSteps = [ 20, 40, 60, 120, 250, 330, 500, 960 ];
```
The set of thumbs that are generated on image upload is defined in `wgUploadThumbnailRenderMap` (I don't think `wgThumbnailBuckets` is used in our deployment, since we don't make size-based thumb buckets?)
```lang=php
// Thumbnail chaining
'wgThumbnailBuckets' => [
'default' => [ 1280 ],
],
'wgThumbnailMinimumBucketDistance' => [
'default' => 100,
],
// Thumbnail prerendering at upload time
'wgUploadThumbnailRenderMap' => [
'default' => [ 320, 640, 800, 1280 ],
'private' => [],
],
```
Users can choose the size of preview they see on file pages on commons from the list defined in `ImageLimits`:
```lang=php
public const ImageLimits = [
'default' => [
[ 320, 240 ],
[ 640, 480 ],
[ 800, 600 ],
[ 1024, 768 ],
[ 1280, 1024 ],
[ 2560, 2048 ],
],
'type' => 'list',
];
```
Here if they pick one of the smaller sizes, they get the next-largest from `$wgThumbnailSteps` scaled in-browser (i.e. 330 scaled to 320, 960 scaled to 800 or 640), above 960 they get the requested size.
Extension:MultimediaViewer has a set of MediaViewerThumbnailBucketSizes which are the set of thumbnail sizes it'll request and then scale according to how big the MediaViewer browser window is. **UPDATE**: T372165 has reduced this set to `400, 960, 1280, 2560 ` and is considering changing the first to 500 or maybe 480. These are not affected by `$wgThumbnailSteps`.
```lang=json
"MediaViewerThumbnailBucketSizes": {
"description": "Array of preselected widths used to generate thumbnail URLs to avoid arbitrary size requests (see also wgUploadThumbnailRenderMap).",
"value": [
320,
800,
1024,
1280,
1920,
2560,
2880
],
"merge_strategy": "provide_default"
```
It offers a different set of download size options, set in `mmv.ui.utils.js`. Unlike the previous, these __are__ impacted by `$wgThumbnailSteps`, so a user asking for a "small 640x480" download will in fact get the 960px thumb(!)
```lang=js
const buckets = {
small: { width: 640, height: 480 },
medium: { width: 1280, height: 720 }, // HD ready = 720p
large: { width: 1920, height: 1080 }, // Full HD = 1080p
xl: { width: 3840, height: 2160 } // 4K = 2160p
};
```
The size in image galleries is set as `wgGalleryOptions`, which is consistent everywhere except svwiki:
```lang=php
'wgGalleryOptions' => [
'default' => [
'imagesPerRow' => 0,
'imageWidth' => 120,
'imageHeight' => 120,
'captionLength' => true,
'showBytes' => true,
'mode' => 'traditional',
],
'+svwiki' => [
'imageWidth' => 150,
'imageHeight' => 150,
],
],
```
So much for the wikis, what about the mobile apps? The below has now been reviewed by relevant Android and iOS experts.
Android first, I find:
```
app/src/main/java/org/wikipedia/Constants.kt
const val PREFERRED_CARD_THUMBNAIL_SIZE = 800
app/src/main/java/org/wikipedia/dataclient/Service.kt
const val PREFERRED_THUMB_SIZE = 320
app/src/main/java/org/wikipedia/places/PlacesFragment.kt
const val THUMB_SIZE = 160
```
The iOS app has a deprecated function in `WMF Framework/WMFArticle+Extensions.h`:
```
@property (nonatomic, nullable) NSURL *thumbnailURL; // Deprecated. Use imageURLForWidth:
```
which has a hardcoded value:
```
return [self imageURLForWidth:240]; //hardcoded to not rely on UIScreen in a model object
```
but I think elsewhere it uses values taken from the following enum (which can be scaled up x2 on retina devices so 120,240, etc.)
```lang=c
typedef NS_ENUM(NSInteger, WMFImageWidth) {
/**
* The smallest image width we will show, e.g. in search cell thumbnails.
*
* There's no guarantee about image aspect ratio, so we fetch a little more and use aspect fill.
*/
WMFImageWidthExtraSmall = 60,
/**
* The next-smallest thumbnail we'll show, e.g. in nearby cell thumbnails.
*/
WMFImageWidthSmall = 120,
/**
* A medium width, e.g. POTD & lead images.
*/
WMFImageWidthMedium = 320,
/**
* A slightly larger width, e.g. modal gallery.
*/
WMFImageWidthLarge = 640,
WMFImageWidthExtraLarge = 1280,
WMFImageWidthExtraExtraLarge = 1920
};
```
There's also a bug discovered while looking at this (T408859) that for the talk page header it takes a static side length of 80 and asks for the retina scale (1,2,3), so 80, 160, 240; the expectation is that will be fixed to use the standard enum sizes mentioned above.
Finally(?) there's the Android Commons app, which sets `const val THUMB_IMAGE_SIZE = "70px"` and `const val THUMB_HEIGHT_PX = 450` (which is unusual in being height rather than widge).
All told, our list stands as follows. The frequency at which these occur in requests is measured in T410304.
20
40
60
70
80
120
150
160
180
200
220
240
250
~~260~~ [no longer canonical]
300
320 [pregenerated]
330
360
400
450 [height setting]
500
640 [pregenerated]
800 [pregenerated]
960
1024
1280 [pregenerated]
1920
2560
2880
3840