[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