matplotlib-devel Mailing List for matplotlib

Due to repeated emails by Eric Firing about how something like this
would be nice to have, I finally got around to packaging a little
utility I wrote. I uploaded it to the MPL source repository. The basic
idea is to create a layout engine for matplotlib. Not wanting to
(re-)invent an API, I decided simply to imitate the layout engine I knew
best, which is wxPython.
Disclaimer: This isn't bug-free, complete, or well-documented and this
announcement should merely be taken as a call to "commence hacking now".
That being said, I've used mplsizer for several figures for publication,
so I don't consider it that bad or incomplete, either.
Anyhow, the source code, licensed under the MIT license, is available at:
https://svn.sourceforge.net/svnroot/matplotlib/trunk/toolkits/mplsizer
One note: aside from depending on matplotlib, this requires setuptools.
Sorry to those of you who hate setuptools, but it simply gives me tools
that make my life easier. If you want to change mplsizer to not require
setuptools, that's fine by me, but we should keep it setuptools compatible.
Here's the last part of the demo_basic.py script. "fig" is a matplotlib
Figure instance, "a","b","b2", and "lowest" are matplotlib Axes instances.
 # Now perform the mplsizer stuff
 import matplotlib.toolkits.mplsizer as mplsizer
 frame = mplsizer.MplSizerFrame( fig )
 sizer = mplsizer.MplBoxSizer()
 frame.SetSizer(sizer)
 sizer.Add(a,name='a',expand=1)
 sizer.Add(b,name='b',all=0,left=1,border=0.2)
 sizer.Add(b2,name='b2')
 if more_plots:
 hsizer = mplsizer.MplBoxSizer(orientation='horizontal')
 hsizer.Add(c,name='c',option=1,align_bottom=1)
 hsizer.Add(d,name='d',align_centre=1)
 sizer.Add(hsizer,all=0,bottom=1,border=0.5,expand=1,option=1)
 frame.Layout() # triggers layout
 # It's naughty to use the private attribute, but, hey, this is for
 # debugging only, so it's OK, right?
 lowest.set_position(hsizer._rect)
pylab.show()

Darren,
I don't like the default either--I just left it in place so as not to 
change too many things at once. There is always some tension in mpl 
between doing things the Matlab way, at least by default, and doing 
things better. If there is no opinion to the contrary, I am happy to 
change colorbar defaults for the better. I use the "shrink" kwarg 
routinely to make the colorbar smaller; I think it should be smaller by 
default. I generally prefer a colorbar with a length about 80% that of 
the corresponding image axis length.
What is really needed to optimize it, however, is a smarter axes packing 
algorithm. So far, I have considered it best to at least defer this 
potentially complex change in favor of sticking with simple automatic 
behavior and the present reasonably easy manual configurability. There 
may still be fairly simple ways to improve the default behavior, 
however, beyond picking better default parameters for the present 
algorithms.
The present algorithm divides the figure box in two, with "fraction" 
giving the fraction reserved for the colorbar. The image axes are then 
resized and repositioned within the remainder.
One of the reasons that doing a really good job of automatic colorbar 
sizing and positioning is not trivial is that aspect ratio handling in 
the draw method determines the actual size of the image; to make the 
colorbar match that, we would have to put the colorbar sizing in the 
draw method after the image dimensions have been determined. Probably 
this can all be done cleanly the same sort of Value magic that is used 
in transforms, but I have not tried to figure it out. I think it would 
require setting up some sort of axes drawing order, with care taken to 
avoid circular dependencies.
So, to summarize, I don't mind doing some simple things to make colorbar 
sizing usually look nicer by default, but a more complex and complete 
solution is not high priority for me now.
Eric
Darren Dale wrote:
> I would like to ask about the behavior of colorbar(). In my opinion, the 
> default colorbar is too big. I know the default is similar to matlab's 
> colorbar, but I dont think it should stretch beyond the axes. Also, there is 
> arguably too much space between the colorbar and the right edge of the 
> figure. I'm attaching two pngs, one is the default behavior and the other is 
> my suggested alternative, which I did with colorbar(fraction=0.0305). I don't 
> understand what fraction is scaled to. I expected fraction=1 to make the 
> height equal to the original axes height, but that actually crashes python:
> 
> terminate called after throwing an instance of 'std::bad_alloc'
> what(): St9bad_alloc
> Aborted
> 
> I don't want to seem too critical of the work that has already been put into 
> the colorbar. I just think it needs a bit of polish. Comments?
> 
> Darren
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Thursday 27 July 2006 8:33 am, JIM MacDonald wrote:
> Hi,
>
> I've just moved from MATLAB to matplotlib, and I'm really impressed
> with the quality of the PS figures it generates with usetex and the
> xpdf distiller. 
Glad to hear it.
> I've hit a couple of problems though
[...]
> The first problem I noticed is that the distilling process was causing
> some of my images to have (lossy) compression applied and others not.
> It turns out that it is a feature of ps2pdf that it tries to detect
> the content of the image and apply appropriate compression. You can
> over ride this distiller options. My patch adds a new rc option
> ps.image_compression that can be set to auto (preserves the current
> behaviour), DCTEncode (applies lossy JPEG compression), and
> FlateEncode (lossless compression). The distiller commands are
> embedded in the ps file. I looked at making it a flag on each image,
> but couldn't get it to work. Another way to do it is to pass extra
> command line options to ps2pdf (-dAutoFilterColorImages=false
> -sColorImageFilter=FlateEncode should do it for colour images). I
> thought embedding it in the PS file would be more flexible.
I'll look into this soon. I'm hesitant to add another rc option, maybe we can 
consider using these settings as the defaults. I'll post again after I have 
had a chance to play with it.
> My second problem involved the resolutions of the image. I'd like to
> preserve the resolution of my image in the PS output, but I can't
> figure out how to stop the image being resized and interpolated.
> Obviously you need to do this for the bitmap backends, but for vector
> ones surely you can just scale the original image in the vector
> output.
The resolution for Postscript is 72 dpi, and I'm not sure this can be changed. 
Would you send me an example postscript file along with the original png?