On Tue, Jan 3, 2012 at 1:10 AM, Eric Firing <efir...@hawaii.edu> wrote:
> On 01/02/2012 05:51 PM, Tony Yu wrote:
>
>>
>>
>> On Mon, Jan 2, 2012 at 3:33 PM, Eric Firing <efir...@hawaii.edu
>> <mailto:efir...@hawaii.edu>> wrote:
>>
>> 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/__**matplotlib-users@lists.__**
>> sourceforge.net/msg09216.html<http://www.mail-archive.com/__matplotlib-users@lists.__sourceforge.net/msg09216.html>
>>
>> <http://www.mail-archive.com/**matplotlib-users@lists.**
>> sourceforge.net/msg09216.html<http://www.mail-archive.com/matplotlib-users@lists.sourceforge.net/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<https://github.com/efiring/__matplotlib/tree/colormap_alpha>
>>
>>
>> <https://github.com/efiring/**matplotlib/tree/colormap_alpha<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
>>
>>
>> This is great! I had hacked together a custom colormap class and
>> overrode its __call__ method to get a similar effect. This solution is
>> much more elegant and general.
>>
>> As for the imshow issue, it seems to be an issue with the "nearest"
>> interpolation method. The example copied below shows the result for
>> three different interpolation methods. The weird behavior only occurs
>> when interpolation is set to 'nearest' (I checked all other
>> interpolation methods, not just the 3 below). What's really strange is
>> that `interpolation='none'` gives the expected result, but in theory,
>> 'none' maps to the same interpolation function as 'nearest'. A quick
>> scan of matplotlib.image suggests that 'none' and 'nearest' share the
>> same code path, but I'm obviously missing something.
>>
>
> It looks to me like 'none' is going through _draw_unsampled_image instead
> of the path that all the other interpolations, including 'nearest' go
> through. I think that JJ put in this unsampled functionality about two
> years ago. I've never dug into the guts of image operations and rendering,
> so I don't even understand what sort of "sampling" is referred to here.
>
> Eric
>
Well, that's embarrassing: Apparently I searched for 'none' with single
quotes, but not double quotes.
Unfortunately, I can't figure out the issue, but while debugging, I noticed
that constant alpha values have the same issue. For example, if you replace
the alpha spec in the custom colormap with:
'alpha': ((0.0, 0.7, 0.7),
(1.0, 0.7, 0.7))}
then you see the same issue. If, however, you set alpha to 1 in the
colormap, but set `alpha=1` in `imshow`, then everything works as expected.
It almost seems like it maybe an overflow issue. As you gradually decrease
the alpha value (in the colormap, not in imshow), the whiter colors start
to get weird, then successively darker colors get weird---you can check
this with the script copied below.
In any case, I think the problem is in C-code, which I'm not really
equipped to debug. Hopefully, someone else can track this down.
-Tony
import numpy as np
import matplotlib.pyplot as plt
from matplotlib.colors import LinearSegmentedColormap
cdict = {'red': ((0.0, 0.0, 0.0),
(0.5, 0.8, 1.0),
(1.0, 0.4, 1.0)),
'green': ((0.0, 0.0, 0.0),
(0.5, 0.9, 0.9),
(1.0, 0.0, 0.0)),
'blue': ((0.0, 0.0, 0.4),
(0.5, 1.0, 0.8),
(1.0, 0.0, 0.0))}
w = 10
y = np.linspace(0, 2*np.pi, w+1)
Z = np.tile(y, (w+1, 1))
alpha_values = (1, 0.9, 0.7, 0.5)
f, axes = plt.subplots(ncols=len(alpha_values))
for i, (ax, alpha) in enumerate(zip(axes, alpha_values)):
cdict = cdict.copy()
cdict['alpha'] = [(0.0, alpha, alpha), (1.0, alpha, alpha)]
cmap = LinearSegmentedColormap('BlueRedAlpha%i' % i, cdict)
im = ax.imshow(Z, interpolation='nearest', cmap=cmap)
ax.set_title('alpha = %g' % alpha)
plt.show()
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
