You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This actually becomes much more obvious when printing, as this can cause some kind of resonant/ringing pattern (I can send a photo of a printout if needed), and really makes the printed colorbar look bad.
Yes, this keeps coming up, but no one has proposed a really good solution; the problem is a function of the particular renderer. A partial solution is in master. Please give that a try and see what you think.
This is a known issue with adjacent, but not overlapping rectangles.
How about just making them overlap? Have the lower values just a little bit taller than they should be and the upper values placed above so that the lower values are cropped at the right place. It's probably easier said than done though, or someone might have tried it already.
Workarounds like that tend to be difficult or impossible to get right in general. One of the problems is that they cause artifacts if alpha is less than one.
The pdf drawing model has gradient fills, so colorbars could be implemented with those instead of adjacent polygons. I guess it would be a nontrivial change, since we'd need to add a new fill type (or a new kind of artist) to matplotlib and implement it for all backends. I guess svg must have gradient fills, but how about agg?
Ah, I didn't know colorbars would allow transparency like that; it'd probably end up with the inverse problem. Actually, this idea was already mentioned in the colorbar documentation:
It is known that some vector graphics viewer (svg and pdf) renders white gaps
between segments of the colorbar. This is due to bugs in the viewers not
matplotlib. As a workaround the colorbar can be rendered with overlapping
segments::
However this has negative consequences in other circumstances. Particularly
with semi transparent images (alpha < 1) and colorbar extensions and is not
enabled by default see (issue #1188).
The pdf drawing model has gradient fills, so colorbars could be
implemented with those instead of adjacent polygons. I guess it would be
a nontrivial change, since we'd need to add a new fill type (or a new
kind of artist) to matplotlib and implement it for all backends. I guess
svg must have gradient fills, but how about agg?
A problem with this approach, apart from the added complexity, is that
it is using a gradient to represent a discrete set of colors.
Colormapping is done with a lookup table. By default it has 256
entries, but it can have any number, from one on up. So if you are going
to use a gradient, you still have to decide at what point to switch from
the present discrete block representation to the gradient.
Let's see if the workaround in #4481 is good enough.
A problem with this approach, apart from the added complexity, is that
it is using a gradient to represent a discrete set of colors.
The gradients in pdf are not required to be smooth or continuous. It’s of course another question how it gets rendered by any particular application, but I’m sure we could represent a stepwise colorbar as a pdf gradient. I don’t know enough about svg to say if it’s doable there.
Here's an interesting explanation of implementing PDF gradients in LibreOffice. SVG allows gradients that are defined by arbitrary stops, so I'd guess it'd be about the same.
Activity
tacaswell commentedon Sep 26, 2015
This is a known issue with adjacent, but not overlapping rectangles. See http://matplotlib.org/api/pyplot_api.html?highlight=colorbar#matplotlib.pyplot.colorbar down towards the bottom.
efiring commentedon Sep 26, 2015
Yes, this keeps coming up, but no one has proposed a really good solution; the problem is a function of the particular renderer. A partial solution is in master. Please give that a try and see what you think.
tacaswell commentedon Sep 26, 2015
we have a partial fix in master?
efiring commentedon Sep 26, 2015
Yes, I think so. If there are more than 50 colors, the colorbar is rasterized. #4481
tacaswell commentedon Sep 26, 2015
Huh, I even reviewed it....
QuLogic commentedon Sep 29, 2015
How about just making them overlap? Have the lower values just a little bit taller than they should be and the upper values placed above so that the lower values are cropped at the right place. It's probably easier said than done though, or someone might have tried it already.
efiring commentedon Sep 29, 2015
Workarounds like that tend to be difficult or impossible to get right in general. One of the problems is that they cause artifacts if alpha is less than one.
jkseppan commentedon Sep 29, 2015
The pdf drawing model has gradient fills, so colorbars could be implemented with those instead of adjacent polygons. I guess it would be a nontrivial change, since we'd need to add a new fill type (or a new kind of artist) to matplotlib and implement it for all backends. I guess svg must have gradient fills, but how about agg?
QuLogic commentedon Sep 29, 2015
Ah, I didn't know colorbars would allow transparency like that; it'd probably end up with the inverse problem. Actually, this idea was already mentioned in the
colorbardocumentation:efiring commentedon Sep 29, 2015
On 2015/09/28 7:07 PM, Jouni K. Seppänen wrote:
A problem with this approach, apart from the added complexity, is that
it is using a gradient to represent a discrete set of colors.
Colormapping is done with a lookup table. By default it has 256
entries, but it can have any number, from one on up. So if you are going
to use a gradient, you still have to decide at what point to switch from
the present discrete block representation to the gradient.
Let's see if the workaround in #4481 is good enough.
jkseppan commentedon Sep 29, 2015
The gradients in pdf are not required to be smooth or continuous. It’s of course another question how it gets rendered by any particular application, but I’m sure we could represent a stepwise colorbar as a pdf gradient. I don’t know enough about svg to say if it’s doable there.
astrofrog commentedon Sep 29, 2015
Just out of curiosity, why not use
imshowto plot the colorbar, with an array of dimension Nx1 where N is the number of colors in the colorbar?tacaswell commentedon Sep 29, 2015
There are also cases where the color regions in the color bar are not evenly spaced.
QuLogic commentedon Nov 26, 2015
Here's an interesting explanation of implementing PDF gradients in LibreOffice. SVG allows gradients that are defined by arbitrary stops, so I'd guess it'd be about the same.
dstansby commentedon Feb 21, 2017
This looks good to me on master - feel free to reopen if that's not the case.
