PEP368 and pixeliterators

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aloha!

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/

One question/idea though: The proposed iterator will iterate over all
pixels in a line, but only one line. The example code looks like this:

# iterate over an image
for line in rgb_image:
for pixel in line:
# swap red and blue, and set green to 0
pixel.value = pixel.b, 0, pixel.r


But, wouldn't it be more Pythonic and simpler to have an iterator that
iterates over all pixels in an image? Starting with upper left corner
and moving left-right and (line by line) to lower right. This would
change the code above to:

for pixel in rgb_image:
# swap red and blue, and set green to 0
pixel.value = pixel.b, 0, pixel.r


The idea I'm having is that fundamentally the image is made up of a 2D
array of pixels, not rows of pixels. And having the iterator focus on
pixels instead make then more sense, no?

Or if possible have two iterators.


Otherwise, big thumbs up for PEP 368 as well as having PEP:s for driving
the language development process in an orderly and well documented way.

- --
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
Kryptoblog - IT-säkerhet på svenska
http://www.strombergson.com/kryptoblog
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpMcIQACgkQZoPr8HT30QFkcgCgzxb9JS2l87B/nkpf05FLDjY5
RPQAni2yPxKjCd4lM/qMBNhjp8HHg/PZ
=9gB/
-----END PGP SIGNATURE-----

 

[Casey Webster]

But, wouldn't it be more Pythonic and simpler to have an iterator that
iterates over all pixels in an image? Starting with upper left corner
and moving left-right and (line by line) to lower right. This would
change the code above to:

Unless I'm totally misreading the PEP, the author does provide both
iterators. Quoting the PEP:

Non-planar images offer the following additional methods:

pixels() -> iterator[pixel]

Returns an iterator that iterates over all the pixels in the image,
starting from the top line and scanning each line from left to
right.
See below for a description of the pixel objects.

__iter__() -> iterator[line]

Returns an iterator that iterates over all the lines in the image,
from top to bottom. See below for a description of the line objects.

 

[Joachim Strömbergson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aloha!

Unless I'm totally misreading the PEP, the author does provide both
iterators. Quoting the PEP:

Non-planar images offer the following additional methods:

pixels() -> iterator[pixel]

Returns an iterator that iterates over all the pixels in the image,
starting from the top line and scanning each line from left to
right.
See below for a description of the pixel objects.

Ah! I knew there was a reason for me wearing glasses. ;-)

Go PEP368!

- --
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
Kryptoblog - IT-säkerhet på svenska
http://www.strombergson.com/kryptoblog
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpMszQACgkQZoPr8HT30QGmVACfezmlZ+K93exuIEoUDJyzNzgM
3dcAn1x4Ghu9AlMKEme2og4sK4TwhXaR
=bNbl
-----END PGP SIGNATURE-----

 

[Nobody]

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.

 

[Steven D'Aprano]

for pixel in rgb_image:
# swap red and blue, and set green to 0 pixel.value = pixel.b, 0,
pixel.r


The idea I'm having is that fundamentally the image is made up of a 2D
array of pixels, not rows of pixels.

A 2D array implies rows (and columns) of pixels.

 

[Rhodri James]

A 2D array implies rows (and columns) of pixels.

But not necessarily an internal representation in which those rows or
columns are contiguous. An efficient internal storage format might
well include margins to make transform edge cases easier, or store
the pixel components in separate arrays, or both. I'd imagine that
quite frequently, the iterator across all pixels will in fact just
be hiding from the programmer the fact that it's really iterating
by row and then by pixel. At Python's level of abstraction, that's
just fine, but the assumption that an image is made up of a 2D
array of pixels is not safe.