I have some comment below but would like to first make some general observations. Certainly I am not the expert on image processing but I have now spent a week or 2 on PIL. I know others have spoken in favor of PIL (I think Jason Grout and maybe some others) and that motivated me to spend some time writing this module. I do think the module will be of use to those who want to use or learn PIL in the context of Sage. I worked on it thinking that with it, PIL could be made a standard part of Sage. However, I am no longer convinced that this is the best idea. I'm still thinking about this issue, so can't say anything definitive at the moment, but from what little I know, I think VIPS might be a better alternative (http://www.vips.ecs.soton.ac.uk/index.php?title=VIPS). The library is LGPL, and the size of the sourve is about 3M. Also, it is faster than the other open source alternatives according to one set of tests http://www.vips.ecs.soton.ac.uk/index.php?title=Speed_and_Memory_Use Therefore, I think VIPS should be looked into further. Also, the VIPS binary (and NIPS, the associated GUI) is available for many common linux distributions.
There is nothing wrong with PIL and it provides good basic functionality. However, I think I will look into VIPS more carefully before making a definite recommendation about what to include with Sage, as far as image processing goes. See below for more comments. On Sun, Jul 5, 2009 at 9:05 PM, David Joyner<[email protected]> wrote: > Hi: > > I'm working on a user-friendly, intuitive interface to PIL and have some > questions. Before preparing a patch, I was hoping that members of this > group would suggest ways to proceed. > > Here is what I've done so far: in the module pil.py, posted to > http://sage.math.washington.edu/home/wdj/patches/pil.py I have updated this file. > there are wrappers for PIL methods which will implement > autocontrast > blend > convert > crop > various filters (sharpening, for example) > roll (shift the pixels, with wrapping) > text , > among others. These are all implemented as functions. > The docstrings require a few image test files, > http://sage.math.washington.edu/home/wdj/patches/pil-test-image1.png > http://sage.math.washington.edu/home/wdj/patches/pil-test-image2.png > (photos of mine which I placed in the public domain) > > To test this module out, you can (for example) (a) create > a clone, (b) copy it to sage/interfaces, (c) copy the png files > somewhere on your computer, (d) start Sage and > type from sage.interfaces.pil import *. The paths in the docstrings need to > be modified to the paths you placed the png files in. > > Questions: > > 1. Where should this module go? In sage/interfaces? I decided it and the png test files should go in sage/media. > > 2. Should I create up a "wrapper class" for PIL (say, "class > PILimage(SageObject):"?) > and copy the wrapper functions (mentioned above) to methods of it? I decided against this. > > 3. Should I provide an interface with Graphics objects? In other words, > instead of providing a raster image (such as pil-test-image.png) > to create an instance of the PILimage class, once could also > provide and instand of the Graphics class. (I don't know how to do > this right now, but am wondering on what others thing of this idea.) If no one has an opinion on this then I won't do it. It is not clear how useful it would be. > > 4. Should I interface also with pyglet classes? (Pyglet is included with > sympy, hence with sage, and does some very very basic "image > processing".) Again, I don't know how this would be done... I decided against this. > > Thanks in advance for any feedback. > > - David Joyner > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
