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

[Sebastian Haase]

I got another question:
One nice thing about PIL is that I could just throw any image file at
it and it finds by itself the right format/plugin to load it.
Does FreeImage have a similar feature ?
 - i.e. determining the image format (not just depending on file name
extension would be quite important ...

- Sebastian



On Wed, May 12, 2010 at 11:25 PM, Zachary Pincus
<zachary.pincus at yale.edu> wrote:
>> - is there currently only one person behind FreeImage ?
> No idea...
>
>> - it seems there are some problems with 64 bit windows - apparently
>> related to inline assembly...
> Ugh, didn't notice that.
>
>> - the discussion group seems not very responsive / active -- might
>> also of course mean that it mostly "just works" ;-)
>> - the "who uses FreeImage" list seems really quite long - but then PIL
>> is probably also used by many ...
> Yeah, it doesn't seem to have a super-active community, but so far it
> seems to just work, which is OK for now, I hope.
>
> Not sure how clean the C code is, but going from the API at least
> someone has spent time thinking about making things clean and
> portable, etc., and hopefully maintainable. I think I'd rather hack on
> FreeImage's C guts than PIL's, but that's without any experience with
> the former.
>
>> How large is the DLL actually ?
>
> Win32 dll = 2.3 MB, OS X intel-only dylib (with debug symbols) = 2.9 MB.
>
> Not terrible.
>
> Zach
>
>
>> Thanks,
>> Sebastian
>>
>>
>> On Wed, May 12, 2010 at 7:10 PM, Zachary Pincus <zachary.pincus at yale.edu
>> > wrote:
>>>> Do you know if FreeImage does anything via memory-mapping ? I'm
>>>> mostly
>>>> interested in TIFF-memmap, which exists according to libtif, but I
>>>> have now idea how useful it is .....  (I need memmap for GB-size
>>>> multipage images)
>>>
>>> I don't know a ton about how memmapping works, but check out these
>>> functions from FreeImage:
>>>
>>>> FreeImage_OpenMemory
>>>> DLL_API FIMEMORY *DLL_CALLCONV FreeImage_OpenMemory(BYTE *data
>>>> FI_DEFAULT(0), DWORD
>>>> size_in_bytes FI_DEFAULT(0));
>>>>
>>>> Open a memory stream. The function returns a pointer to the opened
>>>> memory stream.
>>>> When called with default arguments (0), this function opens a memory
>>>> stream for read / write
>>>> access. The stream will support loading and saving of FIBITMAP in a
>>>> memory file (managed
>>>> internally by FreeImage). It will also support seeking and telling
>>>> in the memory file.
>>>> This function can also be used to wrap a memory buffer provided by
>>>> the application driving
>>>> FreeImage. A buffer containing image data is given as function
>>>> arguments data (start of the
>>>> buffer) and size_in_bytes (buffer size in bytes). A memory buffer
>>>> wrapped by FreeImage is
>>>> read only. Images can be loaded but cannot be saved.
>>>
>>>> FreeImage_LoadFromHandle
>>>> DLL_API FIBITMAP *DLL_CALLCONV
>>>> FreeImage_LoadFromHandle(FREE_IMAGE_FORMAT fif,
>>>> FreeImageIO *io, fi_handle handle, int flags FI_DEFAULT(0));
>>>>
>>>> FreeImage has the unique feature to load a bitmap from an arbitrary
>>>> source. This source
>>>> might for example be a cabinet file, a zip file or an Internet
>>>> stream. Handling of these arbitrary
>>>> sources is not directly handled in the FREEIMAGE.DLL, but can be
>>>> easily added by using a
>>>> FreeImageIO structure as defined in FREEIMAGE.H.
>>>> FreeImageIO is a structure that contains 4 function pointers: one to
>>>> read from a source, one
>>>> to write to a source, one to seek in the source and one to tell
>>>> where in the source we currently
>>>> are. When you populate the FreeImageIO structure with pointers to
>>>> functions and pass that
>>>> structure to FreeImage_LoadFromHandle, FreeImage will call your
>>>> functions to read, seek
>>>> and tell in a file. The handle-parameter (third parameter from the
>>>> left) is used in this to
>>>> differentiate between different contexts, e.g. different files or
>>>> different Internet streams.
>>>
>>> With the first, I think you could just pass the void* pointer
>>> returned
>>> from memmapping a file; with the second, I think you could wrap a
>>> memmapped file with a file-like interface (implemented in python
>>> callbacks, even). Not sure, of course, if that will work OK... Might
>>> be easier to work with wrappers to libtiff directly?
>>>
>>> Zach
>>>
>>> _______________________________________________
>>> SciPy-User mailing list
>>> SciPy-User at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-user
>>>
>> _______________________________________________
>> SciPy-User mailing list
>> SciPy-User at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-user
>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>