matplotlib-users Mailing List for matplotlib (Page 11)

On Wed, Aug 03, 2005 at 05:33:35PM -0500, John Hunter wrote:
> For something like zunzun, a web app server, I suggest not using pylab
> at all, but the matplotlib API, which avoids all the magical things
> that pylab does that can just be a pain in an app server.
> http://matplotlib.sf.net/faq.html#OO
> See for example
> http://matplotlib.sf.net/examples/agg_oo.py
> Let me know if this helps.
Matplotlib newbie that I am, *anything* will doubtless
be of help. Thank you for the references.
> zunzun is amazing!!
One day when I win the lottery and have money for
a serious server, it will really kick some major
mathematical tail. Until then it remains a hobby,
albeit with matplotlib a much prettier one.
 James Phillips
 http://zunzun.com

>>>>> "zunzun" == zunzun <zu...@zu...> writes:
 zunzun> This is James Phillips of http://zunzun.com, I'm in the
 zunzun> process of switching the site graphics from DISLIN to
 zunzun> matplotlib. I had some trouble pinning down why the Y
 zunzun> axis on my plots ws always in the wrong place, and thought
 zunzun> I'd pass along my findings to the mailing list.
 zunzun> If pylab is imported before vtk, everything works fine:
pylab starts the default backend GUI mainloop (if there is one) when
you call "show", and this may be conflicting with vtkpython. The
default matplotlib GUI for the src distribution is GTKAgg and
vtkpython may start tk??? This is a wild guess.
For something like zunzun, a web app server, I suggest not using pylab
at all, but the matplotlib API, which avoids all the magical things
that pylab does that can just be a pain in an app server.
 http://matplotlib.sf.net/faq.html#OO
See for example
 http://matplotlib.sf.net/examples/agg_oo.py
Let me know if this helps.
If you really want to use pylab, make sure you set Agg or some other
image backend as your default backend in your matplotlibrc file
(http://matplotlib.sf.net/matplotlibrc) or do the following before
importing pylab
 import matplotlib
 matplotlib.use('Agg')
 import pylab
Hope this helps. zunzun is amazing!!
JDH

John Hunter wrote:
>>>>>>"Steve" == Steve Schmerler <el...@gm...> writes:
> 
> 
> Steve> Hi I had some issues with marker plots and automatic color
> Steve> cycling.
> Steve> gives only black crosses. It would be nice if someone could
> Steve> please try this out. My guess is that the "o"s and "v"s do
> Steve> have some kind of black margin and a (colored) filling area
> Steve> which the "+"s and "x"s dont't have. If that's right then
> Steve> anyone should see this behavior. Thanx for your help.
> 
> As noted by Christian, the reason for this discrepancy is that '+' is
> not filled and 'o' is. filled marker colors are governed by their
> 'markeredgecolor' and 'markerfacecolor'. line styles are goverened by
> 'color'. Thus it is not entirely trivial to determine how these three
> colors should behave in automatic color cycling. For example, for
> filled markers, you might want the face color to automatically cycle
> and the edge colors to remain black (or more precisely, their default
> rc value). For non-filled markers, which do not have a facecolor, you
> might want the edge color to cycle.
> 
> Could you specify how you think this should behave? My guess is that
> this is sufficiently complicated that different people will want
> different default behaviors. As you posted earlier, it is pretty
> simple to force the kind of cycling you want in your own code. But if
> you can spell out a clear policy of how *it should* work, and there
> seems to be a consensus on this, or at least no objection, I can take
> a stab at implementing it in the axes code. You can take a look
> yourself if you want Axes._process_plot_var_args and
> Axes._process_plot_format.
> 
> JDH
> 
> 
> 
Hi
Well, since mpl changes the markeredgecolor when you request 'r+' and 
the markerfacecolor when you say 'ro' it would be the most natural way 
to keep this behavior when "turning on" automatic cycling by
	rcParams["lines.marker"] = <any_marker>
	rcParams["lines.linestyle"] = "None"
Some would even suggest to let the markeredgecolor == markerfacecolor 
(if there is one) by default for the sake of some "consistency" (i.e. 
remove the markeredgecolor completely, like in gnuplot). I personally 
don't care.
Btw, the issue here applies only to pure marker plots (i.e. nothing like 
'o-') right? What if you want automatic cycling there?
The ideal behavior would be: Say you want to plot 30 data sets with 
lines _and_ markers like '+-'. There would be a call like
setAutoMarkerAndColor()
for i in range(...):
	A = load(<dataset>) # or whatever
	plot(A[:,0], A[:,1]) # no formating at all
which would then behave like
def getFormatString(i):
 # works for len(c) = len(m) and all i >= 0
 c = ['b', 'g', 'r']
 # maybe without '.' and ',' because they are pretty small
 m = ['o', 'x', 'v']
 max = len(c)*len(m) - 1
 if (i > max):
 ii = i - max - 1
 else:
 ii = i
 mind = int(floor(ii / len(m)))
 cind = ii - mind * len(m)
 return c[cind] + m[mind]
		
for i in range(...):
	A = load(<dataset>)
	fs = getFormatString(i)
	plot(A[:,0], A[:,1], fs)
Actually, that's very much it, except that it only works if the numbers 
of colors and markers are the same.
cheers,
steve
-- 
Women are like cell phones. They like to be held and talked to, but push 
the wrong button, and you'll be disconnected.

This is James Phillips of http://zunzun.com, I'm in
the process of switching the site graphics from DISLIN
to matplotlib. I had some trouble pinning down why the
Y axis on my plots ws always in the wrong place, and
thought I'd pass along my findings to the mailing list.
If pylab is imported before vtk, everything works fine:
import pylab, vtkpython
pylab.ylabel('Frequency\n', multialignment='center', rotation=90)
n, bins, patches = pylab.hist([1,1,1,2,2,3,4,5,5,5,8,8,8,8], 5)
pylab.show()
If however vtk is imported first:
import vtkpython, pylab
pylab.ylabel('Frequency\n', multialignment='center', rotation=90)
n, bins, patches = pylab.hist([1,1,1,2,2,3,4,5,5,5,8,8,8,8], 5)
pylab.show()
then the Y axis label is positioned incorrectly on the
plots.
 James Phillips
 http://zunzun.com

On Wednesday 03 August 2005 11:57 am, kristen kaasbjerg wrote:
> The problem only occurs when you save the file in ps
> or eps format. If instead png is used the error
> doesn't appear, at least not at my machine!
I think I understand this. The problem is that the ghostscript command is 
different on linux and windows. On Linux it is "gs", and on windows its 
something like gs32win. Would you try editing your backend_ps.py file to read 
the following, (but make sure gs32win is really the name of the executable), 
note there are subtle changes throughout the block:
command = 'latex -interaction=nonstopmode "%s"' % texfile 
stdin, stdout, stderr = os.popen3(command)
verbose.report(stdout.read(), 'debug-annoying')
verbose.report(stderr.read(), 'helpful')
command = 'dvips -R -T %fin,%fin -o "%s" "%s"' % (pw, ph, psfile, dvifile)
stdin, stdout, stderr = os.popen3(command)
verbose.report(stdout.read(), 'debug-annoying')
verbose.report(stderr.read(), 'helpful')
os.remove(epsfile)
if ext.startswith('.ep'):
 dpi = rcParams['ps.distiller.res']
 command = 'gs32win -dBATCH -dNOPAUSE -dSAFER -r%d \
 -sDEVICE=epswrite -dLanguageLevel=2 -dEPSFitPage \
 -sOutputFile="%s" "%s"'% (dpi, epsfile, psfile) 
 stdin, stdout, stderr = os.popen3(command)
 verbose.report(stdout.read(), 'debug-annoying')
 verbose.report(stderr.read(), 'helpful')
 shutil.move(epsfile, outfile)
else: shutil.move(psfile, outfile)
At some point I'll come up with a way to automatically call the right command 
for ghostscript, but I am really busy at the moment...
-- 
Darren

The problem only occurs when you save the file in ps
or eps format. If instead png is used the error
doesn't appear, at least not at my machine!
Kristen
--- Darren Dale <dd...@co...> wrote:
> On Wednesday 03 August 2005 04:35 am, Alex Rada
> wrote:
> > Hi all,
> >
> > following
>
http://www.scipy.org/wikis/topical_software/UsingTex,
> and in
> > particular the following example:
> >
> > /from matplotlib import rc
> > from matplotlib.numerix import arange, cos, pi
> > from pylab import figure, axes, plot, xlabel,
> ylabel, title, \
> > grid, savefig, show
> >
> > rc('text', usetex=True)
> > figure(1)
> > ax = axes([0.15, 0.1, 0.8, 0.7])
> > t = arange(0.0, 1.0+0.01, 0.01)
> > s = cos(2*2*pi*t)+2
> > plot(t, s)
> >
> > xlabel(r'\bf{time (s)}')
> > ylabel(r'\it{voltage (mV)}',fontsize=16)
> > title(r"\TeX\ is Number
> >
>
$\displaystyle\sum_{n=1}^\infty\frac{-e^{i\pi}}{2^n}$!",
> > fontsize=16, color='r')
> > savefig('tex_demo.eps')
> >
> > show()
> > /
> > I obtain the following error:
> >
> > [....]
> > File
>
"/usr/lib/python2.3/site-packages/matplotlib/texmanager.py",
> line
> > 296, in get_rgba
> > X = readpng(pngfile)
> > RuntimeError: _image_module::readpng could not
> open PNG file
> >
>
/home/alex/.matplotlib/tex.cache/3d522deaf85577451c01974654b36ad3_270.png
> > for reading
> >
> > What does it means!?? I'm using matplotlib 0.83 on
> a linux box with
> > tetex-3.0 and ghostscript-8.51 installed...
> 
> Did you read the "common hangups" section at the end
> of the wiki? You have to 
> make sure that latex, and dvipng can be found on
> your PATH.
> 
> -- 
> 
> Darren
> 
> 
>
-------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux
> Migration Strategies
> from IBM. Find simple to follow Roadmaps,
> straightforward articles,
> informative Webcasts and more! Get everything you
> need to get up to
> speed, fast.
>
http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
>
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

Could you post the exact sequence of commands that you're using and what 
you have interactive mode set to?
I tried this w/ regular python and a version of python that we deliver to 
our customers that supports interactive mode w/ qt and it seems to work 
fine for me.
----------
[non-interactive mode]
import pylab as p
p.figure( 1 )
p.plot( [ 1, 2 ] )
p.show()
[ kill the window ]
p.figure( 1 )
p.plot( [ 3, 4 ] )
p.show()
[ new window pops up fine ]
----------
[interactive mode]
import pylab as p
p.figure( 1 )
[ window pops up ]
p.plot( [ 1, 2 ] )
[ kill the window ]
p.figure( 1 )
[ window pops up ]
At 12:24 AM 8/3/2005, Eugen Wintersberger wrote:
>Hi there.
>I have a problem with the QtAgg backend. It is not that serious but a
>bit nasty. After opening a figure with
>
> > figure(1)
>
>I have no problems to plot there. But after closing the window it is
>no longer possible to open a figure with ID 1 again. Ipython gives no
>error message, everything looks ok. But if one tries to plot something
>in this window nothing appears on the screen.
>I use Ipython 0.6.15 with matplotlib 0.8 on a Debian 3.1 system.
>Does anyone of you have an idea what I'm doing wrong or is this a known
>bug/error.
>
>cu
> Eugen
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Ted Drain Jet Propulsion Laboratory ted...@jp... 

On Wednesday 03 August 2005 04:35 am, Alex Rada wrote:
> Hi all,
>
> following http://www.scipy.org/wikis/topical_software/UsingTex, and in
> particular the following example:
>
> /from matplotlib import rc
> from matplotlib.numerix import arange, cos, pi
> from pylab import figure, axes, plot, xlabel, ylabel, title, \
> grid, savefig, show
>
> rc('text', usetex=True)
> figure(1)
> ax = axes([0.15, 0.1, 0.8, 0.7])
> t = arange(0.0, 1.0+0.01, 0.01)
> s = cos(2*2*pi*t)+2
> plot(t, s)
>
> xlabel(r'\bf{time (s)}')
> ylabel(r'\it{voltage (mV)}',fontsize=16)
> title(r"\TeX\ is Number
> $\displaystyle\sum_{n=1}^\infty\frac{-e^{i\pi}}{2^n}$!",
> fontsize=16, color='r')
> savefig('tex_demo.eps')
>
> show()
> /
> I obtain the following error:
>
> [....]
> File "/usr/lib/python2.3/site-packages/matplotlib/texmanager.py", line
> 296, in get_rgba
> X = readpng(pngfile)
> RuntimeError: _image_module::readpng could not open PNG file
> /home/alex/.matplotlib/tex.cache/3d522deaf85577451c01974654b36ad3_270.png
> for reading
>
> What does it means!?? I'm using matplotlib 0.83 on a linux box with
> tetex-3.0 and ghostscript-8.51 installed...
Did you read the "common hangups" section at the end of the wiki? You have to 
make sure that latex, and dvipng can be found on your PATH.
-- 
Darren

>>>>> "Steve" == Steve Schmerler <el...@gm...> writes:
 Steve> Hi I had some issues with marker plots and automatic color
 Steve> cycling.
 Steve> gives only black crosses. It would be nice if someone could
 Steve> please try this out. My guess is that the "o"s and "v"s do
 Steve> have some kind of black margin and a (colored) filling area
 Steve> which the "+"s and "x"s dont't have. If that's right then
 Steve> anyone should see this behavior. Thanx for your help.
As noted by Christian, the reason for this discrepancy is that '+' is
not filled and 'o' is. filled marker colors are governed by their
'markeredgecolor' and 'markerfacecolor'. line styles are goverened by
'color'. Thus it is not entirely trivial to determine how these three
colors should behave in automatic color cycling. For example, for
filled markers, you might want the face color to automatically cycle
and the edge colors to remain black (or more precisely, their default
rc value). For non-filled markers, which do not have a facecolor, you
might want the edge color to cycle.
Could you specify how you think this should behave? My guess is that
this is sufficiently complicated that different people will want
different default behaviors. As you posted earlier, it is pretty
simple to force the kind of cycling you want in your own code. But if
you can spell out a clear policy of how *it should* work, and there
seems to be a consensus on this, or at least no objection, I can take
a stab at implementing it in the axes code. You can take a look
yourself if you want Axes._process_plot_var_args and
Axes._process_plot_format.
JDH

>>>>> "Alex" == Alex Rada <ale...@ya...> writes:
 Alex> What does it means!?? I'm using matplotlib 0.83 on a linux
 Alex> box with tetex-3.0 and ghostscript-8.51 installed...
What version of dvipng do you have installed? I recommend 1.6 or
later. We need to make the texmanager smarter about raising errors
when it doesn't find the software it needs.
JDH

Hi all,
following http://www.scipy.org/wikis/topical_software/UsingTex, and in 
particular the following example:
/from matplotlib import rc
from matplotlib.numerix import arange, cos, pi
from pylab import figure, axes, plot, xlabel, ylabel, title, \
 grid, savefig, show
rc('text', usetex=True)
figure(1)
ax = axes([0.15, 0.1, 0.8, 0.7])
t = arange(0.0, 1.0+0.01, 0.01)
s = cos(2*2*pi*t)+2
plot(t, s)
xlabel(r'\bf{time (s)}')
ylabel(r'\it{voltage (mV)}',fontsize=16)
title(r"\TeX\ is Number 
$\displaystyle\sum_{n=1}^\infty\frac{-e^{i\pi}}{2^n}$!",
 fontsize=16, color='r')
savefig('tex_demo.eps')
show()
/
I obtain the following error:
[....]
File "/usr/lib/python2.3/site-packages/matplotlib/texmanager.py", line 
296, in get_rgba
 X = readpng(pngfile)
RuntimeError: _image_module::readpng could not open PNG file 
/home/alex/.matplotlib/tex.cache/3d522deaf85577451c01974654b36ad3_270.png 
for reading
What does it means!?? I'm using matplotlib 0.83 on a linux box with 
tetex-3.0 and ghostscript-8.51 installed...
Thanks for the Help,
Alex.

Steve Schmerler wrote:
> this out. My guess is that the "o"s and "v"s do have some kind of black 
> margin and a (colored) filling area which the "+"s and "x"s dont't have. 
> If that's right then anyone should see this behavior. Thanx for your help.
You're right. The marker's margin color is set by
rcParams['lines.markeredgecolor']= 'green'
and you even can have markers without edge by setting
rcParams['lines.markeredgewidth']= 0.0
but that doesn't work for '+' markers as they appear to consist only of the 
edge. As a result, they won't show up.
Christian

Hi there. 
I have a problem with the QtAgg backend. It is not that serious but a
bit nasty. After opening a figure with
> figure(1)
I have no problems to plot there. But after closing the window it is 
no longer possible to open a figure with ID 1 again. Ipython gives no
error message, everything looks ok. But if one tries to plot something
in this window nothing appears on the screen. 
I use Ipython 0.6.15 with matplotlib 0.8 on a Debian 3.1 system. 
Does anyone of you have an idea what I'm doing wrong or is this a known 
bug/error. 
cu 
 Eugen

Hi
I had some issues with marker plots and automatic color cycling.
John suggested
 	rcParams["lines.marker"] = "o"
 	rcParams["lines.linestyle"] = "None"
 	for i in range(4):
		plot(rand(5), rand(5))
which produces nice colorful dots :) "v" also works.
But changing the marker to '+' (or 'x')
	rcParams["lines.marker"] = "+"
