[matplotlib-devel] Fwd: Re: [Matplotlib-users] Change JPG compression ratio in savefig
Dear developers, Since I can't reach the SF tracker, I send my feature request for a JPG compression switch with savefig to the developer list. Details follow below. I hope you can help. Cheers Frank Original-Nachricht Betreff:Re: [Matplotlib-users] Change JPG compression ratio in savefig Datum: Tue, 06 Sep 2011 10:33:53 +0200 Von:Frank Breitling Organisation: Leibniz-Institut für Astrophysik Potsdam (AIP) An: Jeffrey Spencer Jeff, thanks for the hint. But I really want to reduce the compression. I would like to write a feature request, but the link to the tracker (http://sourceforge.net/tracker2/?group_id=80706) at http://matplotlib.sourceforge.net/ gave me "Error - The Tracker has been disabled for this group". Should I send my request through the developer list? Cheers Frank Am 05.09.2011 20:15, schrieb Jeffrey Spencer: You can use dpi=600 as a parameter to increase the resolution but I'm not sure if that's what you mean. If you mean the actual compression strategy used like to Jpeg2000 per se. Might have to do that after saving the file with an image library (for example, PIL). Cheers, Jeff On 09/06/2011 03:21 AM, Frank Breitling wrote: Hi, I am using matplotlib.savefig to save my figures as JPEG files. Now I need to reduce the JPG compression ratio. How can I do this? Any hint is appreciated. Frank -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Matplotlib-users mailing list matplotlib-us...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Change JPG compression ratio in savefig
When saving a figure in JPEG format *via the agg backend*, the following extra keyword arguments have an effect: *quality*: The image quality, on a scale from 1 (worst) to 95 (best). The default is 75. Values above 95 should be avoided; 100 completely disables the JPEG quantization stage. *optimize*: If present, indicates that the encoder should make an extra pass over the image in order to select optimal encoder settings. *progressive*: If present, indicates that this image should be stored as a progressive JPEG file. If a backend implements its JPEG saving differently, these might not do anything -- this seems to be the case for the MacOSX backend, for example. Frank Breitling writes: > Dear developers, > > Since I can't reach the SF tracker, I send my feature request for a > JPG compression switch with savefig to the developer list. > Details follow below. > I hope you can help. > > Cheers > > Frank > > > Original-Nachricht > Betreff: Re: [Matplotlib-users] Change JPG compression ratio in savefig > Datum:Tue, 06 Sep 2011 10:33:53 +0200 > Von: Frank Breitling > Organisation: Leibniz-Institut für Astrophysik Potsdam (AIP) > An: Jeffrey Spencer > > > > Jeff, thanks for the hint. > But I really want to reduce the compression. > I would like to write a feature request, but the link to the tracker > (http://sourceforge.net/tracker2/?group_id=80706) at > http://matplotlib.sourceforge.net/ gave me "Error - The Tracker has been > disabled for this group". > Should I send my request through the developer list? > > Cheers > > Frank > > > Am 05.09.2011 20:15, schrieb Jeffrey Spencer: >> You can use dpi=600 as a parameter to increase the resolution but I'm >> not sure if that's what you mean. If you mean the actual compression >> strategy used like to Jpeg2000 per se. Might have to do that after >> saving the file with an image library (for example, PIL). >> >> Cheers, >> Jeff >> >> On 09/06/2011 03:21 AM, Frank Breitling wrote: >>> Hi, >>> >>> I am using matplotlib.savefig to save my figures as JPEG files. >>> Now I need to reduce the JPG compression ratio. >>> How can I do this? >>> >>> Any hint is appreciated. >>> >>> Frank >>> >>> >>> -- >>> >>> Special Offer -- Download ArcSight Logger for FREE! >>> Finally, a world-class log management solution at an even better >>> price-free! And you'll get a free "Love Thy Logs" t-shirt when you >>> download Logger. Secure your free ArcSight Logger TODAY! >>> http://p.sf.net/sfu/arcsisghtdev2dev >>> ___ >>> Matplotlib-users mailing list >>> matplotlib-us...@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> > > -- > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Jouni K. Seppänen http://www.iki.fi/jks -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Change JPG compression ratio in savefig
Dear Jouni, Thank you very much for your reply. I am using the GTKAgg backend which was the only one I found with support for JPEG. Although the options quality='95' and quality=1 didn't produce an error they didn't have any effect either on a Ubuntu system. Is there anything else I could try? Besides, it would be very useful to find these options in the documentation or the help if there is a situation in which they work. Frank Am 06.09.2011 15:41, schrieb Jouni K. Seppänen: > When saving a figure in JPEG format *via the agg backend*, the following > extra keyword arguments have an effect: > > *quality*: The image quality, on a scale from 1 (worst) to > 95 (best). The default is 75. Values above 95 should > be avoided; 100 completely disables the JPEG > quantization stage. > > *optimize*: If present, indicates that the encoder should > make an extra pass over the image in order to select > optimal encoder settings. > > *progressive*: If present, indicates that this image > should be stored as a progressive JPEG file. > > If a backend implements its JPEG saving differently, these might not do > anything -- this seems to be the case for the MacOSX backend, for > example. > > Frank Breitling writes: > >> Dear developers, >> >> Since I can't reach the SF tracker, I send my feature request for a >> JPG compression switch with savefig to the developer list. >> Details follow below. >> I hope you can help. >> >> Cheers >> >> Frank >> >> >> Original-Nachricht >> Betreff: Re: [Matplotlib-users] Change JPG compression ratio in savefig >> Datum: Tue, 06 Sep 2011 10:33:53 +0200 >> Von: Frank Breitling >> Organisation:Leibniz-Institut für Astrophysik Potsdam (AIP) >> An: Jeffrey Spencer >> >> >> >> Jeff, thanks for the hint. >> But I really want to reduce the compression. >> I would like to write a feature request, but the link to the tracker >> (http://sourceforge.net/tracker2/?group_id=80706) at >> http://matplotlib.sourceforge.net/ gave me "Error - The Tracker has been >> disabled for this group". >> Should I send my request through the developer list? >> >> Cheers >> >> Frank >> >> >> Am 05.09.2011 20:15, schrieb Jeffrey Spencer: >>> You can use dpi=600 as a parameter to increase the resolution but I'm >>> not sure if that's what you mean. If you mean the actual compression >>> strategy used like to Jpeg2000 per se. Might have to do that after >>> saving the file with an image library (for example, PIL). >>> >>> Cheers, >>> Jeff >>> >>> On 09/06/2011 03:21 AM, Frank Breitling wrote: Hi, I am using matplotlib.savefig to save my figures as JPEG files. Now I need to reduce the JPG compression ratio. How can I do this? Any hint is appreciated. Frank -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Matplotlib-users mailing list matplotlib-us...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users >> -- >> Special Offer -- Download ArcSight Logger for FREE! >> Finally, a world-class log management solution at an even better >> price-free! And you'll get a free "Love Thy Logs" t-shirt when you >> download Logger. Secure your free ArcSight Logger TODAY! >> http://p.sf.net/sfu/arcsisghtdev2dev >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] github workflow
I think most of the points being made here are valid. However, a common occurrence (at least for me) is for a user to struggle against a bug that I'm currently working on in one of my branches. Looking at the main repository, it isn't very discoverable that a solution may already exist, and the user can waste time wondering if it's a bug or user error etc. Perhaps a compromise between these two approaches would be to have a wiki page which is a directory of any branches that developers consider interesting and want to point people toward? Maybe that's just creating busy work, of course. Mike On 09/01/2011 05:07 AM, Fernando Perez wrote: > On Wed, Aug 31, 2011 at 20:16, Matthew Brett wrote: >> The issue being - why not have all the development branches in the >> same main repo? >> >> Because: >> >> a) Everyone needs write access to the main repo >> b) It's much less tempting to start experimental and highly unstable branches >> c) You can get a very similar effect by adding remotes to your own repo. >> d) It only very slightly simplifies an unusual case (what's developer >> X working on today?). > Limited internet access here, so no time for a long discussoin... Just > to say that I'm totally in agreement with Matthew here. > > We only make branches in the main ipython repo under exceptional > circumstances, when there's a major piece of work that requires > multiple-developer commit collaboration to beat into shape and > cross-pulling from personal repos would just get annoying. But once > those are ready and merge we delete them as visible branches right > away. > > For example, since we moved to github, we've only done this *twice*: > once for the big parallel rewrite, and once for the notebook work. > Both of these were *major* efforts that took months to shape up, so it > made sense to have them in there. But we make such a decision only > for such special cases, otherwise following the workflow Matthew > points out seems to work really well. > > Once you get into the habit of using multiple remotes to get a handle > of an entire team's worth of contributions to a project, you realize > how simple and effective it is. > > Cheers, > > f > > -- > Special Offer -- Download ArcSight Logger for FREE! > Finally, a world-class log management solution at an even better > price-free! And you'll get a free "Love Thy Logs" t-shirt when you > download Logger. Secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsisghtdev2dev > ___ > Matplotlib-devel mailing list > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Change JPG compression ratio in savefig
Frank Breitling writes:
> I am using the GTKAgg backend which was the only one I found with
> support for JPEG.
I think that backend inherits its support from the GTK backend, which
uses GDK for saving JPEG files, and doesn't do anything with those
options.
I just realized that the Agg support depends on PIL. If you have that
installed, this script should produce a really low-quality JPEG file:
--
#!/usr/bin/env python
import matplotlib
matplotlib.use('agg')
import pylab
pylab.plot([3,1,4,1,5,9,2], lw=4)
pylab.savefig('foo.jpeg', quality=1)
--
> Although the options quality='95' and quality=1 didn't produce an error
> they didn't have any effect either on a Ubuntu system.
> Is there anything else I could try?
If you do have PIL, you could use the non-interactive agg backend. If
you do need to use an interactive backend that doesn't have support for
these options, you could look at the implementation of
FigureCanvasBase.print_jpg and replicate its functionality.
> Besides, it would be very useful to find these options in the
> documentation or the help if there is a situation in which they work.
The options are documented, but it's not very easy to find them:
http://matplotlib.sourceforge.net/api/backend_bases_api.html#matplotlib.backend_bases.FigureCanvasBase.print_jpeg
--
Jouni K. Seppänen
http://www.iki.fi/jks
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Issue with colored latex text on plots
On 09/01/2011 09:10 PM, Michael Gilbert wrote:
> John Hunter wrote:
>
>> On Wed, Aug 31, 2011 at 8:49 PM, John Hunter wrote:
>>
Note that I'm not subscribed to this list, so please CC me on replies.
>>> That won't work because mpl converts all tex png raster to black and
>>> white and handles color on its own in post-processing. The following
>>> does work:
> [...]
>> But since you set usetex, you shouldn't need the $ escapes and the
>> literal rm font. It should be enough to do:
>>
>> pylab.title( r'colored title wanted 2.5', color='blue' )\
> Hi,
>
> Thanks for the insight. What I'm really trying to get is multiple
> colors in the title text. For example, if mpl didn't convert all text
> to black, I would want the following to produce blue and red text:
>
>pylab.rc( 'text' , usetex=True )
>pylab.rc( 'text.latex' , preamble='\usepackage[usenames]{color}' )
>pylab.title( '\\textcolor{Blue}{blue part} \\textcolor{Red}{red part}')
>
> Is there a particular reason why mpl has to convert png colored text
> to black and white?
It works that way so that colored text can be specified by matplotlib
rather than in LaTeX, therefore the color of text doesn't change based
on the value of text.usetex. Matplotlib itself doesn't support
multi-colored text in its own simple text layout algorithm. It's
probably possible to add an rcParam that would change the behavior to
get the full color text from LaTeX and use that, but I don't think that
should be the default behavior.
Mike
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] github workflow
It occurred to me that it's also possible to file pull requests very early on while working on a branch. This would make these branches that others may care about more visible. We would just want some convention to say "wait -- this branch isn't done yet, don't merge". Mike On 09/06/2011 11:38 AM, Michael Droettboom wrote: > I think most of the points being made here are valid. However, a common > occurrence (at least for me) is for a user to struggle against a bug > that I'm currently working on in one of my branches. Looking at the > main repository, it isn't very discoverable that a solution may already > exist, and the user can waste time wondering if it's a bug or user error > etc. Perhaps a compromise between these two approaches would be to have > a wiki page which is a directory of any branches that developers > consider interesting and want to point people toward? Maybe that's just > creating busy work, of course. > > Mike > > On 09/01/2011 05:07 AM, Fernando Perez wrote: >> On Wed, Aug 31, 2011 at 20:16, Matthew Brett >> wrote: >>> The issue being - why not have all the development branches in the >>> same main repo? >>> >>> Because: >>> >>> a) Everyone needs write access to the main repo >>> b) It's much less tempting to start experimental and highly unstable >>> branches >>> c) You can get a very similar effect by adding remotes to your own repo. >>> d) It only very slightly simplifies an unusual case (what's developer >>> X working on today?). >> Limited internet access here, so no time for a long discussoin... Just >> to say that I'm totally in agreement with Matthew here. >> >> We only make branches in the main ipython repo under exceptional >> circumstances, when there's a major piece of work that requires >> multiple-developer commit collaboration to beat into shape and >> cross-pulling from personal repos would just get annoying. But once >> those are ready and merge we delete them as visible branches right >> away. >> >> For example, since we moved to github, we've only done this *twice*: >> once for the big parallel rewrite, and once for the notebook work. >> Both of these were *major* efforts that took months to shape up, so it >> made sense to have them in there. But we make such a decision only >> for such special cases, otherwise following the workflow Matthew >> points out seems to work really well. >> >> Once you get into the habit of using multiple remotes to get a handle >> of an entire team's worth of contributions to a project, you realize >> how simple and effective it is. >> >> Cheers, >> >> f >> >> -- >> Special Offer -- Download ArcSight Logger for FREE! >> Finally, a world-class log management solution at an even better >> price-free! And you'll get a free "Love Thy Logs" t-shirt when you >> download Logger. Secure your free ArcSight Logger TODAY! >> http://p.sf.net/sfu/arcsisghtdev2dev >> ___ >> Matplotlib-devel mailing list >> Matplotlib-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Change JPG compression ratio in savefig
Hi Jouni,
Am 06.09.2011 18:10, schrieb Jouni K. Seppänen:
> Frank Breitling writes:
>
>> I am using the GTKAgg backend which was the only one I found with
>> support for JPEG.
> I think that backend inherits its support from the GTK backend, which
> uses GDK for saving JPEG files, and doesn't do anything with those
> options.
>
> I just realized that the Agg support depends on PIL. If you have that
> installed, this script should produce a really low-quality JPEG file:
>
> --
> #!/usr/bin/env python
> import matplotlib
> matplotlib.use('agg')
> import pylab
>
> pylab.plot([3,1,4,1,5,9,2], lw=4)
> pylab.savefig('foo.jpeg', quality=1)
> --
I have the PIL module installed on my system (if this is what you mean)
but when I run your example I see
lfe001:~$ jpg.py
Traceback (most recent call last):
File "./jpg.py", line 7, in
pylab.savefig('foo.jpeg', quality=1)
File
"/data/sys/opt/pythonlibs/lib/python2.5/site-packages/matplotlib/pyplot.py",
line 356, in savefig
return fig.savefig(*args, **kwargs)
File
"/data/sys/opt/pythonlibs/lib/python2.5/site-packages/matplotlib/figure.py",
line 1032, in savefig
self.canvas.print_figure(*args, **kwargs)
File
"/data/sys/opt/pythonlibs/lib/python2.5/site-packages/matplotlib/backend_bases.py",
line 1420, in print_figure
'%s.' % (format, ', '.join(formats)))
ValueError: Format "jpeg" is not supported.
Supported formats: emf, eps, pdf, png, ps, raw, rgba, svg, svgz.
> If you do have PIL, you could use the non-interactive agg backend. If
> you do need to use an interactive backend that doesn't have support
> for these options, you could look at the implementation of
> FigureCanvasBase.print_jpg and replicate its functionality.
Sounds complicated. I don't know how to do that.
>> Besides, it would be very useful to find these options in the
>> documentation or the help if there is a situation in which they work.
> The options are documented, but it's not very easy to find them:
>
> http://matplotlib.sourceforge.net/api/backend_bases_api.html#matplotlib.backend_bases.FigureCanvasBase.print_jpeg
>
Well, I think it should also be listed at
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.savefig
.
Frank
--
Special Offer -- Download ArcSight Logger for FREE!
Finally, a world-class log management solution at an even better
price-free! And you'll get a free "Love Thy Logs" t-shirt when you
download Logger. Secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsisghtdev2dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] github workflow
On Tue, Sep 6, 2011 at 9:53 AM, Michael Droettboom wrote: > It occurred to me that it's also possible to file pull requests very > early on while working on a branch. This would make these branches that > others may care about more visible. We would just want some convention > to say "wait -- this branch isn't done yet, don't merge". > We do that all the time: we simply say "this PR isn't meant for merge yet, just to get the discussion going while the problem is worked on". In IPython, we've merged over 250 PRs since switching to github, and I think we've had *two* long-lived branches in the main repo (newparallel and htmlnotebook). I still think that's the right approach, as situations like these should be exceptional. I think getting used to many long-lived branches in the main repo precisely encourages the kind of workflow that leads to hard-to-review, hard-to-integrate branches. By *not* putting them in the main repo, there's a certain pressure on keeping things small, self-contained and easy to review in little pull requests. Each time we've done one of these monster branches there's been a solid reason to do it, but it has required summoning extra resources, committing big chunks of time for difficult and lengthy review periods, and being very careful about how they can go out of sync with the rest of the repo. So while occasionally necessary, these things have such a high cost that I absolutely want a workflow that discourages them in everyday practice. HTH, f -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] github workflow
Hi, On Tue, Sep 6, 2011 at 8:38 AM, Michael Droettboom wrote: > I think most of the points being made here are valid. However, a common > occurrence (at least for me) is for a user to struggle against a bug > that I'm currently working on in one of my branches. Looking at the > main repository, it isn't very discoverable that a solution may already > exist, and the user can waste time wondering if it's a bug or user error > etc. Perhaps a compromise between these two approaches would be to have > a wiki page which is a directory of any branches that developers > consider interesting and want to point people toward? Maybe that's just > creating busy work, of course. Maybe the summary is that putting the branches in the main repo labels those branches somehow. You're suggesting the label means 'you might consider merging these to see if they fix your bug'. John is suggesting the label means 'here are the main threads of development going on'. Of course you have another virtual label which is 'branch in pull request state'. Maybe, as Fernando says, that's the best label to use for a branch that the user might consider merging? See you, Matthew -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
