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.
I think this should be changed as in the attached patch.
Otherwise thanks for matplotlib 
Klaus
NonUniformImage-np.asarray-2-ma.asarray-baser5797.diff (586 Bytes)
Eric, could you take a look at this? Although the patch is trivial, I
just want to make sure that the image extension code will do the right
thing if a masked array gets passed into it. I d not see any special
handling in _image.pcolor so am not sure what happens when a masked
array gets passed in.
JDH
On Mon, Jul 21, 2008 at 3:12 AM, Klaus Zimmermann <klaus.zimmermann@...416...> 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.
I think this should be changed as in the attached patch.Otherwise thanks for matplotlib
John Hunter 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.
I think this should be changed as in the attached patch.Otherwise thanks for matplotlib
Eric, could you take a look at this? Although the patch is trivial, I
just want to make sure that the image extension code will do the right
thing if a masked array gets passed into it. I d not see any special
handling in _image.pcolor so am not sure what happens when a masked
array gets passed in.JDH
John, Klaus,
We already were using masked arrays for some image types even when we did not need to do so (and when it was inappropriate), in which case the mask was ignored.
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 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.
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.
Eric
On Mon, Jul 21, 2008 at 3:12 AM, Klaus Zimmermann > <klaus.zimmermann@...416...> wrote:
Eric Firing schrieb:
John Hunter 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.
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.
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?
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.
Cheers,
Klaus
On Mon, Jul 21, 2008 at 3:12 AM, Klaus Zimmermann >> <klaus.zimmermann@...416...> wrote:
Klaus Zimmermann wrote:
Eric Firing schrieb:
John Hunter 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
On Mon, Jul 21, 2008 at 3:12 AM, Klaus Zimmermann >>> <klaus.zimmermann@...416...> wrote:
Cheers,
Klaus