gives only black crosses. It would be nice if someone could please try 
this out. My guess is that the "o"s and "v"s do have some kind of black 
margin and a (colored) filling area which the "+"s and "x"s dont't have. 
If that's right then anyone should see this behavior. Thanx for your help.
cheers,
steve

On Aug 2, 2005, at 5:30 PM, Danny Shevitz wrote:
> But... your last idea is superb. Why not a different way of doing it? 
> How about instead of a lookup table, I just
> write a colormap that has three user defined functions. Then I could 
> do the thresholding exactly. It seems like
> it would be pretty easy to do. I had originally thought colormaps were 
> needed because graphics drivers had finite resolutions
> so you couldn't put up too many colors. So, if I were to create a 
> "functionColormap" instead of a "linearSegmentedColormap"
> with millions of points in the image is there a danger I would run out 
> of colors or is there some internal rounding or truncation
> to prevent this? If there is no problem, then a new colormap subclass 
> is definately the way to go. I assume it would be slower, but
> I'm not sure it matters.
>
> D
>
Yes, I'm thinking some sort of functional, rather than table lookup, 
version would be useful. The table lookup is fast, but has its 
limitations for this kind of problem. I'll think a bit about it too. 
This kind of request comes up regularly (in one form or another) that 
it deserves some sort of solution.
Perry

