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

[Zachary Pincus]

Hello all,

> please don't discuss ndimage and image file-IO (alas PIL) in the  
> same thread !!!
> the "image" in "ndimage" has nothing (!!) to do with jpeg or tiff
> ---- you might know this....

Ha ha, agreed. Sorry!

> So, I summarize then from the recent discussion here,
>  that PIL could be divided into consisting   of five parts:
> a) file format handling based on external libs such as libjpg, libpng,
> (not libtiff, I think, please confirm !!)
> b) file format handling based on PIL's python code
> c) image processing, such as contrast change, pixelwise mapping,
> transformations like rotation, ...
> d) image drawing, like addiong text into an image
> e) image display

One note: (b) should be divided into: (b.1) File _format_  
interpretation in pure-python code (that is, figuring out where in the  
file the image pixels are, in what format they are stored, and in what  
format they need to be unpacked); and (b.2) Pixel unpacking in C-code.

I never use (a) -- the pure-python code for interpreting files is just  
fine, and much more flexible. The only thing that (a) doesn't handle,  
as far as I know, are JPEG files -- those need an external library, I  
fear.
(b.1) is quite good, but there have been a few things I've needed to  
patch with regard to 16-bit TIFFs and PNGs, and 32-bit TIFFs.
(b.2) is not so good, mostly because it's written around the PIL's  
memory model, which is trickier to work with than numpy, and has much  
less flexibility with regard to data type.

I'm with you on the interpretation of the rest.

To answer Stéfan's earlier question of how I see things fitting  
together, I *think* that the pure-python file format interpretation  
code could be used (either by importing from PIL or using patched  
copies as needed) to figure out what a given image file type is, and  
where in the file the pixels are stored. Then the relevant region of  
the file would be passed through python.zipfile/deflate/etc. if needed  
to decompress the pixels, and sent to numpy for unpacking the bits  
from the string.

I think this isn't the perfect solution for everyone: it doesn't use  
external libs, so it will be a bit slower and won't support all the  
strange corners of the format specifications (which PIL doesn't  
either). Also JPEG will be hard to support. But what this would be is  
a very light-weight python-and-numpy image reader with no external  
dependencies, which has merits.

Zach