imageio progress

[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


On 27 April 2013 23:10, Almar Klein <almar.klein at 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<https://bitbucket.org/almarklein/imageio/src/tip/imageio/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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scikit-image/attachments/20130505/7cb40129/attachment.html>