John Hunter wrote:
"Fernando" == Fernando Perez <Fernando.Perez@...76...> writes:
> OK, the perfectionist freak in me wants:
> 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 
> 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
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