Last modified: 2014-10-03 12:03:34 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 29967 - Better support for viewing and downloading large files
Better support for viewing and downloading large files
Status: NEW
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
All All
: Lowest enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: design
Depends on:
Blocks: commons
  Show dependency treegraph
Reported: 2011-07-19 19:40 UTC by Derrick Coetzee
Modified: 2014-10-03 12:03 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Mock-up of view/download options pop up window. (263.63 KB, image/png)
2011-07-19 19:40 UTC, Derrick Coetzee

Description Derrick Coetzee 2011-07-19 19:40:37 UTC
Created attachment 8804 [details]
Mock-up of view/download options pop up window.

I've uploaded a number of very large images approaching the file size limit to Wikimedia Commons. An 90 MB, 83 megapixel example, used in about 2000 articles, is shown here:,_by_Leonardo_da_Vinci,_from_C2RMF_retouched.jpg

I've received complaints from users who wish to download the image but find it is too time-consuming or expensive to do so, or that the images occupy too much memory to load and view/edit on their computer. Some users click on the image on the file description page and accidentally find themselves downloading a very large file, which is problematic when they pay a lot for bandwidth, and sometimes it crashes or hangs their browser (or simply fails to display). The Download button feature allows downloads of thumbnails, but only goes up to 1024 px wide and is not available in Internet Explorer or on other wikis.

I'm proposing a change in which:
* Each user has a maximum download size (a user preference, default for logged-out users: 3 MB). Below this size, the current behavior occurs when clicking on an image. Above this size, clicking on an image will pop up a "view and download options" window.
* The view and download options pop up window offers several download links (see my mock up at, also attached). In my example, 5 options are given, 1024 px wide, 1280 px wide, 10 megapixels, 20 megapixels, and full size.
* Many browsers are not able to view very large images (e.g. over 30 megapixels) inline without breaking due to the memory needed to hold the decoded image. When downloading images over a certain megapixel size, the link should automatically Save As, rather than viewing in browser.
* This feature should be available on all file description pages on all wikis, including pages that show files that are actually stored on Commons.

See for a thread on this (will update this link once the thread is archived). There doesn't appear to be any opposition on Commons to the idea at this stage.
Comment 1 Dan Collins 2011-07-19 23:17:01 UTC
I'm noticing that the link that I would click on to download the full version says:
Full resolution‎ (7,479 × 11,146 pixels, file size: 89.94 MB, MIME type: image/jpeg)

I don't understand the following complaint:
"I've had other users become very upset - and even revert me - when replacing low resolution images by higher resolution ones, on the grounds that "the high res ones take too long/cost too much to download"."

If higher resolution images are included in articles, then they are thumbnailed prior to rendering. If the users are complaining about the image on the description page, then there is an option in Special:Preferences to limit the size of that image. If users are complaining that the full-res image is too large, then they should read the descriptive, obvious, and well-placed text right next to the full resolution link that gives the size of the image both in pixels and in bytes.

Further, as a commentor on that thread indicates, a gadget already exists which allows users who specifically need higher-than-article-resolution but not full-resolution images to download images at a specific scaled down size, and those sizes can be configured to a user's needs.

By the design of our image presentation, every place a user will come across an image, they find a scaled down image, which they can set limitations on the size of. The only place where a user can not configure a limit on the size of an image is the full resolution link, which clearly states what the user is getting. If they accidentally click that and then realize what they did wrong, they can click the back button or cancel the download. If they can not handle even the smallest configurable thumbnail size, we generally try to make sure that wikis will behave well on text-only browsers. There is no missing functionality.

'Workarounds' for this problem include using the preferences made available under Appearance->Files, using the gadget mentioned at your last link, and reading the text next to the full resolution link before clicking it.

Did I miss anything?
Comment 2 Brion Vibber 2011-07-19 23:50:53 UTC
I definitely agree that this is an issue; people will usually expect to click through to a 'full-size' image that's somewhere in the single-digit megapixels, not something that'll allocate so much memory it crashes their browser or turns their photo editor or word processor into swapping hell.

"Obvious well-placed text" usually won't be noticed; many people may not even really be aware what it means if they do see it, but many more will never even see it -- they'll just click through on the image and have their browser fall into a swapping death.

Forcing a 'save as' is a bit tricky unfortunately; can be done by streaming the file through the application servers and adding a Content-Disposition header (as img_auth.php and thumb.php can), though that may be funky to do in context without losing caching.

Broadly speaking I'd support a cleaner look with saner, safer default links and a friendlier way to select a size & trigger downloads. Photo sites like flickr sometimes do this better (though we wouldn't necessarily want to emulate every little feature of their layout!)
Comment 3 Bryan Tong Minh 2011-07-20 07:45:33 UTC
We could go even one step further, and add this little information box to *all* our thumbs, also those embedded in articles, with a box like:

* View author, license and other file information
* Downloads scaled down version
** 800x600 pixels
** 1024x768 pixels
** 2048x1536 pixels
* Download full version (20000x2000 pixels; 10 gazillion bytes)

That might be controversial though.
Comment 4 Jean-Fred 2013-03-29 13:21:20 UTC
Adding 'design' keyword, as it seems to be the main blocker.

Note You need to log in before you can comment on or make changes to this bug.