Jae-Joon Lee wrote: > John and others developers, > > I think the current colorbar implementation has some (minor) issue > related with how ticks are treated. > > Here is a quick example, > > imshow(np.arange(100).reshape((10,10))) > cb = colorbar() > > This gives you a nice colorbar, However, an issue arises when you want > to change the ticks. > > cax = cb.ax > cax.set_yticks([0, 40, 80]) > > And the colorbar got messed up. > > Changing ticks and ticklabels after the colobar is created is quite tricky. > And, the easiest solution is to set those when creating the colorbar. > > As far as I can see, the real confusion comes fromthe fact that, in > the current colorbar implementation, the data coordinate of the > colorbar axes has nothing to do with the actual color scale. > In the above example, while the color scale ranges from 0 to 99, the > data coordinate (ylim) is still from 0 to 1.
How do you get around this while supporting both the proportional and the non-proportional modes? > > A few months back, I worked on a revised implementation of the > colorbar, and that version of colorbar is currently included in the > axes_grid toolkit. It is backward-compatible, but it uses > "axes_locator" feature that I'm a bit reluctant to push into the > mainline matplotlib. > > So, here is a few possible resolutions I consider. > > 1) leave it as is. but issue a warning when a users calls "set_yticks" > (or its relatives) on the colobar axes. Based on a quick look, I think that with some refactoring, we could add a set_ticks method. In a way, the question here is whether the colorbar should be thought of as a conventional axes object, or whether it is OK for it to have its own API. I think the latter is more natural, because it is a specialized object; once its orientation is established, there is only one set of ticks and one axis label. Ideally, cbar.ax would be an Axes object stripped down to its essentials; but that would involve major mpl refactoring. Intercepting calls to set_yticks and set_xticks and replacing them with warnings to use a new set_ticks would be good. > > 2) use the reimplemented version of the colorbar, but drop the > axes_locator part. The colorbar will be fully functional except the > "extend" feature (triangles at the ends of the colorbar. see > http://matplotlib.sourceforge.net/examples/api/colorbar_only.html). This is not acceptable. The "extend" feature is essential. > > 3) use the reimplemented version of the colorbar. > > 4) someone else comes up with a better implementation. Regarding 3 or 4, if you or anyone else can come up with a better implementation, preserving at least the present functionality, that's great. The present implementation was a pain to develop and is hard to understand and maintain. Eric > > I don't think there is an immediate need for any changes as I see it > as a minor issue. > I'm just posting this as there has been a few recent questions > regarding the colorbar behavior in the user list. > > Any suggestion and/or comments? > Regards, > > -JJ ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
