matplotlib-devel Mailing List for matplotlib

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?
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.
Eric

On Sun, Apr 5, 2009 at 16:01, David Moore <da...@sj...> wrote:
> I've had matplotlib running fine on Python 2.6 since shortly after the Python
> 2.6 release. I run Arch Linux. Are you perhaps looking for Windows builds?
> Or does your distro not have matplotlib compiled for Python 2.6 yet?
No, I'm looking to package matplotlib for python-2.6 on MacPorts and
wanted to check that there would be no unexpected surprises, but from
the above it sounds like all should be good.
Cheers
Adam

On Sunday 05 April 2009 18:49:46 Adam Mercer wrote:
> Hi
>
> Now that numpy-1.3.0 has been released what is the timescale for a
> python-2.6 compatible release of matplotlib and matplotlib-basemap? Or
> should the current release work OK?
>
> Cheers
>
> Adam
>
I've had matplotlib running fine on Python 2.6 since shortly after the Python 
2.6 release. I run Arch Linux. Are you perhaps looking for Windows builds? 
Or does your distro not have matplotlib compiled for Python 2.6 yet?
Dave Moore

Hi
Now that numpy-1.3.0 has been released what is the timescale for a
python-2.6 compatible release of matplotlib and matplotlib-basemap? Or
should the current release work OK?
Cheers
Adam

Eric Firing <ef...@ha...> writes:
> I'm not sure who the SVG expert is, and I presume the attached message
> applies to pdf as well as ps. I'm bringing it to your attention
> because it is suggesting what would seem to be significant
> improvements in some backends by taking better advantage of their
> native image support. I know nothing about this; would either of you
> (or anyone else) like to comment?
Thanks for forwarding this Eric - yes, it applies to pdf.
> From: Thomas Robitaille <tho...@gm...>
> I am using matplotlib to create postscript and SVG files. I am
> currently using imshow to show the contents of an array, but this
> means that when saving vector graphics files, matplotlib resamples the
> image/array onto a finer grid. [...] Postscript and SVG (as languages)
> both allow a bitmap of an arbitrary resolution to be scaled,
> translated, and rotated without resampling.
This is complicated by the wide variety of interpolation methods offered
by imshow:
 Acceptable values are *None*, 'nearest', 'bilinear',
 'bicubic', 'spline16', 'spline36', 'hanning', 'hamming',
 'hermite', 'kaiser', 'quadric', 'catrom', 'gaussian',
 'bessel', 'mitchell', 'sinc', 'lanczos',
where None means to use the matplotlibrc value, and I think the default
is bicubic. The 'nearest' case is what you get by simply scaling the
original bitmap, so in that case all vector backends could probably
support skipping the interpolation step. The other interpolation methods
could be programmed in Postscript, but that doesn't help with other
backends - though perhaps PDF shadings (gradient fills) could be hacked
to do this. I don't know anything about SVG.
I wonder how the API between the backend and the image object should
look like. Currently the AxesImage object does essentially
 im = self.make_image(renderer.get_image_magnification())
 renderer.draw_image(round(l), round(b), im, self.axes.bbox.frozen(),
 clippath, affine)
and then the backend does things like
 h, w = im.get_size_out()
 [...]
 h,w,s = im.as_rgba_str()
 rgba.shape = (h, w, 4)
 rgb = rgba[:,:,:3]
 a = rgba[:,:,3:]
Instead, I suppose AxesImage needs to first query the renderer if it
supports the interpolation being used, and if so, call a new renderer
method, say draw_interpolated_image(im). Or perhaps it could just call
the new method, and its implementation in RendererBase would fall back
to interpolating the image and calling the old draw_image. Vector
backends could override it to be smarter when possible.
A possibly related thought: the pdf backend could render some kinds of
image files by passing through the encoded image data from the original
file, so when e.g. image_demo3.py does
 lena = Image.open('../data/lena.jpg')
 im = imshow(lena, origin='lower')
the pdf backend could try to read the JPEG file directly, and only
decode it into a bitmap if it happens to be a wrong subtype of JPEG. For
someone who's using big image files, this would decrease both rendering
time and output size, but I don't know if there are any actual users and
if the benefit is large enough to justify the added complexity - but if
we modify the API anyway to support non-resampling imshow, it might be
good to keep that use-case in mind.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

There is also:
http://www.loria.fr/~rougier/pycons.html
which is a gtk shell with embedded matplotlib figures.
Nicolas
On 5 Apr, 2009, at 06:02 , Christopher Barker wrote:
>
> Eric Bruning wrote:
>> The idea of a shell with inline plots is a fascinating one -
>
> Then check out reinteract -- very cool:
>
> http://www.reinteract.org/trac/
>
> (though no opengl)
>
> -Chris
>
> -- 
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chr...@no...
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

John,
About a week ago, I introduced my own mpl toolkit
(http://dl.getdropbox.com/u/178748/AxesGrid/htdocs/index.html) in the
mpl dev-list. And I wonder if this package can be included in the main
matplotlib source.
As a matter of fact, I was a bit reluctant to do this because the
package is poorly documented at this moment. However, other people
(Matthew Turk and Jeff Oishi) showed their interests in this package
going into the main matplotlib source, and they're willing to help me
to improve the documentation (and other aspects).
I couldn't find any policy (or similar thing) about mpl_toolkits.
Currently, my package is consist of several pure python modules, so
including this in the main source would be straight forward.
Regards,
-JJ

Eric Bruning wrote:
> The idea of a shell with inline plots is a fascinating one -
Then check out reinteract -- very cool:
http://www.reinteract.org/trac/
(though no opengl)
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Jouni, Darren,
I'm not sure who the SVG expert is, and I presume the attached message 
applies to pdf as well as ps. I'm bringing it to your attention because 
it is suggesting what would seem to be significant improvements in some 
backends by taking better advantage of their native image support. I 
know nothing about this; would either of you (or anyone else) like to 
comment?
Eric