GIF preview corruption

GIF preview corruption
by on (#179963)
In this thread corruption of preview GIFs was discussed: https://forums.nesdev.com/viewtopic.php?p=179813#p179813

Details in that thread, but the problem seems to be that traditionally "optimized" GIFs (with each frame cropped to just the area that is different from the frame before) get severely corrupted by the resizing process.

Koitsu suggested that phpBB uses ImageMagick to do the resizing? If so, it seems that it has a "coalesce" option that needs to be applied before resizing, and probably an optimization flag as well to undo the file size explosion that coalesce will cause?

Might also be worth pointing out that the corrupted "preview" GIF in this example is actually 50% larger than the original one, which defeats part of the purpose of doing previews in the first place. I expect that more properly processing them might help with this.
Re: GIF preview corruption
by on (#179975)
FWIW, I use gifsicle for all my gif needs. Its abilities go far above imagemagick's.
Re: GIF preview corruption
by on (#180006)
calima wrote:
FWIW, I use gifsicle for all my gif needs. Its abilities go far above imagemagick's.

Does phpBB have native support for this? If not, then (respectfully of course), it's an irrelevant point. PHP doesn't necessarily just call a shell utility to do its conversion (I'd be very surprised, and scared, if it did), it almost certainly uses the ImageMagick module, which relies on the actual C-based ImageMagick libraries.
Re: GIF preview corruption
by on (#180011)
MediaWiki uses the shell for thumbnails. Is that likewise scary?
Re: GIF preview corruption
by on (#180022)
tepples wrote:
MediaWiki uses the shell for thumbnails. Is that likewise scary?

Very, especially when you consider that an attack against whatever in mediawiki does thumbnail generation could effectively induce an out-of-process (e.g. fork bomb) scenario on a webserver. fork/exec are very expensive.