Legacy ImageMagick Discussions Archive

Hello,

If I try to trim an already coalesced animated GIF image, the trim-tool
only checks the first frame. The resulting animated gif is croped and
has strange artefacts.

Testcase:

wget http://doppelbauer.name/test.gif
convert test.gif -trim +repage result.gif
firefox result.gif

Version: ImageMagick 6.6.4-0

Thanks a lot
Marcus

-trim would have trimmed ALL the images. But the +repage would have junked all the offsets that is so important to a GIF animation!

What you need to do is find the overall bounds of the whole animation, and crop to that.
this is somethign which is not really easy to do, so I created a specific Layers method to do exact that. -layer TrimBounds (this is NOT just for animations either!)

See IM Examples, Animation Modifications, Bound Trimming
http://www.imagemagick.org/Usage/anim_mods/#trim

Note this assumes your animation has not been optimized. This is one situation that a optimized animation is needed to get the desired results.

Hi Anthony,

Thanks for pointing out. Maybe there is a bug, concerning "optimize"?

Testcase (47x29 pixels, coalesced):

wget http://doppelbauer.name/test.gif
convert -verbose test.gif -layers optimize optimized.gif
identify optimized.gif

The problem, optimized.gif[2] is a full image (47x29 pixels), but only the left 31
pixels contain a non-transparent color. Therefore TrimBounds won't work.
Thanks
Marcus

That is very strange! Not the fact that it is a large frame. That is understandable as it is a 'background' dispose frame. Normal identify does not show the disposal setting...
Use this to show animation relevant attributes... I would have expected something like a 31x29 image for the 3rd (index 2) frame.

Hmmm removing all optimizations from the animation (using -coalesce) shows that some pixels between index 2 and 3 were made transparent. That is because -coalesce set a disposal of background for frame index 2. Cooalesce always uses a none disposal, unless some pixel became transparent in which can it sets background dispose, so the coalesced animation will still continue to work correctly.

Looking at the animation on a checkered background shows a lot of white edge 'anti-aliasing pixels' . That seems to indicate that the animation was originally created on a pure white background. It is a change in these white pixels (a few vanished in frame index 3) that caused the need to use a background dispose at that point. This was confirmed using -layers compare_clear.

Of course later frames also needs to convert some pixels back to transparency later, but than those frame are optimizing correctly. Or at least does not seem to be over doing it.

It however does not explain why the image size of index 2 is overly large! At most it should only be large enough to contain transparent pixels that changed from index 1 to 2 and the small number of pixels that were cleared from index 2 to 3. Or at maximum all the pixels that was added in this and all previous frames. It definatally should not be the whole virtual canvas!

As such this does appear to be a bug, and I will investigate further using this animation.
Thank you for bringing this to my attention. Good spotting.

PS: Adding a -fuzz 10% should make the image optimize even better but more frames appear to suddenly become 'full virtual canvas'. It is also definitely coming from the optimize_frame sub-component of optimize.

Now to find out its cause! Code diving is the next step.

Hi Anthony,

Thank you very much for your answer.
Difficult to fix?

Thanks a lot
Marcus

I too a look but it appears the bug is in a deeper subroutine that is going to take a lot of time and effort to determine.

Basically it is a compare function that is saying everything is different when it is not.
I have put in a bug report, but I haven't had a block of time to spend on this problem.

Hi Anthony,

Thank you very much for your answer.
Could you provide me the link to the bug report?

Thanks a lot
Marcus

Sorry it was a private mail.