[Image-SIG] Re: Your wish is my command (long)

[Eric S. Raymond]

Fredrik Lundh <fredrik@pythonware.com>:
> eric> I think the PIL documentation's use of the term `band' is rather
> eric> unfortunate.  To a native English speaker, the term `band' applied to
> eric> a graphic has a strong primary meaning which is different from PIL's;
> eric> that of a stripe or region (especially a horizontal one) extending the
> eric> full width of the image.  
> 
> Well, the term "band" is actually take from an ISO 12087, which AFAIK is
> the only international standard discussing image processing libraries...
> there's a few other historical things in PIL, including the name "mode" for
> the pixel format, the string "L" for greyscale images, etc.

That explains it.  ISO 12087 was probably composed in French.  I bet you
that `band' is a literal translation of a French word by someone who didn't
know what a connotative mess he was making.  Please don't propagate this
error.

>                                                             All these might
> be debatable, but I think changing it would cause as much confusion as
> keeping it as it is.

Depends on whether you think your "market" is mostly English-speaking.
If so, I would strongly recommend "band" -> "channel".
 
> Are you going to write a new set of utilities based on PIL, or will
> you abandon GIFLIB completely?  The reason I'm asking is that some of
> the missing stuff should probably be implemented on top of the existing
> functionality, rather than added to the core library (I don't mind shipping
> such utilities with PIL, of course).

What I'm planning (and have in fact already started writing) is a Python script
called `pildriver' which allows the user to specify a pipeline of PIL image
transformations by specifying command-line switches.

The intention is that it should take an image stream on stdin and emit an
image stream on stdout.  Usage like this:

	pildriver <lena.jpg -i -r 140,160 -e

Emit Lena, inverted and then resized to (140,160) and enhanced.

This one tool would replace most of the GIFLIB utility set.  And yes, I think
it belongs in your distribution, documented, in order to support batch
processing of images.

Implementation problem: I don't see how to read an image from a file stream
object.  ImageFileIO isn't documented and I can't find the code.

> eric> Allow an optional argument in show() specifying the viewer
> eric> command to use.
> 
> I'll do something about this in the next release (not 0.3b1).

Actually I have another show method change for you.  For pipeline-construction
purposes, automatically backgrounding the image display is not the right
thing.  So:

--- Image.py	1998/07/10 05:25:57	1.1
+++ Image.py	1998/07/10 16:34:05
@@ -823,7 +823,7 @@
 # --------------------------------------------------------------------
 # Unix display support
 
-def _showxv(self, title = None):
+def _showxv(self, background=0, title=None):
 
     if self.mode == "P":
 	file = self.convert("RGB")._dump()
@@ -835,4 +835,7 @@
     else:
 	opt = ""
 
-    os.system("(xv %s %s; rm -f %s)&" % (opt, file, file))
+    command = "xv %s %s && rm -f %s" % (opt, file, file)
+    if background:
+        command = "(%s)&" (command,)
+    os.system(command)

> eric> 1. No ability to display images using (a) the Borland BGI driver,
> eric> (b) an Epson printer, (c) a Hercules graphics card.  I think we
> eric> can safely write these off as obsolete, however.
> 
> Last time I wrote a Hercules driver was ten years ago.  We had
> trouble finding a card testing it on...

OK, we can agree to forget this.

> eric> 2. No ability to handle RLE (Utah raster toolkit) images.  I'm not
> eric> too worried about this, either.  Is anybody still using it?
> 
> andrew> * RLE format support
> 
> Well, show me anyone using the Utah RLE format (or the Utah
> raster toolkit, for that matter).  If you find anyone, tell him/her
> to send me some samples and a spec, and I'll see what I can do...
> 
> (afaik, the Utah stuff is about as obsolete as the Hercules mono-
> chrome graphics adapter).

You're probably right.  As I said, I'm not going to worry about it.
GIFLIB dates from '89; I started maintaining it around '91.  There's
a lot of stuff in there that's now only of historical interest.
 
> eric> 3. No equivalent of the gifbg, gifwedge, and gifcolor test pattern
> eric> generators.  These would probably be trivial to write.
> 
> andrew> * Test pattern generators
> 
> There's one undocumented generator available in the Image module:
> 
>     im = Image._wedge()
> 
> This generates a 256x256 greyscale wedge.  Use convert, resize,
> and rotate/transpose to process it anyway you want.
> 
> There's in fact a few more generators in the libImaging code; see
> the Fill.c and Effects.c sources for details.  Still haven't made up
> my mind on how/if those should be exposed...
> 
> The other patterns provided by GIFLIB should be pretty straight-
> forward to implement using the ImageDraw module.  Best done
> in a utility.

I agree.
 
> eric> 4. (Serious) I see no way to overlay text on an image.  I can supply a
> eric> clean 8x8 font and code for ImageDraw to overlay messages on an image
> eric> using it.  Later this method could be extended to support fonts from
> eric> an X font server.  Is this sort of thing what the missing ImageFont
> eric> module is about?
> 
> Yep.  Todays 0.3b1 release includes the "pilfont" package which contains
> converters for PCF and BDF raster fonts.  See the sources for details.

Which brings up a question.  Why aren't docs included with the PIL
distribution?  The only docs I've found are the (incomplete) PIL
web pages.

> eric> 5. (Serious) There's no equivalent of the `clip complement' feature in
> eric> giflclip.  Here's the GIF description:
> 
> andrew> * Complement: cutting out strips of an image
> 
> Well, it takes about five lines of code to implement this (one new,
> followed by four crop/paste operations).  So again, I don't think PIL
> needs to be modified.  Better done in a utility.

