matplotlib-devel Mailing List for matplotlib

>>>>> "Jon" == Jon Peirce <jw...@ps...> writes:
 Jon> John, loving matplotlib - thx.
 Jon> Was using pcolor today but needed a gray colormap rather than
 Jon> jet. Made my own version (see attached) using a class
 Jon> Colormap with attribute color (which can be set to
 Jon> 'jet'). Seemed a bit more adaptable and more like matlab. I
 Jon> linked ColormapJet back to this class so that other people's
 Jon> code wont break (hopefully ;) ). Probably worth allowing
 Jon> users to supply there own as an array too, but I didn't have
 Jon> time to do that today.
I've been wanting to include multiple colormaps, so this is a start in
the right direction. A word of warning: some versions of Numeric are
broken with 'from __future__ import division'
 from __future__ import division
 ...snip...
 self.red = arange(self.N+1)/self.N
It's safer to do
 self.red = 1/self.N*arange(self.N+1) 
or
 self.red = divide(arange(self.N+1), self.N)
 Jon> On a different topic slightly, I wonder if it would be worth
 Jon> having a plot type based on image widgets. For large arrays
 Jon> pcolor is still very slow under gtk. Maybe either using image
 Jon> widgets for pcolor itself or having a different plot type
 Jon> (like matlabs 'image' or 'imagesc').
I don't think a specialized plot type or image widget is the way to
go, since it wouldn't port across backends very well. The plot
commands are fairly high level and are used to construct the lower
level graphics primitives. 
I think it better perhaps to introduce some new graphics primitives
(on the same level as line, patch, text) that handle 2D arrays and
colormaps efficiently. The cases I would like to be able to handle
are
 1) 2D image data: eg, RGB or plain old image files such as PNG
 2) 2D scalar data: points with colormap
 3) 2D scalar data: rectangle patch + colormap + optional gradient
 interpolation
In the existing design of matplotlib, the backends don't handle
transformations, scaling, etc... Consistent with this, we could
provide frontend code to take existing image data (construed broadly
to cover all the cases above), scale it to the axes display
coordinates, do the interpolation as necessary, and construct an MxN
array (axes window is MxN pixels) of RGBA data (RGBA is in normalized
0,1 scale). In other words, we agree on a single image data structure
all implemented in extension code, and then make the backends
implement a method to handle that structures in the same way they have
to now handle a rectangular patch.
Eg, we would need only one additional backend method
 renderer.draw_rgba(imageData)
and it only has to do a little extra work to render it. In GTK all
that would be required is to scale the RGB by 65536 and use the GDK
draw rgb method.
We would definitely want to use some decent image library to do the
frontend scaling, interpolation, file loading, etc. libart and agg
have been discussed on and off list lately as candidates. VTK is also
a possibility. Although it is primarily 3D library, it also has
support for all the 2D stuff you can imagine and everything else too.
VTK is a big and hairy package, but it runs everywhere, does
everything well, and opens the door for going 3D.
I've had some discouraging experiences with libart over the last few
days. In trying to implement clipping for the paint backend, I've
come across some known libart numerical instabilities, and in my
questions to the libart list I've been steered to agg by other
frustrated libart users. 
JDH

John,
loving matplotlib - thx.
Was using pcolor today but needed a gray colormap rather than jet. Made 
my own version (see attached) using a class Colormap with attribute 
color (which can be set to 'jet'). Seemed a bit more adaptable and more 
like matlab. I linked ColormapJet back to this class so that other 
people's code wont break (hopefully ;) ). Probably worth allowing users 
to supply there own as an array too, but I didn't have time to do that 
today.
On a different topic slightly, I wonder if it would be worth having a 
plot type based on image widgets. For large arrays pcolor is still very 
slow under gtk. Maybe either using image widgets for pcolor itself or 
having a different plot type (like matlabs 'image' or 'imagesc').
all the best
Jon
-- 
Jon Peirce
Nottingham University
+44 (0)115 8467176 (tel)
+44 (0)115 9515324 (fax)
http://www.psychology.nottingham.ac.uk/staff/jwp/