matplotlib-users Mailing List for matplotlib

Are there any plans for incorporating this (what used to be mplot3d) 
into the new matplotlib version?
Lisa Tauxe
Scripps Institution of Oceanography
La Jolla, CA 92093-0220
tel: (858) 534-6084
fax: (858) 534-0784
http://magician.ucsd.edu/~ltauxe/
lt...@uc...
NOTE: Fedex or other courier deliveries address:
300C Ritter Hall
8635 Discovery Way
La Jolla, CA 92037

Hi Jae-Joon,
JL> I just had a quick look at this problem. And I'm posting a quick
JL> solution in case Christoper haven't dig it yet.
My figure looks great with these changes. Thank you very much!
-- 
Christopher Brown, Ph.D.
Department of Speech and Hearing Science
Arizona State University

Hello,
I just had a quick look at this problem. And I'm posting a quick
solution in case Christoper haven't dig it yet.
Index: lib/matplotlib/legend.py
===================================================================
--- lib/matplotlib/legend.py (revision 6138)
+++ lib/matplotlib/legend.py (working copy)
@@ -532,7 +532,11 @@
 # Set the data for the legend patch
 bbox = self._get_handle_text_bbox(renderer)
- bbox = bbox.expanded(1 + self.pad, 1 + self.pad)
+ #bbox = bbox.expanded(1 + self.pad, 1 + self.pad)
+ bbox = bbox.transformed(self.get_transform())
+ bbox = bbox.padded(self.pad*self.fontsize)
+ bbox = bbox.inverse_transformed(self.get_transform())
+
 l, b, w, h = bbox.bounds
 self.legendPatch.set_bounds(l, b, w, h)
The problem is already well explained by Eric. And my solution is to
interpret the legend.pad as a fraction of the textsize (pad=0.3 seems
to work fine in my eyes). Note that this breaks the backward
compatibility. I personally think the original behavior may have
produced unsatisfactory results in most of the cases and keeping it as
a default may not be a good idea. While I hope others come out with an
elegant solution, I prefer to break the API in this case.
Regards,
-JJ
On Tue, Sep 30, 2008 at 3:38 PM, Eric Firing <ef...@ha...> wrote:
> Christopher Brown wrote:
>> Sorry, meant to send to the list...
>>
>> Hi Eric,
>>
>> EF> > the vertical padding is too large in the first
>> EF> > legend, and too small in the second.
>> EF>
>> EF> This looks to me like a design flaw: the pad is "fractional"
>> EF> (fraction of legend box size), when logically it should be in
>> EF> something like units of legend text height, or possibly in points.
>> EF> This might be easy enough to change, although for backwards
>> EF> compatibility we would need to use a new kwarg.
>>
>> Could you point me to the function where this change needs to occur? I'd
>> like to hack at it, because I have deadline for a figure. I'm searching
>> around in legend.py, is that where I should be looking?
>
> Yes, that is the place. In principle it should be easy to fix, and
> maybe it is...or maybe it isn't. It will certainly have to do with
> transforms, and using the right one the right way in the right place.
>
>>
>> Also, why would a new kwarg be necessary? If the change simply means
>> that the vertical padding is computed correctly, how would that break
>> backward compatibility?
>>
>
> Because the workaround is to fiddle with the pad value for each
> individual case to make the plot look right, so scripts with that
> workaround would fail if suddenly the pad kwarg were to be interpreted
> in sane units.
>
> The new kwarg could be "pad_units", as a modifier for the pad kwarg. Or
> something like a "padpoints" kwarg could be introduced as an overlapping
> replacement. Or we could just break the API and hope it doesn't cause
> too much trouble. I am not sure what the right approach is in this
> case. I'm also not sure whether this is the only place where a "pad"
> value is still in poorly-chosen units. There was another such case that
> we fixed quite a long time ago.
>
> Eric
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

