From: Eric F. <ef...@ha...> - 2012-01-02 20:33:43
|
On 12/30/2011 01:57 PM, Paul Ivanov wrote: > Eric Firing, on 2011-12-27 15:31, wrote: >> It looks like this is something I can fix by modifying ListedColormap. >> It is discarding the alpha values, and I don't think there is any reason >> it needs to do so. > > One of my first attempts at a contribution to matplotlib three > years ago was related to this. It was in reply to a similar > question on list, and I wrote a patch, but never saw it through > to inclusion because it wasn't something I needed. > > http://www.mail-archive.com/mat...@li.../msg09216.html > > I think it's a helpful starting point, as I include a discussion > on the limitation of mpl colormaps there. I'm switching this to the devel list. Please try https://github.com/efiring/matplotlib/tree/colormap_alpha which has changes similar to yours so that alpha is fully changeable in colormaps. I think this is going to be OK as far as the colormap end of things is concerned, but it turns up a new problem related to alpha in images, and reminds us of an old problem with alpha in agg, at least. The problems are illustrated in the attached modification of the custom_cmap.py example. I added a fourth panel for testing alpha. Look at the comments on the code for that panel, and try switching between pcolormesh and imshow. Pcolormesh basically works as expected, except for the prominent artifacts on patch boundaries (visible also in the colorbar for that panel). These boundary artifacts are the old problem. The new problem is that imshow with alpha in the colormap is completely wonky with a white background, but looks more normal with a black background--which is not so good if what you really want is a white background showing through the transparency. Eric |