Mailman 3 April 2013 - scikit-image

Re: functions of ndimage
by Johannes Schönberger 24 Apr '13

24 Apr '13

>> If this were to be implemented, would our policy then be to use relative imports for the wrapped versions of these functions internally, rather than importing from SciPy? > I hadn't considered this but it makes a lot of sense, as it potentially slowly decouples scikit-image from its scipy dependency. +1 Overall also +1, I think it is a good idea to provide all functions through scikit-image!

1 0

Re: functions of ndimage
by Josh Warner 24 Apr '13

24 Apr '13

I agree with wrappers, ideally with minimal changes to SciPy's API. Of course this means that if SciPy changes their API or re-implements something (like the change of `scipy.ndimage.label` coming in 0.13), we encounter problems... but in general this saves us from needing to reinvent and maintain the wheel. If this were to be implemented, would our policy then be to use relative imports for the wrapped versions of these functions internally, rather than importing from SciPy? On Tuesday, April 23, 2013 11:29:01 PM UTC-5, Juan Nunez-Iglesias wrote: > > I'm in the middle on this: I would suggest importing the relevant ndimage > functions into the skimage namespace, but not touching the API, except > perhaps in extremely egregious cases. Just as the lack of a Gaussian filter > might confuse beginners, two divergent APIs will confuse advanced users. > > > On Wed, Apr 24, 2013 at 11:41 AM, abid rahman <abidr...(a)gmail.com<javascript:> > > wrote: > >> Hi, >> >> Isn't it a bad idea that for some functions we should go for scipy, for >> some other functions we go for skimage. Actually what I felt from >> user-point-of-view is to decrease maximum dependency in the project. So it >> is always better to bring all image processing stuffs in python under one >> library. Installation of one library should serve all our purpose. >> >> Abid K. >> opencvpython.blogspot.com >> >> >> On Wed, Apr 24, 2013 at 3:49 AM, Stéfan van der Walt <ste...(a)sun.ac.za<javascript:> >> > wrote: >> >>> On Tue, Apr 23, 2013 at 11:49 PM, Emmanuelle Gouillart >>> <emmanuelle...(a)nsup.org <javascript:>> wrote: >>> > I can see only a small number of scipy.ndimage functions that >>> are >>> > concerned, like gaussian_filter, distance_transform_edt, >>> > binary_fill_holes, but I now think that it'd be worth having a wrapper >>> > for these functions in skimage, for the sake of users not well aware of >>> > scipy.ndimage. We already depend on scipy anyway. >>> >>> I'd be happy to put wrappers to those functions in skimage, as long as >>> we do a thorough review of the API of each. That turns out to be one >>> of skimage's strongest benefits, and we shouldn't rely on ndimage to >>> have considered it very carefully. I think it would help if we had >>> some practical use cases of each of these, to guide us in the right >>> direction. >>> >>> But yes, I can see how this would confuse beginners... >>> >>> 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...(a)googlegroups.com <javascript:>. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> -- >> 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 1

Re: functions of ndimage
by Juan Nunez-Iglesias 23 Apr '13

23 Apr '13

I'm in the middle on this: I would suggest importing the relevant ndimage functions into the skimage namespace, but not touching the API, except perhaps in extremely egregious cases. Just as the lack of a Gaussian filter might confuse beginners, two divergent APIs will confuse advanced users. On Wed, Apr 24, 2013 at 11:41 AM, abid rahman <abidrahman2(a)gmail.com> wrote: > Hi, > > Isn't it a bad idea that for some functions we should go for scipy, for > some other functions we go for skimage. Actually what I felt from > user-point-of-view is to decrease maximum dependency in the project. So it > is always better to bring all image processing stuffs in python under one > library. Installation of one library should serve all our purpose. > > Abid K. > opencvpython.blogspot.com > > > On Wed, Apr 24, 2013 at 3:49 AM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > >> On Tue, Apr 23, 2013 at 11:49 PM, Emmanuelle Gouillart >> <emmanuelle.gouillart(a)nsup.org> wrote: >> > I can see only a small number of scipy.ndimage functions that >> are >> > concerned, like gaussian_filter, distance_transform_edt, >> > binary_fill_holes, but I now think that it'd be worth having a wrapper >> > for these functions in skimage, for the sake of users not well aware of >> > scipy.ndimage. We already depend on scipy anyway. >> >> I'd be happy to put wrappers to those functions in skimage, as long as >> we do a thorough review of the API of each. That turns out to be one >> of skimage's strongest benefits, and we shouldn't rely on ndimage to >> have considered it very carefully. I think it would help if we had >> some practical use cases of each of these, to guide us in the right >> direction. >> >> But yes, I can see how this would confuse beginners... >> >> 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. >> >> >> > -- > 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: functions of ndimage
by abid rahman 23 Apr '13

