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