matplotlib-devel Mailing List for matplotlib

On Tue, Apr 7, 2009 at 18:06, Andrew Straw <str...@as...> wrote:
> John Hunter wrote:
>> We are not that far away, at least for src snapshots, os x binaries,
>> and the docs. The windows binary would take some work, as would a
>> linux binary, eg a debian package.
> FWIW, the Debian packagers will want to make their own .debs from the
> source package.
I'm ready and waiting for a shiny new release to give our beloved
Debian users a package to install ;)
In unstable we have a "rather old" release, 0.98.3, since I was asked
to not upload 0.98.5.2 to the main audience (it's now in experimental,
JFTR).
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

>
> BTW, my ideas were meant more as "how to wedge MPL quickly into glipy
> with a minimum of work" rather than "a talented programmer with one 
> year
> of free time to come up with the coolest scientific workflow GUI" 
> variety.
Sorry, I did not understood your proposal in the first place...
That might be a good thing to try, I'll have a look at as soon as I 
have more free time.
Nicolas

John Hunter wrote:
[...]
>> And is there a release schedule in mind? Any prospect of more
>> thoroughly automating official releases and of adding svn snapshot
>> releases? And of following numpy's buildbot example?
>>
>> I don't think I can help with any of this; I am just casting about to
>> see if there might be someone on the list who is interested and can
>> break loose some time.
> 
> We are not that far away, at least for src snapshots, os x binaries,
> and the docs. The windows binary would take some work, as would a
> linux binary, eg a debian package. I am definitely for it, but one or
> more of us will have to step up and push it through.
For snapshots, I think that packages are needed only for OS X and 
Windows. Anyone who is going to be running snapshots on linux should be 
able to build from a tarball or svn. (And they should be installing in 
/usr/local or a private location.) The only step that might be nice to 
make that easier would be to list the package dependencies for common 
distros--that is, not just in generic form, but the actual names.
Eric

