Hello all,
I've stumbled onto a bug in colorbar() when displaying an image with a
nonlinear normalization (using a recent CVS version of mpl). If one
subclasses matplotlib.colors.normalize and uses a nonlinear function in the
__call__() method, then colorbar() will mismatch colors and data values in
the colorbar.
Some code illustrating a test case is attached. Here, I use the sqrt()
function to normalize some data in the domain (0, 10) to the range (0, 1)
[f(x)=sqrt(x/10)]. I display an image which consists of a linear ramp, each
value given by the abcissa. The normalization function y=f(x) is overplotted
for reference. imshow() applies the normalization before looking up the
colormap value, as expected (colors are bunched to the left). However, note
the values in the colorbar annotation do not correspond to the data values!
For example, pre-normalization data value 4 (x-axis) is correctly colored as
yellow, however the color bar erroneously lists that value as cyan (which is
the color where y=4/10=.4).
The error is that colorbar() assumes linearity over the normalization domain.
Ultimately, I think I'd like a choice as to whether to stretch colors in the
colorbar with a linear sampling of the data domain, or keep the color
sequence linear and invert the normalization step to determine the tick
values. Has anyone encountered and/or coded a solution for this?
Thanks,
Mike
colorbar_test.py (911 Bytes)
Michael,
You are right, I left the norm kwarg out of the contour function, and colorbar uses contourf. I think I have it fixed now, and I can commit to CVS shortly, but I should do a little more checking first. I will send you a png file offline, and you can tell me if it is giving the result you expect.
Eric
Michael Fitzgerald wrote:
···
Hello all,
I've stumbled onto a bug in colorbar() when displaying an image with a nonlinear normalization (using a recent CVS version of mpl). If one subclasses matplotlib.colors.normalize and uses a nonlinear function in the __call__() method, then colorbar() will mismatch colors and data values in the colorbar.
Some code illustrating a test case is attached. Here, I use the sqrt() function to normalize some data in the domain (0, 10) to the range (0, 1) [f(x)=sqrt(x/10)]. I display an image which consists of a linear ramp, each value given by the abcissa. The normalization function y=f(x) is overplotted for reference. imshow() applies the normalization before looking up the colormap value, as expected (colors are bunched to the left). However, note the values in the colorbar annotation do not correspond to the data values! For example, pre-normalization data value 4 (x-axis) is correctly colored as yellow, however the color bar erroneously lists that value as cyan (which is the color where y=4/10=.4).
The error is that colorbar() assumes linearity over the normalization domain. Ultimately, I think I'd like a choice as to whether to stretch colors in the colorbar with a linear sampling of the data domain, or keep the color sequence linear and invert the normalization step to determine the tick values. Has anyone encountered and/or coded a solution for this?
Thanks,
Mike
Mike,
Thanks for checking the output after the change. I have committed the change to CVS. There may be some lag before it shows up on your mirror.
The revisions are:
Checking in lib/matplotlib/contour.py;
/cvsroot/matplotlib/matplotlib/lib/matplotlib/contour.py,v <-- contour.py
new revision: 1.20; previous revision: 1.19
done
Checking in lib/matplotlib/figure.py;
/cvsroot/matplotlib/matplotlib/lib/matplotlib/figure.py,v <-- figure.py
new revision: 1.44; previous revision: 1.43
Eric
···
I've stumbled onto a bug in colorbar() when displaying an image with a nonlinear normalization (using a recent CVS version of mpl). If one subclasses matplotlib.colors.normalize and uses a nonlinear function in the __call__() method, then colorbar() will mismatch colors and data values in the colorbar.
Hi
With MPL 0.86 and 0.86.1 I found that the axes labels aren't centered (i.e. the xlabel is on the left side of the x-axis, the ylabel on the "bottom" of the y-axis). What's up?
cheers,
steve
···
--
"People like Blood Sausage too. People are Morons!" -- Phil Connors, Groundhog Day
I have exactly the same problem. I've posted it some months ago on this list
and the solution (delete ttfonts file) did not work for me. Is there some
news regarding this error?
Regards,
wr
···
Am Montag, 16. Januar 2006 17:14 schrieb Steve Schmerler:
Hi
With MPL 0.86 and 0.86.1 I found that the axes labels aren't centered
(i.e. the xlabel is on the left side of the x-axis, the ylabel on the
"bottom" of the y-axis). What's up?
cheers,
steve
Willi Richert wrote:
Hi
With MPL 0.86 and 0.86.1 I found that the axes labels aren't centered
(i.e. the xlabel is on the left side of the x-axis, the ylabel on the
"bottom" of the y-axis). What's up?
cheers,
steve
I have exactly the same problem. I've posted it some months ago on this list and the solution (delete ttfonts file) did not work for me. Is there some news regarding this error?
No. I posted several times about this issue but unfortunately nobody seems to have this problem and/or a solution. If you're also running Debian sagre stable then I guess one of the (many) libs that mpl is using is too old/buggy in stable.
On the other hand, my "workarround" (installing 0.82 debs first) shows that newer versions probably read some lib files written from 0.82. I didn't have time to fiddle out the details. At least a hint from a developer would help a lot here.
I must have missed this "solution" (delete ttfonts file). Do you have a link to the thread or do you remember the discussion subject?
cheers,
steve
···
Am Montag, 16. Januar 2006 17:14 schrieb Steve Schmerler:
--
Random number generation is the art of producing pure gibberish as quickly as possible.
I've just tried the latest version (87.2) and still have the same problem. The
install worked just fine (attached). The problem:
Text alignment with text() works, as I can test with
text(3, -4, r'l', fontsize=20, horizontalalignment='left')
text(3, -4, r'c', fontsize=20, horizontalalignment='center')
text(3, -4, r'r', fontsize=20, horizontalalignment='right')
However the xlabel/ylabel commands position the labels at the lower left
corner, which looks just ugly. Also the title is positioned at the upper left
corner.
Any further hint?
I use Fedora Core 3
matplotlib-fonterror.txt (54.8 KB)
···
Am Freitag, 17. März 2006 11:34 schrieb Steve Schmerler:
Willi Richert wrote:
> Am Montag, 16. Januar 2006 17:14 schrieb Steve Schmerler:
>>Hi
>>
>>With MPL 0.86 and 0.86.1 I found that the axes labels aren't centered
>>(i.e. the xlabel is on the left side of the x-axis, the ylabel on the
>>"bottom" of the y-axis). What's up?
>>
>>cheers,
>>steve
>
> I have exactly the same problem. I've posted it some months ago on this
> list and the solution (delete ttfonts file) did not work for me. Is there
> some news regarding this error?
No. I posted several times about this issue but unfortunately nobody
seems to have this problem and/or a solution. If you're also running
Debian sagre stable then I guess one of the (many) libs that mpl is
using is too old/buggy in stable.
On the other hand, my "workarround" (installing 0.82 debs first) shows
that newer versions probably read some lib files written from 0.82. I
didn't have time to fiddle out the details. At least a hint from a
developer would help a lot here.
I must have missed this "solution" (delete ttfonts file). Do you have a
link to the thread or do you remember the discussion subject?
cheers,
steve