matplotlib-users Mailing List for matplotlib (Page 7)

It seems that default backend for Windows binaries is TkAgg in Python 2.5 but
WXAgg in Python 2.6 (files from matplotlib/mpl-data in eggs are
different).So without WxPython (what is quite common) there is ImportError
with simple "from pylab import *".

It could be solved very simply and then everything is ok including saving of
png files.

Thank you,
Petr Marhoun


John Hunter-4 wrote:
> 
> The windows binaries for the latest matplotlib release are now
> available for download at
> 
>  
> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
> 
> for python2.5 and 2.6 (if you need 2.4 please respond here).  Sorry
> for the delay, but we hit a nasty python2.6/libpng/mingw that held us
> up.  Thanks to Christoph Gohlke
> for the visual studio builds and Charlie Moad for the MingW framework.
> 
> Please let us know if you have any troubles.
> 
> JDH
> 

-- 
View this message in context: http://www.nabble.com/matplotlib-0.98.5.3-windows-binaries-available-tp24023736p24035403.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

John,

I installed this on python 2.6.2 using the windows installer (the .exe) but
it crashes even on something as 
simple as importing pylab from the interactive prompt.  To make sure it
wasn't a conflict with other packages, I created a clean virtualenv
directory and installed matplotlib from the 2.6 egg, but the results are the
same.  Trying to run any matplotlib example immediately creates a windows
exception dialog.

Casey


John Hunter-4 wrote:
> 
> The windows binaries for the latest matplotlib release are now
> available for download at
> 
>  
> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
> 
> Please let us know if you have any troubles.
> 
> JDH
> 

-- 
View this message in context: http://www.nabble.com/matplotlib-0.98.5.3-windows-binaries-available-tp24023736p24033870.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

I installed the binaries using the .exe file on Python 2.6.2 but it throws a
windows exception when I try to do anything with matplotlib, even just
typing 'import pylab' in the python command interpreter.  To rule out any
conflicts, I created a python virtualenv directory and installed matplotlib
from the .egg file, but it still throws an exception every time.

Casey


John Hunter-4 wrote:
> 
> The windows binaries for the latest matplotlib release are now
> available for download at
> 
>  
> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
> 
> for python2.5 and 2.6.
> 

-- 
View this message in context: http://www.nabble.com/matplotlib-0.98.5.3-windows-binaries-available-tp24023736p24033941.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hi all,

In order to proceed with contacting speakers, we'd now like to get
some feedback from you.  This Doodle poll should take no more than a
couple of minutes to fill out (no password or registration required):

http://doodle.com/hb5bea6fivm3b5bk

So please let us know which topics you are most interested in, and
we'll do our best to accommodate everyone.  Keep in mind that speaker
availability and balancing out the topics means that the actual
tutorials offered probably won't be exactly the list of top 8 voted
topics, but the feedback will certainly help us steer the decision
process.

Thanks for your time,

Dave Peterson and Fernando Perez

On Mon, Jun 1, 2009 at 10:21 PM, Fernando Perez<fpe...@gm...> wrote:
> Hi all,
>
> The time for the Scipy'09 conference is rapidly approaching, and we
> would like to both announce the plan for tutorials and solicit
> feedback from everyone on topics of interest.
>
> Broadly speaking, the plan is something along the lines of  what we
> had last year: one continuous 2-day tutorial  aimed at introductory
> users, starting from the very basics, and in parallel a set of
> 'advanced' tutorials, consisting of a series of 2-hour sessions on
> specific  topics.
>
> We will request that the presenters for the advanced tutorials keep
> the 'tutorial' word very much in mind, so that the sessions really
> contain hands-on learning work and not simply a 2-hour long slide
> presentation.  We will  thus require that all the tutorials will be
> based on tools that the attendees can install at least 2 weeks in
> advance on all  platforms (no "I released it last night" software).
>
> With that in mind, we'd like feedback from all of you on possible
> topics for the advanced tutorials.  We have space for 8 slots total,
> and here are in no particular order some possible topics.  At this
> point there are no guarantees yet that we can get presentations for
> these, but we'd like to establish a first list of preferred topics to
> try and secure the presentations as soon as possible.
>
> This is simply a list of candiate topics that various people have
> informally suggested so far:
>
> - Mayavi/TVTK
> - Advanced topics in matplotlib
> - Statistics with Scipy
> - The TimeSeries scikit
> - Designing scientific interfaces with Traits
> - Advanced numpy
> - Sparse Linear Algebra with Scipy
> - Structured and record arrays in numpy
> - Cython
> - Sage - general tutorial
> - Sage - specific topics, suggestions welcome
> - Using GPUs with PyCUDA
> - Testing strategies for scientific codes
> - Parallel processing and mpi4py
> - Graph theory with Networkx
> - Design patterns for efficient iterator-based scientific codes.
> - Symbolic computing with sympy
>
> We'd like to hear from any ideas on other possible topics of interest,
> and we'll then run a doodle poll  to gather quantitative feedback with
> the final list of candidates.
>
> Many thanks,
>
> f
>

