Mailman 3 November 2017 - scikit-image

my fast watershed has pass all the test_watershed check
by imagepy＠sina.com 01 Dec '17

01 Dec '17

Hi Everyone:I had implemented a watershed by numba, and now it has pass all the test_watershed check and got a exactly same result with skimage, support watershed-line, support connectivity, (pass test 0-12, but mine did not support compact yet) It support nd, now only support uint8 image with uint16 marks. (because I think sometimes it is enough, It can process float image if it is needed) And it is very smart and fast. less than 100 lines, and faster than skimage one. a 3d image which skimage run more than 10 minutes ( and I cannot wait any longer, so kill it), but my watershed just need 28 s. The code are attached. BestYXDragon

2 2

Re: [scikit-image] Benchmark of image processing libraries
by Juan Nunez-Iglesias 27 Nov '17

27 Nov '17

On 27 Nov 2017, 4:48 PM +1100, Stefan van der Walt <stefanv(a)berkeley.edu>, wrote: > > Who will volunteer to set it up? (apprehensively…) ✋

2 1

Re: [scikit-image] Benchmark of image processing libraries
by Juan Nunez-Iglesias 27 Nov '17

27 Nov '17

Hi Sourav, Yes, improving performance is something that’s in the roadmap (this roadmap exists only in the heads of several core developers — something else that needs to be rectified). It just hasn’t been emphasised for lack of developer time. A very specific goal that I’ve had for a while is to set up integration for the project with airspeed velocity. Once we have that, the performance of the library should progressively improve, simply by having performance be a more visible goal. For this, we need a dedicated machine to run benchmarks. Stéfan, do you think you could make/host one at BIDS? Juan. On 19 Nov 2017, 1:15 AM +1100, Sourav Singh <ssouravsingh12(a)gmail.com>, wrote: > Hello, > > I am writing the mail with reference to the tweet made by Jeremy Howard here- https://twitter.com/jeremyphoward/status/931761385628778496 > > Here, he did an image rotation for all the existing image processing libraries in Python and noted that vips is better than scipy in terms of speed. > > I am interested to know if there is anything that could be done regarding the problem. > > > Regards, > > Sourav > _______________________________________________ > scikit-image mailing list > scikit-image(a)python.org > https://mail.python.org/mailman/listinfo/scikit-image

2 1

Re: [scikit-image] Observed difference between skimage.filters.rank.mean and scipy.signal.convolve2d
by Juan Nunez-Iglesias 26 Nov '17

26 Nov '17

On 4 Nov 2017, 3:13 AM +1100, Poughon Victor <Victor.Poughon(a)cnes.fr>, wrote: > Thank you, that makes sense. > Your link does not explain why float images are restricted to [-1; 1] though? So with my data I can't just do: > > image = np.array(data.coins(), dtype=np.float) > > I guess skimage makes an assumption that images are within a fixed range? The short version is that it’s there so that roundtrip conversions work. Suppose you convert a float image to a uint8 image. If you don’t assume a range ([0, 1] for most float images), then you essentially have to map the image range, which could be, say, [0.45, 276.928], to the possible values for uint8, [0, 255]. Then when you convert back, what output range do you use? [0, 10^302]? By assuming a range, you can keep conversions between data types consistent, within rounding error. We are aiming to be more flexible about this, by reducing the dependence on range checking wherever it is not strictly necessary. Many functions have a `preserve_range` keyword that allows you to input images in arbitrary ranges, and you’ll get back an image with no rescaling applied to it. If you come across a function that you think should work without range conversions, let us know. Unfortunately, rank filters don’t fall in this category, because they need to be converted to a 12-bit integer range, so the input range must be known. You can use exposure.rescale_intensity to do conversions manually before and after the rank filters. Hope this helps! Juan.

1 0

Image deconvolution ...
by Jerome Kieffer 23 Nov '17

23 Nov '17

Dear all, I have an image which is "blurred" by a kernel which depends on the position on the image. This blurring can be expressed as a sparse matrix (A) multiplication where only the neighboring pixels have non-null contribution. Ax = b where in addition Aij>=0 x >= 0 #non negativity constrain. b >= 0 # measured signal Does anyone have some hints on where to start looking at ? Thanks for your help -- Jérôme Kieffer

