Re: [matplotlib-devel] OpenGL backend and pyglet expertiments
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 > > [email protected] > > -- > ___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] imshow without resampling
Eric Firing 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
> 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
--
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] python-2.6 compatible matplotlib
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 -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] python-2.6 compatible matplotlib
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 -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] python-2.6 compatible matplotlib
On Sun, Apr 5, 2009 at 16:01, David Moore 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 -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] release strategy, and the role of v0_98_5_maint
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 -- ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: [Matplotlib-users] imshow without resampling]
Hello,
I just thought I'd mention a little more detail about what I've found
with respect to writing grey/colorscales to vector graphics formats.
The bottom line is that to plot a grayscale or colorscale in a vector
graphics format without resampling, it seems at the moment that
pcolorfast works best, in SVG format (not PS).
Attached is a script to try out different combinations of methods,
formats, and canvas sizes. In all cases I am plotting a 10x10 numpy
array. The file sizes I obtain are:
$ du -sh example*
584Kexample1.ps(imshow and 4x4 canvas)
2.2Mexample2.ps(imshow and 8x8 canvas)
84Kexample3.svg (imshow and 4x4 canvas)
204Kexample4.svg (imshow and 8x8 canvas)
600Kexample5.ps(pcolorfast and 4x4 canvas)
2.3Mexample6.ps(pcolorfast and 8x8 canvas)
16Kexample7.svg (pcolorfast and 4x4 canvas)
20Kexample8.svg (pcolorfast and 8x8 canvas)
As you can see, example7.svg and example8.svg are by far the smallest
files, and their sizes aren't that different, which is the way things
should be as changing the canvas size shouldn't be changing much since
it is a vector graphics format. It's interesting to see that imshow
and pcolorfast produce different results for SVG (both smaller than
the PS results)
Interestingly, pcolorfast shows no improvement compared to imshow for
the PS files, and in addition, the 4x4 images are 4 times smaller than
the 8x8 images, suggesting that in all cases, the colorscale has been
rasterized to a finer resolution.
It might be worth seeing how the SVG driver implements this and apply
the same technique to the PS driver. The fact that the SVG driver can
do this suggests that the matplotlib API should be able to handle this
and so all that is needed is to work on the PS driver?
As a temporary solution, it is possible to produce SVG files and
convert these to PS, but this is not an ideal solution.
Let me know if you have any questions about this,
Thanks,
Thomas
import matplotlib
matplotlib.use('Agg')
from matplotlib.pyplot import *
import numpy as np
image = np.random.random((10,10))
fig = figure(figsize=(4,4))
ax = fig.add_subplot(111)
ax.imshow(image)
fig.savefig('example1.ps')
fig = figure(figsize=(8,8))
ax = fig.add_subplot(111)
ax.imshow(image)
fig.savefig('example2.ps')
fig = figure(figsize=(4,4))
ax = fig.add_subplot(111)
ax.imshow(image)
fig.savefig('example3.svg')
fig = figure(figsize=(8,8))
ax = fig.add_subplot(111)
ax.imshow(image)
fig.savefig('example4.svg')
fig = figure(figsize=(4,4))
ax = fig.add_subplot(111)
ax.pcolorfast(image)
fig.savefig('example5.ps')
fig = figure(figsize=(8,8))
ax = fig.add_subplot(111)
ax.pcolorfast(image)
fig.savefig('example6.ps')
fig = figure(figsize=(4,4))
ax = fig.add_subplot(111)
ax.pcolorfast(image)
fig.savefig('example7.svg')
fig = figure(figsize=(8,8))
ax = fig.add_subplot(111)
ax.pcolorfast(image)
fig.savefig('example8.svg')
On 4 Apr 2009, at 22:50, Eric Firing wrote:
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
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. What I would like, is for code such as
this:
import matplotlib
matplotlib.use('PS')
from matplotlib.pyplot import *
import numpy as np
image = np.random.random((10,10))
fig = figure(figsize=(4,4))
ax = fig.add_subplot(111)
ax.imshow(image)
fig.savefig('example1.ps')
fig = figure(figsize=(8,8))
ax = fig.add_subplot(111)
ax.imshow(image)
fig.savefig('example2.ps')
to produce files that are the roughly the same size, rather than
different by a factor of 4. In addition, both files should be very
small since they should only contain a 10x10 bitmap in addition to the
axes+labels. Postscript and SVG (as languages) both allow a bitmap of
an arbitrary resolution to be scaled, translated, and rotated without
resampling.
I have come across the figimage method which is meant to place an
array in a plot without resampling, but I cannot figure out how to use
it like imshow, i.e. to show the image inside the axes as before. I've
also tried the pcolor functions, but it seems like they define each
pixel as an individual polygon, which is inefficient.
I was wondering if anyone had a solution to this, or if there are
plans to make matplotlib behave like this in future?
Thanks,
Thomas
--
___
Matplotlib-users mailing list
matp
