Mailman 3 October 2009 - scikit-image

So I just found out that PIL will load images from a memory buffer... we should have something like this as well...
by Chris Colbert Oct. 13, 2009

Oct. 13, 2009

I was trying to figure out last night how to get libjpeg to decode a jpeg which existed in memory, and write the decoded image to a memory buffer. I failed. The use case is this: I connect to a wireless video camera and make requests for image via HTTP GET. The image is sent in jpeg format as a stream of bytes which gets stored in a python buffer object. I need to convert this jpeg to an RGB numpy array. This turned out to be trivial to do with PIL and its file parser that accepts a stream of bytes. in essence: In [1]: import httplib In [2]: from PIL import ImageFile In [3]: import numpy as np In [4]: conn = httplib.HTTPConnection('www.therealstevencolbert.com') In [5]: conn.request('GET', '/dump/IMG_0408_rs.JPG') In [6]: r1 = conn.getresponse() In [7]: r1.status Out[7]: 200 In [8]: data = r1.read() In [9]: parser = ImageFile.Parser() In [10]: parser.feed(data) In [11]: img = parser.close() In [12]: img.show() In [13]: numpyimg = np.asarray(img) In [14]: numpyimg.shape Out[14]: (768, 1024, 3) In [15]: numpyimg.dtype Out[15]: dtype('uint8') This is incredibly valuable and I think we should consider adding such capability to scikits image. I'd even be willing to work on this after I'm done with the opencv stuff. Cheers! Chris

2 1

OpenImageIO
by Zachary Pincus Oct. 12, 2009

Oct. 12, 2009

Stéfan: > I wonder if we shouldn't take the plunge and add OpenImageIO as a > dependency? ... > - Supported on Linux, OS X, and Windows. All available under the BSD > license, so you may modify it and use it in both open source or > proprietary apps. > > > I really don't have much hope for PIL. The development process is > closed and slow. Once you ignore your community, you are pretty much > done for. The only reason PIL still exists is because it is useful, > but let's face it: we can easily rewrite 80% of its capabilities at a > multi-day sprint. Perhaps we should. The only downside to OpenImageIO is that it has some not-always- standard dependencies, such as boost and cmake (neither of which mentioned in the build instructions), which make it a bit tricky to install, at least from an end-user perspective (especially as a replacement for PIL, which is just a "python setup.py install" away). The situation on Windows is also not super-simple. Perhaps a streamlined build could be shoehorned into distutils (but the boost thing is still a bit of a pain)... Any thoughts on this matter? I think it looks like a great library, and it would be great to have some ctypes wrappers for it, but I'm not sure how simple a dependency it will wind up being, especially given that they don't have platform binaries available yet for OpenImageIO... Zach

6 31

ok to require PIL for tests?
by Chris Colbert Oct. 11, 2009

Oct. 11, 2009

For writing tests for our functions, it would be easier to include in the test directory a series of images representing modifications to a master image. This obviously requires imageIO, so is it ok to use PIL for this? or should I store the images as binary .npy files instead? -Chris

2 2

opencv stuff now on github
by Chris Colbert Oct. 11, 2009

Oct. 11, 2009

I've made a fork on github to work on the opencv stuff: http://github.com/sccolbert/scikits.image I've also made a pull request to Stefan so the initial stuff will be available in the trunk. A large portion of the infrastructure is now in place with regards to array validation and utility functions. I think theres now enough to start aggressively wrapping functions. I haven't figured out a good way to build these modules yet. Making a setup.py causes Cython compilation to fail on the .pyx files, but using cython *.pyx and then compiling the .c files manually with gcc works fine... So it may be easiest in the future to just have the maintainer cythonize the .pyx and .pxd files, and only ship the .c sources, then have distutils build the c files. Cheers, Chris

2 5

great news with regards to OpenCV support...
by Chris Colbert Oct. 9, 2009

Oct. 9, 2009

At least I think it is great! I've managed (with the help of the community) to get ctypes function pointers to play nice with cython. I've also re-implented the IplImage struct in cython and figured out how to populate the struct with numpy stride information and the numpy data pointer. This all means that we now have the ability to to call OpenCV functions with plain numpy arrays as arguments, and the array gets modified in place!. And since i'm using ctypes to grab the function handle, OpenCV is not required to be on the users machine during build time, but if and when they install the opencv lib, they automagically work! I've a got a working (albeit ugly) example attached. You'll obviously need opencv installed if you want to test it. Just use PIL to open any image on your system then dump it into a numpy array then call testnumpy.test(arr) on that array. Dump the array back into a PIL image and call show() on it. Voila! your image has been guassianed blurred courtesy of OpenCV. So, now that I have the logistics of this figured out and I know it actually works, looks like I'll have plenty to implement during the upcoming sprint. Cheers! Chris

