OpenImageIO

Chris Colbert sccolbert at gmail.com
Sat Oct 3 18:11:31 EDT 2009


I agree that the core functionality should not have dependencies. And
I feel that IO falls under this core functionality. So if we choose an
existing library for IO, I think it should be statically linked.

So then it becomes a questions of which of the existing libraries
would it be easiest to separate out the IO code in order to statically
link.

I'm not familiar with other libraries, but all IO functionality is
performed with libhighgui in opencv. This includes all video IO as
well... and also some basic routines for creating minimal gui windows
and widgets.

-Chris

2009/10/3 Stéfan van der Walt <stefan at sun.ac.za>:
>
> 2009/10/3 Chris Colbert <sccolbert at gmail.com>:
>>
>> but then again, if we want to include anything from OpenCV we might as
>> well use that imageIO because it supports quite a bit as well..
>
> This is an important issue that we should clarify: "general" vs.
> "specific" dependencies.
>
> With a "general" dependency, I refer to a library that developers are
> encourage to use throughout the scikit code.  If OpenCV is chosen as
> such a library, we can use its image loading, processing, vision etc.
> routines.
>
> On the other hand, a specific dependency states that only a certain
> function depends on, for example, OpenCV.  We could say: "If you want
> to execute optical_flow(...) you'll have to have OpenCV installed."
>
> With a general dependency, code becomes inextricably intertwined, and
> you won't be able to get rid of the dependency without invasive
> surgery.  A specific dependency is much more easily removed.
>
> My personal feeling is that we should stay away from general
> dependencies, if possible.  I don't intend for scikits.image to become
> a wrapper around libcvd or opencv -- those wrappers already exist.
> Rather, I want to focus on implementing novel image processing
> techniques that are not easily available elsewhere.  [Of course, if a
> function is easy enough to implement and useful for general purpose
> image processing (such as the color conversion routines), there's
> little reason to exclude it.]
>
> So, for image reading, I'm OK following a path such as:
>
> 1. Attempt to use ImageMagick
> 2. Not found, attempt to use PIL
> 3. Try built-in png reader (we can adapt matplotlib's)
> 4. Give up
>
> I'd like to hear your further opinions regarding dependencies.
>
> Thanks
> Stéfan
>



More information about the scikit-image mailing list