You might want to try setting the rcParam pdf.fonttype to 42 (i.e. 
TrueType mode), which will avoid font subsetting.

You may also want to try using the Ps backend, which does support 
Helvetica directly.  matplotlib ships all of the "standard" Ps font 
metrics as part of matplotlib.  Be sure to set ps.useafm to True.

Mike

On 06/14/2009 04:54 PM, per freem wrote:
> hello all,
>
> I make my figures in matplotlib and then output them (using savefig) 
> as .pdf.  I am using Fedora linux.
>
> When I try to edit the font in the figure to Helvetica using 
> Illustrator, I cannot. i am able to select the fonts, e.g. labels on 
> the axes of the figure, but when i try to change the font it does not 
> work. apparently the font information has been lost.
>
> is there a way to make the .pdf file contain the font? or is the 
> solution to export it as a different file format (if so which)?
>
> p.s. i do not have helvetica on the system that generates the plots so 
> i cannot set it programmatically... this is why i export it using the 
> default matplotlib font and then try to edit it in illustrator.
>
> thanks.
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>    

On 06/12/2009 05:27 PM, Zane Selvans wrote:
> If I set path.simplify: False, the shape of the gaps between the
> filled polygons does change.  Instead of being irregular, it becomes
> an infinitessimally thin gap of uniform width, allowing the (in this
> case white) background to show through.
>    
Just to clarify, these backs only show with the Mac OS-X gui window, not 
with the PNG or PDF output (which are actually handled by the Agg and 
PDF backends respectively, and don't use the Cocoa/Quartz-specific code 
in the macosx backend).

If that's the case, I'll forward this thread to the attention of Michiel 
de Hoon, the author of the macosx backend.

As for path.simplify = True causing irregular gaps, that's my area, and 
I'll look into that further.  path.simplify should not be creating 
visible artifacts (at least in raster images such as PNG), so that's a bug.

Cheers,
Mike
> In both of these cases (path.simplify: True|False), the PNG version of
> the same figures also show representations of these gaps which are
> identical to those which appear in the PDF (though obviously
> pixelated), so I don't think it's something that's wrong in the vector
> graphics code per se.
>
> Zane
>
> On Fri, Jun 12, 2009 at 11:46 AM, Michael Droettboom<md...@st...>  wrote:
>    
>> Shot in the dark here, but what if you set the rcParam "path.simplify" to
>> False?  There have been recent changes to that code.
>>
>> Also, since the Agg backend doesn't have an associated GUI, you need to use
>> the savefig() command and provide a filename, rather than using show().
>>
>> Cheers,
>> Mike
>>
>> Zane Selvans wrote:
>>      
>>> Um, yeah.  So my response got bounced because of the attachment.  Take 2:
>>>
>>> For some reason my script bombed when I switched to the Agg backend,
>>> trying to display to the screen (it said Figure has no method show())
>>>
>>> So I output the plot as both a PDF and a PNG (still having backend:
>>> agg in my rcfile) and in both of those cases, irregular gaps are
>>> visible between the polygons making up the filled contours.  This
>>> wasn't the case with my previously installed setup.  It looks as if
>>> for some reason the vertices of the filled polygons are being
>>> calculated differently from different sides of the same contour,
>>> leading to overlap in some places, and gaps in others.  You can download
>>> the PDF version (in which the exact geometry is much clearer).
>>> from:
>>>
>>> http://zaneselvans.org/dropbox/LinDensity_Grid.pdf
>>>
>>> Zane
>>>
>>> On Fri, Jun 12, 2009 at 5:51 AM, Michael Droettboom<md...@st...>
>>> wrote:
>>>
>>>        
>>>> So you see this behavior if you switch to the Agg backend?  That's the
>>>> backend used to generate the images in the gallery.  If there's a
>>>> difference
>>>> there, that would seem to suggest some tweaking of the macosx backend
>>>> (which
>>>> is still relatively new) is in order.
>>>>
>>>> Mike
>>>>
>>>> Zane Selvans wrote:
>>>>
>>>>          
>>>>> I just installed the latest SciPy Superpack in order to get access to
>>>>> the scipy.spatial.KDTree class, and discovered that for some reason
>>>>> now when I use contourf() lines get drawn at the boundaries between
>>>>> the filled contours.  Additionally, there is always a single vertical
>>>>> line crossing from each contour boundary to the next.  I'm guessing
>>>>> that these are the edges of the filled polygons which are getting
>>>>> drawn.  This behavior doesn't seem to be consistent with the
>>>>> contourf() documentation and when I run code in griddata_demo.py it
>>>>> doesn't come out looking like the picture in the documentation/example
>>>>> gallery...
>>>>>
>>>>> Is anyone else seeing this behavior?  Is there a keyword I can use to
>>>>> force the edges of the polygons not to get drawn?
>>>>>
>>>>> This is on Mac OS X 10.5.7, with
>>>>> scipy.__version__ = 0.8.0.dev5635
>>>>> matplotlib.__version__ = 0.98.6svn
>>>>> numpy.__version__=1.4.0.dev6728
>>>>>
>>>>> As installed by superpack_2009.03.28.sh
>>>>> from http://macinscience.org/?page_id=6
>>>>>
>>>>> using:
>>>>> backend: macosx
>>>>>
>>>>> Cheers,
>>>>> Zane
>>>>>
>>>>>
>>>>>
>>>>>            
>>>> --
>>>> Michael Droettboom
>>>> Science Software Branch
>>>> Operations and Engineering Division
>>>> Space Telescope Science Institute
>>>> Operated by AURA for NASA
>>>>
>>>>
>>>>
>>>>          
>>>
>>>
>>>        
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>>      
>
>
>
>    

