Re: [matplotlib-devel] colormaps in pcolor

[John H. <jdh...@ac...>]

>>>>> "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