Graphics hierarchy

[Alastair David Reid]

> 2. having a basic type RawImage which is just an array of pixels
> (maybe you need RawBitImage, RawGreyImage, RawIndexImage,
> RawRGBImage) which all the various formats can convert to and from,
> adding their various extra information (resolution, copyright,
> palette, etc).

The EXIF format (http://www.pima.net/standards/it10/PIMA15740/exif.htm)
might provide some hints as to what extra information people usually add.

I know nothing about the spec though except that it's what my camera
uses to record shutter speeds, etc. and that the spec (from that URL)
is a scary 172 pages long (so we should use it as a source of ideas
not as something we want to support in full).

> Then someone can write general rotation / scale / compositing etc
> routines if they feel like it (maybe stealing ideas/code from the
> pnm* utilities?).

A fine idea - in fact just sucking in the pnm libraries would take us
most of the way there.

One thing to watch though: there are good reasons for having multiple
"raw" formats.  X11 users will be familiar with the need to process
bitmaps in the same byte order as the X server (essentially the
graphics card) prefers.  People using video cameras (e.g., the FVision
people at Yale and John Hopkins) are used to processing images in the
format that the video camera delivers (which is usually arranged to
match the video display).  You can't always afford to ignore this sort
of stuff - it's just too expensive to pull large amounts of data
through the memory hierarchy.

Which is to say: using one major in-memory format like pnm is a fine
goal, but expect to have to deal with others and plan acordingly.
e.g., consider using type classes, etc. instead of monomorphic
functions.

Also: while part of the FVision project
(http://www.cs.jhu.edu/CIRL/XVision2/), I greencarded some of their
image-processing code.  This does cool things like rotation,
subsampling, etc. for many different formats.  (Also interfacing with
video cameras and double buffering which are very cool but less
relevant to this thread.) And it does these very fast (the project is
concerned with real-time visual tracking) - often in carefully tuned
assembly code .  Once the primary format (pnm or whatever) is up and
running, it'd be worth sucking in their code too.  (The code is
released under a BSD-style license.)

Finally: HGL (and I suspect several other graphics libraries) already
contains routines to read and write bitmaps from a file.  It'd be
worth pulling these out into a separately maintained standard library
(or, rather, libraries since the Win32 bitmap reader is probably of limited
interest to X11 users and vice-versa).

-- 
Alastair Reid        reid@cs.utah.edu        http://www.cs.utah.edu/~reid/