Hi

I am developing on a Desktop install Ubuntu 9.04 machine with matplotlib 0.98.5.2, 
and running the scripts on a Server install Ubuntu 8.10 machine with matplotlib 0.98.3.

I have found that the X axis layout for the same script varies between the two machines.
Both have standard matplotlib installs using apt-get. I haven't made any tweaks.

Rather than go into great detail about the problem, please see the script below and links to the resulting png files.
I hope the png files tell the story.

http://waka.freehostia.com/python/date_axis_scaling_test.py

http://waka.freehostia.com/python/date_axis_scaling_test_0_98_3.png

http://waka.freehostia.com/python/date_axis_scaling_test_0_98_5_2.png

The plot produced by matplotlib 0.98.3 isn't what I want.
Id like the plot to go edge to edge on the x axis grid, as the matplotlib 0.98.3 version does.

Help and advise would be appreciated.
PS : I'm new to python & matplotlib  

######################################################################################
#!/usr/bin/env python
import matplotlib
matplotlib.use('Agg')
import matplotlib.pyplot as plt
from datetime import datetime, timedelta

version   = matplotlib.__version__
HOURSBACK = 365 * 24
now       = datetime.now()
valueList = []
dateList  = []

for i in range(HOURSBACK):
    hoursBack = timedelta( hours = (HOURSBACK - i) )
    then = now - hoursBack
    valueList.append( i )
    dateList.append( then )

fig = plt.figure( figsize=(12, 9), dpi=100 )
ax  = fig.add_subplot(111)
ax.plot(dateList, valueList)
plt.title('Date axis scaling test for matplotlib version : %s' % ( version  ) )
plt.grid(True)
plt.ylabel('Widgets')
plt.xlabel('Date')
fig.autofmt_xdate()

plt.savefig( "date_axis_scaling_test_%s.png" % version.replace('.','_'), format='png' )    

quit()
######################################################################################


_________________________________________________________________
Get the best of MSN on your mobile
http://clk.atdmt.com/UKM/go/147991039/direct/01/

hello all,

I make my figures in matplotlib and then output them (using savefig) as
.pdf.  I am using Fedora linux.

When I try to edit the font in the figure to Helvetica using Illustrator, I
cannot. i am able to select the fonts, e.g. labels on the axes of the
figure, but when i try to change the font it does not work. apparently the
font information has been lost.

is there a way to make the .pdf file contain the font? or is the solution to
export it as a different file format (if so which)?

p.s. i do not have helvetica on the system that generates the plots so i
cannot set it programmatically... this is why i export it using the default
matplotlib font and then try to edit it in illustrator.

thanks.

On Fri, Jun 12, 2009 at 6:44 PM, Christoph Gohlke<cg...@uc...> wrote:
> Here are the Windows installer and egg produced by "setup.py bdist_wininst"
> respectively "setupegg.py bdist_egg":


Thanks Christoph -- I've uploaded these to the sf site.  After the
next trunk release, I may ask you again to provide some visual studio
builds if you have the time, since the mingw/python2.6 problems have
not been solved yet.

JDH

The windows binaries for the latest matplotlib release are now
available for download at

  https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194

for python2.5 and 2.6 (if you need 2.4 please respond here).  Sorry
for the delay, but we hit a nasty python2.6/libpng/mingw that held us
up.  Thanks to Christoph Gohlke
for the visual studio builds and Charlie Moad for the MingW framework.

Please let us know if you have any troubles.

JDH

Hey everyone,

this is more a how-to / feature request than a question... Normally, my
workflow for embedding images in LaTeX is as follows:

1) produce ps-file
2) use pstoedit (xfig) to separate text/math (LaTeX-typesettable) from
the image
3) save as pdf_t and pdf, respectively
4) \input this in the LaTeX document -- pdflatex will then set the text
at every compilation.

This has the advantage that I can change fonts etc without having to
redo all the figures.


I was trying to do so with matplotlib 0.98.3 and pstoedit 3.45 on a
64bit Ubuntu 8.10. I followed the instructions in the matplotlib
cookbook but kept experiencing problems when calling pstoedit [1], the
xlabels and ylabels were somehow converted to Courier but not put in the
"text" part, "." would become ":" and so on.

Solution brought this thread
http://www.nabble.com/Switching-between-different-font-settings-ts21279388.html
which suggested using OldScalarFormatter (thanks at this point also from
my side, Jouni) -- which works, see attached example.


So much for the "how-to-part" -- obviously, my suggestion is now to not
force users to have math-labels. I have to admit that I am not aware of
the drawbacks of OldScalarFormatter, but alone the name makes me think
that it might be not the best solution...


Thanks and best regards,
Sebastian.

P.S.: why actually does
ax.yaxis.get_ticklabels()[1].get_text()
return an empty string when called before savefig?

P.P.S.: I expect to be offline several days, so please excuse me if I
won't be answering timely.


[1]
pstoedit: version 3.45 / DLL interface 108 (build Jun 17 2008 - release
build - g++ 4.3.1) : Copyright (C) 1993 - 2007 Wolfgang Glunz
Warning: Level 2 version of image and imagemask not supported for this
backend (due to lack of support for bitmaps on intermediate files)
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font MCSZLR+CMMI12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font MCSZLR+CMMI12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font MCSZLR+CMMI12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font MCSZLR+CMMI12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.
Warning, unsupported font MCSZLR+CMMI12, using Courier instead.
Warning, unsupported font YBFHZA+CMR12, using Courier instead.

Thanks John.  This doesn't seem to be the cause of my problem, but I appreciate the correction.  I wasn't aware that this was such bad practice.  I guess it is better to import numpy and matplotlib functions separately then?  

Thanks again

--- On Fri, 6/12/09, John Hunter <jd...@gm...> wrote:

From: John Hunter <jd...@gm...>
Subject: Re: [Matplotlib-users] MPL with PyQt: different behavior on Windows  vs. Linux
To: "Steve Nicholes" <ema...@ya...>
Cc: mat...@li...
Date: Friday, June 12, 2009, 7:02 AM

On Wed, Jun 10, 2009 at 12:55 AM, Steve
Nicholes<ema...@ya...> wrote:
> Thanks John.  I hope you aren't receiving this reply twice (my email kicked
> me out when I hit send).  I actually am importing pylab so it isn't an
> entirely qt app.  I didn't post all of the code originally b/c it is long
> (and it would reveal how poor of a programmer I am :) ), but here are the
> relevant sections.  The problematic section is in blue.  Please let me know
> if you need anything else.

Importing pylab or pyplot into a GUI app is simply not supported.
There is never a reason to do it, and it is fraught with perils.  I
don't know if this has anything to do with the problem you are
experiencing, but you need to remove these imports before we can
proceed.

JDH



      

Thanks for the tip Darren.  Adding this line seems to have done the trick!  Very much appreciated.

--- On Fri, 6/12/09, Darren Dale <dsd...@gm...> wrote:

From: Darren Dale <dsd...@gm...>
Subject: Re: [Matplotlib-users] MPL with PyQt: different behavior on Windows  vs. Linux
To: "Steve Nicholes" <ema...@ya...>
Cc: mat...@li...
Date: Friday, June 12, 2009, 6:24 AM



On Tue, Jun 9, 2009 at 6:17 PM, Steve Nicholes <ema...@ya...> wrote:


Hi,

I am writing some code for automated testing via GPIB using MPL and PyQt.  To simulate automated data collection while debugging the program, I have added a for loop (see below) after reading in a data file that plots each point one by one.  When I run the program in Linux, I see each point appear on the canvas one by one as designed, but when I run the same code in Windows, nothing shows up on the canvas during the for loop.  Instead, once the loop has completed, all points appear simulataneously.  Is there any reason the why calls to canvas.draw() show nothing when run in Windows?  


I have seen similar discrepancies between PyQt4 behavior on linux and windows in a few situations. In my experience, a call to PyQt4.QtGui.qApp.processEvents() is sufficient to force an update in your view.


Darren




      

On Saturday 13 June 2009 22:14:47 Alan Jackson wrote:
> Any suggestions for turning a sequence of Matplotlib plots into a Flash
> movie, on Linux?
>
> I did just notice that R now has that capability built in. 8-)

