Mailman 3 June 2013 - scikit-image

Re: skimage and opencv
by Emmanuelle Gouillart 22 Sep '16

22 Sep '16

Hi FranÃ¯Â¿Â½ois, that's an excellent question, and not a troll :-). Opencv is a very powerful library, but it focuses primarily on computer vision (feature detection and extraction, classification, ...), as opposed to image processing in general (with other tasks such as denoising, segmentation, ...). The other big difference is that skimage builds on numpy ndarrays, and uses the full power of the numpy API (including of course the basic facilities for processing arrays as images that come with numpy), as well as some of scipy functions (you could have added scipy.ndimage to your list -- a few functions in skimage are wrappers around scipy.ndimage, that exist for the sake of completeneness). One important consequence is that algorithms working for 3-d or even n-d images can be easily implemented in 3-d/n-d in skimage, whereas opencv is restricted to 2-D images (as far as I know). Thanks to the use of numpy arrays, the API of skimage is also quite pleasant for a numpy user, more than the API of opencv. A related difference is that skimage is written in python and cython, whereas opencv is a C++ library. The two libraries attract a different crowd of developers, and a Python/Cython toolkit based on numpy arrays is easier to develop and maintain inside the Scientific Python ecosystem. I'm sure that other devs/users will have things to add to this discussion! Cheers, Emmanuelle On Thu, Dec 27, 2012 at 02:06:08PM -0800, FranÃ¯Â¿Â½ois wrote: > Hi users and devs, > It came to my knowledge that another python library (based on C++ and C > codes) for image processing exists too : opencv > I understand that numpy intregrates some basic features and we need some > advanced features but I have the feeling that skimages is redoundant with > opencv in some ways. > What's the position of skimage about that? (Don't read this question as a > troll but like a real question). > I mean that similar features exist in both. Would not be possible to > reuse/integrate opencv or merge? what's the reason for keeping them apart? > My observation is there is 4 libraries to manipulate images: > * PIL > * numpy > * skimages > * opencv > That's a lot. > Cheers,

3 2

Re: Contribution: circles and hough transform
by François 18 Jun '14

18 Jun '14

Hi, FYI, I plan to work on the detection of ellipses quite soon. Stefan indicated to me a reference which seems fairly simple to implement. Cheers, François.

3 3

Sift on GPU
by Jérôme Kieffer 10 Sep '13

10 Sep '13

Dear Pythonistas, We are porting the SIFT keypoints extraction algorithm (available from IPOL) to GPU using PyOpenCL. For the moment, the keypoint location works and shows a speed-up of 5 to 10x (without tuning so far, vs C++). A lot of work is remaining, especially: * limit the memory footprint (700MB/10Mpix image currently) * calculate the descriptor for each descriptor * keypoint matching and image alignment. * best interleave of IO/CPU/GPU but we managed to port the most trickiest part to OpenCL (without using textures, which makes it running also on multi-core). I would like to thank the people who published their algorithm on IPOL; making unit testing possible. Last but not least, the code is open source and should have a BSD licence (even if there is a patent on the algorithm in the USA). https://github.com/pierrepaleo/sift_pyocl Cheers, -- Jérôme Kieffer <google(a)terre-adelie.org>

4 5

GSoC Proposal
by Marc de Klerk 10 Jul '13

10 Jul '13

Hello Everyone, I just wanted to post my proposal for the GSoC: https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/dek… I hope it sparks a bit of interest :) Looking forward to hearing any feedback... Cheers Marc

2 2

Re: source compilation error: undefined references
by Evan 10 Jul '13

10 Jul '13

On Thursday, June 13, 2013 1:55:02 PM UTC+2, Stefan van der Walt wrote: > > On Thu, Jun 13, 2013 at 11:43 AM, Evan <evan...(a)gmail.com <javascript:>> > wrote: > > Thanks for your reply. Can you coach me a little on the modification I > need > > to make. I assume the file to edit is: > > ... /scikit-image-0.8.2/skimage/_shared/setup.py > > But so far I don't see how to resolve what's needed from > > http://docs.cython.org/src/tutorial/external.html#dynamic-linking into > the > > setup file. > > Yes, you need to add the 'libraries=["m"]' part. > > Stéfan > Ok, got it. Had to work through and edit each each subdir + setup.py as needed. I'll send the pull request in the next day or two. Thanks very much for the help, Evan

2 1

1st and 2st order statistical texture features of an image
by Dan 04 Jul '13

04 Jul '13

