Matlab ginput

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Matlab ginput

chelle-2

Hi,

I think that's impossible, because the use of gnuplot to draw graphics, but,
I 'd like to know if it exists an octave function that allows to specify
on the graphic window, several points or domain with the mouse and to retrieve this data in an octave object. I think there is a matlab function (~ginput()) that does this.

Thanks in advance.

Michael
  _________________________________________________________________________
 /     Michael CHELLE                                                      \
|                                                        |
|        INRA                       |  email : [hidden email]  |
|   Station de Bioclimatologie      |  phone : +33 01 30 81 55 31           |
| 78850 THIVERVAL-GRIGNON (France)  |  fax   : +33 01 30 81 55 63           |
 \_________________________________________________________________________/

Reply | Threaded
Open this post in threaded view
|

Re: Matlab ginput

Ted.Harding
( Re Message From: [hidden email] )
>
> I think that's impossible, because the use of gnuplot to draw graphics, but,
> I 'd like to know if it exists an octave function that allows to specify
> on the graphic window, several points or domain with the mouse and to
> retrieve this data in an octave object. I think there is a matlab
> function (~ginput()) that does this.

There is indeed such a MatLab function (and very useful it can be).
However, there is no such function with octave-1.1.1.

Nor, so long as graphics depends on gnuplot, is there likely to be: the
gnuplot display does its work independently of octave once it has received
the input from octave: only gnuplot knows where on the screen the
coordinates are plotted, and gnuplot won't tell. You can't use the mouse
to ask gnuplot for the coordinates of points it has plotted.

However, if a different graphics package were used (which one, anyone?),
which had the capability of outputting the coordinates of points selected
by the mouse, then it would be possible to write such an octave function.
Either the coordinates could be written to a file which could be read by
octave. or maybe pipes or sockets could be used.

The statistical software package xlispstat is very good at graphics, and
allows this sort of selection very flexibly. I have been toying with the
idea of interfacing octave to it (but would have to grapple with LISP).

Another possible benefit that could result from such a step would be the
possibility of dynamic graphing -- adding points/lines to a plot in real
time as they are computed.

Has anyone else any ideas along these lines, or has gone further into
xlispstat or similar than I have?

Best wishes to all,
Ted.                                    ([hidden email])

Reply | Threaded
Open this post in threaded view
|

Re: Matlab ginput

petravick@FNAL.GOV
We faced this choice a few years ago in a differnt context. We "required"
ginput()-like functionality, and could not choose gnuplot for the same
reasons.

At that time we chose a package called pgplot. IT had the beneift of
optaillying forking off an X handler, so our application did not need an event
loop. This has served us very well, but integrating pgplot introduces it own
blemish, as it is written in f77.

We have compiled it with g77, and I have heard that others have "f2c"ed it,
but it is a problem.

-- DOn


On Fri, 29 Nov 1996, Ted Harding wrote:

> Date: Fri, 29 Nov 1996 15:04:09 +0000 (GMT)
> From: Ted Harding <[hidden email]>
> To: [hidden email]
> Cc: [hidden email]
> Subject: Re: Matlab ginput
>
> ( Re Message From: [hidden email] )
> >
> > I think that's impossible, because the use of gnuplot to draw graphics, but,
> > I 'd like to know if it exists an octave function that allows to specify
> > on the graphic window, several points or domain with the mouse and to
> > retrieve this data in an octave object. I think there is a matlab
> > function (~ginput()) that does this.
>
> There is indeed such a MatLab function (and very useful it can be).
> However, there is no such function with octave-1.1.1.
>
> Nor, so long as graphics depends on gnuplot, is there likely to be: the
> gnuplot display does its work independently of octave once it has received
> the input from octave: only gnuplot knows where on the screen the
> coordinates are plotted, and gnuplot won't tell. You can't use the mouse
> to ask gnuplot for the coordinates of points it has plotted.
>
> However, if a different graphics package were used (which one, anyone?),
> which had the capability of outputting the coordinates of points selected
> by the mouse, then it would be possible to write such an octave function.
> Either the coordinates could be written to a file which could be read by
> octave. or maybe pipes or sockets could be used.
>
> The statistical software package xlispstat is very good at graphics, and
> allows this sort of selection very flexibly. I have been toying with the
> idea of interfacing octave to it (but would have to grapple with LISP).
>
> Another possible benefit that could result from such a step would be the
> possibility of dynamic graphing -- adding points/lines to a plot in real
> time as they are computed.
>
> Has anyone else any ideas along these lines, or has gone further into
> xlispstat or similar than I have?
>
> Best wishes to all,
> Ted.                                    ([hidden email])
>

