Last modified: 2013-07-25 18:48:45 UTC
Possibly all files affected by the commit in bug 47363 return errors for large thumbnails. (Bug 47363 changed $wgMaxImageArea and $wgMaxAnimatedGifArea to 50 MP)
works for me,
and above does not anymore.
(Could not find an appropriate tiff file by now)
possibly running into the actual resource limits. (if the program that scales images uses too much memory or cpu time, etc it gets killed).
I wonder if there's any way to reduce the used memory/cpu here, as the provided example that fails rendering isn't "too" big. Hence existing folks to run into this more often (visible), but don't know how many of our images are lossless.
(In reply to comment #2)
> I wonder if there's any way to reduce the used memory/cpu here, as the
> example that fails rendering isn't "too" big. Hence existing folks to run
> this more often (visible), but don't know how many of our images are
Note the lossless/lossy thing isnt really the main reason, it more has to do with how image magick doesnt decompress the whole image all at once for nonprogressive jpeg, but does for other formats.
Its been a long term issue that large progressive jpegs don't thumbnail either.
The fix for this bug is bug 28135. Perhaps this should be duped to one of the vips related bugs (unlesd there is some in between step we could take im not aware of)
(In reply to comment #0)
> Not OK
> (Could not find an appropriate tiff file by now)
Those two files (the pngs) look good to me now, after we've deployed VipsScaler on all wikis.
The large gif one (https://upload.wikimedia.org/wikipedia/commons/thumb/b/bf/Mejeri1.gif/577px-Mejeri1.gif) still fails, though.
In fact, I'll just mark this bug fixed and open a new one for using VipsScaler for gifs also (right now VipsScaler is only used on large pngs).