Mailman 3 December 2012 - 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: Making algorithms at least 3D, preferably nD
by jeff witz 26 Apr '13

26 Apr '13

Hello, I think you must all pay attention to standards if you want to act on nD images. For structured data files there is a library that hab been used for decade and which is very efficient, it's netcdf (http://www.unidata.ucar.edu/software/netcdf/), there is already tools in python to deal with it. This library allows one to deal with data in // which is important when one deals with big datas. The last version is based on hdf wich is the tools used on HPC. If your data are not stored in a standard format, the library ITK has provide a binding called SimpleITK that allows one to read every format ITK konws. It is important to take into account the fact that the operation on pixel depend on the grid spacing, as for exampe the finite difference gradient which is wrong when one chooses a step of one because the file as not been read correctly. As the 3D datas often comes from the measurement X-Ray Tomography, MRI, Echography, it is important to consider the device information. The format dicom as been made in this specific purpose there is a python binding called pydicom. I know that scikit team does'nt want to have to much dependances, but for nD case I think it is important to use existing libraries. Best regards Le vendredi 30 novembre 2012 05:45:49 UTC+1, Juan Nunez-Iglesias a écrit : > > Hey Guys, > > I mentioned this briefly at SciPy, but I would like to reiterate: a lot of > data is 3D images these days, and more and more data is being generated > that is multi-channel, 3D+t. Therefore, it would be awesome if scikit-image > started making more of an effort to support these. In the best case, the > dimension of the underlying array can be abstracted away — see here<https://github.com/jni/ray/blob/develop/ray/morpho.py#L328>for example, the functions juicy_center (which extracts the centre of an > array, along all dimensions), surfaces (grabs the "border" arrays along > each dimension), hollowed (zeroes-out the centre), and more. Otherwise, > writing a 3D function that gracefully degrades to 2D when one of the > dimensions is 1 is also possible. > > In general, the amount of additional effort to make code 3-, 4- or n- > dimensional is relatively low when you write the algorithm initially, > relative to refactoring a whole bunch of functions later. I'll try to > fiddle with whichever code I need, but in the meantime, what do you think > about adding a paragraph or a sentence about this issue in the scikit-image > contribute <http://scikit-image.org/docs/dev/contribute.html> section, so > that people at least have this in mind when they are thinking of writing > something new? > > Thanks, > > Juan. >

4 3

Re: skimage and opencv
by François 05 Jan '13

05 Jan '13

Many thanks for your responses. I agree with the fact that methods implemented in python are definitely easier to read. This a major advantage for education purpose. On the skimage home page, there is a 'Related project' box. Don't you think that it would be interesting to add these explanations on a dedicated page? Even the overview (see http://scikit-image.org/docs/dev/overview.html) is very light on the topic.

2 2

Re: the memory issue
by Emmanuelle Gouillart 31 Dec '12

31 Dec '12

