Hi all, I've been meaning for a long time to look into cobbling together some non-broken, maintainable (e.g. non-PIL) image IO library that can deal with scientific (16-bit and floating-point) image formats. I finally bit the bullet yesterday and whipped together a ctypes wrapper for the FreeImage library. (FreeImage is portable and largely if not entirely dependency-free; Windows binaries are available and it compiles cleanly on os x as well as other unixes: http://freeimage.sourceforge.net/ Check out the manual: http://downloads.sourceforge.net/freeimage/FreeImage3131.pdf , particularly the appendix that shows the supported image types and pixel formats: pretty impressive. Also note that there is a "FreeImagePy" project that has ctypes wrappers for FreeImage, but the code is... idiosyncratic... and doesn't interface with numpy anyway.) The underlying library and wrappers I wrote support reading and writing of greyscale, RGB, and RGBA images with 8- and 16-bit int/uint and 32-bit float pixels, as well as greyscale images with 64-bit float and 128-bit complex pixels. (The TIFF spec supports all of these, at least, as does FreeImage, but most other TIFF readers probably don't. The PNG format itself is a bit more limited, but FreeImage can read/ write everything in the spec, I think. Most other formats are 8-bit only.) Multipage image IO is also supported, and there's currently a bit of support for reading EXIF tags, which could easily be beefed up. The wrapper code is pretty compact and straightforward, and the FreeImage library seems pretty robust and simple (once one notes that it uses BGRA ordering on little-endian systems). Overall I feel a lot better about using this than dealing with PIL and its broken memory model and worse patch-acceptance track record. If anyone wants to test the wrappers out, I'll send you the code. Going forward, I'll look into getting this into the scikits image IO system, but I don't really have free cycles for that right now. Zach PS. FreeImage is dual licensed: GPL and a "FreeImage license", the latter of which I have no idea if is BSD compatible -- it says it's "less restrictive" than GPL but I'm unable to parse the license's many clauses. In any case, as long as users are required to provide their own FreeImage dll/so/dylib, it's not really a problem.