README for tkmorph

Written and Copyright (C) 1996 by Michael J. Gourlay

This is my attempt at writing a morphing program using the TCL/Tk
library.

--=--

NOTE about the module containing the main routine:

I don't feel like writing my own main since it's just a generic
wrapper for the Tcl_InitApp routine, and that wrapper seems to be the
most operating system dependant part of any Tk code.  So I just take
the appropriate routine straight from the Tk distribution and add a
single line, which is a call to tkMorphInit.

Also, the MS Win version needs this "TkConsole" hack so I explicitly
include those routines from the Tk distribution, and all of the
header files they reference.  Perhaps in future versions of tkmorph
I'll remove the console window, since it will be superfluous.  For
now, it provides a good debugging and test tool.


--=--

NOTE about image formats and Tk:

Tk provides a way of extending the "Photo Image" format so that more
file types can be read in.  Also, Tk provides a way of creating
entirely new image types.  These might seem like a reasonable way to
write tkmorph:  Either add more photo image formats, or create a new
type.

Neither of these options is reasonable for me.  The photo image type
is insufficient because it lacks an alpha channel.  I thought about
asking the author of the photo image type to add an alpha channel
which could be ignored by people who didn't want to use it, and then
I would have all of the power of the photo image type to use for
xmorph.  But I looked at the code for the photo image format, and he
stores the images in an interleaved way, i.e. the red, green, and
blue channels are adjacent bytes.  To add an alpha channel would
require adding a whole new member to his data structure, since X
can't easily handle having another byte in the way.  Maybe if he were
using the Z-Pixmap storage scheme (which I have never used myself),
perhaps it would be easier to add an alpha channel, but that woudl
require rewriting a lot of code, and I don't think this guy wants to
do that just for me.  Also, it's far more useful for me to store the
images with each channel having all of its data contiguous instead of
interleaved, because then I can treat each channel as a monochrome
image, and the image manipulation routines are easier to write that
way.  So if I were to use the photo image type, I'd have to convert
back and forth between interleaved and non-interleaved every time I
wanted to use an image.

Adding a new image type isn't worth th effort.  There's way too many
things to deal with.  I thought about just using the photo image type
as a template, but the photo image type is far more versatile than I
want to use.  Also, I don't really care about giving the world yet
another image type because an image type with an alpha channel is
probably not going to have a very large audience.

I decided to hack around all of this.  I'm going to use the photo
image type to display my images (and even to load in image formats
that don't have alpha channels anyway).  I'll use converters to go
back and forth between photo images and my own "RGBA" scheme.

The appropriate thing to do, given infinite time, is to partially
create a new image type with an alpha channel.  But then I would
still want to write a converter to go between photo and RGBA because
then I'd be able to use all of the photo image format code without
rewriting it for the RGBA format, and I'd be able to use the photo
image display scheme.  There's probably no reason to write my own
display methods for the RGBA type since most machines aren't going to
have a simple way of using the alpha channel anyway, and the photo
image type handles dithering for non-true-color machines in a fairly
nice way.  Plus it does gamma correction on the fly.  I don't want to
rewrite all of that code.

So, given that the converters would have to be written either way, the
only practical issue is that of whether I conform to the presribed Tk
way of dealing with image, i.e. adding another full-blown image type.
But whether I add another image type or not, a lot of the code would
be the same anyway, so I might as well keep it simple and just use
explicit converters.  Then, if an RGBA image type acquires more uses
(say for image processing) then I'll write it when it comes up.


--=--