Hi Vicky, the random walker algorithm has a quite complex api, because it can use several modes (the 'mode' keyword argument) to solve the linear system of the algorithm - 'bf' (for brute force): an LU decomposition of the matrix is computed. This is very costly in memory, and only recommended for small images. - 'cg' (for conjugate gradient). This mode needs much less memory, I suggest that you use it to test whether the algorithm gives good results for your problem. However, this mode is quite slow. - 'cg_mg': conjugate gradient with multigrid acceleration. This mode is much faster, but you'll need to install the module pyamg to use it. I use the cg_mg mode on tomography data (arrays of 500*500*20 float32 numbers, typically). Hope this helps, Emmanuelle On Mon, Dec 31, 2012 at 11:00:42AM -0800, vicky Liau wrote: > Hi everyone, > I use scikit-image to implement image segmentation for vegetation > classification. The target imagery is about 1GB, and I renewed my laptop > memory to 12GB (Window7 64 bit OS, CPU i7-2860QM) to read in imagery.Ã¯Â¿Â½ > However, when I tried to implement random walker segmentation, ipython > shows memory errors.Ã¯Â¿Â½ > Also, I shrink the imagery to 188 MB, and implement the same algorithm. > Ipython still shows errors as following.Ã¯Â¿Â½ > RuntimeError Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½Traceback (most recent call > last) > C:\Dropbox\open_codes\RS_codes\<ipython-input-80-737c60591471> in > <module>() > ----> 1 labels = random_walker(newarray3, markers, beta=10, mode='bf') > C:\Python27\lib\site-packages\skimage\segmentation\random_walker_segmentation.py > c in random_walker(data, labels, beta, mode, tol, copy, multichannel, > return_ful > l_prob, depth) > Ã¯Â¿Â½ Ã¯Â¿Â½ 396 Ã¯Â¿Â½ Ã¯Â¿Â½ if mode == 'bf': > Ã¯Â¿Â½ Ã¯Â¿Â½ 397 Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ X = _solve_bf(lap_sparse, B, > --> 398 Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ return_full_prob=return_full_prob) > Ã¯Â¿Â½ Ã¯Â¿Â½ 399 Ã¯Â¿Â½ Ã¯Â¿Â½ # Clean up results > Ã¯Â¿Â½ Ã¯Â¿Â½ 400 Ã¯Â¿Â½ Ã¯Â¿Â½ if return_full_prob: > C:\Python27\lib\site-packages\skimage\segmentation\random_walker_segmentation.py > c in _solve_bf(lap_sparse, B, return_full_prob) > Ã¯Â¿Â½ Ã¯Â¿Â½ 418 Ã¯Â¿Â½ Ã¯Â¿Â½ """ > Ã¯Â¿Â½ Ã¯Â¿Â½ 419 Ã¯Â¿Â½ Ã¯Â¿Â½ lap_sparse = lap_sparse.tocsc() > --> 420 Ã¯Â¿Â½ Ã¯Â¿Â½ solver = > sparse.linalg.factorized(lap_sparse.astype(np.double)) > Ã¯Â¿Â½ Ã¯Â¿Â½ 421 Ã¯Â¿Â½ Ã¯Â¿Â½ X = np.array([solver(np.array((-B[i]).todense()).ravel())\ > Ã¯Â¿Â½ Ã¯Â¿Â½ 422 Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ for i in range(len(B))]) > C:\Python27\lib\site-packages\scipy\sparse\linalg\dsolve\linsolve.pyc in > factori > zed(A) > Ã¯Â¿Â½ Ã¯Â¿Â½ 274 > Ã¯Â¿Â½ Ã¯Â¿Â½ 275 Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ # Make LU decomposition. > --> 276 Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ umf.numeric( A ) > Ã¯Â¿Â½ Ã¯Â¿Â½ 277 > Ã¯Â¿Â½ Ã¯Â¿Â½ 278 Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ def solve( b ): > C:\Python27\lib\site-packages\scipy\sparse\linalg\dsolve\umfpack\umfpack.pyc > in > numeric(self, mtx) > Ã¯Â¿Â½ Ã¯Â¿Â½ 401 > Ã¯Â¿Â½ Ã¯Â¿Â½ 402 Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ if self._symbolic is None: > --> 403 Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ self.symbolic( mtx ) > Ã¯Â¿Â½ Ã¯Â¿Â½ 404 > Ã¯Â¿Â½ Ã¯Â¿Â½ 405 Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ indx = self._getIndx( mtx ) > C:\Python27\lib\site-packages\scipy\sparse\linalg\dsolve\umfpack\umfpack.pyc > in > symbolic(self, mtx) > Ã¯Â¿Â½ Ã¯Â¿Â½ 384 Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ if status != UMFPACK_OK: > Ã¯Â¿Â½ Ã¯Â¿Â½ 385 Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ raise RuntimeError('%s failed with %s' % > (self.funs.symbolic > , > --> 386 Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ > Ã¯Â¿Â½umfStatus[status] > )) > Ã¯Â¿Â½ Ã¯Â¿Â½ 387 > Ã¯Â¿Â½ Ã¯Â¿Â½ 388 Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ Ã¯Â¿Â½ self.mtx = mtx > RuntimeError: <function umfpack_di_symbolic at 0x000000015E72F9E8> failed > with U > MFPACK_ERROR_out_of_memory > What can I do for that? Just want to test whether this algorithm works for > my thoughts.Ã¯Â¿Â½ > Thanks!Ã¯Â¿Â½

1 0

Re: skimage and opencv
by Stéfan van der Walt 28 Dec '12

28 Dec '12

