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/_plugi... 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@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
Also, can anyone explain decide the FreeImage Public License is compatible with skimage? Maybe it would be possible to provide some pre-built binary libraries for win/os x. http://freeimage.sourceforge.net/license.html On Dec 13, 2011, at 11:54 AM, Zachary Pincus wrote:
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/_plugi...
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@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
On Tue, Dec 13, 2011 at 9:03 AM, Zachary Pincus <zachary.pincus@yale.edu> wrote:
Also, can anyone explain decide the FreeImage Public License is compatible with skimage? Maybe it would be possible to provide some pre-built binary libraries for win/os x. http://freeimage.sourceforge.net/license.html
I think we should be fine. The two relevant items are: 3.1. Application of License. The Modifications which You create or to which You contribute are governed by the terms of this License, including without limitation Section 2.2. The Source Code version of Covered Code may be distributed only under the terms of this License or a future version of this License released under Section 6.1, and You must include a copy of this License with every copy of the Source Code You distribute. You may not offer or impose any terms on any Source Code version that alters or restricts the applicable version of this License or the recipients' rights hereunder. However, You may include an additional document offering the additional rights described in Section 3.5. 3.7. Larger Works. You may create a Larger Work by combining Covered Code with other code not governed by the terms of this License and distribute the Larger Work as a single product. In such a case, You must make sure the requirements of this License are fulfilled for the Covered Code. We do not place any restrictions on the code, so I believe we are compliant. Stéfan
On 12/13/2011 8:54 AM, Zachary Pincus wrote:
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.
FWIW, writing numpy arrays to TIFF files can be done in pure Python in less lines than the GPL license. Reading is more complicated, just because there are so many options, extensions, and broken files out there. No single library handles them all. Christoph
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/_plugi...
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@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
participants (3)
-
Christoph Gohlke -
Stéfan van der Walt -
Zachary Pincus