matplotlib-users Mailing List for matplotlib

Howdy all,

I have a very obscure (and minor) colormapping issue which I would like to 
discuss. I am writing a workaround and the question is whether or not this 
is worth changing the base matplotlib distribution. The issue applies to 
any code that uses colormapping such as matshow or imshow. I am going to 
write the change and it is up to the user community whether anyone else in 
the world cares about this.

In color.py::LinearSegmentedColormap.__call__
The code that determines the colormap value in the look up table is

         xa = (xa *(self.N-1)).astype(Int)
         rgba = zeros(xa.shape+(4,), Float)
         rgba[...,0] = take(self._red_lut, xa)
         rgba[...,1] = take(self._green_lut, xa)
         rgba[...,2] = take(self._blue_lut, xa)

I am using colormaps for thresholding data. If the normalized image value 
is less than some threshold I plot one color, if it is above that 
threshold, I plot a second color. All images produced this way are two 
colors. This is just what I do, but the issue is always there for thresholding.

Here's the issue. The code line xa = (xa *(self.N-1)).astype(Int) simply 
truncates the data, in essence taking the floor of xa, the reason why this 
matters is that value always get rounded down, so intensities above the 
threshold all get mapped to the threshold value. The error is small and 
dependent only on the quantization of the colormap, normally N=256. 
Nonetheless, there are times, like when the threshold is 0 that the rounded 
down values are visible and should not be.

The best way to make thresholds get rid of this problem is to use the 
ceiling function. So the code would read
         xa = ceil(xa *(self.N-1)).astype(Int)

Then intensities are rounded up, which is safe for thresholding. Note that 
the original code is not wrong. There  are circumstance when it does the 
correct thing, even with thresholding. The new line also takes (not much) 
longer because of the ceil function.

There is a fudge involving only user code, which would be to negate the 
image data and reverse the colormap, but that is not particularly pretty.

My personal suggestion is to include a flag in the declaration of the colormap:

     def __init__(self, name, segmentdata, N=256, ceiling=False):
	self.ceiling = ceiling

then in the __call__ routine:

	if self.ceiling:
	        xa = ceil(xa *(self.N-1)).astype(Int)
	else:
	        xa = (xa *(self.N-1)).astype(Int)

Let me know what you think.

Danny

Darren Dale wrote:
 > On Monday 01 August 2005 08:36 am, Gary Ruben wrote:
<snip>
 > Do you mean ps is broken with TeX support, or it is broken period?

Just the TeX->ps support is broken.

>>>>> "kristen" == kristen kaasbjerg <co...@ya...> writes:

    kristen> First of all, matplotlibrc is NOT put in the intended
    kristen> directory upon istallation. It resides in the old
    kristen> share\matplotlib\. This must be done manually!!

There seems to be some confusion on this point, because Mark Bakker
reported the same problem.  matplotlib has never move the rc file from
the default location share\matplotlib to the user location, because
new installs would overwrite the user specific configuration.  I think
the confusion is that on windows, we never had a default user location
for the rc file.  I'll explain how it has always worked under
linux/unix; maybe this will make it clear how it should now work under
windows.

matplotlib installs the rc file to /usr/share/matplotlib/matplotlibrc.
You can copy this file to your configuration directory,
HOME/.matplotlibrc, and this file will be used first if it exists.
That way future installs to /usr/share/matplotlib will not mess up
your local configurations.  On windows, the default path is
c:\Python23\share\matplotlib.  If you want to customize this file, you
should move it to C:\Documents and Settings\yourname\.matplotlib.

Could you all test with a clean install of matplotlig (remove
site-packages/matplotlib, share/matplotlib and C:\Documents and 
Settings\yourname\.matplotlib before reinstalling) that this procedure
works properly?

Thanks,
JDH


    kristen> Secondly, when using TeX to create figure text, make sure
    kristen> that the directories where dvipng.exe, latex.exe, gs.exe
    kristen> etc are present in the system variable Path.  For most
    kristen> latex/miktex installation this will probably be:
    kristen> C:\texmf\miktex\bin and C:\gs\.

    kristen> I have still not made it work using the PS backend.
    kristen> Somewhere there is an eps and tex file that has not been
    kristen> put in the .matplotlib\tex.cache directory.

Could you update the UsingTex wiki at
http://www.scipy.org/wikis/topical_software/UsingTex with this
information, under a win32 section?

Thanks,
JDH

On Monday 01 August 2005 08:36 am, Gary Ruben wrote:
> The PS backend is broken on my Win2k system too. I can only save as png,
> which isn't all that useful. I reported this a few weeks ago and I hope
> to get a chance to look at it next week to see if I can work out what's
> going on.
> It's good to get confirmation that it's not just my Windows installation
> that's doing this.

Do you mean ps is broken with TeX support, or it is broken period?

I will defend in a couple of weeks, so unfortunately I don't have time to bug 
hunt for a while. I should be back on the ball soon.