5 10

Fwd: ANN: SciPy October Sprint
by Stéfan van der Walt Oct. 7, 2009

Oct. 7, 2009

Hi all, I hope some of you will join me for the SciPy sprint on the 24th/25th to make some further progress on the image processing scikit. Looking forward to it! Cheers Stéfan ---------- Forwarded message ---------- Date: 2009/10/7 Subject: ANN: SciPy October Sprint To: SciPy Developers List <scipy-dev(a)scipy.org> Hi all, Our patch queue keeps getting longer and longer, so here is an opportunity to do some spring cleaning (it's spring in South Africa, at least)! Please join us for an October SciPy sprint: * Date: 24/25 October 2009 (Sat/Sun) * More information: http://projects.scipy.org/scipy/wiki/SciPySprint200910 We are looking for volunteers to write documentation, review code, fix bugs or design marketing material. New contributors are most welcome, and mentoring will be available. See you there, Regards Stéfan

1 0

How to Contribute to scikits.image: Task List
by Stéfan van der Walt Oct. 7, 2009

Oct. 7, 2009

Hi all, I've made available instructions on how to contribute, as well as a list of tasks, available at http://stefanv.github.com/scikits.image/contribute.html Please send these along to any colleague, student, friend, etc. who may be willing to help out. Thanks! Stéfan

1 0

Fwd: OpenImageIO
by Damian Eads Oct. 5, 2009

Oct. 5, 2009

Ed Rosten meant to send this to everyone so I'm forwarding this. ---------- Forwarded message ---------- From: Edward Rosten <edward.rosten(a)gmail.com> Date: Mon, Oct 5, 2009 at 10:33 AM Subject: Re: OpenImageIO To: Damian Eads <eads(a)soe.ucsc.edu> On Sun, Oct 4, 2009 at 1:17 AM, Damian Eads <eads(a)soe.ucsc.edu> wrote: >> I downloaded both ImageMagick and CVD earlier this evening and started >> to compile both. ImageMagick completed fairly quickly, but CVD seems >> to take extremely long (could be a platform/compiler specific issue, >> I"m not sure. Are they making heavy use of templates?). > > It's not a template issue in this case. The FAST corner detector, > which compiles by default in LIBCVD, requires a lot of memory and > computation. To disable, try ./configure --disable-fast7 > --disable-fast8, --disable-fast9. This should greatly speed up > compilation. There are some compiler specific issues. Quite a few from the gcc 3.x series failed to compile the code at all (getting stuck in an infinite loop or failing entirely with an internal error). GCC 4.0.x and 4.1.x are pretty slow with this code. The more recent iterations of 4.x work well. By the way, the makefile supports parallel builds flawlessly, which speeds things up a great deal. The entire thing compiles on 30 seconds on a fast, single socket computer. >> We could >> look at extracting the IO part of CVD or ImageMagick to keep things >> light-weight. > > Could do. LIBCVD is pretty lightweight and much smaller than OpenCV. It is possible, not that hard even. Due to the amount of generic code in libCVD, once you have the image IO and video loading (with the requisite colourspace conversion code), you will have most of the compilable source code. This step wouldn't save you very much over all. Much of the remaining code is in templates, so it won't add anything unless you try to instantiate specific algorithms. If you are still concerned about the extras, then I could put an option in configure to compile only the image IO part, or we could figure some other way of making it work. Although the build system is quite monolithic, the library itself is very modular. I think it would be worth trying to prevent fragmentation if possible, since it makes maintenance, feature enhancements etc easier. > For example, there aren't high-level systems like face detectors in > LIBCVD nor will there ever be. LIBCVD just contains basic data > structures (an Image and ImageRef class), basic image/video loaders, > and easy-to-use, highly optimized image processing operators. Its > interface is designed to be functional rather than object-oriented. I would like to add that libCVD will stay this way. -Ed -- (You can't go wrong with psycho-rats.) (http://mi.eng.cam.ac.uk/~er258) /d{def}def/f{/Times findfont s scalefont setfont}d/s{11}d/r{roll}d f 2/m {moveto}d -1 r 230 350 m 0 1 179{1 index show 88 rotate 4 mul 0 rmoveto} for /s 12 d f pop 235 420 translate 0 0 moveto 1 2 scale show showpage -- ----------------------------------------------------- Damian Eads Ph.D. Candidate University of California Computer Science 1156 High Street Machine Learning Lab, E2-489 Santa Cruz, CA 95064 http://www.soe.ucsc.edu/~eads

1 0

Re: OpenImageIO
by Ralf Gommers Oct. 5, 2009

Oct. 5, 2009

On Sun, Oct 4, 2009 at 4:39 AM, Gary Ruben <gary.ruben(a)gmail.com> wrote: > > Re, IO, has anyone looked into any of the binary file parser libraries > for Python? > For example, there's pyffi, construct and bdec. > Pyffi http://pyffi.sourceforge.net/ looks to me like the best > candidate if this approach was to be considered and it's BSD licensed. > The advantages are that this approach should be robust against faulty > files, there's a gui file editor, it provides access to all the file > contents (not just the image planes) and it may provide a nice general > way to read more general (non-image) binary files in numpy. A possible > disadvantage is that it doesn't take advantage of any of numpy's > binary file machinery so it may be slower, but maybe this could be > improved. It's not clear whether specifying the file format with > something like this makes life easier, but I thought I'd put it out > there. > > With binary machinery do you mean memmap? I thought that that only helps you when the file does not fit in memory. Other than that numpy only has save/load which uses a very simple format for saving/loading ndarrays. > Construct may be worth a look, but I can't see any license info. > http://construct.wikispaces.com/ > > No activity there in 18 months it seems. Another project that looks good is Hachoir http://bitbucket.org/haypo/hachoir/ . These binary parsers seem like they make it easier to add new file formats, however none of them have parsers for image formats yet so it would be a lot of work. Cheers, Ralf

2 1

BSD license in scikits.image
by David Warde-Farley Oct. 4, 2009

Oct. 4, 2009

Hey Stefan, Curious - what happened to the 3rd clause of the BSD license in the LICENSE.txt in Scikits.image? This is the one I'm talking about: * Neither the name of the <organization> nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. ^-- That one. I think it's a pretty important one, no? Implicit protection from people using any contributor's name re: the software without permission. (note that this isn't the "advertising clause" that people sometimes talk about being removed from the BSD license, that was "All advertising materials mentioning features or use of this software must display the following acknowledgement" and is a bad, bad rule for many reasons). Cheers, David