>You are right. The problem is that a lookup table is quantized, and the 
>thresholds/intensities are floats.
>In my particular case, what I'm looking at is an image representing 
>arrival times. The problem is that
>the rounded down quantization gives me a peek into the future, which I 
>don't want. The way I am suggesting
>with the ceiling suffers from exactly the same problem, as you mention. If 
>you were looking at lower thresholds
>instead of upper thresholds then the ceiling would fail. That is why I was 
>suggesting a switch for both behaviors.
>Since this is so obscure hardly anyone would use it or even need to know 
>about it.
>
>But... your last idea is superb. Why not a different way of doing it? How 
>about instead of a lookup table, I just
>write a colormap that has three user defined functions. Then I could do 
>the thresholding exactly. It seems like
>it would be pretty easy to do. I had originally thought colormaps were 
>needed because graphics drivers had finite resolutions
>so you couldn't put up too many colors. So, if I were to create a 
>"functionColormap" instead of a "linearSegmentedColormap"
>with millions of points in the image is there a danger I would run out of 
>colors or is there some internal rounding or truncation
>to prevent this? If there is no problem, then a new colormap subclass is 
>definately the way to go. I assume it would be slower, but
>I'm not sure it matters.
>
>D
>>>Danny
>>Isn't the essence of the problem the fact that the thresholds are 
>>specified as floats and the lookup table is quantized by its nature? (And 
>>that the current design allows for arbitrary N.) Whatever value you 
>>specify for a threshold (unless it it 0 or 1) won't necessarily 
>>correspond to a clean boundary between the quantized values (however you 
>>choose to define the boundary: floor, midpoint, or ceiling). Isn't it 
>>possible that your ceiling version has the same problem the other way 
>>(some values that are actually less now show up above the threshold)?
>>
>>I'm wondering if some other approach isn't needed. But before going into 
>>more thought about that I'd like to clarify your usage.
>>
>>Perry Greenfield

