[PYTHON IMAGE-SIG] The PIL library -- specification for release 0.1

[Fredrik Lundh]

Bill Bumgarner have a lot of good points:

> Sam Leffler's [sp.] libTIFF package reads and writes basically any
> format of TIFF file imaginable-- including TIFF with JPEG compression
> through the use of the IJG code.

Yep, I'm well aware of this library, but the current plans for PIL are
definitely a bit more radical:

  The current PIL file drivers parses all headers and metadata in
Python code, leaving only the actual raster data to tiny codecs
written in C.  Since parsing TIFF is trivial, its more a matter of
providing codecs for the various compression variants.  PIL contains
quite a few in 0.1, libTIFF even more, so maybe snatching the
remaining libTIFF codecs might be wiser than integrating the library
itself.

(In addition, I don't really trust a library that claims there's such
a thing as native bit order :-)


> The gd library by Tom Boutell provides a relatively complete ANSI
> interface for manipulating GIF files.  If I remember correctly, some
> kind soul has already built a python module that wraps gd's
> functionality.

Have anyone looked into how this library is designed?  Creating a
graphics interface on top of the internal PIL raster storage format
would be a great idea (okay, hacking graphics is fun and not very
difficult, so I guess could I do most of it from scratch, if someone
finds me a good text package...).  Maybe Boutell's code could be used
as a base.


> Decoding and encoding the various image formats can be rather
> expensive. For example, web sites that compose GIF images comprised
> of other GIF on the fly incur a massive penalty; every original
> image must be decompressed, and the resulting image must then be
> compressed.

Hmm.  When it comes to relatively straightforward compression formats
like LZW, the above is not always true, depending on your CPU and disk
speeds (and the PIL code contains a brand new decoder implementation
that seems to be _very_ fast compared to most stuff out there).  On
the other hand, a well written server should of course be written in
Python, and cache PIL Image objects internally!


> Lib gd defines an interim file format that is basically a pure 24/32
> RGB bitmap with height/width information-- the file format is used
> to greatly accelerate all operations by storing all of the interim
> files in the generic format.

One advantage of PIL is that you get a lot of file formats wrapped in
a single architecture.  So we don't need to invent a new file format,
just use an appropriate existing one.  For this purpose, I guess PPM
would be a good candidate (and okay, PIL actually supports a distorted
version of of Pbmplus to handle RGBA, CMYK, YCC, LAB, and whatever)...


> It would be a horrible crime against the usability of the PIL to
> have any aspect of the PIL depend on any piece of the Tk stuff...

I wouldn't dare suggesting such a thing :-)

Display support (currently not in 0.1) include Tk "photo image" and
Windows DIB.  General X support requires a good deal more hacking, but
is far from impossible.  And isn't there some X stuff in Jack's img
library?


> Has anyone checked out the San Diego SuperComputing Center's Image
> Processing Library?  It ROCKS!
>
> Seriously, it implements *all kinds* of really useful image processing
> features-- including the ability to filter individual channels of
> various colorspaces... a great tool.

Interesting.  For PIL, the current plan is to rely on the Numerical
Python extension to provide stuff like FFT, convolutions, and lots of
other things.  Check the Matlab Image Toolkit for a good role model
here.  But simple, possibly file-based interfaces to stuff like the
above library, imgStar, Khoros, XITE, and others, could be really
useful.

Thanks	/F

(Hey? Still no GIS/RS folks here?)

=================
IMAGE-SIG - SIG on Image Processing with Python

send messages to: image-sig@python.org
administrivia to: image-sig-request@python.org
=================