[Numpy-discussion] array interface, PIL and PyGame

Travis Oliphant oliphant at ee.byu.edu
Tue Jul 11 14:04:37 EDT 2006


Christopher Barker wrote:

>Hi all,
>
>Over on the PIL mailing list, someone asked about some possible 
>additions to PIL to facilitate copy-free moving of data between PyGame 
>and PIL. I sent a note suggesting that the array interface might be just 
>the ticket. These were the responses:
>
>Pete Shinners wrote:
>  
>
>>Yeah, this would be an ideal solution. I hope more of the base array stuff can
>>get into Python 2.6.
>>
>>We did look at the array proposal, but haven't been able to jump on it yet
>>because of adoption. I guess it needs another package or two to get the ball
>>rolling.
>>    
>>
>
>So that's an advocacy issue, and an illustration of why getting it into 
>the standard lib is critical.
>
>Fredrik Lundh wrote:
>  
>
>>unfortunately, the "array interface" model isn't even close to be able 
>>to describe a PIL image memory (the "Imaging" structure)...
>>    
>>
>
>  
>
We will all welcome Fredrik's comments.  But, I think he is exaggerating 
the situation a bit. 

It is true that the Imaging structure of PIL is a more general memory 
model for 2-d arrays.  My understanding is that it basically allows for 
an array of pointers to memory where each pointer points to a different 
line (or chunk) in the image (kind of like a C-array).

So, basically, the problem is that you may have an image that cannot be 
described as a single block of memory or a singly-strided array.  I 
believe, thought,  that sometimes you do have a PIL image that is 
basically a single chunk of memory. 

So, while a general-purpose "memory-sharing" situation might be 
difficult.  I think some sharing (of each chunk for example) could be 
done. 

Even still, the array interface (the Python side) does technically 
handle the PIL case because the default is to use the sequence interface 
to access elements of the array.

It would be nice if Fredrik were more willing to help establish a 
standard, though.  Calling it "not close" but giving no alternative is 
not helpful.

>Darn. It was my understanding that we thought that it was close to being 
>able to describe an image... so what have we missed. I'm out of my 
>technical depth, but I've encouraged Fredrik to bring the discussion here.
>  
>

-Travis





More information about the NumPy-Discussion mailing list