Page MenuHomePhabricator

Add larger sizes to $wgImageLimits on commons
Open, Needs TriagePublic

Description

per https://commons.wikimedia.org/?oldid=165672017 People want larger sizes on $wgImageLimits

This should generally not affect performance, as the larger size would only be rendered if the user specificly clicked on it. Doing

$wgImageLimits[] = array( '2048', '1536' );
$wgImageLimits[] = array( '3200', '2400' );

would probably satisfy everyone (?)


Also have to look out for $wgSVGMaxSize which is really set way too low (and has a slightly buggy implementation).

Event Timeline

Bawolff created this task.Jul 19 2015, 10:57 AM
Bawolff raised the priority of this task from to Needs Triage.
Bawolff updated the task description. (Show Details)
Bawolff added a subscriber: Bawolff.
Restricted Application added subscribers: Steinsplitter, Aklapper. · View Herald TranscriptJul 19 2015, 10:57 AM
Restricted Application added a subscriber: Matanya. · View Herald TranscriptJul 19 2015, 10:58 AM

Should look like:

This image rendered as PNG in other widths: 200px, 500px, 1000px, 2000px.
Steinsplitter moved this task from Incoming to Backlog on the Commons board.Jul 19 2015, 11:15 AM

Fixed width isn't helpful. It is better to provide the PNG link of the same native/nominal size as the source SVG. Also there should be a width entry box for reader to generate the link of specific size on demand instead of providing bunch of presets.

Fixed width isn't helpful. It is better to provide the PNG link of the same native/nominal size as the source SVG.

There should already be a link to the nominal size if its sane. We are not going to provide a link to the nominal size if that size is something like 100000 x 100000 pixels

Also there should be a width entry box for reader to generate the link of specific size on demand instead of providing bunch of presets.

I don't think that's a good idea from a UX perspective. I'd be opposed to doing that in MediaWiki. (Commons can of course do that in JS if they want)

There should already be a link to the nominal size if its sane.

There is never a PNG render link of the nominal size unless the SVG native size is coincidentally the same as one of the presets.

There should already be a link to the nominal size if its sane.

There is never a PNG render link of the nominal size unless the SVG native size is coincidentally the same as one of the presets.

https://commons.wikimedia.org/wiki/File:$100-school-server-_NetworkView.svg - nominal size is 506 × 337 there is a link under image:

Size of this preview: 506 × 337 pixels.

This will only be true if the nominal size is less than whatever Image size limit is set to in https://commons.wikimedia.org/wiki/Special:Preferences#mw-prefsection-rendering (defaults to 800x600). Admittedly 800x600 is a little low. I suppose it might make sense to add the nominal size as an "other" resolution if it happens to be bigger than the "image size limit" but less than $wgMaxSVGSize (4096px currently).

There should already be a link to the nominal size if its sane.

There is never a PNG render link of the nominal size unless the SVG native size is coincidentally the same as one of the presets.

https://commons.wikimedia.org/wiki/File:$100-school-server-_NetworkView.svg - nominal size is 506 × 337 there is a link under image:

Size of this preview: 506 × 337 pixels.

This will only be true if the nominal size is less than whatever Image size limit is set to in https://commons.wikimedia.org/wiki/Special:Preferences#mw-prefsection-rendering (defaults to 800x600). Admittedly 800x600 is a little low. I suppose it might make sense to add the nominal size as an "other" resolution if it happens to be bigger than the "image size limit" but less than $wgMaxSVGSize (4096px currently).

Actually, it looks like this is only because of a typo in the source code. In principle its supposed to always display the nominal size in the list.

There should already be a link to the nominal size if its sane.

There is never a PNG render link of the nominal size unless the SVG native size is coincidentally the same as one of the presets.

https://commons.wikimedia.org/wiki/File:$100-school-server-_NetworkView.svg - nominal size is 506 × 337 there is a link under image:

Size of this preview: 506 × 337 pixels.

This will only be true if the nominal size is less than whatever Image size limit is set to in https://commons.wikimedia.org/wiki/Special:Preferences#mw-prefsection-rendering (defaults to 800x600). Admittedly 800x600 is a little low. I suppose it might make sense to add the nominal size as an "other" resolution if it happens to be bigger than the "image size limit" but less than $wgMaxSVGSize (4096px currently).

Actually, it looks like this is only because of a typo in the source code. In principle its supposed to always display the nominal size in the list.

Slightly off topic for this bug, but the fix for that is https://gerrit.wikimedia.org/r/225688

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptNov 15 2015, 6:24 AM
Dereckson added subscribers: Gilles, Dereckson.

@Gilles Is there a performance impact for this change?

Restricted Application added a subscriber: JEumerus. · View Herald TranscriptMar 15 2016, 7:26 PM

The performance impact depends on how many people enable the new bigger sizes. If it's not many people, they will themselves experience a performance impact by having a high likelihood of triggering thumbnail generation on the fly. Although, since we currently keep all thumbnails forever, this will get better with time. And the more people use those sizes, the smaller the chance that each person will experience it individually.

There is however a financial cost to doing this. Since we currently store as many as 6 copies of each thumbnail forever (an issue we're trying to solve at the moment, but is still months away from being resolved), and since those would be large sizes, it might require extra swift capacity, and thus, an actual cost.

This would be a lot easier to accept once the production thumbnailing overhaul is done and we don't store that many copies or thumbnails, nor store them forever. I would personally recommend waiting for that to happen, since I'm working full time on this overhaul.

I totally understand the need this is coming from, and this is precisely why we're redoing the thumbnailing infrastructure. It's been very frustrating not to be able to adapt to bigger screen sizes and pixel density, etc. rapidly because of how wasteful our current setup is.

@Gilles I wonder if the software is able to detect if the specific size is actually being used in any wiki page instead of being called merely "for personal use" so the system will remove the thumbnail of the latter case to free up some space.

Restricted Application added a subscriber: Poyekhali. · View Herald TranscriptMay 30 2016, 7:59 AM

The current architecture doesn't allow us to detect and remove "unused" thumbnails, otherwise we would. This is we we're revisiting that whole system.