matplotlib-devel Mailing List for matplotlib (Page 6)

On 9/2/11 1:33 AM, Sandro Tosi wrote:
> Hello,
> I'm trying to download basemap examples tarball from SF but it seems
> to be corrupted - could you confirm/fix it?
>
> Thanks,
Should be fixed now.
-Jeff

On 09/08/2011 03:53 PM, Tiago Bonetti wrote:
> I'm new to github, so forgive me if I'm a litlle lost.
> I have the most recent master branch from github matplotlib
> <https://github.com/matplotlib> / matplotlib
> <https://github.com/matplotlib/matplotlib> public repository...
> I would like to help testing, yet i cant find the dev branch.
It is what you have, the master branch.
Eric
>
> Thanks,
> Tiago Ferreira Bonetti
>
>
> On Thu, Sep 8, 2011 at 10:27 PM, Benjamin Root <ben...@ou...
> <mailto:ben...@ou...>> wrote:
>
>
>
> On Thursday, September 8, 2011, Tiago Bonetti
> <tia...@gm... <mailto:tia...@gm...>> wrote:
> > I was trying for dome time to use the Pyside Backend (qt4Agg with
> pySide), with no success, but after reading the beckend code I've
> finally made it.
> > After installing the 1.0.1 version on my Ubuntu, I've noticed the
> installation doesn't check for pySide what is strange yet, not the
> point here...
> > The trick was quite simple, forcing the QtGui and QtCore to be
> declared from pySide module. This is done inside qt4_compat.py
> checking for the string inside: rcParams['backend.qt4'].
> > This dictionary I don't know where It comes from, so, just
> altering during runtime was enough to make the example
> "embedding_in_qt4.py" work.
> > There is any better way to choose between pySide and pyQt?
> Couldn't they be separated in to individual backends?
> > Yet I understand this information is not easily available on the
> Internet, so i'm trying to share it.
> > Thanks,
> > Tiago Ferreira Bonetti
> >
>
> Tiago,
>
> Have you had a chance to look at the code in the latest
> developmental branch? There was some work over the summer on this,
> and I think it is largely resolved, but testing would be appreciated.
>
> Cheers!
> Ben Root
>
>
>
>
> ------------------------------------------------------------------------------
> Why Cloud-Based Security and Archiving Make Sense
> Osterman Research conducted this study that outlines how and why cloud
> computing security and archiving is rapidly being adopted across the IT
> space for its ease of implementation, lower cost, and increased
> reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I'm new to github, so forgive me if I'm a litlle lost.
I have the most recent master branch from github
matplotlib<https://github.com/matplotlib>/
matplotlib <https://github.com/matplotlib/matplotlib> public repository...
I would like to help testing, yet i cant find the dev branch.
Thanks,
Tiago Ferreira Bonetti
On Thu, Sep 8, 2011 at 10:27 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Thursday, September 8, 2011, Tiago Bonetti <tia...@gm...>
> wrote:
> > I was trying for dome time to use the Pyside Backend (qt4Agg with
> pySide), with no success, but after reading the beckend code I've finally
> made it.
> > After installing the 1.0.1 version on my Ubuntu, I've noticed the
> installation doesn't check for pySide what is strange yet, not the point
> here...
> > The trick was quite simple, forcing the QtGui and QtCore to be declared
> from pySide module. This is done inside qt4_compat.py checking for the
> string inside: rcParams['backend.qt4'].
> > This dictionary I don't know where It comes from, so, just altering
> during runtime was enough to make the example "embedding_in_qt4.py" work.
> > There is any better way to choose between pySide and pyQt? Couldn't they
> be separated in to individual backends?
> > Yet I understand this information is not easily available on the
> Internet, so i'm trying to share it.
> > Thanks,
> > Tiago Ferreira Bonetti
> >
>
> Tiago,
>
> Have you had a chance to look at the code in the latest developmental
> branch? There was some work over the summer on this, and I think it is
> largely resolved, but testing would be appreciated.
>
> Cheers!
> Ben Root

