Re: Animations with image size matching output resolution

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

Ethan A Merritt wrote:
> On Friday 30 December 2005 02:33 pm, you wrote:
> 
>>Ethan Merritt wrote:
>>
>>>>I've recompiled after setting the above parameter to zero.
>>>
>>>Don't do that. It won't work in general, because if any frame later
>>>introduces a new color then the colormap will not be correct.
>>
>>Let's try to fix this.  I think there is a sensible solution.  There are
>>parameters keeping track of frame count (so we know if we've included
>>the correct color map yet), etc.
> 
> 
> I may be mis-understanding the libgd requirements, but I think that
> in order to specify a shared colormap you have to do so at the start.
> I don't see any provision for coming back and changing it later.

As I understand the documentation, there can be a global color map that must be specified at the start, using the sample image I'm guessing.  Then for each individual plot there is the option to include a color map for that plot or use the global color map.  The global color map can't be changed.  However, we can continue to specify to use a local color map.

> But in the general case we cannot do this, because we fundamentally
> don't know if later frames will introduce new colors.  OK, maybe
> for your specific application you can guarantee that.  But I dislike
> coding for a special case.
> 
> If the smaller file size is important for your application, what's
> wrong with post-processing it in gifsicle or some other tool?

Nothing.

> Philisophical difference, I guess.  I look at it the same as I do 
> cropping.  If another tool can do the job well, then why bloat 
> gnuplot with less capable duplicate functionality?

Well, if it is simple to do and it saves the user a bit of work, that's good.  Plus there is a way the library is intended to be used.

Anyway, I've moved the AnimBegin() to right before the very first plot by testing if frame count is zero, i.e., the first AnimAdd(), and this fixes for the correct color map.  Although the compression is not as good as gifsicle then, it is close.

Now, I would think that we could start adding the local color map if the palette changes.  However, the problem is that the "make_palette" routine is called several times before each plot.

I'd argue we really shouldn't be calling that so often.  So that is out as a quick solution.  I'd think that the only time to call make palette is when it changes, or when doing a "set term".  Should I work on cleaning that up in the core?

Also, there is still a problem.  Maybe my gd library is out of date.  Ethan, are you seeing this error message from the library:

GIF file was missing some data (perhaps it was truncated somehow?)

Or might we still not be initializing the file properly?

Dan