> Greg, > > Thank you for your very clear and complete explanation. > > I have committed your patch with only a few modifications: > > 0) I fixed a bug with non-agg backends by setting im.is_grayscale. > > 1) I changed the handling of the interpolation kwarg. The default is > still 'nearest'. > > 2) I took Mike's suggestion to allocate acols and arows only if needed. > > 3) I renamed pcolor_nonuniform to image_nonuniform, modified it to show > both types of interpolation, and added it to the set run by > backend_driver.py. This is the most minimal test; one could write a > whole test suite to exercise various inputs and options.
Thanks for this! > > Among the questions that occur to me: > > 1) Should the functionality be exposed as an Axes method, and from there > as a pyplot function? This could be done by integrating it into imshow, > either via the argument signature or via kwargs for X and Y, or it could > be a separate method. it would be nice, at first I tried to find kwargs in imshow to do exactly that (specify X and Y grid positions), and I did find NonUniformImage after quite a lot of documentation digging and exploring the example directory... > > 2) If X and Y are in fact uniform, should the displayed image be the > same as the present imshow? The big difference now is the boundary: > NonUniformImage extends boundary values indefinitely while Image uses > the background color for anything outside the image. I find the > NonUniformImage behavior disconcerting. You are right, it should be the same. The extrapolation present in NonUniformImage was disconcerting to me at first too, but I now enjoy it: it is the same as what we do in our code for user-provided parameter dependent data: linear interpolation between points, and flat extrapolation outside the min/max: this avoid nasty surprises (linear extrapolation) and sidestep the problem of providing a "default" value outside min/max bounds. But here it is not a strong argument, as background color/full transparency is a good default value in the matplotlib case. I think the best approach would be to give a special kwarg extrapolation= None/flat (and eventually add other options if needed). > > 3) Should caching be added to NonUniformImage? Every other class in the > image.py module uses it. Hum, there I can not help: I do not know what caching is...Is it an optimisation to avoid unneeded re-render, when image size is kept unchanged? If it is, I guess optimisation can never hurt ;-) > > 4) Can we do anything with the internal function naming, at least, to > make the distinction between point data functions and cell data > functions? My thought was to use "image" for point data and "pcolor" > for cell data, but this may reflect my ignorance and particular usage > patterns from matlab days. What I would do is rename the _image.cpp > pcolor function to nonuniform_image, or something like that, to > distinguish it more clearly from pcolor2, which works with cell data. Some rationalization would ne nice indeed. I do not have strong prefences on this, image and pcolor would work fine for me, as any other names used consistently. It could be the opportunity to prepare the addition of other point/cell data function (like delaunay triangulation of arbitrary point data in matlab, or non-uniform cell data with color interpolation on the cell. For the "phong" mapping (mapping data to color after interpolating the data for each pixel ), I am affraid the work would be even greater, as I do not see how to use the imshow filters in this case....except maybe using a fake "greyscale" image working on the data directly, and they mapping the greyscale image to color image using the color mapper pixel per pixel... Performance would suffer, though... Regards, Greg. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
