matplotlib-devel Mailing List for matplotlib

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 :-)

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 <bra...@gm...>:
> 2010/10/18 Friedrich Romstedt <fri...@gm...>:
>> 2010/10/18 脑关(BrainGateway)生命科学仪器 <bra...@gm...>:
>>> On Mon, Oct 18, 2010 at 12:54 AM, Benjamin Root <ben...@ou...> wrote:
>>>> On Sun, Oct 17, 2010 at 5:35 PM, braingateway <bra...@gm...>
>>>> 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