Hi Francois On Thu, Dec 27, 2012 at 2:06 PM, François <francois.boulogne(a)gmail.com> wrote: > 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? Thanks for your question--it's a good one. There are several reasons for a separate project, some of them already highlighted by Emmanuelle. A few years ago, we had to decide whether we wanted to build on top of OpenCV, and the general consensus was that it is too heavy a dependency. We have three aims with `skimage`: 1. Provide a highly Pythonic interface to building blocks for reproducible image processing reseach 2. Have simple, well-written and clear implementations of common algorithms for use in education 3. Provide tools for solving industry problems efficiently I think OpenCV does number 3 particularly well, while some projects such as SimpleCV take on number 1. But when it comes to education and reproducible research, I believe `skimage` still holds a significant advantage, in terms of the transparency and clarity of the code, as well as the examples provided. `skimage` plays particularly well with the scipy stack of tools, and I find that the pipelining tools (dtype conversion, color space handling, exposure adjustment, etc.) significantly improve my research productivity. Your comments and criticisms are most welcome; we are always keen to hear good feedback! Regards Stéfan

1 0

Re: canvastools subpackage for scikit-image viewer
by Stéfan van der Walt 28 Dec '12

28 Dec '12

Hi Tony On Wed, Dec 26, 2012 at 10:41 PM, Tony Yu <tsyu80(a)gmail.com> wrote: > I just added another tool: A canvas painter. It's a bit less responsive than > I'd like, but I think it's as fast as it'll get (it's limited by > matplotlib's blitting support for images). Check out the watershed demo in > the `viewer_examples/plugins` folder, which uses the paint tool to generate > markers for watershed segmentation. Finally, a path to that FFT filter painter I've had in mind! This is very exciting. By the way, it took me a while to figure out to press "enter" to run the segmentation, so how about printing some instructions to the terminal? Thanks again, Stéfan

1 0

Re: canvastools subpackage for scikit-image viewer
by Tony Yu 27 Dec '12

27 Dec '12

On Sun, Dec 23, 2012 at 3:34 AM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > Tony and Steven, > > On Fri, Dec 14, 2012 at 11:11 AM, Steven Silvester > <steven.silvester(a)gmail.com> wrote: > > Great, I'll dig into your PR this weekend. I was thinking that each > plugin could be registered as a dock window, and be switchable via a View > menu. > > Thanks for working on this--it turns out to be a very powerful > teaching and demonstration tool! > > Cheers > Stéfan > > I'm glad you like it. I just added another tool: A canvas painter. It's a bit less responsive than I'd like, but I think it's as fast as it'll get (it's limited by matplotlib's blitting support for images). Check out the watershed demo in the `viewer_examples/plugins` folder, which uses the paint tool to generate markers for watershed segmentation. Best, -Tony

1 0

Re: Testing
by Stéfan van der Walt 26 Dec '12

26 Dec '12

Hi Vikram On Wed, Dec 26, 2012 at 11:36 AM, Vikram Kamath <vikram.kmth(a)gmail.com> wrote: > The problem I'm having is - I've installed scikit-image and I've also forked > the repo. I've created a branch and I'm tinkering with it. How do I run > tests to ensure that the code, after my modification actually works? First, you need to build the extension modules (type "make" in the repository root). Then, you can add that path to your PYTHONPATH: export PYTHONPATH=$PYTHONPATH:/path/to/skimage Then run "nosetests skimage" or import skimage skimage.test() > Also, is there an IRC channel for scikit-image? . Googling for it doesn't > show any relevant results and joining #scikit-image takes me to an empty > channel. Most of our communication takes place through the mailing list, although you may receive general installation help in #scipy on Freenode. Good luck! Stéfan

1 0

Re: "No definition found"
by Stéfan van der Walt 23 Dec '12

23 Dec '12

On Thu, Nov 29, 2012 at 6:43 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > I'm getting this message when trying to find the definition header for > skimage.segmentation.slic: > > In [12]: %pdef segmentation.slic > No definition header found for segmentation.slic > > In [15]: %pdef segmentation.join_segmentations > segmentation.join_segmentations(s1, s2) > > Anyone know why this is? Is this a general feature of Cython functions? Not sure--but this also shows that IPython does not handle unicode characters in a docstring correctly! Would you like to file a bug report? Stéfan

1 0

Re: canvastools subpackage for scikit-image viewer
by Steven Silvester 23 Dec '12

23 Dec '12

Great, I'll dig into your PR this weekend. I was thinking that each plugin could be registered as a dock window, and be switchable via a View menu.

2 1