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

[Fredrik Lundh]

lot's of traffic on the image sig...

david> Also, FYI, a new release is promised for tomorrow (Friday),
david> which makes me doubt F/'s claim of a vacation =).

Well, I was away from work yesterday (almost).  but the PIL
release might be somewhat delayed -- our local internet provider
messed up their DNS servers, and our website host has messed up
their NFS servers, so I cannot upload the new PIL just yet.  they've
promised me that everything will work again later tonight.  sigh.

...

in the meantime, here are some comments...

eric> A couple of documentation bugs

Interesting.  The PIL docs has been unchanged for about a year,
and suddently three people reports the "Enchance" typo within
two days!

I've changed that; the rest will be taken care of in the next
documentation update.

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.  All these might
be debatable, but I think changing it would cause as much confusion as
keeping it as it is.

eric> I announced this to a group that included Guido.  He steered me to
eric> PIL.  PIL is very impressive

We're pretty impressed ourselves -- people have built some really
awesome applications on top of PIL... (if my old bosses had known
how many commercial applications people have built on PIL, they
wouldn't have allowed me to give it away...  on the other hand,
they've using it themselves, so they shouldn't complain ;-)

eric> so much so that I think it will enable
eric> me to officially declare the utilities in GIFLIB obsolete (but not the
eric> library; that's a separate issue to which I'll return below).

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).

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).

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...

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).

(PIL already supports a few other RLE formats, btw).

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.

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.

More font info below.

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.

eric> 6. I see no standard function or method for composing multiple images into a
eric> multi-file image in formats like GIF.  (The gifovly utility in GIFLIB
eric> 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.

The seek/tell methods that can be used to read multiple-frame formats
are documented (they work for at least GIF, FLI/FLC, and TIFF, plus the
lesser known ARG and IM formats).  Also see the ImageSequence module.

To write GIF animations, you can import "gifmaker" and use the
"makedelta" method on a list of images.  See the source for details.

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).

eric> 7. (Serious) There doesn't seem to be any way to specify interlacing or the 
eric> 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.

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).

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.

...

Now to the remaining points on Andrew's wishlist:

andrew> * There are other font rendering solutions such as t1lib and
andrew>pilfont.  t1lib seems too large to add to PIL, but maybe pilfont can
andrew>be added.

the pilfont stuff is included in 0.3b1.  This includes the pilfont "compiler",
and the upgraded ImageFont module.

andrew> * Freetype support
andrew> * t1lib

Fred's written a t1lib interface, and I'm waiting for someone (you know
who you are!) to release his freetype interface...  when that's out, and
I find some spare time, I'll try to come up with a unified raster font
interface.  It would include:

    -- a font registry
    -- a font selection mechanism (something similar to tkFont,
       most likely)
    -- some optimizations in PIL (the current ImageFont implementation
       is pretty gross...)

andrew> * Clean up and document the SANE interface (my job).

The current release is shipped with 0.3b1; it would be great to have
the updated interface in time for the final 0.3 release (nudge, nudge)

...

More wishes:

kevin> How about additional file formats like YUV, UYVY.

Is this the SGI flavour?  There appears to be no shortage of formats
calling themselves YUV -- and they all use different resampling and
colour weights...

PIL 0.3b1 adds direct support for YCrCb (the JFIF flavour: CCIR 601-1
without chroma headroom).  It can also read PhotoYCC via the PCD
decoder.  Other YUV versions can be read as RGB, and converted via
the matrix option to the convert method (see the manual for details).

Anyway, if you have specs and samples for the SGI version, just
send them to me, and I'll add support if I can.

kevin> Or using ImageMagick to convert to formats PIL can understand.

Zach Roadhouse has written an ImageMagick interface for Python,
which includes a PIL interface.

    http://starship.skyport.net/crew/zack/pymagick/
    http://starship.skyport.net/crew/zack/pymagick/#pil

hannu> Could we have compressed GIF's as well ?
hannu> To circumvent the Unisys LZW patent, we could do as xpdf
hannu> does: unix command compress + some converion code ?

PIL reads compressed GIF files.  The Ghostscript folks have researched
this, and all the experts they consulted claimed that Unisys' LZW patent
cannot prevent you from doing this (on the other hand, most experts
claim that Unisys' patent is moot anyway since IBM also happens to have
a patent on the same thing...  and on the third hand, Unisys' LZW patent
isn't valid in Sweden anyway ;-).  Also note that you can disable all kinds
of LZW support via the WITH_LZW option in _imaging.c.

When writing GIF files, PIL uses a simpleminded encoding that, by some
odd reason, LZW decoders have no trouble reading.  To write compressed
GIF files, there are a number of options:

    -- install NETPBM, and hack GifImagePlugin so it uses _save_ppm instead
       of _save (just remove "_ppm" from the latter).
    -- write an _imaging_gif module that takes a PIL image and writes
       a GIF version of it.  how you implement that is up to you...

Unfortunately, I don't think you can use compress to write GIF files; most
compress implementations use something called "deferred clear codes" to
get better compression.  This is explicitly allowed by the GIF specification,
but nobody seems to get that right.  For example, Navigator 2 and 3 bombs
if you give them such files (don't know if it's fixed in version 4).  FWIW,
Internet Explorer has always handled them just fine, though...

richard> Unfortunately, the PNG implementation in PIL is bare-bones,
richard> and I'd remedy that if I had the time (which I will do soon,
richard> but it's just one thing on a list...). 

What do you have in mind here?  The only thing I can think of is that the
current implementation doesn't support interlaced PNG's (patches are wel-
come).  What else have I missed?

dirk> Once there was a discussion about replacing the fromstring and
dirk> tostring method. I would like to have a method which doesn't
dirk> convert the image to/from strings, but passes a pointer (or pointer
dirk> list). The NumPy library (don't know how it is done exactely) has
dirk> methods to do this, and it would be nice to have an efficient
dirk> access to image data from other python modules like NumPy.

Hey, I didn't know that Python had support for pointers ;-)

I don't use NumPy myself (I have colleagues that do, but they haven't
told me about that feature -- maybe they haven't looked close enough).
Can any NumPy guru explain this?  For example, it would be trivial
to add a method that returns a list of long integers, each pointing
to the beginning of a line.  For small images, there's actually a way
to do this today:

        im.load()
        ptr = im.im.isblock()

If ptr is non-zero, it's a pointer to the first byte in the image memory.

...

that's all for today.  now I'm off to see armageddon.  the PIL sources
might make it to our site later tonight.  stay tuned.

Cheers /F