Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

ENH: support alpha arrays in collections#6268

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Merged
jklymak merged 2 commits intomatplotlib:masterfromefiring:alpha_array
Sep 12, 2020

Conversation

efiring
Copy link
Member

@efiringefiring commentedApr 4, 2016
edited
Loading

This started by supporting alpha arrays in collections with color mapping but it now also works when a single color is provided, or when a list of color specifications is given.

Tests are included.
There is an entry in next_whats_new.

pharshalp reacted with thumbs up emoji
@efiringefiring added this to the2.1 (next point release) milestoneApr 4, 2016
@WeatherGod
Copy link
Member

This doesn't relate to the idea of 2D colormaps, right? (The second
dimension being alpha, typically indicating level of confidence in the data)

On Sun, Apr 3, 2016 at 10:24 PM, Eric Firingnotifications@github.com
wrote:

This is apossible alternative to#6250
#6250. It applies the
alpha array in Colormap.call. It probably needs quite a bit more work
for adequate documentation and argument checking at higher levels. And

tests, of course.

You can view, comment on, or merge this pull request online at:

#6268
Commit Summary

  • ENH: support alpha arrays when color mapping

File Changes

Patch Links:


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#6268

@efiring
Copy link
MemberAuthor

@WeatherGod, this could be used for that purpose; it is up to the user to generate the alpha array on a 0-1 scale based on whatever measure of level of confidence, or anything else, the user wishes to encode via transparency. The alpha is applied hereafter the colormapping, so it can be based on a different set of data values and a different norm; it isnot done by modifying alpha in the colormap LUT. (That can also be done, but it is a completely independent and rather different operation.)

@tacaswelltacaswell modified the milestones:2.1 (next point release),2.2 (next next feature release)Sep 24, 2017
@jklymak
Copy link
Member

I'm not sure how obsolete this one is....

Copy link
Member

@jklymakjklymak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This looks to need examples and tests?

@jklymakjklymak modified the milestones:v3.0,v3.1Jul 9, 2018
@jklymakjklymak modified the milestones:v3.1.0,v3.2.0Feb 7, 2019
@timhoffmtimhoffm modified the milestones:v3.2.0,v3.3.0Aug 16, 2019
@jklymakjklymak modified the milestones:v3.3.0,v3.4.0May 26, 2020
@jklymak
Copy link
Member

@efiring,I would like this to go in. Any appetite for resurrecting?

@efiring
Copy link
MemberAuthor

OK, I will have a look.

@efiringefiring marked this pull request as ready for reviewSeptember 6, 2020 23:30
@efiringefiring changed the titleENH: support alpha arrays when color mappingENH: support alpha arrays in collectionsSep 7, 2020
@efiring
Copy link
MemberAuthor

I think this is ready for review now. It actually does more than I originally intended.
codecov/project/tests is unhappy; do I need to do something about that?

y = np.arange(4)
z = np.arange(9).reshape((3, 3))
alpha = z / z.max()
alpha_flat = alpha.ravel()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

So at somepoint someone will put some masked or NaN into alpha. What will happen, and what do you recommend?

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Fail on nan; ignore mask. I don't think it is worthwhile for us to try to propagate nans and masked arrays from the alpha input.

jklymak reacted with thumbs up emoji
@jklymakjklymak self-requested a reviewSeptember 8, 2020 05:00
@efiringefiringforce-pushed thealpha_array branch 2 times, most recently from9c24406 to20b894bCompareSeptember 8, 2020 20:51
@efiring
Copy link
MemberAuthor

Squashed, and passing tests; it's ready, as far as I can see.

self.pchanged()
self.stale = True
martist.Artist._set_alpha_for_array(self, alpha)
if np.ndim(alpha) not in (0, 2):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Do you not want to check this before calling the setter?

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

No, I think it is better to have the more basic argument-checking from the setter before checking the number of dimensions.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Wouldn't that leaveself.alpha in an inconsistent state?

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Why would that matter? An exception is being raised either way. Look at_ImageBase.set_data. All of the validation is being doneafter the attribute assignment:

self._A=cbook.safe_masked_invalid(A,copy=True)

It looks like theset_data code would be slightly more efficient and readable if the attribute assignment were done at the end, but that's not the issue here. Forset_alpha, both efficiency and logical order of validation checks are better with the ndim check afterset_alpha_for_array.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

To resolve this, can we easily write a test that shows how it works?

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I don't see anything to resolve. I have already included a test for this case, raising an exception if the wrong number of dimensions is supplied for an image.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

FWIW, if we already have cases of inconsistent state on invalid input, then I'm slightly less concerned about adding one more.

Copy link
MemberAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

It is impossible to doall validation before setting attributes, given independent setters, because valid alpha depends on data, and vice-versa. That's why one of the tests I added callsupdate_scalarmappable; that's where the validation has to be, because that is where we have both alpha and data and can cross-check them.

@efiring
Copy link
MemberAuthor

@QuLogic Thank you. I think I have addressed everything you have found so far.

Previously this was supported only for images.  Now it works forcollections, and when directly calling a colormap or to_rgba_array.
@efiring
Copy link
MemberAuthor

I have rebased again because the Travis merge test seemed to have gotten stuck (I think it actually ran and passed, but failed to report that back correctly), and a bunch of stuff was merged recently.

@efiring
Copy link
MemberAuthor

Now, after a simple rebase, testing is throwing up what I think are unrelated errors--something about jupyter on windows?

lut[:, -1] = alpha
# If the bad value is set to have a color, then we
# override its alpha just as for any other value.
alpha = (alpha * 255).astype(np.uint8)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Stall a couple of code paths not tested? (L625 and 632)

Copy link
Member

@QuLogicQuLogic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Modulo tests that@jklymak requested.

@efiring
Copy link
MemberAuthor

efiring commentedSep 12, 2020 via email

On 2020/09/11 2:15 PM, Jody Klymak wrote: a couple of code paths not tested? (L625 and 632)
OK, working on those.

Fixup and clarification in colors; more testsTweak whats_new
@jklymakjklymak merged commit1b1afe1 intomatplotlib:masterSep 12, 2020
@jklymak
Copy link
Member

Thanks@efiring This will be pretty helpful in creating graphics with two-dimensions in Z.

@efiringefiring deleted the alpha_array branchSeptember 12, 2020 19:21
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@QuLogicQuLogicQuLogic approved these changes

@jklymakjklymakjklymak approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
v3.4.0
Development

Successfully merging this pull request may close these issues.

7 participants
@efiring@WeatherGod@jklymak@QuLogic@tacaswell@timhoffm@dstansby

[8]ページ先頭

©2009-2025 Movatter.jp