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.
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)
> 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').
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