matplotlib-devel Mailing List for matplotlib

On Fri, 2008年08月08日 at 16:05 +0200, Grégory Lielens wrote:
> Hello everybody,
> 
> I have sent this message to the user group, but thinking of it, it may be more
> relevant to the development mailing list...so here it is again.
> 
> 
> 
> We are looking for the best way to plot a waterfall diagram in
> Matplotlib. The 2 functions which could be used 
> to do that are (as far as I have found) imshow and pcolormesh. Here is a
> small script that use both to compare the output:
> 
> -----------------
> 
> from pylab import *
> 
> 
> delta = 0.2
> x = arange(-3.0, 3.0, delta)
> y = arange(-2.0, 2.0, delta)
> X, Y = meshgrid(x, y)
> Z1 = bivariate_normal(X, Y, 1.0, 1.0, 0.0, 0.0)
> Z2 = bivariate_normal(X, Y, 1.5, 0.5, 1, 1)
> # difference of Gaussians
> Z = 10.0 * (Z2 - Z1)
> figure(1)
> im = imshow(Z,extent=(-3,3,-2,2))
> CS = contour(X, -Y, Z, 6,
> colors='k', # negative contours will be dashed by default
> )
> clabel(CS, fontsize=9, inline=1)
> title('Using imshow')
> figure(2)
> im = pcolormesh(X,-Y,Z)
> CS = contour(X, -Y, Z, 6,
> colors='k', # negative contours will be dashed by default
> )
> clabel(CS, fontsize=9, inline=1)
> title('Using pcolormesh')
> show()
> 
> ---------------------
> 
> 
> The problem is that we need some of the flexibility of pcolormesh (which
> is able to map the matrix of value on any deformed mesh), while
> we would like to use the interpolations available in imshow (which
> explain why the imshow version is much "smoother" than the pcolormesh
> one).
> 
> In fact, what would be needed is not the full flexibility of pcolormesh
> (which can map the grid to any kind of shape), we "only" have to deal
> with rectangular grids where x- and y- graduations are irregularly spaced.
> 
> Is there a drawing function in Matplotlib which would be able to work
> with such a rectangular non-uniform grid?
> And if not (and a quick look at the example and the code make me think 
> that indeed the capability is currently not present),
> what about an extension of imshow which would work as this:
> 
> im = imshow(Z,x_gridpos=x, y_gridpos=y) #specify the
> position of the grid's nodes, instead of giving the extend and assuming
> uniform spacing.
> 
> Longer term, would a pcolormesh accepting interpolation be possible? The
> current behavior, averaging the color of the grids node to get a uniform
> cell color, 
> is quite rough except for a large number of cells...And even then, it
> soon shows when you zoom in...
> 
> The best would be to allow the same interpolations as in imshow (or a
> subset of it), and also allows to use interpolation before colormap
> lookup (or after), 
> like in Matlab. Indeed, Matlab allows to finely tune interpolation by
> specifying Gouraud (interpolation after color
> lookup)/Phong(interpolation before color lookup, i.e. for each pixel).
> Phong is usually much better but also more CPU intensive. Phong is
> especially when using discrete colormap, producing banded colors
> equivalent to countour lines, while Gouraud does not work in those
> cases.
> 
> Of course, the performance will be impacted by some of those
> interpolation options, which would degrade performance in animations for
> example.... but I think that having the different options available
> would be very useful, it allows to have the highest map quality, or have
> a "quick and dirty" map depending on situation (grid spacing, type of
> map, animation or not, ...).
> 
> Best regards,
> 
> Greg.
I have found a method which implement the proposed extension to imshow:
NonUniformImage...
However, this image instance support only nearest neighbor
interpolation. Trying to set the interpolation (using the
set_interpolation method)
to something akin imshow throw a "NotImplementedError: Only nearest
neighbor supported" exception....
So basically I am still stuck, it seems that currently there is no way
in matplotlib to plot interpolated
colormap on irregular rectangular grid, and even less on arbitrarily
mapped grid...
Is there any plans to add support for more interpolation in
NonUniformImage in the future? Or maybe there is another 
drawing function that I did not find yet, with this ability?
Best regards,
Greg.

Simplification is now turned off whenever there are nonfinite elements 
in the vertices array. The "should_simplify" determination is now made 
in Python (to make it easier to tweak and cache).
I also committed your patch to handle masked arrays in the same way as 
arrays-with-nonfinite values (which IMHO is rather elegant -- it gets 
rid of the "more than one way to do it" problem, and should be faster 
all around.)
Now -- anyone want to improve the simplification algorithm?
Cheers,
Mike
Eric Firing wrote:
> Mike,
>
> In looking into the handling of inf and nan, I think I have found some 
> complexities and inefficiencies that are easily eliminated (and I have 
> committed some such changes; others are pending), but in the process I 
> have also found what I am fairly sure is a bug in the path 
> simplification code. It is illustrated by the attached modification 
> of nan_test.py. With 128 or more points in the data set, so that the 
> simplification is invoked, the moveto command that should jump across 
> the gap is getting changed to a lineto. This can be seen most easily 
> by applying the attached patch, which includes additional debugging 
> statements to pin down the incorrect command yielded by the 
> simplification, as well as pending changes to unify the handling of 
> masked arrays, nans, and infs. The bug shows up with or without this 
> patch, however. With the patch, it is also triggered by 
> masked_demo.py, which is how I first found it. (The non-debugging, or 
> substantive, parts of the patch are included here for your review or 
> discussion as a separate matter.)
>
> The middle part of the extra debugging output with the patch applied 
> when running the nan_test.py looks like this:
>
> 2 214.726000 395.178372
> 3 return cmd: 2
> 2 218.012000 387.824331
> 4 skip: 2 218.012000 387.824331
> 1 359.310000 396.688044
> 3 return cmd: 2
> 2 362.596000 403.422341
> 3 return cmd: 2
>
> The line starting with "1" is the moveto command and coordinates 
> yielded by the c++ path iterator; the following line is showing that 
> the corresponding command yielded by the simplification code is 
> instead "2", and that it is being returned at a location I have called 
> "3". All this will make sense only when you look at the patched code.
>
> Eric

