PEP368 and pixeliterators

[Nobody]

On Thu, 02 Jul 2009 10:32:04 +0200, Joachim Strömbergson wrote:

> I just read the PEP368 and really liked the proposed idea, sound like a
> great battery addition to include in the std lib:
> 
> http://www.python.org/dev/peps/pep-0368/

Unfortunately, it's too simplistic, meaning that most of the existing
image formats used by the various GUI toolkits (and OpenGL) will need to
be retained.

Obvious omissions include support for arbitrary numbers of bits per
component (e.g. R5G5B5A1), component, pixel and row strides (padding),
mixing packed and planar components (e.g. packed RGB with a separate alpha
plane), and storage orientation (top-to-bottom or bottom-to-top).

Ideally, an Image should be able to use any sane storage format, so that
you don't have to keep converting the Image to an application-specific
format.

NumPy's arrays would probably be a good model here. Essentially, each
component would have a base pointer plus horizontal and vertical strides
measured in bits.

The strides wouldn't necessarily be the same for all components (allowing
for an R8G8B8 plane with a 3-byte stride plus a distinct A8 plane with a
1-byte stride), vertical stride wouldn't necessarily be greater than
horizontal stride (allowing transposition), strides could be negative
(allowing mirroring), and could be less than a byte (allowing e.g. a 1-bpp
alpha channel, planar 4-bpp data, 12-bpp greyscale, etc).

AFAICT, this would allow all common image storage formats to be
represented. The most common exception is 8-bit RGB data using a 6x6x6
colour cube, but that's not common enough to be worth the added complexity.

The interface should also be flexible enough to allow an Image to be a
"proxy" for a non-local image (e.g. one held in video RAM or in the X
server). You wouldn't be able to get a buffer for the image data, but you
should at least be able to obtain the dimensions and format of such
images, and ideally copy the data (or rectangular subregions) to/from a
local image.