matplotlib-devel Mailing List for matplotlib

Anne Archibald wrote:
> Hi,
> 
> First of all, matplotlib is a very nice piece of software - I use it
> all the time for interactive data analysis, for posters, and for
> published papers.
> 
> For visualizing low-resolution vector fields, quiver() is quite nice.
> But for high-resolution vector fields there is a technique called
> "line integral convolution" that can be quite effective. Matplotlib
> doesn't seem to implement it, but I have written a simple line
> integral convolution operator I'd be happy to contribute. It's written
> in cython, and is quite fast and fairly general. There is no
> high-level interface like quiver() yet, in part because of the many
> ways you might want to use the operator. In fact I don't know for sure
> that it belongs here rather than (say) scipy.
> 
> Are you interested in including this in matplotlib?
Possibly. As you note, the question may be whether this belongs in 
scipy, or in an mpl toolkit, or in mpl itself. I had to google to find 
out what "line integral convolution" is. It does look like it would be 
a nice thing to offer. I presume the actual plot would be via image (or 
maybe pcolorfast if anything but a uniform rectangular grid is used). 
Is that correct, or are there other ways the output of the operator 
would be displayed?
So far, mpl has not had pyrex or cython as a build dependency, but 
cython is used in the basemap toolkit. Personally, I like pyrex/cython 
very much and would be happy to see one of them--presumably cython--used
in mpl. Others may disagree.
Based on what you say above, my guess is that scipy might be the most 
natural home for your code, in which case we would want to have an 
example of its use for generating an image in the set of mpl examples. 
But if something more elaborate is needed in the way of a high-level 
interface, then either putting it in mpl directly, or in a toolkit, 
would be good.
Eric
> 
> Anne
> 
> -------------------------------------------------------------------------
> 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

Hi,
First of all, matplotlib is a very nice piece of software - I use it
all the time for interactive data analysis, for posters, and for
published papers.
For visualizing low-resolution vector fields, quiver() is quite nice.
But for high-resolution vector fields there is a technique called
"line integral convolution" that can be quite effective. Matplotlib
doesn't seem to implement it, but I have written a simple line
integral convolution operator I'd be happy to contribute. It's written
in cython, and is quite fast and fairly general. There is no
high-level interface like quiver() yet, in part because of the many
ways you might want to use the operator. In fact I don't know for sure
that it belongs here rather than (say) scipy.
Are you interested in including this in matplotlib?
Anne

Jae-Joon Lee wrote:
>> - the parameter numpoints should be used (it's ignored right now)
>>
> 
> Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose.
> 
> 
>> - Some private variables are accessed and a new RegularPolycollection is
>> created (does this work eg. with a StarPolygonCollection? I haven't
>> checked, but I don't think so !). Instead of creating a new
>> RegularPolyCollection it might be more useful to make a copy of the
>> existing object... I was thinking about a update_from() method for the
>> Collection class(es) similar to update_from() for lines.
>>
> 
> By changing "RegularPolyCoolection" to "type(handles)", it works for
> StarPolygonCollection.
> In Erik's current implementation, the markers in the legend have
> varying colors, sizes, and y offsets.
> The color variation seems fine.
+1
> But do we need to vary the sizes and
> y-offsets? My inclination is to use a fixed size (median?) and a fixed
> y offset. How does Erik and others think?
I also would prefer fixed sizes for the legend, but maybe one should
ensure that the markers are not too large (larger than text height)?
mm
> Regards,
> 
> -JJ

> - the parameter numpoints should be used (it's ignored right now)
>
Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose.
> - Some private variables are accessed and a new RegularPolycollection is
> created (does this work eg. with a StarPolygonCollection? I haven't
> checked, but I don't think so !). Instead of creating a new
> RegularPolyCollection it might be more useful to make a copy of the
> existing object... I was thinking about a update_from() method for the
> Collection class(es) similar to update_from() for lines.
>
By changing "RegularPolyCoolection" to "type(handles)", it works for
StarPolygonCollection.
In Erik's current implementation, the markers in the legend have
varying colors, sizes, and y offsets.
The color variation seems fine. But do we need to vary the sizes and
y-offsets? My inclination is to use a fixed size (median?) and a fixed
y offset. How does Erik and others think?
Regards,
-JJ