Not considerably smaller than out-coalesce.gif, but I think this is just because the black ground compresses really well, and it could be very significant in general. Out-deconstruct.gif: compressed frames, final output size 1.9 MiB. Output looks visually correct, but the output file size is 2.0 MiB, which is larger than out-deconstruct.gif Out-coalesce.gif: all frames are 256x256 and have the correct offset 0+0. Visually incorrect, since those approximately 256x256 frames have a non-zero offset, e.g. Out.gif: All frames are 256x256 or larger, and huge at about 5MiB, TODO why? Then, if we compare the three conversions: $ identify out-deconstruct.gif | head -n 3 $ convert out-convert.gif -coalesce -resize 256x -deconstruct out-deconstruct.gif $ convert out-convert.gif -coalesce -resize 256x out-coalesce.gif $ convert out-convert.gif -resize 256x out.gif Using the test data from this answer: How do I create an animated gif from still images (preferably with the command line)? we can see this clearly with identify: $ identify out-convert.gif | head -n 3 coalesce then expands all the frames to the original size, which makes the resize work, but it does not re-compress the frames again as your input image: -deconstruct is needed for that! The root cause of the problem is that your input GIF was properly minimized: GIF allows the next frame to be just the modified rectangle from the previous one at an offset.
After -coalesce, you likely want to add a -deconstruct: convert in.gif -coalesce -resize 256x -deconstruct out-deconstruct.gif
0 kommentar(er)