23 Apr '13

Hi, Isn't it a bad idea that for some functions we should go for scipy, for some other functions we go for skimage. Actually what I felt from user-point-of-view is to decrease maximum dependency in the project. So it is always better to bring all image processing stuffs in python under one library. Installation of one library should serve all our purpose. Abid K. opencvpython.blogspot.com On Wed, Apr 24, 2013 at 3:49 AM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > On Tue, Apr 23, 2013 at 11:49 PM, Emmanuelle Gouillart > <emmanuelle.gouillart(a)nsup.org> wrote: > > I can see only a small number of scipy.ndimage functions that are > > concerned, like gaussian_filter, distance_transform_edt, > > binary_fill_holes, but I now think that it'd be worth having a wrapper > > for these functions in skimage, for the sake of users not well aware of > > scipy.ndimage. We already depend on scipy anyway. > > I'd be happy to put wrappers to those functions in skimage, as long as > we do a thorough review of the API of each. That turns out to be one > of skimage's strongest benefits, and we shouldn't rely on ndimage to > have considered it very carefully. I think it would help if we had > some practical use cases of each of these, to guide us in the right > direction. > > But yes, I can see how this would confuse beginners... > > 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

functions of ndimage
by Emmanuelle Gouillart 23 Apr '13

23 Apr '13

Dear all, a while ago, a PR from Riaan van den Dool proposed to have a Gaussian filter in scikit-image. At this time, I remember that I felt that it was not necessary to have a Gaussian filter in the scikit-image, since there is already one in scipy.ndimage. Many people shared this opinion, and the PR was turned down. However, I have gradually changed my opinion on this matter, and I would like to know what the other developers and users think. I've recently given a tutorial / practical session on scikit-image to an audience of Python beginners (undergraduate teachers who will have to teach Python next year, since Python is now part of the French syllabus for undergraduate scientific studies). And it was very puzzling to them that some functions, such as the Gaussian filter, were not to be found in skimage, but in scipy.ndimage. They had no problem understanding that generic low-level arrays routines were in numpy, and specialized image processing functions in skimage, but they felt like scipy.ndimage was an unnecessary complication! Of course, these users are not representative of all skimage's users, but since Python is getting more and more popular in science, we'll have more and more users who'll prefer finding all high-level image processing functions under skimage's umbrella. I can see only a small number of scipy.ndimage functions that are concerned, like gaussian_filter, distance_transform_edt, binary_fill_holes, but I now think that it'd be worth having a wrapper for these functions in skimage, for the sake of users not well aware of scipy.ndimage. We already depend on scipy anyway. What do you think? Cheers, Emmanuelle

2 1

Re: Describing superpixels
by Stéfan van der Walt 23 Apr '13

23 Apr '13

On Tue, Apr 23, 2013 at 2:42 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > Got it. Slightly more space, slightly faster. I imagine you stored repeated > row indices if the object was not convex? > >> Perhaps it will be a bit painful to extend to N-d, but it is doable. You don't even need to. Have a look at section 3.1 of https://scholar.sun.ac.za/handle/10019.1/4883 Either way, I'm not sure I like how this generalized to N-d space--I'd rather work with a graph. So, when it comes down to that, it looks like we have two choices: implement a memory efficient and slightly more computationally expensive implementation, or simply pre-calculate all the neighbor indices and store that. Hrm, that reminds me of the solution we used for ImageCollection--let's just set a memory_efficient flag. If True, we only store the last flood fill result, if False, we store all flood fill results as they are computed. Easy to implement, and gives the user control of memory growth. What do you think? Stéfan

1 0

Re: Describing superpixels
by Stéfan van der Walt 23 Apr '13

23 Apr '13

On Tue, Apr 23, 2013 at 2:42 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > I actually don't understand this at all, but it sounds really interesting. > It seems to me like you can only represent chain topologies, but that would > make no sense? Could you elaborate? I think you are right--so we can disregard that idea.

1 0

Re: Describing superpixels
by Brickle Macho 23 Apr '13

23 Apr '13

On 23/04/13 8:42 PM, Juan Nunez-Iglesias wrote: > This is a whole big can of worms! It really depends on what you're > doing later. For example, do you want to do this hierarchically? Or do > you want to do it in one shot? One shot is simplest: for each edge, > keep a score, something like Pr(join(u, v)). Then, threshold this > graph, ie, throw away all the edges where your probability is lower > than some value. Finally, do a connected components search, and > iterate over all superpixels as follows: I think I understand what you are getting at when you say "keep a score". What you mean "hierarchically" ? Obviously I do some background reading on graph theory so I can understand how to threshold a graph a graph etc. I will doo that later tonight. Once superpixels are combined, I have no need for the graph. I was planning to compare each adjacent superpixel (i.e. each edge) and update a new segment mask as I go. But I have a few problems. Say S1 and S2 are joined. Later I compare S2 and S5 need need to be joined, I need to keep track the S2 has already be relabeled. I think I will need multiple passes, which implies new graph for each pass and repeat until no joins detected. Assuing it would work, it doesn't seem very efficient. I suspect this process to combine vertices in a graph already exists in a graph library so will investigate existing libraries. Thanks again for the ideas. Michael. --