OK, I can live with this.
 
> eric> 6. I see no standard function or method for composing multiple images
> eric> into a multi-file image in formats like GIF.  (The gifovly utility in
> eric> GIFLIB does this.)
> 
> andrew> * Support for multiple-frame images should be documented;
> andrew>there are some demo scripts in Scripts/ (gifmaker.py, explode.py) but
> andrew>they're not very well-known.
> 
[...]
> Adding a general mechanism that works with more formats is harder;
> the best way is to redesign the save plugin interface (there's other
> reasons for this), but there's no way to do that in time for 0.3 final.
> Maybe in 0.4 (aka 1.0).

Yes, I'd figured this out myself.  It's not an immediate issue for me, but
I'm glad to know it's on the to-doi list.
 
> eric> 7. (Serious) There doesn't seem to be any way to specify interlacing
> eric> or the  screen size on GIF output (GIFLIB's gifinter and gifpos
> utilities).
> 
> I just added interlace write support; it's in the 0.3b1 release.  If you
> have the time, patches for screen size (and other relevant options)
> would be welcome.

I'll look into that once I get the new release.

> eric> 8. No utility to section an image into tiles (gifburst).
> 
> eric> 9. No equivalent of my icon2gif utility (see 
> eric>   http://www.tuxedo.org/~esr/giflib/doc/icon2gif.html
> eric>).  Never mind, this is very GIF-specific.
> 
> Shouldn't be hard to write utilities for these (crop/paste are your
> best friends).

True.

> eric> If I hack in some of these things, can I stimulate a PIL release to
> eric> replace GIFLIB?
> 
> If you do it as a set of utilities, I'll ship them with the next release.
> If there's anything you want to change in the core library, let's discuss
> that case for case.

OK, what I'll do is put together pildriver for the next release.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

According to the National Crime Survey administered by the Bureau of
the Census and the National Institute of Justice, it was found that
only 12 percent of those who use a gun to resist assault are injured,
as are 17 percent of those who use a gun to resist robbery. These
percentages are 27 and 25 percent, respectively, if they passively
comply with the felon's demands. Three times as many were injured if
they used other means of resistance.
        -- G. Kleck, "Policy Lessons from Recent Gun Control Research,"