Re: [matplotlib-devel] Patch suggestion

[Nicholas Y. <su...@su...>]

On Wed, 2005-06-01 at 13:14 +0100, Nicholas Young wrote:
> On Wed, 2005-06-01 at 12:39 +0100, Nicholas Young wrote:
> > On Tue, 2005-05-31 at 10:28 -0500, John Hunter wrote:
> > > >>>>> "Nicholas" == Nicholas Young <su...@su...> writes:
> > > 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?
> 
> Sorry to reply to my own message but I realised just after sending it
> that it didn't make any sense (as MxNx4 images aren't normalised
> anyway).  I now realise that it makes sense to assume that an MxNx4
> UInt8 image will contain pixel data as John suggested and I'll rewrite
> my code to implement this.
> 
> It also occurred  to me that it would make sense to change the PIL code
> to avoid the UInt8 -> Float -> UInt transition.  I'll try implementing
> this after making the alterations John suggested.

Now done in the attached patch, I also added support for MxNx3 images;
as I suspected these are noticeably slower than MxNx4 images but I
changed my mind and decided it was worth supporting them.

I changed the PIL image output to output from PIL RGBX (alpha is 255) or
RGBA images only when converting to a string and then array.  This will
use more memory but, as the conversion to RGBA is done no more than once
and by PIL code (which is probably optimised), should be the fastest
option.  I changed the conversion code to always attempt to convert to
RGBA whenever an unsupported format is given and to raise an error on
catching a ValueError (rather than before trying the conversion); this
adds support for several image types.  I'd also suggest changing the
error raised here to a ValueError rather than a SystemError (as the
error is due to an unsupported value) but haven't in case others are
catching the SystemError.

Additionally I changed the docstring for the imshow function to state
that floating point MxNx3 and MxNx4 arrays aren't normalised (this was
the original source of my earlier confusion).

Nick