1 0

Re: Describing superpixels
by Brickle Macho 23 Apr '13

23 Apr '13

Thanks everyone for the advice and tips. I am getting closer to a solution. The (obvious) plan is for each edge find neighbouring regions, use segment_mask to extract indices into the depth map and calculate depth features (average depth, surface normals etc) and then combine segments based on these feature(s). Some of the advice in the replies, suggest using a graph package and having some way to directly access the pixels of each super-pixel with some interesting ideas provided. Being a little naive I was hoping to have a simple set of edges to traverse. I found a Peekaboo blog entry: http://peekaboo-vision.blogspot.com.au/2011/08/region-connectivity-graphs-i… Which takes a segment mask/array and creates a set of vertices and edges representing the region connectivity graph. This looks like it might be sufficient. Am I being too naive? Should I just learn/use a graph package? Also, any advice/gotchas on how to join/combine segments? There seems to be a few join/relabel functions in the library. Thanks again, Michael. -- On 22/04/13 8:32 PM, StÃ¯Â¿Â½fan van der Walt wrote: > On Mon, Apr 22, 2013 at 11:55 AM, Juan Nunez-Iglesias > <jni.soma(a)gmail.com> wrote: >> It's very convenient to have direct access back to the pixels/voxels making >> up each superpixel. Therefore, I stored on each node an array containing all >> the linear indices into the `ravel`ed version of the image. This is pretty >> expensive, though, so if could do it over, I would store the index of a >> single pixel belonging to that superpixel and pair it with a flood fill >> algorithm, so that a function `g.get_pixel_indices(superpixel_id)` would >> transparently return the pixel list, but in O(superpixel_size) time while >> only using up a singe int of space. > Thanks for sharing that good advice. Juan. There is also an > intermediary storage format, one that I used before with some success. > Think of a 2-D example: you store the start and end indices of each > column that comprises the object, paired with an index into the rows > (very similar to CSR). Perhaps it will be a bit painful to extend to > N-d, but it is doable. > > Another option is to store a graph in an array. This goes along very > well with the implementation of ``graph.label``. At each position in > the array, you store the index of the previous pixel to which it is > connected. For any super-pixel, you can then store only the last > pixel, and traverse indices backward to get the entire super-pixel. > Con: 2 x storage. > >> Related note: does skimage have an nd implementation of flood fill? > I think one of the recent PRs made an attempt at a 2D version called > ``connected_component``, but otherwise no. > > StÃ¯Â¿Â½fan >

3 2

Re: Describing superpixels
by Chintak Sheth 23 Apr '13

23 Apr '13

@stefanv Yes, I'm reading up on some material by which I could have a better and more memory efficient algorithm for flood fill. I'm definitely interested in this. On Mon, Apr 22, 2013 at 6:02 PM, Stéfan van der Walt <stefan(a)sun.ac.za>wrote: > On Mon, Apr 22, 2013 at 11:55 AM, Juan Nunez-Iglesias > <jni.soma(a)gmail.com> wrote: > > It's very convenient to have direct access back to the pixels/voxels > making > > up each superpixel. Therefore, I stored on each node an array containing > all > > the linear indices into the `ravel`ed version of the image. This is > pretty > > expensive, though, so if could do it over, I would store the index of a > > single pixel belonging to that superpixel and pair it with a flood fill > > algorithm, so that a function `g.get_pixel_indices(superpixel_id)` would > > transparently return the pixel list, but in O(superpixel_size) time while > > only using up a singe int of space. > > Thanks for sharing that good advice. Juan. There is also an > intermediary storage format, one that I used before with some success. > Think of a 2-D example: you store the start and end indices of each > column that comprises the object, paired with an index into the rows > (very similar to CSR). Perhaps it will be a bit painful to extend to > N-d, but it is doable. > > Another option is to store a graph in an array. This goes along very > well with the implementation of ``graph.label``. At each position in > the array, you store the index of the previous pixel to which it is > connected. For any super-pixel, you can then store only the last > pixel, and traverse indices backward to get the entire super-pixel. > Con: 2 x storage. > > > Related note: does skimage have an nd implementation of flood fill? > > I think one of the recent PRs made an attempt at a 2D version called > ``connected_component``, but otherwise no. > > 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