FIX: Check for colorbar creation with multi-dimensional alpha #20788
Conversation
|
I am not sure about this. I'd just set alpha to one if it's an ndarray. I think we also need to do the same thing in set_alpha. |
|
I'm not sure we should do that silently though? I could change to a warning here instead, but raising an error makes it explicit that a user needs to specify what they want the colorbar to display. |
|
I guess I think 99% of the time they want the colours to display without alpha. I guess you could get someone who set all the alphas the same but still specified an array, but that's the only case I can think of where you would want a non-one alpha applied. But we can let others pipe up as well.. |
903f296 to
9760d25
Compare
|
I don't have a real strong preference here. I agree that is probably what most people want and a warning may be too much even. This will fix the error out case and if someone wants more control/options that can be implemented later. |
lib/matplotlib/colorbar.py
Outdated
| @@ -582,8 +582,10 @@ def _add_solids(self, X, Y, C): | |||
| and any(hatch is not None for hatch in mappable.hatches)): | |||
| self._add_solids_patches(X, Y, C, mappable) | |||
| else: | |||
| # Ignore alpha if the user provided an explicit array | |||
| alpha = None if isinstance(self.alpha, np.ndarray) else self.alpha | |||
There was a problem hiding this comment.
I think self.alpha on the colorbar should be the alpha being used by the colorbar - so we could set the alpha properly in the init and in update_normal?
There was a problem hiding this comment.
Sure, I updated set_alpha to handle both cases in the same place. It still seems unfortunate to get the colorbar's alpha out of sync with the mappable's alpha. But, I think that will only happen in this case.
Looks like there is #7430 with more discussion around a similar topic.
There was a problem hiding this comment.
I mean if you are planning to push through syncing them, we could do something else, like store a pointer to the mappable and just check it at draw time - I don't see any reason for the user to have the ability to set the alpha of the colorbar manually so that it is out of sync with the mappable, but maybe some folks want partially transparent colorbars? But if so that would have to apply to the axes, ticks etc as well....
There was a problem hiding this comment.
I have no idea why the colorbar has a set_alpha(), I assume this may have been for when the colorbar+alpha looked blocky and allowed someone to force fully opaque just so it looks nicer. I could look into deprecating/modifying that in a separate issue/PR. I think something basic like this should get in for the releases as the current error is not descriptive of what the problem actually is.
If an array-like alpha is provided, we set the colorbar alpha to None to use the colormap's transparency values. This would previously error.
9760d25 to
e616780
Compare
PR Summary
Raise a ValueError if a colorbar is created with a collection that has an alpha that is an array. This also adds the ability to override the collection's alpha with a scalar.
closes #19843
closes #20785
PR Checklist
pytestpasses).flake8on changed files to check).flake8-docstringsand runflake8 --docstring-convention=all).doc/users/next_whats_new/(follow instructions in README.rst there).doc/api/next_api_changes/(follow instructions in README.rst there).