Legacy ImageMagick Discussions Archive

Apologies for cross posting this here as well as Users, but I think this might be a better location.

My web hosting company updated to 6.6.3 recently (from 6.3.9), and suddenly, some of my IM code started generating bad GIFs.

Basically, I create several frames, which delay 5 seconds, the morph to the next frame in about .3 seconds overall. A example of the problem I'm seeing is:

convert -size 160x46 xc:'rgb(0, 0, 0, 1.0)' -size 160x46 xc:'rgb(0, 255, 0, 1.0)' -delay 500 \( -clone 0 -clone 1 -morph 3 -set delay 10 \) -delete 0-1 -layers Optimize tp.gif

If I understand -set delay properly, it should modify the animation delay for all the images in the current stack. And it used to with 6.3.9. But, now it doesn't. See the results of the above command, below.



Each frame takes 5 seconds instead of .1 seconds.

The only thing in the release notes I found that might have some bearing is:

2008-05-15 6.4.1-4 Cristy <quetzlzacatenango@image...>
Interpreting the -set option is no longer delayed.

I'm sorry if this, in fact, isn't a bug, but if you could explain the change, I would appreciate it.

Thanks,

Marc

Here is a better example as it shows more what I was trying to do. I've also found a workaround, but I still think there's a bug here. Please correct me if I'm wrong.

convert -size 160x46 xc:'rgb(0, 0, 0, 1.0)' -size 160x46 xc:'rgb(0, 255, 0, 1.0)' -delay 500 \( -clone 0 \) \( -clone 0 -clone 1 -morph 3 -delete 0,4 -set delay 10 \) \( -clone 1 \) \( -clone 1 -clone 0 -morph 3 -delete 0,4 -set delay 10 \) -delete 0-1 -layers Optimize tp3.gif

The code is designed to generate an animated gif that:

1) Shows a black frame for five seconds.
2) Morphs to a green frame using three morphing frames at .1 second each
3) Shows the green frame for 5 seconds.
4) Morphs back to a black frame using three morphing frames at .1 second each.

Now, maybe you've got a better way to do this? I'll take it, if you do.

In the earlier version, I believe the -set delay in the parens reset the delay to 100ms instead of 5 seconds, generating the desired effect. But, in 6.6.3, I'm guessing that when the stack is elevated to the primary stack, since the images are essentially 'added' that they are all reset to 5 seconds. If I remove the "-delay 500" then the morphed frames all have 100ms delays, and the outer black and green frame have no delay.

The above code worked in 6.3.9.

My workaround is:

convert -size 160x46 xc:'rgb(0, 0, 0, 1.0)' -size 160x46 xc:'rgb(0, 255, 0, 1.0)' -set delay 500 \( -clone 0 \) \( -clone 0 -clone 1 -morph 3 -delete 0,4 -set delay 10 \) \( -clone 1 \) \( -clone 1 -clone 0 -morph 3 -delete 0,4 -set delay 10 \) -delete 0-1 -layers Optimize tp5.gif

And this works as I'd expect.

Again, please let me know if I simply misunderstand or if there is a problem.

Thanks,

Marc

Your method is as good as any other. But in principle, in your first method, -delay is supposed to come before the images. But I cannot get it to work your first way, either (even with -respect-parenthesis). So perhaps there is a bug, but I cannot say for sure.

But this also works.

convert -respect-parenthesis -size 160x46 xc:'rgb(0, 0, 0, 1.0)' -size 160x46 xc:'rgb(0, 255, 0, 1.0)' \
\( -delay 500 -clone 0 \) \
\( -clone 0 -clone 1 -morph 3 -delete 0,4 -set delay 10 \) \
\( -delay 500 -clone 1 \) \
\( -clone 1 -clone 0 -morph 3 -delete 0,4 -set delay 10 \) \
-delete 0-1 -layers Optimize tp3.gif

Good... I don't think I knew about -respect-parentheses. I'll remember that. If it was added post 6.3.9, that would be why.

As for -delay coming first, that may be. I didn't put it there originally because those images actually get deleted at the end. The -delay should apply to all the standalone -clones I do.

As for whether it's a bug or not, I hope one of the devs posts and lets me know.

Thanks for your help.

Marc

-delay is a input setting. It should be just stored for use with NEW or read in images overriding any existing delays in those images, as they are created or read in.

