matplotlib-devel Mailing List for matplotlib

> 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

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?
Perry Greenfield

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