Last modified: 2014-10-29 23:05:46 UTC
Commons user Pasimi reports (via OTRS#2014022010012268) that some of their animated GIFs failed to get thumbnails. See https://commons.wikimedia.org/w/index.php?title=Special%3AListFiles&limit=500&user=Pasimi&ilshowall=1 - specifically https://upload.wikimedia.org/wikipedia/commons/thumb/1/1d/Excavator_mechanism.gif/649px-Excavator_mechanism.gif https://upload.wikimedia.org/wikipedia/commons/thumb/archive/2/25/20140220212149%21Rope_shovel.gif/180px-Rope_shovel.gif https://upload.wikimedia.org/wikipedia/commons/thumb/1/1d/Excavator_mechanism.gif/180px-Excavator_mechanism.gif Also, some of the thumbnails shown on that page are not animated, but the full images (SCARA right.gif and SCARA left.gif) are.
137 = OOM In theory we are supposed to render only the first frame if image big enough to cause this. Maybe settings need to be tweaked.
The joke is that a error message ("Note: Due to technical limitations, thumbnails of high resolution GIF images such as this one will not be animated." - maybe from Bug 23063) and a static thumb only appears if the GIF is over 50MP! But the limit is really 12,5MP! (It was a short time 50MP at 2013 https://commons.wikimedia.org/w/index.php?title=Special:Contributions&offset=201305261339&limit=500&tagfilter=&contribs=user&target=Slick)
Sorry my correction, the limitation is not somehow 12.5MP it is above ~23 MP (and seems for sure as of 26 MP, dependence by the frame size I've not tested). I've tested some in [[Category:Animated GIF files affected by MediaWiki restrictions]].
(In reply to PRO from comment #3) > Sorry my correction, the limitation is not somehow 12.5MP it is above ~23 MP > (and seems for sure as of 26 MP, dependence by the frame size I've not > tested). I've tested some in [[Category:Animated GIF files affected by > MediaWiki restrictions]]. Note, the megapixel limit and the memory limit are separate limits. The amount of memory a file takes does not precisely correspond to a specific number of megapixels.
This may be a separate issue, but that error message is particularly unhelpful. When you hit the MP limit, at least you get a message for that, in theory.
(In reply to Dominic from comment #5) > This may be a separate issue, but that error message is particularly > unhelpful. When you hit the MP limit, at least you get a message for that, > in theory. Would actually writing out "out of memory" actually be anymore helpful? I cant imagine that that means much to average user. (For reference 137 comes from 9 + 128, which is bash's way of saying process recieved SIGKILL (signal number 9), which gets caused by exceeding the linux cgroup memory limit)
It may not help the average user experience (though if they are hitting this error, I am nit sure they can be helped), but I was just thinking how frustrated I get at vague error messages, which I can't look up to see what the cause is or if it is a known issue.
(In reply to Dominic from comment #7) > Would actually writing out "out of memory" actually be anymore helpful? I > cant imagine that that means much to average user. Maybe not the average user but the uploader may think his GIF file is broken in some way other than being too large. The error message for TIF seems to be more helpful. C.f: https://upload.wikimedia.org/wikipedia/commons/thumb/2/2f/19-N-9283-1720-42-K-Launching_BB-62_waterborne.tiff/lossy-page1-599px-19-N-9283-1720-42-K-Launching_BB-62_waterborne.tiff.jpg
Different error: oom can be triggered by different but related conditions. Tiff files can also be oom
Hmm, I was recently testing image magick, and it seems to have better memory performance then older versions, with me being able to scale a bunch of images locally that don't work on cluster.
Created attachment 15694 [details] mem limit values I tested image magick with So in my tests, newer versions of image magick seem to sometimes be able to recover from ulimit -v, and use less memory if they run out (at least that's what I think is happening). That doesn't seem to happen with cgroups. There are various environmental variables you can set to tell image magick its memory limits. When I tried setting them on newer image magick (6.8.9-3), it caused the animated gif I was testing to be rendered without exceeding memory limit (where previously cgroups killed it for OOM) [See attached patch for values I was testing with]. However, testing on 6.6.0-4, this didn't seem to have a lot of affect. WMF is currently using "ImageMagick 6.6.9-7 2014-03-06 Q16", so I'm unsure what affect it would have there (Although rumour has it they are updating some applications in the next 2 months). The values I was testing with were mostly pulled out of my hat/trial and error, so also unclear if they are good values. Anyways, more research needs to be done to see if this is practical/a good idea [which is why I added my patch here, not in gerrit]. The gif file I was testing with is https://upload.wikimedia.org/wikipedia/commons/archive/6/64/20140614071837%21BULGARI_-_a_gentleman%27s_Carbongold_Hong_Kong_chronograph_wrist_watch._Fellows-1438-2-A.gif . I was using cgroups with $wgMaxShellMemory set to 400*1024*1024 see also: http://www.imagemagick.org/script/command-line-options.php#limit
*** Bug 70296 has been marked as a duplicate of this bug. ***
*** Bug 47409 has been marked as a duplicate of this bug. ***
New example of problematic image (although the image is really not so big!): https://commons.wikimedia.org/wiki/File:DNA_orbit_animated.gif Try to get for example: http://upload.wikimedia.org/wikipedia/commons/thumb/1/16/DNA_orbit_animated.gif/185px-DNA_orbit_animated.gif
