Re: octave gset, graw

[Daniel J Sebald]

Bill Denney wrote:
> On Fri, 24 Feb 2006, Quentin Spencer wrote:
>
> > Daniel J Sebald wrote:
> >
> > > Could the group be more explicit about the roadmap for graphics?  I 
> > > listen to John I hear one thing, other people say some other thing.
>
>
> I'm not positive, but here is my guess:  handle graphics will be the
> method used in 3.0.  When that happens, there will be a gnuplot back-end
> that you can probably still tweak with __gnuplot_raw__ and other similar
> commands.

OK.


> I would say that searching octave documentation for how to plot 
> something in octave is far more intuitive and less cumbersome than 
> searching gnuplot documentation for how to plot something in octave.

I'll concede that point.

> Also, I have before written scripts that output data that is then input 
> by a gnuplot command script.  Using octave commands to make octave plots 
> seems the least cumbersome.

Oh, certainly.  I mean 'plot(x)' and 'image(A)' win out any day on any computer.

> > > Also, retaining the "graw()" (which I understand now is meant to be 
> > > graphics raw, not gnuplot raw) gives some fine control that might not 
> > > be found in handle graphics.  For example, will there be ways in the 
> > > print command to do something like
> > >
> > > graw('set term gif animate 0.1\n')
> > >
> > > ?  Probably not.  Why?  Because the way Matlab works now, one is 
> > > forced to first draw a plot and then change its properties as opposed 
> > > to setting the properties and then doing the plot.  If I can set the 
> > > properties first, with a command like above, I can string together a 
> > > series of plots into an animation.
>
>
> There are other ways to string together plots into animations.

In Octave?  Such as "movie(A)" or something?  Or maybe "print -dgifanim"?  Or 
do you mean make a series of graphs outside Octave and then string them together with some other 
utility.

>  I 
> personally plan to make sure that there is an SVG output.  With SVG it 
> is trivial to convert it to a gif animation.  I may make that an 
> option.  I don't see how it makes it easier to make an animation by 
> putting the command before or after making the plots.

Well, if the "print" command has a means of stringing together plots, I guess 
not.

> > > If there is an internal graphics engine for Octave, then HG would 
> > > seem fairly easy conceptually.  But if the idea is to support 
> > > multiple graphics engines will life be so simple?
> >
> >
> > I think this is why John has advocated implementing an internal handle 
> > graphics engine written as m files that interface with low-level 
> > plotting functions unique to each graphics backend. It will of course 
> > start with gnuplot as the default, but theoretically someone wanting a 
> > different output generator could write the low-level interface 
> > functions and use the same handle graphics fron end.
>
>
> I agree with this.  That is why I am trying to make sure that the 
> interface for the users and the backend developers is defined.  If I can 
> make a set of handles and then use it to make a plot on the screen, then 
> export it to an SVG, then make an animation out of it, ... then I'm 
> going to enjoy plotting significantly more (which is currently what I 
> think is the biggest weakness in Octave).

__graw__('set term gif animate\n');
__graw__('set output '''myfile.gif'''\n');
for i_image = 1:50
  x = <process some data>;
  plot(x);
end
__graw__('set output\n');

I realize it would be nice to have something more like

for i_image = 1:50
  x = <process some data>;
  plot(x);
  print -dgifa 'myfile.gif'
end

but it takes some non-trivial coding to enable this.

Dan