2 1

What kind of language limitations (if any) do we want to place on implementations??
by Chris Colbert Oct. 4, 2009

Oct. 4, 2009

i.e. Do we want to standardize how we will implement the functionality in the Image Kit or are we free to use whatever tools we are familiar with? Personally, I do most performance related stuff with Cython, so are we ok to require Cython as a build dependency? Or would we rather limit things to python and the C api only? I guess this kind of similar to the discussion on dependencies, but still maybe deserves its own attention... Cheers, Chris

4 5

Documentation page
by Stéfan van der Walt Oct. 3, 2009

Oct. 3, 2009

Hi all, Just a reminder that the docs for the scikit are online at http://stefanv.github.com/scikits.image/ You may generate these docs from the source tree by changing into the `doc` dir and doing `make html`. The output is then located in `build/html`. Sphinx 1.0 is required. Regards Stéfan

1 0

Projective transformations
by Stéfan van der Walt Oct. 3, 2009

Oct. 3, 2009

Hi all, Please review the code for projective transformations / homographies at: http://github.com/stefanv/scikits.image/commit/927157e7e508efbb0628f3e1f77b… Regards Stéfan

1 0

Re: [SciPy-User] How to create multi-page tiff files with python tools?
by Stéfan van der Walt Oct. 2, 2009

Oct. 2, 2009

Apologies, this message was meant for the scikits-image list. Please continue discussions there. 2009/10/3 Stéfan van der Walt <stefan(a)sun.ac.za>: > 2009/9/30 Ralf Gommers <ralf.gommers(a)googlemail.com>: >>> I think the problem is that Frederick Lundh is the only one who has >>> permission to add/change code base. >>> I still find it very suspicious that somewhere on the PIL website it >>> states that you can pay (a lot of money) for a "special license" to >>> get early access to the development version - so even you are >>> providing (free) patches via the mailing list, you would have to pay >>> to get access to the patched version !? >>> A couple months ago I asked for an explanation but didn't get a reply. >>> >> Yeah that is very odd. An attempt to put the I/O part of PIL in a scikit may >> be enough of a push to improve that situation. The only other important >> Python library I can think of that was this inert is setuptools, and look >> what happened there. > > I wonder if we shouldn't take the plunge and add OpenImageIO as a dependency? > > Here's the list of features (from their website): > > - Extremely simple but powerful ImageInput and ImageOutput APIs for > reading and writing 2D images that is format agnostic -- that is, a > "client app" doesn't need to know the details about any particular > image file formats. Specific formats are implemented by DLL/DSO > plugins. > > - Format plugins for TIFF, JPEG/JFIF, OpenEXR, PNG, HDR/RGBE, Targa, > JPEG-2000, BMP, and ICO formats. More coming! The plugins are really > good at understanding all the strange corners of the image formats, > and are very careful about preserving image metadata (including Exif, > GPS, and IPTC data). > > - An ImageCache class that transparently manages a cache so that it > can access truly vast amounts of image data (thousands of image files > totaling hundreds of GB) very efficiently using only a tiny amount > (tens of megabytes at most) of runtime memory. Additionally, a > TextureSystem class provides filtered MIP-map texture lookups, atop > the nice caching behavior of ImageCache. > > - Supported on Linux, OS X, and Windows. All available under the BSD > license, so you may modify it and use it in both open source or > proprietary apps. > > > I really don't have much hope for PIL. The development process is > closed and slow. Once you ignore your community, you are pretty much > done for. The only reason PIL still exists is because it is useful, > but let's face it: we can easily rewrite 80% of its capabilities at a > multi-day sprint. Perhaps we should. > > Regards > Stéfan >