Use mencoder to make a series of images into a video. Don't know if it 
supports flash. If not you can use ffmpeg to turn a video of a supported format 
into a flash .flv video.

http://ubuntuforums.org/showthread.php?t=499174 gives some hints to mencoder.

ffmpeg is pretty much just: ffmpeg -i in.avi out.flv

Best Regards
Troels Kofoed Jacobsen

Any suggestions for turning a sequence of Matplotlib plots into a Flash
movie, on Linux?

I did just notice that R now has that capability built in. 8-)

-- 
-----------------------------------------------------------------------
| Alan K. Jackson            | To see a World in a Grain of Sand      |
| al...@aj...          | And a Heaven in a Wild Flower,         |
| www.ajackson.org           | Hold Infinity in the palm of your hand |
| Houston, Texas             | And Eternity in an hour. - Blake       |
-----------------------------------------------------------------------

Hi,

I want to plot the evolution of an histogram in time. It is naturally an
histogram and not a continuous distribution -the quantities on the X
axis are discrete.

Is there a function that naturally does that? I now hack it using
contourf() and creating an appropriate matrix of "squares", each square
being a sub-matrix with the value of the bar, but the contourf()
interpolation makes it look not perfect.

Thanks!
M.

Here are the Windows installer and egg produced by "setup.py 
bdist_wininst" respectively "setupegg.py bdist_egg":

<http://www.lfd.uci.edu/~gohlke/download/matplotlib-0.98.5.3.win32-py2.6.exe.zip>

<http://www.lfd.uci.edu/~gohlke/download/matplotlib-0.98.5.3_r0-py2.6-win32.egg.zip>

The installer worked for me. I have not run the unit tests.

Here's the build output:

============================================================================
BUILDING MATPLOTLIB
             matplotlib: 0.98.5.3
                 python: 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC
                         v.1500 32 bit (Intel)]
               platform: win32
        Windows version: (6, 0, 6002, 2, 'Service Pack 2')

REQUIRED DEPENDENCIES
                  numpy: 1.3.0
              freetype2: found, but unknown version (no pkg-config)
                         * WARNING: Could not find 'freetype2' headers 
in any
                         * of '.', '.\freetype2'.

OPTIONAL BACKEND DEPENDENCIES
                 libpng: found, but unknown version (no pkg-config)
                         * Could not find 'libpng' headers in any of '.'
                Tkinter: no
                         * Tkinter present, but header files are not found.
                         * You may need to install development packages.
               wxPython: 2.8.10.1
                         * WxAgg extension not required for wxPython >= 2.8
                   Gtk+: no
                         * Building for Gtk+ requires pygtk; you must be 
able
                         * to "import gtk" in your build/install environment
        Mac OS X native: no
                     Qt: no
                    Qt4: Qt: 4.5.1, PyQt4: 4.5
                  Cairo: 1.4.12

OPTIONAL DATE/TIMEZONE DEPENDENCIES
               datetime: present, version unknown
               dateutil: matplotlib will provide
                   pytz: 2009d

OPTIONAL USETEX DEPENDENCIES
                 dvipng: no
            ghostscript: no
                  latex: no
                pdftops: no

[Edit setup.cfg to suppress the above messages]
============================================================================

Hope it helps.

Christoph


On 06/12/2009 12:45, John Hunter wrote:
> Thanks for this link -- the problem I am experiencing is specific to
> the mingw compiler suite, so the visual studio build should work fine.
>   Would you be willing to build a bdist installer and an egg for us
> while we are trying to sort the mingw problems out -- I think all you
> need to do is pass bdist_wininst and bdist_egg to your build command.
>
> JDH
>
>

I switched back to using the macosx backend, and it turns out that the
thin black lines surrounding the polygons (including crossing the
filled contour regions from one closed contour to another) only get
displayed in the GUI.  PDF and PNG output look fine.

Zane