On Aug 1, 2005, at 1:07 PM, Danny Shevitz wrote:
> 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
>
Isn't the essence of the problem the fact that the thresholds are 
specified as floats and the lookup table is quantized by its nature? 
(And that the current design allows for arbitrary N.) Whatever value 
you specify for a threshold (unless it it 0 or 1) won't necessarily 
correspond to a clean boundary between the quantized values (however 
you choose to define the boundary: floor, midpoint, or ceiling). Isn't 
it possible that your ceiling version has the same problem the other 
way (some values that are actually less now show up above the 
threshold)?
I'm wondering if some other approach isn't needed. But before going 
into more thought about that I'd like to clarify your usage.
Perry Greenfield

>>>>> "John" == John Mariska <ma...@nr...> writes:
Hi John, I'm CC-ing this response to the matplotlib users list
 John> Dear John, I'm a long-time IDL user who is growing
 John> increasingly attached to matplotlib. One thing is quite a
On the subject of IDL, if you haven't seen it already, you may be
interested in the IDL cheatsheet for ipython/numerix/matplotlib users
in the appendix of this tutorial
http://www.scipy.org/wikis/topical_software/Tutorial
 John> bother, however, when it comes to preparing publication
 John> quality plots. When the font size is increased to the size
 John> needed for the shrinkage that a publication quality plot
 John> typically undergoes, the bottom y-axis tick numbering often
 John> either hits or is too close to the first x-axis tick label.
 John> IDL takes care of this by having the bottom y-axis tick
 John> label baseline aligned to the bottom of the plot box, and
 John> the top y-axis tick label aligned so that the top of the
 John> numbers barely rise above the top of the plot box. The
 John> remaining tick labels are aligned on the tick location. Is
 John> something like this possible in matplotlib?
This FAQ has some relevant info:
http://matplotlib.sourceforge.net/faq.html#TEXTOVERLAP, which I'll
supplement here.
You can manually set the vertical position of the xicklabels and the
horizontal position of the yticklabels with relative ease. These
positions are in "axes coordinates" where 0,0 is the bottom left of
the Axes rectangle and 1,1 is the top right. So you need negative
numbers to position the xticklabels below the axes and yticklabels to
the left. In pylab, you can set the text properties of the
xticklabels by passing keyword arguments to the "xticks" function 
 xticks(fontsize=20, y=-0.05)
Ditto for the yticks
 yticks(fontsize=20, x=-0.05)
If you are using the matplotlib API, you can first get a list of the
tick labels and then apply setp to them
 from matplotlib.artist import setp
 setp( ax.get_xticklabels(), fontsize=20, y=-0.05)
JDH

On Tuesday 02 August 2005 04:44 am, Alex Rada wrote:
> Hi,
>
> I'm trying to use tex characters on axes label. In particular I want to
> use $\widetilde{xxx}$ command, but I obtain the following error:
>
> matplotlib.pyparsing.ParseException: Found unexpected token, "{" (at
> char 10), (line:1, col:11)
>
> What can I do to avoid this error?
You are using the mathtext module, not TeX, which has partial support for TeX 
characters. See http://matplotlib.sourceforge.net/matplotlib.mathtext.html 
for details.
If you have LaTeX installed, you can set text.usetex = True in your rc 
settings and then LaTeX will be used instead of the mathtext module. See 
http://www.scipy.org/wikis/topical_software/UsingTex for details. 
Unfortunately, there are problems on the windows platform that need to be 
worked out.
-- 
Darren

Hi,
I'm trying to use tex characters on axes label. In particular I want to 
use $\widetilde{xxx}$ command, but I obtain the following error:
matplotlib.pyparsing.ParseException: Found unexpected token, "{" (at 
char 10), (line:1, col:11)
What can I do to avoid this error?
Thanks,
Alex.

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