I sent the below - with referenced attachments - about 24 hours ago and have yet to see it posted - was it blocked due to the attachments?
DG
--- On Mon, 9/29/08, David Goldsmith <d_l...@ya...> wrote:
> From: David Goldsmith <d_l...@ya...>
> Subject: canvas.print_figure printing a variable amount of my figure
> To: mat...@li...
> Date: Monday, September 29, 2008, 5:59 PM
> I feel like I must be missing something: below is some
> "minimal sample" code which reproduces a
> "problem" I'm seeing in a more complicated
> situation:
> 
> import matplotlib as MPL
> from matplotlib.backends.backend_agg import FigureCanvasAgg
> as FigureCanvas
> from matplotlib.figure import Figure
> 
> for DPI in range(100,201,25):
> fig = Figure(figsize=(12,9), 
> dpi=DPI, 
> frameon=False)
> canvas = FigureCanvas(fig)
> 
> nx, ny = (N.uint16(12*DPI), N.uint16(9*DPI))
> temp = N.indices((ny, nx), N.uint8)
> result = N.zeros_like(temp[0])
> result[:ny/2,:] = temp[0,:ny/2,:] + temp[1,:ny/2,:]
> result[ny/2:,:] = temp[0,ny/2:,:] - temp[1,ny/2:,:]
> fig.figimage(result/N.float(N.max(result)))
> 
> canvas.print_figure("test"+str(DPI)+"dpi.png")
> 
> Attached are the results on my computer (see usage details
> below). Granted, I'm increasing the resolution each
> iteration, but I'm always placing the "cut" in
> the figure half way through - why does the cut keep creeping
> up 'til it disappears?
> 
> Usage details: matplotlib version=? (I forget how to get
> that), numpy version = 1.0.4, Python version = 2.5.2, OS =
> Windows XPProSP3, 504 MB RAM w/ "Physical Address
> Extension" (whatever that means).
> 
> DG
> 
> PS: If the figures don't come through and for some
> reason my code doesn't work on your platform or
> doesn't reproduce the problem, email me and I'll
> email you the figures directly.
 

Christopher Brown wrote:
> Sorry, meant to send to the list...
> 
> Hi Eric,
> 
> EF> > the vertical padding is too large in the first
> EF> > legend, and too small in the second.
> EF>
> EF> This looks to me like a design flaw: the pad is "fractional"
> EF> (fraction of legend box size), when logically it should be in
> EF> something like units of legend text height, or possibly in points.
> EF> This might be easy enough to change, although for backwards
> EF> compatibility we would need to use a new kwarg.
> 
> Could you point me to the function where this change needs to occur? I'd
> like to hack at it, because I have deadline for a figure. I'm searching
> around in legend.py, is that where I should be looking?
Yes, that is the place. In principle it should be easy to fix, and 
maybe it is...or maybe it isn't. It will certainly have to do with 
transforms, and using the right one the right way in the right place.
> 
> Also, why would a new kwarg be necessary? If the change simply means
> that the vertical padding is computed correctly, how would that break
> backward compatibility?
> 
Because the workaround is to fiddle with the pad value for each 
individual case to make the plot look right, so scripts with that 
workaround would fail if suddenly the pad kwarg were to be interpreted 
in sane units.
The new kwarg could be "pad_units", as a modifier for the pad kwarg. Or 
something like a "padpoints" kwarg could be introduced as an overlapping 
replacement. Or we could just break the API and hope it doesn't cause 
too much trouble. I am not sure what the right approach is in this 
case. I'm also not sure whether this is the only place where a "pad" 
value is still in poorly-chosen units. There was another such case that 
we fixed quite a long time ago.
Eric

