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

[Bill Bumgarner]

two more points:

1) Because, obviously, fully optimized ANSI C will always be faster than =
python for execution of tight calculation loops and such-- and, of course, =
tight calculation loops are the nuts and bolts of image processing, it =
would be *extremely useful* to have a C API that is *even easier to use* =
than the pre-existing python C API for building image processing modules.

I'm thinking of something that allows one to basically build filter =
function of a given API-- that API would include the buffer to be =
processed [and, potentially, an output buffer if the image is to NOT be =
processed in place] and some kind of a structure containing any =
configuration information as propagated by the python object set.

Now-- why would it be desirable to create Yet Another API?  Well;  two =
reasons-- the first is that image processing [actually,  data processing =
in general-- there is little reason why a similar framework could not be =
used for, say, video processing or audio processing] is a specialized set =
of problems that require a relatively specialized set of tools.  By =
creating a Highly Refined API for building data processing tools, we yield =
an environment in which the developer with lots of experience creating =
image processing tools-- but little experience with general programming-- =
can effectively utilize the environment to greatly augment their toolbox.

The second reason is that the existing Python API-- while relatively easy =
to use for the EXPERIENCED developer-- is too large and confusing for most =
developer's to effectively use.  Seriously;  I have had *lots* of =
experience developing OO software (over 10 years now) and there are two =
basic development paths [wow, the quantity 2 seems to recurr throughout =
this message];  the first is the easy path-- using existing Objects to =
create whole new frameworks for doing useful things (typically, by =
creating a class that inherits from the root class-- this class acts as a =
framework controller).  The second is much more difficult-- it involves =
creating new classes and extending exisiting classes to provide an object =
framework that is *designed for the use of a developer*... the second is =
more difficult because the behaviour has to be well defined at the object =
level, not just at the UI level (yes, yes, I know-- UI level behaviour CAN =
be difficult;  but minor problems don't necessarily mean catastrophic =
failure...).

Python's existing extension API, while being relatively well written and =
designed, is definitely an API for *use by other hardcore developer's* and =
not for consumption by the inexperienced masses. =20

If we were to create a PIL ANSI Extension API, there is no reason why the =
developer cannot continue to use the existing Python API-- if so =
inclined-- but I see *a lot* of advantages to providing the lay-developer =
with an easy to use ANSI API that allows them to develop powerful data =
processing tools while removing *a large quantity* of rope with which to =
hang themselves.

2) in regards to Leffler's libTIFF;  i strongly disagree that a desirable =
solution would be to pull the useful decoding bits from Leffler's library =
and just use those.  This would incur MASSIVE down-the-road maintenance =
penalties-- every time Leffler releases a new version, the bits and pieces =
would have to be sucked from his code and integrated into the PIL... =
potentially hours of tedium per release with no real gain in the feature =
set (beyond the bug fixes provided by leffler).

By using his library directly-- ie; by linking (either dynamically or not) =
the python binary against libtiff and then implementing PIL on top of the =
additional API, we garner an environment that leverages all of the power =
of libtiff without reworking it. =20

Same goes for libjpeg [and libpng, if the png folks ever achieve a level =
of refinenment that doesn't require one to replace pieces of their code =
with per-platform code-- i think they have].

---

BTW:  I am Master of Data Decoding [mostly images, though it looks like =
sound and video will fall in my lap, as well] for a web browser targeted =
at the NEXTSTEP/OPENSTEP markets.  I have been down all three paths of =
using third party image processing software;  roll my own [GIF], integrate =
the useful bits of other's work [PNG], and simply leveraging off existing =
packages [TIFF, JPEG] -- the leveraging off of other's has really paid off =
[jpeg recently moved from version 5 to version 6-- my image decoder =
magically recognized all the new features of JPEG by simply re-linking;  i =
didn't have to change *any* of my code!].

b.bum=

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

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