Re: Animations with image size matching output resolution

[Ethan M. <merritt@u.washington.edu>]

On Friday 30 December 2005 01:54 pm, Daniel J Sebald wrote:
>
> [sebald@local gif]$ gifsicle -l=1 test.gif > test10.gif
> gifsicle: Error while reading 'test.gif' frame #20:
> gifsicle:   trailing garbage after GIF ignored
>
> and I've noticed that the file is about 33 bytes longer now that the
> gdImageGifAnimEnd is called.  The size is still large compared to
> what gifsicle creates.

We may not be able to make all customers happy. Apparently 
some of them want the extra stuff at the end of the file (gthumb),
some of them don't like it (gifsicle), 
and some of them don't care (ImageMagick).

I take it that gifsicle works anyhow, it just spits out a warning?


> > It's tricky, because the terminal type itself may have changed by
> > the time the output file is closed.
>
> I thought that was disallowed; a philosophical no-no. 

On the contrary.  That is what allows you to switch to an interactive
terminal like x11 and then go back to what you were doing before.

> What you've 
> done with term->layer hasn't circumvented the problem, I think.

I know.  That's why I pointed it out.

> It's a matter of choice.  I too thought of adding a variable to some
> function call. To me, TERM_graphics() seemed the logical choice.  

That doesn't work.  term->graphics is called for every frame.
It has no way of knowing whether this is the last frame or not.
In fact the caller may not know either.

> But then I thought, oh my, all those terminals using _graphics()
> would need a conditional statement to check if it were at the start
> of the file or end of the file.  You chose a routine having very
> little use, so that made things a little easier.

The main point is that I chose a routine that (a) takes a parameter,
and (b) always checks that the value of the parameter is one that
it can handle.

> I keep snooping around with the file size issue, then put together a
> FAQ.

I'm going to guess that the effect you are seeing is due to gifsicle
creating a shared color map for the entire file, rather than storing
a separate color map for each frame.   That same comment you
pointed to before explains why this isn't possible at the time the
file is created (we don't know what colors future frames will use).
Of course after the animation is complete, a program like gifsicle
can go through and inspect each frame for what colors it needs
and collect them all into a single, shared color map.

If I'm right, the size difference will scale with the number of 
frames, not the size of the images.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA