Mailman 3 November 2009 - scikit-image

Ready to tag 0.2: please give it a whirl
by Stéfan van der Walt 09 Nov '09

09 Nov '09

Hi all, After merging the 'io' branch, I am ready to tag 0.2 after some more testing (I accidentally called it 0.3 before). Would you please check out the master branch from http://github.com/stefanv/scikits.image and give it a good thrashing before we release? I've also updated the docs on github in preparation: http://stefanv.github.com/scikits.image - Chris, your io and threaded refactor have been merged. - Tony, your docs changes have been merged. - Ralf, your coverage changes have been merged. I'd love to merge the filter improvements too, if you're almost done with those. I added a skeleton for the User Guide (http://stefanv.github.com/scikits.image/user_guide.html). I think an introductory chapter to image processing with examples should be high on the agenda for the next round of development. Thanks! Stéfan

2 1

Aspect Ratio for the fancy imshow, need your opinions!
by Chris Colbert 07 Nov '09

07 Nov '09

Currently, the simple imshow(), just shows the image at its native size with no resizing possible. In the QT plugin version imshow(img, fancy=True), allows the image to be resized with the window to any aspect ratio. What is the preference of everyone here? Would you rather I leave it so it can be resized to any ratio (with the possibility of it not being the correct aspect ratio on launch, if it is very small, or very large). Or would you prefer that the aspect ratio be kept constant? Cheers, Chris

2 3

Fancy imshow and colormixer refactor complete + more functionality
by Chris Colbert 06 Nov '09

06 Nov '09

Hey Everyone, I think i've fixed all the problems I mentioned last night concerning the circular references, etc... In the process, I managed to speed up the widget quite a bit by getting rid of unnecessary fluff. I've also added gamma correction and sigmoidal gamma correction to the color mixer and the imshow widget. So if you all would be so kind, please grab it from my IO branch and give it a thrashing, and let me know if anything breaks. I'm gonna get working on fixing the aspect ratio, and usings holgers suggestion of being able to hide widgets... Cheers! Chris

1 0

Re: Pending release of 0.3
by Chris Colbert 06 Nov '09

06 Nov '09

Here's a couple links on it Holger. Hopefully the scipy links work for you (its the Ipython part of the discussion). I cant get to them right now. http://mail.scipy.org/pipermail/ipython-dev/2009-July/005256.html http://mail.scipy.org/pipermail/ipython-dev/2009-February/004905.html http://mail.python.org/pipermail/python-dev/2005-November/057954.html On Thu, Nov 5, 2009 at 5:14 PM, SirVer <sirver(a)gmx.de> wrote: > >> 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...(a)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...(a)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...(a)sun.ac.za>: >> >> >>> 2009/11/5 Chris Colbert <sccolb...(a)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

2 1

Histograms added to Fancy Imshow and ColorMixer
by Chris Colbert 06 Nov '09

06 Nov '09

Hey All, I've added preliminary Histogramming to the fancy imshow QT widget. In the process I added a fast Naive histogrammer to the ColorMixer for use in this widget. Unfortunately, I'm now suffering from circular references during window instantiation. I'm gonna need to refactor the code a bit because QT likes to fire off event before with main window has finished intializing. Everything still works, it just throws a few exceptions while the window is intializing. At any rate, you can, you can check out the code from my IO branch on git. And here is a screenshot to wet your appetite: http://therealstevencolbert.com/dump/histograms.png Cheers! Chris

3 2

Re: Pending release of 0.3
by Chris Colbert 05 Nov '09

05 Nov '09

On Thu, Nov 5, 2009 at 3:44 PM, SirVer <sirver(a)gmx.de> wrote: > > > > On 5 Nov., 15:27, Chris Colbert <sccolb...(a)gmail.com> wrote: >> On Thu, Nov 5, 2009 at 3:16 PM, SirVer <sir...(a)gmx.de> wrote: >> >> > Hi, >> >> > On 4 Nov., 15:04, Stéfan van der Walt <ste...(a)sun.ac.za> wrote: >> >> 2009/11/4 SirVer <sir...(a)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. 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

