Mailman 3 April 2015 - scikit-image

Re: Range of beta values in segmentation algorithm?
by Juan Nunez-Iglesias 04 Apr '15

04 Apr '15

Hi Yuta, Sorry, this slipped through the cracks. I haven't used random walker segmentation so I can't give you advice here... You might want to read the original publication [1], or, more practically, try out different betas on a logarithmic scale. Juan. [1] http://webdocs.cs.ualberta.ca/~nray1/CMPUT615/MRF/grady2006random.pdf On Sat, Apr 4, 2015 at 12:56 AM, Yuta Sato <yutaxsato(a)gmail.com> wrote: > Dear skimage developers: > I would really appreciate to hear the answer on my question if it does > worth. > Thanks > On Thu, Mar 12, 2015 at 4:04 PM, Yuta Sato <yutaxsato(a)gmail.com> wrote: >> In the following skimage.segmentation.random_walker algorithm: >> What is the range of 'beta' values that can be supplied? >> I am working with a single band 8bit unsigned image. >> >> Is it 0 to 255? >> >> >> skimage.segmentation.random_walker(data, labels, beta=130, mode='bf', >> tol=0.001, copy=True,multichannel=False, return_full_prob=False, >> spacing=None) >> >> beta : float [Penalization coefficient for the random walker motion (the >> greater beta, the more difficult the diffusion)] >> >> Thanks for your support. >> > -- > 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/d/optout.

2 1

Re: GSoC: Rewriting scipy.ndimage in Cython
by Ralf Gommers 03 Apr '15

03 Apr '15

On Fri, Mar 27, 2015 at 3:04 PM, Jaime Fernández del Río < jaime.frio(a)gmail.com> wrote: > On Fri, Mar 27, 2015 at 2:27 AM, Ralf Gommers <ralf.gommers(a)gmail.com> > wrote: > >> >> >> On Thu, Mar 26, 2015 at 8:40 PM, AMAN singh <ug201310004(a)iitj.ac.in> >> wrote: >> >>> Thank you everyone for your insightful comments. >>> I have tried to incorporate your suggestion in the proposal. Kindly >>> have a look at the new proposal here >>> <https://docs.google.com/document/d/11RTVaDQDu38mrEv3WPdguxprJ-ha5kGnx2LhpEU…> >>> and suggest the improvements. >>> >> >> Hi Aman, this looks quite good to me. For the timeline I think it will >> take longer to get the iterators right and shorter to port the last >> functions at the end - once you get the hang of it you'll be able to do the >> last ones quickly I expect. >> > > That sounds about right. I think that breaking down the schedule to what > function will be ported what week is little more than wishful thinking, and > that keeping things at the file level would make more sense. But I think > you are getting your proposal there. > > One idea that just crossed my mind: checking your implementation of the > iterators and other stuff in support.c for correctness and performance is > going to be an important part of the project. Perhaps it is a good idea to > identify, either now or very early on the project, a few current ndimage > top level functions that use each of those objects, if possible without > interaction with the others, and build a sequence that could look something > like (I am making this up in a hurry, so don't take the actual function > names proposed too seriously, although they may actually make sense): > > Port NI_PointIterator -> Port NI_CenterOfMass, benchmark and test > Port NI_LineBuffer -> Port NI_UniformFilter1D, benchmark and test > ... > > This would very likely extend the time you will need to implement all the > items in support.c. But by the time you were finished with that we would > both have high confidence that things were going well, plus a "Rosetta > Stone" that should make it a breeze to finish the job, both for you and > anyone else. We would also have an intermediate milestone (everything in > support ported plus a working example of each being used, with correctness > and performance verified), that would be a worthy deliverable on its own: > if we are terribly miscalculating task duration, and everything slips and > is delayed, getting there could still be considered a success, since it > would make finishing the job for others much, much simpler. > That sounds like an excellent idea to me. > One little concern of mine, and the questions don't really go to Aman, but > to the scipy devs: the Cython docs on fused types have a big fat warning at > the top on support still being experimental. Also, this is going to bump > the version requirements for Cython to a very recent one. Are we OK with > this? > We're using fused types in more places in Scipy now. They've been around for a while, and apart from that you have to be careful with using multiple usages of a fused type in a single function (which explodes the generated code and binary size) I don't remember many problems with it. Maybe worth asking the Cython devs why they haven't removed that warning yet? > Similarly, you suggest using Cython's prange to parallelize computations. > I haven't seen OpenMP used anywhere in NumPy or SciPy, and have the feeling > that parallel implementations are left out on purpose. Am I right, or would > parallelizing were possible be OK? > Yep, that has been on purpose so far. That could change of course, but it would need significant discussion and an overall strategy first. OpenMP proposals for individual functions have always been rejected before. So would be better to remove it from this GSoC proposal. Ralf

1 0

Re: Range of beta values in segmentation algorithm?
by Yuta Sato 03 Apr '15

03 Apr '15