On Thursday, September 8, 2011, Tiago Bonetti <tia...@gm...>
wrote:
> I was trying for dome time to use the Pyside Backend (qt4Agg with pySide),
with no success, but after reading the beckend code I've finally made it.
> After installing the 1.0.1 version on my Ubuntu, I've noticed the
installation doesn't check for pySide what is strange yet, not the point
here...
> The trick was quite simple, forcing the QtGui and QtCore to be declared
from pySide module. This is done inside qt4_compat.py checking for the
string inside: rcParams['backend.qt4'].
> This dictionary I don't know where It comes from, so, just altering during
runtime was enough to make the example "embedding_in_qt4.py" work.
> There is any better way to choose between pySide and pyQt? Couldn't they
be separated in to individual backends?
> Yet I understand this information is not easily available on the
Internet, so i'm trying to share it.
> Thanks,
> Tiago Ferreira Bonetti
>
Tiago,
Have you had a chance to look at the code in the latest developmental
branch? There was some work over the summer on this, and I think it is
largely resolved, but testing would be appreciated.
Cheers!
Ben Root

I was trying for dome time to use the Pyside Backend (qt4Agg with pySide),
with no success, but after reading the beckend code I've finally made it.
After installing the 1.0.1 version on my Ubuntu, I've noticed the
installation doesn't check for pySide what is strange yet, not the point
here...
The trick was quite simple, forcing the QtGui and QtCore to be declared from
pySide module. This is done inside qt4_compat.py checking for the string
inside: rcParams['backend.qt4'].
This dictionary I don't know where It comes from, so, just altering during
runtime was enough to make the example "embedding_in_qt4.py" work.
There is any better way to choose between pySide and pyQt? Couldn't they be
separated in to individual backends?
Yet I understand this information is not easily available on the Internet,
so i'm trying to share it.
Thanks,
Tiago Ferreira Bonetti

On Fri, Sep 2, 2011 at 2:33 AM, Sandro Tosi <mo...@de...> wrote:
> Hello,
> I'm trying to download basemap examples tarball from SF but it seems
> to be corrupted - could you confirm/fix it?
>
>
Actually, yeah, I can't seem to open it. My md5 checksum is:
b76f84b986e689714d44875d0e65a8a6
Jeff, does the file need to be re-uploaded?
Ben Root

Hi,
On Tue, Sep 6, 2011 at 8:38 AM, Michael Droettboom <md...@st...> 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

On Tue, Sep 6, 2011 at 9:53 AM, Michael Droettboom <md...@st...> 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

Hi Jouni,
Am 06.09.2011 18:10, schrieb Jouni K. Seppänen:
> Frank Breitling<fbr...@ai...> 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 <module>
 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

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<mat...@gm...> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On 09/01/2011 09:10 PM, Michael Gilbert wrote:
> John Hunter wrote:
>
>> On Wed, Aug 31, 2011 at 8:49 PM, John Hunter<jd...@gm...> 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

