matplotlib-devel Mailing List for matplotlib

>>>>> "Robert" == Robert Kern <rk...@uc...> writes:

    Sascha> I am writing a web server app that creates charts among
    Sascha> other things. I am trying to get rid of the temporary file
    Sascha> that I use to transmit the figures created with matplotlib
    Sascha> to the actual web server. Although print_figure says "If
    Sascha> filename is a fileobject, write png to file object (thus
    Sascha> you can, for example, write the png to stdout)" I can't
    Sascha> successfully write anything to stdout. Anyone knows an
    Sascha> example or can give me some hint what I can do to get rid
    Sascha> of the tempfile?
    >>  Short answer: no known way to do this currently, though we'd
    >> like to figure it out.  As far as I know (and could very well
    >> be wrong) libpng requires a FILE*, which StringIO and cStringIO
    >> do not provide.

    Robert> StringIO isn't the issue here; being able to write to
    Robert> sys.stdout, which ought to have a valid FILE* underneath,
    Robert> is the issue.

Thanks for reminding me about this.  I thought it was possible to do
this, but had managed to forget

    import sys
    from pylab import plot, savefig, show
    plot([1,2,3])
    savefig(sys.stdout)
    show()

which I run with 

  > python test.py -dAgg > test.png

produces the expected figure.

JDH

Hi,

On Tue, 30 Aug 2005, Ken McIvor wrote:

> On Aug 30, 2005, at 10:45 AM, Arnd Baecker wrote:
> > I would have thought so as well. However I get:
> <snip>
> > A search for wxPython.h on
> > http://www.debian.org/distrib/packages#search_packages
> > gives no hits.
>
> Sorry, due to a lack of coffee this morning I misread "wxPython.h" as
> "wxWidgets.h" or something daft, yielding the kneejerk "install the
> -dev package" response.
>
> I wasn't aware of this situation, but it has the potential to be a big
> problem for me at work, where we primarily run Debian.  I have emailed
> Ron Lee, the wxgtk2.4 package maintainer, about the situation.  We'll
> see what he has to say on the matter.

Excellent - I was thinking about doing the same.

> > I agree. I wonder if anything improved with wx2.6? (for our
> > PlottingCanvas
> > we even dared to keep drawing DCs around, and it works without
> > problems...)
>
> What PlottingCanvas is this?  I'd be interested in seeing what
> optimizations you guys performed, if the source is available.

http://www.physik.tu-dresden.de/~baecker/python/plot.html

One of our main goals was to plot many points quickly,
in such a way that one appears
after another to get a "dynamic" appearance.
See http://www.physik.tu-dresden.de/~baecker/python/StandardMap.py
as an example.
(note that it still uses the old wx style...)

[...]

> > However, we are currently investigating to use
> > matplotlib for
> > a computational physics course (which will be next summer) and many of
> > the
> > students have *much* slower machines. So we need maximum speed but
> > with a
> > minimum of coding hassle (around 30% of the students have never
> > programmed
> > before ...).
>
> Just leveling the playing field between WXAgg and GtkAgg is exciting
> for me, because that means that future efforts at general optimization
> will net a bigger speed improvement for WXAgg.
>
> I'd imagine the plotting speed will be good enough for something along
> the lines of interactive plotting with iPython or visualizing results
> with pylab.

We have just finished the conversion of all exercices
of our course from scipy.xplt (aka pygist) to matplotlib.
Unfortunately, quite a few are prohibitively slow, even
on our fast machines. But we have some ideas
on possible improvements (both on the side of our code
and on the side of matplotlib) - this is going to be
separate thread though ;-)

> Speaking as a recent survivor of a computational physics
> class, I expect you to see a huge benefit from using Python as the
> language and matplotlib as the visualization, especially if you have
> students who have never programmed before.

I absolutely agree - we have been running our course now
for the third year, so far with scipy and scipy.xplt as plotting
programm. We had very positive feedback (of course,
those who never programmed before, had to work harder ;-).
Just in case: http://www.comp-phys.tu-dresden.de/cp2005/,
however the material (apart from the FAQ) is in German.

Best,

Arnd