Dear skimage developers: I would really appreciate to hear the answer on my question if it does worth. Thanks On Thu, Mar 12, 2015 at 4:04 PM, Yuta Sato <yutaxsato(a)gmail.com> wrote: > In the following skimage.segmentation.random_walker algorithm: > What is the range of 'beta' values that can be supplied? > I am working with a single band 8bit unsigned image. > > Is it 0 to 255? > > > skimage.segmentation.random_walker(data, labels, beta=130, mode='bf', > tol=0.001, copy=True,multichannel=False, return_full_prob=False, > spacing=None) > > beta : float [Penalization coefficient for the random walker motion (the > greater beta, the more difficult the diffusion)] > > Thanks for your support. >

1 0

Re: Apply segmentation to a large binary image
by Juan Nunez-Iglesias 03 Apr '15

03 Apr '15

Hey Yuta, You'll need to do some stitching out-of-core. That's a really tricky problem and I don't have any ready-made solutions for you. The solution will depend on the nature of your segments. The only thing I would recommend is that you use a format such as HDF5 (you can use the excellent h5py library) that allows random access into the underlying disk data. Other than that, as I said, to my knowledge you'll have to develop your own stitching: segment *overlapping* tiles independently in memory, and when it comes time to write to disk, load the tile and overlapping tiles that have already been segmented, and resolve label mapping then... Generally, think of it this way: tile i has already been segmented and written out. We now want to write out tile j, which overlaps tile i. Labels from tile i that intersect labels from tile j in the overlap region should be matched. labels in tile j that *don't* intersect tile i should be relabelled to ensure they are unique with respect to tile i. Of course this gets a bit more complicated in 2D or 3D... Juan. On Fri, Mar 13, 2015 at 7:20 PM, Yuta Sato <yutaxsato(a)gmail.com> wrote: > Dear SKIMAGE Developers and Users: > I want to use the following algorithm in a large binary image that does not > fit into my PC memory. So, I am thinking to split my large image into tiles > and apply algorithm one by one. However, the original border definition > change when I do it in parts. I need the result as applied in original full > image. How can I do it efficiently? > skimage.segmentation.clear_border(image, buffer_size=0, bgval=0) > Thanks for your ideas. > -- > 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/d/optout.

3 3

Re: Automatic formatting of Python code
by Josh Warner 03 Apr '15

03 Apr '15

yapf works fairly well. It still needs some work to be truly PEP8 compliant, especially regarding math expressions, and this is an issue I have with most PEP8 style checkers. This is the actual snippet provided by PEP8 as an example of what not to do: i=i+1 submitted +=1 x = x * 2 - 1 hypot2 = x * x + y * y c = (a + b) * (a - b) which, in a true PEP8 style checker/formatter, should change to i = i + 1 submitted += 1 x = x*2 - 1 hypot2 = x*x + y*y c = (a+b) * (a-b) again, this isn't a contrived example, it's directly from PEP8 <https://www.python.org/dev/peps/pep-0008/>! Yet all style checkers I know of get the first two lines right, then fail on the last three thinking the bad snippet is correct while throwing a fit over the correct (and much more readable) one. yapf does the same. Unfortunately the only real way to correct this in the community is to fix the style checkers. So long as our automated tools throw a fit over the ideal formatting, this behavior is going to get more entrenched. There is a lot of inertia to overcome, but it might be worth bucking the trend. It does essentially require us to teach the checker order of operations. Another part of PEP8 which almost nobody obeys for similar reasons pertains to complicated slicing operations. The following is considered correct, and I know violations of these are littered all over the package. ham[1:9], ham[1:9:3], ham[:9:3], ham[1::3], ham[1:9:] ham[lower:upper], ham[lower:upper:], ham[lower::step] ham[lower+offset : upper+offset] ham[: upper_fn(x) : step_fn(x)], ham[:: step_fn(x)] ham[lower + offset : upper + offset] Food for thought! Josh On Wednesday, April 1, 2015 at 12:56:27 AM UTC-5, stefanv wrote: On Tue, Mar 31, 2015 at 10:18 PM, Juan Nunez-Iglesias wrote: > > From Google, a tool to automatically format your Python code, even > beyond > > what PEP8 prescribes: > > > > https://github.com/google/yapf > > > > I always thought Go's gofmt tool (and convention) were a great asset to > that > > community. It'd be awesome to have the same for Python. > > I think you should run the scikit-image code through YAPF, make pull > requests accordingly, and claim the glory for yourself. > > I'd be happy to review :) > > Stéfan >

1 0

Re: Automatic formatting of Python code
by Stéfan van der Walt 01 Apr '15

01 Apr '15

On Tue, Mar 31, 2015 at 10:18 PM, Juan Nunez-Iglesias <jni.soma(a)gmail.com> wrote: > From Google, a tool to automatically format your Python code, even beyond > what PEP8 prescribes: > > https://github.com/google/yapf > > I always thought Go's gofmt tool (and convention) were a great asset to that > community. It'd be awesome to have the same for Python. I think you should run the scikit-image code through YAPF, make pull requests accordingly, and claim the glory for yourself. I'd be happy to review :) Stéfan

1 0

Automatic formatting of Python code
by Juan Nunez-Iglesias 01 Apr '15

01 Apr '15

>From Google, a tool to automatically format your Python code, even beyond what PEP8 prescribes: https://github.com/google/yapf I always thought Go's gofmt tool (and convention) were a great asset to that community. It'd be awesome to have the same for Python. YAPF is pre-alpha but interesting enough to share now. =) Juan. PS: This is apparently not an April Fool's joke. =P

1 0