Frank Breitling <fbr...@ai...> 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

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<mat...@gm...> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

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<fbr...@ai...> 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: 	2011年9月06日 10:33:53 +0200
>> Von: 	Frank Breitling<fbr...@ai...>
>> Organisation: 	Leibniz-Institut für Astrophysik Potsdam (AIP)
>> An: 	Jeffrey Spencer<jef...@gm...>
>>
>>
>>
>> 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
>>>> Mat...@li...
>>>> 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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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 <fbr...@ai...> 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: 	2011年9月06日 10:33:53 +0200
> Von: 	Frank Breitling <fbr...@ai...>
> Organisation: 	Leibniz-Institut für Astrophysik Potsdam (AIP)
> An: 	Jeffrey Spencer <jef...@gm...>
>
>
>
> 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
>>> Mat...@li...
>>> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

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: 	2011年9月06日 10:33:53 +0200
Von: 	Frank Breitling <fbr...@ai...>
Organisation: 	Leibniz-Institut für Astrophysik Potsdam (AIP)
An: 	Jeffrey Spencer <jef...@gm...>
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
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hi list,
Once again, we are looking for a junior developer to work on the
scikit-learn. Below is the official job posting. Unofficially I would
like to stress that this is a unique opportunity to be payed for two
years to work on learning and improving the scientific Python toolstack. 
Gael
________________________________________________________________________________
**Job Description**
INRIA is looking to hire a young graduate on a 2-year position to help
with the community-driven development of the open source machine learning
in Python library, scikit-learn. The scikit-learn is one of the major
machine-learning libraries in Python. It aims to be state-of-the-art on
mid-size to large datasets by harnessing the power of the scientific
Python toolstack.
Speaking French is not a requirement, as it is an international team.
**Requirements**
* Programming skills in Python and C/C++
* Understanding of quality assurance in software development: test-driven programming, version control, technical documentation.
* Some knowledge of Linux/Unix
* Software design skills
* Knowledge of open-source development and community-driven environments
* Good technical English level
* An experience in statistical learning or a mathematical-oriented mindset is a plus
* We can only hire a young-graduate that has received a masters or equivalent degree at most a year ago.
**About the company**
INRIA is the French computer science research institute. It recognized
word-wide as one of the leading research institutions and has a strong
expertise in machine learning. You will be working in the `Parietal team
<https://parietal.saclay.inria.fr/>`_ that makes a heavy use of Python
for brain imaging analysis.
Parietal is a small research team (around 10 people) with an excellent
technical knowledge of scientific and numerical computing in Python as
well as a fine understanding of algorithmic issues in machine learning
and statistics. Parietal is committed to investing in scikit-learn.
Working at Parietal is a unique opportunity to improve your skills in
machine learning and numerical computing in Python. In addition, working
full time on the scikit-learn, a very active open-source project, will
give you premium experience of open source community management and 
collaborative project development.
 
**Contact Info:**
* **Technical Contact**: Bertand Thirion
* **E-mail contact**: ber...@in...
* **HR Contact**: Marie Domingues
* **E-mail Contact**: mar...@in... 
* **No telecommuting**

On Fri, Sep 2, 2011 at 2:16 PM, Eric Firing <ef...@ha...> wrote:
> On 09/02/2011 08:54 AM, Eric Firing wrote:
>
> > Now I see it: all the other backends are simply setting constants in
> > their cursord, so they are not calling the functions that create the
> > cursors until runtime; backend_gtk is calling the functions at import
> > time. This is a design deficiency that will be easy to fix, and will
> > help prevent quite a few problems (including problems I have run into
> > myself).
> >
> > I will take care of it today or tomorrow.
> >
> > Eric
>
> I was too optimistic. Moving the cursor creation to runtime is easy,
> but it triggers an avalanche of warnings and errors, sometimes ending in
> a segfault, if one tries to plot anything when there is no X display.
> Better to leave it the way it is, failing at import.
>
> Eric
>
>
That's too bad. Actually, a better, more generic solution would be if there
was some way for sphinx to create documentation without actually performing
an import. This would be valuable for backends like cocoaagg and macosx
backends as those two require PyObjC which (AFAICT) can't be installed on a
non-mac system.
Anyway, I had some free time and did some grunt-work. Please see my branch
here:
https://github.com/WeatherGod/matplotlib/compare/docfix%2Fbackends
The entires in the TOCs probably need some smarter reorganizatiion (fltkagg
got added to the wrong place...), and I didn't try building these docs in a
headless environment, so I don't know which ones would fail in that
situation.
Cheers!
Ben Root

On 09/02/2011 08:54 AM, Eric Firing wrote:
> Now I see it: all the other backends are simply setting constants in
> their cursord, so they are not calling the functions that create the
> cursors until runtime; backend_gtk is calling the functions at import
> time. This is a design deficiency that will be easy to fix, and will
> help prevent quite a few problems (including problems I have run into
> myself).
>
> I will take care of it today or tomorrow.
>
> Eric
I was too optimistic. Moving the cursor creation to runtime is easy, 
but it triggers an avalanche of warnings and errors, sometimes ending in 
a segfault, if one tries to plot anything when there is no X display. 
Better to leave it the way it is, failing at import.
Eric

