imageio progress

[Almar Klein]

Dear all,

Several months ago, I decided to take the code for skimage's freeimage plugin (which was originally written by Zach Pincus) and turn it into a stand-alone library. I discussed with Zach and a few others how to proceed with that, and it seemed that time was a limiting factor for many, so I ended up doing most coding on my own.

The project is called imageio and it is now a plugin-based library with a relatively small core. The freeimage plugin that started it all currently provides most file formats. Its now at a stage where I think the core is pretty much finished, and focus can shift towards different plugins for various scientific formats. But I am not going to do that alone :)

I could use some help with:

  * People just trying it out.

  * People checking the design of the classes and plugin system.

  * If possible, people checking out the code a bit.

  * And of course, people writing plugins!

The way I see it, imageio can become a common backend for reading and writing images for several libraries (including skimage), or can function stand-alone.

Further, I plan on moving it to github to easier attract developers.

Any help and comments is much appreciated,

  Almar

[Ralf Gommers]

Hi Almar, this looks interesting. I'm not really working with images anymore, but was tempted to try imageio out anyway. Installation was smooth, and the 16-bit TIFF image I tried loaded just fine (where PIL still chokes). So in it's current form I suspect it's already quite useful for some people.

I haven't looked in enough detail to be able to comment on the classes/plugin design.

An option to use imageio.imread/imsave (and/or skimage.io.imread/imsave) as an alternative to PIL from scipy.misc.imread/imshow would make sense to me.

Cheers,
Ralf

[Stéfan van der Walt]

Hi Almar

On Wed, Mar 27, 2013 at 4:33 PM, Almar Klein <almar...@gmail.com> wrote:
> The project is called imageio and it is now a plugin-based library with a
> relatively small core. The freeimage plugin that started it all currently
> provides most file formats. Its now at a stage where I think the core is
> pretty much finished, and focus can shift towards different plugins for
> various scientific formats. But I am not going to do that alone :)

Is there a way to add plugins by simply "dumping" plugin files into
place? This was part of the thinking when we designed the skimage.io
plugin infrastructure (so it would be easy for, e.g., Debian to add
new formats by simply unpacking into the right location).

I am not entirely happy with the complexity of the io module in
skimage, and would love to hear ideas about how it can be simplified,
perhaps integrating with imageio.

Stéfan

[Juan Nunez-Iglesias]

I wrote a lot of image io stuff for my own projects before I became aware of skimage. I spent some time thinking about how people could add and maintain their own modules, and came up with the following:

io/

    __init__.py

    tiff.py

        read()

        write()

    png.py

        read()

        write()

etc. This isn't coded, it was just on my todo. Adding new formats is then a matter of dumping in a file containing read() and write() functions, and importing that in the __init__.py file. This results in very clean syntax:

io.png.read()

There could also be io.read() and io.write() defined in __init__ or some generic name, e.g. io.auto.read(), that would call the right format based on filename.

Thoughts?

--
You received this message because you are subscribed to the Google Groups "scikit-image" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Stéfan van der Walt]

Hi Juan

On Sun, Apr 21, 2013 at 5:50 PM, Juan Nunez-Iglesias <jni....@gmail.com> wrote:
> io.png.read()

That is a very clean abstraction. It doesn't quite cover our use-case
of supporting multiple readers for the same format, but then I also
don't know if that is ideal.

We could make these things explicit:

import skimage.io.matplotlib as skio

skio.imread(...)

At the moment, we support either matplotlib, freeimage, pil, or
whatever is around on the system to do the job. I guess the __init__
could try and import plugins until it finds one that works.

Stéfan

[Juan Nunez-Iglesias]

On Mon, Apr 22, 2013 at 7:46 PM, Stéfan van der Walt <ste...@sun.ac.za> wrote:

It doesn't quite cover our use-case of supporting multiple readers for the same format, but then I also don't know if that is ideal.

I don't know either. ;)

I noticed that you used multiple plugins, but I haven't been a fan. I think, as you suggested, that the user shouldn't have to worry about these things unless he wants to. So, use a default backend, whatever we think is best for each format. Then, if the user wants to use a specific one, he can write (for example):

io.png.set_backend('PIL')

This'd be interesting to engineer I bet. =)

[Almar Klein]

Is there a way to add plugins by simply "dumping" plugin files into
place?  This was part of the thinking when we designed the skimage.io
plugin infrastructure (so it would be easy for, e.g., Debian to add
new formats by simply unpacking into the right location).

I am not entirely happy with the complexity of the io module in
skimage, and would love to hear ideas about how it can be simplified,
perhaps integrating with imageio.

The way in which this is currently implemented in imagio is that each plugin module implements a Format class (with associated Reader and Writer classes), and registers an instance of this Format class with the imagio format manager:

    format = FormatDefinedInThisModule('dummy', 'An example format that does nothing.')
    imageio.formats.add_format(format)

For a more complete example see plugins/example.py. In effect, plugins can be defines anywhere, also in 3d party packages. The plugins/__init__.py simply imports has one line of code per plugin to import it. 

You/we could extend it and make plugins/__init__.py search the whole directory and import all found modules. I've done similar things in visvis, but in retrospect I prefer explicitly importing the modules (also less trouble with e.g. freezing). But perhaps the use case that you described justifies such an approach.

Adding new formats is then a matter of dumping in a file containing read() and write() functions, and importing that in the __init__.py file. This results in very clean syntax:

Imagio currently does something similar. A plugin (or format as its called in imageio) must implement three classes: Format to describe meta information about the format (name, short description and docs), as well as functionality to determine whether a given file(name) can be read/written by the format or not. Reader and Writer are overloaded classes used to read and write image data. They should implement a specific set of methods, but may also implement additional methods in cases it makes sense to complement the default interface.

When the user tries to read an image (e.g. using imageio.imread()) the format manager picks the first format that says it can read the data, and uses an instance of its Reader class to do the reading. Alternatively imagio.read() gives the user an instance of the Reader class for more control. If the user wants to use a specific format he/she can use imageio.imread(filename, format=X), where X can be the name of a format, its extension, or a Format instance.

... perhaps integrating with imageio.

I took imageio out of skimage because I think that reading/saving images is useful to many people that do not necessarily need skimage. But I was indeed hoping for some form of integration with skimage. 

Also, I'm hoping that imageio can be a place to place functionality for reading specific formats (such as TIFF or .mhd (ITK)). An environment such as github should make it fairly easy for multiple people to maintain their own plugin in a collaborative repository.

- Almar

 

 

[Almar Klein]

I just moved imageio to github. Anyone who has an interest in collaborating in this project, please let me know so I can give you write access.

- Almar

[Stéfan van der Walt]

On Sun, May 5, 2013 at 1:56 AM, Almar Klein <almar...@gmail.com> wrote:
> I just moved imageio to github. Anyone who has an interest in collaborating
> in this project, please let me know so I can give you write access.

I can highly recommend working via pull requests. This has made such
a big difference to the skimage development process, that I can't even
imagine developing without it now.

Stéfan