3 6

Re: Pending release of 0.3
by Stéfan van der Walt 05 Nov '09

05 Nov '09

Hi Holger 2009/11/5 SirVer <sirver(a)gmx.de>: > 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 see the PyOpenGL wrappers nowadays use ctypes, so they can be installed without compiling anything (good!). The reason I suggested Pyglet is because it gives you a higher-level abstraction on things such as textures and windows, and allows you to skirt the PyQt dependency, if you'd want to. As for the implementation of a realtime display, I'd be glad to work with you to remove any hinderances that prevent the use of the plugin framework. If it is a fundamental limitation, I'd be glad if we could discuss that to get a better idea of your needs. Regards Stéfan

2 1

Re: Pending release of 0.3
by Chris Colbert 05 Nov '09

05 Nov '09

On Thu, Nov 5, 2009 at 3:16 PM, SirVer <sirver(a)gmx.de> wrote: > > Hi, > > > On 4 Nov., 15:04, Stéfan van der Walt <ste...(a)sun.ac.za> wrote: >> 2009/11/4 SirVer <sir...(a)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" > Cheers, > Holger > > >> >> Regards >> Stéfan

2 1

Re: Pending release of 0.3
by Stéfan van der Walt 05 Nov '09

05 Nov '09

2009/11/4 SirVer <sirver(a)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. Regards Stéfan

2 1

Re: OpenCV 2 or 1
by Chris Colbert 05 Nov '09

05 Nov '09

Im all for a big glaring "OpenCV >= 2.0 required if you want to use opencv extensions" On Wed, Nov 4, 2009 at 1:57 PM, SirVer <sirver(a)gmx.de> wrote: > > A __version__ function in the future is little help to distinguish > between OCV 1 and OCV 2. BUT the current case is not bearable; for > example the test suite can not be run when you have OpenCV 1 > installed, because OpenCV errors always result in a coredump because > of their braindumped I-do-my-own-Exceptions-In-C-Which-Are-Uncatchable > Stuff. That is, as soon as the opencv tests run, the whole python > process is KILLED by opencv throwing an exception because I expects an > array of 1x5 instead of 1x4. (Note that the same is true if we do > stuff vice-versa: making version 1 a dependency and the user has 2 > installed). > > The only REAL solutions I see for this mess is to either > a) decide which version to build against at build time using IFDEFs. > Which is ugly and not easy to pull off and makes OpenCV a hard build > time dependency. On plus we would have to ship binary versions linked > against OCV1 and OCV2. Ugly code, Ugly distribution, hard to > implement. > b) Determine at run time if the user has OpenCV 1 installed and ABORT > then in a pythonic fashion. I know of no portable way to pull this > off; one could only check for relative positions of functions in the > binaries or so. Nice code, nice distribution, very hard to implement. > c) Rip the parts that we need from the OpenCV source code (if > licensing allows that) and build our own subset of the functionality > into scikit.image. No dependency on the OpenCV anymore, no cranky > void* pointer passing around, no strange exceptions that are > uncatchable. Heaven on earth. Downside: a lot of work. Upside: We > really would provide the image processing capabilities. > > What do others think? Personally, I always wanted to have a better > designed Image Library with a smaller, but well tested subset of > ImageProcessing Algos that are really useful. > > >> Goodluck with getting that done though. I doubt we will see a new >> OpenCV release for awhile... and people will be using 2.0 for a long >> time to come... > No wonder; hacking OpenCV code is as ugly as coding can get. > > Cheers, > Holger > >> >> 2009/11/4 Stéfan van der Walt <ste...(a)sun.ac.za>: >> >> >> >> >> >> > 2009/11/4 Chris Colbert <sccolb...(a)gmail.com>: >> >> >> OpenCV has a ___version___ header file. >> >> > We can only access that if it exposed as a function, though, so maybe >> > they can help us out. >> >> > Cheers >> > Stéfan

3 9