matplotlib-users Mailing List for matplotlib (Page 3)

On 2012年10月18日 10:45:24 +0100
Damon McDougall <dam...@gm...> wrote:
> Ok wow, awesome feedback! I started on this yesterday morning to see
> how it would go, and I've already got something working that mimics
> the command-line syntax of GNU's `graph` (except it currently only
> supports one data file as input).
Great!
Using e.g. optparse, multiple data files shouldn't be too complicated.
I might need to look into GNU graph. I was ignorant about it's
existence till it was mentioned here on the MPL list.
> > I'm currently just developing on a local feature branch in the
> matplotlib repository, but I'm happy to pull it out to a different
> repo and announce it here once I make some more ground on it. I
> haven't pushed anything yet. If I do I'll make an announcement here.
Looking forward!
I think a separate repository might be the best option as you probably
do not want to modify MPL in any way, but rather build your scripts on
top of it.
> One thing I have noticed is that GNU's `graph` is rather fast.
> Compared to matplotlib, GNU's `graph` blows matplotlib out of the
> water when it comes to speed. Though, in my opinion, matplotlib wins
> when it comes to output quality. As far as I'm concerned, quality wins
> over speed but I realise that there needs to be some speed
> improvements in matplotlib's backends. I have noticed that text takes
> quite a while to process in the backend (currently using Agg for PDF
> and PNG output).
The good thing is that any command-line "frontend" certainly does not
need to care about backend specifics. The problem is completely
separable.
 
> Regarding input data file-type, I agree, supporting those formats
> would expand our userbase considerably. There are already some helper
> functions in matplotlib.cbook for reading csv-type files. One downside
> of supporting lots of different file-types is that there will be more
> (optional) dependencies.
I typically "try:" to import relevant packages and set a flag in case
that doesn't work. Using this approach, all dependencies really remain
optional.
> I think I should be able to make this public fairly soon. Furthermore,
> it will be trivial to install (copy and paste to the /usr/local/bin
> directory). The command-line utility is literally just a python script
> (with executable permissions) that parses command-line arguments and
> sets up plot and figure parameters. Of course, it may be the case in
> the future that it gets rather large and needs to be made more
> modular.
In case your approach looks right, I am pretty sure you'll find
contributors quickly.
 
Good luck!
Cheers
Alex

On Thu, Oct 18, 2012 at 10:10 AM, Alexander Eberspaecher
<ale...@ov...> wrote:
> Hello,
>
> On 2012年10月17日 11:38:27 +0100
> Damon McDougall <dam...@gm...> wrote:
>
>> How do people feel about perhaps adding a matplotlib version, mocking
>> the same calling signature as graph?
>>
>> I think the most important question is: would it be useful?
>
> Yes, this would certainly be useful! I think there are people
> unfamiliar with Python, but rather excited about MPL's plotting
> capabilities.
>
> I personally would want it to read data from white-space separated text
> files (np.loadtxt()), probably CSV files, and HDF5 files (e.g. using
> h5py, if available).
>
> To be useful for different purposes, I'd want the tool to be able to use
> different backends (producing e.g. PNG output in case you need a figure
> to send via e-mail or PGF output in case you are preparing a LaTeX
> document). Matplotlibrc should be hidden from the user.
>
> As Gnuplot was specifically mentioned in another e-mail in this thread,
> let me use that opportunity to mention that MPL falls behind Gnuplot in
> terms of line styles. Using MPL, I found ls="-" and maybe ls="--" to be
> useful, whereas Gnuplot offers 9 linestyles that are easy to
> distinguish visually. Compare e.g. the figure linked in
> http://www.der-schnorz.de/2010/09/gnuplot-colors-presentations-papers-and-contrast/
> In case this is of general interest, we might discuss that in a new
> thread.
>
> As a side note, personally, for text file visualisation, I often use
> this dirty MPL plotting plugin for the text editor of my choice (Geany):
> https://github.com/aeberspaecher/GeanyPlot
> A command line tool would of course be preferred.
>
> Cheers
>
> Alex
Ok wow, awesome feedback! I started on this yesterday morning to see
how it would go, and I've already got something working that mimics
the command-line syntax of GNU's `graph` (except it currently only
supports one data file as input).
I'm currently just developing on a local feature branch in the
matplotlib repository, but I'm happy to pull it out to a different
repo and announce it here once I make some more ground on it. I
haven't pushed anything yet. If I do I'll make an announcement here.
One thing I have noticed is that GNU's `graph` is rather fast.
Compared to matplotlib, GNU's `graph` blows matplotlib out of the
water when it comes to speed. Though, in my opinion, matplotlib wins
when it comes to output quality. As far as I'm concerned, quality wins
over speed but I realise that there needs to be some speed
improvements in matplotlib's backends. I have noticed that text takes
quite a while to process in the backend (currently using Agg for PDF
and PNG output).
Regarding input data file-type, I agree, supporting those formats
would expand our userbase considerably. There are already some helper
functions in matplotlib.cbook for reading csv-type files. One downside
of supporting lots of different file-types is that there will be more
(optional) dependencies.
Personally, when I just want to see statistics from a computational
run, I think I will find this rather helpful.
I think I should be able to make this public fairly soon. Furthermore,
it will be trivial to install (copy and paste to the /usr/local/bin
directory). The command-line utility is literally just a python script
(with executable permissions) that parses command-line arguments and
sets up plot and figure parameters. Of course, it may be the case in
the future that it gets rather large and needs to be made more
modular.
Right-o, back to more procrastinating. Thanks for all the encouragement! :)
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Hello,
On 2012年10月17日 11:38:27 +0100
Damon McDougall <dam...@gm...> wrote:
> How do people feel about perhaps adding a matplotlib version, mocking
> the same calling signature as graph?
> 
> I think the most important question is: would it be useful?
Yes, this would certainly be useful! I think there are people
unfamiliar with Python, but rather excited about MPL's plotting
capabilities.
I personally would want it to read data from white-space separated text
files (np.loadtxt()), probably CSV files, and HDF5 files (e.g. using
h5py, if available).
To be useful for different purposes, I'd want the tool to be able to use
different backends (producing e.g. PNG output in case you need a figure
to send via e-mail or PGF output in case you are preparing a LaTeX
document). Matplotlibrc should be hidden from the user.
As Gnuplot was specifically mentioned in another e-mail in this thread,
let me use that opportunity to mention that MPL falls behind Gnuplot in
terms of line styles. Using MPL, I found ls="-" and maybe ls="--" to be
useful, whereas Gnuplot offers 9 linestyles that are easy to
distinguish visually. Compare e.g. the figure linked in
http://www.der-schnorz.de/2010/09/gnuplot-colors-presentations-papers-and-contrast/
In case this is of general interest, we might discuss that in a new
thread.
As a side note, personally, for text file visualisation, I often use
this dirty MPL plotting plugin for the text editor of my choice (Geany):
https://github.com/aeberspaecher/GeanyPlot
A command line tool would of course be preferred.
Cheers
Alex

I totally agree with to general opinion that a command line tool would be beneficial.
I've written a simple mpl commandline plotter quite some time ago and use it frequently for
quick previews but also to create simple plots for presentations. It features some options to
modify the appearance just like GNU/graph.
If somebody wants to give it at try, I've attached the script.
br
Jakob
>> I was brain-storming yesterday and I wanted to test the waters to see
>> if people would find it useful.
>>
>> Currently, GNU plotutils comes with command-line utilities such as
>> `graph` to create quick and dirty line plots like this:
>> http://www.gnu.org/software/gsl/manual/html_node/DWT-Examples.html. I
>> think even gnuplot might be similar.
>>
>> How do people feel about perhaps adding a matplotlib version, mocking
>> the same calling signature as graph?
>>
>> I think the most important question is: would it be useful?

Jouni K. Seppänen <jk...@ik...> writes:
> Gökhan Sever <gok...@gm...>
> writes:
>
>> Another point I noticed is setting linewidth to 0 (in fill_between
>> function) isn't working as expected when figure is saved as a PDF
>> file.
>
> A workaround is to add edgecolor='None' to the fill_between call.
I filed an issue at https://github.com/matplotlib/matplotlib/issues/1412
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Gökhan Sever <gok...@gm...>
writes:
> Another point I noticed is setting linewidth to 0 (in fill_between
> function) isn't working as expected when figure is saved as a PDF
> file.
A workaround is to add edgecolor='None' to the fill_between call.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Benjamin Root <ben...@ou...> writes:
> On Wed, Oct 17, 2012 at 12:17 PM, Gökhan Sever
> <gok...@gm...>wrote:
>
>> Another point I noticed is setting linewidth to 0 (in fill_between
>> function) isn't working as expected when figure is saved as a PDF file.
>>
> Actually, this is not a bug in mpl. It is a "bug" in various viewers.
> Some viewers have a "minimum" linewidth and will use that for any requested
> linewidths smaller than that. Are you using Apple's Preview?
That's correct as per the pdf specification: a linewidth of zero means
the thinnest possible line on that device. That's why the pdf backend
attempts to not draw a line if the width is set to zero, but somehow
it's not working in this case. I'd call it a bug.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

I can certainly see the benefit. As Mike said, I don't think I would use it
myself, but I could see non-python users finding it useful.
Personally, I think this would be a nice extension that doesn't have to
live in the core matplotlib code base. That way release cycles and testing
can be done completely independently without complicating the matplotlib
repo.
Nice idea.
Phil
On 17 October 2012 16:20, Daπid <dav...@gm...> wrote:
> I also think that would be useful. It would, for example, allow to
> generate "preview" plots from other languages, without interfacing
> them to Python. It must be said that MPL is actually quite nice
> looking in the default settings for basic plotting, and this is an
> nice feature that can exploit.
>
> I have seen many pieces of code using SuperMongo for plotting. I find
> it absolutely ugly, and super expensive, but it is probably the easier
> plotting system to call from FORTRAN (or, at least, it was).
>
> On Wed, Oct 17, 2012 at 3:15 PM, Michael Droettboom <md...@st...>
> wrote:
> > I think this could be very useful -- and might help increase the user
> > base beyond the Python community. As I, and most of us on this list,
> > are quite comfortable with Python, I don't think I'd use it myself, but
> > I certainly see the utility of it.
> >
> > Mike
> >
> > On 10/17/2012 06:38 AM, Damon McDougall wrote:
> >> All,
> >>
> >> I was brain-storming yesterday and I wanted to test the waters to see
> >> if people would find it useful.
> >>
> >> Currently, GNU plotutils comes with command-line utilities such as
> >> `graph` to create quick and dirty line plots like this:
> >> http://www.gnu.org/software/gsl/manual/html_node/DWT-Examples.html. I
> >> think even gnuplot might be similar.
> >>
> >> How do people feel about perhaps adding a matplotlib version, mocking
> >> the same calling signature as graph?
> >>
> >> I think the most important question is: would it be useful?
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_sfd2d_oct
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

> If nothing speaks against it, i could do a pull request.
If you are willing, I would encourage you to do that, or at least make a
branch in your matplotlib fork and post the diff URL here. That way we can
discuss the pros & cons in-line, even if it means that we do no actually
merge the PR (that sounds bad, but really pull requests are a great medium
for discussing code).
Thanks!
Phil

