The problem is more likely to occur in a shared web server environment where you are limited in how much memory can be allocated to PHP. In my case, my service provider claims that 20M is the maximum, although phpinfo() reports 40M. As other posts have pointed out, it is the number of pixels that determine how large the uncompressed image is. An other factor would be the color depth: 8-, 16- or 24-bit. Displaying the images natively is not a problem, since the images do not need to be uncompressed. I have seen indications that ImageMagick requires less memory than the standard GD library when creating thumbnails, but have not been able to test myself (standard ImageMagick install will not work in a shared environment). Norbert
----- Message from "Itay Ophir" itay@worldwideworkshop.org on Wed, 9
Jan 2008 01:45:53 -0500 -----
So, if someone uploads large resolution picture do ALL wikis break? or
is it
only some of them? I am trying to regroup and find a solution/cause for error.
2008/1/8, Grietinus Koops grietinus@gmail.com:
Thanks Itay! This worked! But same as you I'm curious about the logic behind it. As there is a
limit
of 20M for some reason. 2500 x 1600 pixels generates far less than 20MegaBytes I would say. And then it's only in case of thumbnail view...
I'm open for suggestions :)
Norbert Hoeller wrote:
The problem is more likely to occur in a shared web server environment where you are limited in how much memory can be allocated to PHP. In my case, my service provider claims that 20M is the maximum, although phpinfo() reports 40M. As other posts have pointed out, it is the number of pixels that determine how large the uncompressed image is. An other factor would be the color depth: 8-, 16- or 24-bit. Displaying the images natively is not a problem, since the images do not need to be uncompressed. I have seen indications that ImageMagick requires less memory than the standard GD library when creating thumbnails, but have not been able to test myself (standard ImageMagick install will not work in a shared environment).
There are three main benefits of using ImageMagick:
1) Better scaling quality
2) Since it runs out of process, if the scaling fails (eg due to memory limits), the rest of the wiki keeps running. You just don't have a working image.
3) For JPEG images (at least in some versions), ImageMagick can scale large images without decompressing the entire file into memory/scratch space first. (GIF and PNG images still require loading the whole thing.)
How much memory (or scratch disk) ImageMagick will actually use depends on what mode it's been compiled in (8-bit, 16-bit, or 32-bit pixel depth), but you don't always have to worry too much about that.
MediaWiki has a switch to disable scaling of very large images:
/** * Don't thumbnail an image if it will use too much working memory * Default is 50 MB if decompressed to RGBA form, which corresponds to * 12.5 million pixels or 3500x3500 */ $wgMaxImageArea = 1.25e7;
You can decrease that size to keep large images from breaking the entire system... *however* it isn't applied to JPEG images due to ImageMagick's nicer behavior with them.
To make it apply to JPEGs as well (eg for GD) you might have to hack out the exception for now. Probably we should fix it to check this automatically.
(In current MediaWiki this is in includes/media/Bitmap.php. In older versions you'll probably find it in includes/Image.php)
-- brion vibber (brion @ wikimedia.org)
By the way, there's me railing: http://commons.wikimedia.org/wiki/Commons:Graphics_village_pump/December_200...
jidanni@jidanni.org wrote:
By the way, there's me railing: http://commons.wikimedia.org/wiki/Commons:Graphics_village_pump/December_200...
The particular case there is an animated GIF, which is one of those fun worst cases. It might be nice to have a clean way to detect animated files and treat them specially; at a minimum I'm sure there's work yet to be done on ensuring that they're generated optimally. (Though it might be best to just not thumbnail them.)
-- brion vibber (brion @ wikimedia.org)
On 09/01/2008, Brion Vibber brion@wikimedia.org wrote:
Norbert Hoeller wrote:
uncompressed. I have seen indications that ImageMagick requires less memory than the standard GD library when creating thumbnails, but have not been able to test myself (standard ImageMagick install will not work in a shared environment).
There are three main benefits of using ImageMagick:
- Better scaling quality
- Since it runs out of process, if the scaling fails (eg due to memory
limits), the rest of the wiki keeps running. You just don't have a working image. 3) For JPEG images (at least in some versions), ImageMagick can scale large images without decompressing the entire file into memory/scratch space first. (GIF and PNG images still require loading the whole thing.)
ImageMagick really is the nicer way to do this stuff. I found it a bit painful on Solaris 9, with no package repository system and resolving dependencies by hand from sunfreeware.com ... BlastWave on Solaris 10 is a bit easier. But the best way is IME to use a Linux system with a good repository. (CentOS 4.5 was okay for me - the only annoying bits were PHP 5 stuff from centosplus and one RPM for PHP5 to talk to MySQL. Yes, I'll document this on mediawiki.org some time ...)
ImageMagick also does SVGs, but it's crap at them. librsvg is the only sane way IMO. This too has a ridiculously long string of dependencies (probably all the way down to the original .au of the Free Software Song) so you really don't even want to attempt it unless it's in the repository system of whatever you're installing it on. (again, fine on CentOS 4.5.)
- d.
mediawiki-l@lists.wikimedia.org