Request for feedback regarding creation of a plot-type object.

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

Before you go off in this direction, could you outline how you think colormaps should work? From the sounds of it, you are addressing mostly cases where users have specifically picked colors and you would like colorbar() to work with the selected colors. Generally speaking, you seem to be concerned with discrete color sets. But colormaps were primarily directed towards image display where a nearly continuous range of levels might be encountered. So could you explain how you would handle colormaps for images?

Perry Greenfield

ยทยทยท

On Nov 1, 2005, at 1:34 PM, Jordan Dawe wrote:

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

Before you go off in this direction, could you outline how you think colormaps should work? From the sounds of it, you are addressing mostly cases where users have specifically picked colors and you would like colorbar() to work with the selected colors. Generally speaking, you seem to be concerned with discrete color sets. But colormaps were primarily directed towards image display where a nearly continuous range of levels might be encountered. So could you explain how you would handle colormaps for images?

I think that there should essentially be 2 seperate systems, one for discrete color sets and one for colormaps. I think colormaps work great for things like image data or continuous data where transitions between levels are less important than getting a general feeling of magnitude and structure. Discrete contour levels are better for showing where a set of data exceeds threshold values. So both should be useable, but currently the architecture is focused on using colormaps.

As it stands, colorbar() seems perfectly usable if you are working with colormaps--I'm not sure about this though, because I almost never use colormaps in my figures. So I wouldn't change anything about colormaps for images: this is an extension of the functionality, not a modification.

Jordan