Thanks to visit codestin.com
Credit goes to github.com

Skip to content

ColorbarBase draws edges in slightly wrong positions. #4584

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
rlabbe opened this issue Jul 4, 2015 · 8 comments
Closed

ColorbarBase draws edges in slightly wrong positions. #4584

rlabbe opened this issue Jul 4, 2015 · 8 comments
Labels
status: confirmed bug
Milestone
v3.4.0

Comments

@rlabbe
Copy link

rlabbe commented Jul 4, 2015

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()

figure_3
@jenshnielsen
Copy link
Member

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

@jenshnielsen jenshnielsen added this to the proposed next point release milestone Jul 6, 2015
@tacaswell
Copy link
Member

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
Copy link
Author

rlabbe commented 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:

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

—
Reply to this email directly or view it on GitHub
#4584 (comment)
.

@WeatherGod
Copy link
Member

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:

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:

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

—
Reply to this email directly or view it on GitHub
<
#4584 (comment)

.

—
Reply to this email directly or view it on GitHub
#4584 (comment)
.

@tacaswell tacaswell mentioned this issue Jul 8, 2015
Closed
@efiring efiring mentioned this issue Jul 11, 2015
Closed
@tacaswell tacaswell mentioned this issue Jul 17, 2015
Closed
@tacaswell tacaswell mentioned this issue Dec 22, 2015
Merged
@petehuang
Copy link
Contributor

Reconfirming on TkAgg, MPL 1.5.3, Windows 8.1, Python 2.7.12

@tacaswell
Copy link
Member

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
Copy link
Contributor

Yes, reconfirming with 2.0.0rc2

4584

@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.2 (next next feature release) Oct 3, 2017
@greglucas
Copy link
Contributor

I believe this was solved by #16090. When I run the examples above it looks good to me with no pixel bleeding on master.

@jklymak jklymak closed this as completed Jul 16, 2020
@QuLogic QuLogic modified the milestones: needs sorting, v3.4.0 Jul 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
status: confirmed bug
Projects
None yet
Milestone
v3.4.0
Development

No branches or pull requests
8 participants
@tacaswell @WeatherGod @QuLogic @jenshnielsen @petehuang @jklymak @rlabbe @greglucas