Hi, I wish to perform first (histogram based mean, stdev, smoothness, skewness, uniformity and entropy) and second order (GLCM based contrast, correlation, energy, homogeneity) statistical texture features of an image. is it possible in scikit-image? If so a small script will be a huge help. Thanks.

2 2

Re: Graph Cuts implementation
by Marc de Klerk 01 Jul '13

01 Jul '13

Thanks Ray, That was a great read! Slimcuts look promising. Do you have any thoughts on the implementation? >From what I gather each node must be visited and then to check if any adjacent edge has a capacity larger than the sum of the capacities of the remaining adjacent edges. This process is seemingly them performed repeatedly. This will break the regular structure of the graph meaning that vertex indicies will have to be looked up and I can't figure out how they manage to attain the reported performance. I guess once they have the reduced graph graph-cuts is fast, but I can't see how creating the reducing graph can be fast. They did however mention that C source files are available for research purposes - Does GSOC / scikit-image count as research? Marc On Tuesday, June 25, 2013 3:22:52 AM UTC+2, Thouis (Ray) Jones wrote: > > I would suggest implementing some sort of graph simplification, as in: > http://www.3dtv-con2009.org/papers/data/883/paper_EMMCVPR_11.pdf > or > http://hal.archives-ouvertes.fr/docs/00/78/66/55/PDF/main.pdf > > These can be quite effective at reducing the complexity of the graph for > planar st-mincut problems, without being too difficult to implement. > > Ray Jones > > > > On Sun, Jun 23, 2013 at 6:31 PM, Marc de Klerk <dekl...(a)gmail.com<javascript:> > > wrote: > >> Hi Emmanuelle, >> >> I'll have to go have a look weather it's that simple, but thanks for the >> pointing me in the direction of joblib... >> In the mean I got a lot of the scaffolding down and put together a demo >> for Grow Cuts on the GPU. >> Installation instructions are on my gsoc blog - >> http://mygsoc.blogspot.com/2013/06/a-kickstart-to-first-week.html >> >> Cheers! >> Marc >> >> >> On Sunday, June 23, 2013 11:44:03 PM UTC+2, Emmanuelle Gouillart wrote: >>> >>> Hi Mark, >>> >>> thanks for this first survey. I'll read articles [2] and [4] in the next >>> days, so that I can give you more feedback. For the multicore >>> programming, is it an embarrassingly parallel problem where you could >>> use >>> joblib.Parallel (or simply multiprocessing), or do you have a large >>> number of low-level "small operations" that need to be performed >>> together? Anyway, maybe you can write a first version of the code that >>> is >>> not parallel, convince yourself that the implementation is correct, and >>> only after think about the parallelization? >>> >>> Cheers, >>> Emmanuelle >>> >>> On Thu, Jun 20, 2013 at 03:17:16AM -0700, Marc de Klerk wrote: >>> > Hi Everyone, >>> >>> > One of items on my todo list in first three weeks of my GSOC is to >>> implement a >>> > CPU Graph-cuts. >>> > I've made a couple points from a preliminary literature survey and >>> would like >>> > to get some feedback / recommendations / advice. >>> >>> > Graph cut algorithms can generally be regarded as either begin >>> push-relabel >>> > (PR) or augmenting paths (AP) style. >>> > - The goto algorithm has typically been the Boykov and Kolmogorov >>> algorithm >>> > (AP) [1] >>> > - The current state-of-art graph-cut is packaged as GridCut, product >>> of [2] >>> > - Based on [1] >>> > - Multi core (from [3]) >>> > - Cache efficient memory layout (from [2]) >>> > - For grid-like topologies >>> > - A push relabel variant exists from [4] >>> > - Multi core (from [3]) >>> > - Not bound by memory constraints >>> > - For grid-like topologies >>> > - From what I can gather BK typically outperforms other approaches >>> such as the >>> > push-relabel algorithm, but to what extent I'm can't tell from the >>> literature… >>> > - [4] describes memory layout strategies to optimize caching for both >>> AP and PR >>> > style algorithms, but that choose the implement their strategies on >>> BK. >>> > - PR style algorithms are not limited by memory constraints, whereas >>> AP style >>> > algorithms are, however doing graph cuts on a coarse to fine scale >>> seem to be >>> > an answer. >>> > - PR is the only feasible way to do graph cuts on the GPU. >>> >>> > So I'm suggestions to implement the PR style algorithm of [4] using >>> the >>> > strategies described in [2] to speed things up. This then let's us >>> make a >>> > fairer comparison between CPU and GPU versions of the graph cut >>> >>> > Does this sound like a good way forward? >>> > It does require some multi-core programming which I'm not familiar >>> with - are >>> > there any examples of something similar in scikit-image? >>> >>> > [1] Boykov, Y., & Kolmogorov, V. (2004). An experimental comparison of >>> min-cut/ >>> > max- flow algorithms for energy minimization in vision. Pattern >>> Analysis and >>> > Machine Intelligence, IEEE Transactions on, 26(9), 1124–1137. >>> doi:10.1109/ >>> > TPAMI.2004.60 >>> > [2] Jamriska, O., Sykora, D., & Hornung, A. (2012). Cache-efficient >>> graph cuts >>> > on structured grids (pp. 3673–3680). Presented at the Computer Vision >>> and >>> > Pattern Recognition (CVPR), 2012 IEEE Conference on. doi:10.1109/ >>> > CVPR.2012.6248113 >>> > [3] Liu, J., & Sun, J. (2010). Parallel graph-cuts by adaptive >>> bottom-up >>> > merging (pp. 2181–2188). Presented at the Computer Vision and Pattern >>> > Recognition (CVPR), 2010 IEEE Conference on. >>> doi:10.1109/CVPR.2010.5539898 >>> > [4] Delong, A., & Boykov, Y. (2008). A Scalable graph-cut algorithm >>> for N-D >>> > grids (pp. 1–8). Presented at the Computer Vision and Pattern >>> Recognition, >>> > 2008. CVPR 2008. IEEE Conference on. doi:10.1109/CVPR.2008.4587464 >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "scikit-image" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to scikit-image...(a)googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > >

2 7

Re: segmentation fault with the viewer
by Josh Warner 29 Jun '13

29 Jun '13

I can confirm that `viewer.show()` is blocking on PySide, though it's quite stable for me on qt. On Saturday, June 29, 2013 5:07:49 PM UTC-5, Tony S Yu wrote: > > > On Sat, Jun 29, 2013 at 5:03 PM, Emmanuelle Gouillart < > emmanuelle...(a)nsup.org <javascript:>> wrote: > >> On Sat, Jun 29, 2013 at 02:58:22PM -0700, Josh Warner wrote: >> > I got it to segfault once using the tk backend for pylab, but it wasn't >> > robustly repeatable (randomly happened once out of a lot of focus >> losses/ >> > regains, and never on close). >> >> > It looked similar to routine segfaults I get for the tk backend, which >> I've >> > never been able to track down. That's why I usually avoid the tk >> backend like >> > the plage... >> >> > Is this reproducible on any other backends? >> >> Yes, tk, wx, gtk, I get a segfault with all of them (using qt raises an >> error). >> >> Emmanuelle >> > > Are you on master? Specifically, a version later than yesterday morning? > The viewer-linking PR that was merged yesterday had a number of fixes for > PySide. I don't see any issue on PyQt at the moment. > > -Tony >

1 0

segmentation fault with the viewer
by Emmanuelle Gouillart 29 Jun '13

29 Jun '13

Dear all, I've started playing around with skimage's viewer, and I get a segmentation fault when I try to close the viewer window, or when I click on the window after having the focus on another window. Also, the command viewer.show() is blocking (I'm running ipython --pylab - corresponding to the TkAgg backend). Running a test script from ipython in gdb yields the following message: Program received signal SIGSEGV, Segmentation fault. 0x00007fffd4aa511d in Shiboken::Conversions::isPythonToCppConvertible(SbkConverter*, _object*) () from /usr/lib/x86_64-linux-gnu/libshiboken-python2.7.so.1.1 I'm running Ubuntu 12.04 with Nvidia's proprietary drivers. I am the only one having this problem? Any idea where the seg fault comes from? I reproduce below the test script. Cheers, Emmanuelle ***************** from skimage import data from skimage.viewer import ImageViewer image = data.coins() from skimage.filter import tv_denoise from skimage.viewer.plugins.base import Plugin denoise_plugin = Plugin(image_filter=tv_denoise) from skimage.viewer.widgets import Slider from skimage.viewer.widgets.history import SaveButtons denoise_plugin += Slider('weight', 0.01, 0.5, update_on='release') denoise_plugin += SaveButtons() viewer = ImageViewer(image) viewer += denoise_plugin viewer.show()

3 3

Algorithm to 'walk' along a line from an endpoint by N pixels
by Robin Wilson 29 Jun '13

29 Jun '13

Hi, Does anyone know if an algorithm to take an endpoint of a binary line in an image and 'walk' back along the line for N pixels already exists in skimage? (or in any of the related projects). I'm happy to go ahead and implement it, but it seems like the kind of thing that would have already been implemented, even though I can't find it in the documentation. Does this already exist? Cheers, Robin

3 3