matplotlib-devel Mailing List for matplotlib

> I get the feeling that two different ideas are being discussed here. A 
> discrete color map still would require someone to define a custom one 
> if they have a favorite set of colors they want to use for each 
> contour level. That involves some level of inconvenience. I gather 
> from what Jordan is saying is that he wants to be able to 
> automatically construct a colorbar from the colors assigned to each 
> contour level without having to construct a colormap in the first 
> place. That is, after the contour is done with its specific 
> color/level assignments, then a request for a colorbar would show a 
> linear relationship between data levels and the discrete colors 
> chosen. Do I understand correctly?
Yes, that's it exactly.
Jordan

Perry Greenfield wrote:
> 
> On Nov 3, 2005, at 12:55 AM, Jordan Dawe wrote:
> 
>>
>>> Isn't this closely related to the idea we've tslked about a number of
>>> times (mostly off list) to supplant the colormap infrastructure with a
>>> "DiscreteColormap" or something along those lines, which mapped data
>>> to a set of discrete colors, using nearest neighbor or what have
>>> you. Then you would have the best of both worlds: your favorite
>>> colors and consistency with the mpl colorbar/colormapping API. Would
>>> this work?
>>>
>> I don't quite understand the idea here, but the colorbar mapping is 
>> really only part of this. If you make classes for each plot type, you 
>> could do things like make legend() a call to the PlotClass.Legend() 
>> method, and each plot could make it's own kind of legend.
>>
>> I know this is a large architecture change, but it could be 
>> implimented incrimentally and I think it would give a lot of benefits 
>> in regards to what you could do with customizing different plot 
>> behaviours. But, as I said before, I don't really have nearly the 
>> grasp of the matplotlib codebase that the devs do. It doesn't look 
>> too difficult to me, but there are probably issues I am not aware of. 
>> Is there any reason each plot type shouldn't have it's own class?
>>
> I get the feeling that two different ideas are being discussed here. A 
> discrete color map still would require someone to define a custom one if 
> they have a favorite set of colors they want to use for each contour 
> level. That involves some level of inconvenience. I gather from what 
> Jordan is saying is that he wants to be able to automatically construct 
> a colorbar from the colors assigned to each contour level without having 
> to construct a colormap in the first place. That is, after the contour 
> is done with its specific color/level assignments, then a request for a 
> colorbar would show a linear relationship between data levels and the 
> discrete colors chosen. Do I understand correctly?
Automatic colorbar generation when the contourf (for example) colors are 
given explicitly is certainly one of the things Jordan is talking about, 
and it is something I have been intending to get to. I think that a 
first working version, for contour and contourf, can be done with little 
modification to the present code, and I am inclined to do that at least 
as an interim measure ASAP--within a few days--unless a better idea 
becomes clear.
That brings us to the larger framework, and here I think there are two 
or three general ideas rattling around, overlapping but not mutually 
exclusive.
1) The ScalarMappable class could be extended to include additional 
mapping methods. Here are four possibilities:
 - boundaries: this is what contourf already does; N-1 colors are 
mapped to the regions defined by N boundaries.
 - nearest-neighbor: similar but N-to-N
 - dictionary: maps hashable object to color, given an existing dictionary
 - indexed array: Matlab has this, and I use it extensively in Matlab 
to deal with exactly the problem that motivated Jordan's message; but it 
might not be necessary for mpl.
2) When I changed contourf to output a ContourSet object, John suggested 
that this approach might be used for other types of plot (certainly 
pcolor, for example), and this is getting closer to what Jordan is 
talking about as a framework, I think. The idea is to package all 
useful information in an object, so that either its methods can be 
called later, or it can be passed to a function (such as colorbar) that 
understands what to do with it.
3) Jordan's suggestion seems to be going a little farther; I think the 
idea is to design a class hierarchy for plot types to accomplish the 
goals of (2) in a more systematic way, rather than dealing with each 
plot type ad hoc as the demand arises.
Eric

On Nov 3, 2005, at 12:55 AM, Jordan Dawe wrote:
>
>> Isn't this closely related to the idea we've tslked about a number of
>> times (mostly off list) to supplant the colormap infrastructure with a
>> "DiscreteColormap" or something along those lines, which mapped data
>> to a set of discrete colors, using nearest neighbor or what have
>> you. Then you would have the best of both worlds: your favorite
>> colors and consistency with the mpl colorbar/colormapping API. Would
>> this work?
>>
> I don't quite understand the idea here, but the colorbar mapping is 
> really only part of this. If you make classes for each plot type, you 
> could do things like make legend() a call to the PlotClass.Legend() 
> method, and each plot could make it's own kind of legend.
>
> I know this is a large architecture change, but it could be 
> implimented incrimentally and I think it would give a lot of benefits 
> in regards to what you could do with customizing different plot 
> behaviours. But, as I said before, I don't really have nearly the 
> grasp of the matplotlib codebase that the devs do. It doesn't look 
> too difficult to me, but there are probably issues I am not aware of. 
> Is there any reason each plot type shouldn't have it's own class?
>
I get the feeling that two different ideas are being discussed here. A 
discrete color map still would require someone to define a custom one 
if they have a favorite set of colors they want to use for each contour 
level. That involves some level of inconvenience. I gather from what 
Jordan is saying is that he wants to be able to automatically construct 
a colorbar from the colors assigned to each contour level without 
having to construct a colormap in the first place. That is, after the 
contour is done with its specific color/level assignments, then a 
request for a colorbar would show a linear relationship between data 
levels and the discrete colors chosen. Do I understand correctly?
Perry

>Isn't this closely related to the idea we've tslked about a number of
>times (mostly off list) to supplant the colormap infrastructure with a
>"DiscreteColormap" or something along those lines, which mapped data
>to a set of discrete colors, using nearest neighbor or what have
>you. Then you would have the best of both worlds: your favorite
>colors and consistency with the mpl colorbar/colormapping API. Would
>this work?
> 
>
I don't quite understand the idea here, but the colorbar mapping is 
really only part of this. If you make classes for each plot type, you 
could do things like make legend() a call to the PlotClass.Legend() 
method, and each plot could make it's own kind of legend.
I know this is a large architecture change, but it could be implimented 
incrimentally and I think it would give a lot of benefits in regards to 
what you could do with customizing different plot behaviours. But, as I 
said before, I don't really have nearly the grasp of the matplotlib 
codebase that the devs do. It doesn't look too difficult to me, but 
there are probably issues I am not aware of. Is there any reason each 
plot type shouldn't have it's own class?
Jordan