On 12 May 2010 23:16, Zachary Pincus <zachary.pincus(a)yale.edu> wrote:
> Hi all,
>> I'm definitely interested, having had several nightmarish attempts at
>> making PIL play nice with my 16-bit TIFF data. I don't have a ton of
>> spare time myself right now, but I'd like to give it a shot.
> Wrappers attached. Currently, they try to load "FreeImage.[dll|dylib|
> so]" (depending on the platform) from the same directory as the
> module. This is of course easy to change.
I converted your wrappers to plugins for scikits.image. At the
moment, it still segfaults---could you help me to iron out the
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.
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.
as I'm using both Python/Scipy and image processing in my daily
work, I would be interested in contributing to the image scikit if I can
be of any help.
I have read the "Contribute" page of the website, and maybe the
easiest way to start me off would be that I write some documentation and
tests. But please tell me if you have other suggestions, I do not have
specific preferences. The only thing is that I have almost never used
Cython, but I'm willing to learn it.
By the way, I had trouble installing the scikit as with my
Ubuntu-packaged version of Cython (0.11) I got lots of errors (such as
Buffer types only allowed as function local variables") and I had to
install Cython 0.12 to make it work. I can provide the whole log if you
expected the install to work with Cython 0.11.
In the longer term, I could also contribute two algorithms that I
have implemented in Python (with dependencies to numpy and scipy):
* the circular Hough transform (for 2-D images) that may be used to
* a "random walker" segmentation algorithm that implements a recent
generic algorithm by L. Grady [Random walks for image segmentation, Leo
Grady, IEEE Trans Pattern Anal Mach Intell. 2006 Nov;28(11):1768-83]. The
algorithm basically finds the region into which given markers
preferentially diffuse, with an anisotropic diffusion that penalizes
diffusion across strong gradients. I use it to segment huge (500x500x500)
3-D tomography images that are very noisy and full of artifacts and the
results are quite satisfying (much better than what I can get with a
watershed, for example).
But I think it is wiser that I first get to know the project by
contributing to existing parts of the scikit.
Let me know how I can help.