[solved] Convert does not create a correct MNG file

[broucaries]

Hi,

I seems that display does not play this mng <http://fly.isti.cnr.it/tmp/octave_movie.mng> wheras showimg does.
What could we do in order to help (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499019)

Regards

Bastien

[magick]

The maintainer of the PNG library says:

The ticks_per_second field of the MHDR chunk is 0 which means there is only one frame. Decoders are expected to composite all of the layers on top of each other and show the final result.

Surely that is not what the author intended, but that is the author's problem.

[broucaries]

Thank you closed the debian bug report.

[broucaries]

Corrected the subject.

The video was created by imagemagick using:
convert *.png -adjoin bug_movie.mng

the orignal png file were from http://fly.isti.cnr.it/tmp/bugmovie.tar

Regards

[magick]

The solution is to set a proper delay in the MNG image:

• convert *.png -adjoin -delay 1 bug_movie.mng

A delay of 0 is a legitimate value, meaning the file contains a single composite image.

[broucaries]

Thank you.

Could be documented somewhere. It is a user trap at least.

Regards

[magick]

We will associate a note with the MNG description found here: http://www.imagemagick.org/script/formats.php.

[broucaries]

Thank you.

Bastien

[naoliv]

Hi!

While it's good that you have included an information saying "An interframe delay of 0 generates one frame with each additional layer composited on top. For motion, be sure to specify a non-zero delay." (at http://www.imagemagick.org/script/formats.php), Francesco (who have reported the Debian bug) said:

Thank you for examining this problem. However, I think this explanation is not satisfactory. Even if delay 0 is legitimate, in my opinion it makes little sense to have it as the default. No one expects to create a movie where all the frames are shown at the same time, so that you only see the last one.

I think that either an explicit delay should be required (that is, give an error if no delay is specified) or some default delay should be chosen which is different from 0.

Do you agree that a better default is a value higher than 0? (I somehow agree with him)

Thank you!

[magick]

A non-zero default may make sense for MNG but perhaps not for GIF, MIFF, AVI, or MPEG. That's the thing about defaults, they only work for a subset of the problem space. That is exactly why we have command line options to customize an operation for a particular problem. And if we did change the delay to something other than zero, what delay makes sense? 1 millisecond, 2, 3, whatever? We'll check with Anthony who is the proper person to decide if the default delay should be set to a non-zero value.

[anthony]

If I was going to set a default for -delay I'd probably make it either 1/2 a sec (a value of 50 centi-seconds) or a full second (100 cs). HOWEVER that is NOT a good idea in any case.

If -delay has been set to some 'default' then it will override the normal input values of existing animations such as GIF. And that is VERY bad.

I would leave it alone, unless a separate 'delay is defined' type setting can also be added.

It is a situation we have seen before where a setting needs a defined and undefined state so that when the user 'defines' the setting it will
override any and all existing settings in images that are later read in.

This is not a problem with the "-set delay" operation, though that is a global (all images) change rather than just the next image read in.


So in summery: Leave it alone, and define it if needed.


ASIDE: many browsers add a slight non-zero delay to all animations to prevent the animations running away. This delay however is BAD for zero-delay frame optimizations where you really don't wnat the browser to even display a frame with zero time delay. This however is a fault with browsers, not with IM. I would be sending bug reports to browsers for even allowing the use of animations containing only 'zero delay' times, instead if some time of 'broken animation' symbol.