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

Sebastian Haase haase@msg.ucsf....
Mon Apr 21 03:19:59 CDT 2008


On Mon, Apr 21, 2008 at 9:38 AM, Stéfan van der Walt <stefan@sun.ac.za> wrote:
> On 21/04/2008, Zachary Pincus <zachary.pincus@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
>
Hi all,

please don't discuss ndimage and image file-IO (alas PIL) in the same thread !!!
the "image" in "ndimage" has nothing (!!) to do with jpeg or tiff
---- you might know this....

So, I summarize then from the recent discussion here,
  that PIL could be divided into consisting   of five parts:
a) file format handling based on external libs such as libjpg, libpng,
(not libtiff, I think, please confirm !!)
b) file format handling based on PIL's python code
c) image processing, such as contrast change, pixelwise mapping,
transformations like rotation, ...
d) image drawing, like addiong text into an image
e) image display

I like some of PIL's "d" features.
I don't use "e" at all (I have written my own OpenGL based 2d-section
viewer [BSD lic.])
(I think this is minimal tk code, and some "calling to external OS
viewer programs")
"c" should all be done using numpy ( + here is a connection to
ndimage, but don't dwell on it ...)
"a" might be harder to build, because of dependencies, but this is
also optional, and setup.py exists  (???)

"b" is mainly what is the "annoying" part where patches seem to get
stuck and lie unused.....

I hope you guys can agree with my summary -- now I'm waiting for comments ....

-Sebastian


More information about the SciPy-user mailing list