Re: contributing C/Cython code to the scikit
Hi Mael On Tue, Sep 21, 2010 at 11:10 AM, mael <mael.primet@gmail.com> wrote:
I will try to gradually improve my python code style, have you specifics you have seen in my code that were out of the way?
I think mostly spacing issues; but those are well described in the PEP.
I removed opencv on my laptop because this wouldn't build (I'll try to figure out why)
No problem; just make sure that those changes don't get committed to your repo!
for the data types, the discussion is very interesting, most of the algorithms could be adapted for different data-types by some preprocessor-like translation, however, this might create some problems (floating point comparison etc). Plus, our feeling with the previous library we were using (Megawave) was that it was better not to provide an algorithm for each and every possible datatype, as it forced the end-user to ponder whether the algorithm he was trying to use was suited to his case etc. But I concur that writing float (possibly float and doubles) and integer (int and unsigned char?) arrays should be made as easy as possible.
Our thought was that two types may be manageable, but while we could always generalise to support more types, it's very hard to go back -- so I'm happy that we're taking a conservative approach here.
btw we're also interested in coding some powerful visualization function. I guess we'd rather not clutter the scikit with dependencies to pyQt or other libraries. How would you go about doing something like this? Use some library like chaco? Write from scratch a PyQt viewer?
You'll be glad to discover that we already have a Qt visualisation plugin! Different "imshow" implementations are available, depending on what is available on your system. Try this: import scikits.image.io as sio print sio.plugins() sio.use_plugin('qt') imshow(...) It should pop up a qt viewer. You may also do imshow(..., fancy=True) for a display with tuning widgets (only supported on Qt currently).
I'm not really that good a coder, so I'd be happy to have you guys refactor some of my code and tell me the best way to go about it, particularly to avoid copying arrays over and over. We want to have simple contiguous arrays though, because we don't want to bother with complex array iteration in our C code.
You'll probably find that, especially for large images, it is often quicker to do a single copy (to get contiguous data) and then perform your operation. Good coding comes with practise, and we're all still learning, so you're in good company.
Is the way I'm doing it (that was given to us by Emmanuelle) the proper way of getting our arrays as contiguous C arrays or are there some more efficient and/or elegant way to do this?
The clearest way is probably `numpy.ascontiguousarray`. Regards Stéfan
Hi Ma�l,
On Tue, Sep 21, 2010 at 11:10 AM, mael <mael.primet@gmail.com> wrote:
I will try to gradually improve my python code style, have you specifics you have seen in my code that were out of the way?
I think mostly spacing issues; but those are well described in the PEP.
I'm working on your code right now, so if you're making changes... to your changes, try to fetch first from my repository. Cheers, Emmanuelle
Just a git/github question for the future: when Mael has a set of files that are polished enough for a pull request, will it be better to start a new branch that is a clone of Stefan's main branch, and add these new files to the new branch, for a cleaner commit tree? How do you proceed usually? Cheers, Emmanuelle
Hi Emmanuelle On Tue, Sep 21, 2010 at 9:30 PM, Emmanuelle Gouillart <emmanuelle.gouillart@normalesup.org> wrote:
Just a git/github question for the future: when Mael has a set of files that are polished enough for a pull request, will it be better to start a new branch that is a clone of Stefan's main branch, and add these new files to the new branch, for a cleaner commit tree? How do you proceed usually?
I think there is a lot to be said for a clean commit, especially if you can avoid large binary files (like the Lena he checked in). So, yes, I'd create a new branch, cherry pick, merge, rebase, go crazy until the thing looks good, and then do a pull request. Hope that's what you were asking :) Cheers Stéfan
Hello everyone, Stéfan: actually I saw the data images, but the Lena's in it are too small to be of use on image processing algorithms :) But Emmanuelles scipy.lena trick will do the work. Chris: this is actually an interesting discussion to have, there are pros and cons about doing again what is done by scipy. First, although scipy's version is more elaborate and potentially more optimised, it is also more obfuscated, and thus more difficult to understand. This may not be a problem for "end-users", but this could become problematic when you are a researcher writing a paper and having to be certain about everything you do. Moreover we would like the library to have a triple goal: be used by "end-users" (people needing basic image processing algos ), be used by students (and therefore have clear and accessible algorithms, not something like scipy.ndimage complex C code), and be used by researchers (thus be easy to extend and fiddle with, and have a complete control over the algorithms). This is why we feel that in some case, recoding the algorithms in a simple way could be interesting. Of course, we won't reimplement the FFT or linear algebra algorithms.. This could be nice to discuss those points before we add too much code (but let's be clear: most of the algos we want to add cannot be found in scipy. Actually, the only ones would be median and morphology, which you already implement)
I think there is a lot to be said for a clean commit, especially if you can avoid large binary files (like the Lena he checked in).
So, yes, I'd create a new branch, cherry pick, merge, rebase, go crazy until the thing looks good, and then do a pull request.
Hope that's what you were asking :)
Basically, yes :-). I think it will take me a lot of time before I really understand how to use git, which always seem to be more clever than I am, but I also think it's really worth learning. The page http://stefanv.github.com/scikits.image/gitwash/development_workflow.html is really good, I wish I had read it earlier. Then I would not have pushed work-in-progress commits to my master branch on github, now I have to find a way to clean all this mess. But that's how you learn, don't you :-D ? Cheers, Emmanuelle
On Wed, Sep 22, 2010 at 7:24 PM, Emmanuelle Gouillart <emmanuelle.gouillart@normalesup.org> wrote:
Basically, yes :-). I think it will take me a lot of time before I really understand how to use git, which always seem to be more clever than I am, but I also think it's really worth learning. The page http://stefanv.github.com/scikits.image/gitwash/development_workflow.html is really good, I wish I had read it earlier.
Kudos to Matthew Brett for the gitwash project! (http://github.com/matthew-brett/gitwash) And don't feel bad about git; I managed to make it segfault today (!). Cheers Stéfan
Hello, I had lots of things to do lately, haven't had much time to work on the library, but I'll do it quickly, here are the new things: http://github.com/maelp/scikits.image (some new filters, and some nice zooms) here are other projects that I work on in parallel, and I'd be happy to have some contribution: - image viewer: this should become the image viewer of scikits.image in our opinion (although it is not yet complete). Basically, it is a modulable efficient viewer, that handles zoom properly, displays level lines, etc and should be easily extensible. This is only a stub yet, and I'd be happy to merge it with your viewer, in particular have the threaded computations to have faster computations, and add the histrograms, normalization, etc. It can show grey and color int / float images, and should be pretty fast even for large images since it only computes the strictly required part that is needed to be viewed, and has a cache to speed-up the next recomputations (if you move the view a little, most of the rendered image does not change, and it only recomputes what needs be ) - tutorial: http://github.com/maelp/tutorial This should become a standard way to describe scikits.image algorithms in a dynamic way (this is basically the Qt Webkit that has been extended to include scikits.image algorithm) This could be a good advantage of the library: it is often difficult to find interactive use-case for algorithms, etc, and many times, old algorithms aren't properly documented, or we don't know in which case they do and don't apply. If we have a standard "documentation" in interactive format (where people can try our algorithms, have a mathematical presentation, upload their images etc) this will help keep up with a large image library. I made it such that it is visually attractive because I'm pretty sure this is extremely important (have beautiful documentation ) I will add new filters to the library soon, please give some inputs on the new projects and feel free to extend and/or modify anything I haven't had time to properly document everything yet, I'll do that soon
Of course the viewer is stored here http://github.com/maelp/viewer On Oct 27, 10:43 pm, mael <mael.pri...@gmail.com> wrote:
Hello,
I had lots of things to do lately, haven't had much time to work on the library, but I'll do it quickly,
here are the new things:http://github.com/maelp/scikits.image (some new filters, and some nice zooms)
here are other projects that I work on in parallel, and I'd be happy to have some contribution: - image viewer: this should become the image viewer of scikits.image in our opinion (although it is not yet complete). Basically, it is a modulable efficient viewer, that handles zoom properly, displays level lines, etc and should be easily extensible. This is only a stub yet, and I'd be happy to merge it with your viewer, in particular have the threaded computations to have faster computations, and add the histrograms, normalization, etc. It can show grey and color int / float images, and should be pretty fast even for large images since it only computes the strictly required part that is needed to be viewed, and has a cache to speed-up the next recomputations (if you move the view a little, most of the rendered image does not change, and it only recomputes what needs be )
- tutorial:http://github.com/maelp/tutorial This should become a standard way to describe scikits.image algorithms in a dynamic way (this is basically the Qt Webkit that has been extended to include scikits.image algorithm) This could be a good advantage of the library: it is often difficult to find interactive use-case for algorithms, etc, and many times, old algorithms aren't properly documented, or we don't know in which case they do and don't apply. If we have a standard "documentation" in interactive format (where people can try our algorithms, have a mathematical presentation, upload their images etc) this will help keep up with a large image library. I made it such that it is visually attractive because I'm pretty sure this is extremely important (have beautiful documentation )
I will add new filters to the library soon, please give some inputs on the new projects and feel free to extend and/or modify anything
I haven't had time to properly document everything yet, I'll do that soon
these look really promising at first glance. I wrote Scivi in a weekend then basically never touched it again. I've been wanting to make it proper. So I will definitely take a look at your view and incorporate some of Scivi's threaded utilities. Cheers, Chris On Wed, Oct 27, 2010 at 4:44 PM, mael <mael.primet@gmail.com> wrote:
Of course the viewer is stored here http://github.com/maelp/viewer
On Oct 27, 10:43 pm, mael <mael.pri...@gmail.com> wrote:
Hello,
I had lots of things to do lately, haven't had much time to work on the library, but I'll do it quickly,
here are the new things:http://github.com/maelp/scikits.image (some new filters, and some nice zooms)
here are other projects that I work on in parallel, and I'd be happy to have some contribution: - image viewer: this should become the image viewer of scikits.image in our opinion (although it is not yet complete). Basically, it is a modulable efficient viewer, that handles zoom properly, displays level lines, etc and should be easily extensible. This is only a stub yet, and I'd be happy to merge it with your viewer, in particular have the threaded computations to have faster computations, and add the histrograms, normalization, etc. It can show grey and color int / float images, and should be pretty fast even for large images since it only computes the strictly required part that is needed to be viewed, and has a cache to speed-up the next recomputations (if you move the view a little, most of the rendered image does not change, and it only recomputes what needs be )
- tutorial:http://github.com/maelp/tutorial This should become a standard way to describe scikits.image algorithms in a dynamic way (this is basically the Qt Webkit that has been extended to include scikits.image algorithm) This could be a good advantage of the library: it is often difficult to find interactive use-case for algorithms, etc, and many times, old algorithms aren't properly documented, or we don't know in which case they do and don't apply. If we have a standard "documentation" in interactive format (where people can try our algorithms, have a mathematical presentation, upload their images etc) this will help keep up with a large image library. I made it such that it is visually attractive because I'm pretty sure this is extremely important (have beautiful documentation )
I will add new filters to the library soon, please give some inputs on the new projects and feel free to extend and/or modify anything
I haven't had time to properly document everything yet, I'll do that soon
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 ?
how are you running it when the windows don't stay open? On Mon, Nov 1, 2010 at 10:40 AM, mael <mael.primet@gmail.com> 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 ?
I do io.use_plugin('qt2') io.imshow(im) and it opens and close On Mon, Nov 1, 2010 at 16:01, Chris Colbert <sccolbert@gmail.com> wrote:
how are you running it when the windows don't stay open?
On Mon, Nov 1, 2010 at 10:40 AM, mael <mael.primet@gmail.com> 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 ?
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 <mael.primet@gmail.com> 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 <sccolbert@gmail.com> wrote:
how are you running it when the windows don't stay open?
On Mon, Nov 1, 2010 at 10:40 AM, mael <mael.primet@gmail.com> 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 ?
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 <sccolbert@gmail.com> 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 <mael.primet@gmail.com>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 <sccolbert@gmail.com> wrote:
how are you running it when the windows don't stay open?
On Mon, Nov 1, 2010 at 10:40 AM, mael <mael.primet@gmail.com> 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 ?
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 <mael.primet@gmail.com> 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 <sccolbert@gmail.com> 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 <mael.primet@gmail.com>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 <sccolbert@gmail.com> wrote:
how are you running it when the windows don't stay open?
On Mon, Nov 1, 2010 at 10:40 AM, mael <mael.primet@gmail.com> 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 ?
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 <sccolbert@gmail.com> 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 <mael.primet@gmail.com>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 <sccolbert@gmail.com> 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 <mael.primet@gmail.com>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 <sccolbert@gmail.com>wrote:
how are you running it when the windows don't stay open?
On Mon, Nov 1, 2010 at 10:40 AM, mael <mael.primet@gmail.com> 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 ?
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 <mael.primet@gmail.com> 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 <sccolbert@gmail.com> 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 <mael.primet@gmail.com>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 <sccolbert@gmail.com> 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 <mael.primet@gmail.com>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 <sccolbert@gmail.com>wrote:
how are you running it when the windows don't stay open?
On Mon, Nov 1, 2010 at 10:40 AM, mael <mael.primet@gmail.com> 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 ?
I'm correcting some bugs on the github (although there still are some), and added some new filters there is however something slightly problematic: when using Cython to bind C code, CTRL+C does not work to shut the process, and this might get annoying when developping programs that might still contain some bugs Maël
On Mon, Nov 1, 2010 at 10:12 PM, mael <mael.primet@gmail.com> wrote:
there is however something slightly problematic: when using Cython to bind C code, CTRL+C does not work to shut the process, and this might get annoying when developping programs that might still contain some bugs
If you are not accessing Python objects, you may use with nogil: code snippet here To release the GIL and allow Ctrl-C. Cheers Stéfan
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
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 <mael.primet@gmail.com> 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
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 <sccolbert@gmail.com> 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 <mael.primet@gmail.com> 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
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 <mael.primet@gmail.com> 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 <sccolbert@gmail.com> 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 <mael.primet@gmail.com> 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
Hum.. I can't get widgets to get the correct size On Tue, Nov 2, 2010 at 22:23, Chris Colbert <sccolbert@gmail.com> 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 <mael.primet@gmail.com> 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 <sccolbert@gmail.com> 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 <mael.primet@gmail.com> 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
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 <mael.primet@gmail.com> wrote:
Hum.. I can't get widgets to get the correct size
On Tue, Nov 2, 2010 at 22:23, Chris Colbert <sccolbert@gmail.com> 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 <mael.primet@gmail.com>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 <sccolbert@gmail.com> 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 <mael.primet@gmail.com> 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
So yes, you would need to specify some form of layout for the widgets: Vertical, Horizontal, Grid, etc... and set the appropriate attributes on
I did this but I can' t seem to find the correct settings for the widgets resizing behavior 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 <mael.primet@gmail.com> wrote:
Hum.. I can't get widgets to get the correct size
On Tue, Nov 2, 2010 at 22:23, Chris Colbert <sccolbert@gmail.com> 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 <mael.primet@gmail.com 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 <sccolbert@gmail.com> 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 <mael.primet@gmail.com> 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
Hi Mael On Wed, Oct 27, 2010 at 10:43 PM, mael <mael.primet@gmail.com> wrote:
here are the new things: http://github.com/maelp/scikits.image (some new filters, and some nice zooms)
That looks really interesting. How does the zooming algorithm differ from, for example, transform.homography? That one is based on scipy.ndimage's map_coordinates.
- tutorial: http://github.com/maelp/tutorial
I love this idea! I couldn't get this to work on my system, but maybe I'll check it out again when you've got a README of some sorts.
I made it such that it is visually attractive because I'm pretty sure this is extremely important (have beautiful documentation )
Definitely. Cheers Stéfan
Interesting, I didn't know about those functions. From what I see from the description, I'd say that my zoom has more interpolation choices (constant, bilinear, bicubic and spline 3-11) and should be more efficient, which might be critical for visualization purposes (we don't have to create the intermediate coordinates array) Could you tell me the problem with the tutorial? Have you tried running ipaper? (And you should probably install mathjax too) Is the viewer working properly?
Hi Mael
On Wed, Oct 27, 2010 at 10:43 PM, mael <mael.primet@gmail.com> wrote:
here are the new things: http://github.com/maelp/scikits.image (some new filters, and some nice zooms)
That looks really interesting. How does the zooming algorithm differ from, for example, transform.homography? That one is based on scipy.ndimage's map_coordinates.
- tutorial: http://github.com/maelp/tutorial
I love this idea! I couldn't get this to work on my system, but maybe I'll check it out again when you've got a README of some sorts.
I made it such that it is visually attractive because I'm pretty sure this is extremely important (have beautiful documentation )
Definitely.
Cheers Stéfan
Hi Maël On Thu, Oct 28, 2010 at 10:57 AM, Maël Primet <mael.primet@gmail.com> wrote:
Interesting, I didn't know about those functions. From what I see from the description, I'd say that my zoom has more interpolation choices (constant, bilinear, bicubic and spline 3-11) and should be more efficient, which might be critical for visualization purposes (we don't have to create the intermediate coordinates array)
It may be worth benchmarking the two. Ndimage has order 0, 1, 2 and 3 interpolation. Maintaining accurate spline interpolation routines is a sensitive task, so if we go that route we need to document everything carefully and add the necessary references. Ndimage has a big maintenance problem with spline interp.
Could you tell me the problem with the tutorial? Have you tried running ipaper? (And you should probably install mathjax too)
I did, but it required some other packages I didn't have. What is the exact procedure for generating and viewing the paper? Cheers Stéfan
Hi Maël
On Thu, Oct 28, 2010 at 10:57 AM, Maël Primet <mael.primet@gmail.com> wrote:
Interesting, I didn't know about those functions. From what I see from
I'll try it, but adding more interpolation algorithms also means complexifying the ndimage api and that making changes to the interpolation algorithms will require changing ndimage (this might be problematic, because users will have to keep up to date with both librairies) the
description, I'd say that my zoom has more interpolation choices (constant, bilinear, bicubic and spline 3-11) and should be more efficient, which might be critical for visualization purposes (we don't have to create the intermediate coordinates array)
It may be worth benchmarking the two. Ndimage has order 0, 1, 2 and 3 interpolation. Maintaining accurate spline interpolation routines is a sensitive task, so if we go that route we need to document everything carefully and add the necessary references. Ndimage has a big maintenance problem with spline interp.
Could you tell me the problem with the tutorial? Have you tried running ipaper? (And you should probably install mathjax too)
I did, but it required some other packages I didn't have. What is the exact procedure for generating and viewing the paper?
Cheers Stéfan
On Thu, Oct 28, 2010 at 1:47 PM, Maël Primet <mael.primet@gmail.com> wrote:
I'll try it, but adding more interpolation algorithms also means complexifying the ndimage api and that making changes to the interpolation algorithms will require changing ndimage (this might be problematic, because users will have to keep up to date with both librairies)
I thought order 0, 1, 2 and 3 in ndimage corresponded to your routines? I could be mistaken! Regards Stéfan
Hi Mael, thanks for all these contributions! I had a look at the new filters. I added some documentation to the existing docstrings (http://github.com/emmanuelle/scikits.image/commits/denoise), could you please check that I didn't write anything wrong? I'm planning to add tests for these denoising functions in the next few days. After the code is fully tested, I think it will be time to start to start a new branch, cherry-pick the commits corresponding to the denoising algorithms only, rebase... and ask for a merge. It's important to make sure that your work can be re-used into the main branch. As you seem to have plenty of new stuff (the viewer for example) to keep you busy, I can take care of this refactoring if you like. Concerning the tutorial, I couldn't make the demos run. I understood that Mathjax had to be installed, but the installation instructions of Mathjax did not appear very clear to me, so I did not really know where I should put it. So I guess I will also wait for some documentation from your side. The idea of an interactive tutorial that explains the algorithms and let the user execute some demo is really cool, however! Do you plan to have the tutorial on a single web server, or that users run it on their own computer? In the first case, you may use any kind of top-notch not-so-standard software such as Mathjax, but if every user has to install it, it will be more of a problem... In any case, I'm eager to know more about this tutorial project! Finally, for the viewer, I had to make a small addition to the setup.py to install the package (see my comment on github, I needed to specify the location of numpy headers). I was glad to see that you were able to code some of the features that Lionel and you really need, such as being able to flip between two images, or representing the level lines of an image. However, I know almost nothing about visualization, so I'm afraid I don't have very constructive comments about the viewer. Maybe just one remark: as a lot of scientists work interactively within the Python shell, e.g. Ipython, it is important that calls to the viewer are not blocking, i.e., that the user gets the prompt back. Cheers, Emmanuelle On Wed, Oct 27, 2010 at 01:43:42PM -0700, mael wrote:
Hello,
I had lots of things to do lately, haven't had much time to work on the library, but I'll do it quickly,
here are the new things: http://github.com/maelp/scikits.image (some new filters, and some nice zooms)
here are other projects that I work on in parallel, and I'd be happy to have some contribution: - image viewer: this should become the image viewer of scikits.image in our opinion (although it is not yet complete). Basically, it is a modulable efficient viewer, that handles zoom properly, displays level lines, etc and should be easily extensible. This is only a stub yet, and I'd be happy to merge it with your viewer, in particular have the threaded computations to have faster computations, and add the histrograms, normalization, etc. It can show grey and color int / float images, and should be pretty fast even for large images since it only computes the strictly required part that is needed to be viewed, and has a cache to speed-up the next recomputations (if you move the view a little, most of the rendered image does not change, and it only recomputes what needs be )
- tutorial: http://github.com/maelp/tutorial This should become a standard way to describe scikits.image algorithms in a dynamic way (this is basically the Qt Webkit that has been extended to include scikits.image algorithm) This could be a good advantage of the library: it is often difficult to find interactive use-case for algorithms, etc, and many times, old algorithms aren't properly documented, or we don't know in which case they do and don't apply. If we have a standard "documentation" in interactive format (where people can try our algorithms, have a mathematical presentation, upload their images etc) this will help keep up with a large image library. I made it such that it is visually attractive because I'm pretty sure this is extremely important (have beautiful documentation )
I will add new filters to the library soon, please give some inputs on the new projects and feel free to extend and/or modify anything
I haven't had time to properly document everything yet, I'll do that soon
Hello Emmanuelle, thanks for your input I had a look at the new filters. I added some documentation to
the existing docstrings (http://github.com/emmanuelle/scikits.image/commits/denoise), could you please check that I didn't write anything wrong? I'm planning to add tests for these denoising functions in the next few days. After the code is fully tested, I think it will be time to start to start a new branch, cherry-pick the commits corresponding to the denoising algorithms only, rebase... and ask for a merge. It's important to make sure that your work can be re-used into the main branch. As you seem to have plenty of new stuff (the viewer for example) to keep you busy, I can take care of this refactoring if you like.
Thanks this looks very good
Concerning the tutorial, I couldn't make the demos run. I understood that Mathjax had to be installed, but the installation instructions of Mathjax did not appear very clear to me, so I did not really know where I should put it. So I guess I will also wait for some documentation from your side. The idea of an interactive tutorial that explains the algorithms and let the user execute some demo is really cool, however! Do you plan to have the tutorial on a single web server, or that users run it on their own computer? In the first case, you may use any kind of top-notch not-so-standard software such as Mathjax, but if every user has to install it, it will be more of a problem... In any case, I'm eager to know more about this tutorial project!
Yes, sorry for the lack of documentation, I wanted it to go this way:
we distribute the webbrowser with required fonts and JS libraries that might be used by most of the tutorials, and they might be loaded at run-time by the browser, so distributing new tutorials won't require also distributing (heavy!) libraries now, you don't need MathJax to see how the thing work, but if you want to use it, simply uncompress it as image_denoising_tutorial/js/MathJax to compile, you need to run the Makefile in lib/, then call ipaper.py with the directory "image_denoising_tutorial" as argument, ie. ./ipaper.py /path/to/image_denoising_tutorial/
Finally, for the viewer, I had to make a small addition to the setup.py to install the package (see my comment on github, I needed to specify the location of numpy headers). I was glad to see that you were able to code some of the features that Lionel and you really need, such as being able to flip between two images, or representing the level lines of an image. However, I know almost nothing about visualization, so I'm afraid I don't have very constructive comments about the viewer. Maybe just one remark: as a lot of scientists work interactively within the Python shell, e.g. Ipython, it is important that calls to the viewer are not blocking, i.e., that the user gets the prompt back.
I included it, for the comments regarding this viewer: I think my zooming functions are slightly more suited here: there are more zooms, it's faster and IMO more convenient to use, and most of all, the zooming code is MUCH easier to access (both in term of understandability and ease of modification if we need to update it) than that of ndimage, so I'd recommend using it for the viewer. I'd like to add some GUI rather than having only keyboard shortcuts for the viewer, but I created it in a modular way, such that we could build a very simple viewer with only keyboard accelerators, that would be nice when debugging an algorithm, or quickly looking at the result of an algorithm, and also embedd it in a more full-fledged application if we need a real image viewer. I guess it shouldn't be too hard to return the input to the user
It would be nice if you made the viewer I plugin for the io framework. Plugins are *really* simple to create. Just checkout how I did the qt plugin for io.imshow(). If you follow the plugin architecture, the viewer will by default be compatible from an interactive prompt. Cheers, Chris On Sun, Oct 31, 2010 at 10:46 AM, Maël Primet <mael.primet@gmail.com> wrote:
Hello Emmanuelle,
thanks for your input
I had a look at the new filters. I added some documentation to
the existing docstrings (http://github.com/emmanuelle/scikits.image/commits/denoise), could you please check that I didn't write anything wrong? I'm planning to add tests for these denoising functions in the next few days. After the code is fully tested, I think it will be time to start to start a new branch, cherry-pick the commits corresponding to the denoising algorithms only, rebase... and ask for a merge. It's important to make sure that your work can be re-used into the main branch. As you seem to have plenty of new stuff (the viewer for example) to keep you busy, I can take care of this refactoring if you like.
Thanks this looks very good
Concerning the tutorial, I couldn't make the demos run. I understood that Mathjax had to be installed, but the installation instructions of Mathjax did not appear very clear to me, so I did not really know where I should put it. So I guess I will also wait for some documentation from your side. The idea of an interactive tutorial that explains the algorithms and let the user execute some demo is really cool, however! Do you plan to have the tutorial on a single web server, or that users run it on their own computer? In the first case, you may use any kind of top-notch not-so-standard software such as Mathjax, but if every user has to install it, it will be more of a problem... In any case, I'm eager to know more about this tutorial project!
Yes, sorry for the lack of documentation, I wanted it to go this way:
we distribute the webbrowser with required fonts and JS libraries that might be used by most of the tutorials, and they might be loaded at run-time by the browser, so distributing new tutorials won't require also distributing (heavy!) libraries now, you don't need MathJax to see how the thing work, but if you want to use it, simply uncompress it as image_denoising_tutorial/js/MathJax to compile, you need to run the Makefile in lib/, then call ipaper.py with the directory "image_denoising_tutorial" as argument, ie. ./ipaper.py /path/to/image_denoising_tutorial/
Finally, for the viewer, I had to make a small addition to the setup.py to install the package (see my comment on github, I needed to specify the location of numpy headers). I was glad to see that you were able to code some of the features that Lionel and you really need, such as being able to flip between two images, or representing the level lines of an image. However, I know almost nothing about visualization, so I'm afraid I don't have very constructive comments about the viewer. Maybe just one remark: as a lot of scientists work interactively within the Python shell, e.g. Ipython, it is important that calls to the viewer are not blocking, i.e., that the user gets the prompt back.
I included it,
for the comments regarding this viewer: I think my zooming functions are slightly more suited here: there are more zooms, it's faster and IMO more convenient to use, and most of all, the zooming code is MUCH easier to access (both in term of understandability and ease of modification if we need to update it) than that of ndimage, so I'd recommend using it for the viewer.
I'd like to add some GUI rather than having only keyboard shortcuts for the viewer, but I created it in a modular way, such that we could build a very simple viewer with only keyboard accelerators, that would be nice when debugging an algorithm, or quickly looking at the result of an algorithm, and also embedd it in a more full-fledged application if we need a real image viewer.
I guess it shouldn't be too hard to return the input to the user
Sure, this was the idea, however since it was easier for me to develop the viewer as a side program, I haven't done it yet btw I find it hard to develop directly inside scikits.image, because each time I compile the library, it recompiles everything, rather than the things that changed. How do you handle developpment of new modules.?
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. On Sun, Oct 31, 2010 at 2:54 PM, Maël Primet <mael.primet@gmail.com> wrote:
Sure, this was the idea, however since it was easier for me to develop the viewer as a side program, I haven't done it yet
btw I find it hard to develop directly inside scikits.image, because each time I compile the library, it recompiles everything, rather than the things that changed. How do you handle developpment of new modules.?
On Sun, Oct 31, 2010 at 9:22 PM, Chris Colbert <sccolbert@gmail.com> 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
participants (5)
-
Chris Colbert -
Emmanuelle Gouillart -
mael -
Maël Primet
-
Stéfan van der Walt