Michael Droettboom wrote: > John Hunter wrote: >> On Nov 9, 2007 1:12 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: >> >>> I've committed my changes on the transforms branch so you can play with >>> it -- I'm holding off on changing the trunk due to the pending release. >>> But if everyone agrees on the way to expose this, it would be nice to >>> merge this over to trunk before the release. >> >> Am I right in assuming that the only thing we lose in this approach is >> faceting (which Eric hates but others may care about)? Since it is >> orders of magnitudes faster, we could have a pcolor_faceted which >> pcolor calls the old function if shading='faceted'. Of course the two >> functions would return different types (image vs patch collection) >> which is potentially a bit confusing.... We could play with adding >> faceting to images.... > > pcolor can draw an arbitrary quadmesh (see quadmesh_demo.py, which uses > pcolor), where the edges of the quadrilaterals are not necessarily > parallel to the x or y axes. The NonUniformImage stuff requires that > the quadrilaterals are axis-aligned rectangles. To put it another way, > the X and Y arrays (that define the mesh) can be 2-dimensional for > pcolor, but only 1-dimensional for (the new) imshow. > > pcolormesh, AFAICT, is more-or-less functionally equivalent to pcolor, > but uses optimized quadmesh drawing under the hood, rather than a > PolyCollection. (Though the comments hint at subtle differences related > to masking.) > > But you are right -- NonUniformImage does not support outlining each > quadrilateral -- though that may not be hard to add if needed. > > The difference in return types is perhaps an argument for > NonUniformImages going in imshow, not pcolor. (I was thinking only of > ease of implementation...) > > Cheers, > Mike >
Mike, I have looked at NonUniformImage and found that although in the extension code it is called "pcolor", it is not doing the right thing for pcolor; and I think not quite the right thing for anything "image-like" either. For the latter, the problem is that it extrapolates the edges out indefinitely. I can't think of any circumstance in which this would be desirable. For the former, which is the application that really interests me, this extrapolation is one problem, but worse than that, it does not allow easy specification of the rectangle *boundaries*, which is what pcolor really needs. So, it is a strange hybrid. I thought I might simply make a modified version to do what pcolor really needs, but between general distraction and floundering in C++ I have not succeeded, although it looks like it should be very easy--especially for someone comfortable with C++ and Agg, which I am not. So, if you can get to it, that would be great. If not, I can probably do it within a week or two. The pcolor variant of the nonuniform image code should accept as X and Y vectors giving the *boundaries* of the rectangles, so they should have lengths 1 greater than the corresponding dimensions of the color array. Any pixels that are not within the rectangles should be given the background color, so this needs to be passed in as well, just as it is for the regular image initializer. I will discuss higher level API questions later. Eric ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
