matplotlib-devel Mailing List for matplotlib

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
>