From: Michael F. <fi...@as...> - 2006-01-15 19:53:56
Attachments:
colorbar_test.py
|
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 |
From: Eric F. <ef...@ha...> - 2006-01-16 00:43:12
|
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 > |
From: Eric F. <ef...@ha...> - 2006-01-16 02:08:47
|
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. |
From: Steve S. <el...@gm...> - 2006-01-16 16:15:08
|
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 |
From: Willi R. <w.r...@gm...> - 2006-03-17 09:47:31
|
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? Regards, wr |
From: Steve S. <el...@gm...> - 2006-03-17 10:34:56
|
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 -- Random number generation is the art of producing pure gibberish as quickly as possible. |
From: Willi R. <w.r...@gm...> - 2006-03-17 14:12:15
Attachments:
matplotlib-fonterror.txt
|
I've just tried the latest version (87.2) and still have the same problem. = The=20 install worked just fine (attached). The problem: Text alignment with text() works, as I can test with text(3, -4, r'l', fontsize=3D20, horizontalalignment=3D'left') text(3, -4, r'c', fontsize=3D20, horizontalalignment=3D'center') text(3, -4, r'r', fontsize=3D20, horizontalalignment=3D'right') However the xlabel/ylabel commands position the labels at the lower left=20 corner, which looks just ugly. Also the title is positioned at the upper le= ft=20 corner. Any further hint? I use Fedora Core 3 Am Freitag, 17. M=E4rz 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 the= re > > 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 |
From: John H. <jdh...@ac...> - 2006-03-17 16:06:45
|
>>>>> "Steve" == Steve Schmerler <el...@gm...> writes: Steve> No. I posted several times about this issue but Steve> unfortunately nobody seems to have this problem and/or a Steve> solution. If you're also running Debian sagre stable then I Steve> guess one of the (many) libs that mpl is using is too Steve> old/buggy in stable. Interesting also that both of you appear to have german as your default language. I wonder if one of the default fonts you are using is different and is providing bad font metrics. Could you run a script in the environment which produces the error with --verbose-debug, and then again in the environment which doesn't with the same flag and post the output of both cases. Maybe something about first installing 0.82 and then removing it makes a difference in which fonts are found. Just guessing. But verbose-debug will at least identify which font files are being loaded. If you could do the same Willi, we might be able to triangulate on the common cause for this problem. JDH |
From: Steve S. <el...@gm...> - 2006-03-17 20:39:36
|
John Hunter wrote: >>>>>>"Steve" == Steve Schmerler <el...@gm...> writes: > > Steve> No. I posted several times about this issue but > Steve> unfortunately nobody seems to have this problem and/or a > Steve> solution. If you're also running Debian sagre stable then I > Steve> guess one of the (many) libs that mpl is using is too > Steve> old/buggy in stable. > > Interesting also that both of you appear to have german as your > default language. I wonder if one of the default fonts you are using > is different and is providing bad font metrics. Could you run a > script in the environment which produces the error with > --verbose-debug, and then again in the environment which doesn't with > the same flag and post the output of both cases. Maybe something > about first installing 0.82 and then removing it makes a difference in > which fonts are found. Just guessing. But verbose-debug will at > least identify which font files are being loaded. > sorry forgot to attach the files :) here the test script: ---------------------------------------------- plot([1,2,3]) xlabel('x-label') ylabel('y-label') show() ---------------------------------------------- attached files: mpl_svn0.87.2_bad_labels.txt mpl_deb0.82_good_labels.txt mpl_svn0.87.2_good_labels_run_1.txt mpl_svn0.87.2_good_labels_run_2.txt uninstall.sh what I did: 1) * no mpl stuff on the machine, removed .matplotlibrc/.tex.cache and .matplotlibrc/.ttffont.cache * installed latest svn (0.87.2) * the 1st run creates .matplotlib/.tex.cache and ./matplotlib/.ttffont.cache * the --verbose-debug output of a normal run is in mpl_svn0.87.2_bad_labels.txt * the x-axis starts at -1, not at 0, labels have the wrong position 2) * uninstalled 0.87.2 with uninstall.sh * istalled 0.82 debs * labels OK, --verbose-debug output in mpl_deb0.82_good_labels.txt 3) * removed 0.87.2 build folder, *not* $HOME/.tex.cache, $HOME/.ttffont.cache (which is 0.82 stuff) * recompiled and installed 0.87.2 * labels OK * the output of the 1st run where .matplotlibrc/.tex.cache and .matplotlibrc/.ttffont.cache are created is in mpl_svn0.87.2_good_labels_run_1.txt (copy-paste from shell) * the normal-run output is in mpl_svn0.87.2_good_labels_run_2.txt Now the outputs mpl_svn0.87.2_bad_labels.txt and mpl_svn0.87.2_good_labels_run_2.txt should show some difference regarding loaded font libs but they don't .... ---------------------------------------------------------------------- elcorto@ramrod:~$ diff -cbB mpl_svn0.87.2_bad_labels.txt mpl_svn0.87.2_good_labels_run_2.txt *** mpl_svn0.87.2_bad_labels.txt 2006-03-17 20:39:53.000000000 +0100 --- mpl_svn0.87.2_good_labels_run_2.txt 2006-03-17 21:10:11.000000000 +0100 *************** *** 1,3 **** --- 1,6 ---- + elcorto@ramrod:~$ python test.py --verbose-debug + /usr/lib/python2.3/site-packages/pylab.py:1: DeprecationWarning: Non-ASCII character '\xc3' in file /usr/lib/python2.3/site-packages/matplotlib/__init__.py on line 148, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details + from matplotlib.pylab import * matplotlib data path /usr/lib/python2.3/site-packages/matplotlib/mpl-data $HOME=/home/elcorto CONFIGDIR=/home/elcorto/.matplotlib ---------------------------------------------------------------------- (The DeprecationWarning is caused because of the line __date__ = '$Date: 2006-03-17 20:21:28 +0100 (Fr, 17 Mär 2006) $' where obviously the german date (output of date?) causes some little trouble) cheers, steve -- Random number generation is the art of producing pure gibberish as quickly as possible. |
From: John H. <jdh...@ac...> - 2006-03-17 20:56:10
|
>>>>> "Steve" == Steve Schmerler <el...@gm...> writes: Steve> sorry forgot to attach the files :) OK< after a quick look here is a new approach to think about. After you install and run 0.82, and then build 0.87.x, you did not flush the font cache or tex cache dir, right? In this case the font caching mechanism may be picking up the old font dir look for 'font search path' in your logs. What happens if you first install 0.82, run it, then install 0.87, run it, then flush the font and tex cache. Does 87 then fail as before. Ie is it the running of 0.82 and the preservation of the font cache information that is causing 0.87 to work? Arguing against this is that findfont seems to be returning Vera.ttf in both cases. In any case, an important clue would be to know whether wiping out ~/.matplotlib/*.cache restores the bug in 0.87.x JDH |
From: Steve S. <el...@gm...> - 2006-03-17 21:12:19
|
John Hunter wrote: >>>>>>"Steve" == Steve Schmerler <el...@gm...> writes: > > > Steve> sorry forgot to attach the files :) > > OK< after a quick look here is a new approach to think about. After > you install and run 0.82, and then build 0.87.x, you did not flush the > font cache or tex cache dir, right? In this case the font caching > mechanism may be picking up the old font dir look for 'font search > path' in your logs. What happens if you first install 0.82, run it, > then install 0.87, run it, then flush the font and tex cache. Does 87 > then fail as before. Ie is it the running of 0.82 and the > preservation of the font cache information that is causing 0.87 to > work? Arguing against this is that findfont seems to be returning > Vera.ttf in both cases. > > In any case, an important clue would be to know whether wiping out > ~/.matplotlib/*.cache restores the bug in 0.87.x > No. I removed elcorto@ramrod:~$ rm -r .matplotlib/tex.cache/ .matplotlib/ttffont.cache .ttffont.cache and ran the script. It doesn't fail. Note that I still had a .ttffont.cache (from 0.82) in my $HOME (because I did not remove *anything* related to 0.82 before building 0.87.2). But even removing this doesn't change anything. Does mpl (0.87.2) maybe include 0.82 stuff during the build process? cheers, steve ps: I always get your mails twice :) -- Random number generation is the art of producing pure gibberish as quickly as possible. |
From: Steve S. <el...@gm...> - 2006-03-27 20:05:26
|
John Hunter wrote: > Interesting also that both of you appear to have german as your > default language. I wonder if one of the default fonts you are using > is different and is providing bad font metrics. Hi Finally I found some time to check this one. I changed my system language from german into english and the problem went away. Although I wonder which files mpl loads are different since a run with --verbose=debug says font search path ['/usr/lib/python2.3/site-packages/matplotlib/mpl-data'] trying fontname /usr/lib/python2.3/site-packages/matplotlib/mpl-data/VeraSe.ttf trying fontname /usr/lib/python2.3/site-packages/matplotlib/mpl-data/VeraMono.ttf trying fontname /usr/lib/python2.3/site-packages/matplotlib/mpl-data/cmr10.ttf trying fontname /usr/lib/python2.3/site-packages/matplotlib/mpl-data/cmtt10.ttf trying fontname /usr/lib/python2.3/site-packages/matplotlib/mpl-data/cmmi10.ttf trying fontname /usr/lib/python2.3/site-packages/matplotlib/mpl-data/VeraMoBd.ttf trying fontname /usr/lib/python2.3/site-packages/matplotlib/mpl-data/VeraBI.ttf trying fontname /usr/lib/python2.3/site-packages/matplotlib/mpl-data/Vera.ttf loaded ttfcache file /home/elcorto/.matplotlib/ttffont.cache backend GTKAgg version 2.6.1 findfont failed Lucida Grande findfont failed Verdana findfont failed Geneva findfont failed Lucida findfont found Bitstream Vera Sans, normal, normal 500, normal, 12.0 findfont returning /usr/lib/python2.3/site-packages/matplotlib/mpl-data/Vera.ttf So does mpl use system fonts as well as it's own? cheers, steve ps: Some time ago I posted a _mathtext_data.py which turns slanted uppercase greek letters into non-slanted ones. It works nicely here on my system. Has anyone of the developers had a look at it? -- Random number generation is the art of producing pure gibberish as quickly as possible. |
From: Steve S. <el...@gm...> - 2006-03-17 20:37:56
|
John Hunter wrote: >>>>>>"Steve" == Steve Schmerler <el...@gm...> writes: > > Steve> No. I posted several times about this issue but > Steve> unfortunately nobody seems to have this problem and/or a > Steve> solution. If you're also running Debian sagre stable then I > Steve> guess one of the (many) libs that mpl is using is too > Steve> old/buggy in stable. > > Interesting also that both of you appear to have german as your > default language. I wonder if one of the default fonts you are using > is different and is providing bad font metrics. Could you run a > script in the environment which produces the error with > --verbose-debug, and then again in the environment which doesn't with > the same flag and post the output of both cases. Maybe something > about first installing 0.82 and then removing it makes a difference in > which fonts are found. Just guessing. But verbose-debug will at > least identify which font files are being loaded. > here the test script: ---------------------------------------------- plot([1,2,3]) xlabel('x-label') ylabel('y-label') show() ---------------------------------------------- attached files: mpl_svn0.87.2_bad_labels.txt mpl_deb0.82_good_labels.txt mpl_svn0.87.2_good_labels_run_1.txt mpl_svn0.87.2_good_labels_run_2.txt uninstall.sh what I did: 1) * no mpl stuff on the machine, removed .matplotlibrc/.tex.cache and .matplotlibrc/.ttffont.cache * installed latest svn (0.87.2) * the 1st run creates .matplotlib/.tex.cache and ./matplotlib/.ttffont.cache * the --verbose-debug output of a normal run is in mpl_svn0.87.2_bad_labels.txt * the x-axis starts at -1, not at 0, labels have the wrong position 2) * uninstalled 0.87.2 with uninstall.sh * istalled 0.82 debs * labels OK, --verbose-debug output in mpl_deb0.82_good_labels.txt 3) * removed 0.87.2 build folder, *not* $HOME/.tex.cache, $HOME/.ttffont.cache (which is 0.82 stuff) * recompiled and installed 0.87.2 * labels OK * the output of the 1st run where .matplotlibrc/.tex.cache and .matplotlibrc/.ttffont.cache are created is in mpl_svn0.87.2_good_labels_run_1.txt (copy-paste from shell) * the normal-run output is in mpl_svn0.87.2_good_labels_run_2.txt Now the outputs mpl_svn0.87.2_bad_labels.txt and mpl_svn0.87.2_good_labels_run_2.txt should show some difference regarding loaded font libs but they don't .... ---------------------------------------------------------------------- elcorto@ramrod:~$ diff -cbB mpl_svn0.87.2_bad_labels.txt mpl_svn0.87.2_good_labels_run_2.txt *** mpl_svn0.87.2_bad_labels.txt 2006-03-17 20:39:53.000000000 +0100 --- mpl_svn0.87.2_good_labels_run_2.txt 2006-03-17 21:10:11.000000000 +0100 *************** *** 1,3 **** --- 1,6 ---- + elcorto@ramrod:~$ python test.py --verbose-debug + /usr/lib/python2.3/site-packages/pylab.py:1: DeprecationWarning: Non-ASCII character '\xc3' in file /usr/lib/python2.3/site-packages/matplotlib/__init__.py on line 148, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details + from matplotlib.pylab import * matplotlib data path /usr/lib/python2.3/site-packages/matplotlib/mpl-data $HOME=/home/elcorto CONFIGDIR=/home/elcorto/.matplotlib ---------------------------------------------------------------------- (The DeprecationWarning is caused because of the line __date__ = '$Date: 2006-03-17 20:21:28 +0100 (Fr, 17 Mär 2006) $' where obviously the german date (output of date?) causes some little trouble) cheers, steve -- Random number generation is the art of producing pure gibberish as quickly as possible. |
From: John H. <jdh...@ac...> - 2006-03-17 20:45:21
|
>>>>> "Steve" == Steve Schmerler <el...@gm...> writes: Steve> here the test script: Well, your tests certainly look exhaustive and repeatable and it looks like you are doing everything right. From the diff you posted it certainly doesn't look like my hypothesis is correct. I did not see the attachments thought; could you send them along as well? JDH |