Mailman 3 January 2013 - scikit-image

Re: skimage and opencv
by Emmanuelle Gouillart Sept. 22, 2016

Sept. 22, 2016

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 April 26, 2013

April 26, 2013

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: Release plan for 0.8
by Schönberger Johannes Feb. 4, 2013

Feb. 4, 2013

I think we should push the release some days back to fix the majority of these issues. > https://github.com/scikit-image/scikit-image/issues/318 I'll take on this tomorrow. > https://github.com/scikit-image/scikit-image/issues/336 Made the necessary changes today as part of a new PR. > https://github.com/scikit-image/scikit-image/issues/341 I commented on this topic on github. > https://github.com/scikit-image/scikit-image/issues/418 (check relevance) Has been fixed before, so closed.

1 1

Re: Contribution: circles and hough transform
by François Feb. 3, 2013

Feb. 3, 2013

Le mercredi 9 janvier 2013 17:05:53 UTC+1, Stefan van der Walt a écrit : > > > Both patches would be very welcome! Let us know if you need any help > getting started. > > Thank. I discovered in master circle_perimeter(). This is actually the bresenham method. This PR is for Andres method. https://github.com/scikit-image/scikit-image/pull/410 Since bresenham in already in master, I'm working on the hough transform. :) François.

2 2

Re: Displaying video
by Almar Klein Jan. 31, 2013

Jan. 31, 2013

You could do it with OpenGl, although it wouldn't be straightforward. You can also do it in visvis (which uses OpenGl). Here's some untested code that would do this: import visvis as vv vv.clf() # Clear figure (or create a new figure) tex = vv.imshow(first_frame) while video_not_ended: tex.SetData(next_frame) time.sleep(1.0/framerate) vv.processEvents() - Almar On 30 January 2013 22:07, Colin Lea <colincsl(a)gmail.com> wrote: > For a long time now I've kept OpenCV in my vision stack primarily for > displaying videos. I'm trying to get rid of it as a dependence for use on a > secure remote server which I don't have unfettered access to. > > So I'm wondering, how do other people display videos? I see that PyGame is > another option. Does anyone use that? By displaying videos essentially I > just mean showing streams of images (not necessary from a video file). > > If nobody else has a solution other than to use OpenCV, would it be of > interest to implement something (either using PyGame or otherwise) for > skimage? > > > -- > 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+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > >

1 0

removing small connected components
by Juan Nunez-Iglesias Jan. 31, 2013

Jan. 31, 2013

Hi guys, For my own segmentation package, I wrote a small function to remove small connected components in an ndarray. You can see it here: https://github.com/janelia-flyem/gala/blob/master/gala/morpho.py#L72 I've been looking at things that could be moved from there to skimage and I thought that was a prime candidate (I think you actually do the same thing in one of the examples, but without making it into a function). Any interest in a PR? There's other nd operations in there: morphological reconstruction, h-minima, regional (aka local) minima, and impose minima. Let me know if you would like any of these for inclusion in skimage... Thanks, Juan.

1 0

Re: Policy for import of submodules
by Stéfan van der Walt Jan. 30, 2013

Jan. 30, 2013

On Wed, Jan 30, 2013 at 1:37 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > Ok so I'm hearing consensus about what you guys want to do, which is great. > For future reference though, is the intent that second-level packages do > import everything underneath? Currently there don't appear to be more than > two levels, but will that always be true? Yes, we don't want to stack anything more deeply than that. It really is just a means of ensuring that you can import a selected portion of scikit-image without waiting too long, or without loading unnecessary dependencies (e.g., importing the io module will also import gstreamer if available). Also, in the most severe case where one sub-module can't import, you can at least continue working with the rest. Stéfan

1 0

Re: Policy for import of submodules
by Juan Nunez-Iglesias Jan. 30, 2013

Jan. 30, 2013

