[SciPy-User] FreeImage <-> numpy IO wrappers

[Zachary Pincus]

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.