[SciPy-user] The IO library and image file formats -- compare with with PIL

[Stéfan van der Walt]

On 21/04/2008, Zachary Pincus <zachary.pincus at yale.edu> wrote:
>  > I would really try and avoid the forking route, if we could.   Each
>  > extra dependency (i.e. libpng, libjpeg etc.) is a potential build
>  > problem, and PIL already comes packaged everywhere.  My changes can
>  > easily be included in SciPy, rather than in PIL.  Could we do the same
>  > for yours?  Then we could rather build scipy.image (Travis' and
>  > Robert's colour-space codes can be incorporated there, as well?) on
>  > top of the PIL.
>
>
> Nothing should be built "on top" of PIL, or any other image IO
>  library, IMO. Just build things to work with numpy arrays (or things
>  that have an array interface, so can be converted by numpy), and let
>  the user decide what package is best for getting bits into and out of
>  files on disk. Any explicit PIL dependencies should be really
>  discouraged, because of that library's continued unsuitability for
>  dealing with scientifically-relevant file formats and data types.

I agree with you, but we still need to provide the user with an easy
way to access images on disk (SciPy comes pretty much batteries
included).

>  My thought was thus to take the pure-python file-sniffing
>  part of PIL and marry it to numpy tools for taking in byte sequences
>  and interpreting them as necessary. This would be have no library
>  dependencies, and really wouldn't be a "fork" of PIL so much as using
>  a small amount of non-broken PIL file-format-reading code that's there
>  and abandoning the awkward/broken byte-IO and memory-model. I can't
>  promise I have any time to work on this -- but I'll look into it,
>  maybe -- and if anyone else wants to look into it as well, I'm happy
>  to provide some code to start with.

How would this code be used in practice?  I'm just trying to form a
mental image of how the parts fit together.

>  A major difficulty with ndimage, beyond the hairy C-code, is the
>  spline-interpolation model that nearly everything is built on. While
>  it's technically a nice infrastructure, it's quite dissimilar from
>  what a lot of people (well, especially me) are used to with regard to
>  how image resampling systems are generally constructed. So that makes
>  it a lot harder to hack on or track down and fix bugs. I don't really
>  have a good suggestion for addressing this, though, because the spline
>  model is really quite nice when it works.

I have the article on which this is based (I think?).  It is

"Splines: A Perfect Fit for Signal/Image Processing" by Michael Unser
(http://citeseer.ist.psu.edu/unser99splines.html)

The irony is that we have something like three or four spline
implementations in SciPy!  We should re-factor that into a standard
location, but as you can imagine it is no small task.

Regards
Stéfan