Menu
▾
▴
gnuplot-beta
|
From: Jim K. <je...@kl...> - 2005-01-13 00:54:58
|
Would it make any sense to hack gd.trm to add an option to detect when a new plot is created and if output is to a non-pipe named file to auto-append a number ahead of the extension and close/reopen the file? Quick inspection of the code suggests that it can be done but perhaps there are gotchas and/or complexities that don't show on the surface. For multiplot plots as an example. An option named, say, auto_number_files ? Issuing "set output" commands for every plot can be a tedious retrofit to something that works with PS or PDF. Comments? Jim |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-01-13 01:47:54
|
It would be possible. The "not a pipe" test may be problematic, since there are all sorts of reasons for using a pipe, and some of them might well benefit from the new option. For what it's worth, there is an extended standard that permits multiple images in *one* png file. It is supported, for instance, by ImageMagick. But as I recall this isn't currently provided by libgd. On Wednesday 12 January 2005 04:54 pm, Jim Kleckner wrote: > Would it make any sense to hack gd.trm to > add an option to detect when a new plot is > created and if output is to a non-pipe named > file to auto-append a number ahead of the extension > and close/reopen the file? Quick inspection > of the code suggests that it can be done but perhaps > there are gotchas and/or complexities that don't > show on the surface. For multiplot plots as > an example. > > An option named, say, auto_number_files ? > > Issuing "set output" commands for every plot > can be a tedious retrofit to something that > works with PS or PDF. > > Comments? > > Jim > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Hans-Bernhard B. <Han...@ph...> - 2005-01-14 00:02:14
|
Jim Kleckner wrote: > Would it make any sense to hack gd.trm to > add an option to detect when a new plot is > created and if output is to a non-pipe named > file to auto-append a number ahead of the extension > and close/reopen the file? If at all, such a modification would have to be independent of the terminal driver. I.e. gd.trm really shouldn't have anything to do with this. > Issuing "set output" commands for every plot > can be a tedious retrofit to something that > works with PS or PDF. It may not even be strictly necessary --- at least not for GIF files generated by gd.trm. GIF files can, at least in principle, hold multiple pages. But I suspect the GD library doesn't support this (admittedly rarely used) feature, so gd.trm can't do anything about that. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-01-15 21:12:11
|
On Thursday 13 January 2005 05:02 pm, Hans-Bernhard Broeker wrote: > > It may not even be strictly necessary --- at least not for GIF files > generated by gd.trm. GIF files can, at least in principle, hold > multiple pages. But I suspect the GD library doesn't support this > (admittedly rarely used) feature, so gd.trm can't do anything about > that. Tom Boutell says it is scheduled for an upcoming version of libgd. And, as I mentioned already, png could be supported this way also. But I don't know of any specific plans to add multi-image png support to libgd. -- Ethan A Merritt Biomolecular Structure Center University of Washington 98195-7742 |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-01-18 19:42:30
|
update:
multi-image GIFs are supported and working in libgd as of
version 2.0.32 (Nov 2004).
So we could use this mechanism if we really wanted to.
The first problem I see is that you have to initialize
the GIF file differently if you want to insert multiple
images, so you have to know in advance that you are
going to do so. In other words, it won't work to
have term->graphics() simply check whether the file is
already open. It would have to be a new option
set term gif {animated}
The gif term for multi-image is "animated", although
this may not be the best keyword to use in gnuplot.
"multiplot" would be better, but it already is being
used for something else.
Does anyone think this would be worth the effort?
On Saturday 15 January 2005 01:12 pm, Ethan Merritt wrote:
> On Thursday 13 January 2005 05:02 pm, Hans-Bernhard Broeker wrote:
> >
> > It may not even be strictly necessary --- at least not for GIF files
> > generated by gd.trm. GIF files can, at least in principle, hold
> > multiple pages. But I suspect the GD library doesn't support this
> > (admittedly rarely used) feature, so gd.trm can't do anything about
> > that.
>
> Tom Boutell says it is scheduled for an upcoming version of libgd.
> And, as I mentioned already, png could be supported this way also.
> But I don't know of any specific plans to add multi-image png
> support to libgd.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Harald H. <h.h...@tu...> - 2005-01-18 21:29:13
|
On Tue, 18 Jan 2005, Ethan Merritt wrote:
> multi-image GIFs are supported and working in libgd as of
> version 2.0.32 (Nov 2004).
>
> So we could use this mechanism if we really wanted to.
> The first problem I see is that you have to initialize
> the GIF file differently if you want to insert multiple
> images, so you have to know in advance that you are
> going to do so. In other words, it won't work to
> have term->graphics() simply check whether the file is
> already open. It would have to be a new option
> set term gif {animated}
>
> The gif term for multi-image is "animated", although
> this may not be the best keyword to use in gnuplot.
> "multiplot" would be better, but it already is being
> used for something else.
What about "multipage"?
--
Harald Harders
h.h...@tu...
http://www.harald-harders.de
|
|
From: Hans-Bernhard B. <br...@ph...> - 2005-01-19 13:20:16
|
Harald Harders wrote:
> On Tue, 18 Jan 2005, Ethan Merritt wrote:
>>The first problem I see is that you have to initialize
>>the GIF file differently if you want to insert multiple
>>images, so you have to know in advance that you are
>>going to do so. In other words, it won't work to
>>have term->graphics() simply check whether the file is
>>already open. It would have to be a new option
>> set term gif {animated}
Just as clarification: would it fail to work if we always claimed to be
going to build an animated GIF, but just make it a single-frame
degenerate case of an "animation" in case the user closes output after
only one plot?
>>The gif term for multi-image is "animated", although
>>this may not be the best keyword to use in gnuplot.
>>"multiplot" would be better, but it already is being
>>used for something else.
> What about "multipage"?
Full ACK. Esp. since it exactly matches our existing "help glossary"
definition of what a 'page' is.
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-01-19 19:38:36
|
On Wednesday 19 January 2005 05:21 am, Hans-Bernhard Broeker wrote:
> > On Tue, 18 Jan 2005, Ethan Merritt wrote:
>
> >>The first problem I see is that you have to initialize
> >>the GIF file differently if you want to insert multiple
> >>images, so you have to know in advance that you are
> >>going to do so. In other words, it won't work to
> >>have term->graphics() simply check whether the file is
> >>already open. It would have to be a new option
> >> set term gif {animated}
>
> Just as clarification: would it fail to work if we always claimed to be
> going to build an animated GIF, but just make it a single-frame
> degenerate case of an "animation" in case the user closes output after
> only one plot?
libgd would be fine with that, so far as I know.
But I would worry that not all viewers can handle files
that claim to be animated gifs. Maybe they can.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Jim K. <je...@kl...> - 2005-01-19 19:46:54
|
Hans-Bernhard Broeker wrote:
> Harald Harders wrote:
>
>> On Tue, 18 Jan 2005, Ethan Merritt wrote:
>
>>> The first problem I see is that you have to initialize
>>> the GIF file differently if you want to insert multiple
>>> images, so you have to know in advance that you are
>>> going to do so. In other words, it won't work to
>>> have term->graphics() simply check whether the file is
>>> already open. It would have to be a new option
>>> set term gif {animated}
>
> Just as clarification: would it fail to work if we always claimed to be
> going to build an animated GIF, but just make it a single-frame
> degenerate case of an "animation" in case the user closes output after
> only one plot?
>
>>> The gif term for multi-image is "animated", although
>>> this may not be the best keyword to use in gnuplot.
>>> "multiplot" would be better, but it already is being
>>> used for something else.
>
>> What about "multipage"?
>
> Full ACK. Esp. since it exactly matches our existing "help glossary"
> definition of what a 'page' is.
I have also wanted to create GIF animations. How hard is it to
crack them back apart into individual images? Note that the
current behavior for GIF and PNG is to lose all plots subsequent
to the first one. Would it make sense to define an option to
write these subsequent plots to sequentially numbered files?
Then you choose "multipage" when the GIF should contain
an animation and perhaps "mutifile" when the GIFs should be
written into individual files. Fail if they already exist?
|
|
From: Hans-Bernhard B. <br...@ph...> - 2005-01-21 16:47:55
|
Jim Kleckner wrote: > I have also wanted to create GIF animations. How hard is it to > crack them back apart into individual images? I don't know. But it shouldn't be excessively hard --- even Java's AWT can do it ;-) > Note that the > current behavior for GIF and PNG is to lose all plots subsequent > to the first one. In the existing framework, that's one of only two possibly sane ways of doing it (the other: keep only the last page). > Would it make sense to define an option to > write these subsequent plots to sequentially numbered files? It might, if someone manages to pull it off and find an understandable user interface. I would imagine something like set output 'filename' numbered (maybe with some options to control how the numbers are put into the name). The main benefit of this approach would be that it would work for other file-based terminal drivers, too. |
|
From: Daniel J S. <dan...@ie...> - 2005-01-21 17:03:33
|
Hans-Bernhard Broeker wrote: > Jim Kleckner wrote: > >> I have also wanted to create GIF animations. How hard is it to >> crack them back apart into individual images? > > > I don't know. But it shouldn't be excessively hard --- even Java's > AWT can do it ;-) > >> Note that the >> current behavior for GIF and PNG is to lose all plots subsequent >> to the first one. > > > In the existing framework, that's one of only two possibly sane ways > of doing it (the other: keep only the last page). > > > Would it make sense to define an option to > >> write these subsequent plots to sequentially numbered files? > > > It might, if someone manages to pull it off and find an understandable > user interface. I would imagine something like > > set output 'filename' numbered > > (maybe with some options to control how the numbers are put into the > name). > > The main benefit of this approach would be that it would work for > other file-based terminal drivers, too. With that approach, perhaps "multi" should be a keyword because it is similar in concept to multiplot, agree? Just yesterday I could have used something like this to generate PNG files from a series of graphs in Octave. It beats doing a "mv output.png output1.png" after every plot. On the other hand, I just used the PDF file format because there everything is "packaged" automatically and there is a viewer to go along with it. The problem with PDF, however, is it's usual benefit. If one has a plot with many, many sample points, the series of plots gets rather big. I'd still like the terminal to create a single file for animation if possible. That just seems so much nicer. Guess I see the application for both. Dan |
|
From: Daniel J S. <dan...@ie...> - 2005-01-18 21:39:07
|
Ethan Merritt wrote:
>update:
>
>multi-image GIFs are supported and working in libgd as of
>version 2.0.32 (Nov 2004).
>
>So we could use this mechanism if we really wanted to.
>The first problem I see is that you have to initialize
>the GIF file differently if you want to insert multiple
>images, so you have to know in advance that you are
>going to do so. In other words, it won't work to
>have term->graphics() simply check whether the file is
>already open. It would have to be a new option
> set term gif {animated}
>
>The gif term for multi-image is "animated", although
>this may not be the best keyword to use in gnuplot.
>"multiplot" would be better, but it already is being
>used for something else.
>
>Does anyone think this would be worth the effort?
>
>
I'm sitting here think about the ability to create a movie of plots, say
to watch the activity in some multidimensional data evolve. PDF files
work fairly well at this if one just keeps hitting return fairly fast.
But creating some output format that could be stepped through with a
viewer or movie player might be a long-term neat capability. Is that
what you have in mind with "animate"?
Dan
|
|
From: Petr M. <mi...@ph...> - 2005-01-19 14:41:30
|
> >So we could use this mechanism if we really wanted to.
> >The first problem I see is that you have to initialize
> >the GIF file differently if you want to insert multiple
> >images, so you have to know in advance that you are
> >going to do so. In other words, it won't work to
> >have term->graphics() simply check whether the file is
> >already open. It would have to be a new option
> > set term gif {animated}
> >
> >The gif term for multi-image is "animated", although
> >this may not be the best keyword to use in gnuplot.
> >"multiplot" would be better, but it already is being
> >used for something else.
> >
> >Does anyone think this would be worth the effort?
I've recently built "animation" into the "zimg" program, which normally uses
gd for its output. Before writing the generated image into .gif/.png file,
it is dumping the bitmap into ppm or pgm (ascii) file, which can be
transformed to a movie via animate or convert.
BTW:
set term gif {animated {delay msec}}
--
PM
|