On 2012年10月17日 6:13 PM, Michael Aye wrote:
> I am using matplotlib 1.1.0 that came with the current EPD, which in
> turn comes without pygtk.
>
> However, the linux system I am using this on (CentOS6) has pygtk installed:
>
> /usr/lib64/pygtk/2.0
>
> Is there any change I can marry those two? Currently, when I try to
> matplotlib.use('gtk')
> I get an error
> ImportError("Gtk* backend requires pygtk to be installed.")
>
> Or do I need to recompile it into this matplotlib?
Yes, you need to recompile. It will need to compile _backend_gdk.c, 
which needs to be able to find pygtk.h.
The plain (non-agg) gtk backend is basically unmaintained and its use is 
discouraged. Are you sure there isn't a reasonably easy way to do what 
you need with qt4agg, for example? How do you want to visualize your 
million points?
Eric
>
> Thanks for your help!
>
> Michael
>
> PS.: The reason why I want to try GTK is actually that there are
> reports of it being able to cope with 1 million data points, something
> all other Agg-related backends can not do, apparently. (My linux is
> server is definitely not the limit ;)
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

I am using matplotlib 1.1.0 that came with the current EPD, which in 
turn comes without pygtk.
However, the linux system I am using this on (CentOS6) has pygtk installed:
/usr/lib64/pygtk/2.0
Is there any change I can marry those two? Currently, when I try to
matplotlib.use('gtk')
I get an error
ImportError("Gtk* backend requires pygtk to be installed.")
Or do I need to recompile it into this matplotlib?
Thanks for your help!
Michael
PS.: The reason why I want to try GTK is actually that there are 
reports of it being able to cope with 1 million data points, something 
all other Agg-related backends can not do, apparently. (My linux is 
server is definitely not the limit ;)