Ok so I'm hearing consensus about what you guys want to do, which is great. For future reference though, is the intent that second-level packages *do* import everything underneath? Currently there don't appear to be more than two levels, but will that always be true? On Wed, Jan 30, 2013 at 5:13 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > On Wed, Jan 30, 2013 at 11:42 AM, Tony Yu <tsyu80(a)gmail.com> wrote: > >> So my question is, is this behaviour by design, or should there be > nothing > >> at all in the top-level, or should everything be imported? > > > > I tend to agree that it should be one or the other (with the exception of > > the standard metadata at the top-level). > > As Tony mentioned, it's by design from the lessons learnt in NumPy, > aimed at limiting the import time of the library. Because > ``img_as_float``, ``test`` etc. are used so often, we put them in the > root namespace. We have: > > skimage.data_dir skimage.img_as_int skimage.test > skimage.get_log skimage.img_as_ubyte skimage.test_verbose > skimage.img_as_bool skimage.img_as_uint skimage.util > skimage.img_as_float skimage.pkg_dir skimage.version > > Of these, I would keep at least skimage.version, skimage.test, > skimage.test_verbose and skimage.get_log, because they provide > overarching functionality. > > Stéfan > > -- > 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+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > >

1 0

Re: Policy for import of submodules
by Stéfan van der Walt Jan. 30, 2013

Jan. 30, 2013

On Wed, Jan 30, 2013 at 11:42 AM, Tony Yu <tsyu80(a)gmail.com> wrote: >> So my question is, is this behaviour by design, or should there be nothing >> at all in the top-level, or should everything be imported? > > I tend to agree that it should be one or the other (with the exception of > the standard metadata at the top-level). As Tony mentioned, it's by design from the lessons learnt in NumPy, aimed at limiting the import time of the library. Because ``img_as_float``, ``test`` etc. are used so often, we put them in the root namespace. We have: skimage.data_dir skimage.img_as_int skimage.test skimage.get_log skimage.img_as_ubyte skimage.test_verbose skimage.img_as_bool skimage.img_as_uint skimage.util skimage.img_as_float skimage.pkg_dir skimage.version Of these, I would keep at least skimage.version, skimage.test, skimage.test_verbose and skimage.get_log, because they provide overarching functionality. Stéfan

1 0

Re: Policy for import of submodules
by Tony Yu Jan. 30, 2013

Jan. 30, 2013

On Tue, Jan 29, 2013 at 10:05 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com>wrote: > Hi, > > Does scikit-image have a specific policy for how imports should work? For > example, as far as I know, numpy currently imports everything into the np > namespace with: > > import numpy as np > > > However, the following raises an error, even though the import statement > works fine: > > import skimage as skim > coins = skim.data.coins() > > giving the error: > > --------------------------------------------------------------------------- > AttributeError Traceback (most recent call last) > <ipython-input-3-0ce27ef61295> in <module>() > ----> 1 coins = skim.data.coins() > > AttributeError: 'module' object has no attribute 'data' > > > But some things *are* in the top-level namespace. The following works > fine: > > import skimage as skimfrom skimage import data > coins = data.coins() > coins = skim.img_as_float(coins) > > > So my question is, is this behaviour by design, or should there be nothing > at all in the top-level, or should everything be imported? > > I tend to agree that it should be one or the other (with the exception of the standard metadata at the top-level). The argument against importing everything is that it can lead to slow import times (see, numpy for example<http://numpy-discussion.10968.n7.nabble.com/quot-import-numpy-quot-is-slow-…>), even when you're only using a small subset of the package. While this time may not be too severe now, the hope is that scikit-image will grow ever-more functionality, which would slow import times. I'm in favor of moving the functionality out of the top level. I think the only thing that would need to be moved out would be the converters in `skimage.util.dtype`. There should be a shorter path to access those functions, though. Side note: I'm not a huge fan of `util` (I would have thought `utils`), but that's a minor point. And of course, if others agree, this would need to be phased in over time---probably with a couple of releases raising deprecation warnings when trying to access those functions at the top level. Also, this would wait until after the release of 0.8. -Tony

1 0