mac.kenzie wrote:

I certainly support this measure. I recently purchased a UHD monitor and even with thumbnail size preference set to 300px the images are often too small to see sufficient detail to make use of them.

When the bulk of monitors were 1024x, the 300 px limit was sufficient, but in the era of "retina" displays and now 4K monitors this limit is actually hindering usability of Wikipedia.

I understand certain developments within Media Wiki Viewer may lend themselves to this change given the caching issue with the image secsets to be used.

360px would be welcome for sure but it may be the right time to look at even larger thumbs given pixel density developments.

Context: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=602688540#Reboot. The two comments above focus on Wikimedia project(s) configuration, hence moving there. I suggest a separate bug report for MediaWiki defaults, with considerations about third party users of MediaWiki.

We can see if sysasmins have something to say about this before it actually becomes a request, but until there is on-wiki consensus (on the village pump for individual wikis or [[m:Wikimedia Forum]] for all wikis) I'm adding the relevant keyword.

For what it's worth, bandwidth *is* a problem at least in some cases and at least according to some.
https://www.mediawiki.org/wiki/Requests_for_comment/Reducing_image_quality_for_mobile

We already had similar requests previously and I am the one that rejected them:

Bug 27839 - Offer 460px and 620px as thumbnail size preferences
Bug 41712 - hewiki asks to change default image sizes for thumb and gallery
Bug 47332 - en.Wikivoyage: increase default image thumb size

The reason for rejecting such requests is on https://bugzilla.wikimedia.org/show_bug.cgi?id=41712#c14 and I am copy pasting it there:

Here is a summary I have posted on Gerrit change #31580 which is based off a discussion we had in a restricted mailing list:

It is not reasonable for us to handle different thumbnail sizes per wiki for the following reasons:

• we keep thumbnails forever currently, the more we have the more disk space it takes
• different sizes lower the cache hit rate which in turns cause...
• ... a CPU cost on the cluster to generate a thumbnail, varying the sizes cause more and more thumbnails generations
• whenever a file is updated, we have to purge each thumbnails ever generated

The consensus among the engineering team is to standardize the thumbnails to a few well known formats and have the scaling being done by the web browser. We could let the mobile clients scale up small thumbnails (to save bandwidth) and desktop scale down larger thumbnails (to get nicer pictures).

So I am sorry to say it, but that changes will not land on the live cluster.

There is a few more details on the RFC https://www.mediawiki.org/wiki/Requests_for_comment/Standardized_thumbnails_sizes though we haven't pushed to find a solution. I wrote the document as a reference to discard requests to raise the thumbnail limit.

Sorry. Feel free to bring the subject again on wikitech-l.

(In reply to Antoine "hashar" Musso from comment #3)

It is not reasonable for us to handle different thumbnail sizes per wiki for
the following reasons:

• we keep thumbnails forever currently, the more we have the more disk space

it takes

• different sizes lower the cache hit rate which in turns cause...
• ... a CPU cost on the cluster to generate a thumbnail, varying the sizes

cause more and more thumbnails generations

• whenever a file is updated, we have to purge each thumbnails ever generated

Would it be feasible to use the same (but different than the current one) set of sizes for all wikis? Would it be feasible to replace the 7 current sizes with, say, 4 that are in general a bit larger?

I don't see these questions answered anywhere, and I don't have access to the "restricted mailing list" to check if they were addressed there.

(In reply to Bartosz Dziewoński from comment #4)

Would it be feasible to use the same (but different than the current one)
set of sizes for all wikis? Would it be feasible to replace the 7 current
sizes with, say, 4 that are in general a bit larger?

I don't see these questions answered anywhere, and I don't have access to
the "restricted mailing list" to check if they were addressed there.

Please follow up on wikitech-l and eventually on the RFC talk page as well. Bugzilla is not the best place to emit such a new proposal :-]

Antoine, I'm concerned that I may not have been clear: you have WONTFIXed this on the grounds that you don't want to have different cache sizes for each WMF wiki.

Good: consider this to be a request to STOP having different cache sizes for different wikis.

The request here is really to START offering the SAME (in one case, bigger) cache size that is ALREADY being offered to sv.wikipedia. These files are already being cached; they're just not being offered to everyone.

If your goal is to have the same sizes at all WMF sites, then the correct response to this request is to change the current three-different-configurations settings in http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php

'wgThumbLimits' => array(

'default' => array( 120, 150, 180, 200, 220, 250, 300 ),
'+itwikiquote' => array( 360 ),
'svwiki' => array( 120, 200, 250, 300, 360 ),

),

to a simpler, all-wikis-get-the-same-options configuration:

'wgThumbLimits' => array(

'default' => array( 120, 200, 220, 250, 300, 360 ),

),

(As far as I'm concerned, the exact numbers chosen could be adjusted, so long as one option is the bigger size currently offered to two wikis.) If you really want to stop supporting multiple configurations, then the response to this bug should be "yes, immediately" rather than "no, never".

WhatamIdoing I appreciate your effort. But please follow up on wikitech-l and eventually on the RFC talk page as well.

Lets just reword this:

The community really wants an option for bigger images and doesn't want to wait, The foundation wants bigger images by defat but needs months more to decide where it truly wants to go, before it wants to dedicate resources on the complicated process that is required to realize any sort of more substantial change.

Can we not just, for ALL wikis:

• remove a few small sizes from the thumb options
• delete their thumbs
• Add one larger size (360 ?)
• Not change the default for the thumb size

Other than human effort, this should be a differential of almost 0 (or at most a few gigabytes).

This would probably keep the communities OK for a few more months, while we all debate over a more permanent solution (and keep sending users from the front desk to the information desk, to the helpdesk). At the very least, sending the common user to wikitech-l doesn't seem like the right response either.

Let me remove myself from this bug CC list. Bring it to wikitech-l PLEASE.

mac.kenzie wrote:

I can't quite understand what Antoine is saying "no" to as he seems to be addressing something other than that which is being asked.

How did two other projects get approved for 360px? Although with next gen retina displays even 360px is going to be an issue. However, I'd take 360px as a start if it is easy to implement.

(In reply to mac.kenzie from comment #10)

I can't quite understand what Antoine is saying "no"

Sigh... Antoine didn't say "no" in this bug report. You mistake a summary of previous arguments&discussions for personal opinions by the messenger.
And yet another time: Please bring this topic to wikitech-l@.

mac.kenzie wrote:

I am not being obtuse just rather uninformed about process. So I would love to bring it to wikitech-l if I knew what that was.

http://www.google.com/?q=wikitech-l

I think that it is perfectly reasonable for Mac.Kenzie to interpret marking a request as "WONTFIX" as "saying no", regardless of whether Antoine is doing this on his own authority or as a messenger for some unknown person.

(In reply to WhatamIdoing from comment #14)

I think that it is perfectly reasonable for Mac.Kenzie to interpret marking
a request as "WONTFIX" as "saying no", regardless of whether Antoine is
doing this on his own authority or as a messenger for some unknown person.

Well hashar's comment states why he marked it wontfix. Its not that uncommon in bugzilla to mark something wontfix to reflect a previous decesion on the matter even if the decesion is made by somebody else.

mac.kenzie wrote:

Things that are common here are not common to my experience. That said I should have perhaps used Google first. Looks like I'll have to register for other mailing list.

BTW, not that I should suppose anyone cares, but this is being discussed here: https://en.wikipedia.org/wiki/User_talk:Jimbo_Wales#I_hate_it_here_too_sometimes...

(In reply to mac.kenzie from comment #16)

Things that are common here are not common to my experience. That said I
should have perhaps used Google first.

That's ok :). Just keep in mind that MediaWiki development is its own separate community, with similar but different norms then say Wikipedia.

BTW, not that I should suppose anyone cares, but this is being discussed
here:
https://en.wikipedia.org/wiki/User_talk:
Jimbo_Wales#I_hate_it_here_too_sometimes...

Perma-link for posterity for anyone who cares: https://en.wikipedia.org/w/index.php?title=User_talk:Jimbo_Wales&oldid=603391713#I_hate_it_here_too_sometimes...
(Its your standard constructive dialog that takes place on Jimbo's talk page)

I have sent the e-mail to wikitech list: http://lists.wikimedia.org/pipermail/wikitech-l/2014-April/075849.html

Why is this marked as Community-consensus-needed? As long as the existing preferences for users are not changed, I don't see how community consensus would be required in this.

Most likely a relict of the past since this request was never rejected due to insufficient community consensus but due to very specific technical reasons.

was never rejected due to insufficient community consensus but due to very specific technical reasons.

"Very specific technical reasons" that apparently only apply to some projects, and not to others. Obviously, the thing can be done from a technical standpoint, because it has already been done. Can anyone explain why these very specific technical reasons do not apply to the Swedish Wikipedia or the Italian Wikiquote? For example, do these very specific technical reasons only apply to larger wikis? (That would seem perfectly reasonable to me, but I don't know if it's the relevant consideration.)

This was already discussed on wikitech-l, and no explanation was given for why some wikis are allowed to have what they want and others are not. The wikitech-l discussion includes:

• a proposal to remove the preference entirely, and to set the unchangeable default to what sv.wp already has;
• speculation that, if we create a task whose sole object is deliberately deleting caches of image sizes that are no longer used, the caches will somehow not get deleted anyway;
• a question about whether replacing eight different sizes of cached images with either one (larger) or two (one smaller and one larger) cached images might increase the amount of disk storage needed;
• an acknowledgement that some careful thought should be given to the one (or two) sizes chosen and the way it's deployed (e.g., to avoid having to re-render every single image at every single wiki at the same time);

and a few other comments like that. However, it does not contain even one sentence explaining why this configuration is acceptable from a technical standpoint for some wikis but not for others.

That's all I want to know right now: Why is this configuration such an impossibly bad idea for some wikis, even though it's just fine for others? Knowing the reason helps communities that want this changed. For example, if the issue is the amount of traffic at a project, then obviously such a change at en.wp or de.wp should be approached with trepidation – but if, say, the Finnish Wikipedia wanted to have the same settings as their neighbors in the Swedish Wikipedia, then it should be approved there. If the issue is the number of images, then Commons' default should never be changed, or at least never changed without first deliberately pre-cacheing every image, but it would be acceptable for projects that tend not to use many images, like several Wiktionaries. If the issue is the expected bandwidth of the users, then projects popular in developing countries should stick with smaller options, but there's no reason why projects largely based in countries with excellent infrastructure need to stick with the small images.

And right now, we can't predict the answers, because nobody can explain why these two projects get what they want, while the others are not permitted to have exactly the same thing that some projects already have.

(As you can doubtless tell, I'm very frustrated that we still cannot get a direct answer to this question.)

Could someone from one of the teams explain whether this is feasible or not, currently?

In T65440#1386068, @Glaisher wrote:

Could someone from one of the teams explain whether this is feasible or not, currently?

I think it's feasible. I'll submit a patch and see where it goes.

These are the sizes currently used by Media Viewer:

320, 800, 1024, 1280, 1920, 2560, 2880

Adding any of those to wgThumbLimits shouldn't have a significant impact on capacity/caching, since Media Viewer is already using them. 320 seems like a no-brainer, but is it really satisfying, given how close it is to 300?

Wouldn't it be interesting to explore using 800 displayed as 400px CSS-wise, so that retina displays get a sharper image? It seems like some of these requests about increasing the size are about high definition screens. Serving retina-optimized thumbnails would require more work, though, and the bandwidth implications would be non-trivial. That extra image weight would also be completely counter-productive for non-retina displays.

Isnt that the point of that extra attribute with the 2x sizes, we already serve?

I didn't realize we did, so essentially if we introduce a brand new size, in terms of thumbnails we're actually introducing the new size, its 1.5x and its 2x.

Meaning that the current default list is actually, in terms of practical thumbnails sizes:

120, 150, 180, 200, 220, 225, 240, 250, 270, 300, 330, 360, 375, 400, 440, 450, 500, 600

I feel like we could be smarter about that default list if we looked for more overlap (1.5x and 2x sizes ended up being another default size or another size's 2x/1.5x). But that should be the subject of another task.

Same thing for the new bigger default to introduce, we can try to be smart about where its 1.5x and 2x land.

Merging the above list with Media Viewer sizes, we get:

120, 150, 180, 200, 220, 225, 240, 250, 270, 300, 320, 330, 360, 375, 400, 440, 450, 500, 600, 800, 1024, 1280, 1920, 2560, 2880

If we introduce 360 as a new default, it's already on the list itself. Its 1.5x (540) isn't and its 2x (720) isn't either. A bit costly in terms of cache fragmentation.

If we introduce 400 as the new default, it's already on the list itself. Its 1.5x (600) is as well and its 2x (800) is too.

In that respect, introducing 400px as a new default has the least impact cache-wise. 400px isn't what was initially suggested, though. Would people be happy with 400px as a new default?

I think we should build on multiples of 120 and 160. That should result in the following common cached image sizes: 120, 160, 180, 240, 320, 360, 480, 640, 720, 960, 1280, 1440, 1920... with 240 as the default.

That means no more 150 or 220 (and multiples of those).

In T65440#1442794, @Gilles wrote:

Wouldn't it be interesting to explore using 800 displayed as 400px CSS-wise, so that retina displays get a sharper image? It seems like some of these requests about increasing the size are about high definition screens.

High density sizes should not be included wgThumbLimits. MediaWiki already serves 1.5x and 2x versions of the rendered size using srcset. Our thumbnails buckets are automatically fragmented the 2x and 1.5x variants.

In T65440#1444161, @Gilles wrote:

In that respect, introducing 400px as a new default has the least impact cache-wise. 400px isn't what was initially suggested, though. Would people be happy with 400px as a new default?

400px has been specifically requested in the past by a couple of users.

I suspect that most people who want larger image sizes would be happy with anything that's bigger than what they can get now. Even 10% could make a positive difference for some people with limited vision or screens with high pixel density.

In T65440#1445230, @Edokter wrote:

I think we should build on multiples of 120 and 160. That should result in the following common cached image sizes: 120, 160, 180, 240, 320, 360, 480, 640, 720, 960, 1280, 1440, 1920... with 240 as the default.

That means no more 150 or 220 (and multiples of those).

I think that's a nice idea for a cleanup, but I see that as its own much bigger task than introducing a single new size. Because to make room for that many new sizes introduced by a redo of the list, we would need to delete terabytes of thumbnails from varnish and swift for default sizes that are removed from the list.

I chose those values as they inherently include their own 1.5x and 2x versions (not al of them need to be listed in preferences though). The cleanup is due anyway. I once suggested an expiring mechanism for (existing) thumbs that have been stale for 90 days, but it requires a daily task to run.

in terms of numbers on the swift side these are top50 sizes using the most space (data is from last august but I can run the numbers again if needed)

(size, bytes, how many files of that size)

1024,1983816338204,10317461
800,1611558739172,12428155
640,1178565345552,12886400
320,327225374293,12102106
1280,2271330939183,8496051
180,201621128644,16007728
120,138576139899,21609553
1200,1192529130821,4493242
1920,1074891116299,2043293
1600,637675797664,1651911
500,398172828541,6441459
48,32722842573,14787827
720,254683027206,2248037
768,254529830652,1558824
600,240281894064,2708978
300,214929956431,7330212
450,183784564418,3006382
440,165087861885,3149493
400,149166779881,3234547
576,138535844128,1290115
360,136365055731,3307340
200,123964523013,8136636
240,119759901311,6031216
330,109108356756,3283619
220,100530714585,5515811
250,99627557851,4660492
512,95582335930,1224549
594,83245068186,1172380
568,80708281097,1038669
375,75067386530,1838294
480,72172176271,1229971
150,68418303880,7662868
256,52559567762,2345570
270,50874853927,2046245
350,43436564299,1162991
2560,368381174631,443686
75,34391589368,9046808
100,31855481164,5613938
128,28262939760,3524798
225,25688799676,1360819
160,22579605440,1919223
80,22203569468,5004693
2000,207656381346,520892
192,19882347385,1520249
1599,186518366357,514815
2048,186502636949,281324
170,17399325377,1282248
135,15771675079,2049649
181,14683450778,1178398
90,14465715443,2726773

and top50 most used thumbsize

120,138576139899,21609553
180,201621128644,16007728
48,32722842573,14787827
640,1178565345552,12886400
800,1611558739172,12428155
320,327225374293,12102106
1024,1983816338204,10317461
75,34391589368,9046808
1280,2271330939183,8496051
200,123964523013,8136636
150,68418303880,7662868
300,214929956431,7330212
500,398172828541,6441459
240,119759901311,6031216
100,31855481164,5613938
220,100530714585,5515811
80,22203569468,5004693
250,99627557851,4660492
1200,1192529130821,4493242
128,28262939760,3524798
360,136365055731,3307340
330,109108356756,3283619
400,149166779881,3234547
440,165087861885,3149493
450,183784564418,3006382
90,14465715443,2726773
600,240281894064,2708978
64,9020988351,2625718
256,52559567762,2345570
720,254683027206,2248037
36,4039493795,2189284
96,11665773024,2053466
135,15771675079,2049649
270,50874853927,2046245
1920,1074891116299,2043293
160,22579605440,1919223
50,5225623624,1899484
60,6267629030,1898947
375,75067386530,1838294
103,11315156968,1693902
1600,637675797664,1651911
130,13263608872,1597009
768,254529830652,1558824
192,19882347385,1520249
72,5567373092,1429663
140,14024286384,1406542
32,3210115421,1372788
225,25688799676,1360819
576,138535844128,1290115
170,17399325377,1282248

@Gilles I take it new defaults will affect only new uploads? also plans on removing some smaller sizes like initially proposed?

Change 226051 had a related patch set uploaded (by Gilles):
Offer 400px as a thumbnail size available in Special:Preferences

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

@fgiunchedi no, it affects all files. Basically users can opt into viewing all thumbnails on articles as 400px. But the impact on new thumbnails being generated will be very minimal because:

• people who opted into 200px (an option that's already available) and viewing with a retina display that has a 2x ratio already view 400px thumbnails
• people who opted into 300px (an option that's already available) and viewing with a retina display that has a 2x ratio already view 600px thumbnails, which is 400px's 1.5x
• 400px's 2x (800px) for people who will use this new 400px option on a 2x retina display, is a Media Viewer bucket

All these factors mean that the likelihood that the sizes needed for this new 400px option (400px, 600px, 800px) have already been generated is quite high.

Also, keep in mind that people will have to opt into that new 400px option. There will be a ramp up as people do that gradually.

If you have data about recent traffic per thumbnail size, then we can look at dropping the least used of the small ones. We should take the overlap caused by the 1.5x and 2x retina support into account. I.e. each small option is 3 sizes in practice:

120 => 120, 180, 240
150 => 150, 225, 300
180 => 180, 270, 360
200 => 200, 300, 400
220 => 220, 330, 440
250 => 250, 375, 500
300 => 300, 450, 600

It would make sense to keep 200 and 300, given their overlap with each other and with 400. 120, 180, 220 and 250 would be interesting to look at, since they have no overlap at all for their retina sizes. I couldn't figure out if one of them is the default at a glance, though, which would obviously make it a poor option for a drop :)

The default is 220, btw. Defined in a very weird way by wmgThumbsizeIndex, which is the position of the default value in the wgThumbLimits array.

thanks for the detailed explanation @Gilles!

If it is a cheap (space wise) addition I'm not terribly worried, we can look into pruning old thumbs later on as well. Agreed a thumbs cleanup would be nice to have if anything just for the number of files (~15x the number of originals, taking ~half the disk space of originals)

In T65440#1466501, @Gilles wrote:

The default is 220, btw.

Isn't 440 better as new option, then? If the options grow by a factor of 1.5 or 2 like the retina thumbs, there is less multiplication of total sizes.

Choosing a multiplier of non-default sizes is of little help; very few people select preferences. If MediaViewer using 800px is so important, a task could be filed to make that 880 in the end. But of course all this is just nitpicking. :)

In T65440#1466580, @Nemo_bis wrote:

In T65440#1466501, @Gilles wrote:

The default is 220, btw.

Isn't 440 better as new option, then? If the options grow by a factor of 1.5 or 2 like the retina thumbs, there is less multiplication of total sizes.

No, because 440 would create 2 brand new sizes for retina that are not used by anything right now (660 and 880). If you look at @fgiunchedi 's stats for most used sizes above, you'll see that 400, 600 and 800 are high in that list. Whereas, without surprise, 660 and 880 aren't there at all. In fact 400 and 800 are more used than 440, and 600 isn't that far behind 440.

Quoting:

800,1611558739172,12428155
600,240281894064,2708978
440,165087861885,3149493
400,149166779881,3234547

800 is for MediaViewer and 600 probably for sv.wiki's default 300. Anyway, got it; bigger syncs may be helpful later but no need now. :) Thanks.

Change 226051 merged by jenkins-bot:
Offer 400px as a thumbnail size available in Special:Preferences

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

The change has just been deployed. 400px is now an option in Special:Preferences.

Thank you, @Gilles. I have created T106640: Choose a sensible set of thumbnail sizes for Special:Preferences for the next step in cleaning up the list of options.