ImageMagick tries to handle all frames of an animated GIF

[RandomTroll]

I tried to append a caption to a cartoon by converting the caption text to a gif, resizing it to the same width as the cartoon, then using convert -append. If I do this to an animated gif, convert works for minutes (until I stop it), creating temporary files (23 when I quit). If I try to open the same file with display it works for minutes, creates dozens of temporary files. It used so much CPU the CapsLock key wouldn't change its LED. I eventually hit the power switch.

I think IM should detect animated-ness and deal with it more gracefully.

[fmw42]

Do you want every frame to have the caption or only the first?

See http://www.imagemagick.org/Usage/anim_mods/#label. See also -layers composite at http://www.imagemagick.org/Usage/anim_mods/#composite.

Please always provide your IM version and platform/OS when asking questions.

Can you post your animation and caption text image to some free hosting service and put the URL here so we can test?

How many frames in your animation?

[snibgo]

I tried to append a caption to a cartoon by converting the caption text to a gif, resizing it to the same width as the cartoon, then using convert -append.

In addition to what Fred says, please show your exact command(s). Perhaps you were accidentally appending the frames together.

[RandomTroll]

I use Linux, Slackware, package imagemagick-6.9.9_20-i586-1

Version: ImageMagick 6.9.9-20 Q16 i586 2017-10-25 http://www.imagemagick.org
Copyright: © 1999-2017 ImageMagick Studio LLC
License: http://www.imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules OpenCL
Delegates (built-in): bzlib cairo djvu fftw fontconfig freetype jng jp2 jpeg lcms ltdl lzma openexr pangocairo png raw rsvg tiff webp wmf x xml zlib

You misunderstand my report. I wasn't looking for a solution; I
figured that out: extract a single frame, append the caption to that.
I work in non-X almost all of the time; fbi, the program I use to view
images, displays the first frame of an animated GIF; I don't usually
view animated GIFs.

I think imagemagick should not attempt to caption an infinite number
of frames of a infinitely-looping animated GIF. Just try 'display' on
one: it runs forever, monopolizing disk access, creating unlimited
temporary files.

I did not create the GIF. I wrote a script that fetches the 'New
Yorker's daily cartoon, extracts the caption (which is separate) from
the cartoon's host page, converts the caption to a GIF with text2gif,
resizes it to the same width as the cartoon, appends it. It works
correctly for JPEGs and still GIFs. I didn't even know that some of
them were animated until I had this problem.

December 27's cartoon will do:

https://media.newyorker.com/cartoons/5a ... 122717.gif

The caption is 'Snapchat's newest filter.'

The command is

convert -append DC122717.gif Caption.gif CaptionedCartoon.gif

[fmw42]

Imagemagick does not try to guess what the user wants.

You can handle your issue by using the following command. Note the correct IM syntax is to read the input before the append, though IM 6 is rather forgiving (but IM 7 is not). This will handles all image types including animated gifs (assuming DC122717.gif is not animated). This is unix syntax. If on windows remove the \s from the parens so only ( ... ). Be sure there are spaces between the parens the enclosed command.

Code: Select all

convert image.gif \( -clone 0 DC122717.gif -append \) -swap 0--1 +delete captioned_image.gif

[snibgo]

I think imagemagick should not attempt to caption an infinite number of frames of a infinitely-looping animated GIF.

It doesn't (or shouldn't) attempt to process an infinite number of frames. It processes each frame once. IM processes all images that you give it, whether one image or a thousand. If you don't want them all processed, you should remove them from the list, eg with "-delete 1--1", which removes the second image to the last image.

convert -append DC122717.gif Caption.gif CaptionedCartoon.gif

That command appends all the frames together, with the caption at the bottom. I can see that this is what you want for single-frame cartoons, but might not be wanted for multi-frames cartoons.

It takes 8 seconds on my laptop, making an image of 1088x81615 pixels.

[RandomTroll]