Reply | Threaded
Open this post in threaded view
|

Re: Matlab ginput

John W. Eaton-6
On 29-Nov-1996, [hidden email] <[hidden email]> wrote:

: We faced this choice a few years ago in a differnt context. We "required"
: ginput()-like functionality, and could not choose gnuplot for the same
: reasons.
:
: At that time we chose a package called pgplot. IT had the beneift of
: optaillying forking off an X handler, so our application did not
: need an event loop. This has served us very well, but integrating
: pgplot introduces it own blemish, as it is written in f77.

Most of the numerical parts of Octave are also written in Fortran, so
I don't think this is much of a problem.

I am planning to focus on graphics and GUI stuff for 2.1 and am
currently leaning toward plplot and Tcl/Tk, though I don't want Octave
to depend on either.  I am hoping to make it possible for people to
use whatever graphics and GUI tools they prefer, just by writing a
relatively small amount of C++ code.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Matlab ginput

Jay A. St. Pierre
On Mon, 2 Dec 1996, John W. Eaton wrote:

> I am planning to focus on graphics and GUI stuff for 2.1 and am
> currently leaning toward plplot and Tcl/Tk, though I don't want Octave
> to depend on either.  I am hoping to make it possible for people to
> use whatever graphics and GUI tools they prefer, just by writing a
> relatively small amount of C++ code.

I wonder how hard it would be to make a modification to the gnuplot
source code to allow it to support a ginput interface.  Having never
looked at the gnuplot source in any detail, I don't know.  Has anybody
ever mentioned this to the primary maintainer of gnuplot?

-Jay


Reply | Threaded
Open this post in threaded view
|

Re: Matlab ginput

Mario Storti-3
In reply to this post by chelle-2

BTW, is there a way to know the aspect ratio of the gnuplot window?  I
want  to have the same scale  factor in both  axis, since I'm plotting
finite element meshes, and similar things. In Matlab 3.5 for DOS there
was the axis('square') feature.

Mario

%%%%%%<>%%%%%%<>%%%%%%<>%%%%%%<>%%%%%%<>%%%%%%<>%%%%%%<>%%%%%%<>%%%%%%<>%%%
Mario Alberto Storti               | Fax: (54)(42) 55.09.44               |
Grupo de Tecnologia Mecanica       | Tel: (54)(42) 55.91.75               |
INTEC, Guemes 3450 - 3000 Santa Fe | http://venus.unl.edu.ar/gtm-eng.html |
Argentina                          | Home: Gob. Vera 3161                 |
Reply: [hidden email]  |       (54)(42) 55.00.23              |

Reply | Threaded
Open this post in threaded view
|

Re: Matlab ginput

John W. Eaton-6
On  2-Dec-1996, Mario Storti <[hidden email]> wrote:

: BTW, is there a way to know the aspect ratio of the gnuplot window?

I don't know if gnuplot can return this information.  Even if it can,
it is not currently possible to have it returned in a variable in Octave.

: I want  to have the same scale  factor in both  axis, since I'm plotting
: finite element meshes, and similar things. In Matlab 3.5 for DOS there
: was the axis('square') feature.

With some terminal drivers, the commands

  set size square

or

  set size ratio 1

will set the plot axes to be square, though the scales are not
necessarily forced to be the same, so circles may still be displayed
as ellipses.  For example,

  gnuplot> set size ratio 1
  gnuplot> set parametric

          dummy variable is t for curves, u/v for surfaces
  gnuplot> plot sin(t), cos(t)

shows a circle on my X display, but
 
  gnuplot> set xrange [-2:2]
  gnuplot> replot

