[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).
=09
Complete information can be found here:
=09
ftp://ftp.sgi.com/graphics/tiff
=09
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.
=09
Complete gd information can be found here (the server was down when I =
tried to connect at about 3pm central standard time):
=09
http://www.boutell.com/gd/
=09
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 =
decompression.=20
=09
Sounds like something that might be very useful within the PIL.
=09
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...
=09
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.
=09
other image processing libraries:
Has anyone checked out the San Diego SuperComputing Center's Image =
Processing Library? It ROCKS!
=09
Seriously, it implements *all kinds* of really useful image processing =
features-- including the ability to filter individual channels of various =
colorspaces... a great tool.
=09
ftp://ftp.sdsc.edu/pub/sdsc/graphics/imtools
hope SOME of this information is useful to SOMEONE,=09
b.bum=
=================
IMAGE-SIG - SIG on Image Processing with Python
send messages to: image-sig@python.org
administrivia to: image-sig-request@python.org
=================