matplotlib-devel Mailing List for matplotlib

A long time ago there was discussion about creating a plug-in system for 
pylib, and some code was written. Part of the difficulty was that the 
config file had to be radically altered. There was some discussion on 
how to do this, but no code actually go written in the end (which I had 
promised I would do). Finally having some free time again, I thought I 
would give it another shot. It should be fairly easy to move the plugin 
structure written once an appropriate config mechanism is in place.
Thus, on the suggestion of John, I started to write *just* a config 
module to replace the current one. The idea is mirror the current code, 
so '.matplotlibrc' files can still be used, but at the same time to also 
allow configuration files that are python code. This will allow all 
future extensions to easily be written in python, and allow easy 
backwards compatibility.
Attached is a quick and dirty first attempt. With very few lines of code 
it should be easy to import an old rc file. Let me know what you think.. 
It currently only has the config item 'tick.x', but if it looks 
worthwhile I can transfer the rest of the config items in, and write a 
function for reading in .matplotlibrc files.
Abe

Fernando Perez wrote:
> John Hunter wrote:
>>But using non-equal width and height for the axes seems like a logical
>>error that defeats the stated purpose of matshow. Of course, in real
>>life this might be a hack to defeat unequal dpix and dpiy on your
>>monitor, but it would come back to bite you when you saved to PS,
>>which has the same dpi in both directions.
> 
> 
> Well, the problem is really the following: we need at least 0.15 on the left 
> to leave enough room for the row ticks. Those can grow reasonably wide, given 
> that a 1000 row array forces 4 character labels. OTOH, the labels at the top 
> are all a single character tall, so they don't occupy quite as much space. I 
> was trying to balance these constraints, by moving the image to the right just 
> enough, while trying to avoid a too wide band atop the figure. But your 
> aspect ratio comment is valid, so perhaps the height should be reduced to 
> 0.75. You are correct that matshow should, when at all possible, guarantee an 
> exact aspect ratio. This is especially important for generating array 
> displays in EPS for papers.
> 
> But it's important to leave at least 0.15 on the left, otherwise for tall 
> arrays the labels are lost against the wall.
To close this off, here's a set of numbers
 ax = fig.add_axes([0.15, 0.09, 0.775, 0.775])
which:
 - respect x/y scaling constraints
 - allow up to 4 character labels (arrays with >1000 rows) to display
 - center the image reasonably without unnatural space when possible.
These are the numbers I'm keeping for now in my tree.
And now I'll shut up on this one. It would still be possible to improve the 
layout for the extremely tall/wide cases, but that would require a bunch of 
special-casing code and fine testing. At this point, even I am willing to say 
'good enough'. And now I'll take my meds :)
Cheers,
f

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
> Fernando> OK, the perfectionist freak in me wants:
> 
> Fernando> ax = fig.add_axes([0.15, 0.075, 0.75, 0.8])
> 
> But using non-equal width and height for the axes seems like a logical
> error that defeats the stated purpose of matshow. Of course, in real
> life this might be a hack to defeat unequal dpix and dpiy on your
> monitor, but it would come back to bite you when you saved to PS,
> which has the same dpi in both directions.
Well, the problem is really the following: we need at least 0.15 on the left 
to leave enough room for the row ticks. Those can grow reasonably wide, given 
that a 1000 row array forces 4 character labels. OTOH, the labels at the top 
are all a single character tall, so they don't occupy quite as much space. I 
was trying to balance these constraints, by moving the image to the right just 
enough, while trying to avoid a too wide band atop the figure. But your 
aspect ratio comment is valid, so perhaps the height should be reduced to 
0.75. You are correct that matshow should, when at all possible, guarantee an 
exact aspect ratio. This is especially important for generating array 
displays in EPS for papers.
But it's important to leave at least 0.15 on the left, otherwise for tall 
arrays the labels are lost against the wall.
Side note: I just ran image_demo3, and the dreaded white band appears atop 
lena's head with imshow(). At some point I may look into applying these same 
tricks to imshow, so it does the right thing when aspect=='preserve'. But 
later, we have too much on our plate already (and I haven't even started with 
the real stuff I want for matplotlib :)
> Fernando> I tested this, and these values avoid problems with
> Fernando> labels running into walls or too much whitespace for
> Fernando> extreme aspect ratios. For more square ones, the change
> Fernando> is barely noticeable. You'd make me infinitely happy if
> Fernando> you indulged this little nit :)
> 
> Hmm, you solve my problem on ipython-users and I'll solve yours. :-)
I know, and I feel terrible that yours is a bit trickier than mine.
> Actually, I looked a bit at it yesterday and could replicate it. I
> haven't figured out where the root evil is. Is it known to be safe to
> run two separate tk processes in python? Eg, I'm not 100% convinced
> its a matplotlib bug, but may be 
No worries, at least we have a workaround. I just wanted to know it was on 
your radar, that's all. I won't pester you about it again.
Cheers,
f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> OK, the perfectionist freak in me wants:
 Fernando> ax = fig.add_axes([0.15, 0.075, 0.75, 0.8])
