From: Daniel J S. <dan...@ie...> - 2005-12-29 09:45:44
|
Ethan, Petr, I see your names associated with the newly added animate feature of GIF images. How can I make the following happen? I'll program gnuplot to behave this way if it seems appropriate. (But I need to act fast on a decision.) What I'd like is to create an animation consisting of a series of images, fairly low resolution, say 20 x 20. Now I've seen a description of how to do this on the Gnuplot web page, i.e., a series of GIF images. I'd be fine, really, with anything that can be imported into an existing "player" so I can play at a rate that would be real-time speed. And it would be great if I could generate output images, i.e., GIFs, that are 20 x 20, without any kind of annotation or axis graphics, of course. That way, it would be a very efficient storage of processed information. Then I could put a "player" in full screen mode. (Any suggestions for a GIF animation viewer? The ones I've tried so far aren't working with the gnuplot output, gthumb, Eye of Gnome... gifsicle prints out info about the animated GIF file that makes sense, but I get GIF file was missing some data (perhaps it was truncated somehow?) from gthumb.) So, I have the latest GD library, 2.0.33 and "animate" is activated. I was hoping the following Octave commands would generate an example of what I want, but it does not work: graw('unset border\n'); graw('unset tics\n'); graw('unset colorbox\n'); graw('set term gif animate delay 10 nooptimize size 20,20 crop\n'); graw('set output "test.gif"\n'); for i=1:20 X = floor(rand(20)*64); image(X); end graw('set output\n'); As you can imagine, all I get are the lower left pixels which happen to be all white. Basically, cropping is not done as desired, in my opinion. I know we've talked about this before (regarding PostScript), but as I see it "crop" should mean tight up against the last "non-white" or "opaque" graphic element. I know this is a bit tricky to define because of line thicknesses and what not. But in the case of images only, I think the scenario I've described isn't too uncommon for many users who process images and such. Where would the cropping be done? Inside the terminal driver, or should there be generic routines for cropping? Maybe gnuplot isn't the thing to use for such a feature. Perhaps there is a simpler approach in Octave and some output library. (Petr, can you think of any?) Thanks, Dan |
From: Daniel J S. <dan...@ie...> - 2005-12-29 10:23:18
|
Daniel J Sebald wrote: > Then I could put a "player" in full screen mode. (Any suggestions for a > GIF animation viewer? The ones I've tried so far aren't working with > the gnuplot output, gthumb, Eye of Gnome... gifsicle prints out info > about the animated GIF file that makes sense, but I get > GIF file was missing some data (perhaps it was truncated somehow?) from > gthumb.) Oh hey. I've taken the animate GIF output from gnuplot (200 x 200) and run it through gifsicle simply as follows gifsicle -d 5 test.gif > test2.gif i.e., changed the inter image delay and then run test2.gif through gthumb and the animation works. This would be darn close to acceptable. I can turn off interpolation and it looks very good enlarged to full screen. (If only there were a "freeze" or "step through" mode... 20 x 20 cropping would be great.) So, does this suggest that something is not correct about gnuplots animation GIF output format? Dan |
From: Ethan A M. <merritt@u.washington.edu> - 2005-12-29 17:26:40
|
On Thursday 29 December 2005 01:53 am, Daniel J Sebald wrote: > > What I'd like is to create an animation consisting of a series of > images, fairly low resolution, say 20 x 20. Now I've seen a description > of how to do this on the Gnuplot web page, i.e., a series of GIF images. > I'd be fine, really, with anything that can be imported into an > existing "player" so I can play at a rate that would be real-time speed. The main rationale for using animated gifs is so that they can be viewed in a web browser. A secondary use is to embed in PowerPoint presentations, since the other options for embedded movies tend not to be portable enough to rely on. But if you want to make a proper movie or animation I would not recommend gif at all. > Then I could put a "player" in full screen mode. (Any suggestions for a > GIF animation viewer? Use the ImageMagick "animate" command. > So, I have the latest GD library, 2.0.33 and "animate" is activated. I > was hoping the following Octave commands would generate an example of > what I want, but it does not work: > > graw('unset border\n'); > graw('unset tics\n'); > graw('unset colorbox\n'); > graw('set term gif animate delay 10 nooptimize size 20,20 crop\n'); You definitely do not want to crop and animate at the same time. In fact, I think we had better forbid that combination. > Basically, cropping is not done as desired, in my opinion. I know we've > talked about this before (regarding PostScript), but as I see it "crop" > should mean tight up against the last "non-white" or "opaque" graphic > element. That is exactly what the "set term {png|gif|jpeg} crop" option does. But it does not make any sense in the context of an animation because the individual frames do not necessarily have the same border properties. If you try to crop individual frames then they will not match in size, and cannot be assembled into an animation. IMHO cropping of an image, even single non-animated ones, does not belong inside gnuplot at all. This is clearly a task that has pitfalls and subtleties, and should better be left to a separate utility that has been designed to deal with it. I would prefer to remove the option altogether, in favor of recommending: set term png ... set output "| convert -crop 0x0 png:- cropped_image.png" To make a high quality animation, I suggest writing a script that creates a sequence of PNG or JPEG images. You can then combine these into a movie using a single command to the program "mencoder". Mencoder is part of the mplayer package. It can also deal with cropping, color correction and a large collection of other options, and practically any output format in existence. > Maybe gnuplot isn't the thing to use for such a feature. Perhaps there > is a simpler approach in Octave and some output library. (Petr, can you > think of any?) I think gnuplot is fine for creating the individual frames of an animation. But for fine control over the assembled movie, you need a more sophisticated format than animated gifs. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
From: Daniel J S. <dan...@ie...> - 2005-12-29 20:22:57
Attachments:
output40by40.png
|
Ethan A Merritt wrote: > The main rationale for using animated gifs is so that they can be viewed > in a web browser. A secondary use is to embed in PowerPoint presentations, > since the other options for embedded movies tend not to be portable enough > to rely on. But if you want to make a proper movie or animation I > would not recommend gif at all. I thought GIF seemed kind of skimpy as far as an image format. Not scientific graphics, for sure. > You definitely do not want to crop and animate at the same time. > In fact, I think we had better forbid that combination. > > >>Basically, cropping is not done as desired, in my opinion. I know we've >>talked about this before (regarding PostScript), but as I see it "crop" >>should mean tight up against the last "non-white" or "opaque" graphic >>element. > > > That is exactly what the "set term {png|gif|jpeg} crop" option does. > But it does not make any sense in the context of an animation because > the individual frames do not necessarily have the same border properties. > If you try to crop individual frames then they will not match in size, > and cannot be assembled into an animation. Well, I agree with that, I guess. A person could easily string together a series of plots having no visual reference whatsoever. In one sense, "animate" should be a mode that freezes the border characteristics. But then one could not animate, say, zooming in on a portion of a graph. Then again, that really is getting sophisticated as a would-be gnuplot use. > > IMHO cropping of an image, even single non-animated ones, does not > belong inside gnuplot at all. This is clearly a task that has pitfalls > and subtleties, and should better be left to a separate utility that > has been designed to deal with it. No doubt. However, cropping of images is such a useful thing that it could have it's special case in the gnuplot core. That is, if there is nothing on the plot but an image (easy enough to test if I remember correctly), there could be special code to just plot an image to a file and be done with it. (Force the output resolution to match the image.) Just bypass all of the plot layout and so on (unless the terminal deems that necessary, although I can't see why). > I would prefer to remove the option > altogether, in favor of recommending: > > set term png ... > set output "| convert -crop 0x0 png:- cropped_image.png" > > To make a high quality animation, I suggest writing a script > that creates a sequence of PNG or JPEG images. You can then > combine these into a movie using a single command to the > program "mencoder". Mencoder is part of the mplayer package. > It can also deal with cropping, color correction and a large > collection of other options, and practically any output format > in existence. OK. Thanks Ethan. I'll try these out. Why not add this to the FAQ? I think this is a fairly common task... Well, JPEG is out. The help has nothing about lossless images, but JPEG has interpolation and is not acceptable in this application. (Of course, if somehow we could generate output that matches the size of the image, perhaps JPEG will not have this effect.) Actually, the result isn't that good either, the left side of the JPEG images look to have a "half" pixel. The image is not square overall either. PNG seems to produce the best result of all so far. But even still I have to set the resolution high enough to get anything meaningful. If I set it at 20 x 20 (JPEG or PNG) I get complaints from the respective image library about empty data. If I set it at 40 x 40 I get very strange looking figures that appear more like some kind of color box. (See attached PNG.) >>Maybe gnuplot isn't the thing to use for such a feature. Perhaps there >>is a simpler approach in Octave and some output library. (Petr, can you >>think of any?) > > > I think gnuplot is fine for creating the individual frames > of an animation. But for fine control over the assembled movie, > you need a more sophisticated format than animated gifs. Yeah. What is the animated GIF for, really, in terms of gnuplot? I mean, assembling a movie is a far more meaningful thing in the scientific community than an animated graphic for a web page. Alright, let me look at generating movies with ImageMagick... Dan |
From: Petr M. <mi...@ph...> - 2005-12-29 18:58:30
|
> Then I could put a "player" in full screen mode. (Any suggestions for a GIF > animation viewer? xanim animate (from ImageMagick) > graw('set term gif animate delay 10 nooptimize size 20,20 crop\n'); > > talked about this before (regarding PostScript), but as I see it "crop" > should mean tight up against the last "non-white" or "opaque" graphic > element. [I've just fixed that crop didn't work for gif's.] It seems that xanim for crop+animate uses the largest size. > Maybe gnuplot isn't the thing to use for such a feature. Perhaps there is a > simpler approach in Octave and some output library. (Petr, can you think of > any?) For what exactly? --- PM |
From: Daniel J S. <dan...@ie...> - 2005-12-30 06:36:04
|
I've tried a ton of software now. (Couldn't get xanim to work.) Believe it or not gthumb and the animated GIF combination seem the most useful. Here's a good summary of software http://www.gfdl.noaa.gov/products/vis/animation/ Their comment is mplayer is good, GIF not good. My thoughts: mplayer/mencoder ---------------- Awesome program, however it is a bit more than I particularly need. (This is the first time I've been able to view the movie on my Peter Gabriel O.V.O. Millenium Show CD... yeah, only took five years.) mencoder works well for assembling images of various formats. However, drawbacks o Can't step through frame by frame (why I don't know) o I can't seem to figure out how to get unsmoothed images, especially in full screen mode. Either the image format loses resolution or the program automatically does image smoothing. It doesn't matter the output format I choose, e.g. AVI, PNG. There are filters and all kinds of options; too much given the goal is no image processing after what I've already done. o The GUI or "skin" adds nothing really--waste of time. Recommended as a general tool, but could be better. animate ------- Works with GIF animation and separately stored PNG files. Can step through images. Drawbacks: o There is no nice full screen mode. Have to specify a size at the command line. Even then, the image isn't centered, but over to the left edge. o When expanded, there is smoothing of the image and appears to be no way of controlling it, which is odd because ImageMagick looks very good when expanded. Not recommended. Helix/Real Player ----------------- Surprisingly this works with animated GIF files. Drawbacks o Ever so slight loss of resolution when placed in full screen mode. o Doesn't step through so well. Not recommended, close though. gthumb ------ Works with animated GIF, grayscale or color. No image smoothing in full screen mode (must specify low-quality image in preferences). Can stop animation, and can step through. Drawbacks: o There is no hot key for stepping through the images. Oh well. Recommended. gifsicle -------- Not for viewing, but it is a very flexible program for working with GIF images. Too bad mencoder doesn't work so seamlessly. So, my thought on this is that GIF isn't as undesirable as one might guess. I see there is a format called MNG; like with PNG there is a libmng library. (Something called JNG too.) Maybe a gnuplot MNG terminal is the way to go with this sort of thing. Dan Ethan A Merritt wrote: > On Thursday 29 December 2005 12:30 pm, you wrote: > >>No doubt. However, cropping of images is such a useful thing that it >>could have it's special case in the gnuplot core. > > > It cannot be implemented in the core, because it is a terminal-specific > operation. E.g., how on earth would the core code know anything about > a particular pixel in an output png image? Even more impossible is to > know about the "pixels" in an output PostScript file whose font > characteristics will only be determined by the eventual print device. > > >>Well, JPEG is out. > > > Are you talking about mencoder here? > > >>The help has nothing about lossless images, but JPEG >>has interpolation and is not acceptable in this application. > > > JPEG supports a loss-less mode. But yes, normally if you want > loss-less images you would pick a different format. > > Animation normally involves interpolation between frames, and saves > space by sending full "index" frames every Nth frame but intervening > update frames with only incremental or interpolated contents. > The ratio of full to partial/interpolated frames can be set at the > time you encode the animation. > Sounds like you want index frames only. That is definitely possible. > > >>Yeah. What is the animated GIF for, really, in terms of gnuplot? > > > A/B comparisons? > Sequential evolution of a plot feature? > Build-up of a complicated plot from component features? > > >>I mean, assembling a movie is a far more meaningful thing in the >>scientific community than an animated graphic for a web page. > > > A whole lot more people can easily view an embedded gif on a web > page than will take the time to install some fancy movie-player > just so they can afterwards download and look at your plot. > > >>Alright, let me look at generating movies with ImageMagick... > > > Wrong tool. > You really do want mencoder. Believe me. > But you may have to build it from source to get a full range of > supported formats. > -- Dan Sebald phone: 608 256 7718 email: daniel DOT sebald AT ieee DOT org URL: http://webpages DOT charter DOT net/dsebald/ |
From: Ethan A M. <merritt@u.washington.edu> - 2005-12-30 07:05:48
|
On Thursday 29 December 2005 10:43 pm, you wrote: > > Their comment is mplayer is good, GIF not good. What I said :-) > mplayer/mencoder > > o Can't step through frame by frame (why I don't know) True. I've missed this also. > o The GUI or "skin" adds nothing really--waste of time. Everyone agrees with you there. I don't know anyone who uses the gui. > I see there is a format called MNG; like with PNG there is a libmng > library. (Something called JNG too.) Maybe a gnuplot MNG terminal is > the way to go with this sort of thing. I looked into that already. The problem is that MNG is not implemented in the standard PNG library. It's not supported by libgd either. In fact the only general tool I found that supports it is ImageMagick. So we'd either have to roll our own, losing all the nice features of the libgd driver, or else try to compose single frames using libgd and then transfer the resulting data structures into libMagick as we build up the animation. And then you'd have the problem that almost nothing out there will play it back other than ImageMagick itself. Ethan -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
From: Daniel J S. <dan...@ie...> - 2005-12-30 08:49:19
|
Almost!!! I forgot that the borders were present. Setting those to zero, matching the output size to the image resolution and allowing autoscaling darn near gives a perfect translation of an image one-to-one; PNG and GIF. There is only one slight problem. Although the x-dimension is 20 pixels, the y-dimension is only 19 pixels. I'm going to consider that a bug and put together a patch. (So Petr, don't attempt a fix on the other problems I noted. I'll address those as well.) When I'm done, I will also put together a FAQ entry on how to do this. And maybe even an animated GIF demo. (Perhaps a bunch of little images plotted in gnuplot and some text saying that they will be put into an animated GIF and the user should view the created GIF file in gthumb, RealPlayer or animate.) This is great! Dan Ethan A Merritt wrote: > On Thursday 29 December 2005 10:43 pm, you wrote: > >>Their comment is mplayer is good, GIF not good. > > > What I said :-) > > >>mplayer/mencoder >> >>o Can't step through frame by frame (why I don't know) > > > True. I've missed this also. > > >>o The GUI or "skin" adds nothing really--waste of time. > > > Everyone agrees with you there. I don't know anyone who uses the gui. > > >>I see there is a format called MNG; like with PNG there is a libmng >>library. (Something called JNG too.) Maybe a gnuplot MNG terminal is >>the way to go with this sort of thing. > > > I looked into that already. > The problem is that MNG is not implemented in the standard PNG library. > It's not supported by libgd either. In fact the only general tool I > found that supports it is ImageMagick. So we'd either have to roll our own, > losing all the nice features of the libgd driver, or else try to compose > single frames using libgd and then transfer the resulting data structures > into libMagick as we build up the animation. And then you'd have the > problem that almost nothing out there will play it back other than > ImageMagick itself. There doesn't seem to be any big race to support MNG, does there? > > Ethan > -- Dan Sebald phone: 608 256 7718 email: daniel DOT sebald AT ieee DOT org URL: http://webpages DOT charter DOT net/dsebald/ |
From: Daniel J S. <dan...@ie...> - 2005-12-30 13:26:19
|
Daniel J Sebald wrote: > I'm going to consider that a bug and put together a patch. (So Petr, > don't attempt a fix on the other problems I noted. I'll address those > as well.) I've fixed the pixel size issue. (It had to do with the fact that the image size is the "extent", not the number of pixels. That is, the values which are corners really are the outer edges of the image if one thinks of terms of, say, PostScript. And to confuse things, the corners are specified as ints as opposed to floats.) Anyway, I think I've discovered the problem with the GIF animations not working in gthumb. Ethan put the following note into the gd.term file: /* FIXME - using the global colormap would be better, but it breaks */ /* if the individual frames specify ad-hoc RGB colors. */ /* Also, the very last frame should be followed by a call to */ /* gdImageGifAnimEnd(gpoutfile) although in practice it doesn't */ /* seem to matter. */ Thanks for leaving that message. I forced a gdImageGifAnimEnd(gpoutfile) at the end of my twentieth image and sure enough that makes the animated GIF work in gthumb. So, I think this "it doesn't seem to matter" is not a correct statement. I see why the comment is there; because the closing of the file is done in term.c. Now I think there should be, and I'm surprised there already isn't, a terminal function for finishing a file, e.g., <term>_finishfile <term>_wrapup I would think other formats that use compression and such might need to also have a wrap-up routine. Thoughts people? Note that running these gnuplot GIF animations through gifsicle compresses them by a factor of three... don't think that is our problem. Dan |
From: Ethan M. <merritt@u.washington.edu> - 2005-12-30 20:31:01
Attachments:
animation_29dec2005.patch
|
On Friday 30 December 2005 05:34 am, Daniel J Sebald wrote: > > /* FIXME - > /* Also, the very last frame should be followed by a call to > /* gdImageGifAnimEnd(gpoutfile) > /* although in practice it doesn't seem to matter. */ */ > > Thanks for leaving that message. I forced a > gdImageGifAnimEnd(gpoutfile) at the end of my twentieth image and > sure enough that makes the animated GIF work in gthumb. So, I think > this "it doesn't seem to matter" is not a correct statement. Please try the attached patchset. It fixes that issue and a number of other minor bugs like not reporting the optimization setting when the terminal is in animation mode. > I see why the comment is there; because the closing of the file is > done in term.c. Now I think there should be, and I'm surprised there > already isn't, a terminal function for finishing a file, e.g., > > <term>_finishfile > <term>_wrapup > > I would think other formats that use compression and such might need > to also have a wrap-up routine. I have added a terminal flag TERM_CALL_ON_CLOSE that a terminal can set if it wants to be called before the output file is closed. If it is set, then the core code will call back via term->layer(TERM_LAYER_END_MULTI_FRAME_SEQUENCE). It may be worth creating a separate terminal entry point, as you say. On the other hand I think that this is in fact a "layer" boundary of a sort. I could imagine calling it after a sequence of images in a postscript output file, for instance, to cause the driver to emit an accumulated BoundingBox and other per-document meta information. It's tricky, because the terminal type itself may have changed by the time the output file is closed. You would have to call the *previous* driver, which is dicey at best. I think this will remain a case where an explicit "{un}set output" is needed to guarantee that the animation file is correctly terminated. > Note that running these gnuplot GIF animations through gifsicle > compresses them by a factor of three... don't think that is our > problem. That may be due to the optimization flag not being initialized properly. Hopefully this is fixed in the attached patch. At the least you can now see whether it is set or not by using "show term". -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
From: Daniel J S. <dan...@ie...> - 2005-12-30 21:46:45
|
> Please try the attached patchset. > It fixes that issue and a number of other minor bugs like not reporting > the optimization setting when the terminal is in animation mode. The GIF-A now works directly into gthumb. However, the gifsicle conversion complains [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. >>I see why the comment is there; because the closing of the file is >>done in term.c. Now I think there should be, and I'm surprised there >>already isn't, a terminal function for finishing a file, e.g., >> >><term>_finishfile >><term>_wrapup >> >>I would think other formats that use compression and such might need >>to also have a wrap-up routine. > > > I have added a terminal flag TERM_CALL_ON_CLOSE > that a terminal can set if it wants to be called before the output file > is closed. If it is set, then the core code will call back via > term->layer(TERM_LAYER_END_MULTI_FRAME_SEQUENCE). > > It may be worth creating a separate terminal entry point, as you say. > On the other hand I think that this is in fact a "layer" boundary of a > sort. I could imagine calling it after a sequence of images in a > postscript output file, for instance, to cause the driver to emit an > accumulated BoundingBox and other per-document meta information. > > 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. What you've done with term->layer hasn't circumvented the problem, I think. 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. 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. I keep snooping around with the file size issue, then put together a FAQ. Dan |
From: Ethan M. <merritt@u.washington.edu> - 2005-12-30 22:05:06
|
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 |
From: Daniel J S. <dan...@ie...> - 2005-12-30 22:23:34
|
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 |
From: Daniel J S. <dan...@ie...> - 2005-12-30 22:07:40
|
Daniel J Sebald wrote: > The size is still large compared to what > gifsicle creates. I see what the issue is. Although at the start of the animation file the GlobalCM is set so that the animation can reuse the same color map over and over, the gdImageGifAnimAdd routine indicates that the particular image in question should use it's own color map. gdImageGifAnimAdd(png_state.image, gpoutfile, 1 /* 0 = global 1 = local colormap */, 0, 0 /* No offset */, png_state.frame_delay, gdDisposalNone, png_state.frame_optimization ? png_state.previous_image : NULL); Hence, GlobalCM is effectively turned off here. I've recompiled after setting the above parameter to zero. The file size is then on the order of that produced by gifsicle FROM THE FIRST ATTEMPT: -rw-r--r-- 1 sebald users 9818 Dec 30 16:05 test.gif -rw-r--r-- 1 sebald users 8691 Dec 30 15:43 test10.gif HOWEVER, running that file through gifsicle creates a super-condensed file: -rw-r--r-- 1 sebald users 955 Dec 30 16:05 test11.gif one which in gthumb has a very, very reduced dynamic range (basically black and one level above black). So, something is not right here. It's as if the global color map used to initiate the file is incorrect and setting the parameter from 1 to 0 forces all subsequent images to use that color map. gifsicle thinks it can really compress such a series. Dan |
From: Ethan M. <merritt@u.washington.edu> - 2005-12-30 22:20:19
|
On Friday 30 December 2005 02:15 pm, Daniel J Sebald wrote: > > I see what the issue is. Although at the start of the animation file > the GlobalCM is set so that the animation can reuse the same color > map over and over, the gdImageGifAnimAdd routine indicates that the > particular image in question should use it's own color map. So my guess was correct. > 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. In fact, the current code may set this before colors have been determined even for the 1st frame. If that's the case, it's no wonder you ended up with a monotone image. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
From: Daniel J S. <dan...@ie...> - 2005-12-30 22:26:09
|
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. > > In fact, the current code may set this before colors have been > determined even for the 1st frame. If that's the case, it's no > wonder you ended up with a monotone image. 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. Additional parameter? Or no additional parameter? Dan |
From: Ethan A M. <merritt@u.washington.edu> - 2005-12-31 00:08:15
|
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. 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? 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? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
From: Daniel J S. <dan...@ie...> - 2005-12-31 00:25:20
|
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 |
From: Ethan A M. <merritt@u.washington.edu> - 2005-12-31 00:38:02
|
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. But neither gnuplot nor the end user knows that this has happened, and that the colormap has changed. 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. > 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? -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
From: Daniel J S. <dan...@ie...> - 2005-12-31 01:03:02
|
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 |
From: Daniel J S. <dan...@ie...> - 2006-01-01 02:35:38
|
Here's a resulting patch for I've added a demo. A new animation that spins the globe around. So there is an "animate2.dem" combining the concepts of animate.dem and world2.dem. I've also rewritten "animate.dem" and "gnuplot.rot" slightly. So that I could reuse gnuplot.rot, I've made it generic as follows: zrot=(zrot+zrot_delta)%360 xrot=(xrot+xrot_delta)%360 set view xview(xrot),zview(zrot) replot iteration_count=iteration_count+1 if ((!limit_iterations) || (iteration_count<=limit_iterations)) reread You can imagine how this works. Just define all the variables and away we go. Some comments: 1) It would be nice if looping could be done without requiring two files. What might enable that is a special test or function saying how deep the "reread" is. For example, say I wanted to have the above example in a single file, it might be if (!load_depth()) <all the initial definitions> else zrot= xrot= set view replot iteration_count= if () reread end where load_depth() is just some pseudo function or variable that gnuplot makes available. 2) Modulo (%) doesn't seem to work with negative numbers. Shouldn't it? 3) We've got to combine the layout and border behavior for 2D and 3D plots. In the demo I created, I had to make the GIF output resolution very large simply because otherwise all the image is used up by the borders and only a few pixels are left for the plot. I tried to kludge this by making the view scaling large, but then got: gnuplot: hidden3d.c:776: store_polygon: Assertion `p->ymax <= surface_scale' failed. Dan |
From: Daniel J S. <dan...@ie...> - 2006-01-01 04:45:12
|
Ethan A Merritt wrote: I said wait. :-) Read on... > On Saturday 31 December 2005 06:43 pm, Daniel J Sebald wrote: > > >>1) It would be nice if looping could be done without requiring two >>files. > > > It can, although the lack of if/else/endif blocks makes it ugly: > > if (!defined(i)) foo = foo0 > if (!defined(i)) baz = baz0 > if (!defined(i)) i = 0 > i = i + 1 > ... do lots of stuff > reread OK, that sort of works. I didn't think of defined(). But what if i happens to be defined already upon loading such a script and the user doesn't realize it? It could run without complaints but not produce the desired results. > > >>2) Modulo (%) doesn't seem to work with negative numbers. Shouldn't it? > > > Works for me: > > gnuplot> > gnuplot> print 9 % 8 > 1 > gnuplot> print -9 % 8 > -1 > gnuplot> > > Or were you expecting -9 % 8 to be 7? Yes, I guess that is what I was expecting--something in the set of integers [0,7], related to modular arithmetic. Also, Octave generates 7. The reason this came about is that to get the globe from your world2.dem demo to rotate in the right direction requires a -10 increment in the z rotation. The modular math as it is means eventually a negative value results and gnuplot complains about that view angle "must be between 0 and 360". I solved this of course by making the increment 350 degrees. > > >>3) We've got to combine the layout and border behavior for 2D and 3D >>plots. > > > Good luck! I don't think it should be too difficult to do that anymore. I seem to recall unifying those a bit already. Definitely post 4.1. Dan |