trim +repage animated gif issue

[coloring]

hello

I'm having an issue trying to trim an animated gif to remove the "boring bits" as you say in your docs

when I do trim without any other option, the gif output still has the boring bits around
when I do with repage it does remove the boring bits however, the result can be a mess and completely misaligned

from what I understand the position of every frame is lost

so my question is : is there a way to automatically trim (without human eye) and preserve the position/alignment or the animated gif

[snibgo]

My "Fractal noise animations" page has a script, frTrim.bat, for this task. If all your frames can fit into memory at the same time, the script can be simplified.

[coloring]

interesting thank you, but .bat is windows script am I wrong?
I use imagemagick on linux unfortunately

could you please provide a linux script ? thank you

[snibgo]

What version IM are you using? If v7, and your GIFs are small, it can probably be done in a single convert. (Append frames vertically to get the horizontal trim, and horizontally to get the vertical trim.)

[coloring]

I use IM 6 from the jessie repository

unfortunately it would be risky to update manually to v7 as I would no longer be synched with the repository and security updates, not an option for production environments

do you mean IM v7 can do it and IM v6 can not?

[GeeMack]

do you mean IM v7 can do it and IM v6 can not?

This trimming can be done pretty easily using either IM6 or IM7. It's just that ImageMagick 7 can often reduce a process like this to a single command. Using IM 6.7.7 from a bash shell prompt I can do something like this to accomplish your task...

Code: Select all

inimage=YZu6yZx.gif

trimmer=`convert $inimage -coalesce -flatten -format %@ info:`

convert $inimage -coalesce -crop $trimmer +repage result.gif

That runs the "convert" command once to get the trim specs and put them in a variable. Then it runs another "convert" command using that variable to do the actual work. You could, of course, nest that first "convert" command with backticks inside the second where the "$trimmer" variable is. It still runs the "convert" command twice.

Using ImageMagick 7 you'd be able to obtain the trimming specs and trim the image all in one command, calculating the dimensions and offsets and applying those to the crop directly instead of putting those specs in a shell variable as an intermediate step. I don't have IM7 installed on a *nix machine, but using IM 7.0.4 from a Windows CMD prompt, a command like this would do it...

Code: Select all

set INIMAGE=YZu6yZx.gif

magick %INIMAGE% -coalesce ^
   ( -clone 0--1 -flatten -set option:trimmer %@ +delete ) -crop %[trimmer] +repage result_IM7.gif

Of course when processing a very small image like this, the difference in time or resource usage wouldn't likely be a concern.

[coloring]

@GeeMack

thank you very much

[coloring]

After using this fix, I noticed a weird issue where image that is supposed to be trimmed, ends being even larger than the original

here's an example
https://www.sendspace.com/file/dj05ql

the source is 304x411 and the result is 374x415

do you know what is causing this issue? thank you

[glennrp]

Your injput.gif contains offsets. "magick identify -verbose input.gif" says, for the first frame, "Page geometry: 374x416+70+4"

[coloring]

Thank you but I have no idea what is an offset and how I do fix this issue. Any idea?
Is there a way to make imagemagick ignore this offset?

[fmw42]

Add +repage right after reading the input image to remove the virtual canvas with its offsets.

[GeeMack]

Is there a way to make imagemagick ignore this offset?

As fmw42 mentioned, you may just need to reset the paging information with "+repage". You might have to put it after the "-coalesce" operation. That's where the GIF gets broken into separate frames while still keeping their relative +W+H locations in the viewport. If the "+repage" is before the "-coalesce", the frames may lose the paging information that keeps them +W+H aligned from one to the next.

[fmw42]

Sorry about that. Geemack is probably right.

[coloring]

I just tried replacing the second command like this

trimmer=`convert $inimage -coalesce -flatten -format %@ info:`
>
trimmer=`convert $inimage -coalesce +repage -flatten -format %@ info:`

but it makes no difference

if +repage is before -coalesce it returns the correct size, but you said I would loose the paging information

so what should I do

[snibgo]

The frames in your GIF are different sizes, because that is how GIF normally works. Eg frame [0] is 304x411 but frame [1] is 308x413. They all sit on a canvas that is 374x416. What is the problem? What do you want to change?