[SciPy-user] The IO library and image file formats -- compare with with PIL

[Zachary Pincus]

On Apr 21, 2008, at 1:20 PM, Robert Kern wrote:

> On Mon, Apr 21, 2008 at 12:13 PM, Stéfan van der Walt <stefan at sun.ac.za 
> > wrote:
>> On 21/04/2008, Zachary Pincus <zachary.pincus at yale.edu> wrote:
>>
>>> Again, what I'm imagining wouldn't be a full-featured image IO
>>> library, but something lightweight with no dependencies outside of
>>> numpy, and potentially (if JPEG decoding isn't desired), no C-
>>> extensions. (One could conceivably use numpy to do JPEG encoding and
>>> decoding, but I've no interest in doing that...)
>>
>> I love it -- let's do it (if everyone agrees, of course).  Having a
>> Python reference implementation is the way to go.  Should we separate
>> the io and the image processing routines, or put it all in
>> scipy.image?
>
> If you are thinking about using PIL's code, I would prefer that it not
> go into scipy. It smells too much like a fork, and I just don't want
> scipy to get involved.

Understandable. It does seem pretty clear to me that the most  
expeditious way to proceed with a lightweight library would be to  
start by modifying (perhaps heavily, as in beyond-recognition, or  
perhaps lightly to not-at-all) some of the pure-python PIL code that  
is responsible for reading image file headers.

While I wouldn't call this a "fork" so much as the kind of horizontal- 
code-transfer between related projects that is one of the major  
rationales for open-source, there's no reason to be potentially  
provocative.

Let me look into whether this idea is at all feasible, and if it is we  
can revisit the issue of whether it belongs anywhere near scipy.  
(Would getting Fredrik Lundh's OK to use various bits in this way make  
things easier? He does seem much more responsive to direct queries  
than patch-submissions.)

I'm glad that there's some support for the idea, so let me look at the  
code that I have and see if it's worth pursuing.

Zach