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. -- http://mail.python.org/mailman/listinfo/python-list
