matplotlib-devel Mailing List for matplotlib

Eric Firing wrote:
> John,
>
> I have committed to CVS a set of changes that I think will address 
> recent requests by Jordan and Gerald, and will be of more general use 
> as well. From the CHANGELOG:
>
> 2005年11月27日 Multiple changes in cm.py, colors.py, figure.py, image.py,
> contour.py, contour_demo.py; new _cm.py, 
> examples/image_masked.py.
> 1) Separated the color table data from cm.py out into
> a new file, _cm.py, to make it easier to find the actual
> code in cm.py and to add new colormaps. Also added
> some line breaks to the color data dictionaries. Everything
> from _cm.py is imported by cm.py, so the split should be
> transparent.
> 2) Enabled automatic generation of a colormap from
> a list of colors in contour; see modified
> examples/contour_demo.py.
> 3) Support for imshow of a masked array, with the
> ability to specify colors (or no color at all) for
> masked regions, and for regions that are above or
> below the normally mapped region. See
> examples/image_masked.py.
> 4) In support of the above, added two new classes,
> ListedColormap, and no_norm, to colors.py, and modified
> the Colormap class to include common functionality. Added
> a clip kwarg to the normalize class. Reworked color
> handling in contour.py, especially in the ContourLabeller
> mixin.
>
> With one very subtle exception, I don't think any default behaviors 
> have been changed, so the changes should be entirely non-disruptive.
>
> That one exception is that in the original color mapping scheme, the 
> last color was essentially never used. Consider an extreme case: a 
> colormap with two entries. Suppose the image data ranged from 0 to 1. 
> All values except exactly 1.0 were mapped to the first color, and only 
> that upper limit value was mapped to the second color. As I have 
> changed colors.py, values from 0.0 up to 0.5 will get the first color, 
> and values from 0.5 through 1.0 will get the second. I think this is 
> what a user would expect, and the only reason it hasn't mattered is 
> that with 256 colors in a continuous range, one can't see the difference.
>
> The request from Jordan that is addressed here is the desire for 
> precise color control in filled contouring. Now one can specify a 
> list of colors in the "colors" kwarg, and they will be used to 
> generate a colormap, which will then be used by colorbar. This is 
> shown in a second plot added to examples/contourf_demo.py. (Jordan 
> suggested a more extensive refactoring, which may indeed be a good 
> idea; but I wanted to make these simpler changes before trying to 
> think about anything more drastic.)
>
> The request from Gerald was for easy handling of masked arrays in 
> imshow. It was in the context of basemap, which I have not tested 
> yet; but at least for pylab.imshow, the situation is now easy to 
> handle. If changes to basemap are needed, they should be very simple, 
> and I can do them later as needed. I think that the changes to 
> colormapping that I made to support this will be useful much more 
> widely, but I have made no attempt to track down the places where 
> changes will be in order. I may make additional changes to contour, 
> and I know I will need to change colorbar to fully support this. I 
> think colorbar needs some more refactoring anyway, but I can't do it 
> immediately, and I did not want to delay getting the other changes out 
> for testing and, hopefully, productive use.
>
> Eric
>
Eric: This is fantastic - thanks! I'll try imshow with masked arrays 
and let you know if there are any problems. Should be very useful for 
projections which have some parts hidden, such as orthographic.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-124
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

John,
I think that the following change, from API_CHANGES, is causing trouble:
 made pos=None the default for tick formatters rather than 0 to
 indicate "not supplied"
The symptom is that running (for example) contour_demo.py from the 
command line with gtkagg backend, I often, but not always, get a blast 
of errors like this:
Traceback (most recent call last):
 File 
"/usr/lib/python2.4/site-packages/matplotlib/backends/backend_gtk.py", 
line 188, in motion_notify_event
 FigureCanvasBase.motion_notify_event(self, x, y)
 File "/usr/lib/python2.4/site-packages/matplotlib/backend_bases.py", 
line 797, in motion_notify_event
 func(event)
 File "/usr/lib/python2.4/site-packages/matplotlib/backend_bases.py", 
line 1085, in mouse_move
 try: s = event.inaxes.format_coord(event.xdata, event.ydata)
 File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 612, 
in format_coord
 ys = self.format_ydata(y)
 File "/usr/lib/python2.4/site-packages/matplotlib/axes.py", line 605, 
in format_ydata
 val = func(y)
 File "/usr/lib/python2.4/site-packages/matplotlib/ticker.py", line 
152, in format_data
 return self.__call__(value)
 File "/usr/lib/python2.4/site-packages/matplotlib/ticker.py", line 
178, in __call__
 else: return self.seq[pos]
TypeError: list indices must be integers
pos=None would certainly cause this...but I haven't checked it.
(System is stock Mandriva 2006; mpl is CVS.)
Eric

John,
I have committed to CVS a set of changes that I think will address 
recent requests by Jordan and Gerald, and will be of more general use as 
well. From the CHANGELOG:
2005年11月27日 Multiple changes in cm.py, colors.py, figure.py, image.py,
 contour.py, contour_demo.py; new _cm.py, 
examples/image_masked.py.
 1) Separated the color table data from cm.py out into
 a new file, _cm.py, to make it easier to find the actual
 code in cm.py and to add new colormaps. Also added
 some line breaks to the color data dictionaries. Everything
 from _cm.py is imported by cm.py, so the split should be
 transparent.
 2) Enabled automatic generation of a colormap from
 a list of colors in contour; see modified
 examples/contour_demo.py.
 3) Support for imshow of a masked array, with the
 ability to specify colors (or no color at all) for
 masked regions, and for regions that are above or
 below the normally mapped region. See
 examples/image_masked.py.
 4) In support of the above, added two new classes,
 ListedColormap, and no_norm, to colors.py, and modified
 the Colormap class to include common functionality. Added
 a clip kwarg to the normalize class. Reworked color
 handling in contour.py, especially in the ContourLabeller
 mixin.
With one very subtle exception, I don't think any default behaviors have 
been changed, so the changes should be entirely non-disruptive.
That one exception is that in the original color mapping scheme, the 
last color was essentially never used. Consider an extreme case: a 
colormap with two entries. Suppose the image data ranged from 0 to 1. 
All values except exactly 1.0 were mapped to the first color, and only 
that upper limit value was mapped to the second color. As I have 
changed colors.py, values from 0.0 up to 0.5 will get the first color, 
and values from 0.5 through 1.0 will get the second. I think this is 
what a user would expect, and the only reason it hasn't mattered is that 
with 256 colors in a continuous range, one can't see the difference.
The request from Jordan that is addressed here is the desire for precise 
color control in filled contouring. Now one can specify a list of 
colors in the "colors" kwarg, and they will be used to generate a 
colormap, which will then be used by colorbar. This is shown in a 
second plot added to examples/contourf_demo.py. (Jordan suggested a 
more extensive refactoring, which may indeed be a good idea; but I 
wanted to make these simpler changes before trying to think about 
anything more drastic.)
The request from Gerald was for easy handling of masked arrays in 
imshow. It was in the context of basemap, which I have not tested yet; 
but at least for pylab.imshow, the situation is now easy to handle. If 
changes to basemap are needed, they should be very simple, and I can do 
them later as needed. I think that the changes to colormapping that I 
made to support this will be useful much more widely, but I have made no 
attempt to track down the places where changes will be in order. I may 
make additional changes to contour, and I know I will need to change 
colorbar to fully support this. I think colorbar needs some more 
refactoring anyway, but I can't do it immediately, and I did not want to 
delay getting the other changes out for testing and, hopefully, 
productive use.
Eric