But using non-equal width and height for the axes seems like a logical
error that defeats the stated purpose of matshow. Of course, in real
life this might be a hack to defeat unequal dpix and dpiy on your
monitor, but it would come back to bite you when you saved to PS,
which has the same dpi in both directions.
 Fernando> I tested this, and these values avoid problems with
 Fernando> labels running into walls or too much whitespace for
 Fernando> extreme aspect ratios. For more square ones, the change
 Fernando> is barely noticeable. You'd make me infinitely happy if
 Fernando> you indulged this little nit :)
Hmm, you solve my problem on ipython-users and I'll solve yours. :-)
Actually, I looked a bit at it yesterday and could replicate it. I
haven't figured out where the root evil is. Is it known to be safe to
run two separate tk processes in python? Eg, I'm not 100% convinced
its a matplotlib bug, but may be 
JDH

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> 
> 
> Fernando> Anyway, many thanks for including this. Let me know
> Fernando> when you fix the current bugs and I'll test it again.
> 
> Thanks for the comments - I incorporated them into my local tree. The
> axes thing was just a typo. In matshow, it should read
> 
> 
> ax = fig.add_axes([0.1, 0.05, 0.8, 0.8])
> ^
OK, the perfectionist freak in me wants:
 ax = fig.add_axes([0.15, 0.075, 0.75, 0.8])
I tested this, and these values avoid problems with labels running into walls 
or too much whitespace for extreme aspect ratios. For more square ones, the 
change is barely noticeable. You'd make me infinitely happy if you indulged 
this little nit :)
Regards,
f
ps. Just as a post-it note, keep in mind that the Tk/vtk/close() bug remains 
open. This one is pretty nasty, as it prevents usage of mayavi in the same 
session where pylab is active, unless one uses my sentinel hack. The plain 
close(fighandle) one has been fixed, though, I just checked. Thanks.

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> Anyway, many thanks for including this. Let me know
 Fernando> when you fix the current bugs and I'll test it again.
Thanks for the comments - I incorporated them into my local tree. The
axes thing was just a typo. In matshow, it should read
 ax = fig.add_axes([0.1, 0.05, 0.8, 0.8])
 ^
JDH