On Tue, 2005-08-30 at 21:16 -0700, Robert Kern wrote:
> Why not use PIL where it's available? backend_agg2.py has a start at
> this. Here's a slightly more fleshed-out (but untested) implementation
> for backend_agg.py :
> 
>   if not is_string_like(filename):
>       try:
>           import Image
>           have_pil = True
>       except ImportError:
>           have_pil = False
>       if have_pil:
>           img = Image.frombuffer('RGBA', (self.width, self.height),
>                                  self.buffer_rgba(0, 0))
>           img.write(filename)
>       else:
>           self.renderer._renderer.write_png(filename)

I've previously had a problem with the origin when doing something
similar with buffer_rgba (resulting in a vertical flip).  Doing:

            im = Image.frombuffer('RGBA', (self.width, self.height),
                                  self.buffer_rgba(0, 0),
                                  'raw', 'RGBA', 0, 1)

fixes that problem.

If a method utilising PIL images in this manner is added I'd suggest
adding a to_pil (or similar) method for those who want to process the
resulting image in some manner requiring PIL.

Nick

On Tue, 30 Aug 2005, Ken McIvor wrote:

[...]

> 	# assuming z0 is the initial MxN array that is being decayed...
> 	z_min = min(nx.minimum.reduce(z0))
> 	z_max = max(nx.maximum.reduce(z0))
> 	image = axes.imshow(z0, vmin=z_min, vmax=z_max)
>
> As an aside: I'd love to hear if anyone knows of a nicer way to get
> Numeric to give you the minimum value of a matrix.

What about:
   z_min=min(ravel(z0))

In [3]:Numeric.ravel?
    ravel(m) returns a 1d array corresponding to all the elements of it's
    argument.

OTOH, I am not sure, if the usage of min (which is a python builtin,
operating on sequences) does not cost some performance.
So maybe

  z_min = nx.minimum.reduce(nx.ravel(z0))

is more efficient?

Best,

Arnd

Thanks! Great catch. Sadly, I have been bitten by this before, but had 
completely forgotten about it. I've switched to just doing vmin=0, 
vmax=1, as I know the range before hand.

Abe

Ken McIvor wrote:

> On Aug 30, 2005, at 10:29 PM, John Hunter wrote:
>
>> I suggest you follow pick through set_data and make_image in the image
>> module to see if you can sort out what is going wrong.  Alternatively,
>> if you post an example then I can take a look.
>
>
> I've done Abraham's work for him this time, and attached an example 
> which demonstrates behavior that he *may* be seeing.
>
> The problem is that the minimum and maximum values of the image are 
> determined every time the image is asked to draw itself (in 
> matplotlib.image.AxesImage.__draw()).  I assume that what's happening 
> is that the colors aren't fading down the color ramp as the values 
> decay, but are rather staying constant or blurring a little.
>
> This happens because the color ramp is being applied across the 
> current minimum and maximum of the data, rather than across some 
> absolute scale.  The solution to this (see the attached script for the 
> example) is to specify a vmin and vmax, which will pin the top and 
> bottom of the color ramp to those values:
>
>     # assuming z0 is the initial MxN array that is being decayed...
>     z_min = min(nx.minimum.reduce(z0))
>     z_max = max(nx.maximum.reduce(z0))
>     image = axes.imshow(z0, vmin=z_min, vmax=z_max)
>
> As an aside: I'd love to hear if anyone knows of a nicer way to get 
> Numeric to give you the minimum value of a matrix.
>
> Ken

John Hunter wrote:
>>>>>>"Sascha" == Sascha  <sas...@gm...> writes:
> 
> 
>     Sascha> I am writing a web server app that creates charts among
>     Sascha> other things. I am trying to get rid of the temporary file
>     Sascha> that I use to transmit the figures created with matplotlib
>     Sascha> to the actual web server. Although print_figure says "If
>     Sascha> filename is a fileobject, write png to file object (thus
>     Sascha> you can, for example, write the png to stdout)" I can't
>     Sascha> successfully write anything to stdout. Anyone knows an
>     Sascha> example or can give me some hint what I can do to get rid
>     Sascha> of the tempfile?
> 
> Short answer: no known way to do this currently, though we'd like to
> figure it out.  As far as I know (and could very well be wrong)
> libpng requires a FILE*, which StringIO and cStringIO do not provide.

StringIO isn't the issue here; being able to write to sys.stdout, which
ought to have a valid FILE* underneath, is the issue.

Why not use PIL where it's available? backend_agg2.py has a start at
this. Here's a slightly more fleshed-out (but untested) implementation
for backend_agg.py :

  if not is_string_like(filename):
      try:
          import Image
          have_pil = True
      except ImportError:
          have_pil = False
      if have_pil:
          img = Image.frombuffer('RGBA', (self.width, self.height),
                                 self.buffer_rgba(0, 0))
          img.write(filename)
      else:
          self.renderer._renderer.write_png(filename)


-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter

On Aug 30, 2005, at 10:29 PM, John Hunter wrote:
> I suggest you follow pick through set_data and make_image in the image
> module to see if you can sort out what is going wrong.  Alternatively,
> if you post an example then I can take a look.

I've done Abraham's work for him this time, and attached an example 
which demonstrates behavior that he *may* be seeing.

The problem is that the minimum and maximum values of the image are 
determined every time the image is asked to draw itself (in 
matplotlib.image.AxesImage.__draw()).  I assume that what's happening 
is that the colors aren't fading down the color ramp as the values 
decay, but are rather staying constant or blurring a little.

This happens because the color ramp is being applied across the current 
minimum and maximum of the data, rather than across some absolute 
scale.  The solution to this (see the attached script for the example) 
is to specify a vmin and vmax, which will pin the top and bottom of the 
color ramp to those values:

	# assuming z0 is the initial MxN array that is being decayed...
	z_min = min(nx.minimum.reduce(z0))
	z_max = max(nx.maximum.reduce(z0))
	image = axes.imshow(z0, vmin=z_min, vmax=z_max)

As an aside: I'd love to hear if anyone knows of a nicer way to get 
Numeric to give you the minimum value of a matrix.

Ken

>>>>> "Abraham" == Abraham Schneider <ab...@cn...> writes:

    Abraham> I haven't had time to do a full search yet, but was
    Abraham> hoping someone might at least have an idea of where to
    Abraham> begin to look. My current suspicions is that there might
    Abraham> be a caching issue.

It could be -- the image module does do some caching.  But im.set_data
*does* clear the cache with 

        self._imcache =None

I suggest you follow pick through set_data and make_image in the image
module to see if you can sort out what is going wrong.  Alternatively,
if you post an example then I can take a look.

JDH

Sorry, realized I was a little vague. When I say, 'choppy', I mean that 
some cells won't get updated. If there is a lot of activity everything 
looks like, but once activity dies down, some elements stay on in 
various stages (somewhat like bad pixels).

Abraham Schneider wrote:

> Hi. Sorry if this was covered already, but I ran into a recent problem 
> with animating an image using GTKAgg (and matplotlib 0.83.2). In my 
> update_fig() function, I do:
>
> im.set_data(g)
> manager.canvas.draw()
>
> where g is some arbritrary 20x20 array. Over time it's elements will 
> be set to 1, and then decay exponentially. For the majority of the 
> time the array contains all 0s. Under these conditions, it gets very 
> choppy, and skips a large number of frames.
>
> If I do something like: g[0, 0] = 1, then the animation runs smoothly, 
> and looks like it's supposed to (except I now have one cell in the 
> grid set the an incorrect value.
>
> I haven't had time to do a full search yet, but was hoping someone 
> might at least have an idea of where to begin to look. My current 
> suspicions is that there might be a caching issue.
>
> Thanks,
>
> Abe
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle 
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing 
> & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi. Sorry if this was covered already, but I ran into a recent problem 
with animating an image using GTKAgg (and matplotlib 0.83.2). In my 
update_fig() function, I do:

im.set_data(g)
manager.canvas.draw()

where g is some arbritrary 20x20 array. Over time it's elements will be 
set to 1, and then decay exponentially. For the majority of the time the 
array contains all 0s. Under these conditions, it gets very choppy, and 
skips a large number of frames.

If I do something like: g[0, 0] = 1, then the animation runs smoothly, 
and looks like it's supposed to (except I now have one cell in the grid 
set the an incorrect value.

I haven't had time to do a full search yet, but was hoping someone might 
at least have an idea of where to begin to look. My current suspicions 
is that there might be a caching issue.

Thanks,

Abe