From stefan at sun.ac.za Thu Oct 1 09:44:39 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 1 Oct 2009 15:44:39 +0200 Subject: Finite Radon Transform implemented Message-ID: <9457e7c80910010644s360f8660ka90ad8a58473fe30@mail.gmail.com> 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/e003726de26de276dc07bb2ac4fcfeed6493e17c Thank you, Gary. Enjoy! St?fan From gary.ruben at gmail.com Thu Oct 1 19:56:33 2009 From: gary.ruben at gmail.com (Gary Ruben) Date: Thu, 1 Oct 2009 16:56:33 -0700 (PDT) Subject: Finite Radon Transform implemented In-Reply-To: <9457e7c80910010644s360f8660ka90ad8a58473fe30@mail.gmail.com> References: <9457e7c80910010644s360f8660ka90ad8a58473fe30@mail.gmail.com> Message-ID: <937b1509-ba44-4ab5-b99b-49c96f06d48a@e4g2000prn.googlegroups.com> Hey, thanks for the (overly) kind words St?fan :) Gary On Oct 1, 11:44?pm, St?fan van der Walt wrote: > 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/e003726de26de276dc07bb... > > Thank you, Gary. > > Enjoy! > St?fan From sccolbert at gmail.com Fri Oct 2 10:03:05 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Fri, 2 Oct 2009 07:03:05 -0700 (PDT) Subject: OpenCV? In-Reply-To: <9457e7c80909250221lb72925i3d5f994cb17b8171@mail.gmail.com> References: <8275939c0909242134m2a3834ck2568540d5a2c382c@mail.gmail.com> <9457e7c80909242340p28fea9e2h8d788c859e8a7c4e@mail.gmail.com> <462e7fdf0909250144mdb1963emf532f6be21c90e14@mail.gmail.com> <9457e7c80909250221lb72925i3d5f994cb17b8171@mail.gmail.com> Message-ID: 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 wrote: > 2009/9/25 Damian Eads : > > > 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 From carlos.s.santos at gmail.com Fri Oct 2 10:21:46 2009 From: carlos.s.santos at gmail.com (Carlos da Silva Santos) Date: Fri, 2 Oct 2009 14:21:46 +0000 Subject: OpenCV? In-Reply-To: References: <8275939c0909242134m2a3834ck2568540d5a2c382c@mail.gmail.com> <9457e7c80909242340p28fea9e2h8d788c859e8a7c4e@mail.gmail.com> <462e7fdf0909250144mdb1963emf532f6be21c90e14@mail.gmail.com> <9457e7c80909250221lb72925i3d5f994cb17b8171@mail.gmail.com> Message-ID: <1dc6ddb60910020721m5f120d63lb8117b7daca746ee@mail.gmail.com> 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 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 wrote: >> 2009/9/25 Damian Eads : >> >> > 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 From sccolbert at gmail.com Fri Oct 2 10:35:19 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Fri, 2 Oct 2009 16:35:19 +0200 Subject: OpenCV? In-Reply-To: <1dc6ddb60910020721m5f120d63lb8117b7daca746ee@mail.gmail.com> References: <8275939c0909242134m2a3834ck2568540d5a2c382c@mail.gmail.com> <9457e7c80909242340p28fea9e2h8d788c859e8a7c4e@mail.gmail.com> <462e7fdf0909250144mdb1963emf532f6be21c90e14@mail.gmail.com> <9457e7c80909250221lb72925i3d5f994cb17b8171@mail.gmail.com> <1dc6ddb60910020721m5f120d63lb8117b7daca746ee@mail.gmail.com> Message-ID: <7f014ea60910020735k63325105od568fc95926a6b5f@mail.gmail.com> The new interface however, still requires that the person "learn" opencv. Since that wrapper is relatively complete (and i've heard actually quite good) I see know reason to have my wrapper wrap the entire library. So i thought it would be better if I changed its focus to be completely pythonic and work seamlessly with numpy. i.e. the user shouldnt need to know (or care) that the backend is opencv. Further, if I were to subclass ndarray, the only functions from opencv we would need to wrap, are the ones we want... and then the lib could be statically linked to eliminate the dependency... Chris On Fri, Oct 2, 2009 at 4:21 PM, Carlos da Silva Santos wrote: > > 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 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 wrote: >>> 2009/9/25 Damian Eads : >>> >>> > 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 > From stefan at sun.ac.za Fri Oct 2 18:14:48 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sat, 3 Oct 2009 00:14:48 +0200 Subject: OpenCV? In-Reply-To: References: <8275939c0909242134m2a3834ck2568540d5a2c382c@mail.gmail.com> <9457e7c80909242340p28fea9e2h8d788c859e8a7c4e@mail.gmail.com> <462e7fdf0909250144mdb1963emf532f6be21c90e14@mail.gmail.com> <9457e7c80909250221lb72925i3d5f994cb17b8171@mail.gmail.com> Message-ID: <9457e7c80910021514q5155da7dwd9d577fa0a93985a@mail.gmail.com> Hi Chris 2009/10/2 Chris Colbert : > 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 From sccolbert at gmail.com Fri Oct 2 18:18:12 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Sat, 3 Oct 2009 00:18:12 +0200 Subject: OpenCV? In-Reply-To: <9457e7c80910021514q5155da7dwd9d577fa0a93985a@mail.gmail.com> References: <8275939c0909242134m2a3834ck2568540d5a2c382c@mail.gmail.com> <9457e7c80909242340p28fea9e2h8d788c859e8a7c4e@mail.gmail.com> <462e7fdf0909250144mdb1963emf532f6be21c90e14@mail.gmail.com> <9457e7c80909250221lb72925i3d5f994cb17b8171@mail.gmail.com> <9457e7c80910021514q5155da7dwd9d577fa0a93985a@mail.gmail.com> Message-ID: <7f014ea60910021518w4a907881ybfd9647d1526a3e2@mail.gmail.com> not only does IplImage address contiguous array, it uses a strided model similar to numpy. It should be relatively trivial to have numpy be the storage and make it play nice with OpenCV libs. I will see if i cant get a small self contained example going over the next days and let you see what you think... Chris 2009/10/3 St?fan van der Walt : > > Hi Chris > > 2009/10/2 Chris Colbert : >> 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 > From stefan at sun.ac.za Fri Oct 2 19:19:51 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sat, 3 Oct 2009 01:19:51 +0200 Subject: [SciPy-User] How to create multi-page tiff files with python tools? In-Reply-To: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> Message-ID: <9457e7c80910021619n19799b41q210717304d6cb748@mail.gmail.com> Apologies, this message was meant for the scikits-image list. Please continue discussions there. 2009/10/3 St?fan van der Walt : > 2009/9/30 Ralf Gommers : >>> 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 > From zachary.pincus at yale.edu Sat Oct 3 13:25:13 2009 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Sat, 3 Oct 2009 13:25:13 -0400 Subject: OpenImageIO In-Reply-To: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> Message-ID: 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 From gary.ruben at gmail.com Sat Oct 3 22:39:33 2009 From: gary.ruben at gmail.com (Gary Ruben) Date: Sat, 3 Oct 2009 19:39:33 -0700 (PDT) Subject: OpenImageIO In-Reply-To: <9457e7c80910031753j7de77b25sbee99264bcbd9ecc@mail.gmail.com> References: <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <462e7fdf0910031336v124aad01j55cadff7edfdaaad@mail.gmail.com> <7f014ea60910031355r3b2400f7xac04bddf92012b2b@mail.gmail.com> <7f014ea60910031356te85f799y8cf2fb827dd7a64f@mail.gmail.com> <9457e7c80910031431s24d274b0kc7620d41cdb3d061@mail.gmail.com> <462e7fdf0910031547x1c8a9285l522014d1b6ab4945@mail.gmail.com> <9457e7c80910031649t77ed35cci2666a72247da7973@mail.gmail.com> <462e7fdf0910031717i4be995aax8dc3b0c84d87737c@mail.gmail.com> <9457e7c80910031753j7de77b25sbee99264bcbd9ecc@mail.gmail.com> Message-ID: <32044279-7985-4ae7-9e67-c38a3442c37b@h40g2000prf.googlegroups.com> 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. Construct may be worth a look, but I can't see any license info. http://construct.wikispaces.com/ There's also bdec, but it's lgpl'ed so not a candidate: http://www.hl.id.au/projects/bdec/ Gary On Oct 4, 11:53?am, St?fan van der Walt wrote: > 2009/10/4 Damian Eads : > > > Agreed, I don't think we want to replicate efforts to wrap existing > > libraries. However, I think rewrapping is acceptable if we offer a > > much simpler, functional interface than what has been done before. One > > of the reasons why MATLAB is so popular is its functional style and > > use of arrays to represent most data. If we can greatly reduce > > boilerplating then duplicating efforts may be worthwhile. > > Right on. > > > Yes, I still need to integrate the morphology code into your branch, > > once I get around figuring out how GIT works. > > The easiest way may be to: > > 1. Branch off the current master > 2. Copy your changes in and commit as necessary > 3. Push back to the server using > > git push origin > 4. Click on "Request Merge" > > The most important thing is not to merge with my or other branches > while developing. ?If you feel you'd like to provide a patch that > would provide cleanly, you can rebase, as long as you are aware of the > problems that can cause (for example, never rebase published changes). > > Re: morphologie -- should we consider including the code from the > other Python library as well? > > Regards > St?fan From eads at soe.ucsc.edu Sat Oct 3 16:36:40 2009 From: eads at soe.ucsc.edu (Damian Eads) Date: Sat, 3 Oct 2009 21:36:40 +0100 Subject: OpenImageIO In-Reply-To: <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> Message-ID: <462e7fdf0910031336v124aad01j55cadff7edfdaaad@mail.gmail.com> One alternative is LIBCVD, which reads and writes many common formats including BMP, PNG, PPM, JPEG, etc. It has a simple, easy-to-use image loading function img_load, Image img(img_load("image.png")); It also reads and writes video. All of its dependencies are optional so a reader/writer is only compiled if the development library is available during ./configure. Damian 2009/10/3 St?fan van der Walt : > > Hey Zach > > 2009/10/3 Zachary Pincus : >> The only downside to OpenImageIO is that it has some not-always- >> standard dependencies, such as boost and cmake (neither of which > > I didn't realise there was a boost dependency -- I'd rather avoid > boost if at all possible. > > You spent some time writing a replacement IO reader in pure Python, if > I recall correctly; did you have any practically usable results? > > Another option may be GraphicsMagick: > > http://www.graphicsmagick.org/ > > Regards > St?fan > -- ----------------------------------------------------- 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 From stefan at sun.ac.za Sat Oct 3 16:27:25 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sat, 3 Oct 2009 22:27:25 +0200 Subject: OpenImageIO In-Reply-To: References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> Message-ID: <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> Hey Zach 2009/10/3 Zachary Pincus : > The only downside to OpenImageIO is that it has some not-always- > standard dependencies, such as boost and cmake (neither of which I didn't realise there was a boost dependency -- I'd rather avoid boost if at all possible. You spent some time writing a replacement IO reader in pure Python, if I recall correctly; did you have any practically usable results? Another option may be GraphicsMagick: http://www.graphicsmagick.org/ Regards St?fan From sccolbert at gmail.com Sat Oct 3 16:55:20 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Sat, 3 Oct 2009 22:55:20 +0200 Subject: OpenImageIO In-Reply-To: <462e7fdf0910031336v124aad01j55cadff7edfdaaad@mail.gmail.com> References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <462e7fdf0910031336v124aad01j55cadff7edfdaaad@mail.gmail.com> Message-ID: <7f014ea60910031355r3b2400f7xac04bddf92012b2b@mail.gmail.com> There is also imagemagick, which is included in the ubuntu repos: http://www.imagemagick.org/script/formats.php which supports a ton of formats, and also has python bindings... On Sat, Oct 3, 2009 at 10:36 PM, Damian Eads wrote: > > One alternative is LIBCVD, which reads and writes many common formats > including BMP, PNG, PPM, JPEG, etc. It has a simple, easy-to-use image > loading function img_load, > > ? Image img(img_load("image.png")); > > It also reads and writes video. All of its dependencies are optional > so a reader/writer is only compiled if the development library is > available during ./configure. > > Damian > > 2009/10/3 St?fan van der Walt : >> >> Hey Zach >> >> 2009/10/3 Zachary Pincus : >>> The only downside to OpenImageIO is that it has some not-always- >>> standard dependencies, such as boost and cmake (neither of which >> >> I didn't realise there was a boost dependency -- I'd rather avoid >> boost if at all possible. >> >> You spent some time writing a replacement IO reader in pure Python, if >> I recall correctly; did you have any practically usable results? >> >> Another option may be GraphicsMagick: >> >> http://www.graphicsmagick.org/ >> >> Regards >> St?fan >> > > > > -- > ----------------------------------------------------- > 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 > From sccolbert at gmail.com Sat Oct 3 16:56:56 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Sat, 3 Oct 2009 22:56:56 +0200 Subject: OpenImageIO In-Reply-To: <7f014ea60910031355r3b2400f7xac04bddf92012b2b@mail.gmail.com> References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <462e7fdf0910031336v124aad01j55cadff7edfdaaad@mail.gmail.com> <7f014ea60910031355r3b2400f7xac04bddf92012b2b@mail.gmail.com> Message-ID: <7f014ea60910031356te85f799y8cf2fb827dd7a64f@mail.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.. On Sat, Oct 3, 2009 at 10:55 PM, Chris Colbert wrote: > There is also imagemagick, which is included in the ubuntu repos: > > http://www.imagemagick.org/script/formats.php > > which supports a ton of formats, and also has python bindings... > > > On Sat, Oct 3, 2009 at 10:36 PM, Damian Eads wrote: >> >> One alternative is LIBCVD, which reads and writes many common formats >> including BMP, PNG, PPM, JPEG, etc. It has a simple, easy-to-use image >> loading function img_load, >> >> ? Image img(img_load("image.png")); >> >> It also reads and writes video. All of its dependencies are optional >> so a reader/writer is only compiled if the development library is >> available during ./configure. >> >> Damian >> >> 2009/10/3 St?fan van der Walt : >>> >>> Hey Zach >>> >>> 2009/10/3 Zachary Pincus : >>>> The only downside to OpenImageIO is that it has some not-always- >>>> standard dependencies, such as boost and cmake (neither of which >>> >>> I didn't realise there was a boost dependency -- I'd rather avoid >>> boost if at all possible. >>> >>> You spent some time writing a replacement IO reader in pure Python, if >>> I recall correctly; did you have any practically usable results? >>> >>> Another option may be GraphicsMagick: >>> >>> http://www.graphicsmagick.org/ >>> >>> Regards >>> St?fan >>> >> >> >> >> -- >> ----------------------------------------------------- >> 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 >> > From stefan at sun.ac.za Sat Oct 3 17:31:29 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sat, 3 Oct 2009 23:31:29 +0200 Subject: OpenImageIO In-Reply-To: <7f014ea60910031356te85f799y8cf2fb827dd7a64f@mail.gmail.com> References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <462e7fdf0910031336v124aad01j55cadff7edfdaaad@mail.gmail.com> <7f014ea60910031355r3b2400f7xac04bddf92012b2b@mail.gmail.com> <7f014ea60910031356te85f799y8cf2fb827dd7a64f@mail.gmail.com> Message-ID: <9457e7c80910031431s24d274b0kc7620d41cdb3d061@mail.gmail.com> 2009/10/3 Chris Colbert : > > 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 From eads at soe.ucsc.edu Sat Oct 3 18:33:28 2009 From: eads at soe.ucsc.edu (Damian Eads) Date: Sat, 3 Oct 2009 23:33:28 +0100 Subject: What kind of language limitations (if any) do we want to place on implementations?? In-Reply-To: <7f014ea60910031522g4a256164q629888f2dfc0ddee@mail.gmail.com> References: <7f014ea60910031522g4a256164q629888f2dfc0ddee@mail.gmail.com> Message-ID: <462e7fdf0910031533l1b5078aao63e1161e765fd7d0@mail.gmail.com> On Sat, Oct 3, 2009 at 11:22 PM, Chris Colbert wrote: > > 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? Code already exists in scikits.image which depends on Cython. Damian From eads at soe.ucsc.edu Sat Oct 3 18:47:33 2009 From: eads at soe.ucsc.edu (Damian Eads) Date: Sat, 3 Oct 2009 23:47:33 +0100 Subject: OpenImageIO In-Reply-To: <9457e7c80910031431s24d274b0kc7620d41cdb3d061@mail.gmail.com> References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <462e7fdf0910031336v124aad01j55cadff7edfdaaad@mail.gmail.com> <7f014ea60910031355r3b2400f7xac04bddf92012b2b@mail.gmail.com> <7f014ea60910031356te85f799y8cf2fb827dd7a64f@mail.gmail.com> <9457e7c80910031431s24d274b0kc7620d41cdb3d061@mail.gmail.com> Message-ID: <462e7fdf0910031547x1c8a9285l522014d1b6ab4945@mail.gmail.com> 2009/10/3 St?fan van der Walt : > > 2009/10/3 Chris Colbert : >> >> 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. It is an important distinction. Along these lines, LIBCVD has no general dependencies other than a C++ compiler and compiles on both GCC and Visual Studio. If chosen as a specific dependency, it wouldn't increase the size of our dependency DAG by very much at all. > 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.] Novel image processing algorithms not available elsewhere? Like what? Can you give examples? If we restrict our attention to novel algorithms, then we greatly limit the breadth of functionality, and scikits.image is less likely to be adopted by other researchers. Python is not currently the preferred language for Computer Vision or Image Processing. Most researchers use MATLAB, C++, or a combination of both. We should think of ways to broaden the appeal of Python to such researchers and the development of scikits.image should reflect it. Damian From eads at soe.ucsc.edu Sat Oct 3 18:52:26 2009 From: eads at soe.ucsc.edu (Damian Eads) Date: Sat, 3 Oct 2009 23:52:26 +0100 Subject: What kind of language limitations (if any) do we want to place on implementations?? In-Reply-To: <7f014ea60910031538m583fcb81xc3cf7175c21db9f2@mail.gmail.com> References: <7f014ea60910031522g4a256164q629888f2dfc0ddee@mail.gmail.com> <462e7fdf0910031533l1b5078aao63e1161e765fd7d0@mail.gmail.com> <7f014ea60910031538m583fcb81xc3cf7175c21db9f2@mail.gmail.com> Message-ID: <462e7fdf0910031552l1cc92f39k8eadd410d4273af2@mail.gmail.com> I attended the scikits.image sprint and we agreed to let Cython be dependency. At the sprint, I wrote integral image and morphology code available, which is available here http://github.com/deads/scikits.image/tree/master/scikits/image/filter/ http://github.com/deads/scikits.image/tree/master/scikits/image/morphology/ Stefan has been trying to get me to merge it back in but I haven't had the time to figure out how to do this with GIT. Damian On Sat, Oct 3, 2009 at 11:38 PM, Chris Colbert wrote: > > would you mind pointing it out to me? > > I scanned through the entire source tree here: > http://github.com/stefanv/scikits.image > > but didn't see anything... > > Sorry if I'm just not seeing it.... > > -Chris > > On Sun, Oct 4, 2009 at 12:33 AM, Damian Eads wrote: >> >> On Sat, Oct 3, 2009 at 11:22 PM, Chris Colbert wrote: >>> >>> 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? >> >> Code already exists in scikits.image which depends on Cython. >> >> Damian >> > -- ----------------------------------------------------- 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 From sccolbert at gmail.com Sat Oct 3 18:11:31 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Sun, 4 Oct 2009 00:11:31 +0200 Subject: OpenImageIO In-Reply-To: <9457e7c80910031431s24d274b0kc7620d41cdb3d061@mail.gmail.com> References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <462e7fdf0910031336v124aad01j55cadff7edfdaaad@mail.gmail.com> <7f014ea60910031355r3b2400f7xac04bddf92012b2b@mail.gmail.com> <7f014ea60910031356te85f799y8cf2fb827dd7a64f@mail.gmail.com> <9457e7c80910031431s24d274b0kc7620d41cdb3d061@mail.gmail.com> Message-ID: <7f014ea60910031511t67bb1709q80a1d33886f95250@mail.gmail.com> 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 : > > 2009/10/3 Chris Colbert : >> >> 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 > From dwf at cs.toronto.edu Sun Oct 4 00:22:00 2009 From: dwf at cs.toronto.edu (David Warde-Farley) Date: Sun, 4 Oct 2009 00:22:00 -0400 Subject: What kind of language limitations (if any) do we want to place on implementations?? In-Reply-To: <9457e7c80910031654n1c9de14aif73f378a921ae8c4@mail.gmail.com> References: <7f014ea60910031522g4a256164q629888f2dfc0ddee@mail.gmail.com> <9457e7c80910031654n1c9de14aif73f378a921ae8c4@mail.gmail.com> Message-ID: <7572B7FF-9156-4185-AB55-10B514114834@cs.toronto.edu> On 3-Oct-09, at 7:54 PM, St?fan van der Walt wrote: > Like Damian mentioned, we had a discussion on this at the sprint and > decided that Cython is a good way to go for optimising extensions. I > am a bit allergic to C++ (especially given the compiler mess it has > caused in SciPy), so unless we have a very good reason I'd prefer to > stick to C. It should be noted that Cython needn't be a *dependency*, as such. Release tarballs can include the generated C files and thus not require Cython to build. I think this is ideal to make it easy to build from source but not tether developers to writing in raw C all the time. David From sccolbert at gmail.com Sat Oct 3 18:22:42 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Sun, 4 Oct 2009 00:22:42 +0200 Subject: What kind of language limitations (if any) do we want to place on implementations?? Message-ID: <7f014ea60910031522g4a256164q629888f2dfc0ddee@mail.gmail.com> 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 From sccolbert at gmail.com Sat Oct 3 18:38:13 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Sun, 4 Oct 2009 00:38:13 +0200 Subject: What kind of language limitations (if any) do we want to place on implementations?? In-Reply-To: <462e7fdf0910031533l1b5078aao63e1161e765fd7d0@mail.gmail.com> References: <7f014ea60910031522g4a256164q629888f2dfc0ddee@mail.gmail.com> <462e7fdf0910031533l1b5078aao63e1161e765fd7d0@mail.gmail.com> Message-ID: <7f014ea60910031538m583fcb81xc3cf7175c21db9f2@mail.gmail.com> would you mind pointing it out to me? I scanned through the entire source tree here: http://github.com/stefanv/scikits.image but didn't see anything... Sorry if I'm just not seeing it.... -Chris On Sun, Oct 4, 2009 at 12:33 AM, Damian Eads wrote: > > On Sat, Oct 3, 2009 at 11:22 PM, Chris Colbert wrote: >> >> 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? > > Code already exists in scikits.image which depends on Cython. > > Damian > From dwf at cs.toronto.edu Sun Oct 4 01:05:11 2009 From: dwf at cs.toronto.edu (David Warde-Farley) Date: Sun, 4 Oct 2009 01:05:11 -0400 Subject: BSD license in scikits.image Message-ID: 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 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 From eads at soe.ucsc.edu Sat Oct 3 20:17:23 2009 From: eads at soe.ucsc.edu (Damian Eads) Date: Sun, 4 Oct 2009 01:17:23 +0100 Subject: OpenImageIO In-Reply-To: <9457e7c80910031649t77ed35cci2666a72247da7973@mail.gmail.com> References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <462e7fdf0910031336v124aad01j55cadff7edfdaaad@mail.gmail.com> <7f014ea60910031355r3b2400f7xac04bddf92012b2b@mail.gmail.com> <7f014ea60910031356te85f799y8cf2fb827dd7a64f@mail.gmail.com> <9457e7c80910031431s24d274b0kc7620d41cdb3d061@mail.gmail.com> <462e7fdf0910031547x1c8a9285l522014d1b6ab4945@mail.gmail.com> <9457e7c80910031649t77ed35cci2666a72247da7973@mail.gmail.com> Message-ID: <462e7fdf0910031717i4be995aax8dc3b0c84d87737c@mail.gmail.com> 2009/10/4 St?fan van der Walt : > > 2009/10/4 Damian Eads : >> It is an important distinction. Along these lines, LIBCVD has no >> general dependencies other than a C++ compiler and compiles on both >> GCC and Visual Studio. If chosen as a specific dependency, it wouldn't >> increase the size of our dependency DAG by very much at all. > > 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. >?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. 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. >?But like I mentioned earlier, we could just wrap > existing solutions -- the user is bound to have PIL or matplotlib or > imagemagick or ... installed (and we can encourage them to do so in > the readme, for example). That could work too. :) >>> 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.] >> >> Novel image processing algorithms not available elsewhere? Like what? > > Sorry, I should have said "novel OR not easily available elsewhere". > My main thought was that we should not try to replicate the wrappers > for OpenCV, for example. Agreed, I don't think we want to replicate efforts to wrap existing libraries. However, I think rewrapping is acceptable if we offer a much simpler, functional interface than what has been done before. One of the reasons why MATLAB is so popular is its functional style and use of arrays to represent most data. If we can greatly reduce boilerplating then duplicating efforts may be worthwhile. >> Image Processing. Most researchers use MATLAB, C++, or a combination >> of both. We should think of ways to broaden the appeal of Python to >> such researchers and the development of scikits.image should reflect >> it. > > Absolutely, but since we can't be everything to all people, I'd rather > make a difference where it is needed: adding algorithms not already > easily accessible to Python users. Yes, I still need to integrate the morphology code into your branch, once I get around figuring out how GIT works. Damian ----------------------------------------------------- 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 From stefan at sun.ac.za Sat Oct 3 19:41:26 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 4 Oct 2009 01:41:26 +0200 Subject: Projective transformations Message-ID: <9457e7c80910031641r5bf4ffb4wfc34753ca390a2f2@mail.gmail.com> Hi all, Please review the code for projective transformations / homographies at: http://github.com/stefanv/scikits.image/commit/927157e7e508efbb0628f3e1f77bfb2bf60359ca Regards St?fan From stefan at sun.ac.za Sat Oct 3 19:49:14 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 4 Oct 2009 01:49:14 +0200 Subject: OpenImageIO In-Reply-To: <462e7fdf0910031547x1c8a9285l522014d1b6ab4945@mail.gmail.com> References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <462e7fdf0910031336v124aad01j55cadff7edfdaaad@mail.gmail.com> <7f014ea60910031355r3b2400f7xac04bddf92012b2b@mail.gmail.com> <7f014ea60910031356te85f799y8cf2fb827dd7a64f@mail.gmail.com> <9457e7c80910031431s24d274b0kc7620d41cdb3d061@mail.gmail.com> <462e7fdf0910031547x1c8a9285l522014d1b6ab4945@mail.gmail.com> Message-ID: <9457e7c80910031649t77ed35cci2666a72247da7973@mail.gmail.com> 2009/10/4 Damian Eads : > It is an important distinction. Along these lines, LIBCVD has no > general dependencies other than a C++ compiler and compiles on both > GCC and Visual Studio. If chosen as a specific dependency, it wouldn't > increase the size of our dependency DAG by very much at all. 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?). We could look at extracting the IO part of CVD or ImageMagick to keep things light-weight. But like I mentioned earlier, we could just wrap existing solutions -- the user is bound to have PIL or matplotlib or imagemagick or ... installed (and we can encourage them to do so in the readme, for example). >> 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.] > > Novel image processing algorithms not available elsewhere? Like what? Sorry, I should have said "novel OR not easily available elsewhere". My main thought was that we should not try to replicate the wrappers for OpenCV, for example. > Image Processing. Most researchers use MATLAB, C++, or a combination > of both. We should think of ways to broaden the appeal of Python to > such researchers and the development of scikits.image should reflect > it. Absolutely, but since we can't be everything to all people, I'd rather make a difference where it is needed: adding algorithms not already easily accessible to Python users. Cheers St?fan From stefan at sun.ac.za Sat Oct 3 19:54:49 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 4 Oct 2009 01:54:49 +0200 Subject: What kind of language limitations (if any) do we want to place on implementations?? In-Reply-To: <7f014ea60910031522g4a256164q629888f2dfc0ddee@mail.gmail.com> References: <7f014ea60910031522g4a256164q629888f2dfc0ddee@mail.gmail.com> Message-ID: <9457e7c80910031654n1c9de14aif73f378a921ae8c4@mail.gmail.com> 2009/10/4 Chris Colbert : > 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? Like Damian mentioned, we had a discussion on this at the sprint and decided that Cython is a good way to go for optimising extensions. I am a bit allergic to C++ (especially given the compiler mess it has caused in SciPy), so unless we have a very good reason I'd prefer to stick to C. I'd be very glad if someone could provide a robust setup.py file to automatically build Cython extensions! Setuptools and Cython don't play all that nicely together, and setuptools changed its output directories for .so files during in-place builds when using Python 2.6. Since I'm on the topic of build systems: we may just as well put the infrastructure in place now to build with scons + numscons, David Cournapeau's new build system for NumPy and SciPy. Cheers St?fan From stefan at sun.ac.za Sat Oct 3 19:57:49 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 4 Oct 2009 01:57:49 +0200 Subject: Documentation page Message-ID: <9457e7c80910031657g30390443ne53c71335566cf8f@mail.gmail.com> 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 From stefan at sun.ac.za Sat Oct 3 20:53:24 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 4 Oct 2009 02:53:24 +0200 Subject: OpenImageIO In-Reply-To: <462e7fdf0910031717i4be995aax8dc3b0c84d87737c@mail.gmail.com> References: <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <462e7fdf0910031336v124aad01j55cadff7edfdaaad@mail.gmail.com> <7f014ea60910031355r3b2400f7xac04bddf92012b2b@mail.gmail.com> <7f014ea60910031356te85f799y8cf2fb827dd7a64f@mail.gmail.com> <9457e7c80910031431s24d274b0kc7620d41cdb3d061@mail.gmail.com> <462e7fdf0910031547x1c8a9285l522014d1b6ab4945@mail.gmail.com> <9457e7c80910031649t77ed35cci2666a72247da7973@mail.gmail.com> <462e7fdf0910031717i4be995aax8dc3b0c84d87737c@mail.gmail.com> Message-ID: <9457e7c80910031753j7de77b25sbee99264bcbd9ecc@mail.gmail.com> 2009/10/4 Damian Eads : > Agreed, I don't think we want to replicate efforts to wrap existing > libraries. However, I think rewrapping is acceptable if we offer a > much simpler, functional interface than what has been done before. One > of the reasons why MATLAB is so popular is its functional style and > use of arrays to represent most data. If we can greatly reduce > boilerplating then duplicating efforts may be worthwhile. Right on. > Yes, I still need to integrate the morphology code into your branch, > once I get around figuring out how GIT works. The easiest way may be to: 1. Branch off the current master 2. Copy your changes in and commit as necessary 3. Push back to the server using git push origin 4. Click on "Request Merge" The most important thing is not to merge with my or other branches while developing. If you feel you'd like to provide a patch that would provide cleanly, you can rebase, as long as you are aware of the problems that can cause (for example, never rebase published changes). Re: morphologie -- should we consider including the code from the other Python library as well? Regards St?fan From stefan at sun.ac.za Sun Oct 4 06:46:02 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 4 Oct 2009 12:46:02 +0200 Subject: BSD license in scikits.image In-Reply-To: References: Message-ID: <9457e7c80910040346l75fbd27av1a131ed1c437c1e9@mail.gmail.com> Hi David 2009/10/4 David Warde-Farley : > Curious - what happened to the 3rd clause of the BSD license in the > LICENSE.txt in Scikits.image? Thanks for noticing the oversight. I've uploaded a new version of the docs: http://stefanv.github.com/scikits.image/license.html Cheers St?fan From ralf.gommers at googlemail.com Mon Oct 5 03:52:52 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 5 Oct 2009 09:52:52 +0200 Subject: OpenImageIO In-Reply-To: <32044279-7985-4ae7-9e67-c38a3442c37b@h40g2000prf.googlegroups.com> References: <462e7fdf0910031336v124aad01j55cadff7edfdaaad@mail.gmail.com> <7f014ea60910031355r3b2400f7xac04bddf92012b2b@mail.gmail.com> <7f014ea60910031356te85f799y8cf2fb827dd7a64f@mail.gmail.com> <9457e7c80910031431s24d274b0kc7620d41cdb3d061@mail.gmail.com> <462e7fdf0910031547x1c8a9285l522014d1b6ab4945@mail.gmail.com> <9457e7c80910031649t77ed35cci2666a72247da7973@mail.gmail.com> <462e7fdf0910031717i4be995aax8dc3b0c84d87737c@mail.gmail.com> <9457e7c80910031753j7de77b25sbee99264bcbd9ecc@mail.gmail.com> <32044279-7985-4ae7-9e67-c38a3442c37b@h40g2000prf.googlegroups.com> Message-ID: On Sun, Oct 4, 2009 at 4:39 AM, Gary Ruben 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zachary.pincus at yale.edu Mon Oct 5 10:04:16 2009 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Mon, 5 Oct 2009 10:04:16 -0400 Subject: OpenImageIO In-Reply-To: <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> Message-ID: <5589C16A-33F8-4C24-8313-7E49E33CB0B5@yale.edu> > You spent some time writing a replacement IO reader in pure Python, if > I recall correctly; did you have any practically usable results? I looked into this for a while, and came to the conclusion that it would be very annoying yet technically simple to write a bunch of basic image format parsers in pure python (using the PIL image plugins as a guide). Any compression beyond what exists in the python stdlib (which is to say, zlib, basically), though, becomes rather more of a pain -- either you'd have to disallow jpeg IO, or write/wrap a jpeg decoder -- neither of which sound particularly fun. That is, I think that one could write simple PNG and TIFF decoders (which do not support all the corners of the spec, but neither do those in the PIL) in pure python / numpy in a day or so. This would be useful for many people, but lacking jpeg would be a big issue. Perhaps we could grab just the C core of some jpeg decoder/encoder somewhere and use that? Otherwise, I think the best option is to find a simple, dependency- free C image IO library to wrap. CVD looks OK here. Zach From eads at soe.ucsc.edu Mon Oct 5 08:58:15 2009 From: eads at soe.ucsc.edu (Damian Eads) Date: Mon, 5 Oct 2009 13:58:15 +0100 Subject: Fwd: OpenImageIO In-Reply-To: References: <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <462e7fdf0910031336v124aad01j55cadff7edfdaaad@mail.gmail.com> <7f014ea60910031355r3b2400f7xac04bddf92012b2b@mail.gmail.com> <7f014ea60910031356te85f799y8cf2fb827dd7a64f@mail.gmail.com> <9457e7c80910031431s24d274b0kc7620d41cdb3d061@mail.gmail.com> <462e7fdf0910031547x1c8a9285l522014d1b6ab4945@mail.gmail.com> <9457e7c80910031649t77ed35cci2666a72247da7973@mail.gmail.com> <462e7fdf0910031717i4be995aax8dc3b0c84d87737c@mail.gmail.com> Message-ID: <462e7fdf0910050558q368e3f2bjb72a7923daaea800@mail.gmail.com> Ed Rosten meant to send this to everyone so I'm forwarding this. ---------- Forwarded message ---------- From: Edward Rosten Date: Mon, Oct 5, 2009 at 10:33 AM Subject: Re: OpenImageIO To: Damian Eads On Sun, Oct 4, 2009 at 1:17 AM, Damian Eads 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 From stefan at sun.ac.za Mon Oct 5 12:14:54 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 5 Oct 2009 18:14:54 +0200 Subject: OpenImageIO In-Reply-To: <5589C16A-33F8-4C24-8313-7E49E33CB0B5@yale.edu> References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <5589C16A-33F8-4C24-8313-7E49E33CB0B5@yale.edu> Message-ID: <9457e7c80910050914q2418252dl586582a610b2750f@mail.gmail.com> Hi Zach 2009/10/5 Zachary Pincus : > >> You spent some time writing a replacement IO reader in pure Python, if >> I recall correctly; did you have any practically usable results? [...] > That is, I think that one could write simple PNG and TIFF decoders > (which do not support all the corners of the spec, but neither do > those in the PIL) in pure python / numpy in a day or so. This would be > useful for many people, but lacking jpeg would be a big issue. Perhaps > we could grab just the C core of some jpeg decoder/encoder somewhere > and use that? libjpeg and libpng are both fairly easy to wrap with a couple of cython / ctypes calls, so I might just do that at a next sprint. Looking back at this conversation, I believe a plugin system would be a practical solution that can be implemented right away. For example: plugins (be it for PIL, CVD, Magick, etc.) are asked to load an image. If a plugin fails because the format is not supported, it raises a FormatError and the next plugin is used. WIth a plugin system in place, we can later replace as much of the functionality under the hood as we want, while having developed a consistent interface that can be exposed to the user right away (via imread). Let me know your thoughts. Regards St?fan From gary.ruben at gmail.com Mon Oct 5 07:13:44 2009 From: gary.ruben at gmail.com (Gary Ruben) Date: Mon, 05 Oct 2009 22:13:44 +1100 Subject: OpenImageIO In-Reply-To: References: <462e7fdf0910031336v124aad01j55cadff7edfdaaad@mail.gmail.com> <7f014ea60910031355r3b2400f7xac04bddf92012b2b@mail.gmail.com> <7f014ea60910031356te85f799y8cf2fb827dd7a64f@mail.gmail.com> <9457e7c80910031431s24d274b0kc7620d41cdb3d061@mail.gmail.com> <462e7fdf0910031547x1c8a9285l522014d1b6ab4945@mail.gmail.com> <9457e7c80910031649t77ed35cci2666a72247da7973@mail.gmail.com> <462e7fdf0910031717i4be995aax8dc3b0c84d87737c@mail.gmail.com> <9457e7c80910031753j7de77b25sbee99264bcbd9ecc@mail.gmail.com> <32044279-7985-4ae7-9e67-c38a3442c37b@h40g2000prf.googlegroups.com> Message-ID: <4AC9D4E8.9050901@gmail.com> See inline comments below. Ralf Gommers wrote: > On Sun, Oct 4, 2009 at 4:39 AM, Gary Ruben > 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. No. I just meant numpy's binary file reading straight into numpy arrays, rather than indirectly via some python-native container that I assume requires intermediate storage using python types before being transferred to numpy types. > 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 Looks like construct does have some image types supported but they may not be very robust. Anyway, I agree that it would be a lot of work, but if the work has to be done anyway, I don't think that's an argument against this approach if there are clear benefits. Gary From ralf.gommers at googlemail.com Wed Oct 7 05:48:07 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 7 Oct 2009 11:48:07 +0200 Subject: OpenImageIO In-Reply-To: <9457e7c80910050914q2418252dl586582a610b2750f@mail.gmail.com> References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <5589C16A-33F8-4C24-8313-7E49E33CB0B5@yale.edu> <9457e7c80910050914q2418252dl586582a610b2750f@mail.gmail.com> Message-ID: 2009/10/5 St?fan van der Walt > > Hi Zach > > 2009/10/5 Zachary Pincus : > > > >> You spent some time writing a replacement IO reader in pure Python, if > >> I recall correctly; did you have any practically usable results? > > [...] > > > That is, I think that one could write simple PNG and TIFF decoders > > (which do not support all the corners of the spec, but neither do > > those in the PIL) in pure python / numpy in a day or so. This would be > > useful for many people, but lacking jpeg would be a big issue. Perhaps > > we could grab just the C core of some jpeg decoder/encoder somewhere > > and use that? > > libjpeg and libpng are both fairly easy to wrap with a couple of > cython / ctypes calls, so I might just do that at a next sprint. > > Looking back at this conversation, I believe a plugin system would be > a practical solution that can be implemented right away. For example: > plugins (be it for PIL, CVD, Magick, etc.) are asked to load an image. > If a plugin fails because the format is not supported, it raises a > FormatError and the next plugin is used. > A plugin system sounds like a good idea. Maybe it needs a little more than waiting for a format error, because it is possible for a format to be supported but in a buggy way. Then you'd get back an array filled with garbage. It should be possible for the user to specify the order in which libraries are tried, to exclude libraries completely, as well as easily register their own library as a plugin. > WIth a plugin system in place, we can later replace as much of the > functionality under the hood as we want, while having developed a > consistent interface that can be exposed to the user right away (via > imread). > Do you want a single function for everything, or different functions for single-page / multi-page images? Having to do something like: img = open(fname) img2d = imread(img) img.seek() img2d = imread(img) img.seek() would be less than ideal. Anyway, a big thumbs up for a plugin system no matter what the interface will look like exactly. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Wed Oct 7 07:07:23 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 7 Oct 2009 13:07:23 +0200 Subject: How to Contribute to scikits.image: Task List Message-ID: <9457e7c80910070407h583dcc7ehec29d702cc10885b@mail.gmail.com> 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 From stefan at sun.ac.za Wed Oct 7 07:34:31 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 7 Oct 2009 13:34:31 +0200 Subject: OpenImageIO In-Reply-To: References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <5589C16A-33F8-4C24-8313-7E49E33CB0B5@yale.edu> <9457e7c80910050914q2418252dl586582a610b2750f@mail.gmail.com> Message-ID: <9457e7c80910070434w451e0737uc4ff6a98b48de439@mail.gmail.com> 2009/10/7 Ralf Gommers : > Do you want a single function for everything, or different functions for > single-page / multi-page images? Having to do something like: > > img = open(fname) > img2d = imread(img) > img.seek() > img2d = imread(img) > img.seek() > > would be less than ideal. I have some code waiting to be merged that implements an ImageCollection. Typically, you'd have ic = ImageCollection('*.png') where all PNGs are access only as necessary, and are cached once they've been read from disk. You can also index into or iterate over an ImageCollection (yielding the image arrays). It sounds like a multi-image could be interpreted as an ImageCollection. > Anyway, a big thumbs up for a plugin system no matter what the interface > will look like exactly. OK, I'll implement this over the weekend. If someone else has time, feel free to jump in. Cheers St?fan From stefan at sun.ac.za Wed Oct 7 07:49:21 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 7 Oct 2009 13:49:21 +0200 Subject: Fwd: ANN: SciPy October Sprint In-Reply-To: <9457e7c80910070446k2c1ae895u4011d242abc224b@mail.gmail.com> References: <9457e7c80910070446k2c1ae895u4011d242abc224b@mail.gmail.com> Message-ID: <9457e7c80910070449s4765af60g9a6b189f0324c638@mail.gmail.com> 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 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 From eads at soe.ucsc.edu Thu Oct 8 17:38:14 2009 From: eads at soe.ucsc.edu (Damian Eads) Date: Thu, 8 Oct 2009 14:38:14 -0700 Subject: great news with regards to OpenCV support... In-Reply-To: <7f014ea60910081418s6234168bx6b23659610d32665@mail.gmail.com> References: <7f014ea60910081237w66bba56co2cb9923ed30a6016@mail.gmail.com> <7f014ea60910081418s6234168bx6b23659610d32665@mail.gmail.com> Message-ID: <462e7fdf0910081438r172ff240x809a4724de48c165@mail.gmail.com> On Thu, Oct 8, 2009 at 2:18 PM, Chris Colbert wrote: > > So my next question is: how much hand holding should I do on my end > for the user? > > There are several things I would like to address here: > > - opencv makes extensive use of *out arguments, should we require the user to > ?preallocate their out array or should we make it for them and return it. > ?The latter option is more pythonic, but comes with a small overhead for > ?determining a proper return dtype I think having out be None by default is best. > - how much checking should I do on the input array. OpenCV images can accept > ?6 different dtypes. ?If the user passes an incorrect dtype, should I > raise an exception > ?or just let it fail with a KeyError during the dtype lookup? An exception with a meaningful error message like "type unsupported" is more useful to the user than a KeyError in an undocumented, local variable data structure. > ?How much checking should I do on the array dimensions. We can use 2D > or 3D arrays > ?with the third dimension equal to 2, 3, or 4. Should I check that > the passed arrays conform to > ?this, or just let everything fail? Again, how much validation > overhead should we allow It's not clear to me how the best way to write to a 4D array. It's probably best to throw an exception unless you can come up with a clear use case for high dimensional arrays. > On the technical side, I'm wondering if I should INCREF the numpy > array when I pass it to OpenCV. If Python somehow gc'ed the array > while OpenCV is working on it, that could be nasty. ?The only way I > see this happening is if I start releasing the GIL on opencv calls. > This brings the advantage of performance during threading but will not > at all be thread safe since I'm "borrowing" the numpy data pointer. Will users call the OpenCV functions directly or do you have Python wrappers? If your Python wrapper function keeps a reference to the array throughout execution in C-space, you can probably avoid the INCREF. Damian > On Thu, Oct 8, 2009 at 10:59 PM, Zachary Pincus wrote: >> >> Fantastic! This is great news. >> >> >> On Oct 8, 2009, at 3:37 PM, Chris Colbert wrote: >> >>> 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 >>> >> >> > -- ----------------------------------------------------- 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 From eads at soe.ucsc.edu Thu Oct 8 19:14:10 2009 From: eads at soe.ucsc.edu (Damian Eads) Date: Thu, 8 Oct 2009 16:14:10 -0700 Subject: great news with regards to OpenCV support... In-Reply-To: <7f014ea60910081442m68e7d35flaff5863d60cd52d3@mail.gmail.com> References: <7f014ea60910081237w66bba56co2cb9923ed30a6016@mail.gmail.com> <7f014ea60910081418s6234168bx6b23659610d32665@mail.gmail.com> <462e7fdf0910081438r172ff240x809a4724de48c165@mail.gmail.com> <7f014ea60910081442m68e7d35flaff5863d60cd52d3@mail.gmail.com> Message-ID: <462e7fdf0910081614s75fdc045iaaade64cb9f14863@mail.gmail.com> On Thu, Oct 8, 2009 at 2:42 PM, Chris Colbert wrote: > > On Thu, Oct 8, 2009 at 11:38 PM, Damian Eads wrote: >> >> On Thu, Oct 8, 2009 at 2:18 PM, Chris Colbert wrote: >>> >>> So my next question is: how much hand holding should I do on my end >>> for the user? >>> >>> There are several things I would like to address here: >>> >>> - opencv makes extensive use of *out arguments, should we require the user to >>> ?preallocate their out array or should we make it for them and return it. >>> ?The latter option is more pythonic, but comes with a small overhead for >>> ?determining a proper return dtype >> >> I think having out be None by default is best. >> > > That's how i've been going about it so far, but that obviously incurs > an overhead of determining, exactly if and what to return. True but I think the overhead of checking for a None is minimal compared to the overhead of performing most image processing operations. >>> - how much checking should I do on the input array. OpenCV images can accept >>> ?6 different dtypes. ?If the user passes an incorrect dtype, should I >>> raise an exception >>> ?or just let it fail with a KeyError during the dtype lookup? >> >> An exception with a meaningful error message like "type unsupported" >> is more useful to the user than a KeyError in an undocumented, local >> variable data structure. >> > ?this is leading me to think it would be easiest to just have a > general validator that ensures each array conforms to a common set of > requirements Yes, the cluster package has this to check for validity of data structures. The first part of each function could read something like: check_valid_image(I) # throws exception if something goes wrong if out is None: out = np.zeros(I.shape, dtype=I.dtype) else: check_image_compatibility(I, X) (call OpenCV via ctypes) >>> ?How much checking should I do on the array dimensions. We can use 2D >>> or 3D arrays >>> ?with the third dimension equal to 2, 3, or 4. Should I check that >>> the passed arrays conform to >>> ?this, or just let everything fail? Again, how much validation >>> overhead should we allow >> >> It's not clear to me how the best way to write to a 4D array. It's >> probably best to throw an exception unless you can come up with a >> clear use case for high dimensional arrays. >> > OpenCV cant handle 4D arrays. But it can handle 3D arrays with 4 > channels (i.e. RGBA) > These errors can be caught in a validator. > >>> On the technical side, I'm wondering if I should INCREF the numpy >>> array when I pass it to OpenCV. If Python somehow gc'ed the array >>> while OpenCV is working on it, that could be nasty. ?The only way I >>> see this happening is if I start releasing the GIL on opencv calls. >>> This brings the advantage of performance during threading but will not >>> at all be thread safe since I'm "borrowing" the numpy data pointer. >> >> Will users call the OpenCV functions directly or do you have Python >> wrappers? If your Python wrapper function keeps a reference to the >> array throughout execution in C-space, you can probably avoid the >> INCREF. >> > > the opencv calls are being made in a wrapper, and the function has a > reference to the array until it returns. Great, it's always nice to avoid reference counting. Damian From zachary.pincus at yale.edu Thu Oct 8 16:59:18 2009 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Thu, 8 Oct 2009 16:59:18 -0400 Subject: great news with regards to OpenCV support... In-Reply-To: <7f014ea60910081237w66bba56co2cb9923ed30a6016@mail.gmail.com> References: <7f014ea60910081237w66bba56co2cb9923ed30a6016@mail.gmail.com> Message-ID: Fantastic! This is great news. On Oct 8, 2009, at 3:37 PM, Chris Colbert wrote: > 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 > From sccolbert at gmail.com Thu Oct 8 15:37:32 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Thu, 8 Oct 2009 21:37:32 +0200 Subject: great news with regards to OpenCV support... Message-ID: <7f014ea60910081237w66bba56co2cb9923ed30a6016@mail.gmail.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: testnumpy.pyx Type: application/octet-stream Size: 3029 bytes Desc: not available URL: From sccolbert at gmail.com Thu Oct 8 15:42:15 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Thu, 8 Oct 2009 21:42:15 +0200 Subject: great news with regards to OpenCV support... In-Reply-To: <7f014ea60910081237w66bba56co2cb9923ed30a6016@mail.gmail.com> References: <7f014ea60910081237w66bba56co2cb9923ed30a6016@mail.gmail.com> Message-ID: <7f014ea60910081242u31765390t28df2f89dc23f33@mail.gmail.com> I just realized a fantastic byproduct of this: In OpenCV there is a concept of Region-of-Interest, where, if defined, the function will only operate on that section of the image. But because of numpy handles views, there is no need to provide support for that, you just pass in the view to the function as if it were a normal image. Cheers! Chris On Thu, Oct 8, 2009 at 9:37 PM, Chris Colbert wrote: > 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 > From sccolbert at gmail.com Thu Oct 8 17:18:05 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Thu, 8 Oct 2009 23:18:05 +0200 Subject: great news with regards to OpenCV support... In-Reply-To: References: <7f014ea60910081237w66bba56co2cb9923ed30a6016@mail.gmail.com> Message-ID: <7f014ea60910081418s6234168bx6b23659610d32665@mail.gmail.com> So my next question is: how much hand holding should I do on my end for the user? There are several things I would like to address here: - opencv makes extensive use of *out arguments, should we require the user to preallocate their out array or should we make it for them and return it. The latter option is more pythonic, but comes with a small overhead for determining a proper return dtype - how much checking should I do on the input array. OpenCV images can accept 6 different dtypes. If the user passes an incorrect dtype, should I raise an exception or just let it fail with a KeyError during the dtype lookup? How much checking should I do on the array dimensions. We can use 2D or 3D arrays with the third dimension equal to 2, 3, or 4. Should I check that the passed arrays conform to this, or just let everything fail? Again, how much validation overhead should we allow On the technical side, I'm wondering if I should INCREF the numpy array when I pass it to OpenCV. If Python somehow gc'ed the array while OpenCV is working on it, that could be nasty. The only way I see this happening is if I start releasing the GIL on opencv calls. This brings the advantage of performance during threading but will not at all be thread safe since I'm "borrowing" the numpy data pointer. Cheers! Chris On Thu, Oct 8, 2009 at 10:59 PM, Zachary Pincus wrote: > > Fantastic! This is great news. > > > On Oct 8, 2009, at 3:37 PM, Chris Colbert wrote: > >> 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 >> > > From sccolbert at gmail.com Thu Oct 8 17:42:59 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Thu, 8 Oct 2009 23:42:59 +0200 Subject: great news with regards to OpenCV support... In-Reply-To: <462e7fdf0910081438r172ff240x809a4724de48c165@mail.gmail.com> References: <7f014ea60910081237w66bba56co2cb9923ed30a6016@mail.gmail.com> <7f014ea60910081418s6234168bx6b23659610d32665@mail.gmail.com> <462e7fdf0910081438r172ff240x809a4724de48c165@mail.gmail.com> Message-ID: <7f014ea60910081442m68e7d35flaff5863d60cd52d3@mail.gmail.com> On Thu, Oct 8, 2009 at 11:38 PM, Damian Eads wrote: > > On Thu, Oct 8, 2009 at 2:18 PM, Chris Colbert wrote: >> >> So my next question is: how much hand holding should I do on my end >> for the user? >> >> There are several things I would like to address here: >> >> - opencv makes extensive use of *out arguments, should we require the user to >> ?preallocate their out array or should we make it for them and return it. >> ?The latter option is more pythonic, but comes with a small overhead for >> ?determining a proper return dtype > > I think having out be None by default is best. > That's how i've been going about it so far, but that obviously incurs an overhead of determining, exactly if and what to return. >> - how much checking should I do on the input array. OpenCV images can accept >> ?6 different dtypes. ?If the user passes an incorrect dtype, should I >> raise an exception >> ?or just let it fail with a KeyError during the dtype lookup? > > An exception with a meaningful error message like "type unsupported" > is more useful to the user than a KeyError in an undocumented, local > variable data structure. > this is leading me to think it would be easiest to just have a general validator that ensures each array conforms to a common set of requirements >> ?How much checking should I do on the array dimensions. We can use 2D >> or 3D arrays >> ?with the third dimension equal to 2, 3, or 4. Should I check that >> the passed arrays conform to >> ?this, or just let everything fail? Again, how much validation >> overhead should we allow > > It's not clear to me how the best way to write to a 4D array. It's > probably best to throw an exception unless you can come up with a > clear use case for high dimensional arrays. > OpenCV cant handle 4D arrays. But it can handle 3D arrays with 4 channels (i.e. RGBA) These errors can be caught in a validator. >> On the technical side, I'm wondering if I should INCREF the numpy >> array when I pass it to OpenCV. If Python somehow gc'ed the array >> while OpenCV is working on it, that could be nasty. ?The only way I >> see this happening is if I start releasing the GIL on opencv calls. >> This brings the advantage of performance during threading but will not >> at all be thread safe since I'm "borrowing" the numpy data pointer. > > Will users call the OpenCV functions directly or do you have Python > wrappers? If your Python wrapper function keeps a reference to the > array throughout execution in C-space, you can probably avoid the > INCREF. > the opencv calls are being made in a wrapper, and the function has a reference to the array until it returns. > Damian > >> On Thu, Oct 8, 2009 at 10:59 PM, Zachary Pincus wrote: >>> >>> Fantastic! This is great news. >>> >>> >>> On Oct 8, 2009, at 3:37 PM, Chris Colbert wrote: >>> >>>> 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 >>>> >>> >>> >> > > > > -- > ----------------------------------------------------- > 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 > From ralf.gommers at googlemail.com Thu Oct 8 18:45:49 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 9 Oct 2009 00:45:49 +0200 Subject: great news with regards to OpenCV support... In-Reply-To: <7f014ea60910081442m68e7d35flaff5863d60cd52d3@mail.gmail.com> References: <7f014ea60910081237w66bba56co2cb9923ed30a6016@mail.gmail.com> <7f014ea60910081418s6234168bx6b23659610d32665@mail.gmail.com> <462e7fdf0910081438r172ff240x809a4724de48c165@mail.gmail.com> <7f014ea60910081442m68e7d35flaff5863d60cd52d3@mail.gmail.com> Message-ID: On Thu, Oct 8, 2009 at 11:42 PM, Chris Colbert wrote: > > On Thu, Oct 8, 2009 at 11:38 PM, Damian Eads wrote: > > > > On Thu, Oct 8, 2009 at 2:18 PM, Chris Colbert > wrote: > >> > >> So my next question is: how much hand holding should I do on my end > >> for the user? > >> > >> There are several things I would like to address here: > >> > >> - opencv makes extensive use of *out arguments, should we require the > user to > >> preallocate their out array or should we make it for them and return > it. > >> The latter option is more pythonic, but comes with a small overhead for > >> determining a proper return dtype > > > > I think having out be None by default is best. > > > > That's how i've been going about it so far, but that obviously incurs > an overhead of determining, exactly if and what to return. > Doing it the same as for ufuncs would make sense I think. Is that what you mean by "having out None"? The overhead should be small compared to most operations on images. Ufuncs return a view on `out` if given by the user. scipy.ndimage returns None in that case. I think returning a view is more convenient. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From sccolbert at gmail.com Thu Oct 8 19:03:58 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Fri, 9 Oct 2009 01:03:58 +0200 Subject: great news with regards to OpenCV support... In-Reply-To: References: <7f014ea60910081237w66bba56co2cb9923ed30a6016@mail.gmail.com> <7f014ea60910081418s6234168bx6b23659610d32665@mail.gmail.com> <462e7fdf0910081438r172ff240x809a4724de48c165@mail.gmail.com> <7f014ea60910081442m68e7d35flaff5863d60cd52d3@mail.gmail.com> Message-ID: <7f014ea60910081603u3a743e06k809e3cc3ab8a7571@mail.gmail.com> On Fri, Oct 9, 2009 at 12:45 AM, Ralf Gommers wrote: > > > On Thu, Oct 8, 2009 at 11:42 PM, Chris Colbert wrote: >> >> On Thu, Oct 8, 2009 at 11:38 PM, Damian Eads wrote: >> > >> > On Thu, Oct 8, 2009 at 2:18 PM, Chris Colbert >> > wrote: >> >> >> >> So my next question is: how much hand holding should I do on my end >> >> for the user? >> >> >> >> There are several things I would like to address here: >> >> >> >> - opencv makes extensive use of *out arguments, should we require the >> >> user to >> >> ?preallocate their out array or should we make it for them and return >> >> it. >> >> ?The latter option is more pythonic, but comes with a small overhead >> >> for >> >> ?determining a proper return dtype >> > >> > I think having out be None by default is best. >> > >> >> That's how i've been going about it so far, but that obviously incurs >> an overhead of determining, exactly if and what to return. > > Doing it the same as for ufuncs would make sense I think. Is that what you > mean by "having out None"? The overhead should be small compared to most > operations on images. > > Ufuncs return a view on `out` if given by the user. scipy.ndimage returns > None in that case. I think returning a view is more convenient. > > Cheers, > Ralf > > So far, I've been doing it like this: If the user passes an 'out' array, I verify that its compatible for the operation. If the user does not pass an out array, I create an appropriate one for them. The final case is operations that can performed in place by opencv. In these cases, the function takes an extra boolean kwarg 'in_place'. If true, the operation is performed in place. This is done by assiging 'src' to 'out' and passing both to opencv. In all these cases, I return the 'out' array. So if the user supplied it or requested inplace, they can just ignore the return value. Cheers! Chris From stefan at sun.ac.za Fri Oct 9 00:57:53 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 9 Oct 2009 06:57:53 +0200 Subject: great news with regards to OpenCV support... In-Reply-To: <462e7fdf0910081614s75fdc045iaaade64cb9f14863@mail.gmail.com> References: <7f014ea60910081237w66bba56co2cb9923ed30a6016@mail.gmail.com> <7f014ea60910081418s6234168bx6b23659610d32665@mail.gmail.com> <462e7fdf0910081438r172ff240x809a4724de48c165@mail.gmail.com> <7f014ea60910081442m68e7d35flaff5863d60cd52d3@mail.gmail.com> <462e7fdf0910081614s75fdc045iaaade64cb9f14863@mail.gmail.com> Message-ID: <9457e7c80910082157h5fc01416v49b507bf24c8226f@mail.gmail.com> Hey all, To Chris, congratulations -- this is a very encouraging result! I really like the design. To the rest of you, thanks for answering all his questions so well. As I read the thread this morning, I formulated a bunch of answers but by the end of the thread all were given! Chris, could you make your development available as a branch on github? I'd like to have a look at the code, even if it is a roughly hacked version. Happy coding, St?fan From sccolbert at gmail.com Fri Oct 9 04:41:46 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Fri, 9 Oct 2009 10:41:46 +0200 Subject: great news with regards to OpenCV support... In-Reply-To: <9457e7c80910082157h5fc01416v49b507bf24c8226f@mail.gmail.com> References: <7f014ea60910081237w66bba56co2cb9923ed30a6016@mail.gmail.com> <7f014ea60910081418s6234168bx6b23659610d32665@mail.gmail.com> <462e7fdf0910081438r172ff240x809a4724de48c165@mail.gmail.com> <7f014ea60910081442m68e7d35flaff5863d60cd52d3@mail.gmail.com> <462e7fdf0910081614s75fdc045iaaade64cb9f14863@mail.gmail.com> <9457e7c80910082157h5fc01416v49b507bf24c8226f@mail.gmail.com> Message-ID: <7f014ea60910090141w21cdfea5hb004bffa05f2a63c@mail.gmail.com> I'd be more than happy to put what I have on GIT (as soon as I figure out how to do that :)) I've cleaned up quite a bit from what was posted earlier, and am working on the getting "validation" machinery in place. Chris 2009/10/9 St?fan van der Walt : > > Hey all, > > To Chris, congratulations -- this is a very encouraging result! ?I > really like the design. > > To the rest of you, thanks for answering all his questions so well. > As I read the thread this morning, I formulated a bunch of answers but > by the end of the thread all were given! > > Chris, could you make your development available as a branch on > github? ?I'd like to have a look at the code, even if it is a roughly > hacked version. > > Happy coding, > St?fan > From ralf.gommers at googlemail.com Fri Oct 9 05:35:09 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 9 Oct 2009 11:35:09 +0200 Subject: OpenImageIO In-Reply-To: <9457e7c80910070434w451e0737uc4ff6a98b48de439@mail.gmail.com> References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <5589C16A-33F8-4C24-8313-7E49E33CB0B5@yale.edu> <9457e7c80910050914q2418252dl586582a610b2750f@mail.gmail.com> <9457e7c80910070434w451e0737uc4ff6a98b48de439@mail.gmail.com> Message-ID: 2009/10/7 St?fan van der Walt > > 2009/10/7 Ralf Gommers : > > Do you want a single function for everything, or different functions for > > single-page / multi-page images? Having to do something like: > > > > img = open(fname) > > img2d = imread(img) > > img.seek() > > img2d = imread(img) > > img.seek() > > > > would be less than ideal. > > I have some code waiting to be merged that implements an > ImageCollection. Typically, you'd have > > ic = ImageCollection('*.png') > > where all PNGs are access only as necessary, and are cached once > they've been read from disk. You can also index into or iterate over > an ImageCollection (yielding the image arrays). It sounds like a > multi-image could be interpreted as an ImageCollection. > That sounds like a good option. Let me know if you want me to test it / work on it / send you some multi-image files. Cheers, Ralf > > > Anyway, a big thumbs up for a plugin system no matter what the interface > > will look like exactly. > > OK, I'll implement this over the weekend. If someone else has time, > feel free to jump in. > > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Fri Oct 9 05:48:02 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 9 Oct 2009 11:48:02 +0200 Subject: OpenImageIO In-Reply-To: References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <5589C16A-33F8-4C24-8313-7E49E33CB0B5@yale.edu> <9457e7c80910050914q2418252dl586582a610b2750f@mail.gmail.com> <9457e7c80910070434w451e0737uc4ff6a98b48de439@mail.gmail.com> Message-ID: <9457e7c80910090248h50a69ceoe532418a4e7b528a@mail.gmail.com> Hey Ralph 2009/10/9 Ralf Gommers : >> where all PNGs are access only as necessary, and are cached once >> they've been read from disk. ?You can also index into or iterate over >> an ImageCollection (yielding the image arrays). ?It sounds like a >> multi-image could be interpreted as an ImageCollection. > > That sounds like a good option. Let me know if you want me to test it / work > on it / send you some multi-image files. I'd appreciate it if you could investigate a bit further. The code I was referring to is at http://bazaar.launchpad.net/~stefanv/supreme/main/annotate/head%3A/supreme/misc/io.py As you can see, it is very simplistic. It also returns a bunch of Image objects, that we don't need. But the basic idea is there: a container over which you can iterate, that loads images on demand and keeps a cache as necessary. I've never played with loading of multi-layer images, so I hope you can get something going. Cheers St?fan From ralf.gommers at googlemail.com Fri Oct 9 07:19:23 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 9 Oct 2009 13:19:23 +0200 Subject: OpenImageIO In-Reply-To: <9457e7c80910090248h50a69ceoe532418a4e7b528a@mail.gmail.com> References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <5589C16A-33F8-4C24-8313-7E49E33CB0B5@yale.edu> <9457e7c80910050914q2418252dl586582a610b2750f@mail.gmail.com> <9457e7c80910070434w451e0737uc4ff6a98b48de439@mail.gmail.com> <9457e7c80910090248h50a69ceoe532418a4e7b528a@mail.gmail.com> Message-ID: 2009/10/9 St?fan van der Walt > > Hey Ralph > > 2009/10/9 Ralf Gommers : > >> where all PNGs are access only as necessary, and are cached once > >> they've been read from disk. You can also index into or iterate over > >> an ImageCollection (yielding the image arrays). It sounds like a > >> multi-image could be interpreted as an ImageCollection. > > > > That sounds like a good option. Let me know if you want me to test it / > work > > on it / send you some multi-image files. > > I'd appreciate it if you could investigate a bit further. The code I > was referring to is at > > > http://bazaar.launchpad.net/~stefanv/supreme/main/annotate/head%3A/supreme/misc/io.py > > As you can see, it is very simplistic. It also returns a bunch of > Image objects, that we don't need. But the basic idea is there: a > container over which you can iterate, that loads images on demand and > keeps a cache as necessary. I've never played with loading of > multi-layer images, so I hope you can get something going. > Sure, I'll give it a go. I cloned your scikits.image repo on github, will add a new branch and push to my cloned repo once it works. That is best way to do it right? Another git question, for scipy I followed this guide: http://projects.scipy.org/numpy/wiki/GitMirror. Now I have it here: http://github.com/rgommers/scipy. Would it not be better to clone another scipy repo already on github, like David's or Pauli's? Or does it not matter? Cheers, Ralf > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Fri Oct 9 08:04:10 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 9 Oct 2009 14:04:10 +0200 Subject: OpenImageIO In-Reply-To: References: <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <5589C16A-33F8-4C24-8313-7E49E33CB0B5@yale.edu> <9457e7c80910050914q2418252dl586582a610b2750f@mail.gmail.com> <9457e7c80910070434w451e0737uc4ff6a98b48de439@mail.gmail.com> <9457e7c80910090248h50a69ceoe532418a4e7b528a@mail.gmail.com> Message-ID: <9457e7c80910090504x678a37dek47e445cdd19f10b5@mail.gmail.com> Hi Ralph 2009/10/9 Ralf Gommers : > Sure, I'll give it a go. I cloned your scikits.image repo on github, will > add a new branch and push to my cloned repo once it works. That is best way > to do it right? I added some sparse instructions to http://stefanv.github.com/scikits.image/contribute.html#development-process but patches are welcome to flesh out the description. > Another git question, for scipy I followed this guide: > http://projects.scipy.org/numpy/wiki/GitMirror. Now I have it here: > http://github.com/rgommers/scipy. Would it not be better to clone another > scipy repo already on github, like David's or Pauli's? Or does it not > matter? The idea is that, eventually, we have an official git repo that everybody clones. As is, it seems we all have our own clones hanging around, but David and Pauli's were probably made from the official scipy.git repo. I agree, though, that the instructions can be improved -- a lot! Hopefully we'll be switching to git and redmine soon, then these problems will go away. Cheers St?fan From ralf.gommers at googlemail.com Fri Oct 9 14:36:52 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 9 Oct 2009 20:36:52 +0200 Subject: OpenImageIO In-Reply-To: <9457e7c80910090248h50a69ceoe532418a4e7b528a@mail.gmail.com> References: <9457e7c80910021618h27be08bdr568ce6b199541021@mail.gmail.com> <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <5589C16A-33F8-4C24-8313-7E49E33CB0B5@yale.edu> <9457e7c80910050914q2418252dl586582a610b2750f@mail.gmail.com> <9457e7c80910070434w451e0737uc4ff6a98b48de439@mail.gmail.com> <9457e7c80910090248h50a69ceoe532418a4e7b528a@mail.gmail.com> Message-ID: 2009/10/9 St?fan van der Walt > > Hey Ralph > > 2009/10/9 Ralf Gommers : > >> where all PNGs are access only as necessary, and are cached once > >> they've been read from disk. You can also index into or iterate over > >> an ImageCollection (yielding the image arrays). It sounds like a > >> multi-image could be interpreted as an ImageCollection. > > > > That sounds like a good option. Let me know if you want me to test it / > work > > on it / send you some multi-image files. > > I'd appreciate it if you could investigate a bit further. The code I > was referring to is at > > > http://bazaar.launchpad.net/~stefanv/supreme/main/annotate/head%3A/supreme/misc/io.py > > As you can see, it is very simplistic. It also returns a bunch of > Image objects, that we don't need. But the basic idea is there: a > container over which you can iterate, that loads images on demand and > keeps a cache as necessary. I've never played with loading of > multi-layer images, so I hope you can get something going. > Thanks Stefan, that was a useful start. I added a MultiImg class which is quite similar to your ImgCollection. There are enough differences between a multi-image file and a collection of single image files to justify creating a separate class I think. The code is here: http://github.com/rgommers/scikits.image/blob/imgcollection/scikits/image/io/io.py It works with my multi-frame TIFF files (only PIL trunk, not 1.1.6), and once I figure out how to create a correct TIFF header/file (does anyone have code for this?) I can add a self-contained example and tests. Things that would be useful to add: - caching a configurable number of frames (now 1 or all) - a dtype keyword - switch to the new IO plugin system once it's ready - add a MultiImgCollection - what else? Questions: - do you want to keep the Image class in that form? It seems either a plain ndarray or ndarray + tags dict is enough. - can I remove the EXIF stuff or move it to a subclass of Image? I don't think it belongs in the base Image class. - should imread be moved into io.py? I'd appreciate any feedback on the basic design and new feature suggestions. Cheers, Ralf > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Sat Oct 10 02:12:04 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sat, 10 Oct 2009 08:12:04 +0200 Subject: OpenImageIO In-Reply-To: References: <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <5589C16A-33F8-4C24-8313-7E49E33CB0B5@yale.edu> <9457e7c80910050914q2418252dl586582a610b2750f@mail.gmail.com> <9457e7c80910070434w451e0737uc4ff6a98b48de439@mail.gmail.com> <9457e7c80910090248h50a69ceoe532418a4e7b528a@mail.gmail.com> Message-ID: <9457e7c80910092312r564dfd2dj79d99259bab3ad68@mail.gmail.com> Hey Ralf 2009/10/9 Ralf Gommers : > http://github.com/rgommers/scikits.image/blob/imgcollection/scikits/image/io/io.py Thanks for working on this! > Questions: > - do you want to keep the Image class in that form? It seems either a plain > ndarray or ndarray + tags dict is enough. I'd like to remove the image class entirely. > - can I remove the EXIF stuff or move it to a subclass of Image? I don't > think it belongs in the base Image class. Yes, although having an EXIF reader as a separate function might be handy! That code is BSD-licensed AFAIK. > - should imread be moved into io.py? Let's leave it where it is for now. It is accessible as scikits.image.io.imread, which is fine from a user perspective. Other notes: If you require PIL trunk, you need to check that it is available explicitly. Also, the PIL import test is already done by imread. About naming: I'd prefer if we expand the names, i.e. MultiImage instead of MultiImg. I've learnt this the hard way, but it seems I can never remember my own shorthand :) The example markup does not require the "::". The description of MultiImage could be changed to reflect what it is storing, i.e. something like class MultiImage(object): """Class for loading multi-layer images.""" When using try-except statements, keep the code snippet contained as small as possible. In this case, there's no problem really, because you specifically wait for an EOFError. In general, however, it's safer to use the form: i = 0 while True: i += 1 try: img.seek(i) except EOFError: break return i Not sure whether you'll ever come across images without any frames inside, but in those cases you need a return statement as well, as above. _getallframes can be simplified using _getframe: frames = [] for i in range(len(self)): frames.append(self._getframe(i)) return frames The numframes variable should not be exposed, since len() is already available. The string representation can also include information on the number of frames, e.g. cat.tiff [50 frames] Finally, ensure that read-only members are defined as properties: @property def filename(self): return _filename As always with review comments: they may be overly pedantic, so use what you find applicable and discard the rest. Cheers St?fan From ralf.gommers at googlemail.com Sat Oct 10 03:56:39 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sat, 10 Oct 2009 09:56:39 +0200 Subject: OpenImageIO In-Reply-To: <9457e7c80910092312r564dfd2dj79d99259bab3ad68@mail.gmail.com> References: <9457e7c80910031327h3004bea7g6cfb5073bd66cb48@mail.gmail.com> <5589C16A-33F8-4C24-8313-7E49E33CB0B5@yale.edu> <9457e7c80910050914q2418252dl586582a610b2750f@mail.gmail.com> <9457e7c80910070434w451e0737uc4ff6a98b48de439@mail.gmail.com> <9457e7c80910090248h50a69ceoe532418a4e7b528a@mail.gmail.com> <9457e7c80910092312r564dfd2dj79d99259bab3ad68@mail.gmail.com> Message-ID: Hi Stefan, 2009/10/10 St?fan van der Walt > > Hey Ralf > > 2009/10/9 Ralf Gommers : > > > http://github.com/rgommers/scikits.image/blob/imgcollection/scikits/image/io/io.py > > Thanks for working on this! > > > Questions: > > - do you want to keep the Image class in that form? It seems either a > plain > > ndarray or ndarray + tags dict is enough. > > I'd like to remove the image class entirely. > > > - can I remove the EXIF stuff or move it to a subclass of Image? I don't > > think it belongs in the base Image class. > > Yes, although having an EXIF reader as a separate function might be > handy! That code is BSD-licensed AFAIK. > > What I added is BSD-licensed as well. > > - should imread be moved into io.py? > > Let's leave it where it is for now. It is accessible as > scikits.image.io.imread, which is fine from a user perspective. > > Other notes: > > If you require PIL trunk, you need to check that it is available > explicitly. Also, the PIL import test is already done by imread. > > OK. I'll move the import into the MultiImg class then, so ImageCollection still works if trunk is not available. > About naming: I'd prefer if we expand the names, i.e. MultiImage > instead of MultiImg. I've learnt this the hard way, but it seems I > can never remember my own shorthand :) > The reason was the Image class, which conflicted with the PIL import. That is solved now, so I'll expand all the names again. > > The example markup does not require the "::". > > I saw Pauli do that for examples that are not self-contained, i.e. can't be run with doctest. Alternatively I can use the #doctest +SKIP markup (ugly as well...). > The description of MultiImage could be changed to reflect what it is > storing, i.e. something like > > class MultiImage(object): > """Class for loading multi-layer images.""" > > When using try-except statements, keep the code snippet contained as > small as possible. In this case, there's no problem really, because > you specifically wait for an EOFError. In general, however, it's > safer to use the form: > > i = 0 > while True: > i += 1 > try: > img.seek(i) > except EOFError: > break > return i > > Sure, I'l change that. > Not sure whether you'll ever come across images without any frames > inside, but in those cases you need a return statement as well, as > above. > > _getallframes can be simplified using _getframe: > > frames = [] > for i in range(len(self)): > frames.append(self._getframe(i)) > return frames > _getframe opens and closes the file each time, so _getallframes should be a little faster. And it's still simple code, so I think it's worth the few lines of duplication. > > The numframes variable should not be exposed, since len() is already > available. > > Sure, I'll make it private. > The string representation can also include information on the number > of frames, e.g. > > cat.tiff [50 frames] > > Makes sense. > Finally, ensure that read-only members are defined as properties: > > @property > def filename(self): > return _filename > Sure. > > As always with review comments: they may be overly pedantic, so use > what you find applicable and discard the rest. > > Don't worry, I find the above very useful. Thanks for the feedback. Cheers, Ralf > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sccolbert at gmail.com Sat Oct 10 12:53:09 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Sat, 10 Oct 2009 18:53:09 +0200 Subject: opencv stuff now on github Message-ID: <7f014ea60910100953o3411352ep342e15083314bfe1@mail.gmail.com> 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 From stefan at sun.ac.za Sun Oct 11 01:23:16 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 11 Oct 2009 07:23:16 +0200 Subject: opencv stuff now on github In-Reply-To: <7f014ea60910100953o3411352ep342e15083314bfe1@mail.gmail.com> References: <7f014ea60910100953o3411352ep342e15083314bfe1@mail.gmail.com> Message-ID: <9457e7c80910102223s37811573ucc91b943a4e66e24@mail.gmail.com> Hi Chris 2009/10/10 Chris Colbert : > 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. Thanks, things are progressing really well! As always, I'd like to do a round of review before integrating the code. Standard disclaimer: my comments are just my opinions, so feel free to say if you disagree. OK, here goes: - Instead of trying to load a .dll or .so yourself, make use of numpy's np.ctypeslib.load_library. If might also be a good time to document that function (please!). For example, see line 16 of http://dip.sun.ac.za/~stefan/code/supreme.git/?p=stefan/supreme.git;a=blob;f=supreme/ext/libsupreme.py;h=82d4317033e283ce12f83ddbabb28641fb541b74;hb=HEAD - I saw the comment that you'd like to find a better way to match types in numpy and openCV, but really I think your dictionary is just fine. - Just to clarify things in my own mind: In opencv_type.pxd, you say that you reimplement the _IplImage type. Is this basically a direct copy from the IplImage.h header file? I guess you had to redefine ROI and maskROI to point to void? I'd be very happy to integrate this branch as soon as there are some tests (to make sure the round-tripping of ndarray -> IplImage -> ndarray works, for example). You'll have to make sure that the tests are marked for skipping if opencv is not available. Also, could you document the OpenCV wrappers (like cvSmooth) to have a pointer to the online OpenCV docs? That would help users to get up and running quickly! Finally, we'll have to figure out a way to load libopencv.so even if it is installed in standard locations (e.g., on the different Linux distros such as Debian). Keep up the good work! Cheers St?fan From stefan at sun.ac.za Sun Oct 11 04:50:42 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 11 Oct 2009 10:50:42 +0200 Subject: OpenImageIO In-Reply-To: References: <5589C16A-33F8-4C24-8313-7E49E33CB0B5@yale.edu> <9457e7c80910050914q2418252dl586582a610b2750f@mail.gmail.com> <9457e7c80910070434w451e0737uc4ff6a98b48de439@mail.gmail.com> <9457e7c80910090248h50a69ceoe532418a4e7b528a@mail.gmail.com> <9457e7c80910092312r564dfd2dj79d99259bab3ad68@mail.gmail.com> Message-ID: <9457e7c80910110150t7003071fg3f3ebc03213cc1ed@mail.gmail.com> 2009/10/10 Ralf Gommers : >> The example markup does not require the "::". >> > I saw Pauli do that for examples that are not self-contained, i.e. can't be > run with doctest. Alternatively I can use the #doctest +SKIP markup (ugly as > well...). OK, that's fine then! Let me know when you're done, then I'll have a look at the patch. Cheers St?fan From sccolbert at gmail.com Sun Oct 11 05:38:44 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Sun, 11 Oct 2009 11:38:44 +0200 Subject: opencv stuff now on github In-Reply-To: <9457e7c80910102223s37811573ucc91b943a4e66e24@mail.gmail.com> References: <7f014ea60910100953o3411352ep342e15083314bfe1@mail.gmail.com> <9457e7c80910102223s37811573ucc91b943a4e66e24@mail.gmail.com> Message-ID: <7f014ea60910110238w10b7fca7k2ff2e75016f99a05@mail.gmail.com> Hi, Please see inline comments. 2009/10/11 St?fan van der Walt : > > Hi Chris > > 2009/10/10 Chris Colbert : >> 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. > > Thanks, things are progressing really well! > > As always, I'd like to do a round of review before integrating the > code. ?Standard disclaimer: my comments are just my opinions, so feel > free to say if you disagree. ?OK, here goes: > > - Instead of trying to load a .dll or .so yourself, make use of > numpy's np.ctypeslib.load_library. ?If might also be a good time to > document that function (please!). ?For example, see line 16 of > > http://dip.sun.ac.za/~stefan/code/supreme.git/?p=stefan/supreme.git;a=blob;f=supreme/ext/libsupreme.py;h=82d4317033e283ce12f83ddbabb28641fb541b74;hb=HEAD > I see that function is completely undocumented, is it safe to assume it handles the loading of the library regardless of the platform, making my checks for windows and linux unecessary? > - I saw the comment that you'd like to find a better way to match > types in numpy and openCV, but really I think your dictionary is just > fine. I wasn't quite sure if the performance of a dictionary lookup would be good enough for our case. And I thought that may there was some basic computer science concept that I was missing that would be implemented there (I'm a mechanical engineer and self taught programmer). But if you say the dictionary is fine for that purpose, that suits me just as well. > > - Just to clarify things in my own mind: In opencv_type.pxd, you say > that you reimplement the _IplImage type. ?Is this basically a direct > copy from the IplImage.h header file? ?I guess you had to redefine ROI > and maskROI to point to void? > Yes, it's basically a direct copy from the opencv header file, with a few things set to void that will never be used. I though this would be cleaner than using a "cdef extern from" declaration to get the type from the opencv headers. Plus, we the don't need the opencv headers present on the client machine during build time. > I'd be very happy to integrate this branch as soon as there are some > tests (to make sure the round-tripping of ndarray -> IplImage -> > ndarray works, for example). ?You'll have to make sure that the tests > are marked for skipping if opencv is not available. ?Also, could you > document the OpenCV wrappers (like cvSmooth) to have a pointer to the > online OpenCV docs? ?That would help users to get up and running > quickly! > Yes, I need to go back and add some docstrings, definately. Tests, I was a little unsure of how you want to make the tests. Do you want to test everypossible combination of every function? or just one test case on a small array, and verify the output is correct? > Finally, we'll have to figure out a way to load libopencv.so even if > it is installed in standard locations (e.g., on the different Linux > distros such as Debian). > the library will load provided the directory it is in is available on LD_LIBRARY_PATH in linux, or the equivalent path in windows. I think it should be the responsibility of the user to make sure their libraries are available on the path, instead of us trying to hunt them down. > Keep up the good work! > > Cheers > St?fan > Cheers, Chris From stefan at sun.ac.za Sun Oct 11 05:47:47 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 11 Oct 2009 11:47:47 +0200 Subject: opencv stuff now on github In-Reply-To: <7f014ea60910110238w10b7fca7k2ff2e75016f99a05@mail.gmail.com> References: <7f014ea60910100953o3411352ep342e15083314bfe1@mail.gmail.com> <9457e7c80910102223s37811573ucc91b943a4e66e24@mail.gmail.com> <7f014ea60910110238w10b7fca7k2ff2e75016f99a05@mail.gmail.com> Message-ID: <9457e7c80910110247p51546708we11c9aa986a37707@mail.gmail.com> 2009/10/11 Chris Colbert : >> - Instead of trying to load a .dll or .so yourself, make use of >> numpy's np.ctypeslib.load_library. ?If might also be a good time to >> document that function (please!). ?For example, see line 16 of >> >> http://dip.sun.ac.za/~stefan/code/supreme.git/?p=stefan/supreme.git;a=blob;f=supreme/ext/libsupreme.py;h=82d4317033e283ce12f83ddbabb28641fb541b74;hb=HEAD >> > I see that function is completely undocumented, is it safe to assume > it handles the loading of the library regardless of the platform, > making my checks for windows and linux unecessary? Yes, that's correct.. If you don't mind, it would be great if you could sign on to http://docs.scipy.org and fix the lack of docs! >> - I saw the comment that you'd like to find a better way to match >> types in numpy and openCV, but really I think your dictionary is just >> fine. > > I wasn't quite sure if the performance of a dictionary lookup would be > good enough for our case. And I thought that may there was some basic > computer science concept that I was missing that would be implemented > there (I'm a mechanical engineer and self taught programmer). But if > you say the dictionary is fine for that purpose, that suits me just as > well. First, you did a good job and, second, the algorithms typically run much longer than the time required to call them. We'll optimise if the need arises! > Tests, I was a little unsure of how you want to make the tests. Do you > want to test everypossible combination of every function? or just one > test case on a small array, and verify the output is correct? Yes, I don't think we need to rewrite OpenCV's test suite. Just a simple test for each function to make sure parameters are passed correctly with the right types and that the output is sane. You can use the test decorators (have a look in the scipy source) to skip tests when OpenCV is not available. Cheers St?fan From sccolbert at gmail.com Sun Oct 11 08:10:44 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Sun, 11 Oct 2009 14:10:44 +0200 Subject: opencv stuff now on github In-Reply-To: <9457e7c80910110247p51546708we11c9aa986a37707@mail.gmail.com> References: <7f014ea60910100953o3411352ep342e15083314bfe1@mail.gmail.com> <9457e7c80910102223s37811573ucc91b943a4e66e24@mail.gmail.com> <7f014ea60910110238w10b7fca7k2ff2e75016f99a05@mail.gmail.com> <9457e7c80910110247p51546708we11c9aa986a37707@mail.gmail.com> Message-ID: <7f014ea60910110510o7e8b9805r6f370544b1505365@mail.gmail.com> After taking a look at numpy.ctypeslib.load_library(), is there any particular reason to use that over ctypes.CDLL(). I find the advantage goes to the latter. With the numpy function, you have to specify the path where the library to be loaded exists, using ctypes.CDLL() the library just has to be available on the system library path. The only advantage I see to the numpy method is that is takes care of the library file extension for you (something we could easily do ourselves), but at the expense of having to try to find the libraries ourselves rather than letting the OS take care of it. Unless there is strong backlash, I would much rather use ctypes.CDLL() to load the opencv libs... Cheers, Chris 2009/10/11 St?fan van der Walt : > > 2009/10/11 Chris Colbert : >>> - Instead of trying to load a .dll or .so yourself, make use of >>> numpy's np.ctypeslib.load_library. ?If might also be a good time to >>> document that function (please!). ?For example, see line 16 of >>> >>> http://dip.sun.ac.za/~stefan/code/supreme.git/?p=stefan/supreme.git;a=blob;f=supreme/ext/libsupreme.py;h=82d4317033e283ce12f83ddbabb28641fb541b74;hb=HEAD >>> >> I see that function is completely undocumented, is it safe to assume >> it handles the loading of the library regardless of the platform, >> making my checks for windows and linux unecessary? > > Yes, that's correct.. ?If you don't mind, it would be great if you > could sign on to http://docs.scipy.org and fix the lack of docs! > >>> - I saw the comment that you'd like to find a better way to match >>> types in numpy and openCV, but really I think your dictionary is just >>> fine. >> >> I wasn't quite sure if the performance of a dictionary lookup would be >> good enough for our case. And I thought that may there was some basic >> computer science concept that I was missing that would be implemented >> there (I'm a mechanical engineer and self taught programmer). But if >> you say the dictionary is fine for that purpose, that suits me just as >> well. > > First, you did a good job and, second, the algorithms typically run > much longer than the time required to call them. ?We'll optimise if > the need arises! > >> Tests, I was a little unsure of how you want to make the tests. Do you >> want to test everypossible combination of every function? or just one >> test case on a small array, and verify the output is correct? > > Yes, I don't think we need to rewrite OpenCV's test suite. ?Just a > simple test for each function to make sure parameters are passed > correctly with the right types and that the output is sane. ?You can > use the test decorators (have a look in the scipy source) to skip > tests when OpenCV is not available. > > Cheers > St?fan > From stefan at sun.ac.za Sun Oct 11 10:27:32 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 11 Oct 2009 16:27:32 +0200 Subject: opencv stuff now on github In-Reply-To: <7f014ea60910110510o7e8b9805r6f370544b1505365@mail.gmail.com> References: <7f014ea60910100953o3411352ep342e15083314bfe1@mail.gmail.com> <9457e7c80910102223s37811573ucc91b943a4e66e24@mail.gmail.com> <7f014ea60910110238w10b7fca7k2ff2e75016f99a05@mail.gmail.com> <9457e7c80910110247p51546708we11c9aa986a37707@mail.gmail.com> <7f014ea60910110510o7e8b9805r6f370544b1505365@mail.gmail.com> Message-ID: <9457e7c80910110727r7d4c08ffq23d28c0f98963046@mail.gmail.com> 2009/10/11 Chris Colbert : > Unless there is strong backlash, I would much rather use ctypes.CDLL() > to load the opencv libs... Or, we could fix the problem in NumPy. Whichever way you want to go is fine. http://projects.scipy.org/numpy/browser/trunk/numpy/ctypeslib.py Cheers St?fan From sccolbert at gmail.com Sun Oct 11 13:02:06 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Sun, 11 Oct 2009 19:02:06 +0200 Subject: ok to require PIL for tests? Message-ID: <7f014ea60910111002u37d940d4qf5c692a2cd96db7b@mail.gmail.com> 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 From stefan at sun.ac.za Sun Oct 11 13:17:15 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 11 Oct 2009 19:17:15 +0200 Subject: ok to require PIL for tests? In-Reply-To: <7f014ea60910111002u37d940d4qf5c692a2cd96db7b@mail.gmail.com> References: <7f014ea60910111002u37d940d4qf5c692a2cd96db7b@mail.gmail.com> Message-ID: <9457e7c80910111017x1c3886b0vc03aa1549aaae108@mail.gmail.com> Hi Chris 2009/10/11 Chris Colbert : > > 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? The scikits.image.io module will always contain an "imread" method, but you are welcome to use .npy if you prefer. Jpeg's might be a bit more compact, depending on the image. Cheers St?fan From sccolbert at gmail.com Sun Oct 11 13:29:25 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Sun, 11 Oct 2009 19:29:25 +0200 Subject: ok to require PIL for tests? In-Reply-To: <9457e7c80910111017x1c3886b0vc03aa1549aaae108@mail.gmail.com> References: <7f014ea60910111002u37d940d4qf5c692a2cd96db7b@mail.gmail.com> <9457e7c80910111017x1c3886b0vc03aa1549aaae108@mail.gmail.com> Message-ID: <7f014ea60910111029j5ac7e17biee93140e0600f099@mail.gmail.com> I've started making various .npy versions of "lena", hopefully I can limit it to as few as possible, and get at least a few tests out of each function... We'll see what happens once we get to more complex stuff than just filtering and morphology... 2009/10/11 St?fan van der Walt : > > Hi Chris > > 2009/10/11 Chris Colbert : >> >> 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? > > The scikits.image.io module will always contain an "imread" method, > but you are welcome to use .npy if you prefer. ?Jpeg's might be a bit > more compact, depending on the image. > > Cheers > St?fan > From ralf.gommers at googlemail.com Sun Oct 11 20:41:03 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 12 Oct 2009 02:41:03 +0200 Subject: OpenImageIO In-Reply-To: <9457e7c80910110150t7003071fg3f3ebc03213cc1ed@mail.gmail.com> References: <9457e7c80910050914q2418252dl586582a610b2750f@mail.gmail.com> <9457e7c80910070434w451e0737uc4ff6a98b48de439@mail.gmail.com> <9457e7c80910090248h50a69ceoe532418a4e7b528a@mail.gmail.com> <9457e7c80910092312r564dfd2dj79d99259bab3ad68@mail.gmail.com> <9457e7c80910110150t7003071fg3f3ebc03213cc1ed@mail.gmail.com> Message-ID: 2009/10/11 St?fan van der Walt > > 2009/10/10 Ralf Gommers : > >> The example markup does not require the "::". > >> > > I saw Pauli do that for examples that are not self-contained, i.e. can't > be > > run with doctest. Alternatively I can use the #doctest +SKIP markup (ugly > as > > well...). > > OK, that's fine then! > > Let me know when you're done, then I'll have a look at the patch. > It's done. Nitpick away! Also, what do you think about adding a dtype keyword to imread? I find it useful to be able to get images as float for example so you don't have to worry about division problems. Cheers, Ralf > > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon Oct 12 02:25:04 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 12 Oct 2009 08:25:04 +0200 Subject: OpenImageIO In-Reply-To: References: <9457e7c80910070434w451e0737uc4ff6a98b48de439@mail.gmail.com> <9457e7c80910090248h50a69ceoe532418a4e7b528a@mail.gmail.com> <9457e7c80910092312r564dfd2dj79d99259bab3ad68@mail.gmail.com> <9457e7c80910110150t7003071fg3f3ebc03213cc1ed@mail.gmail.com> Message-ID: <9457e7c80910112325m3966d6c8ybe6f7093ffa2d2e7@mail.gmail.com> 2009/10/12 Ralf Gommers : > Also, what do you think about adding a dtype keyword to imread? I find it > useful to be able to get images as float for example so you don't have to > worry about division problems. That sounds like a useful addition. It should probably default to int8 or uint8 -- whatever is currently returned. St?fan From stefan at sun.ac.za Mon Oct 12 03:09:06 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 12 Oct 2009 09:09:06 +0200 Subject: OpenImageIO In-Reply-To: References: <9457e7c80910070434w451e0737uc4ff6a98b48de439@mail.gmail.com> <9457e7c80910090248h50a69ceoe532418a4e7b528a@mail.gmail.com> <9457e7c80910092312r564dfd2dj79d99259bab3ad68@mail.gmail.com> <9457e7c80910110150t7003071fg3f3ebc03213cc1ed@mail.gmail.com> Message-ID: <9457e7c80910120009x1622ef28j73f365c9d330110d@mail.gmail.com> 2009/10/12 Ralf Gommers : >> Let me know when you're done, then I'll have a look at the patch. > > It's done. Nitpick away! Thanks, Ralf! I've merged your changes: http://github.com/stefanv/scikits.image/commits/ Cheers St?fan From sccolbert at gmail.com Mon Oct 12 07:58:54 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Mon, 12 Oct 2009 13:58:54 +0200 Subject: what functions from OpenCV do you all want to see included? Message-ID: <7f014ea60910120458o13026e53tffdda6ff791151c3@mail.gmail.com> Given the existing machinery of the wrapper, the following functions will be relatively easy to implement. # already implemented cvSobel cvLaplace cvCanny cvPreCornerDetect cvCornerEigenValsAndVecs cvCornerMinEigenVal cvCornerHarris cvSmooth # will be implemented cvFindCornerSubPix cvGoodFeaturesToTrack cvResize cvWarpAffine cvWarpPerspective cvRemap cvLogPolar cvErode cvDilate cvMorphologyEx cvFilter2D cvIntegral cvCvtColor cvThreshold cvAdaptiveThreshold cvPyrDown cvPyrUp cvPyrMeanShiftFiltering cvWatershed cvDistTransform cvInpaint cvMatchTemplate cvContourArea cvArcLength cvPointPolygonTest cvMinAreaRect2 cvMinEnclosingCircle cvCalcOpticalFlowHS cvCalcOpticalFlowLK cvCalcOpticalFlowBM cvCalcOpticalFlowPyrLK cvFindStereoCorrespondence # misc - do we want these -use highgui for an imshow type function -use highgui for image IO -use highgui for video IO If have a hankering desire for some other OpenCV function to be included, please speak up. Adding function other than what is shown here is possible, but its a lot more work that requires implementing new data structures, etc... Thus, if there is not an overwhelming desire for additional stuff, its probably best to leave the other functions to the official opencv wrappers... The last part at the bottom i'm curious if we even want. I mean we already have pylab.imshow, and we will have image io, so i dont think they are necessary. Thanks for any comments, Cheers! Chris From ralf.gommers at googlemail.com Mon Oct 12 07:59:15 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 12 Oct 2009 13:59:15 +0200 Subject: OpenImageIO In-Reply-To: <9457e7c80910120009x1622ef28j73f365c9d330110d@mail.gmail.com> References: <9457e7c80910070434w451e0737uc4ff6a98b48de439@mail.gmail.com> <9457e7c80910090248h50a69ceoe532418a4e7b528a@mail.gmail.com> <9457e7c80910092312r564dfd2dj79d99259bab3ad68@mail.gmail.com> <9457e7c80910110150t7003071fg3f3ebc03213cc1ed@mail.gmail.com> <9457e7c80910120009x1622ef28j73f365c9d330110d@mail.gmail.com> Message-ID: 2009/10/12 St?fan van der Walt > > 2009/10/12 Ralf Gommers : > >> Let me know when you're done, then I'll have a look at the patch. > > > > It's done. Nitpick away! > > Thanks, Ralf! I've merged your changes: > > http://github.com/stefanv/scikits.image/commits/ > > Thanks. I've fixed a test that broke due to the io -> collection rename, and added dtype keywords to imread and MultiImage. Defaults to None, which keeps the current behavior. Can you pull those changes as well? Cheers, Ralf > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon Oct 12 09:32:14 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 12 Oct 2009 15:32:14 +0200 Subject: OpenImageIO In-Reply-To: References: <9457e7c80910090248h50a69ceoe532418a4e7b528a@mail.gmail.com> <9457e7c80910092312r564dfd2dj79d99259bab3ad68@mail.gmail.com> <9457e7c80910110150t7003071fg3f3ebc03213cc1ed@mail.gmail.com> <9457e7c80910120009x1622ef28j73f365c9d330110d@mail.gmail.com> Message-ID: <9457e7c80910120632x6f49fc52v9281fc4e0f7c84b2@mail.gmail.com> 2009/10/12 Ralf Gommers : > Thanks. I've fixed a test that broke due to the io -> collection rename, and > added dtype keywords to imread and MultiImage. Defaults to None, which keeps > the current behavior. > > Can you pull those changes as well? Thanks, done (will push soon). In the future, it may be easier not to merge with the master branch. I'm still figuring out the best way to do this, but I think that will be easier since I can then just merge your branch, instead of cherry picking out the changes. Thanks! St?fan From ralf.gommers at googlemail.com Mon Oct 12 09:43:22 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 12 Oct 2009 15:43:22 +0200 Subject: OpenImageIO In-Reply-To: <9457e7c80910120632x6f49fc52v9281fc4e0f7c84b2@mail.gmail.com> References: <9457e7c80910090248h50a69ceoe532418a4e7b528a@mail.gmail.com> <9457e7c80910092312r564dfd2dj79d99259bab3ad68@mail.gmail.com> <9457e7c80910110150t7003071fg3f3ebc03213cc1ed@mail.gmail.com> <9457e7c80910120009x1622ef28j73f365c9d330110d@mail.gmail.com> <9457e7c80910120632x6f49fc52v9281fc4e0f7c84b2@mail.gmail.com> Message-ID: 2009/10/12 St?fan van der Walt > > 2009/10/12 Ralf Gommers : > > Thanks. I've fixed a test that broke due to the io -> collection rename, > and > > added dtype keywords to imread and MultiImage. Defaults to None, which > keeps > > the current behavior. > > > > Can you pull those changes as well? > > Thanks, done (will push soon). > > In the future, it may be easier not to merge with the master branch. > I'm still figuring out the best way to do this, but I think that will > be easier since I can then just merge your branch, instead of cherry > picking out the changes. > Hmm, not sure how else I would have fixed that test, since it only broke after you renamed io.py in the master branch. Why did you have to cherry pick, instead of just merging back my imgcollection branch into your master? Disclaimer: I am also quite new to this way of doing things. Cheers, Ralf > > Thanks! > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon Oct 12 09:48:38 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 12 Oct 2009 15:48:38 +0200 Subject: OpenImageIO In-Reply-To: References: <9457e7c80910092312r564dfd2dj79d99259bab3ad68@mail.gmail.com> <9457e7c80910110150t7003071fg3f3ebc03213cc1ed@mail.gmail.com> <9457e7c80910120009x1622ef28j73f365c9d330110d@mail.gmail.com> <9457e7c80910120632x6f49fc52v9281fc4e0f7c84b2@mail.gmail.com> Message-ID: <9457e7c80910120648l623db481t968ef1eb1751602@mail.gmail.com> 2009/10/12 Ralf Gommers : >> In the future, it may be easier not to merge with the master branch. >> I'm still figuring out the best way to do this, but I think that will >> be easier since I can then just merge your branch, instead of cherry >> picking out the changes. > > Hmm, not sure how else I would have fixed that test, since it only broke > after you renamed io.py in the master branch. Why did you have to cherry > pick, instead of just merging back my imgcollection branch into your master? > > Disclaimer: I am also quite new to this way of doing things. You could simply have created a new branch, and made your changes there. One branch per change (or related set of changes) sounds about right. If I simply merged, we would have had messages in the commit log such as: Stefan merged Ralf's branch. Ralf merged Stefan's main branch. Ralf changes this and that. Now, we just have: Stefan merged Ralf's branch. Ralf changed this and that. Have a look at these two articles: http://article.gmane.org/gmane.comp.video.dri.devel/34744 http://lwn.net/Articles/328436/ Cheers St?fan From ralf.gommers at googlemail.com Mon Oct 12 10:14:04 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 12 Oct 2009 16:14:04 +0200 Subject: OpenImageIO In-Reply-To: <9457e7c80910120648l623db481t968ef1eb1751602@mail.gmail.com> References: <9457e7c80910092312r564dfd2dj79d99259bab3ad68@mail.gmail.com> <9457e7c80910110150t7003071fg3f3ebc03213cc1ed@mail.gmail.com> <9457e7c80910120009x1622ef28j73f365c9d330110d@mail.gmail.com> <9457e7c80910120632x6f49fc52v9281fc4e0f7c84b2@mail.gmail.com> <9457e7c80910120648l623db481t968ef1eb1751602@mail.gmail.com> Message-ID: 2009/10/12 St?fan van der Walt > > 2009/10/12 Ralf Gommers : > >> In the future, it may be easier not to merge with the master branch. > >> I'm still figuring out the best way to do this, but I think that will > >> be easier since I can then just merge your branch, instead of cherry > >> picking out the changes. > > > > Hmm, not sure how else I would have fixed that test, since it only broke > > after you renamed io.py in the master branch. Why did you have to cherry > > pick, instead of just merging back my imgcollection branch into your > master? > > > > Disclaimer: I am also quite new to this way of doing things. > > You could simply have created a new branch, and made your changes > there. One branch per change (or related set of changes) sounds about > right. > > If I simply merged, we would have had messages in the commit log such as: > > Stefan merged Ralf's branch. > Ralf merged Stefan's main branch. > Ralf changes this and that. > > Now, we just have: > > Stefan merged Ralf's branch. > Ralf changed this and that. > > Have a look at these two articles: > > http://article.gmane.org/gmane.comp.video.dri.devel/34744 > http://lwn.net/Articles/328436/ > Makes sense, thanks for the lesson:) Cheers, Ralf > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Tue Oct 13 05:45:51 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 13 Oct 2009 11:45:51 +0200 Subject: plots in docs Message-ID: Hi all, Is anyone already working on getting plots in the docs? If not, I will play with that. Two other things I noticed in the docs: - missing inheritance diagrams. this works for me when building the docs, just needs graphviz installed - the link in the top corner. there is no way right now to go back to the main page (http://stefanv.github.com/scikits.image/) from the API docs. One question for working with the docs, how should I set up my git branch? I got it down for the master branch now, but got lost in the git docs about tracking other remote branches. "git fetch" doesn't grab them it seems. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Tue Oct 13 06:16:40 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 13 Oct 2009 12:16:40 +0200 Subject: plots in docs In-Reply-To: References: Message-ID: <9457e7c80910130316g55c5687bid89f094d4793ce2@mail.gmail.com> 2009/10/13 Ralf Gommers : > One question for working with the docs, how should I set up my git branch? I > got it down for the master branch now, but got lost in the git docs about > tracking other remote branches. "git fetch" doesn't grab them it seems. Thanks for working on the docs! You can simply create a new docs branch, e.g. if you already have a clone of my master do: git checkout -b docs Then fix the docs up there and push back to github (git push origin docs), from where I'll grab your changes. Don't worry about the gh-pages branch, that's just what github uses to host the pages. Cheers St?fan From sccolbert at gmail.com Tue Oct 13 06:17:35 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Tue, 13 Oct 2009 12:17:35 +0200 Subject: So I just found out that PIL will load images from a memory buffer... we should have something like this as well... Message-ID: <7f014ea60910130317j7ab3ab30t6be1a48338372266@mail.gmail.com> 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 From stefan at sun.ac.za Tue Oct 13 06:39:08 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 13 Oct 2009 12:39:08 +0200 Subject: So I just found out that PIL will load images from a memory buffer... we should have something like this as well... In-Reply-To: <7f014ea60910130317j7ab3ab30t6be1a48338372266@mail.gmail.com> References: <7f014ea60910130317j7ab3ab30t6be1a48338372266@mail.gmail.com> Message-ID: <9457e7c80910130339v5e9300eavc99e61293b7bb02e@mail.gmail.com> Hi Chris 2009/10/13 Chris Colbert : > 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. We may be able to modify imread in a trivial way to handle this. See http://projects.scipy.org/numpy/browser/trunk/numpy/lib/_datasource.py St?fan From ralf.gommers at googlemail.com Tue Oct 13 18:46:44 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 14 Oct 2009 00:46:44 +0200 Subject: plots in docs In-Reply-To: <9457e7c80910130316g55c5687bid89f094d4793ce2@mail.gmail.com> References: <9457e7c80910130316g55c5687bid89f094d4793ce2@mail.gmail.com> Message-ID: 2009/10/13 St?fan van der Walt > > You can simply create a new docs branch, e.g. if you already have a > clone of my master do: > > git checkout -b docs > > Then fix the docs up there and push back to github (git push origin > docs), from where I'll grab your changes. > > I just pushed my docs branch. It adds support for the .. plot:: directive, fixes the links on top of all pages, and some minor issues. Both inline plots and plots from script files work. For an example of the latter see the MultiImage docstring. Below I copy-pasted from the commit message, a few things to keep in mind: - for including scripts from docstrings, use prefix "../plots/", for including scripts in a rst file, use "plots/". This is due to the docs being generated from the source/api folder. - inline plots are not (yet) aware of variables being defined earlier in the Examples section. - we now use the numpydoc sphinx extensions, the original MPL ones can not be used because they have no support for the make file and conf.py not being in the same folder. There is one minor thing that does not work yet. The source code link for plots does not work because for some reason the script files are not copied to the build dir. I'll try to fix this tomorrow, and will then also add a more thorough description of how to use the plot directive to the docs. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Wed Oct 14 01:50:55 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 14 Oct 2009 07:50:55 +0200 Subject: plots in docs In-Reply-To: References: <9457e7c80910130316g55c5687bid89f094d4793ce2@mail.gmail.com> Message-ID: <9457e7c80910132250n7c21292em16ff5f3f0be1e5fe@mail.gmail.com> Hi Ralf 2009/10/14 Ralf Gommers : > I just pushed my docs branch. It adds support for the .. plot:: directive, > fixes the links on top of all pages, and some minor issues. Both inline > plots and plots from script files work. For an example of the latter see the > MultiImage docstring. Good stuff -- thanks! > ??? - for including scripts from docstrings, use prefix? "../plots/", > ????? for including scripts in a rst file, use "plots/". Fixed: you can now just specify the .py filename > There is one minor thing that does not work yet. The source code link for > plots does not work because for some reason the script files are not copied > to the build dir. Fixed. Cheers St?fan From ralf.gommers at googlemail.com Wed Oct 14 07:42:40 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 14 Oct 2009 13:42:40 +0200 Subject: plots in docs In-Reply-To: <9457e7c80910132250n7c21292em16ff5f3f0be1e5fe@mail.gmail.com> References: <9457e7c80910130316g55c5687bid89f094d4793ce2@mail.gmail.com> <9457e7c80910132250n7c21292em16ff5f3f0be1e5fe@mail.gmail.com> Message-ID: 2009/10/14 St?fan van der Walt > > Hi Ralf > > 2009/10/14 Ralf Gommers : > > I just pushed my docs branch. It adds support for the .. plot:: > directive, > > fixes the links on top of all pages, and some minor issues. Both inline > > plots and plots from script files work. For an example of the latter see > the > > MultiImage docstring. > > Good stuff -- thanks! > > > - for including scripts from docstrings, use prefix "../plots/", > > for including scripts in a rst file, use "plots/". > > Fixed: you can now just specify the .py filename > > > There is one minor thing that does not work yet. The source code link for > > plots does not work because for some reason the script files are not > copied > > to the build dir. > > Fixed. > Thanks for fixing the rest Stefan! I was fighting with the MPL plot_directive for a while, then with the numpydoc version, because I did not want to copy the whole extension into the source tree. But now I see your changes that does seem like the best way to go after all. Cheers, Ralf > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Wed Oct 14 08:29:59 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 14 Oct 2009 14:29:59 +0200 Subject: plots in docs In-Reply-To: References: <9457e7c80910130316g55c5687bid89f094d4793ce2@mail.gmail.com> <9457e7c80910132250n7c21292em16ff5f3f0be1e5fe@mail.gmail.com> Message-ID: <9457e7c80910140529r73c2677esac9c36070ea4d6d7@mail.gmail.com> 2009/10/14 Ralf Gommers : > I was fighting with the MPL plot_directive for a while, then with the > numpydoc version, because I did not want to copy the whole extension into > the source tree. But now I see your changes that does seem like the best way > to go after all. I tried the matplotlib version this morning, and when it didn't work out of the box tried to hack it into a better shape. I was very surprised to see that the quality of code in that extension deteriorated since we grabbed it for numpy! It's almost like the numpy one was written by an entirely different person (I wonder how much Pauli modded it). Either way, I think it's good to have a snapshot for our own purposed that does what we require (e.g., the extra file copy). Sometime in the future we'll look at matplotlib's extension again. Cheers St?fan From ralf.gommers at googlemail.com Wed Oct 14 10:14:53 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 14 Oct 2009 16:14:53 +0200 Subject: plots in docs In-Reply-To: <9457e7c80910140529r73c2677esac9c36070ea4d6d7@mail.gmail.com> References: <9457e7c80910130316g55c5687bid89f094d4793ce2@mail.gmail.com> <9457e7c80910132250n7c21292em16ff5f3f0be1e5fe@mail.gmail.com> <9457e7c80910140529r73c2677esac9c36070ea4d6d7@mail.gmail.com> Message-ID: 2009/10/14 St?fan van der Walt > > 2009/10/14 Ralf Gommers : > > I was fighting with the MPL plot_directive for a while, then with the > > numpydoc version, because I did not want to copy the whole extension into > > the source tree. But now I see your changes that does seem like the best > way > > to go after all. > > I tried the matplotlib version this morning, and when it didn't work > out of the box tried to hack it into a better shape. I was very > surprised to see that the quality of code in that extension > deteriorated since we grabbed it for numpy! It's almost like the > numpy one was written by an entirely different person (I wonder how > much Pauli modded it). Either way, I think it's good to have a > snapshot for our own purposed that does what we require (e.g., the > extra file copy). Sometime in the future we'll look at matplotlib's > extension again. > Sorry I should have mentioned that more clearly. I think Pauli did a lot of work on it. He also packaged it separately, so you can do: easy_install numpydoc which is how I got it to work. But you're right, having a snapshot is easier still. Cheers, Ralf > > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sccolbert at gmail.com Wed Oct 14 16:44:26 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Wed, 14 Oct 2009 22:44:26 +0200 Subject: what functions from OpenCV do you all want to see included? In-Reply-To: <7f014ea60910120458o13026e53tffdda6ff791151c3@mail.gmail.com> References: <7f014ea60910120458o13026e53tffdda6ff791151c3@mail.gmail.com> Message-ID: <7f014ea60910141344s2d0cb84s9eeb862b29f3e0bf@mail.gmail.com> Any feedback on this one? On Mon, Oct 12, 2009 at 1:58 PM, Chris Colbert wrote: > Given the existing machinery of the wrapper, the following functions > will be relatively easy to implement. > > # already implemented > > cvSobel > cvLaplace > cvCanny > cvPreCornerDetect > cvCornerEigenValsAndVecs > cvCornerMinEigenVal > cvCornerHarris > cvSmooth > > # will be implemented > > cvFindCornerSubPix > cvGoodFeaturesToTrack > cvResize > cvWarpAffine > cvWarpPerspective > cvRemap > cvLogPolar > cvErode > cvDilate > cvMorphologyEx > cvFilter2D > cvIntegral > cvCvtColor > cvThreshold > cvAdaptiveThreshold > cvPyrDown > cvPyrUp > cvPyrMeanShiftFiltering > cvWatershed > cvDistTransform > cvInpaint > cvMatchTemplate > cvContourArea > cvArcLength > cvPointPolygonTest > cvMinAreaRect2 > cvMinEnclosingCircle > cvCalcOpticalFlowHS > cvCalcOpticalFlowLK > cvCalcOpticalFlowBM > cvCalcOpticalFlowPyrLK > cvFindStereoCorrespondence > > # misc - do we want these > -use highgui for an imshow type function > -use highgui for image IO > -use highgui for video IO > > > > If have a hankering desire for some other OpenCV function to be > included, please speak up. Adding function other than what is shown > here is possible, but its a lot more work that requires implementing > new data structures, etc... Thus, if there is not an overwhelming > desire for additional stuff, its probably best to leave the other > functions to the official opencv wrappers... > > The last part at the bottom i'm curious if we even want. I mean we > already have pylab.imshow, and we will have image io, so i dont think > they are necessary. > > Thanks for any comments, > > Cheers! > > Chris > From sirver at gmx.de Thu Oct 15 02:43:05 2009 From: sirver at gmx.de (SirVer) Date: Wed, 14 Oct 2009 23:43:05 -0700 (PDT) Subject: what functions from OpenCV do you all want to see included? In-Reply-To: <7f014ea60910120458o13026e53tffdda6ff791151c3@mail.gmail.com> References: <7f014ea60910120458o13026e53tffdda6ff791151c3@mail.gmail.com> Message-ID: <9cb30d14-8013-40bd-9ad2-bf3f25efac15@b2g2000yqi.googlegroups.com> I definitely would love to have a calibration toolkit. I currently have a wrapper around opencv in my own (very small) python image processing toolbox that I need for my work. It detects checkerboxes in images and allows to use/discard individual images quickly. To calibrate a camera only takes 50pics of a checkerboard and 5 minutes. I'd really like to loose the opencv dependency because I do not use it except for the checkerboard finder (which is lousy in OpenCV), the subpixel edge detector and the undistortion framework (which is acceptable). If anyone implements this in the scikit, I volunteer to contribute the GUI script as userland tool (does depend on PyQt though). as for highgui and similar, I feel that there is very much good GUI Software out there for python (PyQt which is the best, wxpython, tkinter). I feel it would be a bit wasteful to wrap the highgui stuff. Just my 2c From sirver at gmx.de Thu Oct 15 02:53:56 2009 From: sirver at gmx.de (SirVer) Date: Wed, 14 Oct 2009 23:53:56 -0700 (PDT) Subject: Bug reports in documentation Message-ID: Hi, i was unable to file a bug on github as was suggested in TASK.txt. Where is the correct place? nevertheless: the code contains a lot of wrong references to scikit.gpu, for example in the README and in the documentation: ------------------- SNIP ------------------- $ grep scikits.gpu -R . ./doc/build/html/_sources/install.txt:`http://github.com/stefanv/ scikits.gpu ./doc/build/html/_sources/install.txt:`_. ./doc/build/html/_sources/overview.txt:http://github.com/stefanv/ scikits.gpu ./doc/build/html/install.html:http://github.com/stefanv/ scikits.gpu.

./doc/build/html/overview.html:

http://github.com/stefanv/ scikits.gpu

./doc/source/install.txt:`http://github.com/stefanv/scikits.gpu ./doc/source/install.txt:`_. ./doc/source/overview.txt:http://github.com/stefanv/scikits.gpu ./README.txt:http://github.com/stefanv/scikits.gpu ------------------- SNAP ------------------- I am not familiar with git, otherwise I would push a branch. Cheers, Holger From sirver at gmx.de Thu Oct 15 07:50:29 2009 From: sirver at gmx.de (SirVer) Date: Thu, 15 Oct 2009 04:50:29 -0700 (PDT) Subject: OpenCV Calibration Wrapping - Some questions Message-ID: <86a53fb1-18e4-4d70-b462-b1664b7ae241@j24g2000yqa.googlegroups.com> I just mentioned some hours ago that I wanted to have the OpenCV calibration tools at my fingertips. Well, I decided to give it a go myself and started by wrapping cvFindChessboard and cvDrawChessboard. This already took a while since I am not very familiar with cython (yet?); nevertheless I pushed a github branch - I hope I did everything correctly, I was working the first time with git. You can find the branch here: http://github.com/SirVer/scikits.image/network I also send you a merge request. Some questions remain for me though: 1) Where do convenience wrappers go? The OpenCv is terrible to use. I'd like to offer a more Pythonic interface to the stuff I am currently wrapping. An Example would be an ImageUndistorter class that would offer a single interface to undistort multiple Images in a Row. Where should this go? obviously into the opencv module, but how should this module be sorted? 2) Utility scripts I'd like to contribute my camcalib script which I wrote for intrinsic calibration of monoscopic cameras. I wrapped the opencv with Ctypes for that; obviously I will first add the needed functions to the current opencv wrapper. The first question here is were do those scripts live so that the user can easily start them as soon as the scikit is installed? 3) GUI dependency. I use Pyqt for all my image processing tools because it is very fast (200 fps is no problem to display) and because it is very convenient. I feel that a image scikit should provide some GUI functionality (what good is image processing without seeing images?) and I would urge to investigate PyQt. With this question, I just want to get the ball rolling; I feel the discussing of wether GUI tools are wanted or not and which toolkit to use or not might be crucial for the evolution of the image scikit. Cheers, Holger From sirver at gmx.de Thu Oct 15 08:29:57 2009 From: sirver at gmx.de (SirVer) Date: Thu, 15 Oct 2009 05:29:57 -0700 (PDT) Subject: OpenCV Calibration Wrapping - Some questions In-Reply-To: <7f014ea60910150514k229886bcmbd721e03bc19f869@mail.gmail.com> References: <86a53fb1-18e4-4d70-b462-b1664b7ae241@j24g2000yqa.googlegroups.com> <7f014ea60910150507k617eef0bl1223a3f60d28b5c9@mail.gmail.com> <7f014ea60910150514k229886bcmbd721e03bc19f869@mail.gmail.com> Message-ID: Hi Chris, On 15 Okt., 14:14, Chris Colbert wrote: > Man Holger, I must say (I just read your code on git), you picked up > my code an ran with it quite well! Impressive! Thanks :). Been in the game for a while. > There are only a few things (semantic) that I would change. But they > are long-winded to explain here. I will investigate and try to adapt. My programming style is a mix of PEP 8 and the numpy docstring conventions. But I usually just go with the flow. > > At any rate, fork my git branch, and push your changes to that. Then > send me a pull request and I will make the semantic changes and a unit > test. I'd love to do that by I need a kickstart in git. What i did now in my clone of Stefans branch was: $ git remote add chris git://github.com/sccolbert/scikits.image.git $ git fetch chris ~/Desktop/Promotion/prog/ scikit_image_sccolbert >From git://github.com/sccolbert/scikits.image * [new branch] gh-pages -> chris/gh-pages * [new branch] homography -> chris/homography * [new branch] master -> chris/master $ git merge chris/master Already up-to-date. Therefore my current branch on github is the most recent one (I guess), can't you merge from this? > > Also go ahead and create the utilities sub-dir if want... I will, but some more cvFunctions need wrapping for this. Cheers, Holger > > On Thu, Oct 15, 2009 at 2:07 PM, Chris Colbert wrote: > > So we can keep all opencv stuff together, I would suggest that you > > make a fork of my branch: > > >http://github.com/sccolbert/scikits.image > > > most all of the machinery to wrap the opencv functions from cython is > > already there. Take a look through the source to see how it's done. > > (It's fairly self documenting). > > > The way I have been going about the wrapping is that each function > > (more or less) allows the user to do things the opencv way or the > > python way. That is, you can pass in an out argument, but if you dont, > > I create an appropriate one for you. > > > I would like to keep everything under /opencv/, pure opencv routines. > > If you want to add some higher level convienence routines, I would > > make a subdirectory: ?/opencv/utilities/ ?and put them in there. Try > > to use as much of the existing opencv-cython machinery as possible. No > > need to reinvent the wheel, and it will just make things harder to > > maintain. > > > Cheers, > > > Chris > > > On Thu, Oct 15, 2009 at 1:50 PM, SirVer wrote: > > >> I just mentioned some hours ago that I wanted to have the OpenCV > >> calibration tools at my fingertips. Well, I decided to give it a go > >> myself and started by wrapping cvFindChessboard and cvDrawChessboard. > >> This already took a while since I am not very familiar with cython > >> (yet?); nevertheless I pushed a github branch - I hope I did > >> everything correctly, I was working the first time with git. You can > >> find the branch here: > >>http://github.com/SirVer/scikits.image/network > > >> I also send you a merge request. > > >> Some questions remain for me though: > >> 1) Where do convenience wrappers go? > >> The OpenCv is terrible to use. I'd like to offer a more Pythonic > >> interface to the stuff I am currently wrapping. An Example would be an > >> ImageUndistorter class that would offer a single interface to > >> undistort multiple Images in a Row. Where should this go? obviously > >> into the opencv module, but how should this module be sorted? > > >> 2) Utility scripts > >> I'd like to contribute my camcalib script which I wrote for intrinsic > >> calibration of monoscopic cameras. I wrapped the opencv with Ctypes > >> for that; obviously I will first add the needed functions to the > >> current opencv wrapper. The first question here is were do those > >> scripts live so that the user can easily start them as soon as the > >> scikit is installed? > > >> 3) GUI dependency. > >> I use Pyqt for all my image processing tools because it is very fast > >> (200 fps is no problem to display) and because it is very convenient. > >> I feel that a image scikit should provide some GUI functionality (what > >> good is image processing without seeing images?) and I would urge to > >> investigate PyQt. With this question, I just want to get the ball > >> rolling; I feel the discussing of wether GUI tools are wanted or not > >> and which toolkit to use or not might be crucial for the evolution of > >> the image scikit. > > >> Cheers, > >> Holger From stefan at sun.ac.za Thu Oct 15 01:17:30 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 15 Oct 2009 07:17:30 +0200 Subject: what functions from OpenCV do you all want to see included? In-Reply-To: <7f014ea60910141344s2d0cb84s9eeb862b29f3e0bf@mail.gmail.com> References: <7f014ea60910120458o13026e53tffdda6ff791151c3@mail.gmail.com> <7f014ea60910141344s2d0cb84s9eeb862b29f3e0bf@mail.gmail.com> Message-ID: <9457e7c80910142217h7318ca4apfca05cbc08e3bb5b@mail.gmail.com> 2009/10/14 Chris Colbert : > > Any feedback on this one? If this set is significantly easier to implement than the others, it's a good place to start! I see that most of the functions I find useful are included already. Cheers St?fan From sirver at gmx.de Thu Oct 15 11:10:35 2009 From: sirver at gmx.de (SirVer) Date: Thu, 15 Oct 2009 08:10:35 -0700 (PDT) Subject: OpenCV Calibration Wrapping - Some questions In-Reply-To: <9457e7c80910150631m7b1d91c9y703258b8cb004001@mail.gmail.com> References: <86a53fb1-18e4-4d70-b462-b1664b7ae241@j24g2000yqa.googlegroups.com> <9457e7c80910150631m7b1d91c9y703258b8cb004001@mail.gmail.com> Message-ID: <8d848745-a8fa-4d74-8a9d-f0022974da4c@f16g2000yqm.googlegroups.com> Hi, > I see you looked a the C-library loading routines. ?If possible, we > should try and re-use > > numpy.ctypeslib.load_library Afaik the loading of the library is only to check if the library really is there. Nevertheless, on MacOS X it is needed to probe many paths for the library, since there is no ldconfig or similar. replacing ctypes.CDLL throuhg ctypeslib.load_library is not a problem. > > Some questions remain for me though: > > 1) Where do convenience wrappers go? > > The OpenCv is terrible to use. I'd like to offer a more Pythonic > > interface to the stuff I am currently wrapping. An Example would be an > > ImageUndistorter class that would offer a single interface to > > undistort multiple Images in a Row. Where should this go? obviously > > into the opencv module, but how should this module be sorted? > > We have to be careful with the scope of the scikit, which is to > implement basic tools needed for image processing. ?For example, the > above result may be obtained by combining > scikits.image.io.ImageCollection with the opencv wrapper, instead of > writing a custom class. ?It's worth answering the question: what is > the fundamental set of tools users would need to obtain results/do > research. Year, what is it? My scope is naturally a bit wider here I guess: I'd like to have as many tools for image processing available to me as possible. This would even contain image acquisition (Actually, I have a quite healthy ctypes wrapper around libdc1394 2.0 which you can find on launchpad. This + ctypes can do fun stuff: http://www.youtube.com/watch?gl=DE&hl=de&v=5O4FrRujlII) and GUI Stuff. But (intrinsic) camera calibration is (for me) fundamental: All Images come from one camera or another and (intrinsic) calibration is needed for all kind of measuring applications with images. > > 2) Utility scripts > > I'd like to contribute my camcalib script which I wrote for intrinsic > > calibration of monoscopic cameras. I wrapped the opencv with Ctypes > > for that; obviously I will first add the needed functions to the > > current opencv wrapper. The first question here is were do those > > scripts live so that the user can easily start them as soon as the > > scikit is installed? > > Does camera calibration fall under the umbrella of image processing? > The reason I ask is because we're trying to get another project off > the ground with Andrew Straw: > > https://launchpad.net/pinpoint I am not so much into stereo. I only need intrinsic calibration; I feel this is fundamental. > > > 3) GUI dependency. > > I use Pyqt for all my image processing tools because it is very fast > > (200 fps is no problem to display) and because it is very convenient. > > I feel that a image scikit should provide some GUI functionality (what > > good is image processing without seeing images?) and I would urge to > > investigate PyQt. With this question, I just want to get the ball > > rolling; I feel the discussing of wether GUI tools are wanted or not > > and which toolkit to use or not might be crucial for the evolution of > > the image scikit. > > A while ago we discussed implementing a plugin system for image IO. I haven't followed this discussion. What is the reason to not depend on PIL? Every Image Processor I know whos using python has PIL installed; even scipy uses it via misc.scipy.pilutil. > We may want to do something similar for image display. ?At the moment, > I mostly use matplotlib do display images, but for faster displaying a > QT-based GUI may be worth it. ?I want us to keep dependencies at a > minimum, so we could follow a similar route to the new opencv module: > compile wrappers, but only load those once the library becomes > available. So we could add support for a set of GUI functions that are just not available when pyqt (or in a very near future pyside) is not available. Good for me, that's the python way to do things anyway. Cheers, Holger From stefan at sun.ac.za Thu Oct 15 03:02:01 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 15 Oct 2009 09:02:01 +0200 Subject: Bug reports in documentation In-Reply-To: References: Message-ID: <9457e7c80910150002h310f3135i2319f3a2b13927c2@mail.gmail.com> Hi Holger, Thanks for the report! This is now fixed in my branch and will be pushed soon. Cheers St?fan 2009/10/15 SirVer : > i was unable to file a bug on github as was suggested in TASK.txt. > Where is the correct place? > > nevertheless: the code contains a lot of wrong references to > scikit.gpu, for example in the README and in the documentation: From sccolbert at gmail.com Thu Oct 15 08:07:06 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Thu, 15 Oct 2009 14:07:06 +0200 Subject: OpenCV Calibration Wrapping - Some questions In-Reply-To: <86a53fb1-18e4-4d70-b462-b1664b7ae241@j24g2000yqa.googlegroups.com> References: <86a53fb1-18e4-4d70-b462-b1664b7ae241@j24g2000yqa.googlegroups.com> Message-ID: <7f014ea60910150507k617eef0bl1223a3f60d28b5c9@mail.gmail.com> So we can keep all opencv stuff together, I would suggest that you make a fork of my branch: http://github.com/sccolbert/scikits.image most all of the machinery to wrap the opencv functions from cython is already there. Take a look through the source to see how it's done. (It's fairly self documenting). The way I have been going about the wrapping is that each function (more or less) allows the user to do things the opencv way or the python way. That is, you can pass in an out argument, but if you dont, I create an appropriate one for you. I would like to keep everything under /opencv/, pure opencv routines. If you want to add some higher level convienence routines, I would make a subdirectory: /opencv/utilities/ and put them in there. Try to use as much of the existing opencv-cython machinery as possible. No need to reinvent the wheel, and it will just make things harder to maintain. Cheers, Chris On Thu, Oct 15, 2009 at 1:50 PM, SirVer wrote: > > I just mentioned some hours ago that I wanted to have the OpenCV > calibration tools at my fingertips. Well, I decided to give it a go > myself and started by wrapping cvFindChessboard and cvDrawChessboard. > This already took a while since I am not very familiar with cython > (yet?); nevertheless I pushed a github branch - I hope I did > everything correctly, I was working the first time with git. You can > find the branch here: > http://github.com/SirVer/scikits.image/network > > I also send you a merge request. > > > Some questions remain for me though: > 1) Where do convenience wrappers go? > The OpenCv is terrible to use. I'd like to offer a more Pythonic > interface to the stuff I am currently wrapping. An Example would be an > ImageUndistorter class that would offer a single interface to > undistort multiple Images in a Row. Where should this go? obviously > into the opencv module, but how should this module be sorted? > > 2) Utility scripts > I'd like to contribute my camcalib script which I wrote for intrinsic > calibration of monoscopic cameras. I wrapped the opencv with Ctypes > for that; obviously I will first add the needed functions to the > current opencv wrapper. The first question here is were do those > scripts live so that the user can easily start them as soon as the > scikit is installed? > > 3) GUI dependency. > I use Pyqt for all my image processing tools because it is very fast > (200 fps is no problem to display) and because it is very convenient. > I feel that a image scikit should provide some GUI functionality (what > good is image processing without seeing images?) and I would urge to > investigate PyQt. With this question, I just want to get the ball > rolling; I feel the discussing of wether GUI tools are wanted or not > and which toolkit to use or not might be crucial for the evolution of > the image scikit. > > Cheers, > Holger > > > From sccolbert at gmail.com Thu Oct 15 08:14:01 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Thu, 15 Oct 2009 14:14:01 +0200 Subject: OpenCV Calibration Wrapping - Some questions In-Reply-To: <7f014ea60910150507k617eef0bl1223a3f60d28b5c9@mail.gmail.com> References: <86a53fb1-18e4-4d70-b462-b1664b7ae241@j24g2000yqa.googlegroups.com> <7f014ea60910150507k617eef0bl1223a3f60d28b5c9@mail.gmail.com> Message-ID: <7f014ea60910150514k229886bcmbd721e03bc19f869@mail.gmail.com> Man Holger, I must say (I just read your code on git), you picked up my code an ran with it quite well! Impressive! There are only a few things (semantic) that I would change. But they are long-winded to explain here. At any rate, fork my git branch, and push your changes to that. Then send me a pull request and I will make the semantic changes and a unit test. Also go ahead and create the utilities sub-dir if want... Cheers! Chris On Thu, Oct 15, 2009 at 2:07 PM, Chris Colbert wrote: > So we can keep all opencv stuff together, I would suggest that you > make a fork of my branch: > > http://github.com/sccolbert/scikits.image > > most all of the machinery to wrap the opencv functions from cython is > already there. Take a look through the source to see how it's done. > (It's fairly self documenting). > > The way I have been going about the wrapping is that each function > (more or less) allows the user to do things the opencv way or the > python way. That is, you can pass in an out argument, but if you dont, > I create an appropriate one for you. > > I would like to keep everything under /opencv/, pure opencv routines. > If you want to add some higher level convienence routines, I would > make a subdirectory: ?/opencv/utilities/ ?and put them in there. Try > to use as much of the existing opencv-cython machinery as possible. No > need to reinvent the wheel, and it will just make things harder to > maintain. > > Cheers, > > Chris > > On Thu, Oct 15, 2009 at 1:50 PM, SirVer wrote: >> >> I just mentioned some hours ago that I wanted to have the OpenCV >> calibration tools at my fingertips. Well, I decided to give it a go >> myself and started by wrapping cvFindChessboard and cvDrawChessboard. >> This already took a while since I am not very familiar with cython >> (yet?); nevertheless I pushed a github branch - I hope I did >> everything correctly, I was working the first time with git. You can >> find the branch here: >> http://github.com/SirVer/scikits.image/network >> >> I also send you a merge request. >> >> >> Some questions remain for me though: >> 1) Where do convenience wrappers go? >> The OpenCv is terrible to use. I'd like to offer a more Pythonic >> interface to the stuff I am currently wrapping. An Example would be an >> ImageUndistorter class that would offer a single interface to >> undistort multiple Images in a Row. Where should this go? obviously >> into the opencv module, but how should this module be sorted? >> >> 2) Utility scripts >> I'd like to contribute my camcalib script which I wrote for intrinsic >> calibration of monoscopic cameras. I wrapped the opencv with Ctypes >> for that; obviously I will first add the needed functions to the >> current opencv wrapper. The first question here is were do those >> scripts live so that the user can easily start them as soon as the >> scikit is installed? >> >> 3) GUI dependency. >> I use Pyqt for all my image processing tools because it is very fast >> (200 fps is no problem to display) and because it is very convenient. >> I feel that a image scikit should provide some GUI functionality (what >> good is image processing without seeing images?) and I would urge to >> investigate PyQt. With this question, I just want to get the ball >> rolling; I feel the discussing of wether GUI tools are wanted or not >> and which toolkit to use or not might be crucial for the evolution of >> the image scikit. >> >> Cheers, >> Holger >> >> >> > From ralf.gommers at googlemail.com Thu Oct 15 08:18:52 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 15 Oct 2009 14:18:52 +0200 Subject: OpenCV Calibration Wrapping - Some questions In-Reply-To: <86a53fb1-18e4-4d70-b462-b1664b7ae241@j24g2000yqa.googlegroups.com> References: <86a53fb1-18e4-4d70-b462-b1664b7ae241@j24g2000yqa.googlegroups.com> Message-ID: On Thu, Oct 15, 2009 at 1:50 PM, SirVer wrote: > 3) GUI dependency. > I use Pyqt for all my image processing tools because it is very fast > (200 fps is no problem to display) and because it is very convenient. > I feel that a image scikit should provide some GUI functionality (what > good is image processing without seeing images?) and I would urge to > investigate PyQt. With this question, I just want to get the ball > rolling; I feel the discussing of wether GUI tools are wanted or not > and which toolkit to use or not might be crucial for the evolution of > the image scikit. > > Note that PyQt is GPL licensed, with an exception to allow BSD/MIT code that calls PyQt. But it does mean we can not include PyQt itself, which may be limiting. If some GUI functionality is wanted at all is a separate question of course. It feels a bit orthogonal to the stated goal of providing image processing algorithms. Cheers, Ralf Cheers, > Holger > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sccolbert at gmail.com Thu Oct 15 08:26:31 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Thu, 15 Oct 2009 14:26:31 +0200 Subject: OpenCV Calibration Wrapping - Some questions In-Reply-To: References: <86a53fb1-18e4-4d70-b462-b1664b7ae241@j24g2000yqa.googlegroups.com> Message-ID: <7f014ea60910150526y907ac49ue7e1f41132a55abe@mail.gmail.com> There are new python bindings for QT 'PySide' which is LGPL.... that may or may not help... I'm licensing ignorant. On Thu, Oct 15, 2009 at 2:18 PM, Ralf Gommers wrote: > > > On Thu, Oct 15, 2009 at 1:50 PM, SirVer wrote: >> >> 3) GUI dependency. >> I use Pyqt for all my image processing tools because it is very fast >> (200 fps is no problem to display) and because it is very convenient. >> I feel that a image scikit should provide some GUI functionality (what >> good is image processing without seeing images?) and I would urge to >> investigate PyQt. With this question, I just want to get the ball >> rolling; I feel the discussing of wether GUI tools are wanted or not >> and which toolkit to use or not might be crucial for the evolution of >> the image scikit. >> > Note that PyQt is GPL licensed, with an exception to allow BSD/MIT code that > calls PyQt. But it does mean we can not include PyQt itself, which may be > limiting. > > If some GUI functionality is wanted at all is a separate question of course. > It feels a bit orthogonal to the stated goal of providing image processing > algorithms. > > Cheers, > Ralf > >> Cheers, >> Holger >> >> > > From stefan at sun.ac.za Thu Oct 15 08:45:21 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 15 Oct 2009 14:45:21 +0200 Subject: OpenCV Calibration Wrapping - Some questions In-Reply-To: References: <86a53fb1-18e4-4d70-b462-b1664b7ae241@j24g2000yqa.googlegroups.com> <7f014ea60910150507k617eef0bl1223a3f60d28b5c9@mail.gmail.com> <7f014ea60910150514k229886bcmbd721e03bc19f869@mail.gmail.com> Message-ID: <9457e7c80910150545h2784a13ds276f46cc76bccecd@mail.gmail.com> 2009/10/15 SirVer : > I'd love to do that by I need a kickstart in git. What i did now in my > clone of Stefans branch was: At the moment, I have a very short write-up at http://stefanv.github.com/scikits.image/contribute.html#development-process but if you give me some feedback I'd gladly expand. I'm also new at the git-helm, but from what I've seen collaboration becomes a lot easier if there aren't merged between all parties involved. I.e., when working together, pick a patch manager so that patches flow in one direction. I can then pull from that person, without seeing hundreds of "merged me with you", "merged you with me" type things going on. Cheers St?fan From sccolbert at gmail.com Thu Oct 15 08:46:25 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Thu, 15 Oct 2009 14:46:25 +0200 Subject: OpenCV Calibration Wrapping - Some questions In-Reply-To: References: <86a53fb1-18e4-4d70-b462-b1664b7ae241@j24g2000yqa.googlegroups.com> <7f014ea60910150507k617eef0bl1223a3f60d28b5c9@mail.gmail.com> <7f014ea60910150514k229886bcmbd721e03bc19f869@mail.gmail.com> Message-ID: <7f014ea60910150546r403e73bcsdb7b64e17110dcb6@mail.gmail.com> what I would do is just backup the code you've written somewhere outside of your current local git repo. Then delete your current fork (the fork from stefan) on github. Then fork my branch. then create yourself a new local git repo from that: git clone git at github.com:yourusername/yourfork.git # you can get this line from your fork at github then add an upstream repo (mine) so you can keep in synch with my branch (which will be kept in synch with the main branch) git remote add upstream git://github.com/sccolbert/scikits.image.git then when you make changes just do: git push origin master then make a pull request from github so i can pull your changes into my branch. I can then make a pull request to Stefan once everything is tested. and here is the guide on how to sync your branch with my updates: http://github.com/guides/keeping-a-git-fork-in-sync-with-the-forked-repo Let me know if that didnt make sense: Cheers! Chris On Thu, Oct 15, 2009 at 2:29 PM, SirVer wrote: > > Hi Chris, > > On 15 Okt., 14:14, Chris Colbert wrote: >> Man Holger, I must say (I just read your code on git), you picked up >> my code an ran with it quite well! Impressive! > Thanks :). Been in the game for a while. > > >> There are only a few things (semantic) that I would change. But they >> are long-winded to explain here. > I will investigate and try to adapt. My programming style is a mix of > PEP 8 and the numpy docstring conventions. But I usually just go with > the flow. > > >> >> At any rate, fork my git branch, and push your changes to that. Then >> send me a pull request and I will make the semantic changes and a unit >> test. > I'd love to do that by I need a kickstart in git. What i did now in my > clone of Stefans branch was: > $ git remote add chris ?git://github.com/sccolbert/scikits.image.git > $ git fetch chris ? ? ? ~/Desktop/Promotion/prog/ > scikit_image_sccolbert > From git://github.com/sccolbert/scikits.image > ?* [new branch] ? ? ?gh-pages ? -> chris/gh-pages > ?* [new branch] ? ? ?homography -> chris/homography > ?* [new branch] ? ? ?master ? ? -> chris/master > $ git merge chris/master > Already up-to-date. > > Therefore my current branch on github is the most recent one (I > guess), > can't you merge from this? > >> >> Also go ahead and create the utilities sub-dir if want... > I will, but some more cvFunctions need wrapping for this. > > Cheers, > Holger > >> >> On Thu, Oct 15, 2009 at 2:07 PM, Chris Colbert wrote: >> > So we can keep all opencv stuff together, I would suggest that you >> > make a fork of my branch: >> >> >http://github.com/sccolbert/scikits.image >> >> > most all of the machinery to wrap the opencv functions from cython is >> > already there. Take a look through the source to see how it's done. >> > (It's fairly self documenting). >> >> > The way I have been going about the wrapping is that each function >> > (more or less) allows the user to do things the opencv way or the >> > python way. That is, you can pass in an out argument, but if you dont, >> > I create an appropriate one for you. >> >> > I would like to keep everything under /opencv/, pure opencv routines. >> > If you want to add some higher level convienence routines, I would >> > make a subdirectory: ?/opencv/utilities/ ?and put them in there. Try >> > to use as much of the existing opencv-cython machinery as possible. No >> > need to reinvent the wheel, and it will just make things harder to >> > maintain. >> >> > Cheers, >> >> > Chris >> >> > On Thu, Oct 15, 2009 at 1:50 PM, SirVer wrote: >> >> >> I just mentioned some hours ago that I wanted to have the OpenCV >> >> calibration tools at my fingertips. Well, I decided to give it a go >> >> myself and started by wrapping cvFindChessboard and cvDrawChessboard. >> >> This already took a while since I am not very familiar with cython >> >> (yet?); nevertheless I pushed a github branch - I hope I did >> >> everything correctly, I was working the first time with git. You can >> >> find the branch here: >> >>http://github.com/SirVer/scikits.image/network >> >> >> I also send you a merge request. >> >> >> Some questions remain for me though: >> >> 1) Where do convenience wrappers go? >> >> The OpenCv is terrible to use. I'd like to offer a more Pythonic >> >> interface to the stuff I am currently wrapping. An Example would be an >> >> ImageUndistorter class that would offer a single interface to >> >> undistort multiple Images in a Row. Where should this go? obviously >> >> into the opencv module, but how should this module be sorted? >> >> >> 2) Utility scripts >> >> I'd like to contribute my camcalib script which I wrote for intrinsic >> >> calibration of monoscopic cameras. I wrapped the opencv with Ctypes >> >> for that; obviously I will first add the needed functions to the >> >> current opencv wrapper. The first question here is were do those >> >> scripts live so that the user can easily start them as soon as the >> >> scikit is installed? >> >> >> 3) GUI dependency. >> >> I use Pyqt for all my image processing tools because it is very fast >> >> (200 fps is no problem to display) and because it is very convenient. >> >> I feel that a image scikit should provide some GUI functionality (what >> >> good is image processing without seeing images?) and I would urge to >> >> investigate PyQt. With this question, I just want to get the ball >> >> rolling; I feel the discussing of wether GUI tools are wanted or not >> >> and which toolkit to use or not might be crucial for the evolution of >> >> the image scikit. >> >> >> Cheers, >> >> Holger From stefan at sun.ac.za Thu Oct 15 09:31:26 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 15 Oct 2009 15:31:26 +0200 Subject: OpenCV Calibration Wrapping - Some questions In-Reply-To: <86a53fb1-18e4-4d70-b462-b1664b7ae241@j24g2000yqa.googlegroups.com> References: <86a53fb1-18e4-4d70-b462-b1664b7ae241@j24g2000yqa.googlegroups.com> Message-ID: <9457e7c80910150631m7b1d91c9y703258b8cb004001@mail.gmail.com> Hi Holger, 2009/10/15 SirVer : > I just mentioned some hours ago that I wanted to have the OpenCV > calibration tools at my fingertips. Well, I decided to give it a go > myself and started by wrapping cvFindChessboard and cvDrawChessboard. Thanks for contributing! > This already took a while since I am not very familiar with cython > (yet?); nevertheless I pushed a github branch - I hope I did > everything correctly, I was working the first time with git. You can > find the branch here: > http://github.com/SirVer/scikits.image/network I see you looked a the C-library loading routines. If possible, we should try and re-use numpy.ctypeslib.load_library If it does not work as expected, we can always contribute a patch (whilst keeping a fixed version in our repo). > Some questions remain for me though: > 1) Where do convenience wrappers go? > The OpenCv is terrible to use. I'd like to offer a more Pythonic > interface to the stuff I am currently wrapping. An Example would be an > ImageUndistorter class that would offer a single interface to > undistort multiple Images in a Row. Where should this go? obviously > into the opencv module, but how should this module be sorted? We have to be careful with the scope of the scikit, which is to implement basic tools needed for image processing. For example, the above result may be obtained by combining scikits.image.io.ImageCollection with the opencv wrapper, instead of writing a custom class. It's worth answering the question: what is the fundamental set of tools users would need to obtain results/do research. Your specific example may be different; it's just a point I wanted to raise. > 2) Utility scripts > I'd like to contribute my camcalib script which I wrote for intrinsic > calibration of monoscopic cameras. I wrapped the opencv with Ctypes > for that; obviously I will first add the needed functions to the > current opencv wrapper. The first question here is were do those > scripts live so that the user can easily start them as soon as the > scikit is installed? Does camera calibration fall under the umbrella of image processing? The reason I ask is because we're trying to get another project off the ground with Andrew Straw: https://launchpad.net/pinpoint > 3) GUI dependency. > I use Pyqt for all my image processing tools because it is very fast > (200 fps is no problem to display) and because it is very convenient. > I feel that a image scikit should provide some GUI functionality (what > good is image processing without seeing images?) and I would urge to > investigate PyQt. With this question, I just want to get the ball > rolling; I feel the discussing of wether GUI tools are wanted or not > and which toolkit to use or not might be crucial for the evolution of > the image scikit. A while ago we discussed implementing a plugin system for image IO. We may want to do something similar for image display. At the moment, I mostly use matplotlib do display images, but for faster displaying a QT-based GUI may be worth it. I want us to keep dependencies at a minimum, so we could follow a similar route to the new opencv module: compile wrappers, but only load those once the library becomes available. Given that Nokia officially released PySide, I'm afraid PyQT may be starving a slow death. Luckily, it seems as though you can simply (for now, at least) replace the PyQT import with PySide. Cheers St?fan From sirver at gmx.de Fri Oct 16 07:52:06 2009 From: sirver at gmx.de (SirVer) Date: Fri, 16 Oct 2009 04:52:06 -0700 (PDT) Subject: OpenCV Calibration Wrapping - Some questions In-Reply-To: References: <86a53fb1-18e4-4d70-b462-b1664b7ae241@j24g2000yqa.googlegroups.com> <9457e7c80910150631m7b1d91c9y703258b8cb004001@mail.gmail.com> <8d848745-a8fa-4d74-8a9d-f0022974da4c@f16g2000yqm.googlegroups.com> Message-ID: <5c8ae5f4-8836-4330-8502-af047392007f@x37g2000yqj.googlegroups.com> > find one then. Will definitely play with yours if I get the chance! The launchpad version is not completly up to date; i did some changes and switched repositories.. I will eventually incorporate them. For now, it should work. Please feel free to join in the effort to make it better ;) > > > > > > > > > > > 3) GUI dependency. > > > > I use Pyqt for all my image processing tools because it is very fast > > > > (200 fps is no problem to display) and because it is very convenient. > > > > I feel that a image scikit should provide some GUI functionality (what > > > > good is image processing without seeing images?) and I would urge to > > > > investigate PyQt. With this question, I just want to get the ball > > > > rolling; I feel the discussing of wether GUI tools are wanted or not > > > > and which toolkit to use or not might be crucial for the evolution of > > > > the image scikit. > > > > A while ago we discussed implementing a plugin system for image IO. > > I haven't followed this discussion. What is the reason to not depend > > on PIL? > > Every Image Processor I know whos using python has PIL installed; even > > scipy > > uses it via misc.scipy.pilutil. > > PIL has some issues, with 16-bit images and with multi-page images. More > importantly, it has a completely broken development model. We discussed this > a while ago, see:http://groups.google.com/group/scikits-image/browse_thread/thread/76a... > > > We may want to do something similar for image display. ?At the moment, > > > I mostly use matplotlib do display images, but for faster displaying a > > > QT-based GUI may be worth it. ?I want us to keep dependencies at a > > > minimum, so we could follow a similar route to the new opencv module: > > > compile wrappers, but only load those once the library becomes > > > available. > > So we could add support for a set of GUI functions that are just not > > available > > when pyqt (or in a very near future pyside) is not available. Good for > > me, > > that's the python way to do things anyway. > > Sounds good to me. > > Cheers, > Ralf > > > > > > > Cheers, > > Holger From ralf.gommers at googlemail.com Fri Oct 16 07:46:56 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 16 Oct 2009 13:46:56 +0200 Subject: OpenCV Calibration Wrapping - Some questions In-Reply-To: <8d848745-a8fa-4d74-8a9d-f0022974da4c@f16g2000yqm.googlegroups.com> References: <86a53fb1-18e4-4d70-b462-b1664b7ae241@j24g2000yqa.googlegroups.com> <9457e7c80910150631m7b1d91c9y703258b8cb004001@mail.gmail.com> <8d848745-a8fa-4d74-8a9d-f0022974da4c@f16g2000yqm.googlegroups.com> Message-ID: On Thu, Oct 15, 2009 at 5:10 PM, SirVer wrote: > > > We have to be careful with the scope of the scikit, which is to > > implement basic tools needed for image processing. For example, the > > above result may be obtained by combining > > scikits.image.io.ImageCollection with the opencv wrapper, instead of > > writing a custom class. It's worth answering the question: what is > > the fundamental set of tools users would need to obtain results/do > > research. > Year, what is it? My scope is naturally a bit wider here I guess: I'd > like > to have as many tools for image processing available to me as > possible. This would > even contain image acquisition (Actually, I have a quite healthy > ctypes wrapper > around libdc1394 2.0 which you can find on launchpad. This + ctypes > can do fun > stuff: http://www.youtube.com/watch?gl=DE&hl=de&v=5O4FrRujlII) and GUI > Stuff. > > That's pretty cool! I know I looked for a libdc1394 wrapper and couldn't find one then. Will definitely play with yours if I get the chance! > > > > > > 3) GUI dependency. > > > I use Pyqt for all my image processing tools because it is very fast > > > (200 fps is no problem to display) and because it is very convenient. > > > I feel that a image scikit should provide some GUI functionality (what > > > good is image processing without seeing images?) and I would urge to > > > investigate PyQt. With this question, I just want to get the ball > > > rolling; I feel the discussing of wether GUI tools are wanted or not > > > and which toolkit to use or not might be crucial for the evolution of > > > the image scikit. > > > > A while ago we discussed implementing a plugin system for image IO. > I haven't followed this discussion. What is the reason to not depend > on PIL? > Every Image Processor I know whos using python has PIL installed; even > scipy > uses it via misc.scipy.pilutil. > PIL has some issues, with 16-bit images and with multi-page images. More importantly, it has a completely broken development model. We discussed this a while ago, see: http://groups.google.com/group/scikits-image/browse_thread/thread/76a1fbf21ee8ef43 > We may want to do something similar for image display. At the moment, > > I mostly use matplotlib do display images, but for faster displaying a > > QT-based GUI may be worth it. I want us to keep dependencies at a > > minimum, so we could follow a similar route to the new opencv module: > > compile wrappers, but only load those once the library becomes > > available. > So we could add support for a set of GUI functions that are just not > available > when pyqt (or in a very near future pyside) is not available. Good for > me, > that's the python way to do things anyway. > Sounds good to me. Cheers, Ralf > > Cheers, > Holger > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Sat Oct 17 12:48:30 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sat, 17 Oct 2009 18:48:30 +0200 Subject: OpenCV Calibration Wrapping - Some questions In-Reply-To: <8d848745-a8fa-4d74-8a9d-f0022974da4c@f16g2000yqm.googlegroups.com> References: <86a53fb1-18e4-4d70-b462-b1664b7ae241@j24g2000yqa.googlegroups.com> <9457e7c80910150631m7b1d91c9y703258b8cb004001@mail.gmail.com> <8d848745-a8fa-4d74-8a9d-f0022974da4c@f16g2000yqm.googlegroups.com> Message-ID: <9457e7c80910170948u15a46163x7fb7769610170ef2@mail.gmail.com> 2009/10/15 SirVer : > to have as many tools for image processing available to me as > possible. This would > even contain image acquisition (Actually, I have a quite healthy > ctypes wrapper > around libdc1394 2.0 which you can find on launchpad. This + ctypes > can do fun > stuff: http://www.youtube.com/watch?gl=DE&hl=de&v=5O4FrRujlII) and GUI > Stuff. Having some image acquisition in the scikit would be handy. I see OpenCV also wraps libdc, so what is the best route to access the library? I really like the video, btw! > So we could add support for a set of GUI functions that are just not > available > when pyqt (or in a very near future pyside) is not available. Good for > me, > that's the python way to do things anyway. Yes, especially with the image acquisition suggested above, this would be good to have. Cheers St?fan From stefan at sun.ac.za Sat Oct 17 15:01:18 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sat, 17 Oct 2009 21:01:18 +0200 Subject: Update: OpenCV and docs Message-ID: <9457e7c80910171201s4702e273yf3629de3725f2b22@mail.gmail.com> Hi all, Thanks to an effort led by Chris Colbert, and with contributions by Holger Rapp, we now have (optional) wrappers to OpenCV. I encourage you to try these out and to report on your experience. Further, I'd like to thank Ralf Gommers for cleaning up the API generation. You'll find the much-improved API table of contents at: http://stefanv.github.com/scikits.image/api/api.html Thanks for all your hard work! At this rate, we'll soon have a very competitive toolkit. Regards St?fan From sccolbert at gmail.com Sat Oct 17 15:12:45 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Sat, 17 Oct 2009 21:12:45 +0200 Subject: Update: OpenCV and docs In-Reply-To: <9457e7c80910171201s4702e273yf3629de3725f2b22@mail.gmail.com> References: <9457e7c80910171201s4702e273yf3629de3725f2b22@mail.gmail.com> Message-ID: <7f014ea60910171212l63fd68baxe996ce97dee025ac@mail.gmail.com> I'd also like to mention that Stefan helped a great deal with the Nitty Gritty of the OpenCV wrappers, (setup.py anyone?). Credit where it's due... Also, this is not the end state of the wrappers, what you send is ~ 30% of what I plan to have wrapped. I committing every couple of days, so it's really still a work in progress. Cheers! Chris 2009/10/17 St?fan van der Walt : > > Hi all, > > Thanks to an effort led by Chris Colbert, and with contributions by > Holger Rapp, we now have (optional) wrappers to OpenCV. ?I encourage > you to try these out and to report on your experience. > > Further, I'd like to thank Ralf Gommers for cleaning up the API > generation. ?You'll find the much-improved API table of contents at: > > http://stefanv.github.com/scikits.image/api/api.html > > Thanks for all your hard work! ?At this rate, we'll soon have a very > competitive toolkit. > > Regards > St?fan > From ralf.gommers at googlemail.com Sun Oct 18 08:26:18 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sun, 18 Oct 2009 14:26:18 +0200 Subject: iso-contour finding and color-space manipulations Message-ID: Hi all, Looking at the code that needs to be integrated, I'm most interested in the 2D iso-contour finding and color-space manipulations. The coming week I've got time to do this. The iso-contour item says to ask Zach Pincus. Zach, if you want me to work on this, can you point me to the code and what needs to be done? Same question for the color-space stuff, Nicolas, or anyone else? Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Sun Oct 18 11:01:35 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 18 Oct 2009 17:01:35 +0200 Subject: iso-contour finding and color-space manipulations In-Reply-To: References: Message-ID: <9457e7c80910180801j4814a102mabf3c3244a0a19d8@mail.gmail.com> Hi Ralf 2009/10/18 Ralf Gommers : > Looking at the code that needs to be integrated, I'm most interested in the > 2D iso-contour finding and color-space manipulations. The coming week I've > got time to do this. The relevant post on the SciPy list is here: http://mail.scipy.org/pipermail/scipy-user/2009-July/021719.html > Same question for the color-space stuff, Nicolas, or anyone else? Travis had some colour-space manipulation code here: http://svn.scipy.org/svn/scipy/branches/sandbox/scipy/sandbox/image/color.py I think Nicholas included his (faster) version of rgb2hsv, but the file above includes many more converters which can be brought over once they're documented and tested. Regards St?fan From sccolbert at gmail.com Sun Oct 18 15:34:28 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Sun, 18 Oct 2009 21:34:28 +0200 Subject: iso-contour finding and color-space manipulations In-Reply-To: <9457e7c80910180801j4814a102mabf3c3244a0a19d8@mail.gmail.com> References: <9457e7c80910180801j4814a102mabf3c3244a0a19d8@mail.gmail.com> Message-ID: <7f014ea60910181234l52f54e94peff169b18d38299a@mail.gmail.com> I can have relatively complete color space conversions from OpenCV: http://opencv.willowgarage.com/documentation/image_processing.html#cvCvtColor completed with almost no effort. Since you need it, I'll work on that next. I'll be busy the next few days. But may be able to work it in. At the latest Thursday or Friday. Cheers, Chris 2009/10/18 St?fan van der Walt : > > Hi Ralf > > 2009/10/18 Ralf Gommers : >> Looking at the code that needs to be integrated, I'm most interested in the >> 2D iso-contour finding and color-space manipulations. The coming week I've >> got time to do this. > > The relevant post on the SciPy list is here: > > http://mail.scipy.org/pipermail/scipy-user/2009-July/021719.html > >> Same question for the color-space stuff, Nicolas, or anyone else? > > Travis had some colour-space manipulation code here: > > http://svn.scipy.org/svn/scipy/branches/sandbox/scipy/sandbox/image/color.py > > I think Nicholas included his (faster) version of rgb2hsv, but the > file above includes many more converters which can be brought over > once they're documented and tested. > > Regards > St?fan > From ralf.gommers at googlemail.com Sun Oct 18 16:34:55 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sun, 18 Oct 2009 22:34:55 +0200 Subject: iso-contour finding and color-space manipulations In-Reply-To: <7f014ea60910181234l52f54e94peff169b18d38299a@mail.gmail.com> References: <9457e7c80910180801j4814a102mabf3c3244a0a19d8@mail.gmail.com> <7f014ea60910181234l52f54e94peff169b18d38299a@mail.gmail.com> Message-ID: Hi Chris, On Sun, Oct 18, 2009 at 9:34 PM, Chris Colbert wrote: > > I can have relatively complete color space conversions from OpenCV: > > > http://opencv.willowgarage.com/documentation/image_processing.html#cvCvtColor > > completed with almost no effort. > > Since you need it, I'll work on that next. > Thanks. It's actually not urgent. I expect to use that functionality at some point, but right now I have quite a bit of time and was just picking some items from the tasks list I was interested in. The OpenCV functionality looks quite good, while Travis' code needs quite a bit of polishing. So the question is how much we want to rely on OpenCV? Maybe its worth having plain Python functions for conversion between RGB, HSV and CMYK(?), and rely on OpenCV for the rest? Or is there not much point in even doing that since it basically duplicates OpenCV functionality? Cheers, Ralf > I'll be busy the next few days. But may be able to work it in. At the > latest Thursday or Friday. > > Cheers, > > Chris > > 2009/10/18 St?fan van der Walt : > > > > Hi Ralf > > > > 2009/10/18 Ralf Gommers : > >> Looking at the code that needs to be integrated, I'm most interested in > the > >> 2D iso-contour finding and color-space manipulations. The coming week > I've > >> got time to do this. > > > > The relevant post on the SciPy list is here: > > > > http://mail.scipy.org/pipermail/scipy-user/2009-July/021719.html > > > >> Same question for the color-space stuff, Nicolas, or anyone else? > > > > Travis had some colour-space manipulation code here: > > > > > http://svn.scipy.org/svn/scipy/branches/sandbox/scipy/sandbox/image/color.py > > > > I think Nicholas included his (faster) version of rgb2hsv, but the > > file above includes many more converters which can be brought over > > once they're documented and tested. > > > > Regards > > St?fan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sirver at gmx.de Mon Oct 19 03:47:40 2009 From: sirver at gmx.de (SirVer) Date: Mon, 19 Oct 2009 00:47:40 -0700 (PDT) Subject: iso-contour finding and color-space manipulations In-Reply-To: References: <9457e7c80910180801j4814a102mabf3c3244a0a19d8@mail.gmail.com> <7f014ea60910181234l52f54e94peff169b18d38299a@mail.gmail.com> <9457e7c80910182126q7eb5d279l124bfb8671e5ba70@mail.gmail.com> <7f014ea60910182336i1e0359c7t630b9018ec1f978@mail.gmail.com> <7f014ea60910182341l5cc24395t7642bf6a1fd4a9f2@mail.gmail.com> Message-ID: <1dab8070-c2fe-40c1-a22e-517931624090@p35g2000yqh.googlegroups.com> My two cents: OpenCV is currently the de factor standard for image processing and it has it's uses. But frankly, the library is so very ugly and so hard to extend and work with that I doubt it will persist. I am glad that chris started wrapping opencv stuff (I contributed because I think this is the most worthwhile wrapping attempt for the opencv yet: interfacing it to numpy), but in the long run I'd really like to have a true replacement for opencv. ATM this means though having to write a lot of stuff anew; either in cython or directly in cpp. In one, two years from now, i'd really like to only make apt-get install scip-scikit-image numpy scipy matplotlib ipython py27-pyqt and have a speedy, multicore aware, OpenCL aware image processing toolkit.... aa, dreams ;) Just my two cents and my motivation to work on scikit-image. Cheers, Holger On 19 Okt., 09:12, Ralf Gommers wrote: > > On Mon, Oct 19, 2009 at 8:36 AM, Chris Colbert > > wrote: > > > I agree. > > > > It's nice having opencv there if you need it for something difficult > > > to implement or if you need the speed. I'm definitely not opposed to > > > having duplicated functionality, if the duplicate is written in pure > > > python. This is especially important for those who dont have or dont > > > want to build OpenCV in order to use the scikit. > > > > Chris > > > > 2009/10/19 St?fan van der Walt : > > > >> Hi Ralf > > > >> 2009/10/18 Ralf Gommers : > > >>> The OpenCV functionality looks quite good, while Travis' code needs > > quite a > > >>> bit of polishing. So the question is how much we want to rely on > > OpenCV? > > >>> Maybe its worth having plain Python functions for conversion between > > RGB, > > >>> HSV and CMYK(?), and rely on OpenCV for the rest? Or is there not much > > point > > >>> in even doing that since it basically duplicates OpenCV functionality? > > > >> These colour conversions should be fairly easy to implement, so it may > > >> be worth having pure Python versions for those without OpenCV. > > Okay makes sense. Then I'll add tests and docs to all the existing funcs and > add what is missing (only hsv2rgb and cmyk as far as I can tell now). > > Cheers, > Ralf > > > > > >> Cheers > > >> St?fan From sirver at gmx.de Mon Oct 19 04:22:12 2009 From: sirver at gmx.de (SirVer) Date: Mon, 19 Oct 2009 01:22:12 -0700 (PDT) Subject: Image acquisition (via camera) in scikit-image Message-ID: <95de49a9-893f-4237-af9e-a44807148d27@g31g2000yqc.googlegroups.com> Moving this to a new thread. Let's discuss if and if yes how to integrate image acquisition into scikits-image First let's agree that image processing != image acquisition. image acquisition is more Computer vision for me; but that's basically what I do with images: acquiring and processing. Imho there are two possible paths here 1) built image acquisition into scikits-images either by 1a) wrapping opencv's camera wrappers 1b) wrapping our own 2) by close collaboration with a project that would do things like we would do it and provide camera access. 2a) which project? 2b) how to collaborate? 1) Quote by stefan. > Having some image acquisition in the scikit would be handy. I see > OpenCV also wraps libdc, so what is the best route to access the > library? Having thought about this over the weekend I would discourage this route: scikits-image != scikits-computervision imho. But if we do agree on doing it which suboption? 1a) I have no experience with them, but having to rely on opencv for image capturing feels for me as uncool as having to rely on it for GUI stuff: specialized solutions are better. In fact in my experience (I have hacked on > 10 CV projects in two different labs) opencv was never used as acquisition library because it is quite constrained and programming for it is awkward (void* pointer anyone?). 1b) I would suggest using pyrex (because we are using this already) or ctypes (because it doesn't introduce another dependency). I have a good starting point (see below) 2) I personally prefer this way to keep responsibilities separated. a) My libdcwrappers [1] (using ctypes, returning a numpy array subclass enhanced with timestamps and avoiding copying of data; providing continuos acquisition (for interactive display) or do-not-miss-an- image vie Queues) are an excellent starting point. It is a little rough around the edges, misses test cases (how to write an unit test without writing a complete mock libdc1394?) and is only used on point gray cameras currently, but it is already the best camera library I ever used *modesty*. Problem is, it only wraps libdc1394 (and some obscure 3D cameras; i didn't even bother to include the code on launchpad because no one will use them for at least 4 years. I was doing research on them), that is it works on linux & mac for IEEE cameras. So it doesn't work on Windows (i am not sure there is a libdc port to windows) and it doesn't work for any camera not firewire. I doubt the OpenCV wrappers work for something else then USB & IEEE; and afaik there is no other project out there that works for CamBus. [1] https://launchpad.net/pydc1394 For completeness I include other projects: http://pypi.python.org/pypi/Dc1394/0.1 - Tamas Haraszti. I contacted him by email when I started my wrapper. He basically wrote a CPP wrapper around a subset of libdc1394 and then wrapped this with swig. He copies data around and he is not sure about the performance of his code. He's not actively maintaining his code. http://cia.vc/stats/project/navi-misc/libdc1394-python - No information on this one, besides 'This is a very minimally functional python wrapper around libdc1394'. Last update was in 2004; so this is probably dead. http://github.com/damg/libdc1394-python - No information on this either. Wrapping using swig. Last commit june 04, 2008. Skimming the code on github I couldn't find a frontend class; so this only wraps the c functions verbatimly. 2b) I imagine a collaboration like it is common in the python world; for example like between ipython and matplotlib. They do not share code, but if matplotlib is installed, ipython offers ipython -pylab transparently to offer a unique solution. In our case, we could provide example scripts that rely on the cam library to be installed and the use the cameras pictures to show off our image processing madness. Likewise we could mention the library in our docs and vice versa: the camera lib would propose scikit image for image processing. I am very keen to get your thoughts on that. Cheers, Holger From stefan at sun.ac.za Mon Oct 19 00:26:16 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 19 Oct 2009 06:26:16 +0200 Subject: iso-contour finding and color-space manipulations In-Reply-To: References: <9457e7c80910180801j4814a102mabf3c3244a0a19d8@mail.gmail.com> <7f014ea60910181234l52f54e94peff169b18d38299a@mail.gmail.com> Message-ID: <9457e7c80910182126q7eb5d279l124bfb8671e5ba70@mail.gmail.com> Hi Ralf 2009/10/18 Ralf Gommers : > The OpenCV functionality looks quite good, while Travis' code needs quite a > bit of polishing. So the question is how much we want to rely on OpenCV? > Maybe its worth having plain Python functions for conversion between RGB, > HSV and CMYK(?), and rely on OpenCV for the rest? Or is there not much point > in even doing that since it basically duplicates OpenCV functionality? These colour conversions should be fairly easy to implement, so it may be worth having pure Python versions for those without OpenCV. Cheers St?fan From sccolbert at gmail.com Mon Oct 19 02:36:43 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Mon, 19 Oct 2009 08:36:43 +0200 Subject: iso-contour finding and color-space manipulations In-Reply-To: <9457e7c80910182126q7eb5d279l124bfb8671e5ba70@mail.gmail.com> References: <9457e7c80910180801j4814a102mabf3c3244a0a19d8@mail.gmail.com> <7f014ea60910181234l52f54e94peff169b18d38299a@mail.gmail.com> <9457e7c80910182126q7eb5d279l124bfb8671e5ba70@mail.gmail.com> Message-ID: <7f014ea60910182336i1e0359c7t630b9018ec1f978@mail.gmail.com> I agree. It's nice having opencv there if you need it for something difficult to implement or if you need the speed. I'm definitely not opposed to having duplicated functionality, if the duplicate is written in pure python. This is especially important for those who dont have or dont want to build OpenCV in order to use the scikit. Chris 2009/10/19 St?fan van der Walt : > > Hi Ralf > > 2009/10/18 Ralf Gommers : >> The OpenCV functionality looks quite good, while Travis' code needs quite a >> bit of polishing. So the question is how much we want to rely on OpenCV? >> Maybe its worth having plain Python functions for conversion between RGB, >> HSV and CMYK(?), and rely on OpenCV for the rest? Or is there not much point >> in even doing that since it basically duplicates OpenCV functionality? > > These colour conversions should be fairly easy to implement, so it may > be worth having pure Python versions for those without OpenCV. > > Cheers > St?fan > From sccolbert at gmail.com Mon Oct 19 02:41:56 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Mon, 19 Oct 2009 08:41:56 +0200 Subject: iso-contour finding and color-space manipulations In-Reply-To: <7f014ea60910182336i1e0359c7t630b9018ec1f978@mail.gmail.com> References: <9457e7c80910180801j4814a102mabf3c3244a0a19d8@mail.gmail.com> <7f014ea60910181234l52f54e94peff169b18d38299a@mail.gmail.com> <9457e7c80910182126q7eb5d279l124bfb8671e5ba70@mail.gmail.com> <7f014ea60910182336i1e0359c7t630b9018ec1f978@mail.gmail.com> Message-ID: <7f014ea60910182341l5cc24395t7642bf6a1fd4a9f2@mail.gmail.com> Furthermore, I'm hesitant to wrap anything in opencv regarding contour finding. This will requiring aliasing the OpenCV memstorage struct, which i'm no particularly keen on doing as it will probably snowball into a huge ordeal. As a result, I'm trying to stay away from any routines that rely on the use of that struct. Chris On Mon, Oct 19, 2009 at 8:36 AM, Chris Colbert wrote: > I agree. > > It's nice having opencv there if you need it for something difficult > to implement or if you need the speed. I'm definitely not opposed to > having duplicated functionality, if the duplicate is written in pure > python. This is especially important for those who dont have or dont > want to build OpenCV in order to use the scikit. > > Chris > > 2009/10/19 St?fan van der Walt : >> >> Hi Ralf >> >> 2009/10/18 Ralf Gommers : >>> The OpenCV functionality looks quite good, while Travis' code needs quite a >>> bit of polishing. So the question is how much we want to rely on OpenCV? >>> Maybe its worth having plain Python functions for conversion between RGB, >>> HSV and CMYK(?), and rely on OpenCV for the rest? Or is there not much point >>> in even doing that since it basically duplicates OpenCV functionality? >> >> These colour conversions should be fairly easy to implement, so it may >> be worth having pure Python versions for those without OpenCV. >> >> Cheers >> St?fan >> > From ralf.gommers at googlemail.com Mon Oct 19 03:12:23 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 19 Oct 2009 09:12:23 +0200 Subject: iso-contour finding and color-space manipulations In-Reply-To: <7f014ea60910182341l5cc24395t7642bf6a1fd4a9f2@mail.gmail.com> References: <9457e7c80910180801j4814a102mabf3c3244a0a19d8@mail.gmail.com> <7f014ea60910181234l52f54e94peff169b18d38299a@mail.gmail.com> <9457e7c80910182126q7eb5d279l124bfb8671e5ba70@mail.gmail.com> <7f014ea60910182336i1e0359c7t630b9018ec1f978@mail.gmail.com> <7f014ea60910182341l5cc24395t7642bf6a1fd4a9f2@mail.gmail.com> Message-ID: > On Mon, Oct 19, 2009 at 8:36 AM, Chris Colbert > wrote: > > I agree. > > > > It's nice having opencv there if you need it for something difficult > > to implement or if you need the speed. I'm definitely not opposed to > > having duplicated functionality, if the duplicate is written in pure > > python. This is especially important for those who dont have or dont > > want to build OpenCV in order to use the scikit. > > > > Chris > > > > 2009/10/19 St?fan van der Walt : > >> > >> Hi Ralf > >> > >> 2009/10/18 Ralf Gommers : > >>> The OpenCV functionality looks quite good, while Travis' code needs > quite a > >>> bit of polishing. So the question is how much we want to rely on > OpenCV? > >>> Maybe its worth having plain Python functions for conversion between > RGB, > >>> HSV and CMYK(?), and rely on OpenCV for the rest? Or is there not much > point > >>> in even doing that since it basically duplicates OpenCV functionality? > >> > >> These colour conversions should be fairly easy to implement, so it may > >> be worth having pure Python versions for those without OpenCV. > >> > Okay makes sense. Then I'll add tests and docs to all the existing funcs and add what is missing (only hsv2rgb and cmyk as far as I can tell now). Cheers, Ralf > >> Cheers > >> St?fan > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sirver at gmx.de Mon Oct 19 12:55:52 2009 From: sirver at gmx.de (SirVer) Date: Mon, 19 Oct 2009 09:55:52 -0700 (PDT) Subject: Separation of tests into unit test and functional tests Message-ID: <1fe1baa1-cbb5-485e-8cac-a72b508cf954@l33g2000vbi.googlegroups.com> Hi, I have something of a lot of importance to mention. We should start to separate our tests into unit and integration tests. For what reason? The 40 tests need 3.256 seconds on my box to run; that's approximately the time it takes to compile the opencv module here. So compiling + tests = 2 * compiling. That's still acceptable, but 40 tests is nothing. 400 tests will need 30 seconds which is too much to run after each edit. But that is was unittests are for. The reason why I come up with this now is that it is important to make this separation while it is still easy and possible. The best way is to group tests into many groups ('opencv', 'fast', 'slow', 'need_camera'). A short blog post concerning this is: http://beust.com/weblog/archives/000319.html I have no idea how to achieve this with pynose in a simple way though, Once again: I think scikit_image will grow fast and therefore test will grow fast. Users will stop running the tests if they take to long. Too long for an interactive coding session is > 10s . Cheers, Holger From stefan at sun.ac.za Mon Oct 19 03:57:16 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 19 Oct 2009 09:57:16 +0200 Subject: iso-contour finding and color-space manipulations In-Reply-To: <1dab8070-c2fe-40c1-a22e-517931624090@p35g2000yqh.googlegroups.com> References: <9457e7c80910180801j4814a102mabf3c3244a0a19d8@mail.gmail.com> <7f014ea60910181234l52f54e94peff169b18d38299a@mail.gmail.com> <9457e7c80910182126q7eb5d279l124bfb8671e5ba70@mail.gmail.com> <7f014ea60910182336i1e0359c7t630b9018ec1f978@mail.gmail.com> <7f014ea60910182341l5cc24395t7642bf6a1fd4a9f2@mail.gmail.com> <1dab8070-c2fe-40c1-a22e-517931624090@p35g2000yqh.googlegroups.com> Message-ID: <9457e7c80910190057j303c03c7o3e4d483e97c8d763@mail.gmail.com> 2009/10/19 SirVer : > In one, two years from now, i'd really like to only make apt-get > install scip-scikit-image numpy scipy matplotlib ipython py27-pyqt > and have a speedy, multicore aware, OpenCL aware image processing > toolkit.... aa, dreams ;) We should definitely aim to turn this dream into a reality! I'm especially keen on seeing OpenCL algorithms implemented. Cheers St?fan From sirver at gmx.de Mon Oct 19 12:57:46 2009 From: sirver at gmx.de (SirVer) Date: Mon, 19 Oct 2009 09:57:46 -0700 (PDT) Subject: Image acquisition (via camera) in scikit-image In-Reply-To: <9457e7c80910190138s39bb6b9cmdb782bdeef4d755d@mail.gmail.com> References: <95de49a9-893f-4237-af9e-a44807148d27@g31g2000yqc.googlegroups.com> <9457e7c80910190138s39bb6b9cmdb782bdeef4d755d@mail.gmail.com> Message-ID: On 19 Okt., 10:38, St?fan van der Walt wrote: > Hi Holger > > 2009/10/19 SirVer : > > > 1b) I would suggest using pyrex (because we are using this already) or > > ctypes (because it doesn't introduce another dependency). I have a > > good starting point (see below) > > A Cython solution would be excellent. ?We should also take a look at > what Andrew Straw has done: > > http://code.astraw.com/projects/motmot/libcamiface.html I didn't know about this project. It seems like a lot of stuff is already implemented there. The python wrapper he provides are ctypes wrapper around a c lib though. That means the interface is not Pythonic at all. St?fan, which is the solution (1 or 2) you'd like to have for sckit- images? Cheers, Holger From stefan at sun.ac.za Mon Oct 19 04:38:31 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 19 Oct 2009 10:38:31 +0200 Subject: Image acquisition (via camera) in scikit-image In-Reply-To: <95de49a9-893f-4237-af9e-a44807148d27@g31g2000yqc.googlegroups.com> References: <95de49a9-893f-4237-af9e-a44807148d27@g31g2000yqc.googlegroups.com> Message-ID: <9457e7c80910190138s39bb6b9cmdb782bdeef4d755d@mail.gmail.com> Hi Holger 2009/10/19 SirVer : > 1b) I would suggest using pyrex (because we are using this already) or > ctypes (because it doesn't introduce another dependency). I have a > good starting point (see below) A Cython solution would be excellent. We should also take a look at what Andrew Straw has done: http://code.astraw.com/projects/motmot/libcamiface.html > My libdcwrappers [1] (using ctypes, returning a numpy array subclass > enhanced with timestamps and avoiding copying of data; providing > continuos acquisition (for interactive display) ?or do-not-miss-an- > image vie Queues) are an excellent starting point. It is a little > rough around the edges, misses test cases (how to write an unit test > without writing a complete mock libdc1394?) With the OpenCV wrappers, we wrote the tests assuming that libcv is available. If it is not, we simply skip those tests. Cheers St?fan From ralf.gommers at googlemail.com Mon Oct 19 13:28:36 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Mon, 19 Oct 2009 19:28:36 +0200 Subject: Separation of tests into unit test and functional tests In-Reply-To: <1fe1baa1-cbb5-485e-8cac-a72b508cf954@l33g2000vbi.googlegroups.com> References: <1fe1baa1-cbb5-485e-8cac-a72b508cf954@l33g2000vbi.googlegroups.com> Message-ID: Hi Holger, That's a good point. On Mon, Oct 19, 2009 at 6:55 PM, SirVer wrote: > > Hi, > > I have something of a lot of importance to mention. We should start to > separate our tests into unit and integration tests. For what reason? > The 40 tests need 3.256 seconds on my box to run; that's approximately > the time it takes to compile the opencv module here. So compiling + > tests = 2 * compiling. That's still acceptable, but 40 tests is > nothing. 400 tests will need 30 seconds which is too much to run after > each edit. The main thing I think is to be careful with images. The slowest one by far now are the tests for lpi_filter, because they do a lot of things with a *large* image. This is why I originally put my test images for io under io/tests. I thought data_dir should only contain images for examples, useful for users. Images for testing algorithms can often be small. For the color conversion I now use images of size (4, 2, 3), which means they take no time at all. > But that is was unittests are for. The reason why I come up > with this now is that it is important to make this separation while it > is still easy and possible. The best way is to group tests into many > groups ('opencv', 'fast', 'slow', 'need_camera'). What is lacking when you apply decorators like @opencv_skip and @slow? Note also that if you run nosetests from some folder you run only tests in subfolders. This is a natural separation already. > A short blog post > concerning this is: > > http://beust.com/weblog/archives/000319.html > > That's mostly semantics. > I have no idea how to achieve this with pynose in a simple way > though, > > Once again: I think scikit_image will grow fast and therefore test > will grow fast. Users will stop running the tests if they take to > long. Too long for an interactive coding session is > 10s . > True. The @slow decorator should take care of this. What is the approximate limit again when it should be used? Cheers, Ralf > > Cheers, > Holger -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Tue Oct 20 00:33:20 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 20 Oct 2009 06:33:20 +0200 Subject: Image acquisition (via camera) in scikit-image In-Reply-To: References: <95de49a9-893f-4237-af9e-a44807148d27@g31g2000yqc.googlegroups.com> <9457e7c80910190138s39bb6b9cmdb782bdeef4d755d@mail.gmail.com> Message-ID: <9457e7c80910192133xf9f37d1x9dd7f8c28a72ffa8@mail.gmail.com> 2009/10/19 SirVer : > St?fan, which is the solution (1 or 2) you'd like to have for sckit- > images? Personally, I'd prefer 1(b) [Cython wrapper] with a second choice 2 [close collaboration with an existing project], simply because it is easier to manage code under our own roof. In order to get this implemented as soon as possible, we should build on the work done by yourself and Andrew. His code is also BSD licensed, so no problems there. Also have a look at his higher-level Python wrapper: http://code.astraw.com/projects/motmot/cam_iface.html Cheers St?fan From stefan at sun.ac.za Tue Oct 20 01:11:37 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Tue, 20 Oct 2009 07:11:37 +0200 Subject: Separation of tests into unit test and functional tests In-Reply-To: References: <1fe1baa1-cbb5-485e-8cac-a72b508cf954@l33g2000vbi.googlegroups.com> Message-ID: <9457e7c80910192211gedb4500na1c4adf25bb0fe32@mail.gmail.com> 2009/10/19 Ralf Gommers : > The main thing I think is to be careful with images. The slowest one by far > now are the tests for lpi_filter, because they do a lot of things with a > *large* image. Also, the kernel size is currently set to the shape of the image, which is not necessary. I'd also like the filtering code to take a kernel as a parameter, instead of a function. I've placed it on the tasks list. > This is why I originally put my test images for io under io/tests. I thought > data_dir should only contain images for examples, useful for users. Images > for testing algorithms can often be small. For the color conversion I now > use images of size (4, 2, 3), which means they take no time at all. The idea is for each package to use the same pool of images, so that we don't have to include data-files in each sub-package. If needed, we could put them in subdirectories under data to show what they were intended for. > What is lacking when you apply decorators like @opencv_skip and @slow? Note > also that if you run nosetests from some folder you run only tests in > subfolders. This is a natural separation already. I see one danger in using @slow: people stop executing anything but the fast tests. In such a case, it may simply be worth speeding up the slow test, if possible. Ralf gives a good tip for developing: run only the relevant tests, e.g., nosetests scikits.image.opencv Cheers St?fan From ralf.gommers at googlemail.com Tue Oct 20 04:03:42 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 20 Oct 2009 10:03:42 +0200 Subject: Separation of tests into unit test and functional tests In-Reply-To: <9457e7c80910192211gedb4500na1c4adf25bb0fe32@mail.gmail.com> References: <1fe1baa1-cbb5-485e-8cac-a72b508cf954@l33g2000vbi.googlegroups.com> <9457e7c80910192211gedb4500na1c4adf25bb0fe32@mail.gmail.com> Message-ID: 2009/10/20 St?fan van der Walt > > 2009/10/19 Ralf Gommers : > > This is why I originally put my test images for io under io/tests. I > thought > > data_dir should only contain images for examples, useful for users. > Images > > for testing algorithms can often be small. For the color conversion I now > > use images of size (4, 2, 3), which means they take no time at all. > > The idea is for each package to use the same pool of images, so that > we don't have to include data-files in each sub-package. If needed, > we could put them in subdirectories under data to show what they were > intended for. > > Sure that makes sense. It would be good if data_dir has only "nice" images. I can rearrange them today, either in one subdir per module or simply one new data_dir/testdata. Cheers, Ralf > > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From idfregoso3 at gmail.com Tue Oct 20 13:13:57 2009 From: idfregoso3 at gmail.com (FunGuy) Date: Tue, 20 Oct 2009 10:13:57 -0700 (PDT) Subject: That's awesome)) Message-ID: <0421bc2b-9ed8-472f-b8ee-42850895856a@z34g2000vbl.googlegroups.com> Muhahahhaaa )))awesome!!))) still can't believe this)).... http://villaworld.com/pictures/ From dwf at cs.toronto.edu Tue Oct 20 20:15:15 2009 From: dwf at cs.toronto.edu (David Warde-Farley) Date: Tue, 20 Oct 2009 20:15:15 -0400 Subject: That's awesome)) In-Reply-To: <0421bc2b-9ed8-472f-b8ee-42850895856a@z34g2000vbl.googlegroups.com> References: <0421bc2b-9ed8-472f-b8ee-42850895856a@z34g2000vbl.googlegroups.com> Message-ID: <35375191-AB8D-4C7E-BC89-EC97DFAB3008@cs.toronto.edu> And so it begins... Time to reevaluate the posting permissions? David On 20-Oct-09, at 1:13 PM, FunGuy wrote: > > Muhahahhaaa )))awesome!!))) still can't believe this)).... > http://villaworld.com/pictures/ From sirver at gmx.de Wed Oct 21 07:32:36 2009 From: sirver at gmx.de (SirVer) Date: Wed, 21 Oct 2009 04:32:36 -0700 (PDT) Subject: Bug in io.ImageCollection Message-ID: On a side note, can't we get a real bug tracker somewhere? --- I have a selection of grayscale (8bit) tifs in a directory. In [14]: k = io.ImageCollection("calib/*.tif", True) In [15]: k[0].dtype Out[15]: dtype('uint8') In [16]: k = io.ImageCollection("calib/*.tif", as_grey=True) In [17]: k[0].dtype Out[17]: dtype('float32') --- But the docs say: as_grey : bool, optional If True, convert the input images to grey-scale. This does not affect images that are already in a grey-scale format. Obviously the image data type gets converted though. Cheers, Holger From sirver at gmx.de Wed Oct 21 07:36:29 2009 From: sirver at gmx.de (SirVer) Date: Wed, 21 Oct 2009 04:36:29 -0700 (PDT) Subject: Separation of tests into unit test and functional tests In-Reply-To: <9457e7c80910192211gedb4500na1c4adf25bb0fe32@mail.gmail.com> References: <1fe1baa1-cbb5-485e-8cac-a72b508cf954@l33g2000vbi.googlegroups.com> <9457e7c80910192211gedb4500na1c4adf25bb0fe32@mail.gmail.com> Message-ID: Hi, > > What is lacking when you apply decorators like @opencv_skip and @slow? Note > > also that if you run nosetests from some folder you run only tests in > > subfolders. This is a natural separation already. > Ahh, now i understood how to select which tests to run with the nosetest script. I finally figured out -a and -A > I see one danger in using @slow: people stop executing anything but > the fast tests. ?In such a case, it may simply be worth speeding up > the slow test, if possible. I started to use @dec.slow now for every test that needs > 0.1 s on my system. They are still run by default but can be left out. It is wise to run the complete test suite (of all modules, not only those you worked on) before commiting ,). Cheers, Holger From stefan at sun.ac.za Wed Oct 21 03:09:51 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 21 Oct 2009 09:09:51 +0200 Subject: That's awesome)) In-Reply-To: <35375191-AB8D-4C7E-BC89-EC97DFAB3008@cs.toronto.edu> References: <0421bc2b-9ed8-472f-b8ee-42850895856a@z34g2000vbl.googlegroups.com> <35375191-AB8D-4C7E-BC89-EC97DFAB3008@cs.toronto.edu> Message-ID: <9457e7c80910210009i79afe601vef6eadc3c0f8b9c4@mail.gmail.com> 2009/10/21 David Warde-Farley : > > And so it begins... > > Time to reevaluate the posting permissions? Sorry about that. Messages from new members will now be moderated. Stefan From ralf.gommers at googlemail.com Wed Oct 21 08:47:29 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 21 Oct 2009 14:47:29 +0200 Subject: Bug in io.ImageCollection In-Reply-To: References: Message-ID: On Wed, Oct 21, 2009 at 1:32 PM, SirVer wrote: > > On a side note, can't we get a real bug tracker somewhere? > > This one should do the job right? At least for now. http://github.com/stefanv/scikits.image/issues > --- > I have a selection of grayscale (8bit) tifs in a directory. > > In [14]: k = io.ImageCollection("calib/*.tif", True) > > In [15]: k[0].dtype > Out[15]: dtype('uint8') > > In [16]: k = io.ImageCollection("calib/*.tif", as_grey=True) > > In [17]: k[0].dtype > Out[17]: dtype('float32') > --- > But the docs say: > as_grey : bool, optional > If True, convert the input images to grey-scale. This does not > affect images that are already in a grey-scale format. > > Obviously the image data type gets converted though. > Thanks for testing Holger. I wrote the docstring based on what I thought pil_imread was doing. Obviously I was wrong. This is the desired behavior imho, so I'll come up with a patch for pil_imread. Cheers, Ralf > Cheers, > Holger > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Wed Oct 21 10:52:16 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 21 Oct 2009 16:52:16 +0200 Subject: Bug in io.ImageCollection In-Reply-To: References: Message-ID: On Wed, Oct 21, 2009 at 2:47 PM, Ralf Gommers wrote: > > > On Wed, Oct 21, 2009 at 1:32 PM, SirVer wrote: > >> >> On a side note, can't we get a real bug tracker somewhere? >> >> This one should do the job right? At least for now. > http://github.com/stefanv/scikits.image/issues > >> --- >> I have a selection of grayscale (8bit) tifs in a directory. >> >> In [14]: k = io.ImageCollection("calib/*.tif", True) >> >> In [15]: k[0].dtype >> Out[15]: dtype('uint8') >> >> In [16]: k = io.ImageCollection("calib/*.tif", as_grey=True) >> >> In [17]: k[0].dtype >> Out[17]: dtype('float32') >> --- >> But the docs say: >> as_grey : bool, optional >> If True, convert the input images to grey-scale. This does not >> affect images that are already in a grey-scale format. >> >> Obviously the image data type gets converted though. >> > > Thanks for testing Holger. > > I wrote the docstring based on what I thought pil_imread was doing. > Obviously I was wrong. This is the desired behavior imho, so I'll come up > with a patch for pil_imread. > Fixed in my asgrey branch: http://github.com/rgommers/scikits.image/tree/asgrey I sent Stefan a pull request but grab it there if you need it now. If you only have grey-scale images setting as_grey to False should do the right thing as well. Cheers, Ralf > Cheers, > Ralf > > >> Cheers, >> Holger >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Wed Oct 21 13:27:53 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 21 Oct 2009 19:27:53 +0200 Subject: color spaces Message-ID: Hi all, I'm working on the color spaces, and would like some feedback. Doing color space conversions is very simple, but finding the right references and making sure things are correct is a real pain. So I'm wondering what spaces are useful and unambiguously defined. So far I have ----------------- - RGB : sRGB with D65 whitepoint, the "central" color space in the API. - HSV : unambiguous - XYZ : unambiguous - CIE RGB : unambiguous - RGB NTSC : from Travis' code, not sure what it is. Not equal to YIQ, which is the color space used for NTSC. Will delete again unless I figure it out. Some code, seems clearly defined ---------------------------------------------- - CIE LAB - CIE LUV Some code, but not sure about ----------------------------------------- - RGBP : gamma corrected sRGB. I am usually interested in intensities / photon counts, so I have a natural aversion to this one. Anyone care? - YIQ : see RGB NTSC above - RGB SB : Stiles and Burch (1955) 2-degree RGB color space. seems obsolete. - UVW : seems obsolete - YUV / YCbCr / YCC / YPbPr / 8-bit YCbCr : these are all similar and often confused. A mess. No code yet, but commonly used -------------------------------------------- - HSL - CMYK The code I have so far lives here: http://github.com/rgommers/scikits.image/tree/color I'm afraid adding color spaces that are not clearly defined does more harm than good, so please let me know which color spaces are useful for you. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Wed Oct 21 16:13:12 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 21 Oct 2009 22:13:12 +0200 Subject: color spaces In-Reply-To: References: Message-ID: <9457e7c80910211313w16ba0b59obd95b4da42405251@mail.gmail.com> Hi Ralf 2009/10/21 Ralf Gommers : > I'm working on the color spaces, and would like some feedback. Doing color > space conversions is very simple, but finding the right references and > making sure things are correct is a real pain. So I'm wondering what spaces > are useful and unambiguously defined. Let's stick to the unambiguous cases and see what feedback we get. If the user requirements are more ambitious, we'll await patches :) We should definitely link to Poynton's FAQ in the docs: http://www.poynton.com/ColorFAQ.html Good stuff! Cheers St?fan From stefan at sun.ac.za Wed Oct 21 16:20:00 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 21 Oct 2009 22:20:00 +0200 Subject: Bug in io.ImageCollection In-Reply-To: References: Message-ID: <9457e7c80910211320q2126c11eg9e7435059f97e5bd@mail.gmail.com> Hey Ralf 2009/10/21 Ralf Gommers : > Fixed in my asgrey branch: > http://github.com/rgommers/scikits.image/tree/asgrey > I sent Stefan a pull request but grab it there if you need it now. > > If you only have grey-scale images setting as_grey to False should do the > right thing as well. Seeing the problem Holger reported makes me think that imread's behaviour is rather counter-intuitive. Should we not introduce a dtype flag, so that the outcome type is always as expected? I.e. imread('x.png') -> (uint8, uint8, uint8, ...) imread('x.png', flatten=True) -> uint8 imread('x.png', flatten=True, dtype=float) -> float imread('x.png', dtype=float) -> (float, float, float, ...) When it comes to dtypes, surprises are seldom good. What do you think? Cheers St?fan From ralf.gommers at googlemail.com Wed Oct 21 16:34:27 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 21 Oct 2009 22:34:27 +0200 Subject: Bug in io.ImageCollection In-Reply-To: <9457e7c80910211320q2126c11eg9e7435059f97e5bd@mail.gmail.com> References: <9457e7c80910211320q2126c11eg9e7435059f97e5bd@mail.gmail.com> Message-ID: 2009/10/21 St?fan van der Walt > > Hey Ralf > > 2009/10/21 Ralf Gommers : > > Fixed in my asgrey branch: > > http://github.com/rgommers/scikits.image/tree/asgrey > > I sent Stefan a pull request but grab it there if you need it now. > > > > If you only have grey-scale images setting as_grey to False should do the > > right thing as well. > > Seeing the problem Holger reported makes me think that imread's > behaviour is rather counter-intuitive. Should we not introduce a > dtype flag, so that the outcome type is always as expected? > > There is a dtype argument already, you merged my patch for that, commit 44679c7aae5d6b3747c88d46756a3dc96c9a727f. I.e. > > imread('x.png') -> (uint8, uint8, uint8, ...) > imread('x.png', flatten=True) -> uint8 > imread('x.png', flatten=True, dtype=float) -> float > imread('x.png', dtype=float) -> (float, float, float, ...) > > When it comes to dtypes, surprises are seldom good. > > What do you think? > I think a "flatten" keyword is useful, and float32 is a reasonable default. imread should just not try to flatten images that are already flat. Note that flatten does not only change the dtype, but also does color -> grey-scale correctly. i.e. it returns a 2-D instead of 3-D array: >>> lena = imread(os.path.join(data_dir, 'lena.png'), dtype="float32") >>> lena.shape (128, 128, 3) >>> lena.dtype dtype('float32') >>> lena = imread(os.path.join(data_dir, 'lena.png'), flatten=True) >>> lena.shape (128, 128) >>> lena.dtype dtype('float32') Cheers, Ralf > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Wed Oct 21 16:47:28 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Wed, 21 Oct 2009 22:47:28 +0200 Subject: Bug in io.ImageCollection In-Reply-To: References: <9457e7c80910211320q2126c11eg9e7435059f97e5bd@mail.gmail.com> Message-ID: <9457e7c80910211347s2f633514o154e9ec1ea0433a7@mail.gmail.com> 2009/10/21 Ralf Gommers : > There is a dtype argument already, you merged my patch for that, commit > 44679c7aae5d6b3747c88d46756a3dc96c9a727f. Oh yes, of course :) My point remains, however, that the default for dtype may have to be changed for consistency. Currently, you have to read the docs to figure out what type will be returned, and I feel that element of surprise can be eliminated simply by specifying the default dtype=float or dtype=np.uint8. Cheers St?fan From ralf.gommers at googlemail.com Wed Oct 21 17:59:27 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Wed, 21 Oct 2009 23:59:27 +0200 Subject: Bug in io.ImageCollection In-Reply-To: <9457e7c80910211347s2f633514o154e9ec1ea0433a7@mail.gmail.com> References: <9457e7c80910211320q2126c11eg9e7435059f97e5bd@mail.gmail.com> <9457e7c80910211347s2f633514o154e9ec1ea0433a7@mail.gmail.com> Message-ID: 2009/10/21 St?fan van der Walt > > 2009/10/21 Ralf Gommers : > > There is a dtype argument already, you merged my patch for that, commit > > 44679c7aae5d6b3747c88d46756a3dc96c9a727f. > > Oh yes, of course :) > > My point remains, however, that the default for dtype may have to be > changed for consistency. Don't think I would agree with that. dtype=None is consistent with how NumPy does this. See for example np.array / np.asarray. Currently, you have to read the docs to > figure out what type will be returned, and I feel that element of > surprise can be eliminated simply by specifying the default > dtype=float or dtype=np.uint8. > The returned type by default is the type the image was saved as. To me that is the only thing that makes sense. The only thing you have to look up in the docs is what dtype you get when specifying flatten=True. Since you explicitly ask for color -> grey-scale conversion, a sensible type has to be chosen if it's not specified. The smallest type that makes sense is float32. Cheers, Ralf > > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zachary.pincus at yale.edu Thu Oct 22 09:42:28 2009 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Thu, 22 Oct 2009 09:42:28 -0400 Subject: isocontours, marching squares, patent issue In-Reply-To: References: Message-ID: I do not believe that the "marching squares" algorithm was ever covered under the marching cubes patent -- it might even have been cited as prior art? Anyhow, that's irrelevant now since the latter is expired, so as far as I can tell there are no issues at all. A Simplified-BSD-licensed version is attached. Zach On Oct 22, 2009, at 8:37 AM, Ralf Gommers wrote: > Hi all, > > I was just looking at the iso-contouring code of Zach Pincus (http://mail.scipy.org/pipermail/scipy-user/2009-July/021719.html > ), and saw it is implemented with the marching squares algorithm. On > the task list that algorithm is listed as well, with a note to > investigate patent issues. So I had a look at that. > > The patent issue was earlier raised in this thread in 2004: http://osdir.com/ml/python.matplotlib.devel/2004-10/msg00066.html > . The open question was whether marching squares was covered under > the patent for marching cubes or not. This is a 1985 patent and has > expired in the meantime, as noted here: http://en.wikipedia.org/wiki/Marching_cubes > . > > IANAL, but I think there are no patent issues anymore. > > > Separate question to Zach: the code you sent to the SciPy list in > July was GPL licensed. You noted you were willing to send it again > under a different license. Could you please send it to the list with > a BSD/MIT/similar license? > > Cheers, > Ralf > -------------- next part -------------- A non-text attachment was scrubbed... Name: find_contours.zip Type: application/zip Size: 7487 bytes Desc: not available URL: From stefan at sun.ac.za Thu Oct 22 04:42:03 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 22 Oct 2009 10:42:03 +0200 Subject: Bug in io.ImageCollection In-Reply-To: References: <9457e7c80910211320q2126c11eg9e7435059f97e5bd@mail.gmail.com> <9457e7c80910211347s2f633514o154e9ec1ea0433a7@mail.gmail.com> Message-ID: <9457e7c80910220142i7c618406l7b6c35e95b771dda@mail.gmail.com> 2009/10/21 Ralf Gommers : >> ?Currently, you have to read the docs to >> figure out what type will be returned, and I feel that element of >> surprise can be eliminated simply by specifying the default >> dtype=float or dtype=np.uint8. > > The returned type by default is the type the image was saved as. To me that > is the only thing that makes sense. Thanks, that's a convincing argument. Cheers St?fan From ralf.gommers at googlemail.com Thu Oct 22 06:00:52 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 22 Oct 2009 12:00:52 +0200 Subject: color spaces In-Reply-To: <9457e7c80910211313w16ba0b59obd95b4da42405251@mail.gmail.com> References: <9457e7c80910211313w16ba0b59obd95b4da42405251@mail.gmail.com> Message-ID: 2009/10/21 St?fan van der Walt > > Hi Ralf > > 2009/10/21 Ralf Gommers : > > I'm working on the color spaces, and would like some feedback. Doing > color > > space conversions is very simple, but finding the right references and > > making sure things are correct is a real pain. So I'm wondering what > spaces > > are useful and unambiguously defined. > > Let's stick to the unambiguous cases and see what feedback we get. If > the user requirements are more ambitious, we'll await patches :) > > Sure. I'm done for now, we have support for four spaces: RGB, HSV, XYZ, RGB CIE. Other spaces that could be included are HSL, CMYK, LAB and LUV, but let's wait till what is there now gets some usage first. > We should definitely link to Poynton's FAQ in the docs: > > http://www.poynton.com/ColorFAQ.html > Yes, very useful doc. Cheers, Ralf > > Good stuff! > > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sccolbert at gmail.com Thu Oct 22 06:13:03 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Thu, 22 Oct 2009 12:13:03 +0200 Subject: color spaces In-Reply-To: References: <9457e7c80910211313w16ba0b59obd95b4da42405251@mail.gmail.com> Message-ID: <7f014ea60910220313n695df8acn7e38508c0f0345bf@mail.gmail.com> Looks Good, I will hold off then on cvCvtColor unless it's requested... Cheers! Chris On Thu, Oct 22, 2009 at 12:00 PM, Ralf Gommers wrote: > > > 2009/10/21 St?fan van der Walt >> >> Hi Ralf >> >> 2009/10/21 Ralf Gommers : >> > I'm working on the color spaces, and would like some feedback. Doing >> > color >> > space conversions is very simple, but finding the right references and >> > making sure things are correct is a real pain. So I'm wondering what >> > spaces >> > are useful and unambiguously defined. >> >> Let's stick to the unambiguous cases and see what feedback we get. ?If >> the user requirements are more ambitious, we'll await patches :) >> > Sure. I'm done for now, we have support for four spaces: RGB, HSV, XYZ, RGB > CIE. > > Other spaces that could be included are HSL, CMYK, LAB and LUV, but let's > wait till what is there now gets some usage first. > >> >> We should definitely link to Poynton's FAQ in the docs: >> >> http://www.poynton.com/ColorFAQ.html > > Yes, very useful doc. > > Cheers, > Ralf > >> >> Good stuff! >> >> Cheers >> St?fan > > From ralf.gommers at googlemail.com Thu Oct 22 08:37:25 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 22 Oct 2009 14:37:25 +0200 Subject: isocontours, marching squares, patent issue Message-ID: Hi all, I was just looking at the iso-contouring code of Zach Pincus ( http://mail.scipy.org/pipermail/scipy-user/2009-July/021719.html), and saw it is implemented with the marching squares algorithm. On the task list that algorithm is listed as well, with a note to investigate patent issues. So I had a look at that. The patent issue was earlier raised in this thread in 2004: http://osdir.com/ml/python.matplotlib.devel/2004-10/msg00066.html. The open question was whether marching squares was covered under the patent for marching cubes or not. This is a 1985 patent and has expired in the meantime, as noted here: http://en.wikipedia.org/wiki/Marching_cubes. IANAL, but I think there are no patent issues anymore. Separate question to Zach: the code you sent to the SciPy list in July was GPL licensed. You noted you were willing to send it again under a different license. Could you please send it to the list with a BSD/MIT/similar license? Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Thu Oct 22 10:15:42 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Thu, 22 Oct 2009 16:15:42 +0200 Subject: isocontours, marching squares, patent issue In-Reply-To: References: Message-ID: On Thu, Oct 22, 2009 at 3:42 PM, Zachary Pincus wrote: > I do not believe that the "marching squares" algorithm was ever covered > under the marching cubes patent -- it might even have been cited as prior > art? Anyhow, that's irrelevant now since the latter is expired, so as far as > I can tell there are no issues at all. > > A Simplified-BSD-licensed version is attached. > > Thanks! Ralf > Zach > > > > On Oct 22, 2009, at 8:37 AM, Ralf Gommers wrote: > > Hi all, >> >> I was just looking at the iso-contouring code of Zach Pincus ( >> http://mail.scipy.org/pipermail/scipy-user/2009-July/021719.html), and >> saw it is implemented with the marching squares algorithm. On the task list >> that algorithm is listed as well, with a note to investigate patent issues. >> So I had a look at that. >> >> The patent issue was earlier raised in this thread in 2004: >> http://osdir.com/ml/python.matplotlib.devel/2004-10/msg00066.html. The >> open question was whether marching squares was covered under the patent for >> marching cubes or not. This is a 1985 patent and has expired in the >> meantime, as noted here: http://en.wikipedia.org/wiki/Marching_cubes. >> >> IANAL, but I think there are no patent issues anymore. >> >> >> Separate question to Zach: the code you sent to the SciPy list in July was >> GPL licensed. You noted you were willing to send it again under a different >> license. Could you please send it to the list with a BSD/MIT/similar >> license? >> >> Cheers, >> Ralf >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Thu Oct 22 12:17:27 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 22 Oct 2009 18:17:27 +0200 Subject: color spaces In-Reply-To: References: Message-ID: <9457e7c80910220917l3a0afc9bk502d76d7c3357fb7@mail.gmail.com> Hi Ralf 2009/10/21 Ralf Gommers : > The code I have so far lives here: > http://github.com/rgommers/scikits.image/tree/color Thanks for cleaning up the colour conversion routines! Here are some review comments: - Add this contribution to CONTRIBUTORS.txt - Do not check types explicitly against ndarray. A safer route is to use "asanyarray". - "float32" is not a valid dtype descriptor -- use np.float32 instead - Question: why are there NaN's in the output? A question that pertains to the scikit as a whole: what do we assume the limits of images to be? I think a common convention is 0-255 for type uint8 and 0-1 for type float. These need to be handled in all functions, and we may soon see patterns emerging that can be captured in standard utility functions. Regards St?fan From sccolbert at gmail.com Thu Oct 22 13:06:34 2009 From: sccolbert at gmail.com (Chris Colbert) Date: Thu, 22 Oct 2009 19:06:34 +0200 Subject: color spaces In-Reply-To: <9457e7c80910220917l3a0afc9bk502d76d7c3357fb7@mail.gmail.com> References: <9457e7c80910220917l3a0afc9bk502d76d7c3357fb7@mail.gmail.com> Message-ID: <7f014ea60910221006x16498e8cu55582f181fdec45e@mail.gmail.com> for the limit for uint8 regardless of what may be routine is 255 ;) that said, I think a more important question is how should we handle overflow on uint8 images? and should we even bother trying? The numpy standard is to wrap, the opencv standard is to threshold at 255. I don't see any easy way to make either of these two do it the other way. Chris 2009/10/22 St?fan van der Walt : > > Hi Ralf > > 2009/10/21 Ralf Gommers : >> The code I have so far lives here: >> http://github.com/rgommers/scikits.image/tree/color > > Thanks for cleaning up the colour conversion routines! ?Here are some > review comments: > > - Add this contribution to CONTRIBUTORS.txt > - Do not check types explicitly against ndarray. ?A safer route is to > use "asanyarray". > - "float32" is not a valid dtype descriptor -- use np.float32 instead > - Question: why are there NaN's in the output? > > A question that pertains to the scikit as a whole: what do we assume > the limits of images to be? ?I think a common convention is 0-255 for > type uint8 and 0-1 for type float. ?These need to be handled in all > functions, and we may soon see patterns emerging that can be captured > in standard utility functions. > > Regards > St?fan > From ralf.gommers at googlemail.com Fri Oct 23 05:02:00 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 23 Oct 2009 11:02:00 +0200 Subject: color spaces In-Reply-To: <9457e7c80910220917l3a0afc9bk502d76d7c3357fb7@mail.gmail.com> References: <9457e7c80910220917l3a0afc9bk502d76d7c3357fb7@mail.gmail.com> Message-ID: Hi Stefan, Thanks for reviewing. 2009/10/22 St?fan van der Walt > > Hi Ralf > > 2009/10/21 Ralf Gommers : > > The code I have so far lives here: > > http://github.com/rgommers/scikits.image/tree/color > > Thanks for cleaning up the colour conversion routines! Here are some > review comments: > > - Add this contribution to CONTRIBUTORS.txt > - Do not check types explicitly against ndarray. A safer route is to > use "asanyarray". > - "float32" is not a valid dtype descriptor -- use np.float32 instead > all done. > - Question: why are there NaN's in the output? > I assume you mean the two isnan checks? I removed the one in hsv2rgb, it was not necessary. The one in rgb2hsv should be there, because there are some divisions (see for example the S channel) that can be zero. Setting those NaN elements to zero is correct, and more efficient than doing a check for zeros beforehand. If you meant you see actual NaN's in the output that would be a bug. Cheers, Ralf > Regards > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Fri Oct 23 05:23:37 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 23 Oct 2009 11:23:37 +0200 Subject: color spaces In-Reply-To: <7f014ea60910221006x16498e8cu55582f181fdec45e@mail.gmail.com> References: <9457e7c80910220917l3a0afc9bk502d76d7c3357fb7@mail.gmail.com> <7f014ea60910221006x16498e8cu55582f181fdec45e@mail.gmail.com> Message-ID: On Thu, Oct 22, 2009 at 7:06 PM, Chris Colbert wrote: > > for the limit for uint8 regardless of what may be routine is 255 ;) > > that said, I think a more important question is how should we handle > overflow on uint8 images? and should we even bother trying? > > The numpy standard is to wrap, the opencv standard is to threshold at > 255. I don't see any easy way to make either of these two do it the > other way. > > Indeed not easy to do, and there's very little one can do with uint8 data anyway. Don't bother trying I would say. > Chris > > 2009/10/22 St?fan van der Walt : > > > > A question that pertains to the scikit as a whole: what do we assume > > the limits of images to be? I think a common convention is 0-255 for > > type uint8 and 0-1 for type float. These need to be handled in all > > functions, and we may soon see patterns emerging that can be captured > > in standard utility functions. > For float images I think we should not assume anything. Rescaling loses information that is valuable, like absolute light intensity. Is there a need to make an assumption like this? uint8: 0-255, the only choice. but again, why assume anything? Cheers, Ralf > > > > Regards > > St?fan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Fri Oct 23 06:29:07 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 23 Oct 2009 12:29:07 +0200 Subject: color spaces In-Reply-To: References: <9457e7c80910220917l3a0afc9bk502d76d7c3357fb7@mail.gmail.com> <7f014ea60910221006x16498e8cu55582f181fdec45e@mail.gmail.com> Message-ID: <9457e7c80910230329q228117ect7b92a7e8e442217e@mail.gmail.com> 2009/10/23 Ralf Gommers : > For float images I think we should not assume anything. Rescaling loses > information that is valuable, like absolute light intensity. Is there a need > to make an assumption like this? I'm pretty sure those assumptions will have to me made sooner rather than later. You didn't need to do any scaling during colour conversion? Lucky, I guess, but it's something that pops up all over the place. Cheers St?fan From ralf.gommers at googlemail.com Fri Oct 23 07:54:15 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 23 Oct 2009 13:54:15 +0200 Subject: color spaces In-Reply-To: <9457e7c80910230329q228117ect7b92a7e8e442217e@mail.gmail.com> References: <9457e7c80910220917l3a0afc9bk502d76d7c3357fb7@mail.gmail.com> <7f014ea60910221006x16498e8cu55582f181fdec45e@mail.gmail.com> <9457e7c80910230329q228117ect7b92a7e8e442217e@mail.gmail.com> Message-ID: 2009/10/23 St?fan van der Walt > > 2009/10/23 Ralf Gommers : > > For float images I think we should not assume anything. Rescaling loses > > information that is valuable, like absolute light intensity. Is there a > need > > to make an assumption like this? > > I'm pretty sure those assumptions will have to me made sooner rather > than later. You didn't need to do any scaling during colour > conversion? Lucky, I guess, but it's something that pops up all over > the place. > Most color conversions were simply matrix multiplication. But you're right, the RGB -> HSV conversion assumes values in the [0, 1] interval. I will add a note. And I agree your 0-255 and 0.-1. defaults are sensible. I still think it is dangerous to automatically scale images. To take the rgb2hsv function as an example, a way to scale would be to check the dtype and then if it is uint8, divide by 255. Now what if the image is 16bit? Or it was uint8 but the user happened to convert it to float already without changing the data range? Say the range is [0.5 - 127.], do you map it to [0. - 1.] or [0.5 - 127.] / 255? When you need to assume a range, I think it should be in the docs, maybe even use a warning or a scale(=False) parameter if it's important. Provide some utility functions for users to scale to different data ranges. But automatic scaling is tricky and will usually not do the right thing for all users. Cheers, Ralf > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsyu80 at gmail.com Wed Oct 28 17:36:17 2009 From: tsyu80 at gmail.com (Tony S Yu) Date: Wed, 28 Oct 2009 17:36:17 -0400 Subject: reading images in palette mode Message-ID: <658358CD-BE2F-45D4-9BD5-ECB0D18AE8D1@gmail.com> Hi, Currently, imread doesn't properly handle palette images since PIL palette images can't be converted directly to numpy arrays. Well, you can convert it, but the output is garbage since the array values correspond to the image palette, which you don't have access. Flattening the image seems to be an OK work around, but if the image had a color palette, this information is lost. Also, this work around requires you to know that an image is in palette mode before calling imread. Below is a short patch that checks if an image is in palette mode; if it is, grayscale images are converted to luminance mode and color images are converted to RGB. I'm not sure if these conversions are appropriate, but at least it's an improvement. I hope this is helpful to somebody. Cheers, -Tony P.S. `palette_is_grayscale` is a convoluted function to check whether the palette is grayscale. PIL may provide a simpler check; if so, I couldn't find it. P.P.S. The following link has examples of palette images if you want to test: http://homepages.inf.ed.ac.uk/rbf/HIPR2/libfce.htm (NOTE: the thumbnails are actually not palette images, but the linked images are) ~~~~~~~ diff --git a/scikits/image/io/pil_imread.py b/scikits/image/io/ pil_imread.py index 421f45c..946d00c 100644 --- a/scikits/image/io/pil_imread.py +++ b/scikits/image/io/pil_imread.py @@ -34,6 +34,34 @@ def imread(fname, flatten=False, dtype=None): " instructions.") im = Image.open(fname) + if im.mode == 'P': + if palette_is_grayscale(im): + im = im.convert('L') + else: + im = im.convert('RGB') if flatten and not im.mode in ('1', 'L', 'I', 'F', 'I;16', 'I; 16L', 'I;16B'): im = im.convert('F') return np.array(im, dtype=dtype) + + +def palette_is_grayscale(pil_image): + """Return True if PIL image is grayscale. + + Parameters + ---------- + pil_image : PIL image + PIL Image that is in Palette mode. + + Returns + ------- + is_grayscale : bool + True if all colors in image palette are gray. + """ + assert pil_image.mode == 'P' + # get palette as an array with R, G, B columns + palette = np.asarray(pil_image.getpalette()).reshape((256, 3)) + # Not all palette colors are used; unused colors have junk values. + start, stop = pil_image.getextrema() + valid_palette = palette[start:stop] + # Image is grayscale if channel differences (R - G and G - B) are all zero. + return np.allclose(np.diff(valid_palette), 0) From ralf.gommers at googlemail.com Fri Oct 30 11:31:50 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Fri, 30 Oct 2009 16:31:50 +0100 Subject: reading images in palette mode In-Reply-To: <658358CD-BE2F-45D4-9BD5-ECB0D18AE8D1@gmail.com> References: <658358CD-BE2F-45D4-9BD5-ECB0D18AE8D1@gmail.com> Message-ID: Hi Tony, On Wed, Oct 28, 2009 at 10:36 PM, Tony S Yu wrote: > > Hi, > > Currently, imread doesn't properly handle palette images since PIL palette > images can't be converted directly to numpy arrays. Well, you can convert > it, but the output is garbage since the array values correspond to the image > palette, which you don't have access. > > Flattening the image seems to be an OK work around, but if the image had a > color palette, this information is lost. Also, this work around requires you > to know that an image is in palette mode before calling imread. > > Below is a short patch that checks if an image is in palette mode; if it > is, grayscale images are converted to luminance mode and color images are > converted to RGB. I'm not sure if these conversions are appropriate, but at > least it's an improvement. > > I hope this is helpful to somebody. Cheers, > This looks like a useful addition to me. The images on the page you linked to can not be included I think (copyright), so could you generate two small palette images (one rgb, one grey, 10x10 pixels) for use in a test? (or ideally, write the test:)) Also, I see you are already using git, so next time could you push your changes to github as described here http://stefanv.github.com/scikits.image/contribute.html#development-process, that would make it a bit faster to test. Thanks, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsyu80 at gmail.com Sat Oct 31 12:36:59 2009 From: tsyu80 at gmail.com (Tony S Yu) Date: Sat, 31 Oct 2009 12:36:59 -0400 Subject: reading images in palette mode In-Reply-To: References: <658358CD-BE2F-45D4-9BD5-ECB0D18AE8D1@gmail.com> Message-ID: <47028081-BAB9-4296-A3CE-569D69299961@gmail.com> Hi Ralf, Thanks for the feedback. On Oct 30, 2009, at 11:31 AM, Ralf Gommers wrote: > The images on the page you linked to can not be included I think > (copyright), so could you generate two small palette images (one > rgb, one grey, 10x10 pixels) for use in a test? (or ideally, write > the test:)) I couldn't easily find any palette images that weren't copyrighted; it never occurred to me just create them. Thanks. > Also, I see you are already using git, so next time could you push > your changes to github as described here http://stefanv.github.com/scikits.image/contribute.html#development-process > , that would make it a bit faster to test. I was afraid I'd have to learn git. ;) I added the changes in three commits to: http://github.com/tonysyu/scikits.image The first commit just adds the images, the second adds palette image handling + a test, and the third adds an additional test. I wasn't sure how to test imread. I ended up checking that imread returns a 2D array for the grayscale palette image and a 3D array for the color palette image. Another possibility is to test the values of the array, but that seems fragile. The last commit adds a test of the function `palette_is_gray`. Unfortunately, the test is a bit ugly. First, I had to add an import of PIL in the test, since palette_is_gray works specifically on PIL palette images. Second, I had to add `palette_is_grayscale` to __all__ in pil_imread so that I could use the function in my test. (Python documentation suggests that __all__ only affects ``from <> import *``, but it seemed to prevent ``from scikits.image.io import palette_is_grayscale``.) Let me know what you think of the tests. Also, should I do a pull request? Best, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsyu80 at gmail.com Sat Oct 31 15:48:47 2009 From: tsyu80 at gmail.com (Tony S Yu) Date: Sat, 31 Oct 2009 15:48:47 -0400 Subject: reading images in palette mode In-Reply-To: References: <658358CD-BE2F-45D4-9BD5-ECB0D18AE8D1@gmail.com> <47028081-BAB9-4296-A3CE-569D69299961@gmail.com> Message-ID: On Oct 31, 2009, at 1:48 PM, Ralf Gommers wrote: > The last commit adds a test of the function `palette_is_gray`. > Unfortunately, the test is a bit ugly. First, I had to add an import > of PIL in the test, since palette_is_gray works specifically on PIL > palette images. Second, I had to add `palette_is_grayscale` to > __all__ in pil_imread so that I could use the function in my test. > (Python documentation suggests that __all__ only affects ``from <> > import *``, but it seemed to prevent ``from scikits.image.io import > palette_is_grayscale``.) > > The PIL import is fine, but the try-except block is unnecessary > since that is already done in imread. > > Adding to __all__ is not necessary, you can import it from > io.pil_imread. Ahh, of course. > I did notice that other imread tests fail already if PIL is not > available. For this we do need an @pil_skip decorator I think. > > Let me know what you think of the tests. Also, should I do a pull > request? > > Looks good overall. I made some minor changes reflecting the > comments I made above: http://github.com/rgommers/scikits.image/commit/a6ad7415d7a43185cea898d3454e087b0b01f105 > > If you are happy with those, you can pull my palette branch over and > send Stefan a pull request. The changes look good. Thanks! Pull request sent. Thanks, -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Sat Oct 31 13:48:26 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sat, 31 Oct 2009 18:48:26 +0100 Subject: reading images in palette mode In-Reply-To: <47028081-BAB9-4296-A3CE-569D69299961@gmail.com> References: <658358CD-BE2F-45D4-9BD5-ECB0D18AE8D1@gmail.com> <47028081-BAB9-4296-A3CE-569D69299961@gmail.com> Message-ID: Hi Tony, On Sat, Oct 31, 2009 at 5:36 PM, Tony S Yu wrote: > Hi Ralf, > > Thanks for the feedback. > > On Oct 30, 2009, at 11:31 AM, Ralf Gommers wrote: > > The images on the page you linked to can not be included I think > (copyright), so could you generate two small palette images (one rgb, one > grey, 10x10 pixels) for use in a test? (or ideally, write the test:)) > > > I couldn't easily find any palette images that weren't copyrighted; it > never occurred to me just create them. Thanks. > You're welcome. In addition to avoiding copyright issues, it is nice to have very small images. Otherwise the size of the scikit would be completely dominated by lots of large test images after a while. > > Also, I see you are already using git, so next time could you push your > changes to github as described here > http://stefanv.github.com/scikits.image/contribute.html#development-process, > that would make it a bit faster to test. > > > I was afraid I'd have to learn git. ;) > > I trust it wasn't too painful, thanks for doing it. > I added the changes in three commits to: > http://github.com/tonysyu/scikits.image > The first commit just adds the images, the second adds palette image > handling + a test, and the third adds an additional test. > > I wasn't sure how to test imread. I ended up checking that imread returns a > 2D array for the grayscale palette image and a 3D array for the color > palette image. Another possibility is to test the values of the array, but > that seems fragile. > > This looks fine to me. Testing values would be good as well, and if you do it with assert_array_almost_equal from numpy.testing it should not be fragile. > The last commit adds a test of the function `palette_is_gray`. > Unfortunately, the test is a bit ugly. First, I had to add an import of PIL > in the test, since palette_is_gray works specifically on PIL palette images. > Second, I had to add `palette_is_grayscale` to __all__ in pil_imread so that > I could use the function in my test. (Python documentation suggests that > __all__ only affects ``from <> import *``, but it seemed to prevent ``from > scikits.image.io import palette_is_grayscale``.) > > The PIL import is fine, but the try-except block is unnecessary since that is already done in imread. Adding to __all__ is not necessary, you can import it from io.pil_imread. I did notice that other imread tests fail already if PIL is not available. For this we do need an @pil_skip decorator I think. > Let me know what you think of the tests. Also, should I do a pull request? > Looks good overall. I made some minor changes reflecting the comments I made above: http://github.com/rgommers/scikits.image/commit/a6ad7415d7a43185cea898d3454e087b0b01f105 If you are happy with those, you can pull my palette branch over and send Stefan a pull request. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Sat Oct 31 17:55:40 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sat, 31 Oct 2009 23:55:40 +0200 Subject: Request for review / progress updates Message-ID: <9457e7c80910311455o40e7439ehe5f7b95da567a8d8@mail.gmail.com> Hey guys, I finally got around to writing a draft of the proposed plugin system. You'll find this work in the 'io' branch at http://github.com/stefanv/scikits.image It's still a work in progress, but I welcome all comments. Example plugins are http://github.com/stefanv/scikits.image/blob/io/scikits/image/io/matplotlib_plugin.py http://github.com/stefanv/scikits.image/blob/io/scikits/image/io/pil_plugin.py I've merged Ralf's colour space conversions, as well as his code coverage enhancements. Ralf is now documenting the coverage process and will also look at improving the execution time of the slow filter tests. For OpenCV, Chris wrote a docs-decorator that now provides us with links to the OpenCV online reference: http://stefanv.github.com/scikits.image/api/scikits.image.opencv.html#cvlaplace He added more functions to the cv module, and is busy implementing some checks to make sure that even slices out of ndarray's may be passed to OpenCV, whenever possible. Tony Yu (welcome!) did some work on loading paletted images. I'll be sure to review those changes tomorrow. Have yourselves a splendid weekend! Cheers St?fan From ralf.gommers at googlemail.com Sat Oct 31 19:07:08 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sun, 1 Nov 2009 00:07:08 +0100 Subject: Request for review / progress updates In-Reply-To: <9457e7c80910311455o40e7439ehe5f7b95da567a8d8@mail.gmail.com> References: <9457e7c80910311455o40e7439ehe5f7b95da567a8d8@mail.gmail.com> Message-ID: Hi Stefan, 2009/10/31 St?fan van der Walt > > Hey guys, > > I finally got around to writing a draft of the proposed plugin system. > You'll find this work in the 'io' branch at > > http://github.com/stefanv/scikits.image > > It's still a work in progress, but I welcome all comments. Example plugins > are > > > http://github.com/stefanv/scikits.image/blob/io/scikits/image/io/matplotlib_plugin.py > > http://github.com/stefanv/scikits.image/blob/io/scikits/image/io/pil_plugin.py > > That looks promising! It all works for me, and it's easy to understand. The one thing I can think of after quickly looking through it, is some convenience funcs to get/set the defaults for the plugin, both for all keywords in plugin_store or for a single keyword. This will help when plugins start to overlap in functionality. I would for example like to be able to set MPL to be the default for showing/saving, and PIL for loading, without having to use plugin='...' each time. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: