Transparent figures no longer working

Not sure when this occurred, but I just updated to the latest SVN and
still see the issue:
   I am no longer able to save transparent figure---specifically, I
need no patch drawn for the figure and axis when saving to EPS.

savefig('test.eps', transparent=True)

The above should work, but it doesn't.. Explicitly setting the patch
colors to 'none' doesn't work either.

Anyone else seeing this?

Looking at the code, the "transparent" option set alphas of paches to
0, which I think is simply ignored in ps backend (which does not
support alpha). I think it is better if the visibility of patches is
set to False when the "transparent" option is set.

Setting patch's (face) color to "none" work for me. If it does not
work, please post a complete script.

Regards,

-JJ

···

On Mon, Apr 26, 2010 at 2:38 AM, T J <tjhnson@...287...> wrote:

Not sure when this occurred, but I just updated to the latest SVN and
still see the issue:
I am no longer able to save transparent figure---specifically, I
need no patch drawn for the figure and axis when saving to EPS.

savefig('test.eps', transparent=True)

The above should work, but it doesn't.. Explicitly setting the patch
colors to 'none' doesn't work either.

Anyone else seeing this?

------------------------------------------------------------------------------
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

Looking at the code, the "transparent" option set alphas of paches to
0, which I think is simply ignored in ps backend (which does not
support alpha). I think it is better if the visibility of patches is
set to False when the "transparent" option is set.

Or both.

Setting patch's (face) color to "none" work for me. If it does not
work, please post a complete script.

Attached. But I'm not doing anything fancy. I've also attached the
EPS along with a TEX document.

transeps.py (180 Bytes)

transeps.eps (13.1 KB)

transeps.tex (195 Bytes)

···

On Mon, Apr 26, 2010 at 12:01 PM, Jae-Joon Lee <lee.j.joon@...287...> wrote:

Jae-Joon Lee wrote:

Looking at the code, the "transparent" option set alphas of paches to
0, which I think is simply ignored in ps backend (which does not
support alpha). I think it is better if the visibility of patches is
set to False when the "transparent" option is set.

The ps backend does not support alpha in general, but it does use alpha=0 as a flag to not render. The problem is that there is a single alpha for an artist with both line color and face color. The artist alpha kwarg and attribute are at the root of much of the present alpha-mess in mpl.

Setting patch's (face) color to "none" work for me. If it does not
work, please post a complete script.

I think this is what needs to be fixed in figure.py: the transparent option should be manipulating the patch facecolors, not the patch artist alpha value.

Eric

···

Regards,

-JJ

On Mon, Apr 26, 2010 at 2:38 AM, T J <tjhnson@...287...> wrote:

Not sure when this occurred, but I just updated to the latest SVN and
still see the issue:
  I am no longer able to save transparent figure---specifically, I
need no patch drawn for the figure and axis when saving to EPS.

savefig('test.eps', transparent=True)

The above should work, but it doesn't.. Explicitly setting the patch
colors to 'none' doesn't work either.

Anyone else seeing this?

------------------------------------------------------------------------------
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

------------------------------------------------------------------------------
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

Has anyone been able to reproduce this? If not, it suggests a local
problem for me. I am still interested in figuring it out, but I could
use some pointers.

···

On Mon, Apr 26, 2010 at 12:28 PM, T J <tjhnson@...287...> wrote:

On Mon, Apr 26, 2010 at 12:01 PM, Jae-Joon Lee <lee.j.joon@...287...> wrote:

Looking at the code, the "transparent" option set alphas of paches to
0, which I think is simply ignored in ps backend (which does not
support alpha). I think it is better if the visibility of patches is
set to False when the "transparent" option is set.

Attached. But I'm not doing anything fancy. I've also attached the
EPS along with a TEX document.

T J wrote:

Looking at the code, the "transparent" option set alphas of paches to
0, which I think is simply ignored in ps backend (which does not
support alpha). I think it is better if the visibility of patches is
set to False when the "transparent" option is set.

Attached. But I'm not doing anything fancy. I've also attached the
EPS along with a TEX document.

Has anyone been able to reproduce this? If not, it suggests a local
problem for me. I am still interested in figuring it out, but I could
use some pointers.

It's a bug, made more confusing by the trickery that is done when printing a figure. DPI, facecolor, and edgecolor that are set for a figure object are used only for screen display, and are overridden when the figure is saved. The overriding values can be supplied to the savefig call or via rcParams.

I think I have fixed the bug in svn, so that "transparent" will work as advertised. In addition, I made a change so that even with transparent=True, if you supply facecolor and/or edgecolor to the savefig call, those values should be used for the figure patch when the figure is saved. This might be useful if you want to keep the line around the figure, for example.

