skeletonize question

[Zachary Pincus]

> Your wrapper is read-only, right?  Any sense on how much work to make
> it able to write some of these formats, as well?

Nope, read-write, with basic handling for multipage files (read-write also), though I've only tested this with TIFFs.

FreeImage supports a ton of image formats (read and write), all of which should work via the wrappers I wrote:
http://freeimage.sourceforge.net/features.html

Moreover, the library supports read/write for most of the exotic pixel types supported by some file formats. See the appendix of the documentation PDF for a full list of filetypes/pixel-types supported:
http://freeimage.sourceforge.net/documentation.html

Of specific interest for scientific imaging, pretty much every numpy dtype can be read/written in TIFF format, including signed/unsigned ints (8/16/32) and floats (32/64), and even complex too, for what that's worth. PNGs support greyscale/RGB/RGBA for uint8/16, and JPEGs support greyscale/RGB uint8. 

Filetype-specific compression options are selectable via IO flags. There's also rudimentary support in my wrappers for reading strings from image metadata (which I use for getting the info out of OME-TIFF files). This could easily be beefed up.

Overall, FreeImage is a decent little library, with a reasonably clean API. I tried to keep the ctypes wrappers as simple and thin as possible:
https://github.com/scikits-image/scikits-image/blob/master/skimage/io/_plugins/freeimage_plugin.py

There's a lot more functionality of FreeImage than is currently exposed, but this is a pretty good start.


Zach



On Dec 13, 2011, at 10:45 AM, Thouis (Ray) Jones wrote:

> On Tue, Dec 13, 2011 at 16:09, Zachary Pincus <zachary.pincus at yale.edu> wrote:
>> On Dec 13, 2011, at 5:23 AM, Thouis (Ray) Jones wrote:
>>> Having fought this fight far too many times, I'm beginning to think
>>> there's a need for a simple, small, and fast python module wrapping
>>> libtiff, libpng, and libjpeg and talking to numpy.  This would handle
>>> 90% or more of everyone's needs and would hopefully be simpler to
>>> install and use than PIL (and would have a faster development cycle).
>> 
>> That's why I wrote that FreeImage backend... But maybe asking people to get libfreeimage (lightweight and dependency-free as it may be) is harder than ensuring they have libs tiff, png, and jpeg?
> 
> This is probably good enough.  I admit we never tried this option with
> CellProfiler.
> 
> Your wrapper is read-only, right?  Any sense on how much work to make
> it able to write some of these formats, as well?
> 
> Ray