matplotlib-users Mailing List for matplotlib

Hi,

In 10/24/06, John Hunter <jdh...@ac...> wrote:
> >>>>> "Matthew" == Matthew Brett <mat...@gm...> writes:
>
>     Matthew> I attach a stack trace in case it's helpful.  Any
>     Matthew> pointers on where I should go for debugging further?

For completeness - it was specific to the WXAgg backend, and was
probably because I had installed a 32-bit wxPython rpm.  Recompling
the FC4 src rpm fixed it,

Thanks a lot,

Matthew

On Tue, Oct 24, 2006 at 08:49:19AM -0500, John Hunter wrote:
> >>>>> "Glen" == Glen W Mabey <Gle...@sw...> writes:
> 
>     Glen> Hello, I have been unable to discover in the docs a method
>     Glen> for discovering the exact size in pixels of an axes.
> 
>     Glen> The only way I have thought of is to get the size of the
>     Glen> canvas via FigureCanvas.get_width_height() and then multiply
>     Glen> by the results of axes.get_position(), but really I want to
>     Glen> have the exact size in pixels.
> 
> In [1]: ax = subplot(111)
> 
> In [2]: left, bottom, width, height = ax.bbox.get_bounds()
> 
> In [3]: print left, bottom, width, height
> 
> 80.0 48.0 496.0 384.0
> 
> However, this question looks like one that would be better answered by
> describing what you are trying to do.  There may be a more elegant
> solution using some of matplotlib's built-in coordinate systems which
> would prevent you from having to do raw pixel calculations, which is
> not usually what you want.  So you may want to describe your actual
> problem rather than your solution <wink>

Happy to do so, and I'm glad you asked.

I have recently been working on a project where I need to show a
spectrogram of some large data sets (200 million complex samples).
Directly using the specgram function is not a good idea, and I have come
to conclude that the traditional method for generating spectrograms is
inherently flawed.  That is, the MATLAB approach of generating a picture
based on the psd's and then display it using imshow is a hack.

I arrived at this conclusion through my work-around to generating
spectrograms for these large files.  What I did was to choose a number
of "data slice" to use, extract those at regular intervals throughout
the file, and then set overlap=0.

For example, if I wanted to use a 1024-point FFT, and if my axes is
about 500 pixels wide, then I would seek() through the file reading 1024
contiguous samples and then skipping 1./500-th of the total samples, and
reading in another slice.  I would end up with 500*1024 points, and pass
this data to specgram() with overlap=0.

Now, of course, there is a lot of information that was discarded, but it
made the implementation tractable.

I would propose that the loss associated with this method was comparable
to what is lost when the entire data set is used and then an image
resize algorithm (hardly appropriate for this type of thing, IMHO)
averages out a tremendous amount of the computations that were
performed.

As I started to think about it, I concluded that the other extreme
applies.  For short data sets, it is much more appropriate to have the
overlap increase automatically than to use an image interpolation
function.  

The case of operating on large data sets then corresponds to a negative
overlap.

I recall one technical review I was in where the presenter was
displaying a spectrogram in MATLAB.  He pointed out a visible feature
and then zoomed in on it.  It was a large data set, and when it finished
drawing, the feature was no longer visible -- very strange, and
frustrating to the presenter!  I then began to wonder about the
appropriateness of treating a spectrogram like a picture.

Not to imply that there wouldn't be anomalies like this with this
"auto-overlap" approach, but certainly it seems (to me) like a more 
rational approach to this signal processing operation.

So, I'm hoping to find time on my current project to implement this type
of functionality.  In my mind the FFT size would still be selected as a
parameter, so that power-of-2 implementations are used..  Granted, there 
would be averaging going on along the vertical axis, I just propose that 
better 1 than 2: the number of psd's performed would correspond exactly 
to the horizontal dimension of the drawing area, so no resampling would 
be required along that axis.

When the axes is resized, psd's would have to be recomputed, but what is
displayed on the screen would more closely related to the result of the
transforms performed.

Zooming would also necessitate recomputation of the psd's.  My idea for
smooth zooming (dragging with right mouse button in pylab) was to keep
the existing functionality, until the mouse is released, at which time
the psd's would be recomputed, but only for the segment of the data that
corresponds to the visible portion of the horizontal axis.  Same thing
for panning around this zoomed image: don't recalculate anything until
the user releases the mouse button.  

This would obviously be a more complicated implementation, and I'm not
suggesting that the current specgram implementation is useless.  This
alternate approach has served me well so far, and being able to extract
the size of the axes will make things more efficient.

Thanks for listening and for the tip.

Best Regards,
Glen Mabey

Does anyone have experience in what settings to use
to create matplotlib images such that they will display
well in a webpage - the ones I have are typically
square, or 3:2 ratio or 2:1 ration (length:height).

What output settings work well so that the images look
good on screen and when printed out (typically to a 
hi-res mono laser)?

Thanks!
Derek