You-all miss the point: I don't know the properties of the image first. I fetch the 'New Yorker's daily cartoons with a crontab job. For a long time the 'New Yorker's daily cartoons were stills, the processing took less than a second. On the 27th something was monopolizing disk access, slowing down everything else that used the disk. I inspected the process list, saw that convert was trying to caption that day's 'New Yorker' cartoon. I let it go for a few more minutes; it didn't finish. I killed the process then investigated the cause. I found 23 8MB imagemagick temporary files in /tmp

Running 'display DC122717.gif' (forget appending a caption) did the same, but used even more CPU time: my computer was unusable: I powered it down. I had more than 100 temporary files in /tmp.

My laptop is 7 years old, has only 2 cores, runs at only 2.1 GHz, has only 3 GB RAM. Mr/Ms snibgo seems to have a more powerful computer. If his/her resultant file is 81615 pixels, that's 68 frames (its height is 1200) - fewer than the number of temporary files imagemagick created when I tried to display that cartoon. Perhaps imagemagick can't finish on my under-powered computer and unhalts.

I had already dealt with this problem *before* I posted this message: now I extract the first frame from any GIF, append the caption to that.

How do I find out how many frames a GIF has?

[GeeMack]

How do I find out how many frames a GIF has?

Try this..

Code: Select all

convert input.gif -set option:frames "%[n]" -delete 1--1 -format "%[frames]" info:

[snibgo]

now I extract the first frame from any GIF, append the caption to that.

Yes, "abc.gif[0]" will read just the first frame. This also works when there is only one frame, so it is safe.

My four-year-old laptop is quite powerful (12 GB memory), but I can still hit problems when I ask IM to do something heavy. This is what policy.xml is for: it limits the resources IM can use, so it doesn't gobble up all the memory or CPU cores or wall time.

[fmw42]

My command above does not care how many frames there are or if there is only a single image. Give it a try.

[RandomTroll]

date;convert DC122717.gif[255] 255.gif ;date

returns:
Fri Dec 29 10:40:43 MST 2017
convert: subimage specification returns no images `DC122717.gif' @ error/constitute.c/ReadImage/581.
Fri Dec 29 10:56:47 MST 2017

16 minutes to figure out the frame requested isn't.

date;convert DC122717.gif -set option:frames "%[n]" -delete 1--1 -format "%[frames]" info:;date

returns:
Fri Dec 29 11:04:53 MST 2017
149
Fri Dec 29 11:20:24 MST 2017

It took 15:31 just to get the number of frames: there must be an easier way.

[snibgo]

Something is badly wrong on your computer. Your commands, on that file, on my computer take 1.7s and 1.14s. Less than 2 seconds each, compared to your 15 minutes each.

[RandomTroll]

Hmm... you may be right. I have 2 other GIFs from the 'New Yorker'; the 16-frame GIF takes 1 second to count the frames; the 30-frame GIF takes 3 (resolving to the second). That a 149-frame GIF takes 931 is disproportionate.

IM creates multiple 8 MB temporary files; I have about 2.5 GB RAM free: it shouldn't have to. policy.xml lets it use 2. If IM makes an 8MB temp file per frame, that would account for all the disk access - and I don't think anybody could do it all in 1 second. Is there some reason IM caches to disk instead of RAM?

[snibgo]

Your frames are about 1000x1000 pixels, so at 8 bytes/pixel, they need 8 MB each. IM stores pixel caches in main memory unless policy.xml prevents this, or the O/S prevents it. Some installations have per-process limits on memory use.

Obviously, make sure you are not running anything else at the same time, eg browsers.

[snibgo]

Incidentally, you might try:

Code: Select all

convert DC122717.gif[1x1+0+0] -set option:frames "%[n]" -delete 1--1 -format "%[frames]" info:

The "[1x1+0+0]" after the filename gets just one pixel from each image. I'm not sure if it first reads all the images then discards most pixels (in which case it won't help), or if it reads one image, discards pixels, and repeats.