-set delay is a immediate operation. It should be applied to the current images in memory and then forgotten. It should not be stored any where but as the delay for images in memory.

The only non-create/read operation that MIGHT make use of -delay (in the future) is -morph where it is proposed that the new images inserted between the input images are given a different delay as per the -delay setting. This is currently not the case, making the adjustment of intermedate frame delays awkward.


It looks like the -delay 500 in that first example is hitting a bug, as no new images are created or read after that setting was set. -clone should not change the delay in the clones image.

NOTE -respect-parenthesis is only supposed to reset 'settings' when the parenthesis ends. setting made before a parenthesis starts are ment to be passed into the parenthesis. See the examples on using -respect-parenthesis in IM Examples, Basics
http://www.imagemagick.org/Usage/basics ... arenthesis

May be it changed with the introduction of -respect-parenthesis. marclallen said it changed between 6.3.9 and 6.6.3 and Anthony mentions

"As of IM v6.4.1-4 the new operational control option "-respect-parenthesis" can override this behaviour." at http://www.imagemagick.org/Usage/basics ... arenthesis

Perhaps it is now a case of precedence between -delay and -set delay. Since (in the method that now does not work) -delay is outside the parens, so it may now override the parens results from the values set inside the parens by -set delay?

Anthony sent me this PM clarification:

Anthony wrote:There should not be any precidence. -delay should only store a value for read/create operators. -set delay should apply it to images, and then forget.

The fact that -delay is effecting things beyond read/create is a BUG. It is just a matter of determine what causes that bug to be acted on.

anthony wrote:It looks like the -delay 500 in that first example is hitting a bug, as no new images are created or read after that setting was set. -clone should not change the delay in the clones image.

So...

convert -delay 500 a.png b.png -delay 1000 \( clone 0-1 \) ...

Should have a different result than:

convert -delay 500 a.png b.png -delay 1000 a.png b.png ...

Is that what you're saying?

I would have expected -clone to create a new image that was simply a copy of the old image, but the the new settings applied. However, I can see where you might want -clone to be an exact duplicate regardless of settings changed.

Marc

-clone does not create a new image. It duplicates all the meta data and then links the image data so it is shared between the two images (as a memory saving method. If some operation modifies the image data THEN a copy will be made.

BUG found.... 500

is correct but
1

is simply WRONG! the result should still be 500!

A temporary fix is to use respect parenthesis... 500
500

this show that clone CORRECTLY does not use the delay setting.

What is worse is that -set delay is not doing the right thing either! 500 500
500

Basically BOTH -delay and -set delay is BROKEN!


'mpr' does not use the -delay setting either, but this it is only cloning from a stored one. I would probably not want it changing things. 500
500


Things are definitely broken. I am reporting this page to Cristy!

Anthony,

Thanks for the clarification on -clone.

So, if only the meta data is changed on a -clone, is the entire image copied or just the meta data?

For instance:

convert -delay 500 rose: \( -clone 0 -set delay 100 \)

Do I have two images/meta data? Or do I have two meta data sets, each tied to the same image information? Or is a frame delay not considered meta data?

So, the following should have different results, right?

convert -delay 500 a.png b.png -delay 1000 \( clone 0-1 \) ...
convert -delay 500 a.png b.png -delay 1000 a.png b.png ...

because the second example loads two new images (earning the new -delay value), while the first clones them (thus NOT earning the new -delay value). Have I got that right?

I also think that -set delay is not actually broken, but is somehow being overridden or affected by -delay. I can't be sure, of course, but here's what I saw in practice:

convert -delay 500 rose: \( -clone 0 -set delay 100 \)

500, 500

But,

convert rose: \( -clone 0 -set delay 100 \)

(no delay), 100.

So, it looks like -set delay does it's job, but when -delay is set, it either doesn't override it, or the -delay setting blocks or overwrites it again.

Marc

If you really want an answer. Perhaps you should try posting a new topic in the bugs forum with as simple an example as you can possibly construct and point back to this topic. Mention that Anthony thought it was a bug and ask for verification. Hopefully then no one will reply to the post. That might then get the attention of the IM developer who would know.

We can reproduce the problem you posted and have a patch in ImageMagick 6.6.3-1 Beta available by sometime tomorrow.