Michael Droettboom wrote:
> So the easy fix is to turn off simplification when the array contains 
> NaNs (and bonus points if we can cache that so we don't have to run 
> through the list to find NaNs ahead of time).
> 
On further thought, this shouldn't be too difficult -- so I'll go ahead 
and implement this...
> The harder fix is to rewrite the simplification code (which is rather 
> opaque) to handle MOVETOs, or perhaps to handle NaNs directly (whichever 
> is easier).
> 
...and defer this until I have a good long chunk of time.
Cheers,
Mike

The simplification code was written with the assumption that all of the 
codes are LINETO. That is, it has no MOVETOs or CURVEs. There is code 
in backend_agg.h that tries to make sure not to run simplification when 
this is the case (see should_simplify -- it returns false whenever there 
is a codes array). This all worked before NaN support was added to the 
path iterator. However, we now have a case where this limitation of 
path simplification was not explicitly documented, and is now 
interacting with a new, more efficient, way to handle skipping that 
wasn't anticipated.
So the easy fix is to turn off simplification when the array contains 
NaNs (and bonus points if we can cache that so we don't have to run 
through the list to find NaNs ahead of time).
The harder fix is to rewrite the simplification code (which is rather 
opaque) to handle MOVETOs, or perhaps to handle NaNs directly (whichever 
is easier).
I may not get to this before SciPy, however.
Cheers,
Mike
Eric Firing wrote:
> Mike,
>
> In looking into the handling of inf and nan, I think I have found some 
> complexities and inefficiencies that are easily eliminated (and I have 
> committed some such changes; others are pending), but in the process I 
> have also found what I am fairly sure is a bug in the path 
> simplification code. It is illustrated by the attached modification 
> of nan_test.py. With 128 or more points in the data set, so that the 
> simplification is invoked, the moveto command that should jump across 
> the gap is getting changed to a lineto. This can be seen most easily 
> by applying the attached patch, which includes additional debugging 
> statements to pin down the incorrect command yielded by the 
> simplification, as well as pending changes to unify the handling of 
> masked arrays, nans, and infs. The bug shows up with or without this 
> patch, however. With the patch, it is also triggered by 
> masked_demo.py, which is how I first found it. (The non-debugging, or 
> substantive, parts of the patch are included here for your review or 
> discussion as a separate matter.)
>
> The middle part of the extra debugging output with the patch applied 
> when running the nan_test.py looks like this:
>
> 2 214.726000 395.178372
> 3 return cmd: 2
> 2 218.012000 387.824331
> 4 skip: 2 218.012000 387.824331
> 1 359.310000 396.688044
> 3 return cmd: 2
> 2 362.596000 403.422341
> 3 return cmd: 2
>
> The line starting with "1" is the moveto command and coordinates 
> yielded by the c++ path iterator; the following line is showing that 
> the corresponding command yielded by the simplification code is 
> instead "2", and that it is being returned at a location I have called 
> "3". All this will make sense only when you look at the patched code.
>
> Eric

Mike,
In looking into the handling of inf and nan, I think I have found some 
complexities and inefficiencies that are easily eliminated (and I have 
committed some such changes; others are pending), but in the process I 
have also found what I am fairly sure is a bug in the path 
simplification code. It is illustrated by the attached modification of 
nan_test.py. With 128 or more points in the data set, so that the 
simplification is invoked, the moveto command that should jump across 
the gap is getting changed to a lineto. This can be seen most easily by 
applying the attached patch, which includes additional debugging 
statements to pin down the incorrect command yielded by the 
simplification, as well as pending changes to unify the handling of 
masked arrays, nans, and infs. The bug shows up with or without this 
patch, however. With the patch, it is also triggered by masked_demo.py, 
which is how I first found it. (The non-debugging, or substantive, 
parts of the patch are included here for your review or discussion as a 
separate matter.)
The middle part of the extra debugging output with the patch applied 
when running the nan_test.py looks like this:
2 214.726000 395.178372
3 return cmd: 2
2 218.012000 387.824331
4 skip: 2 218.012000 387.824331
1 359.310000 396.688044
3 return cmd: 2
2 362.596000 403.422341
3 return cmd: 2
The line starting with "1" is the moveto command and coordinates yielded 
by the c++ path iterator; the following line is showing that the 
corresponding command yielded by the simplification code is instead "2", 
and that it is being returned at a location I have called "3". All this 
will make sense only when you look at the patched code.
Eric