On 09/02/2011 04:48 AM, Benjamin Root wrote:
> On Wed, Aug 31, 2011 at 10:51 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
> On 08/31/2011 05:00 PM, Trevor J Christensen wrote:
> > I went here:
> >
> > http://matplotlib.sourceforge.net/api/index_backend_api.html
> >
> > and didn't see tkagg listed.
> >
> > Trevor
>
> Trevor,
>
> Thank you. It is still missing from the devel branch, along with
> several others. I can see how this could cause some confusion. Maybe
> we can get it fixed before the next release, maybe not.
>
> Part of the problem here is that auto-generation of docs saves a huge
> amount of work, but can also lead to problems, of which this is just one
> example.
>
> Eric
>
>
> It wouldn't be that difficult to add references to those other backends,
> however I do not know how complete their documentations are. As an
> interesting note, the GTKAgg API docs are currently commented out with a
> note saying that an active X-window session is needed to import the GTK
> backends. Was this preventing the GTK docs from building? How come do
> other GUI backends still build fine?
Now I see it: all the other backends are simply setting constants in 
their cursord, so they are not calling the functions that create the 
cursors until runtime; backend_gtk is calling the functions at import 
time. This is a design deficiency that will be easy to fix, and will 
help prevent quite a few problems (including problems I have run into 
myself).
I will take care of it today or tomorrow.
Eric
>
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 09/02/2011 04:48 AM, Benjamin Root wrote:
> On Wed, Aug 31, 2011 at 10:51 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> wrote:
>
> On 08/31/2011 05:00 PM, Trevor J Christensen wrote:
> > I went here:
> >
> > http://matplotlib.sourceforge.net/api/index_backend_api.html
> >
> > and didn't see tkagg listed.
> >
> > Trevor
>
> Trevor,
>
> Thank you. It is still missing from the devel branch, along with
> several others. I can see how this could cause some confusion. Maybe
> we can get it fixed before the next release, maybe not.
>
> Part of the problem here is that auto-generation of docs saves a huge
> amount of work, but can also lead to problems, of which this is just one
> example.
>
> Eric
>
>
> It wouldn't be that difficult to add references to those other backends,
> however I do not know how complete their documentations are. As an
> interesting note, the GTKAgg API docs are currently commented out with a
> note saying that an active X-window session is needed to import the GTK
> backends. Was this preventing the GTK docs from building? How come do
> other GUI backends still build fine?
That seems to be just a peculiarity of the particular gui toolkits. It 
is possible to import the others without a display; they don't fail 
until one tries to plot something.
Eric
>
> Ben Root
>

On Wed, Aug 31, 2011 at 10:51 PM, Eric Firing <ef...@ha...> wrote:
> On 08/31/2011 05:00 PM, Trevor J Christensen wrote:
> > I went here:
> >
> > http://matplotlib.sourceforge.net/api/index_backend_api.html
> >
> > and didn't see tkagg listed.
> >
> > Trevor
>
> Trevor,
>
> Thank you. It is still missing from the devel branch, along with
> several others. I can see how this could cause some confusion. Maybe
> we can get it fixed before the next release, maybe not.
>
> Part of the problem here is that auto-generation of docs saves a huge
> amount of work, but can also lead to problems, of which this is just one
> example.
>
> Eric
>
>
It wouldn't be that difficult to add references to those other backends,
however I do not know how complete their documentations are. As an
interesting note, the GTKAgg API docs are currently commented out with a
note saying that an active X-window session is needed to import the GTK
backends. Was this preventing the GTK docs from building? How come do
other GUI backends still build fine?
Ben Root

Hello,
I'm trying to download basemap examples tarball from SF but it seems
to be corrupted - could you confirm/fix it?
Thanks,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

John Hunter wrote:
> On Wed, Aug 31, 2011 at 8:49 PM, John Hunter <jd...@gm...> 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?
Best wishes,
Mike

On Wed, Aug 31, 2011 at 20:16, Matthew Brett <mat...@gm...> 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