https://bugzilla.wikimedia.org/show_bug.cgi?id=34241
--- Comment #4 from Bawolff <[email protected]> 2012-02-07 15:32:21 UTC --- Oh right, gif images are going to be bigger because they're animated so multiply everything by number of frames... Still, the $wgMaxAnimatedGifArea = 1.25e7; default should stop it from going over the limit (According to comment, that's about 50 mb in totally uncompressed form with 24bit colour, so I would imagine a gif image using only 255 colours should fit comfortably in that, [but i say that without knowing how imagemagick really works or what image magick actually does when scaling an image]) >Another problem (of too low shell memory) is, that you barely see any >substantial error message. The Thumb nails are simply not generated. Unless one has fancy thumbnailing configuration set up (like Wikimedia does) you should see the very cryptic and fairly useless error message about Memory allocation failed or delegate failed, etc. Are you saying you don't get those error messages? (Yes, ideally we would detect this error condition better and present something more human readable. However, this is probably a very difficult error to programmaticly catch from the mediawiki side) >I suggest to increase the value. Perhaps someone else has made similar >experiences, then it's a good moment to discuss it now here. I won't be pushing >to a higher value, I am just proposing this. My earlier comment (comment 1) was not meant to imply that we should keep it the same (or change it for that matter), only that 100mb seemed quite a large number already, and we shouldn't change it without first understanding why the limit is being reached. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
