Re: [matplotlib-devel] [Matplotlib-users] contourf with rgba colours

2012-01-02 Thread Eric Firing 

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/[email protected]/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
#!/usr/bin/env python

import numpy as np
import matplotlib.pyplot as plt
from matplotlib.colors import LinearSegmentedColormap

"""

Example: suppose you want red to increase from 0 to 1 over the bottom
half, green to do the same over the middle half, and blue over the top
half.  Then you would use:

cdict = {'red':   ((0.0,  0.0, 0.0),
   (0.5,  1.0, 1.0),
   (1.0,  1.0, 1.0)),

 'green': ((0.0,  0.0, 0.0),
   (0.25, 0.0, 0.0),
   (0.75, 1.0, 1.0),
   (1.0,  1.0, 1.0)),

 'blue':  ((0.0,  0.0, 0.0),
   (0.5,  0.0, 0.0),
   (1.0,  1.0, 1.0))}

If, as in this example, there are no discontinuities in the r, g, and b
components, then it is quite simple: the second and third element of
each tuple, above, is the same--call it "y".  The first element ("x")
defines interpolation intervals over the full range of 0 to 1, and it
must span that whole range.  In other words, the values of x divide the
0-to-1 range into a set of segments, and y gives the end-point color
values for each segment.

Now consider the green. cdict['green'] is saying that for
0 <= x <= 0.25, y is zero; no green.
0.25 < x <= 0.75, y varies linearly from 0 to 1.
x > 0.75, y remains at 1, full green.

If there are discontinuities, then it is a little more complicated.
Label the 3 elements in each row in the cdict entry for a given color as
(x, y0, y1).  Then for values of x between x[i] and x[i+1] the color
value is interpolated between y1[i] and y0[i+1].

Going back to the cookbook example, look at cdict['red']; because y0 !=
y1, it is saying that for x from 0 to 0.5, red increases from 0 to 1,
but then it jumps down, so that for x from 0.5 to 1, red increases from
0.7 to 1.  Green ramps from 0 to 1 as x goes from 0 to 0.5, then jumps
back to 0, and ramps back to 1 as x goes from 0.5 to 1.

row i:   x  y0  y1
/
   /
row i+1: x  y0  y1

Above is an attempt to show that for x in the range x[i] to x[i+1], the
interpolation is between y1[i] and y0[i+1].  So, y0[0] and y1[-1] are
never used.

"""



cdict1 = {'red':   ((0.0, 0.0, 0.0),
   (0.5, 0.0, 0.1),
   (1.0, 1.0, 1.0)),

 'green': ((0.0, 0.0, 0.0),
   (1.0, 0.0, 0.0)),

 'blue':  ((0.0, 0.0, 1.0),
   (0.5, 0.1, 0.0),
   (1.0, 0.0, 0.0))
}

cdict2 = {'red':   ((0.0, 0.0, 0.0),
   (0.5, 0.0, 1.0),
   (1.0, 0.1, 1.0)),

 'green': ((0.0, 0.0, 0.0),
   (1.0, 0.0, 0.0)),

 'blue':  ((0.0, 0.0, 0.1),
   (0.5, 1.0, 0.0),
   (1.0, 0.0, 0.0))
}

cdict3 = {'red':  ((0.0, 0.0, 0.0),
   (0.25,0.0, 0.0),
   (0.5, 0.8, 1.0),
   (0.75,1.0, 1.0),
   (1.0, 0.4, 1.0)),

 'green': ((0.0, 0.0, 0.0),
   (0.25,0.0, 0.0),
   (0.5, 0.9, 0.9),
   (0.75,0.0, 0.0),
   (1.0, 0.0, 0.0)),

 'blue':  ((0.0, 0.0, 0.4),
   (0.25,1.0, 1.0),
   (0.5, 1.0, 0.8),

Re: [matplotlib-devel] [Matplotlib-users] contourf with rgba colours

2012-01-02 Thread Tony Yu 
On Mon, Jan 2, 2012 at 3:33 PM, Eric Firing  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
>>
>> 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
>

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()
#
--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] [Matplotlib-users] contourf with rgba colours

2012-01-02 Thread Eric Firing 
On 01/02/2012 05:51 PM, Tony Yu wrote:
>
>
> On Mon, Jan 2, 2012 at 3:33 PM, Eric Firing  > 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
> 
> 
>
> 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
>
>
> 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()
> #


--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu