From: Jordan D. <fre...@oc...> - 2005-11-01 18:35:00
|
I have been hacking away at the colorbar( ) code because I wanted a more flexible colorbar facility for my figures. However, the current figure/axes architechture presents a few problems for me. My primary problem is this: I never, ever, ever use the colormap facilities in matplotlib; I specify the colors of each of my contour levels with rgb tuples, because I have grown super-obsessed with graphics design and I want exact control of the shades displayed. Not using colormaps creates the problem that colorbar() doesn't work, as there is no colormap for it to plot. Colormaps are, in my opinion, a horrible hack and one of the worst parts of Matlab. In fact, one of the main reasons I have been using matplotlib is because it's much easier to turn colormaps off. But this does present a problem for automated colorbars. The solution that I am inclined to pursue is to create a set of 'plot-type' objects; ie, objects called "contour", "contourf", "bar", "pie", "plot", etc, which all inherit from a parent class. These objects would contain information about the levels plotted, the colors of the lines, links to the PolyCollections that are currently stored by the axes, etc. This would allow colorbar() to, say, automatically grab the last contourf plotted, figure out the colors, space the color divisions in proportion to the data levels, and so on. I could see if the axes have a contour plot as well as a contourf, and if the data levels agreed, it could plot the contour levels onto the colorbar as well. It would also allow for more flexible legends, and it wouldn't neccessitate the abandonment of matlab compatibility, since colorbar() would still default to searching for a colormap first. But I haven't been looking at the matplotlib code for that long, so I'm not sure this is actually a good idea. Is there an obvious problem with this idea? Is it worth me trying to start hacking something together? Thanks. Jordan |