matplotlib-devel Mailing List for matplotlib

Thanks for all the work you put into this patch.
As you say, it would be nice to have a generic framework for this so 
that new types of interpolation could be easily added and to be able to 
support arbitrary (non-axis-aligned) quadmeshes as well. But that's 
even more work -- if we keep waiting for everything we want, we'll never 
get it... ;) I agree that Agg probably won't be much help with that. 
There are a couple of comments with the patch as it stands -->
There seems to be a gap extrapolating over the left and bottom edge (see 
attached screenshot from pcolor_nonuniform.py).
Memory management looks problematic, some of which I think you inherited 
from earlier code. For example, arows and acols are never freed. 
Personally, I think these temporary buffers should be std::vector's so 
they'll be free'd automatically when scope is left. It might also be 
nice to move all of the Py_XDECREF's that happen when exceptions are 
thrown to either a master try/catch block or an "exit" goto label at the 
bottom. The amount of duplication and care required to ensure 
everything will be freed by all of the different exit paths is a little 
cumbersome.
Also, acols and arows are only used in BILINEAR interpolation, but they 
are allocated always.
Once these issues are addressed, it would be great to have someone who 
*uses* the nonuniform pcolor functionality (Eric Firing?) have a look at 
this patch for any regressions etc.. Assuming none, I'll be happy to 
commit it (but I won't be around for a week or so).
Cheers,
Mike
Grégory Lielens wrote:
> Hi all,
>
> here is a patch which implement bilinear interpolation on irregular grid
> ( i.e. it allows NonUniformImage
> to accept both 'nearest' and 'bilinear' interpoaltion, instead of only
> 'nearest'.)
>
> It is not perfect, given the current architecture of the image module I
> think there is not simple way
> to specify other interpolations (except for 'nearest', all
> interpolations are implemented at the AGG level, not in
> matplotlib itself).
> For the same reason, it is not possible to interpolate before colormap
> lookup instead of after (and this 
> is usually where the biggest effect is, when dealing with coarse grid).
> However, I think it is already quite useful and the best one ca do
> without a -very- extensive rewrite
> of the matrix map modules....
>
> BTW, I think it also corrects a small bug in the 'nearest'
> interpolation: the last intervals was ignored
> in the CVS version, now it is taken into account.
>
> BOTH nearest and bilinear interpolation do the same for values oustside
> the data grid: they just use boundary values (constant extrapolation).
> I avoided linear extrapolation for 'bilinear', as extrapolation is
> usually dangerous or meaningless (we can go outside the colormap very
> fast)...
>
> I have included a small example showing how both interpolation works....
>
> Any remarks, could this be added before the next release? ;-)
>
>
> Greg.
>
>
>
>
>
> On Mon, 2008年08月11日 at 16:50 +0200, Grégory Lielens wrote:
> 
>> 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.
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

In article 
<638...@ma...>,
 "Charlie Moad" <cw...@gm...> wrote:
> >
> >
> > You can't put a readme in the zip file?
> 
> 
> I think he was referring to the egg as a zip, which it technically is but
> setuptools extracts it for you.
I already find easy_install mysterious and unsettling and I guess you 
can add this notational confusion to the list. Why not call .egg.zip a 
"zipped egg" even if easy_install can handle it directly? But avoiding 
the notational issue entirely, here's my take on it:
The file I downloaded was a .zip file. The obvious naive thing to do 
with a zip file is to unzip it, especially if one is looking for 
instructions!
This yields a .egg file. It could yield a .egg file and a ReadMe file if 
one was included in the zip file. easy_install can install a .egg file 
so it's no harm to unzip the download.
Presumably one could include a ReadMe file into the .egg.zip in such a 
way that easy_install would ignore it.
On the other hand, the web page that is the source of the download could 
also have the ReadMe info, as you point out. Either is fine.
Personally I am not sold on easy_install. It's a clever idea and maybe 
someday it'll live up to its promise, but right now it seems to have 
some many undesirable behaviors (such as mysteriously and needlessly 
downloading stuff).
For now I'd suggest that package installers (e.g. as created by 
bdist_mpkg) be used for Mac because they are standard, are used by 
simply double clicking (thus have no learning curve or need to install 
anything), have ReadMe support build in, and do not mysteriously 
download stuff.
 
-- Russell

Are there any plans for path simplification in any of the non-agg backends? When plotting large numbers of data points (~50k upwards in my case) using the ps backend the resulting file are rather large (several MB). More of a concern is that they take a very long time (~5 minutes) to render with ghostscript on a modern computer with obvious negative implications if sending to a postscript printer / including in publication graphics.
I've added some _very_ simple path simplification to backend_ps.py, which is sufficient for my usage (see attached diff - against 0.98pre, rev 5075). Its pretty ugly though with an arbitrary delta value for determining whether it is safe to skip a point, and a boolean switch to turn it on & off, both currently as module-level variables. 
If there is enough interest, and I was pointed in the direction of the necessary info I could try and clean it up a bit for potential inclusion.
I'd need to know the following:
Is the backend itself the best/preferred place to be doing path simplification?
What would be the best method of doing the configuration (turning on/off, setting delta)?
It would obviously be desirable to automagically select a reasonable delta value - although this is potentially difficult as the resulting graph can be arbitrarily scaled - any ideas?
best wishes,
David
 Win a MacBook Air or iPod touch with Yahoo!7. http://au.docs.yahoo.com/homepageset