Re: imageio progress

24 views
Skip to first unread message

Almar Klein

unread,
May 4, 2013, 7:56:54 PM5/4/13
to scikit...@googlegroups.com, ima...@googlegroups.com
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


On 27 April 2013 23:10, Almar Klein <almar...@gmail.com> wrote:

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
 


 

Reply all
Reply to author
Forward
0 new messages