2009/10/5 Stéfan van der Walt
<stefan@sun.ac.za>
Hi Zach
2009/10/5 Zachary Pincus <zachary.pincus@yale.edu>:
>
>> You spent some time writing a replacement IO reader in pure Python, if
>> I recall correctly; did you have any practically usable results?
[...]
> That is, I think that one could write simple PNG and TIFF decoders
> (which do not support all the corners of the spec, but neither do
> those in the PIL) in pure python / numpy in a day or so. This would be
> useful for many people, but lacking jpeg would be a big issue. Perhaps
> we could grab just the C core of some jpeg decoder/encoder somewhere
> and use that?
libjpeg and libpng are both fairly easy to wrap with a couple of
cython / ctypes calls, so I might just do that at a next sprint.
Looking back at this conversation, I believe a plugin system would be
a practical solution that can be implemented right away. For example:
plugins (be it for PIL, CVD, Magick, etc.) are asked to load an image.
If a plugin fails because the format is not supported, it raises a
FormatError and the next plugin is used.
A plugin system sounds like a good idea. Maybe it needs a little more than waiting for a format error, because it is possible for a format to be supported but in a buggy way. Then you'd get back an array filled with garbage.
It should be possible for the user to specify the order in which libraries are tried, to exclude libraries completely, as well as easily register their own library as a plugin.
WIth a plugin system in place, we can later replace as much of the
functionality under the hood as we want, while having developed a
consistent interface that can be exposed to the user right away (via
imread).
Do you want a single function for everything, or different functions for single-page / multi-page images? Having to do something like:
img = open(fname)
img2d = imread(img)
img.seek()
img2d = imread(img)
img.seek()
would be less than ideal.
Anyway, a big thumbs up for a plugin system no matter what the interface will look like exactly.
Cheers,
Ralf