On Fri, Jun 12, 2009 at 2:27 PM, Zane Selvans<za...@id...> wrote:
> If I set path.simplify: False, the shape of the gaps between the
> filled polygons does change.  Instead of being irregular, it becomes
> an infinitessimally thin gap of uniform width, allowing the (in this
> case white) background to show through.
>
> In both of these cases (path.simplify: True|False), the PNG version of
> the same figures also show representations of these gaps which are
> identical to those which appear in the PDF (though obviously
> pixelated), so I don't think it's something that's wrong in the vector
> graphics code per se.
>
> Zane
>
> On Fri, Jun 12, 2009 at 11:46 AM, Michael Droettboom<md...@st...> wrote:
>> Shot in the dark here, but what if you set the rcParam "path.simplify" to
>> False?  There have been recent changes to that code.
>>
>> Also, since the Agg backend doesn't have an associated GUI, you need to use
>> the savefig() command and provide a filename, rather than using show().
>>
>> Cheers,
>> Mike
>>
>> Zane Selvans wrote:
>>>
>>> Um, yeah.  So my response got bounced because of the attachment.  Take 2:
>>>
>>> For some reason my script bombed when I switched to the Agg backend,
>>> trying to display to the screen (it said Figure has no method show())
>>>
>>> So I output the plot as both a PDF and a PNG (still having backend:
>>> agg in my rcfile) and in both of those cases, irregular gaps are
>>> visible between the polygons making up the filled contours.  This
>>> wasn't the case with my previously installed setup.  It looks as if
>>> for some reason the vertices of the filled polygons are being
>>> calculated differently from different sides of the same contour,
>>> leading to overlap in some places, and gaps in others.  You can download
>>> the PDF version (in which the exact geometry is much clearer).
>>> from:
>>>
>>> http://zaneselvans.org/dropbox/LinDensity_Grid.pdf
>>>
>>> Zane
>>>
>>> On Fri, Jun 12, 2009 at 5:51 AM, Michael Droettboom<md...@st...>
>>> wrote:
>>>
>>>>
>>>> So you see this behavior if you switch to the Agg backend?  That's the
>>>> backend used to generate the images in the gallery.  If there's a
>>>> difference
>>>> there, that would seem to suggest some tweaking of the macosx backend
>>>> (which
>>>> is still relatively new) is in order.
>>>>
>>>> Mike
>>>>
>>>> Zane Selvans wrote:
>>>>
>>>>>
>>>>> I just installed the latest SciPy Superpack in order to get access to
>>>>> the scipy.spatial.KDTree class, and discovered that for some reason
>>>>> now when I use contourf() lines get drawn at the boundaries between
>>>>> the filled contours.  Additionally, there is always a single vertical
>>>>> line crossing from each contour boundary to the next.  I'm guessing
>>>>> that these are the edges of the filled polygons which are getting
>>>>> drawn.  This behavior doesn't seem to be consistent with the
>>>>> contourf() documentation and when I run code in griddata_demo.py it
>>>>> doesn't come out looking like the picture in the documentation/example
>>>>> gallery...
>>>>>
>>>>> Is anyone else seeing this behavior?  Is there a keyword I can use to
>>>>> force the edges of the polygons not to get drawn?
>>>>>
>>>>> This is on Mac OS X 10.5.7, with
>>>>> scipy.__version__ = 0.8.0.dev5635
>>>>> matplotlib.__version__ = 0.98.6svn
>>>>> numpy.__version__=1.4.0.dev6728
>>>>>
>>>>> As installed by superpack_2009.03.28.sh
>>>>> from http://macinscience.org/?page_id=6
>>>>>
>>>>> using:
>>>>> backend: macosx
>>>>>
>>>>> Cheers,
>>>>> Zane
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Michael Droettboom
>>>> Science Software Branch
>>>> Operations and Engineering Division
>>>> Space Telescope Science Institute
>>>> Operated by AURA for NASA
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>
>
>
> --
> Zane A. Selvans
> Amateur Earthling
> http://zaneselvans.org
> +1 303 815 6866
>



-- 
Zane A. Selvans
Amateur Earthling
http://zaneselvans.org
+1 303 815 6866

If I set path.simplify: False, the shape of the gaps between the
filled polygons does change.  Instead of being irregular, it becomes
an infinitessimally thin gap of uniform width, allowing the (in this
case white) background to show through.

In both of these cases (path.simplify: True|False), the PNG version of
the same figures also show representations of these gaps which are
identical to those which appear in the PDF (though obviously
pixelated), so I don't think it's something that's wrong in the vector
graphics code per se.

Zane

On Fri, Jun 12, 2009 at 11:46 AM, Michael Droettboom<md...@st...> wrote:
> Shot in the dark here, but what if you set the rcParam "path.simplify" to
> False?  There have been recent changes to that code.
>
> Also, since the Agg backend doesn't have an associated GUI, you need to use
> the savefig() command and provide a filename, rather than using show().
>
> Cheers,
> Mike
>
> Zane Selvans wrote:
>>
>> Um, yeah.  So my response got bounced because of the attachment.  Take 2:
>>
>> For some reason my script bombed when I switched to the Agg backend,
>> trying to display to the screen (it said Figure has no method show())
>>
>> So I output the plot as both a PDF and a PNG (still having backend:
>> agg in my rcfile) and in both of those cases, irregular gaps are
>> visible between the polygons making up the filled contours.  This
>> wasn't the case with my previously installed setup.  It looks as if
>> for some reason the vertices of the filled polygons are being
>> calculated differently from different sides of the same contour,
>> leading to overlap in some places, and gaps in others.  You can download
>> the PDF version (in which the exact geometry is much clearer).
>> from:
>>
>> http://zaneselvans.org/dropbox/LinDensity_Grid.pdf
>>
>> Zane
>>
>> On Fri, Jun 12, 2009 at 5:51 AM, Michael Droettboom<md...@st...>
>> wrote:
>>
>>>
>>> So you see this behavior if you switch to the Agg backend?  That's the
>>> backend used to generate the images in the gallery.  If there's a
>>> difference
>>> there, that would seem to suggest some tweaking of the macosx backend
>>> (which
>>> is still relatively new) is in order.
>>>
>>> Mike
>>>
>>> Zane Selvans wrote:
>>>
>>>>
>>>> I just installed the latest SciPy Superpack in order to get access to
>>>> the scipy.spatial.KDTree class, and discovered that for some reason
>>>> now when I use contourf() lines get drawn at the boundaries between
>>>> the filled contours.  Additionally, there is always a single vertical
>>>> line crossing from each contour boundary to the next.  I'm guessing
>>>> that these are the edges of the filled polygons which are getting
>>>> drawn.  This behavior doesn't seem to be consistent with the
>>>> contourf() documentation and when I run code in griddata_demo.py it
>>>> doesn't come out looking like the picture in the documentation/example
>>>> gallery...
>>>>
>>>> Is anyone else seeing this behavior?  Is there a keyword I can use to
>>>> force the edges of the polygons not to get drawn?
>>>>
>>>> This is on Mac OS X 10.5.7, with
>>>> scipy.__version__ = 0.8.0.dev5635
>>>> matplotlib.__version__ = 0.98.6svn
>>>> numpy.__version__=1.4.0.dev6728
>>>>
>>>> As installed by superpack_2009.03.28.sh
>>>> from http://macinscience.org/?page_id=6
>>>>
>>>> using:
>>>> backend: macosx
>>>>
>>>> Cheers,
>>>> Zane
>>>>
>>>>
>>>>
>>>
>>> --
>>> Michael Droettboom
>>> Science Software Branch
>>> Operations and Engineering Division
>>> Space Telescope Science Institute
>>> Operated by AURA for NASA
>>>
>>>
>>>
>>
>>
>>
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>



-- 
Zane A. Selvans
Amateur Earthling
http://zaneselvans.org
+1 303 815 6866

Hi,

I think you mean:

>    mpl_toolkits.basemap.NetCDFFile("output.nc", mode='r', maskandscale=True,
> cache=None, mmap=True, username=None, password=None, verbose=False)

Note quotes round filename...  Sorry, I missed those out in my previous mail.

Best,

Matthew

Hello, 

First let me say thank you for all of the help it is very appreciated. Your
suggestion to use the command import "import mpl_toolkits.basemap" has
worked, but now a new problem has popped up. 

Does the Netcdf file need to be in the same directory as the script I am
running to retrieve the file? I have moved the netcdf file to the same
location as the script and I get the following error. 

Traceback (most recent call last):
  File "/Users/interpott/Documents/trial.py", line 7, in <module>
    mpl_toolkits.basemap.NetCDFFile(output.nc, mode='r', maskandscale=True,
cache=None, mmap=True, username=None, password=None, verbose=False)
NameError: name 'output' is not defined

Any thoughts?

Thanks, 

Jon



Matthew Brett wrote:
> 
> Hi,
> 
> On Fri, Jun 12, 2009 at 10:52 AM, JPKay<ka...@va...> wrote:
>> from mpl_toolkits.basemap import Basemap
> 
> You have not so far imported mpl_toolkits into the namespace, only
> Basemap.  You could do:
> 
> import mpl_toolkits.basemap
> 
> as another import line, or:
> 
> from mpl_toolkits.basemap import Basemap, NetCDFFile
> 
> followed by:
> 
> ncfile = NetCDFFile(output.nc, ...)
> 
> Best,
> 
> Matthew
> 
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 

-- 
View this message in context: http://www.nabble.com/Quiver-plot-of-a-netcdf-file-tp23986313p24005790.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Fri, Jun 12, 2009 at 2:20 PM, Christoph Gohlke<cg...@uc...> wrote:
> Hello,
>
> I have compiled Matplotlib 0.98.5.3 for Python 2.6 for Windows 32-bit
> using Visual Studio 2008. The build process was straightforward and the
> produced binaries work for me, specifically there is no crash in
> _png.pyd when writing PNG files.

Thanks for this link -- the problem I am experiencing is specific to
the mingw compiler suite, so the visual studio build should work fine.
 Would you be willing to build a bdist installer and an egg for us
while we are trying to sort the mingw problems out -- I think all you
need to do is pass bdist_wininst and bdist_egg to your build command.

JDH

Hello,

I have compiled Matplotlib 0.98.5.3 for Python 2.6 for Windows 32-bit 
using Visual Studio 2008. The build process was straightforward and the 
produced binaries work for me, specifically there is no crash in 
_png.pyd when writing PNG files.

<http://www.lfd.uci.edu/~gohlke/download/matplotlib-0.98.5.3.win32-py2.6.zip>

Use at your own risk. To install, remove previous installations of 
matplotlib and unzip the file to C:\Python26\Lib\site-packages.

Sources used:
Matplotlib svn v0_98_5_maint rev 7211
Freetype 2.3.9
Libpng 1.2.37
Zlib 1.2.3
Python 2.6.2 from python.org
NumPy 1.3.0 from scipy.org
wxPython 2.8.10.1 from wxpython.org

Regards,

Christoph

jor...@ya... wrote:
> 
> 
> 
> 
> ----- Mensaje original ----
>> De: Eric Firing <ef...@ha...>
>>
>> import matplotlib.cbook as cbook
>>
>> def to_sequence(arg):
>>     if cbook.is_iterable(arg):

I goofed.  It should be cbook.iterable(arg).

Eric

Matthias Michler wrote:
> Hi Sebastian, Hi list,
> 
> I'm not the one to decide this, but I think it is worth to try to remove 
> matplotlib.mlab routines, if their numpy counterparts provide the same 
> functionality or do I miss anything? After doing this one additionally could 

We have been doing this via deprecations.  If there is something we have 
missed--a function in mlab that is also in numpy and that is *not* 
deprecated in mlab--please be specific about what it is, and we will 
deprecate it.

The functions like log2 are historical, part of a set contributed by 
Fernando Perez a long time ago.  We tend to be cautious about ripping 
out such things, because user code may be depending on them.  Maybe some 
of them should be deprecated.  It is often hard to decide where and how 
to compromise between cleaning things up and maintaining backwards 
compatibility, just in case someone's code is depending on something 
obscure that has been there from early days.

If there are *specific* recommendations about functions that should be 
deprecated or changed, we would be happy to consider those recommendations.

> clean up the imports in pylab in order to have only one call "from 
> matplotlib.mlab import" instead of 3.

Yes, I see now that the mlab imports in pylab are an incredibly ugly 
mess and desperately need to be cleaned up.  Thanks for pointing that out.

Multiple calls to "from matplotlib.mlab import ..." are fine with me, 
but I hate backslash line continuations, and I see that some functions 
are imported more than once.

It looks like we must be importing nearly everything, in which case it 
would be better to simply import * and then delete a few things if we 
really don't want them.  A more radical change, such as importing only a 
very few things, and/or breaking mlab up so as to separate out the parts 
that pylab needs to import, may be better.

Eric

> 
> kind regards Matthias 
> 
> On Friday 12 June 2009 14:41:28 Sebastian Haase wrote:
>> On Fri, Jun 12, 2009 at 2:01 PM, John Hunter<jd...@gm...> wrote:
>>> On Fri, Jun 12, 2009 at 6:10 AM, Sebastian Haase<seb...@gm...> 
> wrote:
>>>> On Fri, Jun 12, 2009 at 11:21 AM, Matthias
>>>>
>>>> Michler<Mat...@gm...> wrote:
>>>>> Hi Sebastian,
>>>>>
>>>>> You are right. A large number of numpy functions is part of pylab, but
>>>>> I think this problem was solved by introducing matplotlib.pyplot, which
>>>>> holds all plotting functions of matplotlib. The module pylab imports
>>>>> these plotting functions and all the numpy-stuff in order to offer
>>>>> plotting + numerical functions by one import.
>>>>>
>>>>> kind regards Matthias
>>>> Matthias,
>>>> thanks for the info. thats the info I was missing.
>>>>
>>>>>>> from matplotlib import pyplot
>>>>>>> len(pyplot.__dict__)
>>>> 191
>>>>
>>>> Now I'm somewhat wondering about the things in pylab that are not in
>>>> pyplot nor in numpy.
>>>> E.g.:
>>>> pyplot.log2  is not numpy.log2
>>>> or
>>>> pyplot.window_hanning   vs.  numpy.hanning
>>>> or
>>>> pyplot.chisquare  (which however is in numpy.random)
>>> These symbols are not in svn:
>>>
>>>
>>> In [59]: plt.log2
>>> ------------------------------------------------------------
>>> Traceback (most recent call last):
>>>  File "<ipython console>", line 1, in ?
>>> AttributeError: 'module' object has no attribute 'log2'
>>>
>>>
>>> In [60]: plt.window_hanning
>>> ------------------------------------------------------------
>>> Traceback (most recent call last):
>>>  File "<ipython console>", line 1, in ?
>>> AttributeError: 'module' object has no attribute 'window_hanning'
>> Sorry - I meant pylab ! not pyplot ...
>> There are those symbols.
>>
>> -S.
> 
> 
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing 
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users