From: Christopher B. <Chr...@no...> - 2006-07-11 17:46:58
|
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)... 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. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Travis O. <oli...@ee...> - 2006-07-11 18:04:40
|
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 |
From: Perry G. <pe...@st...> - 2006-07-11 18:30:24
|
On Jul 11, 2006, at 2:04 PM, Travis Oliphant wrote: >> > 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. To expand on this a bit, I think Fredrik is misreading the intent of the array interface somewhat. It's not that we are promising that the array data structure will suit his every need. Far from it. It's that it allows him (or us) to provide convenience functions that allow accessing data in PIL without jumping through lots of annoying hoops. It should be possible to convert PIL image data to arrays easily. Does that mean that all associated information is propagated as part of the array object? Of course not. But this information is obtainable by other means anyway. Even in the case where different chunks of an image are in different memory locations and there is no simple way of avoiding copying the data, so what? I still much prefer the data be copied to an array so that numpy functionality can be applied to the array and have to avoid calling a sequence of operations to convert the data to a string and then to an array. At least one copy is avoided, but avoiding copying isn't the entire justification. Think of it this way, if PIL strength is that it can convert images between many different formats (no doubt, copying data in the process) then arrays should be one of the supported formats, no? Perry |