matplotlib-devel Mailing List for matplotlib

On Tue, Jan 3, 2012 at 10:12 AM, Michael Droettboom <md...@st...> wrote:
> I've been away on vacation -- just to confirm, it looks like Benjamin
> Root (@WeatherGod) has already got around to doing this?
>
> Mike
>
>
No, I think it was done before me. My merge only brought in a one-line fix.
Ben Root

I've been away on vacation -- just to confirm, it looks like Benjamin 
Root (@WeatherGod) has already got around to doing this?
Mike
On 12/27/2011 03:07 PM, Jouni K. Seppänen wrote:
> I had some time to work on matplotlib, and created pull request #633 to
> fix a bug reported recently. I branched off v1.1.x since the fix is
> small and self-contained, and thought I'd create a different branch for
> master, where the relevant code has changed a little. (What should the
> process be in this kind of cases?)
>
> However, it seems that v1.1.x has diverged from master:
>
> commit 2da9d8fb5d087eaeb31c0af88141aafaf0716e9c
> Merge: 3c3c466 585606f
> Author: Eric Firing<ef...@ha...>
> Date: Wed Dec 14 10:01:53 2011 -0800
>
> Merge pull request #627 from efiring/quiver_angle
>
> Quiver: copy input angles array to avoid side effects; fixes issue #625
>
> commit 3c3c466564cba3d80f928a46857e54738787779b
> Merge: 96caca8 fb52b96
> Author: Michael Droettboom<md...@gm...>
> Date: Wed Dec 14 06:10:26 2011 -0800
>
> Merge pull request #586 from mdboom/numpy-version-13
>
> Numpy version 1.4
>
> commit 585606f7bd79b93cbaa9d538cbf537c82cb9a4a6
> Author: Eric Firing<ef...@ha...>
> Date: Tue Dec 13 07:53:54 2011 -1000
>
> Quiver: copy input angles array to avoid side effects; fixes issue #625
>
> commit fb52b961a596c41fa2a1bb2dd85d7078f2ad39de
> Author: Michael Droettboom<md...@gm...>
> Date: Mon Nov 14 14:42:28 2011 -0500
>
> Put the minimum required version of Numpy in one place.
>
> commit bf73b9088e0ce5e2dfcc5b2cac9a4f20515ed9f2
> Author: Michael Droettboom<md...@gm...>
> Date: Mon Nov 14 08:31:34 2011 -0500
>
> Update checks and documentation to refer to Numpy 1.4 as the minimum Numpy version.
>
> I presume all of these changes are wanted on master, but the branch
> doesn't merge cleanly. It would probably be best if the author of each
> change did the merging into master, since they know best how to resolve
> any merge conflicts. I can make a suggested merge as a pull request, but
> it would be best if Eric and Michael reviewed it.
>

On 01/02/2012 05:51 PM, Tony Yu wrote:
>
>
> On Mon, Jan 2, 2012 at 3:33 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> 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/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
> <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
>
> -Tony
>
> #~~~~
> import matplotlib.pyplot as plt
>
>
> 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)),
>
> 'alpha': ((0.0, 1.0, 1.0),
> (0.5, 0.3, 0.3),
> (1.0, 1.0, 1.0))}
>
> plt.register_cmap(name='BlueRedAlpha', data=cdict)
>
>
> if __name__ == '__main__':
> import numpy as np
>
> w = 10
> y = np.linspace(0, 2*np.pi, w+1)
> Z = np.tile(y, (w+1, 1))
>
> plt.rcParams['image.cmap'] = 'BlueRedAlpha'
>
> f, axes = plt.subplots(ncols=3)
> interp_method = ['none', 'bilinear', 'nearest']
> for interp, ax in zip(interp_method, axes):
> # Draw a line with low zorder so it will be behind the image.
> ax.plot([0, w], [0, w], color='c', lw=20, zorder=-1)
> ax.imshow(Z, interpolation=interp)
> ax.set_title(interp)
>
> plt.show()
> #~~~~

On Mon, Jan 2, 2012 at 3:33 PM, Eric Firing <ef...@ha...> 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/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<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.
-Tony
#~~~~
import matplotlib.pyplot as plt
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)),
 'alpha': ((0.0, 1.0, 1.0),
 (0.5, 0.3, 0.3),
 (1.0, 1.0, 1.0))}
plt.register_cmap(name='BlueRedAlpha', data=cdict)
if __name__ == '__main__':
 import numpy as np
 w = 10
 y = np.linspace(0, 2*np.pi, w+1)
 Z = np.tile(y, (w+1, 1))
 plt.rcParams['image.cmap'] = 'BlueRedAlpha'
 f, axes = plt.subplots(ncols=3)
 interp_method = ['none', 'bilinear', 'nearest']
 for interp, ax in zip(interp_method, axes):
 # Draw a line with low zorder so it will be behind the image.
 ax.plot([0, w], [0, w], color='c', lw=20, zorder=-1)
 ax.imshow(Z, interpolation=interp)
 ax.set_title(interp)
 plt.show()
#~~~~