[SciPy-user] The IO library and image file formats -- compare with with PIL
Mon Apr 21 08:12:48 CDT 2008
> 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
(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.
More information about the SciPy-user