Re: Animations with image size matching output resolution

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> 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?

Correct.  We aren't done yet though I think.  (See previous email.)  The complaints might go away.

> 
> 
> 
>>>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.

Ah yes.  But there is no file associate with X11, maybe that is where terminal transitions should be disallowed.  Hmm, but that would require knowing there is currently an open file (no problem) and the "change to" terminal also works with open files (not so easy).

> 
> 
>>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.

Yes, this is correct.  A real conundrum.  Let's check if there is an after-the-fact miscellaneous routine in the library that will allow this...  I don't see any.

OK, well I think there is a reasonable solution here.  How about another option for the animation terminal called "colormap global/local"?  The effect on the parameters should be obvious, but the behavior inside the gd.trm would be to disallow and complain if someone tries to change the colormap when in animate global colormap mode.  That works for me.

I fact, you could get by without having that option if we have a variable "cmsetting" and set it to 0 at the start of the animation.  Use that as the argument of gdImageGifAnimAdd and when a colormap call is done, switch that flag over to cmsetting = 1 so that from that point forward the local colormap is included.

Dan