At 2002-02-27 01:07, Ketil Z. Malde wrote:
-- probably elsewhere in the hierarchy class FileFormat a where encode :: a -> [Word8] decode :: [Word8] -> a
instance FileFormat PNG where encode = ... decode = ..
I prefer ML-style structures/functors in this particular instance: data FileFormat a = MkFileFormat { encodeFile :: a -> [Word8], decodeFile :: [Word8] -> Maybe a }; formatPNG :: (Image img) => FileFormat img; formatJPEG :: (Image img) => JPEGCompressionFactor -> FileFormat img; formatUTF8 :: FileFormat String;
class Image a where rotate :: a -> Int -> a scale :: a -> Int -> Int -> a
Maybe compose/blend images? Altering alpha and gamma, color manipulation?
Sounds like a serious project, with the possibility of plenty of complication. -- Ashley Yakeley, Seattle WA
Ashley says:
Ketil says:
class Image a where rotate :: a -> Int -> a scale :: a -> Int -> Int -> a
Maybe compose/blend images? Altering alpha and gamma, color manipulation?
Sounds like a serious project, with the possibility of plenty of complication.
I agree with Ashley - surely we're not trying to write *new* libraries, we're just trying to better organise the existing ones. The two options that spring to mind are 1. not having a shared Image type or class at all (just types PNG, GIF, JPEG, etc) and/or 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). Then someone can write general rotation / scale / compositing etc routines if they feel like it (maybe stealing ideas/code from the pnm* utilities?). --KW 8-)
Keith Wansbrough
I agree with Ashley - surely we're not trying to write *new* libraries, we're just trying to better organise the existing ones.
1. not having a shared Image type or class at all (just types PNG, GIF, JPEG, etc)
I think that is a good choice, since otherwise you need to make some decisions that bring you into new-libraries territory. Conversion between formats would probably be useful, though, perhaps one could FFI to ImageMagick or something? ISTR the Amiga having a library called DataType or something. This would automatically convert data types from a library of conversion routines, so that if you wrote a program to read TIFFs, it could apply the appropriate routine to read BMPs as well. Or something like that. It seems to me that some of this functionality is the domain of a type system - can it e.g. be achieved with a generic 'fromImage' function? -kzm -- If I haven't seen further, it is by standing in the footprints of giants
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/
participants (4)
-
Alastair David Reid -
Ashley Yakeley -
Keith Wansbrough -
ketil＠ii.uib.no