[Matplotlib-users] axes3D
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/ [EMAIL PROTECTED] NOTE: Fedex or other courier deliveries address: 300C Ritter Hall 8635 Discovery Way La Jolla, CA 92037 - 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] vertical padding in legend
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 <[EMAIL PROTECTED]> 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 > Matplotlib-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > - 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] Fw: canvas.print_figure printing a variable amount of my figure
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 <[EMAIL PROTECTED]> wrote:
> From: David Goldsmith <[EMAIL PROTECTED]>
> Subject: canvas.print_figure printing a variable amount of my figure
> To: matplotlib-users@lists.sourceforge.net
> 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.
-
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
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] vertical padding in legend
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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] colors: rgb tuple vs. tuple of rgb values
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"
> }}}
>
-
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
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] Fwd: tcl/tk install problems
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 - 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] broken example - no module numerical_methods
On Tue, Sep 30, 2008 at 6:00 AM, Antonio Gonzalez <[EMAIL PROTECTED]> wrote: > Hello, > > Running the latest mpl (svn 6134), 'fill_between.py' from the examples > directory fails: > > File "fill_between.py", line 2, in >import matplotlib.numerical_methods as numerical_methods > ImportError: No module named numerical_methods Thanks Antonio, This is now fixed in svn 6134. JDH - 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] broken example - no module numerical_methods
Hello, Running the latest mpl (svn 6134), 'fill_between.py' from the examples directory fails: File "fill_between.py", line 2, in import matplotlib.numerical_methods as numerical_methods ImportError: No module named numerical_methods Regards, Antonio - 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] colors: rgb tuple vs. tuple of rgb values
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
-
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
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