Thomas Guettler wrote:
> Hi,
> 
> this snippet works if there are more (or less) elements in the menMeans 
> tuple. If
> there are three, it does not work since the bar command thinks the three
> element tuple is a tuple of rgb values. But it is a (r, g, b) tuple.
> 
> I think it is a bug. Should I create a ticket?
Yes it is a bug. I don't think a ticket will be needed. A quick look 
indicates that it will be easy to fix, so I will try to remember to do 
it later today. If I haven't done it within 24 hours, send me a reminder.
> 
> I use 0.98.3
> 
> I helped myself by using rgb2hex. But somehow this is not a good solution.
> Maybe colorConverter.to_rgb should return a subclass of tuple called 
> 'ColorTuple'.
> This way it would be easier to distinguish between a tuple of rgb values 
> and a rgb color tuple.
I don't think this will be necessary, and it would not really solve the 
problem in general. I think we already have a solution, but it is not 
being used in the bar() method.
> 
> {{{
> #!/usr/bin/env python
> import numpy as np
> import matplotlib.pyplot as plt
> import matplotlib
> 
> cmap=matplotlib.cm.jet
> menMeans = (20, 35, 30) # Does work if there are more or less then three 
> elements in the tuple
> N=len(menMeans)
> ind = np.arange(N) # the x locations for the groups
> width = 0.35 # the width of the bars
> plt.subplot(111)
> color=matplotlib.colors.colorConverter.to_rgb(cmap(0.5))
The call to to_rgb here seems completely unnecessary; cmap returns rgba, 
and the color kwarg should accept that. All the to_rgb() is doing is 
chopping off the alpha value.
Eric
> rects1 = plt.bar(ind, menMeans, width, color=color)
> plt.show()
> }}}
> 
> {{{
> Traceback (most recent call last):
> File 
> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
> line 333, in expose_event
> self._render_figure(self._pixmap, w, h)
> File 
> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
> line 75, in _render_figure
> FigureCanvasAgg.draw(self)
> File 
> "/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
> line 261, in draw
> self.figure.draw(self.renderer)
> File "/usr/lib64/python2.5/site-packages/matplotlib/figure.py", line 
> 759, in draw
> for a in self.axes: a.draw(renderer)
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 
> 1523, in draw
> a.draw(renderer)
> File "/usr/lib64/python2.5/site-packages/matplotlib/patches.py", line 
> 275, in draw
> rgbFace = colors.colorConverter.to_rgb(self._facecolor)
> File "/usr/lib64/python2.5/site-packages/matplotlib/colors.py", line 
> 280, in to_rgb
> raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' % (str(arg), exc))
> ValueError: to_rgb: Invalid rgb arg "0,490196078431"
> }}}
> 

Folks,
I sent this msg last Friday but it never appeared in the digest...
I am trying to install, in a private 'space', 0.98.3 on a linux 
x86-64 scientific cluster on which I am not the admin. tcl/tk is 
indeed installed, and I know where they are. matplotlib cannot find 
them. When running 'python setup.py build', tclConfig.sh and 
tkConfig.sh are on the path.
It seems tcl/tk detection is a persistent issue, from searching the 
web. My head hurts right now on this, so I hope there's some kind of 
an answer.
Some output:
> python setup.py build
============================================================================
BUILDING MATPLOTLIB
 matplotlib: 0.98.3
 python: 2.5.2 (r252:60911, Sep 25 2008, 16:58:03) [GCC
 4.1.2 20071124 (Red Hat 4.1.2-38)]
 platform: linux2
REQUIRED DEPENDENCIES
 numpy: 1.1.1
 freetype2: 9.10.3
OPTIONAL BACKEND DEPENDENCIES
 libpng: 1.2.10
 Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
 * Guessing the library and include directories for
 * Tcl and Tk because the tclConfig.sh and
 * tkConfig.sh could not be found and/or parsed.
 Gtk+: no
 * Building for Gtk+ requires pygtk; you must be able
 * to "import gtk" in your build/install environment
 Qt: no
 Qt4: no
 Cairo: no

On Tue, Sep 30, 2008 at 6:00 AM, Antonio Gonzalez <ja...@ca...> wrote:
> Hello,
>
> Running the latest mpl (svn 6134), 'fill_between.py' from the examples
> directory fails:
>
> File "fill_between.py", line 2, in <module>
> import matplotlib.numerical_methods as numerical_methods
> ImportError: No module named numerical_methods
Thanks Antonio,
This is now fixed in svn 6134.
JDH

Hello,
Running the latest mpl (svn 6134), 'fill_between.py' from the examples 
directory fails:
File "fill_between.py", line 2, in <module>
 import matplotlib.numerical_methods as numerical_methods
ImportError: No module named numerical_methods
Regards,
Antonio

Hi,
this snippet works if there are more (or less) elements in the menMeans 
tuple. If
there are three, it does not work since the bar command thinks the three
element tuple is a tuple of rgb values. But it is a (r, g, b) tuple.
I think it is a bug. Should I create a ticket?
I use 0.98.3
I helped myself by using rgb2hex. But somehow this is not a good solution.
Maybe colorConverter.to_rgb should return a subclass of tuple called 
'ColorTuple'.
This way it would be easier to distinguish between a tuple of rgb values 
and a rgb color tuple.
{{{
#!/usr/bin/env python
import numpy as np
import matplotlib.pyplot as plt
import matplotlib
cmap=matplotlib.cm.jet
menMeans = (20, 35, 30) # Does work if there are more or less then three 
elements in the tuple
N=len(menMeans)
ind = np.arange(N) # the x locations for the groups
width = 0.35 # the width of the bars
plt.subplot(111)
color=matplotlib.colors.colorConverter.to_rgb(cmap(0.5))
rects1 = plt.bar(ind, menMeans, width, color=color)
plt.show()
}}}
{{{
Traceback (most recent call last):
 File 
"/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_gtk.py", 
line 333, in expose_event
 self._render_figure(self._pixmap, w, h)
 File 
"/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_gtkagg.py", 
line 75, in _render_figure
 FigureCanvasAgg.draw(self)
 File 
"/usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py", 
line 261, in draw
 self.figure.draw(self.renderer)
 File "/usr/lib64/python2.5/site-packages/matplotlib/figure.py", line 
759, in draw
 for a in self.axes: a.draw(renderer)
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 
1523, in draw
 a.draw(renderer)
 File "/usr/lib64/python2.5/site-packages/matplotlib/patches.py", line 
275, in draw
 rgbFace = colors.colorConverter.to_rgb(self._facecolor)
 File "/usr/lib64/python2.5/site-packages/matplotlib/colors.py", line 
280, in to_rgb
 raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' % (str(arg), exc))
ValueError: to_rgb: Invalid rgb arg "0,490196078431"
}}}
-- 
Thomas Guettler, http://www.thomas-guettler.de/
E-Mail: guettli (*) thomas-guettler + de

Friedrich Hagedorn wrote:
> Yes as *.png. I think it's convinient to understand your problem in a
> few seconds.
> 
The bottom two subplots of the attached.
Peter

I feel like I must be missing something: below is some "minimal sample" code which reproduces a "problem" I'm seeing in a more complicated situation:
import matplotlib as MPL
from matplotlib.backends.backend_agg import FigureCanvasAgg as FigureCanvas
from matplotlib.figure import Figure
for DPI in range(100,201,25):
 fig = Figure(figsize=(12,9), 
 dpi=DPI, 
 frameon=False)
 canvas = FigureCanvas(fig)
 nx, ny = (N.uint16(12*DPI), N.uint16(9*DPI))
 temp = N.indices((ny, nx), N.uint8)
 result = N.zeros_like(temp[0])
 result[:ny/2,:] = temp[0,:ny/2,:] + temp[1,:ny/2,:]
 result[ny/2:,:] = temp[0,ny/2:,:] - temp[1,ny/2:,:]
 fig.figimage(result/N.float(N.max(result)))
 canvas.print_figure("test"+str(DPI)+"dpi.png")
Attached are the results on my computer (see usage details below). Granted, I'm increasing the resolution each iteration, but I'm always placing the "cut" in the figure half way through - why does the cut keep creeping up 'til it disappears?
Usage details: matplotlib version=? (I forget how to get that), numpy version = 1.0.4, Python version = 2.5.2, OS = Windows XPProSP3, 504 MB RAM w/ "Physical Address Extension" (whatever that means).
DG
PS: If the figures don't come through and for some reason my code doesn't work on your platform or doesn't reproduce the problem, email me and I'll email you the figures directly.