From zachary.pincus at yale.edu Fri Sep 11 12:24:20 2009 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Fri, 11 Sep 2009 12:24:20 -0400 Subject: OpenImageIO In-Reply-To: <9457e7c80909110806wecd6b79o720bf2bda586822c@mail.gmail.com> References: <9457e7c80909110806wecd6b79o720bf2bda586822c@mail.gmail.com> Message-ID: Provided the library is pretty lightweight and easy to build, this might not be a bad idea at all... Zach On Sep 11, 2009, at 11:06 AM, St?fan van der Walt wrote: > > Hi all, > > The OpenImageIO project will soon have Python bindings available. If > we are willing to introduce their library as a dependency, we'll be > able to load many image formats. I'd be quite happy to stick to a > pure Python loader as well, but I don't know if such code exists. > > http://openimageio.org/ > > Enjoy your weekend! > > Cheers > St?fan From stefan at sun.ac.za Fri Sep 11 11:06:35 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 11 Sep 2009 17:06:35 +0200 Subject: OpenImageIO Message-ID: <9457e7c80909110806wecd6b79o720bf2bda586822c@mail.gmail.com> Hi all, The OpenImageIO project will soon have Python bindings available. If we are willing to introduce their library as a dependency, we'll be able to load many image formats. I'd be quite happy to stick to a pure Python loader as well, but I don't know if such code exists. http://openimageio.org/ Enjoy your weekend! Cheers St?fan From stefan at sun.ac.za Thu Sep 24 13:43:45 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Thu, 24 Sep 2009 19:43:45 +0200 Subject: ANN: Image Processing SciKit Message-ID: <9457e7c80909241043h6b94c18q5e4fb8ccc5cdc657@mail.gmail.com> Hi all, After a short sprint at SciPy 2009, we've put together the infrastructure for an Image Processing SciKit. The source code [1] and documentatin [2] is available online. WIth the infrastructure in place, the next focus will be on getting contributions (listed at [3]) merged. If you have code for generally useful image processing algorithms available, please consider contributing. Feel free to join further discussions on the scikit mailing list [4]. Kind regards St?fan [1] http://github.com/stefanv/scikits.image [2] http://stefanv.github.com/scikits.image [3] http://conference.scipy.org/sprints [4] http://groups.google.com/group/scikits-image From gary.ruben at gmail.com Fri Sep 25 00:01:48 2009 From: gary.ruben at gmail.com (Gary Ruben) Date: Thu, 24 Sep 2009 21:01:48 -0700 (PDT) Subject: ideas for contributions Message-ID: <9e767ebd-b366-40fb-84eb-8ef971f0c9c2@h40g2000prf.googlegroups.com> You may already know this, but pymorph is BSD licensed and may be a good starting point for incorporating morphological functions: http://luispedro.org/pymorph/ Also, I'm going to advertise the existence of this toolbox around here - I know a friend has some filtered back-projection code which may still be based on numarray, but is apparently quite fast. I'll try to get him to contribute it (and numpyify it first if necessary). Also I have some small Finite Radon Transform routines, which are pure Python and hence not super fast (but they are super fast compared to Matlab) but they do work correctly. It's not a widely used transform but if you're interested, I'm happy to contribute it to scikits.image.transform. From msarahan at gmail.com Fri Sep 25 00:17:50 2009 From: msarahan at gmail.com (Mike Sarahan) Date: Thu, 24 Sep 2009 21:17:50 -0700 Subject: ideas for contributions In-Reply-To: <9e767ebd-b366-40fb-84eb-8ef971f0c9c2@h40g2000prf.googlegroups.com> References: <9e767ebd-b366-40fb-84eb-8ef971f0c9c2@h40g2000prf.googlegroups.com> Message-ID: <8275939c0909242117x49e66607r937118e52ad7ac40@mail.gmail.com> Those radon transforms & filtered backprojection would be of great interest to me (I'm in electron microscopy.) I'd be interested in seeing those make it into the kit, and willing to help do any integration work. -Mike On Thu, Sep 24, 2009 at 9:01 PM, Gary Ruben wrote: > > You may already know this, but pymorph is BSD licensed and may be a > good starting point for incorporating morphological functions: > http://luispedro.org/pymorph/ > > Also, I'm going to advertise the existence of this toolbox around here > - I know a friend has some filtered back-projection code which may > still be based on numarray, but is apparently quite fast. I'll try to > get him to contribute it (and numpyify it first if necessary). > > Also I have some small Finite Radon Transform routines, which are pure > Python and hence not super fast (but they are super fast compared to > Matlab) but they do work correctly. It's not a widely used transform > but if you're interested, I'm happy to contribute it to > scikits.image.transform. From msarahan at gmail.com Fri Sep 25 00:34:53 2009 From: msarahan at gmail.com (Mike Sarahan) Date: Thu, 24 Sep 2009 21:34:53 -0700 Subject: OpenCV? Message-ID: <8275939c0909242134m2a3834ck2568540d5a2c382c@mail.gmail.com> Sorry if I missed this in discussions at the sprint, but is there any reason we're not taking advantage of OpenCV? It may be a little more than what this scikit is aiming to offer, but it has some really nice, well-optimized routines. It's BSD licensed. I have been using the ctypes-opencv python wrapper, which is also BSD licensed. Yes, it's another dependency, but it's really easy to get - Ubuntu & Fedora have packages, binaries are readily available for Windows, and it has built easily on my OSX system. If you guys think it's something worth including, I can work on getting the wrappers integrated with the scikit. -Mike From stefan at sun.ac.za Fri Sep 25 02:40:35 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 25 Sep 2009 08:40:35 +0200 Subject: OpenCV? In-Reply-To: <8275939c0909242134m2a3834ck2568540d5a2c382c@mail.gmail.com> References: <8275939c0909242134m2a3834ck2568540d5a2c382c@mail.gmail.com> Message-ID: <9457e7c80909242340p28fea9e2h8d788c859e8a7c4e@mail.gmail.com> Hi Mike 2009/9/25 Mike Sarahan : > Sorry if I missed this in discussions at the sprint, but is there any > reason we're not taking advantage of OpenCV? ?It may be a little more > than what this scikit is aiming to offer, but it has some really nice, > well-optimized routines. ?It's BSD licensed. ?I have been using the > ctypes-opencv python wrapper, which is also BSD licensed. I know there are two sets of wrappers, but I haven't used either. Do you know their pros and cons? OpenCV is a fairly heavy dependency, but if it adds good value I see little reason to avoid it. Regards St?fan From stefan at sun.ac.za Fri Sep 25 02:48:32 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 25 Sep 2009 08:48:32 +0200 Subject: ideas for contributions In-Reply-To: <9e767ebd-b366-40fb-84eb-8ef971f0c9c2@h40g2000prf.googlegroups.com> References: <9e767ebd-b366-40fb-84eb-8ef971f0c9c2@h40g2000prf.googlegroups.com> Message-ID: <9457e7c80909242348l5e2e65e1gc29cf56b60847a10@mail.gmail.com> 2009/9/25 Gary Ruben : > You may already know this, but pymorph is BSD licensed and may be a > good starting point for incorporating morphological functions: > http://luispedro.org/pymorph/ Damian has been working on morphological operators during the sprint, so I'll ask him to compare pymorph to the work he has done so far. It looks like pymorph pretty much covers all the Matlab functionality? > Also I have some small Finite Radon Transform routines, which are pure > Python and hence not super fast (but they are super fast compared to > Matlab) but they do work correctly. It's not a widely used transform > but if you're interested, I'm happy to contribute it to > scikits.image.transform. I'd be very interested to see this code included! Regards St?fan From eads at soe.ucsc.edu Fri Sep 25 04:44:46 2009 From: eads at soe.ucsc.edu (Damian Eads) Date: Fri, 25 Sep 2009 09:44:46 +0100 Subject: OpenCV? In-Reply-To: <9457e7c80909242340p28fea9e2h8d788c859e8a7c4e@mail.gmail.com> References: <8275939c0909242134m2a3834ck2568540d5a2c382c@mail.gmail.com> <9457e7c80909242340p28fea9e2h8d788c859e8a7c4e@mail.gmail.com> Message-ID: <462e7fdf0909250144mdb1963emf532f6be21c90e14@mail.gmail.com> LIBCVD: http://mi.eng.cam.ac.uk/~er258/cvd/ 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. For example, Image img = img_load("lena.png") Image out(img.size()); convolveGaussian(img, out, 3.0); loads an image from a file and convolves a Gaussian with it. LIBCVD's design is very simple: there are only three main classes and its interface is designed to be very functional so it translates from Python very nicely. Most of its dependencies are optional so it compiles very easily. You don't have to use pointers very much in LIBCVD, which eliminates many kinds of bugs--iteration is done with highly optimized and succinct iterators and index operators (e.g. image[y][x]). Best of all, it's very fast. Damian PS: I'm cc'ing Edward Rosten who's the author of LIBCVD. 2009/9/25 St?fan van der Walt : > > Hi Mike > > 2009/9/25 Mike Sarahan : >> Sorry if I missed this in discussions at the sprint, but is there any >> reason we're not taking advantage of OpenCV? ?It may be a little more >> than what this scikit is aiming to offer, but it has some really nice, >> well-optimized routines. ?It's BSD licensed. ?I have been using the >> ctypes-opencv python wrapper, which is also BSD licensed. > > I know there are two sets of wrappers, but I haven't used either. ?Do > you know their pros and cons? > > OpenCV is a fairly heavy dependency, but if it adds good value I see > little reason to avoid it. > > 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 Fri Sep 25 05:21:02 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 25 Sep 2009 11:21:02 +0200 Subject: OpenCV? In-Reply-To: <462e7fdf0909250144mdb1963emf532f6be21c90e14@mail.gmail.com> References: <8275939c0909242134m2a3834ck2568540d5a2c382c@mail.gmail.com> <9457e7c80909242340p28fea9e2h8d788c859e8a7c4e@mail.gmail.com> <462e7fdf0909250144mdb1963emf532f6be21c90e14@mail.gmail.com> Message-ID: <9457e7c80909250221lb72925i3d5f994cb17b8171@mail.gmail.com> 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 gary.ruben at gmail.com Sun Sep 27 07:48:55 2009 From: gary.ruben at gmail.com (Gary Ruben) Date: Sun, 27 Sep 2009 04:48:55 -0700 (PDT) Subject: ideas for contributions In-Reply-To: <9457e7c80909242348l5e2e65e1gc29cf56b60847a10@mail.gmail.com> References: <9e767ebd-b366-40fb-84eb-8ef971f0c9c2@h40g2000prf.googlegroups.com> <9457e7c80909242348l5e2e65e1gc29cf56b60847a10@mail.gmail.com> Message-ID: <439457ac-ebcf-48cc-acac-9a2c8d94f72f@x5g2000prf.googlegroups.com> I've set up a github account and added my finite radon transform code to my local clone. St?fan, should I try pushing the changes back? A little bit of information about the frt. My code is a pure Python implementation. I'm told that one can implement the frt in terms of the fft which should be faster, but maybe only if rewritten in C or Cython. The best/fastest way is actually to use the number theoretic transform (ntt) which the guy in the next office to me, who is doing his PhD on this, has implemented. Anyway, that's for the future. For now, I have the frt code and my other friend said he's willing to donate the other numpy routines. This is the filtered back projection code and some other forward transform routines, which he says do work with numpy. I may take Mike Sarahan up on his offer to integrate that code, because I shouldn't be spending time on this at the moment, but my friend may do it himself. Gary From stefan at sun.ac.za Sun Sep 27 18:48:09 2009 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 28 Sep 2009 00:48:09 +0200 Subject: ideas for contributions In-Reply-To: <439457ac-ebcf-48cc-acac-9a2c8d94f72f@x5g2000prf.googlegroups.com> References: <9e767ebd-b366-40fb-84eb-8ef971f0c9c2@h40g2000prf.googlegroups.com> <9457e7c80909242348l5e2e65e1gc29cf56b60847a10@mail.gmail.com> <439457ac-ebcf-48cc-acac-9a2c8d94f72f@x5g2000prf.googlegroups.com> Message-ID: <9457e7c80909271548nf422aa9udb4e9536e07945cf@mail.gmail.com> Hi Gary 2009/9/27 Gary Ruben : > I've set up a github account and added my finite radon transform code > to my local clone. St?fan, should I try pushing the changes back? That's fantastic -- thanks. Could you please send me the url of your branch or, even easier, click on "request merge" on Github? Regards St?fan From dwf at cs.toronto.edu Tue Sep 29 20:59:16 2009 From: dwf at cs.toronto.edu (David Warde-Farley) Date: Tue, 29 Sep 2009 20:59:16 -0400 Subject: [SciPy-User] How to create multi-page tiff files with python tools? In-Reply-To: References: Message-ID: <29AB395E-0D54-497A-ADB3-DD3C78F3693D@cs.toronto.edu> On 29-Sep-09, at 2:24 PM, Ralf Gommers wrote: > On Tue, Sep 29, 2009 at 11:14 AM, Sebastian Haase > wrote: > > Hi Sebastian, this is very useful functionality for me as well. > > The question I have is if your patched PIL includes fixes for 16-bit > images. > Right now I'm using a patched PIL kindly provided to me by Zachary > Pincus > that fixes 16-bit issues. I saw that some improvements for 16-bit were > included in PIL trunk but not his patches. Your patch is included it > seems, > so I could also run PIL trunk if someone can confirm that 16-bit TIF > images > work. I'd prefer Priithon though because then I could stop asking my > users > to compile PIL themselves... I've been following this discussion somewhat and I wanted to point out that (as far as I can remember) image I/O free of PIL dependence was one of the stated goals of the image scikit. I'm not sure much progress has been made on that front yet. It seems that common requirements not being met by PIL are a) full support for multipage TIFF (loading, creating, saving) b) 16-bit multipage TIFF Rather than monkeypatching PIL four ways from Sunday, maybe it would be best to direct efforts towards building a PIL-free alternative? Incorporation of very specific code from PIL shouldn't be an issue given that PIL is quite liberally licensed. David (P.S. I'm CCing the scikits-image list as well, should you want to join it, etc.) From ralf.gommers at googlemail.com Tue Sep 29 22:11:13 2009 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Tue, 29 Sep 2009 22:11:13 -0400 Subject: [SciPy-User] How to create multi-page tiff files with python tools? In-Reply-To: <29AB395E-0D54-497A-ADB3-DD3C78F3693D@cs.toronto.edu> References: <29AB395E-0D54-497A-ADB3-DD3C78F3693D@cs.toronto.edu> Message-ID: On Tue, Sep 29, 2009 at 8:59 PM, David Warde-Farley wrote: > > On 29-Sep-09, at 2:24 PM, Ralf Gommers wrote: > > Hi Sebastian, this is very useful functionality for me as well. >> >> The question I have is if your patched PIL includes fixes for 16-bit >> images. >> Right now I'm using a patched PIL kindly provided to me by Zachary Pincus >> that fixes 16-bit issues. I saw that some improvements for 16-bit were >> included in PIL trunk but not his patches. Your patch is included it >> seems, >> so I could also run PIL trunk if someone can confirm that 16-bit TIF >> images >> work. I'd prefer Priithon though because then I could stop asking my users >> to compile PIL themselves... >> > > > I've been following this discussion somewhat and I wanted to point out that > (as far as I can remember) image I/O free of PIL dependence was one of the > stated goals of the image scikit. I'm not sure much progress has been made > on that front yet. > > It seems that common requirements not being met by PIL are > a) full support for multipage TIFF (loading, creating, saving) > b) 16-bit multipage TIFF > > Rather than monkeypatching PIL four ways from Sunday, maybe it would be > best to direct efforts towards building a PIL-free alternative? > Incorporation of very specific code from PIL shouldn't be an issue given > that PIL is quite liberally licensed. > That would be great. I don't know much about PIL internals but I am up for contributing tests and documentation if such an effort is made. Cheers, Ralf > > David > > (P.S. I'm CCing the scikits-image list as well, should you want to join it, > etc.) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eads at soe.ucsc.edu Wed Sep 30 09:27:22 2009 From: eads at soe.ucsc.edu (Damian Eads) Date: Wed, 30 Sep 2009 14:27:22 +0100 Subject: ideas for contributions In-Reply-To: <9457e7c80909242348l5e2e65e1gc29cf56b60847a10@mail.gmail.com> References: <9e767ebd-b366-40fb-84eb-8ef971f0c9c2@h40g2000prf.googlegroups.com> <9457e7c80909242348l5e2e65e1gc29cf56b60847a10@mail.gmail.com> Message-ID: <462e7fdf0909300627q3f43798ak5b96a7ea2bdca5ed@mail.gmail.com> Hi Stefan, Sorry for the delayed response. I've been traveling a bit and my connectivity has been pretty intermittent. 2009/9/25 St?fan van der Walt : > > 2009/9/25 Gary Ruben : >> You may already know this, but pymorph is BSD licensed and may be a >> good starting point for incorporating morphological functions: >> http://luispedro.org/pymorph/ > > Damian has been working on morphological operators during the sprint, > so I'll ask him to compare pymorph to the work he has done so far. ?It > looks like pymorph pretty much covers all the Matlab functionality? Very interesting. pymorph is a huge library that covers a large space of mathematical morphology algorithms. I searched around google, sourceforge, and their project website, and I've been unable to find their source code to see exactly what it depends on and how it might be integrated into scikits.image. They only have a windows release of their code so I'm unable at the moment to try some benchmarks on my Linux machine. The API should definitely be changed: the function names are too short and every function begins with mm rather than using a module name to encapsulate. LIBCVD supports highly optimized, basic morphology but not the full space of algorithms provided by pymorph. 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 gary.ruben at gmail.com Wed Sep 30 10:26:21 2009 From: gary.ruben at gmail.com (Gary Ruben) Date: Thu, 01 Oct 2009 00:26:21 +1000 Subject: ideas for contributions In-Reply-To: <462e7fdf0909300627q3f43798ak5b96a7ea2bdca5ed@mail.gmail.com> References: <9e767ebd-b366-40fb-84eb-8ef971f0c9c2@h40g2000prf.googlegroups.com> <9457e7c80909242348l5e2e65e1gc29cf56b60847a10@mail.gmail.com> <462e7fdf0909300627q3f43798ak5b96a7ea2bdca5ed@mail.gmail.com> Message-ID: <4AC36A8D.4090607@gmail.com> Hi Damian, The code is accessible via a link on Lu??s Pedro Coelho's site, but the documentation is hosted by the original authors. To be precise, the source is here: http://luispedro.org/files/pymorph-0.91.1.tar.gz He says this further down also: "Most of the documentation in the original documentation is still valid, except that I removed the mm prefix from function names..." "I also changed other small things, including removing some functions which were superfluous. See the CHANGES_SINCE_08 file in the distribution." It looks to me like it's purely dependent on numpy and a couple of standard Python modules. Perhaps it could actually be sped up by making ndimage a dependency and simply replacing a few of the functions in terms of ndimage ones. Gary Damian Eads wrote: > Hi Stefan, > > Sorry for the delayed response. I've been traveling a bit and my > connectivity has been pretty intermittent. > > 2009/9/25 St??fan van der Walt : >> 2009/9/25 Gary Ruben : >>> You may already know this, but pymorph is BSD licensed and may be a >>> good starting point for incorporating morphological functions: >>> http://luispedro.org/pymorph/ >> Damian has been working on morphological operators during the sprint, >> so I'll ask him to compare pymorph to the work he has done so far. It >> looks like pymorph pretty much covers all the Matlab functionality? > > Very interesting. pymorph is a huge library that covers a large space > of mathematical morphology algorithms. I searched around google, > sourceforge, and their project website, and I've been unable to find > their source code to see exactly what it depends on and how it might > be integrated into scikits.image. They only have a windows release of > their code so I'm unable at the moment to try some benchmarks on my > Linux machine. The API should definitely be changed: the function > names are too short and every function begins with mm rather than > using a module name to encapsulate. LIBCVD supports highly optimized, > basic morphology but not the full space of algorithms provided by > pymorph. > > Damian