Hi Sterling ,
Thanks for your email. I definitely think I was running into issues with
the figure updating while it was trying to draw , constantly. I
experimented with sleep ..but didnt try hard enough to get it to work.
That said, I have a very nice solution to my problem using the
wx.aui.AuiNotebook
 borrowed from example wx5 (
http://matplotlib.org/examples/user_interfaces/embedding_in_wx5.html)
# MY SOLUTION
I now have a single Plot wx.Panel which then encloses a wx.aui.Notebook
just like in the wx5 example link above.
Once I have finished processing the data . I initialize the plotter just
like in the example above. I have a for loop that goes over all 384 data
sets and then adds a page to the Notebook for every dataset.
The result is a 384 , tabbed Notebook , where each tab is a fully
interactive matplotlib plot , created like before.
def do_my_plot(well_id, plotter_from_main):
 my_plotter = plotter_from_main
 # Here is where I add a page to the Notebook and get its current axis
 ax = plotter.add("figure %s" % well_id).gca()
 par1 = ax .twinx()
 par2 = ax.twinx()
.............................................and -so on
The neatest thing of the final Notebook is that , although it takes about a
minute to appear at first call to frame.Show()..
After that it is very performant.
 Importantly I can quickly scroll through all the 384 tabs ( or pages in
the notebook) using CTRL-TAB to go forward and CTRL-Shift_TAB to go
backward. This ability to navigate is a huge plus for me. The Navigation is
actually very fast and "redraws" are nearly instantaneous.
I will still try and get the "single figure that refreshed " approach as I
originally wanted, using the techniques you , Ben and Damon suggested .
In many cases I dont need to have a 384 tabbed frame..and can do with a
plot that refreshes every few seconds so I know that everything went right.
Thanks everyone for all your help..Ill get back to the group once I get the
repaint within a single frame to work..
Hari
On Wed, Oct 17, 2012 at 5:38 PM, Sterling Smith <sm...@fu...>wrote:
> Hari,
>
> While I am not intimately acquainted with the inner working of the
> interactive matplotlib functionality, I have seen that it tries to not
> update the figure if you ask for some change to it while it is trying to
> update the figure. That sounds circular, but oh well.
>
> Perhaps you could have each analysis open a new figure, and have an if
> statement to close 5 (or 10...) figures ago.
>
> Another subtlety that I have noticed (and perhaps read somewhere) is that
> there could be a difference in behavior between having interactivity set in
> the matplotlibrc file and using the ion() call after having set
> interactive: False in the matplotlibrc file.
>
> Another solution might be a time.sleep after each update of the figure.
>
> (Note that with ion(), the command for updating the figure is pylab.draw,
> which may need to be issued after each case - the pylab/pyplot functions
> usually have a draw_if_interactive call in them.)
>
> -Sterling
>
> PS If I am causing more confusion than help, please let me know.
>
>
> On Oct 17, 2012, at 10:54AM, hari jayaram wrote:
>
> > Thanks Benjamin, Sterling and Damon for your prompt help
> >
> > However I am still not able to achieve what I wanted .
> >
> > I can get the headless script to work just great where it saves all the
> figures and I can view them after the script is done running.
> >
> > But somehow when I try the figure number method that Sterling suggested
> , along with the axis clear and redraw method (Damon) , or the decouple and
> clear and then plot method (Benjamin Root) : I get the plot just spinning
> with a blue circle on Windows 7 and the script just chugs merrily along.
> >
> >
> > I think part of the problem was that I was wrong in the way I stated my
> application. Each of the 384 data processing steps takes a few seconds..and
> not a minute as I had indicated. I tried with both ion() and ioff() and
> giving the figure a number , which stays constant and clearing the axis
> everytime before plotting. But I get a spiining blue circle in Windows.
> >
> > I will try and cookup a test case , and send to the list , to reproduce
> what I am seeing. it may still be that I am calling pylab , pyplot
> incorrectly and hence not getting the continuously changing figure that
> your suggestions should give me.
> >
> > hari
> >
> >
> >
> >
> > Using plt.ion() or plt.ioff() causes a spinning blue-ball on
> windows..while the rest of the script continues.
> > If I use the figure number trick. I get the first figure displayed.
> >
> > On Tue, Oct 16, 2012 at 12:15 PM, Benjamin Root <ben...@ou...> wrote:
> >
> >
> > On Tue, Oct 16, 2012 at 11:25 AM, hari jayaram <ha...@gm...>
> wrote:
> > Hi
> > I am a relative newbie to matplotlib.
> >
> > I have a python script that handles a dataset that comprises 384 sets of
> data.
> >
> > At the present moment , I read in a set of data - process it - and the
> create a figure using code shown below.
> > I am using windows with the default backend ( I think I set it to wx).
> >
> > When I run the program, figure after figure shows up..the program
> continues from well to well plotting the figure. I can close the figure
> window using the X on the right -hand side..while the program chugs along.
> >
> > Is there a way to just recycle the figure object , so that the plot
> shows up for a brief second and refreshes when the next calculation is
> complete. Each process_data function , takes a few minutes.
> >
> > Alternatively I just want to close the figure object I show after a
> brief lag. I am OK if that happens instantaneously..but I dont know how to
> achieve this.
> > Do I have to use the matplotlib.Figure object to achieve this
> functionality
> >
> > Thanks
> > Hari
> >
> >
> >
> > Hari,
> >
> > To recycle the figure, try the following:
> >
> >
> >
> > import matplotlib.pyplot as plt
> >
> > def do_my_plot(par1, par2, well_id):
> > processed_data_object = processed_dict[well_id]
> > # Plot all the data
> > par1.plot(processed_data_object.raw_x,processed_data_object.raw_y).
> > par2.plot(....
> > # finally
> > plt.show()
> > # I tried fig.clf()
> >
> >
> > def plot_and_process_data():
> > plt.ion() # Turn on interactive mode
> > fig = plt.figure(figsize=(7,7)
> > ax = fig.add_subplot(1,1,1)
> > par1 =ax.twinx()
> > par2 = ax.twinx()
> >
> > for well_id in list_of_384_well_ids:
> > par1.cla()
> > par2.cla()
> > process_data(well_id)
> > do_my_plot(par1, par2, well_id)
> >
> > Note, this is completely untested, but it would be how I would go about
> it at first. The "plt.ion()" turns on interactive mode to allow your code
> to continue running even after the plot window appears (but does not end
> until the last window is closed.). Of course, another approach would
> simply be to do "fig.savefig()" after every update to the figure and never
> use show() and ion() (essentially, a non-interactive head-less script).
> >
> > Hopefully, this helps.
> > Ben Root
> >
> >
> >
> ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> >
> http://p.sf.net/sfu/appdyn_sfd2d_oct_______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Hari,
While I am not intimately acquainted with the inner working of the interactive matplotlib functionality, I have seen that it tries to not update the figure if you ask for some change to it while it is trying to update the figure. That sounds circular, but oh well. 
Perhaps you could have each analysis open a new figure, and have an if statement to close 5 (or 10...) figures ago. 
Another subtlety that I have noticed (and perhaps read somewhere) is that there could be a difference in behavior between having interactivity set in the matplotlibrc file and using the ion() call after having set interactive: False in the matplotlibrc file.
Another solution might be a time.sleep after each update of the figure.
(Note that with ion(), the command for updating the figure is pylab.draw, which may need to be issued after each case - the pylab/pyplot functions usually have a draw_if_interactive call in them.)
-Sterling
PS If I am causing more confusion than help, please let me know.
On Oct 17, 2012, at 10:54AM, hari jayaram wrote:
> Thanks Benjamin, Sterling and Damon for your prompt help
> 
> However I am still not able to achieve what I wanted .
> 
> I can get the headless script to work just great where it saves all the figures and I can view them after the script is done running.
> 
> But somehow when I try the figure number method that Sterling suggested , along with the axis clear and redraw method (Damon) , or the decouple and clear and then plot method (Benjamin Root) : I get the plot just spinning with a blue circle on Windows 7 and the script just chugs merrily along.
> 
> 
> I think part of the problem was that I was wrong in the way I stated my application. Each of the 384 data processing steps takes a few seconds..and not a minute as I had indicated. I tried with both ion() and ioff() and giving the figure a number , which stays constant and clearing the axis everytime before plotting. But I get a spiining blue circle in Windows.
> 
> I will try and cookup a test case , and send to the list , to reproduce what I am seeing. it may still be that I am calling pylab , pyplot incorrectly and hence not getting the continuously changing figure that your suggestions should give me.
> 
> hari
> 
> 
> 
> 
> Using plt.ion() or plt.ioff() causes a spinning blue-ball on windows..while the rest of the script continues.
> If I use the figure number trick. I get the first figure displayed.
> 
> On Tue, Oct 16, 2012 at 12:15 PM, Benjamin Root <ben...@ou...> wrote:
> 
> 
> On Tue, Oct 16, 2012 at 11:25 AM, hari jayaram <ha...@gm...> wrote:
> Hi 
> I am a relative newbie to matplotlib.
> 
> I have a python script that handles a dataset that comprises 384 sets of data.
> 
> At the present moment , I read in a set of data - process it - and the create a figure using code shown below.
> I am using windows with the default backend ( I think I set it to wx).
> 
> When I run the program, figure after figure shows up..the program continues from well to well plotting the figure. I can close the figure window using the X on the right -hand side..while the program chugs along.
> 
> Is there a way to just recycle the figure object , so that the plot shows up for a brief second and refreshes when the next calculation is complete. Each process_data function , takes a few minutes. 
> 
> Alternatively I just want to close the figure object I show after a brief lag. I am OK if that happens instantaneously..but I dont know how to achieve this.
> Do I have to use the matplotlib.Figure object to achieve this functionality
> 
> Thanks
> Hari
> 
> 
> 
> Hari,
> 
> To recycle the figure, try the following:
> 
> 
> 
> import matplotlib.pyplot as plt
> 
> def do_my_plot(par1, par2, well_id):
> processed_data_object = processed_dict[well_id]
> # Plot all the data
> par1.plot(processed_data_object.raw_x,processed_data_object.raw_y).
> par2.plot(....
> # finally
> plt.show() 
> # I tried fig.clf()
> 
> 
> def plot_and_process_data():
> plt.ion() # Turn on interactive mode 
> fig = plt.figure(figsize=(7,7)
> ax = fig.add_subplot(1,1,1)
> par1 =ax.twinx()
> par2 = ax.twinx()
> 
> for well_id in list_of_384_well_ids:
> par1.cla()
> par2.cla()
> process_data(well_id)
> do_my_plot(par1, par2, well_id)
> 
> Note, this is completely untested, but it would be how I would go about it at first. The "plt.ion()" turns on interactive mode to allow your code to continue running even after the plot window appears (but does not end until the last window is closed.). Of course, another approach would simply be to do "fig.savefig()" after every update to the figure and never use show() and ion() (essentially, a non-interactive head-less script).
> 
> Hopefully, this helps.
> Ben Root
> 
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct_______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hello group,
is there any special reason for the special handling of scalar 
arguments in the normalization classes? Would it not be simpler 
to just use asarray and only use arrays? 
If nothing speaks against it, i could do a pull request.
greetings
Till Stensitzki

On Wed, Oct 17, 2012 at 12:03 PM, Damon McDougall <dam...@gm...
> wrote:
>
>
> Also notice the triangle transparency...
>
>
True. Mike's 4 line addition fixes that issue:
https://github.com/matplotlib/matplotlib/issues/1410
-- 
Gökhan

I see that the same behavior here on 3 different viewers. It is a slight
aesthetic issue, but once in a while I come up similar differences between
PDF and PNGs outputs.
-- 
Gökhan

On Wed, Oct 17, 2012 at 6:58 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Wed, Oct 17, 2012 at 1:21 PM, Damon McDougall <dam...@gm...>
> wrote:
>>
>> On Wed, Oct 17, 2012 at 6:13 PM, Benjamin Root <ben...@ou...> wrote:
>> >
>> >
>> > On Wed, Oct 17, 2012 at 1:08 PM, Damon McDougall
>> > <dam...@gm...>
>> > wrote:
>> >>
>> >> On Wed, Oct 17, 2012 at 5:56 PM, Gökhan Sever <gok...@gm...>
>> >> wrote:
>> >> >
>> >> >
>> >> > On Wed, Oct 17, 2012 at 10:21 AM, Benjamin Root <ben...@ou...>
>> >> > wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Wed, Oct 17, 2012 at 12:17 PM, Gökhan Sever
>> >> >> <gok...@gm...>
>> >> >> wrote:
>> >> >>>
>> >> >>> Thanks Mike,
>> >> >>>
>> >> >>> Another point I noticed is setting linewidth to 0 (in fill_between
>> >> >>> function) isn't working as expected when figure is saved as a PDF
>> >> >>> file.
>> >> >>>
>> >> >>> I noticed this while posting a sample script on scipy-users:
>> >> >>>
>> >> >>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.py
>> >> >>>
>> >> >>> Compare the outputs of pdf and png to see the difference that I am
>> >> >>> mentioning:
>> >> >>>
>> >> >>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.pdf
>> >> >>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.png
>> >> >>>
>> >> >>
>> >> >> Actually, this is not a bug in mpl. It is a "bug" in various
>> >> >> viewers.
>> >> >> Some viewers have a "minimum" linewidth and will use that for any
>> >> >> requested
>> >> >> linewidths smaller than that. Are you using Apple's Preview?
>> >> >>
>> >> >> Cheers!
>> >> >> Ben Root
>> >> >>
>> >> >
>> >> > Hi Ben,
>> >> >
>> >> > I was guessing the same way, but trying different viewers doesn't
>> >> > make
>> >> > any
>> >> > difference:
>> >> >
>> >> > Evince v3.2.1
>> >> > Xpdf v3.03
>> >> > Okular v0.14.3
>> >> >
>> >> > Could anyone confirm this on a window machine?
>> >> >
>> >> > --
>> >> > Gökhan
>> >>
>> >> Confirmed with Preview.app on OS X 10.7.4.
>> >>
>> >
>> > I think it looks ok with the old Adobe viewer on linux (I never bothered
>> > updating it since I use Evince). Kinda hard to tell the difference
>> > between
>> > grey and greyer... Could somebody include a screenshot of what they are
>> > seeing?
>>
>> Sir, the internet has completed your request: http://i.imgur.com/UdRB9.png
>>
>> >
>> > Ben Root
>> >
>>
>>
>
> Thanks! That helps.
>
> With the older Adobe viewer for linux, there is a very slight line, but not
> nearly as pronounced as Apple's Preview (which is where I originally
> encountered this issue about a year ago). Attaching a screen capture for
> reference.
>
> Cheers!
> Ben Root
>
Also notice the triangle transparency...
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Wed, Oct 17, 2012 at 1:21 PM, Damon McDougall
<dam...@gm...>wrote:
> On Wed, Oct 17, 2012 at 6:13 PM, Benjamin Root <ben...@ou...> wrote:
> >
> >
> > On Wed, Oct 17, 2012 at 1:08 PM, Damon McDougall <
> dam...@gm...>
> > wrote:
> >>
> >> On Wed, Oct 17, 2012 at 5:56 PM, Gökhan Sever <gok...@gm...>
> >> wrote:
> >> >
> >> >
> >> > On Wed, Oct 17, 2012 at 10:21 AM, Benjamin Root <ben...@ou...>
> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Oct 17, 2012 at 12:17 PM, Gökhan Sever <
> gok...@gm...>
> >> >> wrote:
> >> >>>
> >> >>> Thanks Mike,
> >> >>>
> >> >>> Another point I noticed is setting linewidth to 0 (in fill_between
> >> >>> function) isn't working as expected when figure is saved as a PDF
> >> >>> file.
> >> >>>
> >> >>> I noticed this while posting a sample script on scipy-users:
> >> >>>
> >> >>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.py
> >> >>>
> >> >>> Compare the outputs of pdf and png to see the difference that I am
> >> >>> mentioning:
> >> >>>
> >> >>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.pdf
> >> >>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.png
> >> >>>
> >> >>
> >> >> Actually, this is not a bug in mpl. It is a "bug" in various
> viewers.
> >> >> Some viewers have a "minimum" linewidth and will use that for any
> >> >> requested
> >> >> linewidths smaller than that. Are you using Apple's Preview?
> >> >>
> >> >> Cheers!
> >> >> Ben Root
> >> >>
> >> >
> >> > Hi Ben,
> >> >
> >> > I was guessing the same way, but trying different viewers doesn't make
> >> > any
> >> > difference:
> >> >
> >> > Evince v3.2.1
> >> > Xpdf v3.03
> >> > Okular v0.14.3
> >> >
> >> > Could anyone confirm this on a window machine?
> >> >
> >> > --
> >> > Gökhan
> >>
> >> Confirmed with Preview.app on OS X 10.7.4.
> >>
> >
> > I think it looks ok with the old Adobe viewer on linux (I never bothered
> > updating it since I use Evince). Kinda hard to tell the difference
> between
> > grey and greyer... Could somebody include a screenshot of what they are
> > seeing?
>
> Sir, the internet has completed your request: http://i.imgur.com/UdRB9.png
>
> >
> > Ben Root
> >
>
>
>
Thanks! That helps.
With the older Adobe viewer for linux, there is a very slight line, but not
nearly as pronounced as Apple's Preview (which is where I originally
encountered this issue about a year ago). Attaching a screen capture for
reference.
Cheers!
Ben Root

Thanks Benjamin, Sterling and Damon for your prompt help
However I am still not able to achieve what I wanted .
I can get the headless script to work just great where it saves all the
figures and I can view them after the script is done running.
But somehow when I try the figure number method that Sterling suggested ,
along with the axis clear and redraw method (Damon) , or the decouple and
clear and then plot method (Benjamin Root) : I get the plot just spinning
with a blue circle on Windows 7 and the script just chugs merrily along.
I think part of the problem was that I was wrong in the way I stated my
application. Each of the 384 data processing steps takes a few seconds..and
not a minute as I had indicated. I tried with both ion() and ioff() and
giving the figure a number , which stays constant and clearing the axis
everytime before plotting. But I get a spiining blue circle in Windows.
I will try and cookup a test case , and send to the list , to reproduce
what I am seeing. it may still be that I am calling pylab , pyplot
incorrectly and hence not getting the continuously changing figure that
your suggestions should give me.
hari
Using plt.ion() or plt.ioff() causes a spinning blue-ball on windows..while
the rest of the script continues.
If I use the figure number trick. I get the first figure displayed.
On Tue, Oct 16, 2012 at 12:15 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Tue, Oct 16, 2012 at 11:25 AM, hari jayaram <ha...@gm...> wrote:
>
>> Hi
>> I am a relative newbie to matplotlib.
>>
>> I have a python script that handles a dataset that comprises 384 sets of
>> data.
>>
>> At the present moment , I read in a set of data - process it - and the
>> create a figure using code shown below.
>> I am using windows with the default backend ( I think I set it to wx).
>>
>> When I run the program, figure after figure shows up..the program
>> continues from well to well plotting the figure. I can close the figure
>> window using the X on the right -hand side..while the program chugs along.
>>
>> Is there a way to just recycle the figure object , so that the plot shows
>> up for a brief second and refreshes when the next calculation is complete.
>> Each process_data function , takes a few minutes.
>>
>> Alternatively I just want to close the figure object I show after a brief
>> lag. I am OK if that happens instantaneously..but I dont know how
>> to achieve this.
>> Do I have to use the matplotlib.Figure object to achieve this
>> functionality
>>
>> Thanks
>> Hari
>>
>>
>>
> Hari,
>
> To recycle the figure, try the following:
>
>
>
> import matplotlib.pyplot as plt
>
> def do_my_plot(par1, par2, well_id):
> processed_data_object = processed_dict[well_id]
> # Plot all the data
> par1.plot(processed_data_object.raw_x,processed_data_object.raw_y).
> par2.plot(....
> # finally
> plt.show()
> # I tried fig.clf()
>
>
> def plot_and_process_data():
> plt.ion() # Turn on interactive mode
> fig = plt.figure(figsize=(7,7)
> ax = fig.add_subplot(1,1,1)
> par1 =ax.twinx()
> par2 = ax.twinx()
>
> for well_id in list_of_384_well_ids:
> par1.cla()
> par2.cla()
> process_data(well_id)
> do_my_plot(par1, par2, well_id)
>
> Note, this is completely untested, but it would be how I would go about it
> at first. The "plt.ion()" turns on interactive mode to allow your code to
> continue running even after the plot window appears (but does not end until
> the last window is closed.). Of course, another approach would simply be
> to do "fig.savefig()" after every update to the figure and never use show()
> and ion() (essentially, a non-interactive head-less script).
>
> Hopefully, this helps.
> Ben Root
>
>

On Wed, Oct 17, 2012 at 6:13 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Wed, Oct 17, 2012 at 1:08 PM, Damon McDougall <dam...@gm...>
> wrote:
>>
>> On Wed, Oct 17, 2012 at 5:56 PM, Gökhan Sever <gok...@gm...>
>> wrote:
>> >
>> >
>> > On Wed, Oct 17, 2012 at 10:21 AM, Benjamin Root <ben...@ou...> wrote:
>> >>
>> >>
>> >>
>> >> On Wed, Oct 17, 2012 at 12:17 PM, Gökhan Sever <gok...@gm...>
>> >> wrote:
>> >>>
>> >>> Thanks Mike,
>> >>>
>> >>> Another point I noticed is setting linewidth to 0 (in fill_between
>> >>> function) isn't working as expected when figure is saved as a PDF
>> >>> file.
>> >>>
>> >>> I noticed this while posting a sample script on scipy-users:
>> >>>
>> >>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.py
>> >>>
>> >>> Compare the outputs of pdf and png to see the difference that I am
>> >>> mentioning:
>> >>>
>> >>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.pdf
>> >>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.png
>> >>>
>> >>
>> >> Actually, this is not a bug in mpl. It is a "bug" in various viewers.
>> >> Some viewers have a "minimum" linewidth and will use that for any
>> >> requested
>> >> linewidths smaller than that. Are you using Apple's Preview?
>> >>
>> >> Cheers!
>> >> Ben Root
>> >>
>> >
>> > Hi Ben,
>> >
>> > I was guessing the same way, but trying different viewers doesn't make
>> > any
>> > difference:
>> >
>> > Evince v3.2.1
>> > Xpdf v3.03
>> > Okular v0.14.3
>> >
>> > Could anyone confirm this on a window machine?
>> >
>> > --
>> > Gökhan
>>
>> Confirmed with Preview.app on OS X 10.7.4.
>>
>
> I think it looks ok with the old Adobe viewer on linux (I never bothered
> updating it since I use Evince). Kinda hard to tell the difference between
> grey and greyer... Could somebody include a screenshot of what they are
> seeing?
Sir, the internet has completed your request: http://i.imgur.com/UdRB9.png
>
> Ben Root
>
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Wed, Oct 17, 2012 at 1:08 PM, Damon McDougall
<dam...@gm...>wrote:
> On Wed, Oct 17, 2012 at 5:56 PM, Gökhan Sever <gok...@gm...>
> wrote:
> >
> >
> > On Wed, Oct 17, 2012 at 10:21 AM, Benjamin Root <ben...@ou...> wrote:
> >>
> >>
> >>
> >> On Wed, Oct 17, 2012 at 12:17 PM, Gökhan Sever <gok...@gm...>
> >> wrote:
> >>>
> >>> Thanks Mike,
> >>>
> >>> Another point I noticed is setting linewidth to 0 (in fill_between
> >>> function) isn't working as expected when figure is saved as a PDF file.
> >>>
> >>> I noticed this while posting a sample script on scipy-users:
> >>>
> >>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.py
> >>>
> >>> Compare the outputs of pdf and png to see the difference that I am
> >>> mentioning:
> >>>
> >>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.pdf
> >>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.png
> >>>
> >>
> >> Actually, this is not a bug in mpl. It is a "bug" in various viewers.
> >> Some viewers have a "minimum" linewidth and will use that for any
> requested
> >> linewidths smaller than that. Are you using Apple's Preview?
> >>
> >> Cheers!
> >> Ben Root
> >>
> >
> > Hi Ben,
> >
> > I was guessing the same way, but trying different viewers doesn't make
> any
> > difference:
> >
> > Evince v3.2.1
> > Xpdf v3.03
> > Okular v0.14.3
> >
> > Could anyone confirm this on a window machine?
> >
> > --
> > Gökhan
>
> Confirmed with Preview.app on OS X 10.7.4.
>
>
I think it looks ok with the old Adobe viewer on linux (I never bothered
updating it since I use Evince). Kinda hard to tell the difference between
grey and greyer... Could somebody include a screenshot of what they are
seeing?
Ben Root

On Wed, Oct 17, 2012 at 5:56 PM, Gökhan Sever <gok...@gm...> wrote:
>
>
> On Wed, Oct 17, 2012 at 10:21 AM, Benjamin Root <ben...@ou...> wrote:
>>
>>
>>
>> On Wed, Oct 17, 2012 at 12:17 PM, Gökhan Sever <gok...@gm...>
>> wrote:
>>>
>>> Thanks Mike,
>>>
>>> Another point I noticed is setting linewidth to 0 (in fill_between
>>> function) isn't working as expected when figure is saved as a PDF file.
>>>
>>> I noticed this while posting a sample script on scipy-users:
>>>
>>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.py
>>>
>>> Compare the outputs of pdf and png to see the difference that I am
>>> mentioning:
>>>
>>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.pdf
>>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.png
>>>
>>
>> Actually, this is not a bug in mpl. It is a "bug" in various viewers.
>> Some viewers have a "minimum" linewidth and will use that for any requested
>> linewidths smaller than that. Are you using Apple's Preview?
>>
>> Cheers!
>> Ben Root
>>
>
> Hi Ben,
>
> I was guessing the same way, but trying different viewers doesn't make any
> difference:
>
> Evince v3.2.1
> Xpdf v3.03
> Okular v0.14.3
>
> Could anyone confirm this on a window machine?
>
> --
> Gökhan
Confirmed with Preview.app on OS X 10.7.4.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Wed, Oct 17, 2012 at 10:21 AM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Wed, Oct 17, 2012 at 12:17 PM, Gökhan Sever <gok...@gm...>wrote:
>
>> Thanks Mike,
>>
>> Another point I noticed is setting linewidth to 0 (in fill_between
>> function) isn't working as expected when figure is saved as a PDF file.
>>
>> I noticed this while posting a sample script on scipy-users:
>>
>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.py
>>
>> Compare the outputs of pdf and png to see the difference that I am
>> mentioning:
>>
>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.pdf
>> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.png
>>
>>
> Actually, this is not a bug in mpl. It is a "bug" in various viewers.
> Some viewers have a "minimum" linewidth and will use that for any requested
> linewidths smaller than that. Are you using Apple's Preview?
>
> Cheers!
> Ben Root
>
>
Hi Ben,
I was guessing the same way, but trying different viewers doesn't make any
difference:
Evince v3.2.1
Xpdf v3.03
Okular v0.14.3
Could anyone confirm this on a window machine?
-- 
Gökhan

On 10/16/12 12:29 PM, Jeff Whitaker wrote:
> On 10/16/12 11:20 AM, Rich Signell wrote:
>> Jeff,
>> Yep, that worked! So here is a working example of OWSlib with
>> Basemap: http://nbviewer.ipython.org/3900648/
>>
>> I switched the Basemap projection to 'cyl' because we need to ensure
>> that Basemap and WMS are using the same projection, right? (and since
>> I had requested EPSG:4326 from WMS, that's the 'cyl' in Basemap).
>>
>> Thanks!
>> Rich
> Rich: I took your code and made it into a new example.
>
> https://github.com/matplotlib/basemap/pull/84
>
> I think it may be better not to try to create a wmsimage method, since
> OWSlib.wms.WebMapService is quite a complicated beast to wrap.
>
> -Jeff
Rich: I went ahead and added a wmsimage method to Basemap (similar to 
Klo's implementation) and modified your example to use it. The extra 
**kwargs are just passed on to OWSLib.wms.WebMapService.getmap. Please 
add comments to pull request
https://github.com/matplotlib/basemap/pull/84
-Jeff
>> On Tue, Oct 16, 2012 at 11:38 AM, Jeff Whitaker <js...@fa...> wrote:
>>> On 10/16/12 8:48 AM, Rich Signell wrote:
>>>> Klo & Jeff,
>>>>
>>>> I tried making a concrete example of using OWSlib with Basemap, but
>>>> althought the WMS image looks good, the warpimage does not.
>>>>
>>>> http://nbviewer.ipython.org/3899690/
>>>>
>>>> Do you see where I went wrong?
>>>>
>>>> Thanks,
>>>> Rich
>>> Rich: warpimage assumes the image is of global extent. In your example, I
>>> think you can just pass the image to the basemap imshow method with
>>>
>>> from matplotlib.image import imread
>>> import urllib2
>>> m.imshow(imread(urllib2.urlopen(url)),origin='upper')
>>>
>>> Klo previously mentioned there might be a problem with the png data from the
>>> WMS server being 'chunked', s you might have to use klo's imshow_chunked
>>> function
>>>
>>> http://www.mail-archive.com/mat...@li.../msg25618.html
>>>
>>>
>>> -Jeff
>>>
>>>> On Sat, Oct 13, 2012 at 7:26 PM, klo uo <kl...@gm...> wrote:
>>>>> That's also what that snippet I linked does. You can add it to to Basemap
>>>>> and it should work.
>>>>>
>>>>> However Jeff suggested we use this tiny package OWSlib and handle WMS
>>>>> that
>>>>> way, which is better IMHO, but for some reason we did not got further
>>>>> reply.
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Oct 12, 2012 at 1:31 PM, Rich Signell <rsi...@us...> wrote:
>>>>>> WMS services are required to respond to "GetCapabiltiies" request,
>>>>>> reporting what layers, styles, times, elevations, and projections they
>>>>>> have available. So for example, using the Unidata WMS example below,
>>>>>> if we do:
>>>>>>
>>>>>>
>>>>>>
>>>>>> http://motherlode.ucar.edu:8080/thredds/wms/fmrc/NCEP/NAM/CONUS_12km/NCEP-NAM-CONUS_12km-noaaport_best.ncd?service=WMS&request=GetCapabilities
>>>>>>
>>>>>> we can see from the XML response that the Coordinate Reference Systems
>>>>>> supported are:
>>>>>>
>>>>>> <CRS>EPSG:4326</CRS>
>>>>>> <CRS>CRS:84</CRS>
>>>>>> <CRS>EPSG:41001</CRS>
>>>>>> <CRS>EPSG:3857</CRS>
>>>>>> <CRS>EPSG:27700</CRS>
>>>>>> <CRS>EPSG:3408</CRS>
>>>>>> <CRS>EPSG:3409</CRS>
>>>>>> <CRS>EPSG:32661</CRS>
>>>>>> <CRS>EPSG:32761</CRS>
>>>>>>
>>>>>> And for this server, the supported response types are:
>>>>>> <Format>image/jpeg</Format>
>>>>>> <Format>image/png</Format>
>>>>>> <Format>application/vnd.google-earth.kmz</Format>
>>>>>> <Format>image/gif</Format>
>>>>>>
>>>>>> So I guess one way to proceed if you wanted to use WMS in Matplotlib
>>>>>> and avoid reprojection in python would be to:
>>>>>> 1. do the WMS GetCapabilities request to find the available supported
>>>>>> Coordinate Reference Systems (which will vary with WMS server)
>>>>>> 2. setup Basemap to use one of these CRS
>>>>>> 3. use the bounding box of your current axis (in projection units) as
>>>>>> part of a GetMap request to the WMS.
>>>>>>
>>>>>> -Rich
>>>>>>
>>>>>> On Thu, Oct 11, 2012 at 12:16 AM, klo uo <kl...@gm...> wrote:
>>>>>>> I guess that's it?
>>>>>>>
>>>>>>> warpimage() as it is now, checks if passed image is url, so we can add
>>>>>>> additional check if image is url, with urlparse to deduce image
>>>>>>> coordinates
>>>>>>> and projection if present, then overlay it over already created Basemap
>>>>>>> object.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Don't let slow site performance ruin your business. Deploy New Relic
>>>>>>> APM
>>>>>>> Deploy New Relic app performance management and know exactly
>>>>>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>>>>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>>>>>> http://p.sf.net/sfu/newrelic-dev2dev
>>>>>>> _______________________________________________
>>>>>>> Matplotlib-users mailing list
>>>>>>> Mat...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>>>
>>>>>> --
>>>>>> Dr. Richard P. Signell (508) 457-2229
>>>>>> USGS, 384 Woods Hole Rd.
>>>>>> Woods Hole, MA 02543-1598
>>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On Wed, Oct 17, 2012 at 12:17 PM, Gökhan Sever <gok...@gm...>wrote:
> Thanks Mike,
>
> Another point I noticed is setting linewidth to 0 (in fill_between
> function) isn't working as expected when figure is saved as a PDF file.
>
> I noticed this while posting a sample script on scipy-users:
>
> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.py
>
> Compare the outputs of pdf and png to see the difference that I am
> mentioning:
>
> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.pdf
> http://atmos.uwyo.edu/~gsever/data/test/curvefit_test.png
>
>
Actually, this is not a bug in mpl. It is a "bug" in various viewers.
Some viewers have a "minimum" linewidth and will use that for any requested
linewidths smaller than that. Are you using Apple's Preview?
Cheers!
Ben Root