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

Bill Bumgarner bbum@friday.com
Wed, 20 Mar 96 16:02:10 -0600

Looks awesome;  a couple of pionts I would like to raise--   obviously, a =
lot of this is certainly outside of the scope of the 0.1 release and is =
not intended to be a complaint about lack of features.

for TIFF:

	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.  The licensing restrictions should be loose enough =
for the purposes of the PIL and the library builds on basically anything =
(as far as I know).
	Complete information can be found here:
for GIF:

	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.  =
Regardless of how much code can be recycled from said module, the gd =
library provides an excellent starting point for reading/writing GIF =
images-- and it also includes the ability to manipulate the images in =
interesting ways (which may be completely useless within PIL-- the API may =
be such that it violates the ongoing feature set of the PIL.
	Complete gd information can be found here (the server was down when I =
tried to connect at about 3pm central standard time):
interesting aside:

	Decoding and encoding the various image formats can be rather expensive.  =
For example, web sites that compose GIF images comprised of other GIF =
images on the fly incur a massive penalty;  every original image must be =
decompressed, and the resulting image must then be compressed.  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.  It is then very easy for the library to load and =
manipulate these files without incurring the additional cost of =
	Sounds like something that might be very useful within the PIL.
windowing stuff:

	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...  hopefully, that =
*fact* is obvious to everyone involved.  If not, I will happily explain =
*exactly* why this is true [in private email-- no need to trash the list] =
to anyone who disagrees...
	Yes, i'm a bit religious about this issue-- but that's because I wish to =
ensure that I can use the image processing module on *any* of the =
multitude of platforms I regularly use.
other image processing libraries:

	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.

hope SOME of this information is useful to SOMEONE,=09

IMAGE-SIG - SIG on Image Processing with Python

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