Eric

···

On Mon, Apr 26, 2010 at 12:28 PM, T J <tjhnson@...287...> wrote:

On Mon, Apr 26, 2010 at 12:01 PM, Jae-Joon Lee <lee.j.joon@...287...> wrote:

This still does not work for me. I dug around a bit and found an
issue. Figure.savefig() sets the 'edgecolor' and 'facecolor' of the
axis patches but delegates the patches of the figure to the actual
print command. It does this by setting the edgecolor and facecolor
values in the kwargs dict. However, self.canvas.print_figure()
expects edgecolor and facecolor as args, not kwargs. So
print_figure() uses the default value: 'w' instead of 'none'. This is
a bit inconsistent, it seems, especially b/c the PS backend (which is
called after print_figure()) expects facecolor and edgecolor as
kwargs.

I went ahead and changed this, hoping it'd fix the issue, but it does
not. At least now, I can see that the edgecolor and facecolor are
both set to 'none' all the way until self.figure.draw(renderer) is
called. So somehow, the draw() command is unaffected by this still.

What next?

···

On Wed, Apr 28, 2010 at 12:22 PM, Eric Firing <efiring@...202...> wrote:

It's a bug, made more confusing by the trickery that is done when printing a
figure. DPI, facecolor, and edgecolor that are set for a figure object are
used only for screen display, and are overridden when the figure is saved.
The overriding values can be supplied to the savefig call or via rcParams.

I think I have fixed the bug in svn, so that "transparent" will work as
advertised. In addition, I made a change so that even with
transparent=True, if you supply facecolor and/or edgecolor to the savefig
call, those values should be used for the figure patch when the figure is
saved. This might be useful if you want to keep the line around the figure,
for example.

T J wrote:

It's a bug, made more confusing by the trickery that is done when printing a
figure. DPI, facecolor, and edgecolor that are set for a figure object are
used only for screen display, and are overridden when the figure is saved.
The overriding values can be supplied to the savefig call or via rcParams.

I think I have fixed the bug in svn, so that "transparent" will work as
advertised. In addition, I made a change so that even with
transparent=True, if you supply facecolor and/or edgecolor to the savefig
call, those values should be used for the figure patch when the figure is
saved. This might be useful if you want to keep the line around the figure,
for example.

This still does not work for me. I dug around a bit and found an
issue. Figure.savefig() sets the 'edgecolor' and 'facecolor' of the
axis patches but delegates the patches of the figure to the actual
print command. It does this by setting the edgecolor and facecolor
values in the kwargs dict. However, self.canvas.print_figure()
expects edgecolor and facecolor as args, not kwargs. So
print_figure() uses the default value: 'w' instead of 'none'. This is
a bit inconsistent, it seems, especially b/c the PS backend (which is
called after print_figure()) expects facecolor and edgecolor as
kwargs.

I don't see this in the version as I changed it in svn r8282. Are you sure you installed and built from svn after I made the change? Using the attached script, I get the two attached (gzipped) eps files. The first with transparent=True, has no fill operations other than for generation of the glyphs; the second differs from the first in having two extra fill operations, one for the axes patch, the other for the figure patch.

When I use your transeps.tex, run latex, and then dvips, the resulting ps file (also gzipped and attached) has the figure with a red background, sitting on a white page. I presume this is what you expect, and so the figure and axes really are transparent.

Eric

transeps.py (168 Bytes)

transeps.eps.gz (2.76 KB)

transeps_opaque.eps.gz (2.78 KB)

transeps.ps.gz (16.3 KB)

···

On Wed, Apr 28, 2010 at 12:22 PM, Eric Firing <efiring@...202...> wrote:

I went ahead and changed this, hoping it'd fix the issue, but it does
not. At least now, I can see that the edgecolor and facecolor are
both set to 'none' all the way until self.figure.draw(renderer) is
called. So somehow, the draw() command is unaffected by this still.

What next?

------------------------------------------------------------------------------
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options

It looks like I messed up my install. On top of that, when I was
testing this second time, I was not bothering to create the ps (from
latex) and just using my OS's default EPS viewer to verify that
transparency was working---the problem was that Evince displays images
on a white background rather than on some distinguishing background to
let me know that it is a transparent image. Sorry for the noise, its
definitely working in r8282.

···

On Fri, Apr 30, 2010 at 1:55 AM, Eric Firing <efiring@...202...> wrote:

I don't see this in the version as I changed it in svn r8282. Are you sure
you installed and built from svn after I made the change? Using the
attached script, I get the two attached (gzipped) eps files. The first with
transparent=True, has no fill operations other than for generation of the
glyphs; the second differs from the first in having two extra fill
operations, one for the axes patch, the other for the figure patch.