Hi all,
I'm generating plots for a document with a non-white background, and I
need the outer rectangle (the one is normally gray on the screen) to
be transparent. Savefig doesn't seem to have such an option: is it
possible to do it already, and if not, would there be any interest in
a patch?
Regards
Stéfan
Something similar was added to SVN yesterday. Pass "transparent=True" to savefig. This will set both the figure rectangle and the axes rectangles to transparent.
If you just want a transparent figure rectangle, you can do:
fig().figurePatch.set_alpha(0.0)
Maybe this should be made an option on the "transparent" kwarg to savefig, something like:
transparent = 'figure' | 'figure_and_axes'
Or is that just making things too complicated?
Cheers,
Mike
St�fan van der Walt wrote:
Hi all,
I'm generating plots for a document with a non-white background, and I
need the outer rectangle (the one is normally gray on the screen) to
be transparent. Savefig doesn't seem to have such an option: is it
possible to do it already, and if not, would there be any interest in
a patch?Regards
St�fan-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
2008/6/25 Michael Droettboom <mdroe@...31...>:
Maybe this should be made an option on the "transparent" kwarg to savefig,
something like:transparent = 'figure' | 'figure_and_axes'
Or is that just making things too complicated?
Those options would both be very handy.
In the meantime, thanks for the workaround! My hack was to export to
SVG, then edit with Inkscape (first compiled Inkscape for OSX :), save
to PNG and finally convert the PNG to a PNG that Firefox can
understand, using GIMP (also compiled for OSX). Phew!
Regarding OSX: it seems that, for the first time in months, I can now
build matplotlib on OSX with gcc 4.1 without jumping through all sorts
of crazy loops. Thanks!
Regards
Stéfan
Stefan -- just for a little background. The figure has a
matplotlib.patches.Rectangle instance called "figurePatch" and the
axes has a Rectangle instance called axesPatch. You can set any
property on them directly (facecolor, edgecolor, linewidth, linestyle,
alpha). Eg,
fig = plt.figure()
fig.figurePatch.set_alpha(0.5)
ax = fig.add_subplot(111)
ax.axesPatch.set_alpha(0.5)
Michael's transparent kwarg is just a helper function to do this
automatically at save time w/o affecting the screen rendered figure.
For stylistic reasons, I'd like a new name for figurePatch and
rectanglePatch. "background", "rectangle" and "patch" would all be
nicer. I'm inclined toward "rectangle" -- I think I'll just put an
alias in Figure and Axes unless someone has a better idea.
JDH
On Wed, Jun 25, 2008 at 8:25 AM, Stéfan van der Walt <stefan@...337...> wrote:
2008/6/25 Michael Droettboom <mdroe@...31...>:
Maybe this should be made an option on the "transparent" kwarg to savefig,
something like:transparent = 'figure' | 'figure_and_axes'
Or is that just making things too complicated?
Those options would both be very handy.
"rectangle" might be a bad name for "axesPatch" since it can be a circle for polar plots, and ellipse for geo plots etc.
Cheers,
Mike
John Hunter wrote:
On Wed, Jun 25, 2008 at 8:25 AM, St�fan van der Walt <stefan@...337...> wrote:
2008/6/25 Michael Droettboom <mdroe@...31...>:
Maybe this should be made an option on the "transparent" kwarg to savefig,
something like:transparent = 'figure' | 'figure_and_axes'
Or is that just making things too complicated?
Those options would both be very handy.
Stefan -- just for a little background. The figure has a
matplotlib.patches.Rectangle instance called "figurePatch" and the
axes has a Rectangle instance called axesPatch. You can set any
property on them directly (facecolor, edgecolor, linewidth, linestyle,
alpha). Eg,fig = plt.figure()
fig.figurePatch.set_alpha(0.5)
ax = fig.add_subplot(111)
ax.axesPatch.set_alpha(0.5)Michael's transparent kwarg is just a helper function to do this
automatically at save time w/o affecting the screen rendered figure.
For stylistic reasons, I'd like a new name for figurePatch and
rectanglePatch. "background", "rectangle" and "patch" would all be
nicer. I'm inclined toward "rectangle" -- I think I'll just put an
alias in Figure and Axes unless someone has a better idea.JDH
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
Ahh yes, mind still mushy even after a good night's sleep. "patch" or
"background" I feel about the same. "patch" isn't terribly mnemonic
unless you are a matlab user, but at least it points you to the base
class and is most consistent with the current name, in which the
"figure" part of "figurePatch" is simply redundant.
patch, going once, going twice,...
JDH
On Wed, Jun 25, 2008 at 9:09 AM, Michael Droettboom <mdroe@...31...> wrote:
"rectangle" might be a bad name for "axesPatch" since it can be a circle for
polar plots, and ellipse for geo plots etc.
I was just confused by the method "get_axes_patch" which looks like an
accessor method for the axesPatch, but instead is the method that
generates a new rectangle (or circle or whatever). To add to the
confusion, there is the method get_frame, which returns the axesPatch
even though there is also an axesFrame (which was created by
get_axes_patch). Is you head spinning like mine?
How about:
_generate_axes_patch to replace get_axes_patch - internal class use only
get_frame and get_patch deprecated - just use "patch" and "frame",
formerly "axesPatch" and "axesFrame". We'll add a deprecation warning
to get_frame and keep axesPatch and axesFrame around as aliases.
Michael -- IIRC you added the axesFrame. Was this to support to
separate drawing of the edge and face since our patches don't
(currently) have support for separate alpha channels for edge and
face. Or are there additional motivations for the projection
backends?
JDH
On Wed, Jun 25, 2008 at 9:23 AM, John Hunter <jdh2358@...149...> wrote:
On Wed, Jun 25, 2008 at 9:09 AM, Michael Droettboom <mdroe@...31...> wrote:
"rectangle" might be a bad name for "axesPatch" since it can be a circle for
polar plots, and ellipse for geo plots etc.Ahh yes, mind still mushy even after a good night's sleep. "patch" or
"background" I feel about the same. "patch" isn't terribly mnemonic
unless you are a matlab user, but at least it points you to the base
class and is most consistent with the current name, in which the
"figure" part of "figurePatch" is simply redundant.
John Hunter wrote:
"rectangle" might be a bad name for "axesPatch" since it can be a circle for
polar plots, and ellipse for geo plots etc.
Ahh yes, mind still mushy even after a good night's sleep. "patch" or
"background" I feel about the same. "patch" isn't terribly mnemonic
unless you are a matlab user, but at least it points you to the base
class and is most consistent with the current name, in which the
"figure" part of "figurePatch" is simply redundant.
I was just confused by the method "get_axes_patch" which looks like an
accessor method for the axesPatch, but instead is the method that
generates a new rectangle (or circle or whatever). To add to the
confusion, there is the method get_frame, which returns the axesPatch
even though there is also an axesFrame (which was created by
get_axes_patch). Is you head spinning like mine?
Yes, I saw that when I added the transparent kwarg and was also confused, but thought best to leave it at the time... 
How about:
_generate_axes_patch to replace get_axes_patch - internal class use only
get_frame and get_patch deprecated - just use "patch" and "frame",
formerly "axesPatch" and "axesFrame". We'll add a deprecation warning
to get_frame and keep axesPatch and axesFrame around as aliases.Michael -- IIRC you added the axesFrame. Was this to support to
separate drawing of the edge and face since our patches don't
(currently) have support for separate alpha channels for edge and
face. Or are there additional motivations for the projection
backends?
It was so that the zorder could be something like:
axesPatch
... data ...
... grids ...
axesFrame
It prevents data from overlapping the axes frame. This was most crucial in the PDF and Cairo backends where the clipping rectangle is pixel-aligned but the axes frame and background are not necessarily. In the Agg backend, where we have more fine control, it actually doesn't really matter.
Cheers,
Mike
On Wed, Jun 25, 2008 at 9:23 AM, John Hunter <jdh2358@...149...> wrote:
On Wed, Jun 25, 2008 at 9:09 AM, Michael Droettboom <mdroe@...31...> wrote:
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
Michael Droettboom wrote:
get_frame and get_patch deprecated - just use "patch" and "frame",
formerly "axesPatch" and "axesFrame". We'll add a deprecation warning
to get_frame and keep axesPatch and axesFrame around as aliases.Michael -- IIRC you added the axesFrame. Was this to support to
separate drawing of the edge and face since our patches don't
(currently) have support for separate alpha channels for edge and
face. Or are there additional motivations for the projection
backends?
I did it two years ago, r2415.
It was so that the zorder could be something like:
axesPatch
... data ...
... grids ...
axesFrame
This was the main motivation, but the secondary thought was that it would facilitate doing something that people ask for now and then, which is allow one to specify only some axes boundaries instead of the whole rectangle. A common plot style is to have axes lines on the left and bottom, for example; but sometimes people want only a line on the bottom, and I am sure that sooner or later someone will want top and right, or top and bottom, or whatever. Obviously, I never got around to putting that option in place.
It prevents data from overlapping the axes frame. This was most crucial in the PDF and Cairo backends where the clipping rectangle is pixel-aligned but the axes frame and background are not necessarily. In the Agg backend, where we have more fine control, it actually doesn't really matter.
No, I think it matters on all backends, especially if the frame is thick. Whether the zorder above is what one wants may be a matter of taste, but on any backend it will make a difference in the way the plot looks.
Eric
Cheers,
Mike