Re: Animations with image size matching output resolution

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

Ethan A Merritt wrote:
> On Friday 30 December 2005 04:33 pm, Daniel J Sebald wrote:
> 
>>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 think you are not understanding my main point. It has nothing to
> do with make_palette.  The thing is, gnuplot now allows general color
> specs like  "lt rgb 'xffee43'".   That may or may not be a color in the
> current color map.  How would you know?  If it is already there, then
> requesting it will not change the colormap.  If that color isn't
> in the current colormap, then libgd will create a new entry for it.

You're saying that libgd will attempt to map the value to some other reasonble value?  And if it isn't that sophisticated it might just pick the closest value?  Sure.

> But neither gnuplot nor the end user knows that this has happened,
> and that the colormap has changed.  

A knowledgable end user will know that.  I don't think this is a new problem, the potential mismatch of palettes.  That's a garbage in, garbage out sort of thing.  Even if "local color map" is always forced, this could still happen I think.

> 
> Yes, you could program around this by testing for a color match first,
> and making a note that this is a new color and therefore the colormap
> must have changed.  But then what would you do about it?
> I just don't see that it would gain us anything.

What I'm thinking right now is something along the lines of what gifsicle does.  It must look at the palettes for successive images and determine it is the same as the global palette then toss it out.  So there's a way to avoid having ensure proper calls of _make_palette().  We can do the gifsicle approach easy enough.  (Although libgd has the palette stuff scattered about the image structure in a haphazard way for some reason.)

> 
> 
>>GIF file was missing some data (perhaps it was truncated somehow?)
> 
> 
> Nope.  Never seen that one.  And grepping the source files for
> gd 2.0.33 doesn't produce any hits.  Are you sure that is coming
> from libgd?

Well, it must be... oh wait.  You're right.  I probably launched the gthumb application from a terminal and when the file changes, gthumb reloads and complains.

Dan