| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
This is important/asked for enough that I'd consider it a major feature, so docs would be a plus. |
Sorry, something went wrong.
|
@story645, there are some doc updates here. What sort of additional documentation do you have in mind? A further extension of the docstring or an example similar to https://github.com/matplotlib/matplotlib/blob/master/examples/images_contours_and_fields/image_masked.py? If an example, do you have a preference for adding this to an existing example or creating a dedicated one? |
Sorry, something went wrong.
|
Adding to an existing example would be great, or as a new one in the color section of the examples. |
Sorry, something went wrong.
|
It looks like we could update this example with the new implementation. In particular, the following no longer applies:
Happy for me to rewrite while keeping the generated images the same? |
Sorry, something went wrong.
|
that'd be perfect, thanks! |
Sorry, something went wrong.
There was a problem hiding this comment.
More detailed documentations will be nice. It is still a bit difficult to understand just by reading the source codes.
Sorry, something went wrong.
|
@ruidazeng, what information would you like to see specifically? |
Sorry, something went wrong.
Sorry, something went wrong.
|
@tillahoffmann I'm happy with the docs, thanks! |
Sorry, something went wrong.
| alpha : float | ||
| """ | ||
| martist.Artist.set_alpha(self, alpha) | ||
| if np.isscalar(alpha): |
There was a problem hiding this comment.
the docs of np.isscalar basically tell you to not use this function, and suggests np.ndim(alpha) == 0 instead: https://docs.scipy.org/doc/numpy/reference/generated/numpy.isscalar.html
Sorry, something went wrong.
There was a problem hiding this comment.
also, should this unset any previously set array_alpha?
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks for the pointer regarding np.isscalar. Yes, the _array_alpha should also be unset. Having said that, maybe the implementation proposed in tillahoffmann#1 is preferable because it also addresses @jklymak's #14889 (comment) above.
Sorry, something went wrong.
There was a problem hiding this comment.
I think I prefer the approach of tillahoffmann#1, yes this means that the type of get_alpha() changed but that seems better than lying as to the alpha value.
OTOH, tillahoffmann#1 also has a change to composite_images and that change appears to not take array_alpha into account? (Try with two overlapping images that use array alpha, and save to pdf to check.)
It may be fine to just disable software compositing in that case if it's too complicated, and draw the two images separately.
Sorry, something went wrong.
| alpha : scalar, optional | ||
| alpha : scalar or array_like, optional, default: None | ||
| The alpha blending value, between 0 (transparent) and 1 (opaque). | ||
| This parameter is ignored for RGBA input data. |
There was a problem hiding this comment.
I have dropped This parameter is ignored for RGBA input data. because it appears to be respected by the released matplotlib==3.1.1.
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks @tillahoffmann !
Sorry, something went wrong.
|
I restarted the appveyor CI which looks like it had a worker fail. Given that azure passed, I don't think that this is a windows related bug. |
Sorry, something went wrong.
|
Is there a reason to allow vectorized alpha only for images, and not just every ScalarMappable? |
Sorry, something went wrong.
| self.stale = True | ||
| self._imcache = None | ||
|
|
||
| def _get_scalar_alpha(self): |
There was a problem hiding this comment.
This appears to just return 1 for alpha-arrays. IMHO this needs documentation: What's the purpose of this function and why this kind of handling of alpha-arrays?
Sorry, something went wrong.
There was a problem hiding this comment.
Added a description.
Sorry, something went wrong.
Co-Authored-By: Tim Hoffmann <2836374+timhoffm@users.noreply.github.com>
Hm, yes, good point. @ImportanceOfBeingErnest, are you suggesting adding the handling of alpha arrays here? matplotlib/lib/matplotlib/cm.py Line 178 in bec9259 |
Sorry, something went wrong.
|
Yes, naively I would think one could have ScalarMappable._alpha which can be a scalar or of the same shape as ScalarMappable._A. However there might be problems because alpha is usually a property of the artist, not the mixin. But if there are no problems, having every ScalarMappable being able to profit from vectorized alphas would be nice. E.g. there are many cases where you cannot use imshow so sooner or later people would ask to have it implemented for pcolor-like functions as well. |
Sorry, something went wrong.
|
If the intention is to broaden to all ScalarMappables this should move to 3.3. I don't think we have a clear enough view and enough testing time to bring such a major change into 3.2. Are there any possible problems with merging this as is for imshow only and think on a generalization later? |
Sorry, something went wrong.
|
On the other hand it would be a pity to delay it if it turns out that a more general solution is not desireable. I think the real question is: Does the implementation as shown here prevent a more general solution in the future (in the sense of needing to deprecate newly introduced stuff again etc.)? |
Sorry, something went wrong.
|
We can always tag the current approach as experimental (as we did for constrained_layout). |
Sorry, something went wrong.
|
I believe the approach proposed by @ImportanceOfBeingErnest is certainly preferable over the implementation in this PR, but I don't think we'd have to break any interface in the future if we wanted to support vector-alpha at the level of the ScalarMappable mix-in. |
Sorry, something went wrong.
|
I am in favor of merging this now and addressing generalizing it in 3.3. It is better to get useful, but incomplete code out rather than wait for perfect general solutions. This does not add any public API other than allowing imshow to take a greater range of inputs. This also connects to #8738 |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
PR Summary
This PR supports pixel-by-pixel alpha channels in imshow and is a replacement for #8183.
cc @jklymak
PR Checklist