From mael.primet at gmail.com Mon Nov 1 10:40:55 2010 From: mael.primet at gmail.com (mael) Date: Mon, 1 Nov 2010 07:40:55 -0700 (PDT) Subject: denoising algorithms / working with Github In-Reply-To: References: <20100909214336.GB23543@phare.normalesup.org> <20100910125611.GA31060@phare.normalesup.org>

<20100921160523.GB31763@phare.normalesup.org> <20100921193017.GE31763@phare.normalesup.org> <20100922172444.GA10153@phare.normalesup.org> <0ac62f51-486c-43d6-a360-237faca3871b@h7g2000yqn.googlegroups.com> <20101030215639.GA30142@phare.normalesup.org> Message-ID: On Sun, Oct 31, 2010 at 9:22 PM, Chris Colbert wrote: > The same way you are. i.e. just recompile everything. If you are building in > place, I *think* you can get away with just running the setup.py script in > the directory that has changed files. But don't quote me on that. That should be the case. Also, with in-place builds things won't recompile every time (or if they do it is a bug). St?fan From sccolbert at gmail.com Mon Nov 1 11:01:26 2010 From: sccolbert at gmail.com (Chris Colbert) Date: Mon, 1 Nov 2010 11:01:26 -0400 Subject: denoising algorithms / working with Github In-Reply-To: <2816b690-46e3-45d6-bbf4-7236d6a18619@30g2000yql.googlegroups.com> References: <20100909214336.GB23543@phare.normalesup.org> <20100910125611.GA31060@phare.normalesup.org>

<20100921160523.GB31763@phare.normalesup.org> <20100921193017.GE31763@phare.normalesup.org> <20100922172444.GA10153@phare.normalesup.org> <0ac62f51-486c-43d6-a360-237faca3871b@h7g2000yqn.googlegroups.com> <237cdc4a-be45-4a30-a591-f9b3948f8c87@d8g2000yqf.googlegroups.com> <2816b690-46e3-45d6-bbf4-7236d6a18619@30g2000yql.googlegroups.com> Message-ID: I'm not quite ready at this point to cherry pick or merge. I want to take a longer look at the code and see if we can incorporate the new features into existing things, or merge the two qt viewers into one. On Mon, Nov 1, 2010 at 11:50 AM, Ma?l Primet wrote: > Okay, now it works on my computer, can you try it on your, and then > perhaps cherry-pick and commit to scikits (also merge with histograms if you > have the courage ) > > BTW, perhaps for histogram visualization, it should be more efficient if I > kept a cache of the zoomed float32 image (and not only the end pixmap), and > thus I would be able to > quickly adapt the histogram wihtout having to rezoom the entire image, but > I don't know if this is often necessary (eg. will people often zoom and > change the contrast ) > > > On Mon, Nov 1, 2010 at 16:35, Chris Colbert wrote: > >> in scivi2.py:_simple_imshow you are not passing the window_manager object >> to the widget. So the reference to the image window is lost and window is >> being garbage collected. Once you pass along the reference to the manager, >> the windows displays. >> >> However, the image doesn't show up in the window, so now you have another >> issue to track down ;) >> >> >> >> On Mon, Nov 1, 2010 at 11:22 AM, Ma?l Primet wrote: >> >>> From an interactive shell.. >>> I tried mimicking more closely the definition of scivi.py, but it does >>> not work :p >>> Could you try using it from your computer? (github.com/maelp ) >>> >>> >>> On Mon, Nov 1, 2010 at 16:09, Chris Colbert wrote: >>> >>>> are you using that from an interactive shell or from a script? >>>> >>>> If you are using from a script, you need to call `io.show()` at the end >>>> of your script to enter the toolkit's event loop. >>>> >>>> >>>> On Mon, Nov 1, 2010 at 11:06 AM, Ma?l Primet wrote: >>>> >>>>> I do io.use_plugin('qt2') >>>>> io.imshow(im) >>>>> and it opens and close >>>>> >>>>> >>>>> On Mon, Nov 1, 2010 at 16:01, Chris Colbert wrote: >>>>> >>>>>> how are you running it when the windows don't stay open? >>>>>> >>>>>> On Mon, Nov 1, 2010 at 10:40 AM, mael wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I added a 'qt2' plugin to my github repository, but can't get the >>>>>>> window to stay displayed, >>>>>>> do you know where the problem might be ? >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mael.primet at gmail.com Mon Nov 1 16:12:07 2010 From: mael.primet at gmail.com (mael) Date: Mon, 1 Nov 2010 13:12:07 -0700 (PDT) Subject: denoising algorithms / working with Github In-Reply-To: References: <20100909214336.GB23543@phare.normalesup.org> <20100910125611.GA31060@phare.normalesup.org>

<20100921160523.GB31763@phare.normalesup.org> <20100921193017.GE31763@phare.normalesup.org> <20100922172444.GA10153@phare.normalesup.org> <0ac62f51-486c-43d6-a360-237faca3871b@h7g2000yqn.googlegroups.com> <237cdc4a-be45-4a30-a591-f9b3948f8c87@d8g2000yqf.googlegroups.com> <2816b690-46e3-45d6-bbf4-7236d6a18619@30g2000yql.googlegroups.com> Message-ID: Okay, now it works on my computer, can you try it on your, and then perhaps cherry-pick and commit to scikits (also merge with histograms if you have the courage ) BTW, perhaps for histogram visualization, it should be more efficient if I kept a cache of the zoomed float32 image (and not only the end pixmap), and thus I would be able to quickly adapt the histogram wihtout having to rezoom the entire image, but I don't know if this is often necessary (eg. will people often zoom and change the contrast ) On Mon, Nov 1, 2010 at 16:35, Chris Colbert wrote: > in scivi2.py:_simple_imshow you are not passing the window_manager object > to the widget. So the reference to the image window is lost and window is > being garbage collected. Once you pass along the reference to the manager, > the windows displays. > > However, the image doesn't show up in the window, so now you have another > issue to track down ;) > > > > On Mon, Nov 1, 2010 at 11:22 AM, Ma?l Primet wrote: > >> From an interactive shell.. >> I tried mimicking more closely the definition of scivi.py, but it does not >> work :p >> Could you try using it from your computer? (github.com/maelp ) >> >> >> On Mon, Nov 1, 2010 at 16:09, Chris Colbert wrote: >> >>> are you using that from an interactive shell or from a script? >>> >>> If you are using from a script, you need to call `io.show()` at the end >>> of your script to enter the toolkit's event loop. >>> >>> >>> On Mon, Nov 1, 2010 at 11:06 AM, Ma?l Primet wrote: >>> >>>> I do io.use_plugin('qt2') >>>> io.imshow(im) >>>> and it opens and close >>>> >>>> >>>> On Mon, Nov 1, 2010 at 16:01, Chris Colbert wrote: >>>> >>>>> how are you running it when the windows don't stay open? >>>>> >>>>> On Mon, Nov 1, 2010 at 10:40 AM, mael wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I added a 'qt2' plugin to my github repository, but can't get the >>>>>> window to stay displayed, >>>>>> do you know where the problem might be ? >>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Mon Nov 1 17:17:30 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Mon, 1 Nov 2010 23:17:30 +0200 Subject: denoising algorithms / working with Github In-Reply-To: <9bfe4a75-a9c3-4f0d-9f53-a19e232040f4@s5g2000yqm.googlegroups.com> References: <20100909214336.GB23543@phare.normalesup.org> <20100910125611.GA31060@phare.normalesup.org>

Message-ID: Can you not do this with the Show()/Hide() methods on each widget? I know its possible, but I would have to play around with it for a bit. On Tue, Nov 2, 2010 at 5:20 PM, Ma?l Primet wrote: > Sorry I wasn't clear, my fault, > I know how to act on key signal, my problem is getting the resize > behaviour correctly, > I'm not sure it can be done without reimplementing a Layout? > > can you check this? > > > On Tue, Nov 2, 2010 at 22:17, Chris Colbert wrote: > >> you'll need to setup listeners for the widget's key signals. >> >> You should read the PyQt docs for how to hook up signals and slots. >> >> On Tue, Nov 2, 2010 at 5:08 PM, mael wrote: >> >>> Is anyone comfortable with Qt? >>> >>> I'm having lot of trouble implementing the interface the way I want. >>> Basically, I want something non intrusive, thus the >>> GUI will be shown / hidden by pressing F10, but I don't want this to >>> change the way the viewer is shown, so here is the thing: >>> - first: pressing + zooms x2, I'd like to have ctrl++ zoom x2 and >>> also resize the widget x2 (if small enough for the screen), how can I >>> do that? >>> - second: pressing F10 should keep the viewer as it is, but add some >>> widgets beneath it to tweak each parameter, I can't get Qt to behave >>> this way? >>> >>> (last version of scivi2 is in github.com/maelp/scikits.image ) >>> >>> Thank you >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sccolbert at gmail.com Tue Nov 2 17:26:58 2010 From: sccolbert at gmail.com (Chris Colbert) Date: Tue, 2 Nov 2010 17:26:58 -0400 Subject: denoising algorithms / working with Github In-Reply-To: References: <20100909214336.GB23543@phare.normalesup.org> <20100910125611.GA31060@phare.normalesup.org>

Message-ID: So yes, you would need to specify some form of layout for the widgets: Vertical, Horizontal, Grid, etc... and set the appropriate attributes on the layout and widgets so that they display how you want. Alternatively, you could use QtDesigner and pyuic4 to create your layout, then just wire everything up. (this is how make standalone QT stuff now, because its just so convenient). On Tue, Nov 2, 2010 at 5:24 PM, Ma?l Primet wrote: > Hum.. I can't get widgets to get the correct size > > > On Tue, Nov 2, 2010 at 22:23, Chris Colbert wrote: > >> Can you not do this with the Show()/Hide() methods on each widget? >> >> I know its possible, but I would have to play around with it for a bit. >> >> >> On Tue, Nov 2, 2010 at 5:20 PM, Ma?l Primet wrote: >> >>> Sorry I wasn't clear, my fault, >>> I know how to act on key signal, my problem is getting the resize >>> behaviour correctly, >>> I'm not sure it can be done without reimplementing a Layout? >>> >>> can you check this? >>> >>> >>> On Tue, Nov 2, 2010 at 22:17, Chris Colbert wrote: >>> >>>> you'll need to setup listeners for the widget's key signals. >>>> >>>> You should read the PyQt docs for how to hook up signals and slots. >>>> >>>> On Tue, Nov 2, 2010 at 5:08 PM, mael wrote: >>>> >>>>> Is anyone comfortable with Qt? >>>>> >>>>> I'm having lot of trouble implementing the interface the way I want. >>>>> Basically, I want something non intrusive, thus the >>>>> GUI will be shown / hidden by pressing F10, but I don't want this to >>>>> change the way the viewer is shown, so here is the thing: >>>>> - first: pressing + zooms x2, I'd like to have ctrl++ zoom x2 and >>>>> also resize the widget x2 (if small enough for the screen), how can I >>>>> do that? >>>>> - second: pressing F10 should keep the viewer as it is, but add some >>>>> widgets beneath it to tweak each parameter, I can't get Qt to behave >>>>> this way? >>>>> >>>>> (last version of scivi2 is in github.com/maelp/scikits.image ) >>>>> >>>>> Thank you >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mael.primet at gmail.com Tue Nov 2 17:20:31 2010 From: mael.primet at gmail.com (=?UTF-8?B?TWHDq2wgUHJpbWV0?=) Date: Tue, 2 Nov 2010 22:20:31 +0100 Subject: denoising algorithms / working with Github In-Reply-To: References: <20100909214336.GB23543@phare.normalesup.org> <20100910125611.GA31060@phare.normalesup.org>

Message-ID: Hum.. I can't get widgets to get the correct size On Tue, Nov 2, 2010 at 22:23, Chris Colbert wrote: > Can you not do this with the Show()/Hide() methods on each widget? > > I know its possible, but I would have to play around with it for a bit. > > > On Tue, Nov 2, 2010 at 5:20 PM, Ma?l Primet wrote: > >> Sorry I wasn't clear, my fault, >> I know how to act on key signal, my problem is getting the resize >> behaviour correctly, >> I'm not sure it can be done without reimplementing a Layout? >> >> can you check this? >> >> >> On Tue, Nov 2, 2010 at 22:17, Chris Colbert wrote: >> >>> you'll need to setup listeners for the widget's key signals. >>> >>> You should read the PyQt docs for how to hook up signals and slots. >>> >>> On Tue, Nov 2, 2010 at 5:08 PM, mael wrote: >>> >>>> Is anyone comfortable with Qt? >>>> >>>> I'm having lot of trouble implementing the interface the way I want. >>>> Basically, I want something non intrusive, thus the >>>> GUI will be shown / hidden by pressing F10, but I don't want this to >>>> change the way the viewer is shown, so here is the thing: >>>> - first: pressing + zooms x2, I'd like to have ctrl++ zoom x2 and >>>> also resize the widget x2 (if small enough for the screen), how can I >>>> do that? >>>> - second: pressing F10 should keep the viewer as it is, but add some >>>> widgets beneath it to tweak each parameter, I can't get Qt to behave >>>> this way? >>>> >>>> (last version of scivi2 is in github.com/maelp/scikits.image ) >>>> >>>> Thank you >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mael.primet at gmail.com Tue Nov 2 17:35:43 2010 From: mael.primet at gmail.com (=?UTF-8?B?TWHDq2wgUHJpbWV0?=) Date: Tue, 2 Nov 2010 22:35:43 +0100 Subject: denoising algorithms / working with Github In-Reply-To: References: <20100909214336.GB23543@phare.normalesup.org> <20100910125611.GA31060@phare.normalesup.org>

Message-ID: I did this but I can' t seem to find the correct settings for the widgets resizing behavior > So yes, you would need to specify some form of layout for the widgets: > Vertical, Horizontal, Grid, etc... and set the appropriate attributes on the > layout and widgets so that they display how you want. > > Alternatively, you could use QtDesigner and pyuic4 to create your layout, > then just wire everything up. (this is how make standalone QT stuff now, > because its just so convenient). > > On Tue, Nov 2, 2010 at 5:24 PM, Ma?l Primet wrote: > >> Hum.. I can't get widgets to get the correct size >> >> >> On Tue, Nov 2, 2010 at 22:23, Chris Colbert wrote: >> >>> Can you not do this with the Show()/Hide() methods on each widget? >>> >>> I know its possible, but I would have to play around with it for a bit. >>> >>> >>> On Tue, Nov 2, 2010 at 5:20 PM, Ma?l Primet wrote: >>> >>>> Sorry I wasn't clear, my fault, >>>> I know how to act on key signal, my problem is getting the resize >>>> behaviour correctly, >>>> I'm not sure it can be done without reimplementing a Layout? >>>> >>>> can you check this? >>>> >>>> >>>> On Tue, Nov 2, 2010 at 22:17, Chris Colbert wrote: >>>> >>>>> you'll need to setup listeners for the widget's key signals. >>>>> >>>>> You should read the PyQt docs for how to hook up signals and slots. >>>>> >>>>> On Tue, Nov 2, 2010 at 5:08 PM, mael wrote: >>>>> >>>>>> Is anyone comfortable with Qt? >>>>>> >>>>>> I'm having lot of trouble implementing the interface the way I want. >>>>>> Basically, I want something non intrusive, thus the >>>>>> GUI will be shown / hidden by pressing F10, but I don't want this to >>>>>> change the way the viewer is shown, so here is the thing: >>>>>> - first: pressing + zooms x2, I'd like to have ctrl++ zoom x2 and >>>>>> also resize the widget x2 (if small enough for the screen), how can I >>>>>> do that? >>>>>> - second: pressing F10 should keep the viewer as it is, but add some >>>>>> widgets beneath it to tweak each parameter, I can't get Qt to behave >>>>>> this way? >>>>>> >>>>>> (last version of scivi2 is in github.com/maelp/scikits.image ) >>>>>> >>>>>> Thank you >>>>> >>>>> >>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sccolbert at gmail.com Fri Nov 5 09:29:29 2010 From: sccolbert at gmail.com (Chris Colbert) Date: Fri, 5 Nov 2010 09:29:29 -0400 Subject: RFR: IO cleanup In-Reply-To: References: Message-ID: Did we decided on a standard for which dtypes we will support? Some of the color conversions can be sped up in Cython with a lut (ala scivi), but we would need to write one func for each dtype. I am working on a webinar for image processing and am getting back into using th scikit, so there are some things I'm seeing during use that I would like to improve, but would require knowledge of what dtypes to support. Chris 2010/11/5 St?fan van der Walt > Hi all, > > At the SciPy sprint (ages ago), Chris suggested that we clean up the > image loading API. The following changes simplify `imread` by > removing the `dtype` argument. This allows for simpler plugins. > Because `as_grey` is such a commonly used parameter, it is left in > place, but now works differently: after the image is loaded, the (new) > rgb2grey is simply performed on it. > > Please have a look at > > https://github.com/stefanv/scikits.image/compare/master...io_cleanup > > Regards > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sccolbert at gmail.com Fri Nov 5 09:30:20 2010 From: sccolbert at gmail.com (Chris Colbert) Date: Fri, 5 Nov 2010 09:30:20 -0400 Subject: RFR: Image-collection reader In-Reply-To: References: Message-ID: Scivi's gonna get a new-and-improved frontend and features when I get some time ;) 2010/11/5 St?fan van der Walt > Please review the proposed plugin hook for an Image Collection reader: > > https://github.com/stefanv/scikits.image/compare/master...imagecollection > > Having a way to easily load and manipulate a whole collection of > images would be great! Think for example, of how easily SciVi could > become a usable image (gallery) viewer. > > Regards > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sccolbert at gmail.com Fri Nov 5 09:31:13 2010 From: sccolbert at gmail.com (Chris Colbert) Date: Fri, 5 Nov 2010 09:31:13 -0400 Subject: OpenCL modules In-Reply-To: References: Message-ID: sounds interesting. On Fri, Nov 5, 2010 at 4:44 AM, Ma?l Primet wrote: > Great idea, although I have never used it > > Hi all, > > > > How do you feel about the inclusion of OpenCL-based algorithms in the > > scikit? Should we perhaps introduce a new module, such as > > scikits.image.gpu, which includes some common image processing > > kernels? > > > > Of course, I have no interest in re-writing PyOpenCL from scratch; > > that would become an optional dependency. > > > > Regards > > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sccolbert at gmail.com Fri Nov 5 09:38:44 2010 From: sccolbert at gmail.com (Chris Colbert) Date: Fri, 5 Nov 2010 09:38:44 -0400 Subject: RFR: IO cleanup In-Reply-To: References: Message-ID: btw, all your changes look good. On Fri, Nov 5, 2010 at 9:29 AM, Chris Colbert wrote: > Did we decided on a standard for which dtypes we will support? > > Some of the color conversions can be sped up in Cython with a lut (ala > scivi), but we would need to write one func for each dtype. > > I am working on a webinar for image processing and am getting back into > using th scikit, so there are some things I'm seeing during use that I would > like to improve, but would require knowledge of what dtypes to support. > > Chris > > 2010/11/5 St?fan van der Walt > > Hi all, >> >> At the SciPy sprint (ages ago), Chris suggested that we clean up the >> image loading API. The following changes simplify `imread` by >> removing the `dtype` argument. This allows for simpler plugins. >> Because `as_grey` is such a commonly used parameter, it is left in >> place, but now works differently: after the image is loaded, the (new) >> rgb2grey is simply performed on it. >> >> Please have a look at >> >> https://github.com/stefanv/scikits.image/compare/master...io_cleanup >> >> Regards >> St?fan >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mael.primet at gmail.com Fri Nov 5 04:44:22 2010 From: mael.primet at gmail.com (=?UTF-8?B?TWHDq2wgUHJpbWV0?=) Date: Fri, 5 Nov 2010 09:44:22 +0100 Subject: OpenCL modules In-Reply-To: References: Message-ID: Great idea, although I have never used it > Hi all, > > How do you feel about the inclusion of OpenCL-based algorithms in the > scikit? Should we perhaps introduce a new module, such as > scikits.image.gpu, which includes some common image processing > kernels? > > Of course, I have no interest in re-writing PyOpenCL from scratch; > that would become an optional dependency. > > Regards > St?fan -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.bergstra at gmail.com Fri Nov 5 10:27:32 2010 From: james.bergstra at gmail.com (James Bergstra) Date: Fri, 5 Nov 2010 10:27:32 -0400 Subject: OpenCL modules In-Reply-To: References:

Message-ID: OpenCL is also a good way to get good CPU performance using multicore chips - check out AMD's stream lib. On Fri, Nov 5, 2010 at 9:31 AM, Chris Colbert wrote: > sounds interesting. > > > On Fri, Nov 5, 2010 at 4:44 AM, Ma?l Primet wrote: > >> Great idea, although I have never used it >> > Hi all, >> > >> > How do you feel about the inclusion of OpenCL-based algorithms in the >> > scikit? Should we perhaps introduce a new module, such as >> > scikits.image.gpu, which includes some common image processing >> > kernels? >> > >> > Of course, I have no interest in re-writing PyOpenCL from scratch; >> > that would become an optional dependency. >> > >> > Regards >> > St?fan >> > > -- http://www-etud.iro.umontreal.ca/~bergstrj -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Fri Nov 5 04:41:54 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 5 Nov 2010 10:41:54 +0200 Subject: OpenCL modules Message-ID: Hi all, How do you feel about the inclusion of OpenCL-based algorithms in the scikit? Should we perhaps introduce a new module, such as scikits.image.gpu, which includes some common image processing kernels? Of course, I have no interest in re-writing PyOpenCL from scratch; that would become an optional dependency. Regards St?fan From stefan at sun.ac.za Fri Nov 5 05:57:46 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 5 Nov 2010 11:57:46 +0200 Subject: RFR: Image-collection reader Message-ID: Please review the proposed plugin hook for an Image Collection reader: https://github.com/stefanv/scikits.image/compare/master...imagecollection Having a way to easily load and manipulate a whole collection of images would be great! Think for example, of how easily SciVi could become a usable image (gallery) viewer. Regards St?fan From jturner at gemini.edu Fri Nov 5 11:47:16 2010 From: jturner at gemini.edu (James Turner) Date: Fri, 5 Nov 2010 12:47:16 -0300 Subject: RFR: Image-collection reader In-Reply-To: References: Message-ID: <4CD42704.8050106@gemini.edu> Hi St??????fan, I'm a bit confused about this being "proposed", since we were using it at the SciPy sprints(?). Not that me being confused matters a lot when I haven't been active on the project since, but just curious :-). Thanks! James. PS. I notice you haven't pulled in my FITS plugin yet. Were you still waiting on me doing something (I believe I replied to a message asking about merging it a while ago, but maybe something is still missing)? > Please review the proposed plugin hook for an Image Collection reader: > > https://github.com/stefanv/scikits.image/compare/master...imagecollection > > Having a way to easily load and manipulate a whole collection of > images would be great! Think for example, of how easily SciVi could > become a usable image (gallery) viewer. > > Regards > St??????fan From sccolbert at gmail.com Fri Nov 5 13:32:48 2010 From: sccolbert at gmail.com (Chris Colbert) Date: Fri, 5 Nov 2010 13:32:48 -0400 Subject: RFR: IO cleanup In-Reply-To: References: Message-ID: I think we should be aiming for as little C-code as possible in preference for Cython, escpecially when you start talking about raising exceptions. By using Cython, all of those questions you have are solved. On Fri, Nov 5, 2010 at 1:27 PM, Ma?l Primet wrote: > Yes, and also it would be good if we'd specify clearly > the correct way to treat image arrays: > eg. how to load properly an array in the good type? > should the algorithms automatically convert an array to the algorithm's > required type, or should the algorithm fail if the data is not of the > correct type (some algorithms have no reason to be run on integers / or real > -valued data, for instance). > there should be an utility function that do the transfer with as little > copying as possible, yet it should be possible to force copy when the > algorithms request it > how do we transfer the arrays to C code ? should we transfer the array > directly ? only the memory pointer and the size as is done now ? (but then > we cannot call python code from C code, to do for instance an FFT ) How do > we ensure the array is contiguous with as few copies as necessary ? How do > we force a copy to be contiguous ? etc > > and also: what is the proper way to raise an exception from C code, etc. > > if you have any idea, > it'd be welcome! > > > On Fri, Nov 5, 2010 at 14:38, Chris Colbert wrote: > >> btw, all your changes look good. >> >> >> On Fri, Nov 5, 2010 at 9:29 AM, Chris Colbert wrote: >> >>> Did we decided on a standard for which dtypes we will support? >>> >>> Some of the color conversions can be sped up in Cython with a lut (ala >>> scivi), but we would need to write one func for each dtype. >>> >>> I am working on a webinar for image processing and am getting back into >>> using th scikit, so there are some things I'm seeing during use that I would >>> like to improve, but would require knowledge of what dtypes to support. >>> >>> Chris >>> >>> 2010/11/5 St?fan van der Walt >>> >>> Hi all, >>>> >>>> At the SciPy sprint (ages ago), Chris suggested that we clean up the >>>> image loading API. The following changes simplify `imread` by >>>> removing the `dtype` argument. This allows for simpler plugins. >>>> Because `as_grey` is such a commonly used parameter, it is left in >>>> place, but now works differently: after the image is loaded, the (new) >>>> rgb2grey is simply performed on it. >>>> >>>> Please have a look at >>>> >>>> https://github.com/stefanv/scikits.image/compare/master...io_cleanup >>>> >>>> Regards >>>> St?fan >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sccolbert at gmail.com Fri Nov 5 13:33:17 2010 From: sccolbert at gmail.com (Chris Colbert) Date: Fri, 5 Nov 2010 13:33:17 -0400 Subject: RFR: IO cleanup In-Reply-To: References: Message-ID: In fact mael, I plan on coverting most of your C code to Cython before pushing it. On Fri, Nov 5, 2010 at 1:32 PM, Chris Colbert wrote: > I think we should be aiming for as little C-code as possible in preference > for Cython, escpecially when you start talking about raising exceptions. By > using Cython, all of those questions you have are solved. > > > On Fri, Nov 5, 2010 at 1:27 PM, Ma?l Primet wrote: > >> Yes, and also it would be good if we'd specify clearly >> the correct way to treat image arrays: >> eg. how to load properly an array in the good type? >> should the algorithms automatically convert an array to the algorithm's >> required type, or should the algorithm fail if the data is not of the >> correct type (some algorithms have no reason to be run on integers / or real >> -valued data, for instance). >> there should be an utility function that do the transfer with as little >> copying as possible, yet it should be possible to force copy when the >> algorithms request it >> how do we transfer the arrays to C code ? should we transfer the array >> directly ? only the memory pointer and the size as is done now ? (but then >> we cannot call python code from C code, to do for instance an FFT ) How do >> we ensure the array is contiguous with as few copies as necessary ? How do >> we force a copy to be contiguous ? etc >> >> and also: what is the proper way to raise an exception from C code, >> etc. >> >> if you have any idea, >> it'd be welcome! >> >> >> On Fri, Nov 5, 2010 at 14:38, Chris Colbert wrote: >> >>> btw, all your changes look good. >>> >>> >>> On Fri, Nov 5, 2010 at 9:29 AM, Chris Colbert wrote: >>> >>>> Did we decided on a standard for which dtypes we will support? >>>> >>>> Some of the color conversions can be sped up in Cython with a lut (ala >>>> scivi), but we would need to write one func for each dtype. >>>> >>>> I am working on a webinar for image processing and am getting back into >>>> using th scikit, so there are some things I'm seeing during use that I would >>>> like to improve, but would require knowledge of what dtypes to support. >>>> >>>> Chris >>>> >>>> 2010/11/5 St?fan van der Walt >>>> >>>> Hi all, >>>>> >>>>> At the SciPy sprint (ages ago), Chris suggested that we clean up the >>>>> image loading API. The following changes simplify `imread` by >>>>> removing the `dtype` argument. This allows for simpler plugins. >>>>> Because `as_grey` is such a commonly used parameter, it is left in >>>>> place, but now works differently: after the image is loaded, the (new) >>>>> rgb2grey is simply performed on it. >>>>> >>>>> Please have a look at >>>>> >>>>> https://github.com/stefanv/scikits.image/compare/master...io_cleanup >>>>> >>>>> Regards >>>>> St?fan >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sccolbert at gmail.com Fri Nov 5 14:28:57 2010 From: sccolbert at gmail.com (Chris Colbert) Date: Fri, 5 Nov 2010 14:28:57 -0400 Subject: RFR: IO cleanup In-Reply-To: References: Message-ID: see inline comments: On Fri, Nov 5, 2010 at 2:02 PM, Ma?l Primet wrote: > Well, > > perhaps we should talk about this a little more, because there are many > aspects: > - of course, Cython has a more clean feeling > - however, it is still not as efficient as C (for some of the code I > published, I tried the Cython version first, then switched to C when I saw > that it was too slow) > I suspect this has more to do with how you've written the Cython versus the speed of Cython vs C. Cython is *very* fast when properly used. > - some older user of the library, less able with python, might still want to > develop C code and bind it if there is an easy way to do it > Since our data structure is a numpy array, manipulating that pointer in C would take an awful lot of knowledge about NumPy internals. Raising an exception even moreso. It would be less effort for said person to just learn Cython. > - it is interesting to have some simple C core code, like a function that > takes arrays as double * and (w, h) integers, because it enables easy reuse > of the core of the algorithm for some other projects (without having to > include the whole library) if someone only wants to extract one or two > algorithm (this might be interesting when we develop research code and some > private company want to use the algorithm ) > > There is nothing stopping you from doing that in your own personal library. But seeing as how we creating a library for image processing in Python, I think we should use the best available tools for Python, thus making things most accessible and maintainable to our target audience. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sccolbert at gmail.com Fri Nov 5 14:48:46 2010 From: sccolbert at gmail.com (Chris Colbert) Date: Fri, 5 Nov 2010 14:48:46 -0400 Subject: RFR: IO cleanup In-Reply-To: References:

Message-ID: On Fri, Nov 5, 2010 at 2:37 PM, Ma?l Primet wrote: > I fully understand this, and am willing to try developing cython code, but > keep in mind that the real goal is more to have a widely used library than > the most pythonic one (eg the most important thing is the community of > users) and *having talked to several researchers, they do like C.* > That's cause they haven't learned the power of the Python/Cython combo yet ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Fri Nov 5 09:10:54 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Fri, 5 Nov 2010 15:10:54 +0200 Subject: RFR: IO cleanup Message-ID: Hi all, At the SciPy sprint (ages ago), Chris suggested that we clean up the image loading API. The following changes simplify `imread` by removing the `dtype` argument. This allows for simpler plugins. Because `as_grey` is such a commonly used parameter, it is left in place, but now works differently: after the image is loaded, the (new) rgb2grey is simply performed on it. Please have a look at https://github.com/stefanv/scikits.image/compare/master...io_cleanup Regards St?fan From mael.primet at gmail.com Fri Nov 5 13:19:10 2010 From: mael.primet at gmail.com (=?UTF-8?B?TWHDq2wgUHJpbWV0?=) Date: Fri, 5 Nov 2010 18:19:10 +0100 Subject: RFR: Image-collection reader In-Reply-To: References:

Message-ID: This is a good idea, and image sequences will definitely be useful for movies. However, I'm not sure that scivi should be a gwenview-like "gallery" image viewer, but rather a scientific visualization toolkit.. I'd definitely want movie sequences to be handled (as a sequence of image files, not necessarily .avi, but we could have script to convert from/to ), but I don't really see how the "gallery of images" feature might be useful? On the contrary, something that might be useful is this: often when doing experiments, you try lots of parameters on the same image, and you have a metric for the result. Say for instance, that you have 2 parameters taking values in [0,1]? and you have a metric taking values in [0,1], then you could sample points in the grid, use your algorithm with the sampled parameters, and show the grid as dots (position: parameters, color/size is metric) and when clicking on the dot, it might show the corresponding filtered image. This might prove nice for algorithm exploration -------------- next part -------------- An HTML attachment was scrubbed... URL: From mael.primet at gmail.com Fri Nov 5 13:27:28 2010 From: mael.primet at gmail.com (=?UTF-8?B?TWHDq2wgUHJpbWV0?=) Date: Fri, 5 Nov 2010 18:27:28 +0100 Subject: RFR: IO cleanup In-Reply-To: References: Message-ID: Yes, and also it would be good if we'd specify clearly the correct way to treat image arrays: eg. how to load properly an array in the good type? should the algorithms automatically convert an array to the algorithm's required type, or should the algorithm fail if the data is not of the correct type (some algorithms have no reason to be run on integers / or real -valued data, for instance). there should be an utility function that do the transfer with as little copying as possible, yet it should be possible to force copy when the algorithms request it how do we transfer the arrays to C code ? should we transfer the array directly ? only the memory pointer and the size as is done now ? (but then we cannot call python code from C code, to do for instance an FFT ) How do we ensure the array is contiguous with as few copies as necessary ? How do we force a copy to be contiguous ? etc and also: what is the proper way to raise an exception from C code, etc. if you have any idea, it'd be welcome! On Fri, Nov 5, 2010 at 14:38, Chris Colbert wrote: > btw, all your changes look good. > > > On Fri, Nov 5, 2010 at 9:29 AM, Chris Colbert wrote: > >> Did we decided on a standard for which dtypes we will support? >> >> Some of the color conversions can be sped up in Cython with a lut (ala >> scivi), but we would need to write one func for each dtype. >> >> I am working on a webinar for image processing and am getting back into >> using th scikit, so there are some things I'm seeing during use that I would >> like to improve, but would require knowledge of what dtypes to support. >> >> Chris >> >> 2010/11/5 St?fan van der Walt >> >> Hi all, >>> >>> At the SciPy sprint (ages ago), Chris suggested that we clean up the >>> image loading API. The following changes simplify `imread` by >>> removing the `dtype` argument. This allows for simpler plugins. >>> Because `as_grey` is such a commonly used parameter, it is left in >>> place, but now works differently: after the image is loaded, the (new) >>> rgb2grey is simply performed on it. >>> >>> Please have a look at >>> >>> https://github.com/stefanv/scikits.image/compare/master...io_cleanup >>> >>> Regards >>> St?fan >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mael.primet at gmail.com Fri Nov 5 14:02:46 2010 From: mael.primet at gmail.com (=?UTF-8?B?TWHDq2wgUHJpbWV0?=) Date: Fri, 5 Nov 2010 19:02:46 +0100 Subject: RFR: IO cleanup In-Reply-To: References: Message-ID: Well, perhaps we should talk about this a little more, because there are many aspects: - of course, Cython has a more clean feeling - however, it is still not as efficient as C (for some of the code I published, I tried the Cython version first, then switched to C when I saw that it was too slow) - some older user of the library, less able with python, might still want to develop C code and bind it if there is an easy way to do it - it is interesting to have some simple C core code, like a function that takes arrays as double * and (w, h) integers, because it enables easy reuse of the core of the algorithm for some other projects (without having to include the whole library) if someone only wants to extract one or two algorithm (this might be interesting when we develop research code and some private company want to use the algorithm ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mael.primet at gmail.com Fri Nov 5 14:37:44 2010 From: mael.primet at gmail.com (=?UTF-8?B?TWHDq2wgUHJpbWV0?=) Date: Fri, 5 Nov 2010 19:37:44 +0100 Subject: RFR: IO cleanup In-Reply-To: References:

Message-ID: I fully understand this, and am willing to try developing cython code, but keep in mind that the real goal is more to have a widely used library than the most pythonic one (eg the most important thing is the community of users) and having talked to several researchers, they do like C. > see inline comments: > > On Fri, Nov 5, 2010 at 2:02 PM, Ma?l Primet wrote: > >> Well, >> >> perhaps we should talk about this a little more, because there are many >> aspects: >> - of course, Cython has a more clean feeling >> - however, it is still not as efficient as C (for some of the code I >> published, I tried the Cython version first, then switched to C when I saw >> that it was too slow) >> > > I suspect this has more to do with how you've written the Cython versus the > speed of Cython vs C. Cython is *very* fast when properly used. > > >> > - some older user of the library, less able with python, might still want to >> develop C code and bind it if there is an easy way to do it >> > > Since our data structure is a numpy array, manipulating that pointer in C > would take an awful lot of knowledge about NumPy internals. Raising an > exception even moreso. It would be less effort for said person to just learn > Cython. > > >> - it is interesting to have some simple C core code, like a function that >> takes arrays as double * and (w, h) integers, because it enables easy reuse >> of the core of the algorithm for some other projects (without having to >> include the whole library) if someone only wants to extract one or two >> algorithm (this might be interesting when we develop research code and some >> private company want to use the algorithm ) >> >> > There is nothing stopping you from doing that in your own personal library. > But seeing as how we creating a library for image processing in Python, I > think we should use the best available tools for Python, thus making things > most accessible and maintainable to our target audience. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at googlemail.com Fri Nov 5 21:48:37 2010 From: ralf.gommers at googlemail.com (Ralf Gommers) Date: Sat, 6 Nov 2010 09:48:37 +0800 Subject: RFR: Image-collection reader In-Reply-To: References: Message-ID: 2010/11/5 St?fan van der Walt : > Please review the proposed plugin hook for an Image Collection reader: > Can you explain why you set up the tests like that? It seems the test is split over two files, with this change: +def imread_collection(x, conserve_memory=True): + assert conserve_memory == False + assert x == '*.png' relying on a call from another file with the expected arguments. This will be confusing I think. The rest looks good to me. Cheers, Ralf From sccolbert at gmail.com Sat Nov 6 21:14:10 2010 From: sccolbert at gmail.com (Chris Colbert) Date: Sat, 6 Nov 2010 21:14:10 -0400 Subject: RFR: IO cleanup In-Reply-To: References:

Message-ID: i think we should definitely add uint8 support for algorithms. I think float64, int16, and uint8 versions of each algorithm would be a good compromise. 2010/11/6 St?fan van der Walt > On Fri, Nov 5, 2010 at 3:29 PM, Chris Colbert wrote: > > Did we decided on a standard for which dtypes we will support? > > IIRC, we said we'd write utility functions to convert from whatever > input is received to either float64 or int16 types and go from there. > The output type is whatever is most convenient for the algorithm, and > should be well documented. > > Can you recall the different approaches discussed at the sprint? > > Cheers > St?fan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan at sun.ac.za Sat Nov 6 18:02:29 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 7 Nov 2010 00:02:29 +0200 Subject: RFR: Image-collection reader In-Reply-To: <4CD42704.8050106@gemini.edu> References: <4CD42704.8050106@gemini.edu> Message-ID: Hi James On Fri, Nov 5, 2010 at 5:47 PM, James Turner wrote: > I'm a bit confused about this being "proposed", since we were using > it at the SciPy sprints(?). Not that me being confused matters a lot > when I haven't been active on the project since, but just curious :-). Your confusion is fully warranted :) Like you mentioned, I haven't merged your FITS plugin yet, and this is a building block in that direction. I'm just making sure everyone is happy with the proposed changes--also those who weren't at the sprint. Sorry for the long day; I'm playing catch-up now! Cheers St?fan From stefan at sun.ac.za Sat Nov 6 18:04:03 2010 From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=) Date: Sun, 7 Nov 2010 00:04:03 +0200 Subject: RFR: Image-collection reader In-Reply-To: References: Message-ID: Hi Ralph On Sat, Nov 6, 2010 at 3:48 AM, Ralf Gommers