1 0

Re: OpenCV?
by Stéfan van der Walt Oct. 2, 2009

Oct. 2, 2009

Hi Chris 2009/10/2 Chris Colbert <sccolbert(a)gmail.com>: > I have since been wanting to get back to working on the wrapper, but > I've been toying with the idea of instead of just wrapping the OpenCV > array type and providing functions to convert to and from numpy > arrays, to use a numpy array as the base data type (perhaps through > subclassing or a hidden attribute; i havent yet decided) and > dynamically creating/updating OpenCV array headers that point to the > numpy data. I think this approach would be more natural and pythonic > (at a small cost for speed). It would also eleminate the need to wrap > the entire opencv library as simple manipulations can just be done > with numpy or scipy.ndimage I am not familiar with the OpenCV array type, but if it addresses contiguous memory, this should be fairly easy to achieve by adding an array interface. The is basically how we are capable of reading PIL arrays these days. An alternative approach would be to write the converter you describe, using this trick suggested by Travis Oliphant: http://blog.enthought.com/?p=62 Thanks for contributing! Regards Stéfan

2 1

Re: OpenCV?
by Carlos da Silva Santos Oct. 2, 2009

Oct. 2, 2009

I have no experience with OpenCV but I saw that OpenCV 2.O (released last week) has a new python interface. From what I could tell, they are using a custom wrapper generator (i.e no swig, ctypes or cython): http://opencv.willowgarage.com/wiki/PythonInterface Cheers, Carlos On Fri, Oct 2, 2009 at 2:03 PM, Chris Colbert <sccolbert(a)gmail.com> wrote: > > I actually started work on an OpenCV wrapper using Cython a couple of > months ago. I got about 25% complete but then got busy with other > things. I was real carefully about releasing the GIL whenever possible > to make multi-core usage a reality. In some basic tests, the > performance was on par with using opencv from pure C (more or less). > > I have since been wanting to get back to working on the wrapper, but > I've been toying with the idea of instead of just wrapping the OpenCV > array type and providing functions to convert to and from numpy > arrays, to use a numpy array as the base data type (perhaps through > subclassing or a hidden attribute; i havent yet decided) and > dynamically creating/updating OpenCV array headers that point to the > numpy data. I think this approach would be more natural and pythonic > (at a small cost for speed). It would also eleminate the need to wrap > the entire opencv library as simple manipulations can just be done > with numpy or scipy.ndimage > > I have some free time now again, and I could ramp back up my work on > this or perhaps merge the work into this project if the devs show > interest. > > You can take a look at the current code here: > > http://code.google.com/p/cython-opencv/ > > Cheers! > > Chris > > On Sep 25, 11:21 am, Stéfan van der Walt <ste...(a)sun.ac.za> wrote: >> 2009/9/25 Damian Eads <e...(a)soe.ucsc.edu>: >> >> > Have you considered LIBCVD as an alternative to OpenCV? It is highly >> > optimized for frame-rate real-time applications but also has a nice, >> > succinct, simple (almost pythonic) syntax. >> >> What is the feature scope of CVD compared to OpenCV? >> >> Stéfan

2 1

OpenCV?
by Mike Sarahan Oct. 2, 2009

Oct. 2, 2009

Sorry if I missed this in discussions at the sprint, but is there any reason we're not taking advantage of OpenCV? It may be a little more than what this scikit is aiming to offer, but it has some really nice, well-optimized routines. It's BSD licensed. I have been using the ctypes-opencv python wrapper, which is also BSD licensed. Yes, it's another dependency, but it's really easy to get - Ubuntu & Fedora have packages, binaries are readily available for Windows, and it has built easily on my OSX system. If you guys think it's something worth including, I can work on getting the wrappers integrated with the scikit. -Mike

4 4

Finite Radon Transform implemented
by Stéfan van der Walt Oct. 1, 2009

Oct. 1, 2009

Hi all, Thanks to a beautiful patch by Gary Ruben, the 2-D Fast Radon Transform is now included in the master branch: http://github.com/stefanv/scikits.image/commit/e003726de26de276dc07bb2ac4fc… Thank you, Gary. Enjoy! Stéfan

2 1