John Hunter wrote:
> * you also need to be sure that the axes have the same width and
> height. Since the width and height are expressed in fractions of
> the figure size, you can use any width and height you want and get
> the right answer as long as they are the same, since the figure
> width and height have the right aspect ration. The default axes --
> subplot(111) -- have slightly different values for w and h. This
> is fixed in CVS with 
> 
> 
> w,h = figaspect(arr)
> fig = figure(figsize=(w,h))
> ax = fig.add_axes([0.0, 0.05, 0.8, 0.8])
Well, but this breaks things badly. Have a run at my supplied examples with 
your version, and you'll see the arrays get banged against the left side. 
(make sure to rename the matshow routine in my example to matshow2, so you are 
actually testing matplotlib and not my code)
I played with these numbers a bit but couldn't get something that looked OK 
for all the examples. The original looked perfect, so it's a matter of 
reusing the same defaults that I was ending up with via my imshow() call, I 
guess. But I did some grepping for add_axes and couldn't find it elsewhere, 
so I don't know how to fix it.
> * To get the labels on top, you do
> 
> ax.xaxis.tick_top() # this turns off tick bottom and turns on tick top
> 
> likewise, there are yaxis functions tick_left and tick_right. This
> is also in CVS
This is nice, thanks.
> * I return a (fig, ax, im) tuple 
OK.
Minor docstring nits:
 matshow() calls imshow() with Aargs and **kwargs, but by default
should be:
 matshow() calls imshow() with *args and **kwargs, but by default
And why do you use enumerate here?
 for i, d in enumerate(dimlist):
 fig, ax, im = matshow(samplemat(d))
 show()
This example would be clearer with just
 for d dimlist:
 fig, ax, im = matshow(samplemat(d))
 show()
since you don't really use the index for anything. Less noise to read through.
Anyway, many thanks for including this. Let me know when you fix the current 
bugs and I'll test it again.
Cheers,
f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> I just tested this code on a second box with different
 Fernando> mpl defaults and found a few minor issues. They are now
 Fernando> fixed in this new attached version.
Hi Fernando, this is a very useful submission that solves a recurrent
problem people have. So useful, that I factored out the hard part
(getting the figure size right) into a separate function figaspect
which lives in matplotlib.figure so it could be reused in other
contexts. The rest is easy, and lives in pylab.matshow, which calls
figaspect to do the heavy lifting.
A few comments 
 * you also need to be sure that the axes have the same width and
 height. Since the width and height are expressed in fractions of
 the figure size, you can use any width and height you want and get
 the right answer as long as they are the same, since the figure
 width and height have the right aspect ration. The default axes --
 subplot(111) -- have slightly different values for w and h. This
 is fixed in CVS with 
 w,h = figaspect(arr)
 fig = figure(figsize=(w,h))
 ax = fig.add_axes([0.0, 0.05, 0.8, 0.8])
 * To get the labels on top, you do
 ax.xaxis.tick_top() # this turns off tick bottom and turns on tick top
 likewise, there are yaxis functions tick_left and tick_right. This
 is also in CVS
 * I return a (fig, ax, im) tuple 
Give it a test drive and let me know what you think (pylab revision
1.34 or later in CVS)
JDH

Quoting Fernando Perez <Fer...@co...>:
> a better name. If you run the attached script via %run in a pylab session,
> it will display various arrays.
I just tested this code on a second box with different mpl defaults and found a
few minor issues. They are now fixed in this new attached version.
Regards,
f

Hi all,
one of the things which has been bugging me in my recent conversion to mpl has 
been the lack of a good matrix display routine, which would plot the arrays 
with 'upper' origin but row-descending numbers, and which would satisfy the 
colliding constraints of no stretching, a window with the aspect ratio of the 
original array, all within reasonable window sizes.
imshow, figimage and pcolor all fail to do this in different ways. So I'm 
attaching here a new routine, which roughly does what I want (with current CVS 
code, since it needs my new figure() patch). I called it matshow, for lack of 
a better name. If you run the attached script via %run in a pylab session, it 
will display various arrays.
I think the functionality is a good improvement over the existing 
image-related display routines (I need something like this from day 1 if I'm 
to use matplotlib), but I have some doubts about my implementation. I poked 
around inside matplotlib for a while, trying to finesse this functionality 
into imshow() itself, but I got hopelessly lost. Perhaps a better coder than 
me can make it work, if y'all think the functionality is worth having.
If people don't mind the implementation, I guess I'd like to see it included 
(perhaps with a better name, and after a good review by the experts). The 
docstring contains some notes about improvements I don't know how to make, and 
the code is heavily commented.
Regards,
f