Now that alpha works with screen output, I recognized a problem with the eps output. This is my little test script:
import pylab
x = pylab.npy.arange(0,10)
pylab.scatter(x,x, s=50, alpha=0.5)
pylab.scatter(x,x+0.5, facecolor='blue', edgecolor='red', s=50, alpha=0)
pylab.savefig('alpha.png')
pylab.savefig('alpha.eps')
pylab.show()
The resulting figures are attached. The problem occurs in the eps output where the edgecolors are not correctly reproduced, only the first marker symbol has a red edge, the others don't.
I used the latest svn for this test.
Manuel
John Hunter wrote:
alpha.eps (29.1 KB)
···
On 10/18/07, John Hunter <jdh2358@...149...> wrote:
You should use the "c" argument for scatter -- this controls the facecolor.
scatter(x,x+0.5, c='blue', s=50, alpha=0.5)
This is a bit of an anachronism from matlab compatibility.
This is now fixed in svn, so you can use facecolor as well. Note that
for constant size and color markers, plot will be significantly faster
ax.plot(x, x+0.5, mfc='blue', alpha=0.5, ms=20)
JDH
I removed a gsave/grestore pair surrounding RendererPS._draw_ps in svn-3967.
It looks like this fixed the problem (graphics state was being lost). I
checked contour_demo.py for any unintended side-effects, and didn't find any,
but please keep an eye out for strange behavior.
Darren
···
On Friday 19 October 2007 03:57:31 am Manuel Metz wrote:
Now that alpha works with screen output, I recognized a problem with the
eps output. This is my little test script:
import pylab
x = pylab.npy.arange(0,10)
pylab.scatter(x,x, s=50, alpha=0.5)
pylab.scatter(x,x+0.5, facecolor='blue', edgecolor='red', s=50, alpha=0)
pylab.savefig('alpha.png')
pylab.savefig('alpha.eps')
pylab.show()
The resulting figures are attached. The problem occurs in the eps output
where the edgecolors are not correctly reproduced, only the first marker
symbol has a red edge, the others don't.
I added this gsave/grestore pair in draw_ps because in a first attempt
to get Ellipse working properly with axis='auto'. I was using an
approach inspired by Michael's branch, which is to create a unit
circle and then apply rotation and scaing transformation to make the
ellipse. The transformation settings were persistent so I wrapped all
of the draw_ps in a save/restore block to insulate them.
Then I realized that doing the transformation in PS wreaks all kinds
of havoc with the linewidth settings, and reverted the code to doing
the transformations in python, as we have always done. So removing
the save/restore block should be fine, but file it away in the back of
your mind that pushing transformations in the current implementation
may result in unintended weirdness.
JDH
···
On 10/19/07, Darren Dale <darren.dale@...143...> wrote:
I removed a gsave/grestore pair surrounding RendererPS._draw_ps in svn-3967.
It looks like this fixed the problem (graphics state was being lost). I
checked contour_demo.py for any unintended side-effects, and didn't find any,
but please keep an eye out for strange behavior.
Thanks for letting me know. When we first implemented draw_markers in
backend_ps, we let the postscript interpretter do the transforms. That turned
out to be a disaster. It took forever for ghostscript to render the images,
so we went back to doing transforms in mpl.
Darren
···
On Friday 19 October 2007 10:55:24 am John Hunter wrote:
On 10/19/07, Darren Dale <darren.dale@...143...> wrote:
> I removed a gsave/grestore pair surrounding RendererPS._draw_ps in
> svn-3967. It looks like this fixed the problem (graphics state was being
> lost). I checked contour_demo.py for any unintended side-effects, and
> didn't find any, but please keep an eye out for strange behavior.
I added this gsave/grestore pair in draw_ps because in a first attempt
to get Ellipse working properly with axis='auto'. I was using an
approach inspired by Michael's branch, which is to create a unit
circle and then apply rotation and scaing transformation to make the
ellipse. The transformation settings were persistent so I wrapped all
of the draw_ps in a save/restore block to insulate them.
Then I realized that doing the transformation in PS wreaks all kinds
of havoc with the linewidth settings, and reverted the code to doing
the transformations in python, as we have always done. So removing
the save/restore block should be fine, but file it away in the back of
your mind that pushing transformations in the current implementation
may result in unintended weirdness.
Darren Dale wrote:
I removed a gsave/grestore pair surrounding RendererPS._draw_ps in
svn-3967. It looks like this fixed the problem (graphics state was being
lost). I checked contour_demo.py for any unintended side-effects, and
didn't find any, but please keep an eye out for strange behavior.
I added this gsave/grestore pair in draw_ps because in a first attempt
to get Ellipse working properly with axis='auto'. I was using an
approach inspired by Michael's branch, which is to create a unit
circle and then apply rotation and scaing transformation to make the
ellipse. The transformation settings were persistent so I wrapped all
of the draw_ps in a save/restore block to insulate them.
Then I realized that doing the transformation in PS wreaks all kinds
of havoc with the linewidth settings, and reverted the code to doing
the transformations in python, as we have always done. So removing
the save/restore block should be fine, but file it away in the back of
your mind that pushing transformations in the current implementation
may result in unintended weirdness.
The gsave/grestore can always be placed only around the transform and the fill/stroke itself, not around the graphics context changes. That's what I have done for the clip paths on the branch, and what the clipping rectangle already does on the trunk.
Thanks for letting me know. When we first implemented draw_markers in backend_ps, we let the postscript interpretter do the transforms. That turned out to be a disaster. It took forever for ghostscript to render the images, so we went back to doing transforms in mpl.
For both of these reasons, I also bailed on doing the transformations in the Postscript (and PDF, SVG and probably Cairo) on my branch as well. I'm leaving the backend interface as-is (where the outline and the transform are both passed to the backend), because that approach is slightly faster with the Agg backend, mainly because it doesn't have to make a transformed copy of all of the points before rendering. But that does mean the output of the non-interactive backends will benefit less from all this refactoring than originally thought. However, it should be helpful in the long run to have fewer backend methods to write and maintain.
Cheers,
Mike
···
On Friday 19 October 2007 10:55:24 am John Hunter wrote:
On 10/19/07, Darren Dale <darren.dale@...143...> wrote:
--
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA
