1

With gnuplot 5.4 (Win7), I tried to animate circles in 3D, basically the animated version of this.

The test data $Data contains random x,y,z coordinates, random sizes and random colors from 0x0000000 to 0xffffff. When the animated GIF is created, the circles are changing the color depending on the viewing angle.

As far as I know, GIF is limited to 256 colors, so it is clear that not all colors from 0x0000000 to 0xffffff can be displayed. I expected gnuplot to take somehow the nearest color and stick with it. However, I didn't expect at all that the color of the circles would change depending on the angle.

Why is this? How to work around this?

Code:

### animated plot with circles in 3D (only for gnuplot >=5.4)
reset session

set term gif size 400,400 animate delay 30 optimize
set output "WithCircles3D.gif"

# create some test data
set print $Data
    do for [i=1:100] {
        print sprintf("%g %g %g %g %g", rand(0), rand(0), rand(0), rand(0)*0.02+0.02, int(rand(0)*0xffffff))
    }
set print

set view equal xyz
set xyplane at 0
set border 4095
set xtics 0.2
set ytics 0.2
set ztics 0.2
set style fill solid 1.0

do for [a=5:360:10] {
    set view 60,a,1.25
    splot $Data u 1:2:3:4:5 w circles lc rgb var notitle
}
set output
### end of code

Result:

enter image description here

Result 2: (different random set when exporting single PNG frames with term pngcairo and put them together as animated GIF with some other software.)

enter image description here

theozh
  • 22,244
  • 5
  • 28
  • 72
  • For 100 circles, I think it won't exceed 256 colors. If you remove "optimize" from the "set terminal gif ...", you can reproduce Result 2. I suspect it's a bug related to the "optimize" option. – binzo Oct 28 '20 at 10:26
  • @binzo, argh, right that's it. Thanks! Each frame will be optimized on its own. So, an optimized 256 color palette for each frame. And then the 36 frames with the different colors will simply be put together. Do you want to put this as an answer, such that I can accept it? – theozh Oct 28 '20 at 10:38
  • Sorry. I believe that even if I used optimize as you did, Result 2 should be reproduced. Therefore, I do not have a correct answer to this question. – binzo Oct 28 '20 at 11:51
  • @binzo, ok, well... that's what gnuplot help says for `help gif` and 'optimize': A single color map is used for the entire animation. This requires that all colors used in any frame of the animation are already defined in the first frame. – theozh Oct 28 '20 at 13:19

1 Answers1

2

I think the work-around is to not use the "optimize" option. It relies on upstream support (in libgd) that has been unreliable if not outright broken for years now. Probably we should deprecate the gnuplot option or remove it altogether.

The example you show works correctly if you remove that keyword, right?

Ethan
  • 13,715
  • 2
  • 12
  • 21
  • Thank you for clarification. Yes, I get a correct looking result when I remove the option `optimize`. However, then I also don't get the second intention of `optimize`: possible reduction of file size. Well, then I have to use a separate GIF optimizer. – theozh Oct 29 '20 at 04:42