4 6

Benchmark of image processing libraries
by Sourav Singh 18 Nov '17

18 Nov '17

Hello, I am writing the mail with reference to the tweet made by Jeremy Howard here- https://twitter.com/jeremyphoward/status/931761385628778496 Here, he did an image rotation for all the existing image processing libraries in Python and noted that vips is better than scipy in terms of speed. I am interested to know if there is anything that could be done regarding the problem. Regards, Sourav

1 0

Re: [scikit-image] Python 3 transition
by Stefan van der Walt 16 Nov '17

16 Nov '17

On Thu, Nov 16, 2017, at 11:57, Egor Panfilov wrote: > Actually, mid-January | early February sounds OK now. We need some > time to awaken the reviewers, and catch up with the scheduled > issues/PRs. And then, fortunately or not, everyone is having Christmas > and Happy New Year :).> This is the best we can do for now, but (sorry in advance) during the > next year I'll be pushing more to have the releases more frequently > (1/6-9month). :) Thanks for taking charge of this, Egor! The 0.14 milestone is here: https://github.com/scikit-image/scikit-image/milestone/7 Let's start working down that list! Stéfan

1 0

Re: [scikit-image] Python 3 transition
by Egor Panfilov 16 Nov '17

16 Nov '17

Hi all, >I recall this too. =) I'm still in charge! ;) Actually, mid-January | early February sounds OK now. We need some time to awaken the reviewers, and catch up with the scheduled issues/PRs. And then, fortunately or not, everyone is having Christmas and Happy New Year :). This is the best we can do for now, but (sorry in advance) during the next year I'll be pushing more to have the releases more frequently (1/6-9month). :) Regards, Egor 2017-11-15 9:55 GMT+03:00 Stefan van der Walt <stefanv(a)berkeley.edu>: > On Tue, Nov 14, 2017, at 22:41, Juan Nunez-Iglesias wrote: > > I think we can hold off a bit on 0.14: our last release was in > September, and there are a few PRs in the pipeline near completion. > How about we split off the 0.14.x branch beginning of February? > > > Feb! That seems excessive? I don’t think our bug fix backport releases > really count as releases. > > > How about this, then: Egor, give us a date that you'd like to release > (taking into consideration that you'd then need to do the work ;), leaving > at least one month before that to finish pending PRs. > > Stéfan > > > _______________________________________________ > scikit-image mailing list > scikit-image(a)python.org > https://mail.python.org/mailman/listinfo/scikit-image > >

1 0

Re: [scikit-image] Python 3 transition
by Juan Nunez-Iglesias 15 Nov '17

15 Nov '17

Responses inline below. On 13 Nov 2017, 8:31 AM +1100, Stefan van der Walt <stefanv(a)berkeley.edu>, wrote: > It looks like we have general support for the notion to do one more > Python 2.7 release, and to then switch to Python >= 3.5. 🎉 > As far as I recall, Egor volunteered to be release manager---thank you! I recall this too. =) > I think we can hold off a bit on 0.14: our last release was in > September, and there are a few PRs in the pipeline near completion. How about we split off the 0.14.x branch beginning of February? Feb! That seems excessive? I don’t think our bug fix backport releases really count as releases. > Since we're going to be backporting a lot of patches, should I ask > Matthias Bussonier to activate > > https://github.com/MeeseeksBox/MeeseeksDev I’m a fan of this idea.

2 1

Re: [scikit-image] Determine different grass percentage
by K.-Michael Aye 13 Nov '17

13 Nov '17

On Nov 13, 2017, 14:57 -0700, Stefan van der Walt <stefanv(a)berkeley.edu>, wrote: > On Sun, Nov 12, 2017, at 23:18, Dzung Nguyen wrote: > > How about labeling manually a dataset for training, then let machine learning do the rest (of course local binary pattern could be used as feature)? > > You will definitely need some ground truth data; both for training, and for evaluating any system you come up with. > Alternatively, if you are sure you/the human visual cortex can correctly identify it, then you could create your training data set (i.e. the labels) using a Citizen Science project. zooniverse.org has a relatively easy process for setting up a new project. Michael > Stéfan >

2 1