<snipped lots of interesting discussion...> > I guess I would argue for what you refer to below, that the > functionality to read image formats should be decoupled, at least > initially, from the plotting (display?) package. In fact, initially > it may make sense just to use PIL for that functionality alone until > we understand better what really needs to be integrated into the > display package. (The main drawback of PIL is that it doesn't support > either Numeric or numarray, and Lundt isn't inclined to support > either unless either is part of the Python Standard Library. It > may turn out that we could add it to PIL, or extract from PIL > the image file support component for our purposes. I suspect that > that stuff is pretty stable). But initially, reading images into > arrays seems like the most flexible and straightforward thing to > do. Disclaimer: I surely don't understand all of the requirements for matplotlib imaging. I would also suggest PIL, sticking as much as possible to the pure-Python interface. I suggest this because some OSs (well, Mac OS X is what I'm thinking of) are supposed to have native image-handling routines which are fine-tuned to their hardware and unlikely to be beat by some multi-platform project. (For example, I've heard that Apple's PNG handling is faster and better than libpng.) If someone modified PIL to take advantage of these platform-specific features, we would reap the benefits. Then again, this argument assumes someone will someday do that. >> * As for raw pixel data, should we try to support >> grayscale/luminance, rgb and rgba with the platform dependent byte >> ordering problems, or leave it to the user to load these into a >> numeric/numarray and init the image with that? Should we follow >> PILs lead here and just provide a fromstring method with format >> strings? >> > I haven't given this a great deal of thought, but again, arguing > for simplicity, that the array representations should be simple. > For example, nxm dim array implies luminance, nxmx3 implies > rgb, nxmx4 implies rgba. The I/O module always fills the arrays > in native byte order. I suppose that some thought should be given > to the default array type. One possibility is to use Float32 with > normalized values (1.0=max), but it is probably important to keep > integer values from some image formats (like png). Floats give > the greatest flexibility and independence from the display hardware, > if sometimes wasteful of memory. The second type to support would be > UInt8 (I admit I could be stupidly overlooking something). I think the format string idea is a good one. An nxm dim array could be luminance, alpha, or possibly colormapped -- it's not necessarily known in advance what data type it is, although a guess would probably be right 99% of the time. I also vote use a floating-point representation whenever possible. It's clear that 8 bits per color aren't enough for many purposes. <snipped more interesting discussion...>