[Matplotlib-users] problem of cm.get_cmap('gist_rainbow', 256)

Bug fixed in repo github.com/friedrichromstedt/matplotlib:trunk

A pull by astraw if possible would be great, I don't want to merge in
the trunk from astraw all the time, according to numpy-discussion this
will generate messy structure once we switched to GitHub :slight_smile:

UNTESTED, LittleBigBrain (how's your real name?), can you please fetch
from that repo and run the test suite, I have to work for numpy 10.5
Installers.

Your tests provided by you pass now. But it might break other things
if I had bad luck.

Alternatively I can provide the diff, if someone tells me how to do
that. First awaiting LittleBigBrain's test results.

Friedrich

2010/10/18 LittleBigBrain <braingateway@...149...>:

···

2010/10/18 Friedrich Romstedt <friedrichromstedt@...149...>:

2010/10/18 脑关(BrainGateway)生命科学仪器 <braingateway@...149...>:

On Mon, Oct 18, 2010 at 12:54 AM, Benjamin Root <ben.root@...553...> wrote:

On Sun, Oct 17, 2010 at 5:35 PM, braingateway <braingateway@...149...> >>>> wrote:

I tried all possible colormaps and found out: gist_rainbow, terrain,
bwr, brg, and seismic will generate the same error, all other colormaps
are OK. I wonder is this a bug or expected behavior?

Hi Ben,
Thanks a lot for answering my question! I am a newbie to matplotlib,
so please forgive me, if the question is stupid ;p

Questions are never stupid ...

In my program I wanna know the exact RGBA value of a data point in the
figure, in order to plot a corresponding line with the same color in
another figure. That is why I need to call a(z) to get RGBA value of a
point at (x,y,z) (z is represented by color). If I understood it
correctly, you said I do not need to specify the 'lut' in
cm.get_cmap(name,lut)? I thought the colormap object is actually a
lookup table with a length specified by lut.

Kind of, but it's initialised from a linear segmentation dictionary,
so you can get cmaps with a precision you want.

It turns out I do not
need to specify anything here.

Default param is 256.

But if I do not specify anything the
colormap.N is always 256. What will happen then, if I need more color
steps?

cm = get_cmap('...', 1024)

I do notice a(2) and a(2.2) returns different values. So I am
very confused about the principle how the RGBA value is generated by
the colormaps.

It's the "magic" to distinguish between integer (in the LUT range) and
float (in [0.0, 1.0]). 2 gives the LUT entry 2, 2.0 will give the
upper value since it's > 1, as will 2.2 do. Try 0.5, and 0.6, or 0.0
and 0.1.

Actually I cannot reproduce your error on a recently (some weeks ago)
checked-out GitHub repo version of mpl 1.0.0. Please provide
mpl.__version__ so that we check if that's the reason - as simple as
it might be.

MacBook-Pro-Friedrich:Report Friedrich$ python
Python 2.6.5 (r265:79063, Jul 18 2010, 12:14:53)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

import matplotlib.cm
cm = matplotlib.cm.get_cmap('gist_rainbow')
cm(range(256))

array([[ 1. , 0. , 0.16 , 1. ],
      [ 1. , 0. , 0.13908497, 1. ],
      [ 1. , 0. , 0.11816993, 1. ],
      ...,
      [ 1. , 0. , 0.79262575, 1. ],
      [ 1. , 0. , 0.77131287, 1. ],
      [ 1. , 0. , 0.75 , 1. ]])

print matplotlib.__version__

1.0.0

The attribute of the cm where the error occurs on your machine is set
to a valid value for me. I also cannot find any code path leading to
a wrong initialisation of the attribute. Might be that the data the
cm is init'ed from changed. There is a code path initialising the cm
from a tuple (your attribute was a tuple used like a dict), but this
works too: (terrain is such an example):

cm = matplotlib.cm.get_cmap('terrain')
cm(range(256))

array([[ 0.2 , 0.2 , 0.6 , 1. ],
      [ 0.19477124, 0.21045752, 0.61045752, 1. ],
      [ 0.18954248, 0.22091503, 0.62091503, 1. ],
      ...,
      [ 0.98431373, 0.97992157, 0.97898039, 1. ],
      [ 0.99215686, 0.98996078, 0.9894902 , 1. ],
      [ 1. , 1. , 1. , 1. ]])

Might be that there was 'red' misspelled in gist_rainbow in you mpl
version, this may explain the behaviour if we track it down. Can you
do the following to verify this:

import matplotlib._cm
print matplotlib._cm._gist_stern_data

? Thx,
Friedrich

Thanks a lot for your detailed response!
In previous posts I did give the version: '1.0.svn'. Then I installed
the latest stable version. Here is the version info:

print matplotlib.__version__

1.0.0

However, the error is still there.

You could not reproduce the error in your code, because you did not
specify 'lut' when you call get_cmap
try this:
maps=[m for m in matplotlib.cm.datad if not m.endswith("_r")]
for i in maps:
       try:
               a=matplotlib.cm.get_cmap(i,256)(range(256))
       except:
               (type, value, traceback) = sys.exc_info()
               print "Problems to create %s" % (i,)
               print "The error was --> %s: %s" % (type, value)
u will reproduce the error.

Thanks very much to point out I could actually print the colormap
definition-data.
I printed all of them, and found out the colormaps invoking errors are
all tuples but not dictionaries and all other colormaps are actually
dictionaries.
###Examples without Errors###
###They are all dictionaries###
print matplotlib._cm._gist_stern_data
{'blue': ((0.0, 0.0, 0.0), (0.5, 1.0, 1.0), (0.73499999999999999, 0.0,
0.0), (1.0, 1.0, 1.0)), 'green': ((0, 0, 0), (1, 1, 1)), 'red': ((0.0,
0.0, 0.0), (0.054699999999999999, 1.0, 1.0), (0.25, 0.027, 0.25),
(1.0, 1.0, 1.0))}
print matplotlib._cm._jet_data
{'blue': ((0.0, 0.5, 0.5), (0.11, 1, 1), (0.34000000000000002, 1, 1),
(0.65000000000000002, 0, 0), (1, 0, 0)), 'green': ((0.0, 0, 0),
(0.125, 0, 0), (0.375, 1, 1), (0.64000000000000001, 1, 1),
(0.91000000000000003, 0, 0), (1, 0, 0)), 'red': ((0.0, 0, 0),
(0.34999999999999998, 0, 0), (0.66000000000000003, 1, 1),
(0.89000000000000001, 1, 1), (1, 0.5, 0.5))}
###Colormaps invoking Errors###
###They are all Tuples###
Problems to create gist_rainbow
((0.0, (1.0, 0.0, 0.16)), (0.029999999999999999, (1.0, 0.0, 0.0)),
(0.215, (1.0, 1.0, 0.0)), (0.40000000000000002, (0.0, 1.0, 0.0)),
(0.58599999999999997, (0.0, 1.0, 1.0)), (0.77000000000000002, (0.0,
0.0, 1.0)), (0.95399999999999996, (1.0, 0.0, 1.0)), (1.0, (1.0, 0.0,
0.75)))
The error was --> <type 'exceptions.TypeError'>: tuple indices must be
integers, not str
Problems to create terrain
((0.0, (0.20000000000000001, 0.20000000000000001,
0.59999999999999998)), (0.14999999999999999, (0.0,
0.59999999999999998, 1.0)), (0.25, (0.0, 0.80000000000000004,
0.40000000000000002)), (0.5, (1.0, 1.0, 0.59999999999999998)), (0.75,
(0.5, 0.35999999999999999, 0.33000000000000002)), (1.0, (1.0, 1.0,
1.0)))
The error was --> <type 'exceptions.TypeError'>: tuple indices must be
integers, not str
Problems to create bwr
((0.0, 0.0, 1.0), (1.0, 1.0, 1.0), (1.0, 0.0, 0.0))
The error was --> <type 'exceptions.TypeError'>: tuple indices must be
integers, not str
Problems to create brg
((0.0, 0.0, 1.0), (1.0, 0.0, 0.0), (0.0, 1.0, 0.0))
The error was --> <type 'exceptions.TypeError'>: tuple indices must be
integers, not str
Problems to create seismic
((0.0, 0.0, 0.29999999999999999), (0.0, 0.0, 1.0), (1.0, 1.0, 1.0),
(1.0, 0.0, 0.0), (0.5, 0.0, 0.0))
The error was --> <type 'exceptions.TypeError'>: tuple indices must be
integers, not str