The colors.Normalize class currently defines an inverse() method (http://matplotlib.org/devdocs/api/colors_api.html#matplotlib.colors.Normalize -- by the way it is not documented), which maps the normalized value (i.e., index into the colormap) back to image data value.

In practice this method is only used in one place: the colorbar is drawn by taking uniformly spaced points in normalized space, transform back into data space (at the end of Colorbar._process_values()), then later drawn by calling pcolormesh on such data values (applying the normalization back into normalized space). I guess the reason for this is that one may want to draw the colorbar using user-specified data values instead.

However, this could just as easily be done by always working internally in normalized values: by default, just plot uniformly spaced normalized values; if the user specifies the values to use, just normalize them first.

The advantage of making such a change was highlighted to me by #7294, a PR which proposes supporting arbitrary normalization functions. While there are a number of other points I make in that PR, one issue is that this PR requires the user to specify both the normalization function and the inverse normalization function (in order to provide inverse). But, as mentioned above, with a fix to the way colorbars are drawn, there wouldn't be a requirement for the user to specify the inverse normalization (which may be nontrivial to compute).