Re: [matplotlib-devel] Patch suggestion

>>>>> "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