Darren

Hi Kristen,

The PS backend is broken on my Win2k system too. I can only save as png, 
which isn't all that useful. I reported this a few weeks ago and I hope 
to get a chance to look at it next week to see if I can work out what's 
going on.
It's good to get confirmation that it's not just my Windows installation 
that's doing this.

Gary R.

kristen kaasbjerg wrote:
> Hi matplotliber's (windows users)
> 
> A few days ago I reported problems with the
> tex_demo.py script. Some solutions have been found
> meanwhile.
> 
> First of all, matplotlibrc is NOT put in the intended
> directory upon istallation. It resides in the old
> share\matplotlib\. This must be done manually!!
> 
> Secondly, when using TeX to create figure text, make
> sure that the directories where dvipng.exe, latex.exe,
> gs.exe etc are present in the system variable Path.
> For most latex/miktex installation this will probably
> be: C:\texmf\miktex\bin and C:\gs\.
> 
> I have still not made it work using the PS backend.
> Somewhere there is an eps and tex file that has not
> been put in the .matplotlib\tex.cache directory.
> 
> Also, much of the text doesn't come out correctly in
> the figures, so there are still problems when using
> TeX on Windows!!
> 
> Kristen

Hi matplotliber's (windows users)

A few days ago I reported problems with the
tex_demo.py script. Some solutions have been found
meanwhile.

First of all, matplotlibrc is NOT put in the intended
directory upon istallation. It resides in the old
share\matplotlib\. This must be done manually!!

Secondly, when using TeX to create figure text, make
sure that the directories where dvipng.exe, latex.exe,
gs.exe etc are present in the system variable Path.
For most latex/miktex installation this will probably
be: C:\texmf\miktex\bin and C:\gs\.

I have still not made it work using the PS backend.
Somewhere there is an eps and tex file that has not
been put in the .matplotlib\tex.cache directory.

Also, much of the text doesn't come out correctly in
the figures, so there are still problems when using
TeX on Windows!!

Kristen

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Sascha GL wrote:
> Attached is the output from the build process; it contains a few warnings.
> Maybe these are related to my issue?

Where is libfreetype on your machine?

-- 
Robert Kern
rk...@uc...

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter

Attached is the output from the build process; it contains a few warnings.
Maybe these are related to my issue?

-- 
GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

Ok, so I have upgraded gcc to 3.4.4 and built Numeric and Matplotlib with
it. Both install fine. However, when I try to import the pylab interface, I
get the following traceback:

>>> import pylab
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.3/site-packages/pylab.py", line 1, in ?
    from matplotlib.pylab import *
  File "/usr/local/lib/python2.3/site-packages/matplotlib/pylab.py", line
198, in ?
    from axes import Axes, PolarAxes
  File "/usr/local/lib/python2.3/site-packages/matplotlib/axes.py", line 14,
in ?
    from axis import XAxis, YAxis
  File "/usr/local/lib/python2.3/site-packages/matplotlib/axis.py", line 25,
in ?
    from font_manager import FontProperties
  File "/usr/local/lib/python2.3/site-packages/matplotlib/font_manager.py",
line 39, in ?
    from matplotlib import ft2font
ImportError: /usr/local/lib/python2.3/site-packages/matplotlib/ft2font.so:
undefined symbol: FT_Get_PS_Font_Info

To me it sounds like there is an issue with the Freetype library. Any idea
what I can do about that?

Appreciate your help.

Sascha

> --- Ursprüngliche Nachricht ---
> Von: "Sascha" <sas...@gm...>
> An: <mat...@li...>
> Betreff: Re: [Matplotlib-users] Installation issue
> Datum: Fri, 29 Jul 2005 17:13:36 +0200
> 
> > That's very good bet -- 2.95 is *really old*.  It looks like it may
> > not be properly handling wide characters.  I don't think there is
> > anything we can do on our end about this one.  Can you upgrade your
> > compiler?
> 
> Well, it's an old server box of my faculty at the university. I'll see
> what 
> I can do about it.
> 
> Thanks for your advice.
> 
> Sascha 

-- 
GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

I just installed version 0.83.2 on XP.
It was my first install since the matplotlibrc file moved to the new=20
location.
It didn't work so well.
First, it didn't create the .matplotlib directory in my Documents and=20
Settings\mbakker directory, but a tex.cache folder.
When I imported pylab the first time, I got the following nice warning that=
=20
fixed that:

WARNING: found a TeX cache dir in the deprecated location "C:\Documents and=
=20
Settings\mbakker\.tex.cache".
Moving it to the new default location "C:\Documents and=20
Settings\mbakker\.matplotlib\tex.cache".

But, the default matplotlibrc file was never put in the correct directory.
I got it all fixed, which was easy enought to do, but this may be=20
problematic for less experienced matplotlib users.

I can try tomorrow on a clean machine at work to see if it gives the same=
=20
problem there,

Mark