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

Stéfan van der Walt stefan@sun.ac...
Sun Apr 20 12:42:24 CDT 2008

On 18/04/2008, Zachary Pincus <zachary.pincus@yale.edu> wrote:
> I have my own "internal fork" of PIL that I've been calling "PIL-
>  lite". I tore out everything except the file IO, and I fixed that to
>  handle 16-bit files correctly on all endian machines, and to have a
>  more robust array interface.
>  If people wanted to make a proper "fork" of PIL into a numpy-
>  compatible image IO layer, I would be all for that. I'd be happy to
>  donate "PIL-lite" as a starting point. Now, the file IO in PIL is a
>  bit circuitous -- files are initially read by pure-Python code that
>  determines the file type, etc. This information is then passed to
>  (brittle and ugly) C code to unpack and swizzle the bits as necessary,
>  and pack them into the PIL structs in memory.

I would really try and avoid the forking route, if we could.   Each
extra dependency (i.e. libpng, libjpeg etc.) is a potential build
problem, and PIL already comes packaged everywhere.  My changes can
easily be included in SciPy, rather than in PIL.  Could we do the same
for yours?  Then we could rather build scipy.image (Travis' and
Robert's colour-space codes can be incorporated there, as well?) on
top of the PIL.

I'm really unhappy about the current state of ndimage.  It's written
in (Python API) C, so no one wants to touch the code.  Much of it can
be rewritten in equivalent pure Python, using modern NumPy constructs
that weren't available to Peter.  What we really need is to get
knowledgeable people together for a week and hack on this (ndimage is
an extremely useful module!), but I don't know when we're going to
have that chance.  Who fancies a visit to South Africa? :)


More information about the SciPy-user mailing list