[plt-scheme] 2htdp/image
I think this is a reasonable approach to images: by default, store
them in terms of drawing primitives (so rotation, scaling, etc. work
nicely) but for display and some other purposes, "flatten" them to
bitmaps. It also makes sense to have two different equality
operators on images: do they have the same bit-map representation
right now, and would they continue to have the same bit-map
representation after rotation, reflection, scaling, etc?
So what should the drawing primitives be? The obvious base cases (to
me) are ellipses (filled or outline), polygons (filled or outline),
line segments, and bitmaps. And maybe text in a specified font. The
obvious operators, off the top of my head, are vertical and
horizontal concatenation, overlay (with translation), rotation,
reflection, scaling, and clipping. Concatenation is the composition
of an overlay and a translation. Conveniently enough, rotation,
reflection, translation, and scaling (as well as skewing) can all be
represented as matrix multiplication, and matrix multiplication (at
least in a pure, exact mathematical world) is associative, so any
SEQUENCE of rotations, translations, reflections, scalings, and skews
can be represented as a single matrix multiplication. Overlay, and
clipping to an arbitrary rectangular region aligned with the current
coordinate system, should be trivial (although they can't be
represented as matrix multiplication).
Now, about exactness. It would be nice if (reflect-horiz (rotate 72
(rotate 200 (rotate 88 (reflect-horiz blah))))) were exactly equal to
blah. If you represent rotation, reflection, scaling, and skewing by
matrix multiplication with floating-point matrix entries, it may not
be. On the other hand, if you represent each of these operations by
separate tree nodes even when they're in sequence, flattening (and
therefore displaying) becomes needlessly expensive, especially after
you've run an animation of a spinning star for a few minutes.
Obviously, images coming from photographs should by rights be
considered inexact, as should anything stored in a lossy format like
JPEG... and for display on a physical monitor, we don't need exact
images anyway. Why don't we just cut the Gordian knot and say that
ALL images and ALL functions on them are inexact, and you can't
reasonably rely on the equality I mentioned at the top of this
paragraph? At low magnification, they may turn out to have equal
bitmaps, just as the result of a floating-point computation may be
within a large delta of another floating-point value, but one would
no more expect exact equality on computed images than on computed
inexact numbers.
Most of what I've said above applies to 3-D "images" too, of course,
but that's another bucket of worms....
Stephen Bloch
sbloch at adelphi.edu