matplotlib-devel Mailing List for matplotlib

>>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
 Nicholas> I think it's partly in there in a non-functional form,
 Nicholas> the patch I've attached removes it and adds a new
 Nicholas> function to the Axes class called directshow. This
 Nicholas> accepts the same syntax as imshow (where relevant)
 Nicholas> rather than adding options to imshow; I chose to do this
 Nicholas> as my old syntax for passing through imshow wasn't that
 Nicholas> easy to understand didn't makes the different
 Nicholas> functionality clear. This function calls a class call
 Nicholas> DirectImage which inherits from AxesImage.
I have mixed feelings about making this a separate class / separate
function. The current axes imshow / image.AxesImage is already
overloaded (handling MxN, MxNx3, MxNx3, _image.Image and PIL images.
What is the logic of making a special functions/classes case for MxNx4
with directshow. On the one hand, I appreciate the desire to simplify
the code by pulling it into separate classes and functions. On the
other hand, I wonder if it will confuse users to have one separate
function for UInt8 images and another for everything else. Another
worry I have about the separate DirectImage class is that it copies
much of the image resize functionality from AxesImage, including the
broken handling of aspect='preserve'. This too argues for keeping as
much functionality in AxesImage as possible, testing for A.typecode()
where appropriate. What do you think?
Also, note the matplotlib CVS has added several new image
interpolation methods. Some of these need the parameters
 filternorm=1,
 filterrad=4.0
as described in the imshow docstring. Since directimage exposes the
interpolation method, shouldn't it also expose these new params.
 Nicholas> I've also rewritten my c++ image object creation
 Nicholas> function called frombyte to take an unsigned byte array
 Nicholas> as input rather than a buffer. By using the
 Nicholas> std::memcopy function rather than a loop for copying the
 Nicholas> speed advantage of passing data in as a buffer
 Nicholas> disappears and using arrays is generally more intuitive.
 Nicholas> The function still only takes x*y*4 arrays as input at
 Nicholas> the moment as the processor time decrease from not using
 Nicholas> loops to copy is fairly significant.
Looks good to me. I'll hold off on applying these changes until I
hear from you on the issues above.
Thanks!
JDH

>>>>> "Daishi" == Daishi Harada <da...@eg...> writes:
 Daishi> Hi John, I've uploaded some new files to sourceforge.
 Daishi> On May 26, 2005, at 7:34 PM, John Hunter wrote:
 >> My only suggestions are: 1) move the dash text class to the
 >> text module rather than the axis module (where it seems to
 >> belong since it is a general purpose connector between a text
 >> instance and a point), and
 Daishi> Done. I also slightly modified axes.py to facilitate
 Daishi> providing your suggestion 2).
I've added the changes to CVS text.py revision: 1.27
Thanks again!
JDH