MNT: improve image array argument checking in to_rgba. Closes #2499. #6122

Merged
merged 2 commits into from Mar 7, 2016

Conversation

Projects
None yet
5 participants
Owner

efiring commented Mar 7, 2016

No description provided.

@luispedro @efiring luispedro BUG Raise exception for invalid input
Arrays of non-uint8 types were assumed to be in 0..1 range.

When this was not true and integer values were used, only the low-order
bits were used, resulting in a mangled image. Now, an explicit exception
is raised.

Closes issue #2499
8433eec

efiring changed the title from MNT: improve image array argument checking in to_rgba. Closes #2499. to MNT: improve image array argument checking in to_rgba. Closes #2499. Mar 7, 2016

efiring added the needs_review label Mar 7, 2016

Owner

tacaswell commented Mar 7, 2016

/home/travis/build/matplotlib/matplotlib/lib/matplotlib/cm.py:259:80: E501 line too long (83 > 79 characters)

/home/travis/build/matplotlib/matplotlib/lib/matplotlib/cm.py:267:80: E501 line too long (81 > 79 characters)

❤️ pep8

@efiring efiring MNT: improve image array argument checking in to_rgba. Closes #2499.
c2f91c5

@tacaswell tacaswell added a commit that referenced this pull request Mar 7, 2016

@tacaswell tacaswell Merge pull request #6122 from efiring/update_2632_2
MNT: improve image array argument checking in to_rgba. Closes #2499.
7df8f0d

@tacaswell tacaswell merged commit 7df8f0d into matplotlib:master Mar 7, 2016

1 of 2 checks passed

continuous-integration/appveyor/pr Waiting for AppVeyor build to complete
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

tacaswell removed the needs_review label Mar 7, 2016

@mdboom mdboom commented on the diff Mar 7, 2016

lib/matplotlib/cm.py
@@ -255,10 +254,18 @@ def to_rgba(self, x, alpha=None, bytes=False, norm=True):
xx = x
else:
raise ValueError("third dimension must be 3 or 4")
- if bytes and xx.dtype != np.uint8:
- xx = (xx * 255).astype(np.uint8)
- if not bytes and xx.dtype == np.uint8:
- xx = xx.astype(float) / 255
+ if xx.dtype.kind == 'f':
+ if xx.max() > 1 or xx.min() < 0:
@mdboom

mdboom Mar 7, 2016

Owner

Kind of an expensive check for something that's on the mainline for displaying images. What happens if we remove this check?

@efiring

efiring Mar 7, 2016

Owner

How does this interact with your image refactor? I think that if this check is executed only on external input of 3-D RGBA arrays, then it is OK; that is really its purpose here. But if it is executed on internally-generated arrays in the normal course of events, then it needs to be bypassed. In fact, if that is happening, perhaps it is an entire call to the to_rgba method that needs to be bypassed, and the check can stay in place.

@mdboom

mdboom Mar 7, 2016

Owner

That's a good point. I do think it will only get run on externally-provided images -- but that does include images loaded using imread. I still wonder if it's too expensive even in that case though.

@mdboom

mdboom Mar 7, 2016

Owner

At least post-image-refactor these images are at "screen resolution" and not at data resolution which could be larger.

@tacaswell

tacaswell Mar 7, 2016

Owner

sorry for being trigger happy on this.

@mdboom

mdboom Mar 7, 2016

Owner

Having poked at it, for image I think it's impossible for this case to even happen -- the data is normalized (in any event) before it gets here. (However, I suspect that's not the case for other places to_rgba is used, like scatter).

@efiring

efiring Mar 7, 2016

Owner

I think uses like scatter are irrelevant because the checking in question is invoked only for MxNx3 and MxNx4 inputs, which are assumed to be RGB or RGBA images.
As for "impossible": to_rgba is not private, so it is entirely possible for a user to generate a 3-D float array that would fail the check. If such an array is fed to imshow with interpolation 'none', will it be run through to_rgba? Certainly it will not be normalized.
The options are to remove the check on the grounds that it is usually unnecessary (we have managed without it for a long time), to leave it in and accept the performance penalty, or to find a way to distinguish between cases where it might be useful, if such cases exist, and cases where we are sure it is pointless. The last probably would be the best if it can be accomplished with minimal added complexity.

@mdboom

mdboom Mar 7, 2016

Owner

As a middle road, I think we can safely assume if norm=False is passed in that it's already normalized and we don't need to do this check. That will catch most of the cases where the check would be redundant.

Member

QuLogic commented Mar 7, 2016

Is this going to be backported? While it's milestoned 2.1, the original issue is milestoned 2.0.

Owner

tacaswell commented Mar 8, 2016

I am 50/50 on backporting.

Owner

tacaswell commented Mar 8, 2016

And we should wait for @mdboom 's follow on commit in either case.

efiring deleted the efiring:update_2632_2 branch Jun 23, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment