Klaus Zimmermann wrote: > Eric Firing schrieb: >> John Hunter wrote: >>> On Mon, Jul 21, 2008 at 3:12 AM, Klaus Zimmermann >>> <[EMAIL PROTECTED]> wrote: >>>> Hello *, >>>> >>>> right now the NonUniformImage class in image.py uses numpy's asarray >>>> method. All similar classes instead use numpy.ma.asarray, thus allowing >>>> for masked images. > [...] >> Masked arrays are handled automatically as needed by the >> ScalarMappable.to_rgba() method. >> >> What we really wanted, and the change I made throughout image.py, is >> to keep masked input as masked, and to ensure that anything else is a >> plain ndarray. This is now committed. > I just checked and I think your changes solve my problem well, obviously > without introducing the potential problems you mentioned above. Thanks! > I was just confused by the different semantics: > AxesImage : does masks, NxM array expects N, M dimensions. > NonUniformImage : didn't do masks, NxM array expects N, M dimensions. > PcolorImage: does masks, NxM array expects N+1, M+1 dimensions.
Note that Image also handles PIL arrays, and all three handle NxMx3 and NxMx4 rbg and rgba arrays, in place of color mapping. > > Though I think the mask thingie in the NonUniformImage was simply a bug > and I understand why PcolorImage is the way it is, it still stumped me > at first sight. Also I find it difficult to understand the difference > Pcolor and NonUniform since NonUniform does pseudo colors just as well? > However if you feel this is just a lack of RTFM on my part please feel > free to ignore. NonUniformImage came first, and sat around for a long time without getting an Axes or pylab interface. Exactly what it should do always seemed a bit ambiguous to me; when the "pixels" are not uniformly spaced, where should the boundaries be? The only thing that makes sense to me in this case is to explicitly provide the boundaries, which is what pcolor does. But the original pcolor was slow, so I modified the NonUniformImage extension and python code to handle explicit boundaries to make a faster pcolor. I ended up with pcolorfast, which uses image code if the grid is uniform, PcolorImage code if it is rectangular but not uniform, and quadmesh if it is not even rectangular. In all of this, since I had never used NonUniformImage, and had no idea who was using it for what, I simply left it alone. It could be reimplemented as a wrapper around PcolorImage, thereby reusing rather than duplicating some code, but this is at best low priority. > >> I considered using np.asanyarray(A) but rejected it because it could >> fail for matrix input if any code is expecting iteration or >> single-indexing to return a 1-D array. > Makes sense. But perhaps we should refactor that check into a (module) > function of its own, as to avoid recundancy? I can do that if you want, > or if you prefer a classmethod in AxesImage? > I think the check is so short and simple that for now it is best to leave it as-is; maybe later there will be an attempt to factor some argument handling like this out from mpl as a whole, not just the image classes. > >> We lack examples to test masking of various types of input in the >> various types of image, though. Maybe I will add that later. Klaus, >> if you have any nice, small examples you would like to add to the mpl >> examples directory, that illustrate features or use cases that are not >> exercised in any present examples, please submit them. > Will do. > Good, thank you. Eric > Cheers, > Klaus ------------------------------------------------------------------------- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