turns it into an ellipse.

This works with gnuplot 3.6beta, anyway.  I didn't check earlier
versions.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Matlab ginput

Ted.Harding
In reply to this post by chelle-2
( Re Message From: John W. Eaton )

>
> On  2-Dec-1996, Mario Storti <[hidden email]> wrote:
>
> : BTW, is there a way to know the aspect ratio of the gnuplot window?
>
> I don't know if gnuplot can return this information.  Even if it can,
> it is not currently possible to have it returned in a variable in Octave.
>
> : I want  to have the same scale  factor in both  axis, since I'm plotting
> : finite element meshes, and similar things. In Matlab 3.5 for DOS there
> : was the axis('square') feature.
>
> With some terminal drivers, the commands
>   set size square
> or
>   set size ratio 1
> will set the plot axes to be square, though the scales are not
> necessarily forced to be the same, so circles may still be displayed
> as ellipses.  For example,
>   gnuplot> set size ratio 1
>   gnuplot> set parametric
>  dummy variable is t for curves, u/v for surfaces
>   gnuplot> plot sin(t), cos(t)
> shows a circle on my X display, but
>   gnuplot> set xrange [-2:2]
>   gnuplot> replot
> turns it into an ellipse.
>
> This works with gnuplot 3.6beta, anyway.  I didn't check earlier
> versions.
>
> jwe

With regard to the above: I haven't used 3.6-beta, but am a long-time user
of gnuplot-3.5. In 3.5, the "set size <anything>" command sets the size of
the total /plotting/ area, including tic-labels, axis labels, plot title,
etc. The /graph/ itself (i.e. the axes and the plotted points) fits into
this according to the space taken up by the "furniture". Therefore it is
not possible to directly control the size of the /graph/, and you can only
get a 1:1 aspect ratio for the /axes/ by experiment. Also, a size setting
that gives 1:1 on a screen display may well give non-1:1 when printed on
paper. I know there were intentions to address these and other questions
during the development of 3.6, but can't answer for where they're at.