-- 
This message is subject to the CSIR's copyright, terms and conditions and
e-mail legal notice. Views expressed herein do not necessarily represent the
views of the CSIR.
 
CSIR E-mail Legal Notice
http://mail.csir.co.za/CSIR_eMail_Legal_Notice.html 
 
CSIR Copyright, Terms and Conditions
http://mail.csir.co.za/CSIR_Copyright.html 
 
For electronic copies of the CSIR Copyright, Terms and Conditions and the CSIR
Legal Notice send a blank message with REQUEST LEGAL in the subject line to
Cal...@cs....


This message has been scanned for viruses and dangerous content by MailScanner, 
and is believed to be clean.

>>>>> "Matthew" == Matthew Brett <mat...@gm...> writes:

    Matthew> I attach a stack trace in case it's helpful.  Any
    Matthew> pointers on where I should go for debugging further?

Hey Matthew

See the instructions in SEGFAULTS in the root mpl dir -- it will tell
you how to proceed to get more better diagnostic information.

JDH

Hi,

I'm getting a segfault on show():

[mb312@foundmachine tmp]$ python
Python 2.4.3 (#1, Jun 13 2006, 16:41:45)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from pylab import *
/home/mb312/lib64/python2.4/site-packages/numpy/ctypeslib.py:12:
UserWarning: All features of ctypes interface may not work with ctypes
< 1.0.1
  warnings.warn("All features of ctypes interface may not work with " \
>>> plot([1,2,3])
[<matplotlib.lines.Line2D instance at 0x2aaab27f1170>]
>>> show()
Segmentation fault

This is current SVN of numpy and matplotlib, deleted build directories and all:
In [2]: matplotlib.__version__
Out[2]: '0.87.6'
In [5]: numpy.__version__
Out[5]: '1.0.dev3390'

FC4 x86_64:
Linux foundmachine 2.6.17-1.2142_FC4 #1 Tue Jul 11 22:41:06 EDT 2006
x86_64 x86_64 x86_64 GNU/Linux

Output of --verbose-helpful:

matplotlib data path
/home/mb312/lib64/python2.4/site-packages/matplotlib/mpl-data
$HOME=/home/mb312
CONFIGDIR=/home/mb312/.matplotlib
loaded rc file /home/mb312/.matplotlib/matplotlibrc
matplotlib version 0.87.6
verbose.level helpful
interactive is False
platform is linux2
/home/mb312/lib64/python2.4/site-packages/numpy/ctypeslib.py:12:
UserWarning: All features of ctypes interface may not work with ctypes
< 1.0.1
  warnings.warn("All features of ctypes interface may not work with " \
numerix numpy 1.0.dev3390
font search path
['/home/mb312/lib64/python2.4/site-packages/matplotlib/mpl-data']
loaded ttfcache file /home/mb312/.matplotlib/ttffont.cache
backend WXAgg version 2.4.2.4u

I attach a stack trace in case it's helpful.  Any pointers on where I
should go for debugging further?

Thanks a lot,

Matthew

>>>>> "Glen" == Glen W Mabey <Gle...@sw...> writes:

    Glen> Hello, I have been unable to discover in the docs a method
    Glen> for discovering the exact size in pixels of an axes.

    Glen> The only way I have thought of is to get the size of the
    Glen> canvas via FigureCanvas.get_width_height() and then multiply
    Glen> by the results of axes.get_position(), but really I want to
    Glen> have the exact size in pixels.

In [1]: ax = subplot(111)

In [2]: left, bottom, width, height = ax.bbox.get_bounds()

In [3]: print left, bottom, width, height

80.0 48.0 496.0 384.0

However, this question looks like one that would be better answered by
describing what you are trying to do.  There may be a more elegant
solution using some of matplotlib's built-in coordinate systems which
would prevent you from having to do raw pixel calculations, which is
not usually what you want.  So you may want to describe your actual
problem rather than your solution <wink>

JDH

Hello,

I have been unable to discover in the docs a method for discovering the
exact size in pixels of an axes.

The only way I have thought of is to get the size of the canvas via
FigureCanvas.get_width_height() and then multiply by the results of
axes.get_position(), but really I want to have the exact size in pixels.

Thank you,
Glen Mabey

>>>>> "Willi" == Willi Richert <w.r...@gm...> writes:

    Willi> Hi, even with the newest version the problem remains,
    Willi> unless I put the set_ylim() command _after_ plot(). Why?

Quoting myself from my first post in this thread

  1) you are calling set_ylim before a plot command and the autoscaler
     is kicking on the plot command and overriding your changes.  You
     should call set_ylim after all plot commands, or turn autoscaling
     off with the autoscale_on property of the Axes

Hi,

even with the newest version the problem remains, unless I put the set_ylim() 
command  _after_  plot(). Why?

Am Samstag, 21. Oktober 2006 20:30 schrieb Eric Firing:
> Willi Richert wrote:
> > Am Freitag, 20. Oktober 2006 17:31 schrieb John Hunter:
> >> from pylab import *
> >>
> >> ax1 = subplot(111)
> >> t = arange(0.01, 10.0, 0.01)
> >> s1 = exp(t)
> >> plot(t, s1, 'b-')
> >> xlabel('time (s)')
> >> ylabel('exp')
> >>
> >>
> >> # turn off the 2nd axes rectangle with frameon kwarg
> >> ax2 = twinx()
> >> s2 = sin(2*pi*t)
> >> plot(t, s2, 'r.')
> >> ylabel('sin')
> >> ax2.yaxis.tick_right()
> >> ax2.set_ylim(ymin=-3)
> >> show()
> >
> > Hi,
> >
> > this example does not work for me: Right axis is in the range [-1, 1].
> > (The same as the example two_axes.py with an additional set_ylim in my
> > previous mail. Sorry for the sparse information.)
> >
> > matplotlib.__version__ == 0.82
>
> There is the problem: you need to update your matplotlib.
>
> Eric

wr

Woops -- sent from the wrong email address ... here's a reply for the  
list:

On Oct 24, 2006, at 12:04 AM, Steve Lianoglou wrote:

>> Once when I found that NumPy released its version 1.0rc3,
>> I happily upgraded NumPy from 1.0rc1 to 1.0rc3 under WindowsXP.
>> A nightmare just happened. Matplotlib failed to run with NumPy 1.0  
>> rc3,
>> and I cannot found a NumPy 1.0rc1 on its download page.
>> Will matplotlib upgrade for NumPy 1.0rc3?
>> What can I do for this?
>
> One thing you can do is read some of the emails about this subject  
> that were just posted a few hours ago :-)
>
>
> ... or, if you're looking for some constructive suggestions, you can:
>
> 1) Probably compile both from their recent svn checkouts and they  
> should work fine.
> 2) You can get rc1 of numpy by playing with the url from the  
> sourceforge d/l page.
> It looks like this will get you an rc1 binary for windows:
> http://prdownloads.sourceforge.net/numpy/numpy-1.0rc1.win32- 
> py2.3.exe?download
>
> Hope that helps,
> -steve

