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/