Re: Pending release of 0.3
On Thu, Nov 5, 2009 at 3:44 PM, SirVer <sirver@gmx.de> wrote:
On Thu, Nov 5, 2009 at 3:16 PM, SirVer <sir...@gmx.de> wrote:
Hi,
On 4 Nov., 15:04, Stéfan van der Walt <ste...@sun.ac.za> wrote:
2009/11/4 SirVer <sir...@gmx.de>:
Stefan, concerning my GUI branch: I played around with pyqt and QImages and they just couldn't deliver what I needed: Speed.
I'd like to see some benchmarks that support this, because it should be the cost of 2 python calls + whatever time the GUI uses. QImage is fast when loading directly from a numpy array. I'm not sure, with the copying that you have to do into a texture, that OpenGL can do any better. I did some benchmarks, but unfortunately I do not have the code around. I created QImages and painted them directly in PyQt. It was reasonable fast, but I couldn't reach the performance I have with a QGLWidget which delivers easily 300fps or 60fps in 12 different windows. I'd rather not hack this again since this issue is somewhat settled for me and I'd prefer spending my coding time on other itches I have.
I still think that PyQt is a much bigger dependency then PyOpenGL - and even so: both are optional and only needed when GUI stuff in real time should be performed.
I think you're not really grasping the idea of "plugin" Well, I understood the principle of plugin quite well; BUT the plugin architecture does not allow real time display of images right now. It won't be possible to implement it that way. AND there are users who will need this and might need it in image
On 5 Nov., 15:27, Chris Colbert <sccolb...@gmail.com> wrote: processing tasks. The question here is just if and if yes how to implement this.
I meant that you make the claim that QT is a heavy dependency, when in fact its not a dependency at all unless the individual wants to use the qt plugins. The scikit, and all it's image process, still function without having QT installed. Further, these imshow() type widgets are primarily meant to be used from the interactive interpreter, an environment not best suited for real time image acquisition and display. that said, the plugin archiceture can most certainly be used in the method you speak of. You just simply have your imshow() function return the window object, and implement an update() or similar method that the consumer can call to update the image.
If my code and my attempts are not to be included in scikit.image, so be it. I will continue to use it anyway; i just think they are useful and WANT to contribute them to the public.
Cheers, Holger
Regards Stéfan
2009/11/5 Chris Colbert <sccolbert@gmail.com>:
Further, these imshow() type widgets are primarily meant to be used from the interactive interpreter, an environment not best suited for real time image acquisition and display. that said, the plugin archiceture can most certainly be used in the method you speak of. You just simply have your imshow() function return the window object, and implement an update() or similar method that the consumer can call to update the image.
This could even be accomplished using 'imshow' only. The WindowManager keeps track of the single window produced, and 'imshow' simply grabs that window and updates its current content. I'd be surprised if we couldn't pump out a large number of frames-per-second that way. Stéfan
I was just testing out something along these lines, but I run into the problem of the the python interpreter not considering time.sleep() as idle time, thus, it never calls PyOS_InputHook inside of for-loops. So i'm not quite sure how to get video feed to run interactively without hacking out something like ipython -whatever thread. Mind you, this is not a problem with the plugin architecture, its a problem with the python interpreter... but maybe i can ctypes into the os_hook and call it at the end of a loop.... <evil grin> 2009/11/5 Stéfan van der Walt <stefan@sun.ac.za>:
2009/11/5 Chris Colbert <sccolbert@gmail.com>:
Further, these imshow() type widgets are primarily meant to be used from the interactive interpreter, an environment not best suited for real time image acquisition and display. that said, the plugin archiceture can most certainly be used in the method you speak of. You just simply have your imshow() function return the window object, and implement an update() or similar method that the consumer can call to update the image.
This could even be accomplished using 'imshow' only. The WindowManager keeps track of the single window produced, and 'imshow' simply grabs that window and updates its current content. I'd be surprised if we couldn't pump out a large number of frames-per-second that way.
Stéfan
So while i havent yet been able to get the pyos_inputhook thing sorted out, I did time a couple loops. For a decent sized image, we can easily get 60fps update rates, and thats including the time for the numpy operations: In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg') In [6]: img.shape Out[6]: (503, 790, 3) In [7]: win = io.imshow(img, updateable=True) In [8]: def test(img, win): ...: for i in range(30): ...: img[:] += 1 ...: win.update() ...: ...: In [9]: %timeit test(img, win) 1 loops, best of 3: 564 ms per loop one thing to note, I bypassed the prepare_for_display() method that we usually call to make sure an array is contiguous, of the right dtype, etc... I assume if someone wants video, they can prepare the arrays themselves. This behavior can also be changed by the plugin writer. For this example, i simply took the easy route and subclassed ImageWindow Cheers, Chris On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolbert@gmail.com> wrote:
I was just testing out something along these lines, but I run into the problem of the the python interpreter not considering time.sleep() as idle time, thus, it never calls PyOS_InputHook inside of for-loops. So i'm not quite sure how to get video feed to run interactively without hacking out something like ipython -whatever thread.
Mind you, this is not a problem with the plugin architecture, its a problem with the python interpreter...
but maybe i can ctypes into the os_hook and call it at the end of a loop.... <evil grin>
2009/11/5 Stéfan van der Walt <stefan@sun.ac.za>:
2009/11/5 Chris Colbert <sccolbert@gmail.com>:
Further, these imshow() type widgets are primarily meant to be used from the interactive interpreter, an environment not best suited for real time image acquisition and display. that said, the plugin archiceture can most certainly be used in the method you speak of. You just simply have your imshow() function return the window object, and implement an update() or similar method that the consumer can call to update the image.
This could even be accomplished using 'imshow' only. The WindowManager keeps track of the single window produced, and 'imshow' simply grabs that window and updates its current content. I'd be surprised if we couldn't pump out a large number of frames-per-second that way.
Stéfan
Holger, There is nothing stopping you from making a pyopengl plugin. Or even modifying your current gui to fit within the plugin framework. However, i'm afraid that your current gui may rely on ipython -q4thread, which is now deprecated (big mailing list discussion on this). So that may throw a wrench in the video portion of it, unless we can figure out this pyos_input hook thing. But as my previous example shows, its definately possible to fit it within the plugin framework. Cheers! Chris On Thu, Nov 5, 2009 at 4:56 PM, Chris Colbert <sccolbert@gmail.com> wrote:
So while i havent yet been able to get the pyos_inputhook thing sorted out, I did time a couple loops.
For a decent sized image, we can easily get 60fps update rates, and thats including the time for the numpy operations:
In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')
In [6]: img.shape Out[6]: (503, 790, 3)
In [7]: win = io.imshow(img, updateable=True)
In [8]: def test(img, win): ...: for i in range(30): ...: img[:] += 1 ...: win.update() ...: ...:
In [9]: %timeit test(img, win) 1 loops, best of 3: 564 ms per loop
one thing to note, I bypassed the prepare_for_display() method that we usually call to make sure an array is contiguous, of the right dtype, etc... I assume if someone wants video, they can prepare the arrays themselves.
This behavior can also be changed by the plugin writer. For this example, i simply took the easy route and subclassed ImageWindow
Cheers,
Chris
On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolbert@gmail.com> wrote:
I was just testing out something along these lines, but I run into the problem of the the python interpreter not considering time.sleep() as idle time, thus, it never calls PyOS_InputHook inside of for-loops. So i'm not quite sure how to get video feed to run interactively without hacking out something like ipython -whatever thread.
Mind you, this is not a problem with the plugin architecture, its a problem with the python interpreter...
but maybe i can ctypes into the os_hook and call it at the end of a loop.... <evil grin>
2009/11/5 Stéfan van der Walt <stefan@sun.ac.za>:
2009/11/5 Chris Colbert <sccolbert@gmail.com>:
Further, these imshow() type widgets are primarily meant to be used from the interactive interpreter, an environment not best suited for real time image acquisition and display. that said, the plugin archiceture can most certainly be used in the method you speak of. You just simply have your imshow() function return the window object, and implement an update() or similar method that the consumer can call to update the image.
This could even be accomplished using 'imshow' only. The WindowManager keeps track of the single window produced, and 'imshow' simply grabs that window and updates its current content. I'd be surprised if we couldn't pump out a large number of frames-per-second that way.
Stéfan
However, i'm afraid that your current gui may rely on ipython -q4thread, which is now deprecated (big mailing list discussion on this). So that may throw a wrench in the video portion of it, unless we can figure out this pyos_input hook thing. It infact does. Chris, could you please point me at this discussion? It is most relevant for my work.
Cheers, Holger
But as my previous example shows, its definately possible to fit it within the plugin framework.
Cheers!
Chris
On Thu, Nov 5, 2009 at 4:56 PM, Chris Colbert <sccolb...@gmail.com> wrote:
So while i havent yet been able to get the pyos_inputhook thing sorted out, I did time a couple loops.
For a decent sized image, we can easily get 60fps update rates, and thats including the time for the numpy operations:
In [5]: img = io.imread('/home/brucewayne/Pictures/failboat_4.jpg')
In [6]: img.shape Out[6]: (503, 790, 3)
In [7]: win = io.imshow(img, updateable=True)
In [8]: def test(img, win): ...: for i in range(30): ...: img[:] += 1 ...: win.update() ...: ...:
In [9]: %timeit test(img, win) 1 loops, best of 3: 564 ms per loop
one thing to note, I bypassed the prepare_for_display() method that we usually call to make sure an array is contiguous, of the right dtype, etc... I assume if someone wants video, they can prepare the arrays themselves.
This behavior can also be changed by the plugin writer. For this example, i simply took the easy route and subclassed ImageWindow
Cheers,
Chris
On Thu, Nov 5, 2009 at 4:24 PM, Chris Colbert <sccolb...@gmail.com> wrote:
I was just testing out something along these lines, but I run into the problem of the the python interpreter not considering time.sleep() as idle time, thus, it never calls PyOS_InputHook inside of for-loops. So i'm not quite sure how to get video feed to run interactively without hacking out something like ipython -whatever thread.
Mind you, this is not a problem with the plugin architecture, its a problem with the python interpreter...
but maybe i can ctypes into the os_hook and call it at the end of a loop.... <evil grin>
2009/11/5 Stéfan van der Walt <ste...@sun.ac.za>:
2009/11/5 Chris Colbert <sccolb...@gmail.com>:
Further, these imshow() type widgets are primarily meant to be used from the interactive interpreter, an environment not best suited for real time image acquisition and display. that said, the plugin archiceture can most certainly be used in the method you speak of. You just simply have your imshow() function return the window object, and implement an update() or similar method that the consumer can call to update the image.
This could even be accomplished using 'imshow' only. The WindowManager keeps track of the single window produced, and 'imshow' simply grabs that window and updates its current content. I'd be surprised if we couldn't pump out a large number of frames-per-second that way.
Stéfan
On Thu, Nov 5, 2009 at 3:44 PM, SirVer <sir...@gmx.de> wrote:
On 5 Nov., 15:27, Chris Colbert <sccolb...@gmail.com> wrote:
On Thu, Nov 5, 2009 at 3:16 PM, SirVer <sir...@gmx.de> wrote:
Hi,
On 4 Nov., 15:04, Stéfan van der Walt <ste...@sun.ac.za> wrote:
2009/11/4 SirVer <sir...@gmx.de>:
Stefan, concerning my GUI branch: I played around with pyqt and QImages and they just couldn't deliver what I needed: Speed.
I'd like to see some benchmarks that support this, because it should be the cost of 2 python calls + whatever time the GUI uses. QImage is fast when loading directly from a numpy array. I'm not sure, with the copying that you have to do into a texture, that OpenGL can do any better. I did some benchmarks, but unfortunately I do not have the code around. I created QImages and painted them directly in PyQt. It was reasonable fast, but I couldn't reach the performance I have with a QGLWidget which delivers easily 300fps or 60fps in 12 different windows. I'd rather not hack this again since this issue is somewhat settled for me and I'd prefer spending my coding time on other itches I have.
I still think that PyQt is a much bigger dependency then PyOpenGL - and even so: both are optional and only needed when GUI stuff in real time should be performed.
I think you're not really grasping the idea of "plugin" Well, I understood the principle of plugin quite well; BUT the plugin architecture does not allow real time display of images right now. It won't be possible to implement it that way. AND there are users who will need this and might need it in image processing tasks. The question here is just if and if yes how to implement this.
I meant that you make the claim that QT is a heavy dependency, when in fact its not a dependency at all unless the individual wants to use the qt plugins. The scikit, and all it's image process, still function without having QT installed. I understood that; and frankly that is out of question. I only mean IF
On 5 Nov., 15:54, Chris Colbert <sccolb...@gmail.com> wrote: they want to display anything in real time, pyopengl is not a heavy dependency comparing to Pyqt.
Further, these imshow() type widgets are primarily meant to be used from the interactive interpreter, an environment not best suited for real time image acquisition and display. I use live camera display + annotated images in pylab/ipython every day; I couldn't do my job without it.
that said, the plugin archiceture can most certainly be used in the method you speak of. You just simply have your imshow() function return the window object, and implement an update() or similar method that the consumer can call to update the image. I thought that this was not the way it should go. What I would need was a kind of update() functionality for each image. I would also need a kind of annotate functionality, so that the user has the chance to draw things onto the image (the drawing would not be backend independent, obviously). That said comes a big but: But as a user, I would not see the reason to use the plugin architecture then anymore (the same holds for me and matplotlib: they offer a backend independent signaling library (for mouse events etc), but every time I tried to use it, I decided to choose the backend to be qt (and no longer anything else) and use qt directly for enhanced flexibility). My point is: the current attempt for the plugin architecture is to make many backends for image displaying and maybe modification simple. My aim is in another direction: to offer the user a set of base classes, that he really wants to extend in his own Programs and which are NOT backend independent. Maybe scikit.images is not the right place for this, but that's what i'm here to discuss.
If my code and my attempts are not to be included in scikit.image, so be it. I will continue to use it anyway; i just think they are useful and WANT to contribute them to the public.
Cheers, Holger
Regards Stéfan
participants (3)
-
Chris Colbert -
SirVer -
Stéfan van der Walt