> Once when I found that NumPy released its version 1.0rc3,
> I happily upgraded NumPy from 1.0rc1 to 1.0rc3 under WindowsXP.
> A nightmare just happened. Matplotlib failed to run with NumPy 1.0  
> rc3,
> and I cannot found a NumPy 1.0rc1 on its download page.
> Will matplotlib upgrade for NumPy 1.0rc3?
> What can I do for this?

One thing you can do is read some of the emails about this subject  
that were just posted a few hours ago :-)


... or, if you're looking for some constructive suggestions, you can:

1) Probably compile both from their recent svn checkouts and they  
should work fine.
2) You can get rc1 of numpy by playing with the url from the  
sourceforge d/l page.
It looks like this will get you an rc1 binary for windows:
http://prdownloads.sourceforge.net/numpy/numpy-1.0rc1.win32-py2.3.exe? 
download

Hope that helps,
-steve

Once when I found that NumPy released its version 1.0rc3,
I happily upgraded NumPy from 1.0rc1 to 1.0rc3 under WindowsXP.
A nightmare just happened. Matplotlib failed to run with NumPy 1.0 rc3,
and I cannot found a NumPy 1.0rc1 on its download page.
Will matplotlib upgrade for NumPy 1.0rc3?
What can I do for this?
Grateful to any suggestion.
Thanks

Chris S wrote:
>> I think that 97.6 was compiled against 1.0rc2 but Charlie Moad is the
>> authority on this since he did the compile.  I have added this "news
>> flash" to the site
> 
> Ok, thanks. I suspected that, but since even Google isn't able to find
> an rc2 binary, I guess my only option is to wait for a compatible
> Matplotlib to be released.
> 
> On a loosely-related topic, I originally tried upgrading to try out
> pylab.quiver. In earlier versions, the arrows drawn by quiver could
> not be properly scaled and were rendered at a huge size. Do you know
> if this was a registered bug, and if it's been fixed?

There is a complete re-implementation of quiver with correct scaling and 
control over arrow shape, size, color, and outline.

Eric

I was thinking of something like this - it isn't pretty, but it does  
get all the data on the page.


import pylab

# Annoying-to-plot data
data=[1]*100 + [2]*3 + [3]*2+ [4]*3 + [5]

# Make a histogram out of the data in x and prepare a bar plot.
top = pylab.subplot(211)
vals, bins, patchs = pylab.hist(data)

# but only show the top fraction of the graph in the upper plot
top.set_ylim(max(vals)-2, max(vals)+2)

bot = pylab.subplot(212)
vals, bins, patchs=pylab.hist(data)
bot.set_ylim(0,4)

pylab.show()

The latest word on the numpy list is that numpy-1.0 is coming out on
Wednesday.  I suggest waiting until the final 1.0 release is out
before we do a new matplotlib build.  I will try to push a build asap
after that.  Are there any show stoppers lingering that would delay a
release?  I would also suggest we refrain from any major commits.

Charlie