With regard to the other query from Jay St Pieere ("I wonder how hard it
would be to make a modification to the gnuplot source code to allow it to
support a ginput interface"), my guess is that this might be possible. It
would involve modifying, not gnuplot, but gnuplot-X11 (which is a
"backend" to gnuplot that gnuplot writes to, which in turn writes to the X
display). In fact, the best approach would be to produce a totally
different X "back-end" which could interpret gnuplot X-output (the
character stream), and have a mouse-event handler built-in. If this could
then write to file/named pipe/screen (and be based on Tcl/Tk perhaps) then
it might be possible.

But this would not be a trivial task, and I myself don't propose to try --
for the following reasons.

Based on my experience of 3.5 (and I may be doing 3.6-beta an injustice),
while gnuplot is a very useful rough-and-ready graphics display tool, and
can produce quite decent output on many occasions, it is not a top-class
package for "production" output. As well as the sort of minor roughness
such as the "size" question above, 3.5 at least was capable of making a
total mess of contouring and of surface plotting, and there are many other
technical shortcomings as well. Unless 3.6 (when finished) solves all
these problems, I would remain of the same view of gnuplot. Gnuplot's
basic problem is that it tries to be all things to all "terminals", and
builds the lot into the main code (with the partial exception of X11).
When 3.6 was first mooted, there was discussion of moving ALL the
terminal-dependent code out into backends like gnuplot-x11, with gnuplot
itself concerned only with generating "terminal-independent" code. If they
had gone down this road I would have joined in enthusiastically, but
apparently they decided not to, and I think this means that gnuplot is
going to continue to try to break out of its dead-end, but in fact only
tinker with the problem. My understanding is that, while this approach
would have been straightforward on UNIX systems, it would have been too
difficult, or impossible, on other OSs, and there was a policy decision to
keep gnuplot "universal". So be it. But then my wish is to see something
other than gnuplot.

Gnuplot has served octave well, but is not adequate to allow octave to
reach its full potential. Octave has reached a new stage of maturity, and
it is time to address the graphics question seriously. Along with this
goes the contouring/surface-plotting question. Again, up to a point
gnuplot has served octave reasonably well for these two purposes, but
(leaving aside the occasional complete collapse of contour/surface) there
are important possibilities which remain remote (though not absolutely
impossible) so long as these functions are delegated to gnuplot, rather
than being computed within octave.

1. You cannot directly obtain the coordinates of the countour lines
   (planar or surface) as you can in MatLab (where the function "contour"
   returns lists of numerical coordinates directly to MatLab); the best
   you can do in gnuplot is to "set terminal table" and "set output file",
   and then write an octave function to recover this information from the
   file.

2. Similar considerations apply to surfaces themselves.

3. (A different point). It is not possible to fill, shade or colour boxes,
   facets of surfaces, or bands between contours etc, in gnuplot. This is
   because all these things are simply collections of line segments to
   gnuplot, which has no concept of closed region.

So far, using octave, I have on accasion substituted other graphics
software (mainly PlotMTV and sometimes GLE) for gnuplot, especially when I
want a professional finish or special effects (not so special -- these are
not only normal expectation for good presentation, but often essential to
represent the information at all).

Therefore I warmly welcome John's announced intention to develop octave
graphics in a new direction, and will be happy to help as best I can.
The main thing needed by anyone who wants to think about "new graphics for
octave" is what the "graphics output stream" is expected to look like.
Given that, we can try the effects and capabilities of different tools.

Given these views, I think modifying gnuplot for "ginput" would be yet
another stop-gap in the long line of such attempts to rememdy gnuplot
deficiencies.

This is also the moment to, at least, put contouring where it belongs:
fair and square in octave!

Sorry to have launched a mini-treatise on the questions, but the above
(and a good deal else besides) has been building up steam for some time.

Meanwhile, my hearty thanks and deep appreciation to John Eaton for having
brought octave to where it is, and for his continuing efforts and
intentions to further enhance it.

Best wishes to all,
Ted.                                    ([hidden email])

Reply | Threaded
Open this post in threaded view
|

Re: Matlab ginput

Joao Cardoso-6
In reply to this post by chelle-2

Hi,

 | With regard to the above: I haven't used 3.6-beta, but am a long-time user
 | of gnuplot-3.5. In 3.5, the "set size <anything>" command sets the size of
 | the total /plotting/ area, including tic-labels, axis labels, plot title,
 | etc. The /graph/ itself (i.e. the axes and the plotted points) fits into
 | this according to the space taken up by the "furniture". Therefore it is
 | not possible to directly control the size of the /graph/, and you can only
 | get a 1:1 aspect ratio for the /axes/ by experiment. Also, a size setting
 | that gives 1:1 on a screen display may well give non-1:1 when printed on
 | paper. I know there were intentions to address these and other questions
 | during the development of 3.6, but can't answer for where they're at.

The WhatsNews of gnuplot pre3.6-pl315 says:

in release 293/294
  set size square has been generalised to
    set size { square | ratio <r> | noratio }
    where <r> is an aspect ratio of height / width

in release 162/164
   set size [{no}square] x,y  - tries to plot with aspect ratio 1
   - seems to work great for postscript
   - please check with your favourite driver
   - uses relative sizes of tics to determine required size.

So it seems that they try, but not completely succedd,
Joao


--
Joao Cardoso, INESC  |  e-mail: [hidden email]
R. Jose Falcao 110   |  tel:    + 351 2 2094345
4000 Porto, Portugal |  fax:    + 351 2 2008487





Reply | Threaded
Open this post in threaded view
|

Re: Matlab ginput

John W. Eaton-6
In reply to this post by Ted.Harding
On  3-Dec-1996, Ted Harding <[hidden email]> wrote:

: With regard to the other query from Jay St Pieere ("I wonder how hard it
: would be to make a modification to the gnuplot source code to allow it to
: support a ginput interface"), my guess is that this might be
: possible.

Yes.  For an example of something like this, you might look at
ftp://ftp.ma.utexas.edu/pub/mzou/XPLOT.tgz.  I'm not suggesting that
this is the right thing for Octave, just that modifying gnuplot to
have a more extensive X interface is certainly possible.

: Therefore I warmly welcome John's announced intention to develop octave
: graphics in a new direction, and will be happy to help as best I
: can.

Anyone who is interested in discussing implementation details of new
graphics and GUI tools for Octave is welcome to join a mailing list
that I have set up for that purpose.  Just send me mail to join.

Thanks,

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Matlab ginput

niles-5
> : Therefore I warmly welcome John's announced intention to develop octave
> : graphics in a new direction, and will be happy to help as best I
> : can.
>
> Anyone who is interested in discussing implementation details of new
> graphics and GUI tools for Octave is welcome to join a mailing list
> that I have set up for that purpose.  Just send me mail to join.

Yes! Please check out

http://axp745.gsfc.nasa.gov/java/XYPlot/

(make sure you try all three mouse buttons...)

It's something I whipped up in a few days of Java...  But I really
think Java is the way to go!!  It's system independent so the GUI will
theoretically work under all OS's.  MS is already causing
problems...but I don't think that's a show stopper.  Java is cool
too..  Better Object orientated that C++ (IMHO).  It's somewhat
slow but really not too bad.. and we could work out a Web server
based Octave...for education and demos!

I know some people had there heart set on Tk, but I really think this
will be more portable and in the tradition of Octave's cutting
edge...(I'd guess C++ was somewhat new when jwe started), and OO
design.  Of course, I know little of Tk so I'm prepared to be flamed..
but let's kill the Tcl idea already..it's a minor scripting language.

        Rick Niles.


Reply | Threaded
Open this post in threaded view
|

Re: Matlab ginput

John W. Eaton-6
On  2-Dec-1996, [hidden email] <[hidden email]> wrote:

: Please check out
:
: http://axp745.gsfc.nasa.gov/java/XYPlot/
:
: (make sure you try all three mouse buttons...)

I see that the middle and left mouse buttons allow zooming and
extraction of coordinates.  What is the first mouse button supposed to
do?

: It's something I whipped up in a few days of Java...  But I really
: think Java is the way to go!!

: I know some people had there heart set on Tk, but I really think this
: will be more portable

Since things are likely to change, I'm planning on making it as easy
as possible for people to use different graphics packages and toolkits
with Octave.  My first implemenation will probably use plplot and
Tcl/Tk not because I think they are perfect, but because I think it
will be possible to implement most of the important features that
people seem to want.  Also, I believe that they will probably work
well together (plplot already has an interface to Tcl/Tk).

I'm not proposing that Octave users start writing Tcl/Tk code directly
to manipulate GUI and graphics objects.  That would be a mistake,
because it would make it nearly impossible to switch to other GUI and
graphics toolkits later.  Instead, Octave users will write code that
can be expected to work no matter what toolkit is actually being used.
I don't know yet exactly what the syntax and semantics will be.
Compatibility with Matlab is still a reasonable goal for GUI and
graphics objects, but get() and set() will probably not be the only
way to access graphics objects.  I think it makes more sense to take
advantage of Octave's data structure capabilities directly, but that
doesn't prevent writing some M-files to implement get() and set().

Again, if you would like to participate in discussions about the
details of the implementation, send me mail.

: (I'd guess C++ was somewhat new when jwe started)

According to The Design and Evolution of C++, Stroustrup started work
on C with Classes in 1979 (several years before I knew anything about
computing) and published the first edition of The C++ Programming
Language in late 1985.  I started working on some of the C++ classes
for Octave in the summer of 1991.  Full time work on the interpreter
began in February 1992.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: Matlab ginput

niles-5
> On  2-Dec-1996, [hidden email] <[hidden email]> wrote
:

>
> : Please check out
> :
> : http://axp745.gsfc.nasa.gov/java/XYPlot/
> :
> : (make sure you try all three mouse buttons...)
>
> I see that the middle and left mouse buttons allow zooming and
> extraction of coordinates.  What is the first mouse button supposed to
> do?
>

Well, it's already changed, but before it just "selected" the plot...
that is changed the background...it's useful for the implementation
of the rest of the application.

        Rick.