The problem is the default quantizing of all rectilinear axis-aligned
lines (which includes the spines). They are "rounded" to the nearest
center pixels in order to make them less fuzzy.
However, there's actually a bug in the quantizer that your example
illustrates. Since the spine lines in your example have a stroke width
of 4 pixels, they should actually be rounded to the nearest pixel edge,
not nearest center pixel. So the quantizing is causing this slight
alignment problem *and* making the straight lines look fuzzier than they
should. I'm planning on writing a patch that will take stroke width
into account to address this. By coincidence only, this will also make
your example plot look more accurate (but that's dependent on the
specific scale being used).
The quantizing (once corrected) is a tradeoff to increase the sharpness
of rectilinear lines (which is important to many, including myself) at
the expense of some subpixel accuracy. The easy solution is to provide
a global flag (similar to path.simplify) that would turn off
quantization globally for those that want to live on the other side of
the tradeoff. The harder solution would be to quantize the axes (or
spines) and adjust the data accordingly based on the amount of shift.
I'm really not sure how to make the latter work without completely
reworking how quantization is currently implemented (the quantization is
pretty ignorant of anything "global" other than what it is currently
drawing).
Mike
On 06/11/2010 02:02 AM, Jason Grout wrote:
> Hi all,
>
> If you zoom in to the origin in the following figure:
>
> fig = plt.figure()
> ax = fig.add_subplot(1,1,1, aspect='equal')
> ax.plot([-1,1],[-1,1], color='blue')
> ax.set_xlim(-1.1,1.1)
> ax.set_ylim(-1.1,1.1)
> ax.spines['left'].set_position('zero')
> ax.spines['right'].set_color('none')
> ax.spines['bottom'].set_position('zero')
> ax.spines['top'].set_color('none')
> ax.xaxis.set_ticks_position('bottom')
> ax.yaxis.set_ticks_position('left')
> fig.savefig('test.png',dpi=300)
>
> you'll see that the blue line isn't quite centered at the origin (at
> least the origin marked by the spines). It appears to hit just above or
> just to the left of the origin. Notice that there is a bit of blue
> coloring in the second quadrant, but none in the fourth. Notice also
> that there are more pixels colored just below the x-axis in quadrant 3
> than just above the axis in quadrant 1.
>
> Several of us Sage developers have been practically pulling out our hair
> trying to trace down why our plots seem to be shifted up or to the left
> by a pixel or so. I think the above example illustrates what is going on.
>
> Any ideas as to what is going on? I'm not sure if the problem is with
> the line or with the spines. The lines ax.plot([-1,1],[0,0]) and
> ax.plot([0,0],[-1,1]) seem to be right on center with the spines.
>
> Thanks,
>
> Jason
>
> --
> Jason Grout
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
