Repository navigation
ColorbarBase draws edges in slightly wrong positions. #4584
Description
The code below uses ColorbarBase to print a stacked bar chart of a list of numbers. I use drawedges=True to get vertical lines to separate the colors with a black line. The lines are often, not always, slightly misaligned compared to the colors and the tick marks, never more than a few pixels. As I drag the matplotlib window larger and slower you can see these edge lines sometimes rendering correctly (right where the colors change) or just a few pixels off. I think the error is always to the right.
I've attached an example image. If you click the image to see if full scale you'll see a several pixel error at 0.3, and perhaps a 1 pixel error at 0.4. If I drag the window to a different size I can make these errors larger or smaller.
Environment:
Windows 7
Anaconda Python 3.4, 64 bit installation.
matplotlib 1.4.3
Qt graphics back end
import matplotlib as mpl
import matplotlib.pyplot as plt
a = [.0, .1, .3, .4, 1.]
cmap = mpl.colors.ListedColormap([[0., .4, 1.],
[0., .8, 1.],
[1., .8, 0.],
[1., .4, 0.],
[0., .4, 1.]])
fig = plt.figure(figsize=(6,3))
ax = fig.add_axes([0.05, 0.475, 0.9, 0.15])
norm = mpl.colors.BoundaryNorm(a, cmap.N)
mpl.colorbar.ColorbarBase(ax, cmap=cmap,
norm=norm,
drawedges=True,
spacing='proportional',
orientation='horizontal')
plt.show()
Activity
jenshnielsen commentedon Jul 6, 2015
I can reproduce this on master with QT4/5, GTK(3)Agg and WXAgg but not with GTK(3)Cairo, OSX and WX backends so It looks like something specific to Agg
tacaswell commentedon Jul 7, 2015
Might be related to snapping?
It might also be some pathological float -> int -> float conversion issues which would mean the line is in the right place and the error is in the colored patches.
You might get some mileage out of http://matplotlib.org/examples/pylab_examples/broken_barh.html
rlabbe commentedon Jul 7, 2015
Having played with it more I'm fairly sure the lines are correct and the
color bars are incorrect.
On Jul 6, 2015 9:11 PM, "Thomas A Caswell" [email protected] wrote:
WeatherGod commentedon Jul 7, 2015
This sounds familiar. It is sort of the snapping problem, but a bit more
subtle than that. Snapping lines and polygons have different implications.
When one snaps a line, everything remails ok, but if one snaps a polygon
that was supposed to be up against another polygon, separation can occur.
If we were to have the polygons share identical vertexes, then separation
doesn't occur because they would be snapped identically, but that causes
issues when alpha is not 1 (lines form).
I guess it would be nice if we could define the strokes for the polygons in
such a way that the vertexes define the outside of the polygons with the
strokes running just inside the defined path. That way, we could share
vertexes for abutting polygons, but not worry about subtle overlap issues
that could occur in rendering.
On Tue, Jul 7, 2015 at 9:16 AM, Roger Labbe [email protected]
wrote:
petehuang commentedon Jan 10, 2017
Reconfirming on TkAgg, MPL 1.5.3, Windows 8.1, Python 2.7.12
tacaswell commentedon Jan 10, 2017
Can you check this with 2.0.0rc2?
I also now strongly suspect that this is related to the stamping / snapping of the ticks.
petehuang commentedon Jan 10, 2017
Yes, reconfirming with 2.0.0rc2
greglucas commentedon Jul 16, 2020
I believe this was solved by #16090. When I run the examples above it looks good to me with no pixel bleeding on master.