I am a bit concerned about the inverse tests:

In [14]:nn=mc.DivergingNorm(0,1,10)In [15]:nn.inverse(nn(np.arange(10)))==np.arange(10)Out[15]:masked_array(data= [TrueFalseFalseFalseFalseFalseFalseFalseFalseFalse],mask=False,fill_value=True)

If I add the inverse function back in the color bar does not work correctly even withspacing=proportional

importnumpyasnpimportmatplotlib.pyplotaspltimportmatplotlib.colorsasmcolorsx=np.linspace(-2,7)y=np.linspace(-1*np.pi,np.pi)X,Y=np.meshgrid(x,y)Z=x*np.sin(Y)**2fig, (ax1,ax2,ax3)=plt.subplots(ncols=3,figsize=(9,3))cmap=plt.cm.coolwarmnorm=mcolors.DivergingNorm(vmin=-2,vcenter=0,vmax=7)img1=ax1.imshow(Z,cmap=cmap,norm=None)cbar1=fig.colorbar(img1,ax=ax1)img2=ax2.imshow(Z,cmap=cmap,norm=norm)cbar2=fig.colorbar(img2,ax=ax2)img3=ax3.imshow(Z,cmap=cmap,norm=norm)cbar3=fig.colorbar(img3,ax=ax3,spacing='proportional')

gives

attn@efiring

definverse(self,value):result,is_scalar=self.process_value(value)self.autoscale_None(result)vmin,vcenter,vmax=self.vmin,self.vcenter,self.vmaxifvmin==vmax==vcenter:result.fill(0)elifnotvmin<=vcenter<=vmax:raiseValueError("minvalue must be less than or equal to ""centervalue which must be less than or ""equal to maxvalue")else:vmin=float(vmin)vcenter=float(vcenter)vmax=float(vmax)# in degenerate cases, prefer the center value to the extremesdegen= (result==vcenter)ifvcenter==vmaxelseNonex,y= [vmin,vcenter,vmax], [0,0.5,1]result=ma.masked_array(np.interp(result,y,x),mask=ma.getmask(result))ifdegenisnotNone:result[degen]=0.5ifis_scalar:result=np.atleast_1d(result)[0]returnresult

@efiring I have sunk another few hours into trying to understand the color bar code and am still failing 😞 (but I am getting closer!). It looks like'proportional' is intended for use with theBoundayNorm and not much else?

I think the problem is that for'proportional' when the color bar is trying to guess what the correct value forb should be in_process_value it should not use the inverse, but I can not figure out what it should use instead. I tried just usingnp.linspace(vmin, vmax), but that doesn't work right (I think there is someplace else in the ticking where it gets compensated for?) and it breaksLogNorm withspacing='proportional'.

@tacaswell, the use of inverse is deliberate; I found I needed it when I added LogNorm. It allows one to find the boundaries in data space corresponding to a linear increase in plot space. This is critical. I'm puzzled as to why the inverse inherited from Normalize seems to be giving a reasonable result. Please give me a little time to figure this out. I agree that the colorbar code is very hard to follow, even for me, who wrote most of it many years ago.
Regarding the spacing kwarg: it is intended to make a difference for "discrete colors", as it says in the docstring--but that could be made clearer. This includes BoundaryNorm, and the discrete boundaries from contourf. It seems like it could also make a difference in the ordinary, quasi-continuous case, and I don't remember whether it ever did, or whether it intentionally does not.

Looking at#5061, I think I understand: the picture you are showing is with the inverse, and#5061 is showing the picture without the inverse. Well, the picture with the inverse is correct in the sense that it is consistent with colorbar's logic--it just isn't what you expect or want. Consider the case of a more extreme norm, the LogNorm: if you were to put in linearly-selected tick values, they would be all bunched together at one end.
I'm still not sure what the solution is; I will look again tomorrow.

Hmm, yes, colorbar code, I took a look at it last night when working on thePiecewiseLinearNorm in#5061, it should serve as an alternative to this PR asDivergingNorm subclassesPiecewiseLinearNorm.

@efiring@tacaswell you should feel happy to note that I have a plan on refactoring the colorbar. While the code still lay clear in my mind of the parts of colorbar that I looked at (the lastelse bit inColorbarBase_process_values, and updated MEP29 (Axes refactor) with the new information I gleaned there, still very much a W-I-P so no need to look at it now, just to let you know it does and will get some attention in the near future 👼.

I am starting to think that getting this in for 1.5 is a bigger can of worms than anticipated.

Due to the issues with the inverse and the colorbar, punting this to the next release.

On 2015/09/14 5:50 AM, Thomas A Caswell wrote:

Due to the issues with the inverse and the colorbar, punting this to the
next release.

Good move. I don't see it as urgent.

Okay, I now understand the inverse thing inColorbarBase and I document this in MEP29, as I see it we have two different scales going on, the scale used byNormalize to map the values to a colour, and the scale used to draw thecolorbar.ColorbarBase currently assumes this later scale as the inverse of that given by theNormalize class, i.e. with the inverse, when we specify a center value for example, 0.5, in the example abovevcenter=0.5, this means that the colorbar will currently obey that.

So the solution lies into seperating this conflation of scales into the two distinct scales, something I had planned for MEP29, but didn't realise until now just how significantly this refactor plays into this issue.

This seems to have died an untimely death. Does anyone want to champion?

How about making such thing a wishlist item or something similar, to make it something that can get picked up, but doesn't count as a blocker for release.

Moved to#12419....