[Python-3000] PEP 368: Standard image protocol and class

[Joe Smith]

"Lino Mastrodomenico" <l.mastrodomenico at gmail.com> wrote in message 
news:cc93256f0707010959o44c77912sb989c68cf890b846 at mail.gmail.com...
>2007/7/1, BJörn Lindqvist <bjourne at gmail.com>:
>> But I cannot see how it would solve the problem with to many image
>> classes. The reason why PIL, PyGame and wxPython has different image
>> classes is because each of them use different C functions for
>> manipulating said image classes. These differences bubble up through
>> the bindings and results in PIL exposing an Image, PyGame a Surface
>> and wxPython a wxImage. The result is that if you want to use a PIL
>> Image in say PyGame, you  still need to convert it.
>
>Actually, this is not always true. :-)
>
>For example it's entirely possible to have the *same* python RGBA
>image considered as a SDL_Surface by SDL (the underlying library used
>by pygame), as an ImagingMemoryInstance by the PIL C library and have
>its buffer directly accepted by the OpenGL function glTexImage2D (with
>a bit of care in the order of the corners passed to glTexCoord2f),
>independently by who created the image in the first place.
>
>This works because most C/C++ libraries give the possibility of
>creating a native image struct/class using an existing memory buffer
>(without copying it) and they support at least a subset of the modes
>currently defined, with the exact byte order, padding, etc, specified
>in the PEP (usually L and at least one of RGB or RGBA).
>
>But you are right, the particular format specified in the PEP is not
>always supported by existing the libraries, even when they support
>that particular mode. Sometimes this can be fixed (e.g. PIL currently
>uses by default 4 bytes per pixel for RGB images and has only
>experimental support for 3 bytes per pixel, but its C library is
>written by the same people that maintain the Python bindings, so they
>can change it if they want) and sometimes it cannot be easily fixed
>(e.g. a wxImage class will happily accept a RGB buffer as defined by
>the PEP, but it has a funny memory arrangement for RGBA images that is
>completely incompatible).
>
>So I expect that each Python library that jumps on the PEP bandwagon
>will have three levels of support for the modes listed:
>
>  1) no support at all (e.g. most 3D libraries will probably never
>accept CMYK images as textures); the user can explicitly convert the
>image using "new_image = Image(new_mode, source=old_image)";
>
>  2) limited support: they support a particular mode, but cannot
>directly use the standard memory arrangement, so when they receive an
>alien image object they convert it on the fly to their preferred byte
>order and they do the reverse operation when a foreign library tries
>to access the buffer property of their images (they may offer a
>read-only buffer); this is not ideal, but it's better than the current
>situation because it's transparent to the user and it requires only a
>single memory copy/conversion instead of the two usually performed by
>the current tostring/fromstring dance;
>
>  3) full support: no conversion or memory copy ever necessary for the
>exchange of images between two libraries if they both have full
>support for a particular mode. Of course the Image class that I'm
>writing and that I hope will be included in the stdlib, will have full
>support for all the modes.
>
>Please note that the conversions in "2)" above can be avoided in some
>(most?) cases if PEP 3118 is accepted, because it will become possible
>to expose and discover the "native" memory arrangement of an image
>without accessing its buffer property (that, in my vision, will always
>offer the "standard" arrangement defined in the PEP, to simplify
>things for libraries that prefer a simpler interface, even if it may
>be slightly less efficient in some, hopefully rare, cases).
>

If the maintainers of most of the large packages that do imaging are willing 
to support this,
and your code is good, I see absolutely no reason why this PEP would not be 
accepted.

It appears you worked hard to make sure that it would be possible for
the existing libraries to use the Image protocol without too much work.
(Unless they need to use "support level 2" as you described above, for some 
modes. That would add some extra work).

Will you provide an abstract base class for Image Protocol implentations to 
inherit from? (The ImageMixin could inheirit from that class, just not 
providing implemenations of info, buffer, mode, and size. [Hmm. If any of 
those were functions then that would prevent somebody from directly 
instancing ImageMixin, which would be a good thing, as it was really only 
intended to be used as a base class as far as I can tell.])

Will the simple "Image" class have no extra functionally beyond the 
protocol's minimum requirements and the stated resizing/mode-changing 
constructors?

If an image-protocol object is passed to the Image-constructor requesting a 
mode conversion or resizing, but is already in the requested mode/size what 
happens? Is the underlying image data duplicated? Or does the new instance 
basically point to the old data?