Nicolas Rougier wrote:
> 
> What I do generally to have "nice" OpenGL output is to render 
> screenshots at high resolution and then use something like gimp to 
> resize them. I agree that it is far from optimal but it's pretty 
> decent for a scientific paper. Other solutions are vector rendering of 
> scene (using gl2ps for example) or the texture anti-aliasing technique 
> (http://homepage.mac.com/arekkusu/bugs/invariance/TexAA.html).
Yes. That is why I said a "naive" implementation.
> But, beside rendering issue, I think an OpenGL backend could be useful 
> for experiments involving very fast rendering of large arrays. Using 
> OpenGL texture, you can render 1000x1000 arrays with continuous update 
> of data (on recent machines).
Yes. I wrote a module pygarrayimage for just that:
http://code.astraw.com/projects/motmot/pygarrayimage.html
BTW, my ideas were meant more as "how to wedge MPL quickly into glipy
with a minimum of work" rather than "a talented programmer with one year
of free time to come up with the coolest scientific workflow GUI" variety.
-Andrew

What I do generally to have "nice" OpenGL output is to render 
screenshots at high resolution and then use something like gimp to 
resize them. I agree that it is far from optimal but it's pretty 
decent for a scientific paper. Other solutions are vector rendering of 
scene (using gl2ps for example) or the texture anti-aliasing technique 
(http://homepage.mac.com/arekkusu/bugs/invariance/TexAA.html).
But, beside rendering issue, I think an OpenGL backend could be useful 
for experiments involving very fast rendering of large arrays. Using 
OpenGL texture, you can render 1000x1000 arrays with continuous update 
of data (on recent machines).
Nicolas
On 7 Apr, 2009, at 19:05 , Andrew Straw wrote:
> Nicolas Rougier wrote:
>>
>> I read the thread about mplot3d and the work that has been done by
>> Jonathan Taylor. I wonder if an OpenGL backend is necessary at all.
>> Jonathan's work seems to be great for simple 3D plotting while the
>> mayavi mlab module is here for more "serious" rendering. I think I
>> will concentrate my efforts on a simple GL terminal for IPython with
>> embedded visualization capability. As for sympy (and because it uses
>> pyglet), I guess the integration should be straight forward.
>>
>> Last version of the ipython GL terminal is on launchpad:
>> https://launchpad.net/glipy
>
> Hi Nicolas, I haven't tried your glipy terminal, but it looks very
> interesting.
>
> The main issue with an OpenGL backend for MPL is simply that a naive
> implementation is going to look ugly when compared, pixel-by-pixel,
> against the Agg or cairo backends to generate bitmaps. Agg and cairo 
> are
> very good at drawing anti-aliased lines, whereas one must jump through
> hoops to get consumer OpenGL cards to render lines well.
>
> Here's an idea -- an OpenGLAgg backend that actually uses Agg for all
> the rendering, but blits the results to an OpenGL texture for display.
> Thus, the backend would really just be glue between the existing Agg
> backend and pyglet.
>
> -Andrew
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Nicolas Rougier wrote:
> 
> I read the thread about mplot3d and the work that has been done by 
> Jonathan Taylor. I wonder if an OpenGL backend is necessary at all. 
> Jonathan's work seems to be great for simple 3D plotting while the 
> mayavi mlab module is here for more "serious" rendering. I think I 
> will concentrate my efforts on a simple GL terminal for IPython with 
> embedded visualization capability. As for sympy (and because it uses 
> pyglet), I guess the integration should be straight forward.
> 
> Last version of the ipython GL terminal is on launchpad:
> https://launchpad.net/glipy
Hi Nicolas, I haven't tried your glipy terminal, but it looks very
interesting.
The main issue with an OpenGL backend for MPL is simply that a naive
implementation is going to look ugly when compared, pixel-by-pixel,
against the Agg or cairo backends to generate bitmaps. Agg and cairo are
very good at drawing anti-aliased lines, whereas one must jump through
hoops to get consumer OpenGL cards to render lines well.
Here's an idea -- an OpenGLAgg backend that actually uses Agg for all
the rendering, but blits the results to an OpenGL texture for display.
Thus, the backend would really just be glue between the existing Agg
backend and pyglet.
-Andrew

I read the thread about mplot3d and the work that has been done by 
Jonathan Taylor. I wonder if an OpenGL backend is necessary at all. 
Jonathan's work seems to be great for simple 3D plotting while the 
mayavi mlab module is here for more "serious" rendering. I think I 
will concentrate my efforts on a simple GL terminal for IPython with 
embedded visualization capability. As for sympy (and because it uses 
pyglet), I guess the integration should be straight forward.
Last version of the ipython GL terminal is on launchpad:
 https://launchpad.net/glipy
Nicolas
On 7 Apr, 2009, at 00:38 , Cohen-Tanugi Johann wrote:
> There has been a recent thread discussing sympy interface to pyglet 
> in the context of matplotlib refactoring of the 3D code. See thread 
> named 'Updating MPlot3D to a more recent matplotlib.'
> If you are porting pyglet interface to Ipython, Ondrej might be 
> happy to see his sympy 3D plotting routines go there as well :)
> cheers,
> Johann
>
> Nicolas Rougier wrote:
>> Sure, thread about IPython integration to be continued on ipython- 
>> dev list...
>>
>> Nicolas
>>
>> On 3 Apr, 2009, at 19:07 , Fernando Perez wrote:
>>
>>
>>> On Fri, Apr 3, 2009 at 10:00 AM, Nicolas Rougier
>>> <Nic...@lo...> wrote:
>>>
>>>> Sorry for that, I coded it on linux and just tested on mac.
>>>> I fixed the error and upload the new version on the same link. 
>>>> Tell me if
>>>> it's ok.
>>>>
>>> Great!
>>>
>>> Would you have any interest in having this be shipped/developed as
>>> part of IPython itself?
>>>
>>> You are using a fair amount of internals of the ipython machinery, 
>>> and
>>> we're getting ready for a large cleanup. Having your code shipped
>>> with ipython itself would give it perhaps more exposure, as well as
>>> allow it to evolve in sync with the rest of the API, since we could
>>> test it as the internals change.
>>>
>>> I think it would be great to ship this with ipython itself, and I'm
>>> sure you'd get help and contributions from the rest of the ipython
>>> team as well...
>>>
>>> Best,
>>>
>>> f
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>

John Hunter wrote:
> In general, only very clear bugfixes which are unlikely to result in
> "surprise" breakages should go in. The _png patch, though a bug fix,
> has more of the feel of a feature enhancement, and given its
> complexity, should probably not go in to the branch unless someone
> makes a compelling case (though I am very excited to see it go in to
> the trunk).
> 
OK, I wasn't sure about it when I put it in. Shall I back it out?
> We are not that far away, at least for src snapshots, os x binaries,
> and the docs. The windows binary would take some work, as would a
> linux binary, eg a debian package.
FWIW, the Debian packagers will want to make their own .debs from the
source package.
Also note that the Windows binaries may take more effort than normal --
Python 2.6 is built with a different MS compiler than before.

On Sun, Apr 5, 2009 at 6:38 PM, Eric Firing <ef...@ha...> wrote:
> It is not always clear what should go in the 0.98.5 maintenance branch.
> For example, is the _png.cpp patch by Tobias, committed by Andrew, a
> bug fix or a new feature? I would have said the latter, but I can see
> arguments either way.
>
> More generally, how long do we need to keep updating this maintenance
> branch?
>
I have been meaning to do a release from the branch for some time, but
haven't gotten it done. Charlie, if you are out there and have some
time, please forge ahead. Otherwise, I will devote some time to it
next week when I am back from vacation.
In general, only very clear bugfixes which are unlikely to result in
"surprise" breakages should go in. The _png patch, though a bug fix,
has more of the feel of a feature enhancement, and given its
complexity, should probably not go in to the branch unless someone
makes a compelling case (though I am very excited to see it go in to
the trunk).
As soon as we get the branch release out, I would like to push to get
a trunk release out as soon as it is ready, and all the remaining
outstanding features that people are working on get put in. Then the
trunk will become the branch, and the branch will be finished, either
removed or allowed to linger for a while and then removed. But I
think this should be the last release of this branch, one suitable for
debian and other packagers who release infrequently because it should
be very stable at this point.
> And is there a release schedule in mind? Any prospect of more
> thoroughly automating official releases and of adding svn snapshot
> releases? And of following numpy's buildbot example?
>
> I don't think I can help with any of this; I am just casting about to
> see if there might be someone on the list who is interested and can
> break loose some time.
We are not that far away, at least for src snapshots, os x binaries,
and the docs. The windows binary would take some work, as would a
linux binary, eg a debian package. I am definitely for it, but one or
more of us will have to step up and push it through.
JDH
JDH

"Andrew Hawryluk" <HA...@no...> writes:
>> Does it help if you set ps.fonttype and pdf.fonttype to 42 in
>> matplotlibrc?
>
> Yes, that works very well, thanks! However, it now embeds the entire
> font rather than a subset. This results in a PDF of 14.4 MB with this
> font. I ran it through ghostscript to get a PDF of 24.2 kB with
> subsetting, but I'm wondering if I can get subsetting of type 42 fonts
> directly from matplotlib?
I'm afraid there's no support for that in the current version, except
probably in the Cairo backend (every time I try to compile pycairo I run
into trouble with some of the dependencies, but if you can get it to
work, it's a very advanced graphics library for producing all sorts of
formats).
-- 
Jouni K. Seppänen
http://www.iki.fi/jks