Mailman 3 August 2016 - scikit-image

Re: Interactive image processing in jupyter notebook
by Juan Nunez-Iglesias 30 Aug '16

30 Aug '16

Hi Nadav, Have a look at the filters lesson in github.com/scikit-image/skimage-tutorials. It's not a "real" image processing application, but rather an illustration, but it should be enough of a template for you to modify it. Juan. On 30 Aug 2016, 7:08 PM +1000, Nadav Horesh <nadavh.horesh(a)gmail.com>, wrote: > > I am trying to find a *working* notebook showing interactive image processing using ipywidget "interact" function. I found only an outdated notebook "Image Processing with skimage". > Is there an example I can really use? > > > Nadav > > > > > -- > 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 (mailto:scikit-image+unsubscribe@googlegroups.com). > To post to this group, send email to scikit-image(a)googlegroups.com (mailto:scikit-image@googlegroups.com). > To view this discussion on the web, visit https://groups.google.com/d/msgid/scikit-image/CA%2BoBP_vBxk4HgbgWLdq_RxXu3… (https://groups.google.com/d/msgid/scikit-image/CA%2BoBP_vBxk4HgbgWLdq_RxXu3…). > For more options, visit https://groups.google.com/d/optout.

2 1

Re: IHC Image color deconvolution
by Stefan van der Walt 30 Aug '16

30 Aug '16

On Tue, Aug 30, 2016, at 00:56, Koundinya Desiraju wrote: > Thank you Cedric. That helped a lot. Would you like to add this to the gallery example, so that other users can do the same? Stéfan

1 0

Interactive image processing in jupyter notebook
by Nadav Horesh 30 Aug '16

30 Aug '16

I am trying to find a *working* notebook showing interactive image processing using ipywidget "interact" function. I found only an outdated notebook "Image Processing with skimage". Is there an example I can really use? Nadav

1 0

Re: Image edge detection
by Dipankar “Dipu” Ganguly 30 Aug '16

30 Aug '16

Hi: I have ImageJ installed on the same Mac that I am using to develop IPython Image Processing algorithms under Anaconda Navigator’s Jupyter. Can I load ImageJ as a package in my Image Processing environment and call its functions as I do with Scikit-image? Thanks Dipu Dipankar “Dipu” Ganguly dipugee(a)gmail.com Cell: 408-203-8814 > On Aug 8, 2016, at 5:24 PM, Stéfan van der Walt <stefanv(a)berkeley.edu> wrote: > > Hi Dipu > > Please try one of the examples from the gallery: > > http://scikit-image.org/docs/dev/auto_examples/ <http://scikit-image.org/docs/dev/auto_examples/> > > Stéfan > > On 8 August 2016 at 17:09, Dipankar Ganguly <dipugee(a)gmail.com <mailto:dipugee@gmail.com>> wrote: > I am trying to do an image edge detection project using Python 3.5 under Jupyter on Anaconda's Navigator on my Mac running OS 10.11.6. I have verified that the Envirnoment does have scikit-image installed I have run into this at the very outset. > > _________________ > File "<ipython-input-8-59ade0051fc5>", line 1 > import scikit-image as image > ^ > SyntaxError: invalid syntax > __________________ > > How do I solve this? Is there a more recent package I should be using? > > Thanks. > > Dipu > > > > -- > 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 <mailto:scikit-image+unsubscribe@googlegroups.com>. > To post to this group, send email to scikit-image(a)googlegroups.com <mailto:scikit-image@googlegroups.com>. > To view this discussion on the web, visit https://groups.google.com/d/msgid/scikit-image/476b29f9-0e89-495d-aaee-88a9… <https://groups.google.com/d/msgid/scikit-image/476b29f9-0e89-495d-aaee-88a9…>. > For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to a topic in the Google Groups "scikit-image" group. > To unsubscribe from this topic, visit https://groups.google.com/d/topic/scikit-image/7IskXgM-99E/unsubscribe <https://groups.google.com/d/topic/scikit-image/7IskXgM-99E/unsubscribe>. > To unsubscribe from this group and all its topics, send an email to scikit-image+unsubscribe(a)googlegroups.com <mailto:scikit-image+unsubscribe@googlegroups.com>. > To post to this group, send email to scikit-image(a)googlegroups.com <mailto:scikit-image@googlegroups.com>. > To view this discussion on the web, visit https://groups.google.com/d/msgid/scikit-image/CABDkGQ%3D-HOcA1Xoxxfp8H%2Bo… <https://groups.google.com/d/msgid/scikit-image/CABDkGQ%3D-HOcA1Xoxxfp8H%2Bo…>. > For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

1 0

Management of PRs, issues, and threads
by Juan Nunez-Iglesias 22 Aug '16

22 Aug '16

Hi everyone, We've had a couple of community fails on GitHub recently: https://github.com/scikit-image/scikit-image/pull/1474#issuecomment-2412830… https://github.com/scikit-image/scikit-image/issues/2080 (The last one is missing a presumably-deleted comment where someone outside the project recommended to a potential contributor to just fork the project!). That's just the couple I've noticed, I'm sure there are lots more. We definitely have many, many abandoned PRs from >1y, >2y ago. Obviously, something in our process isn't working. I don't have immediate solutions, but here's a couple of suggestions: - we need a system to assign core devs to PRs/issues. Currently, it's too easy for all of us to go, "someone else on the team will handle this". We need a fair way to assign a manager to each issue/PR. The assigned dev wouldn't necessarily be responsible for review, but they would be responsible for chasing up other reviewers. - NEVER close a PR without the explicit consent of the contributor, OR after the contributor has been non-responsive for e.g. 1mo and two pings. In this last situation I would even suggest that we need two core devs to sign off. Other suggestions welcome in this thread. We should try to get a new process hammered out very soon. I also want to acknowledge @soupault for his triage/labelling work, which is a massive step in the right direction. But we need to follow up his triage with some actual process. Juan.

1 0

Next sprint?
by François Boulogne 20 Aug '16

20 Aug '16

Hi, I'm wondering if there is a sprint schedule during euroscipy. It seems that it didn't really happen last time in the US. I think it would be a good occasion to review PR. We have several PR waiting for reviews and bugs waiting for decisions... it tends to grow :) Best. -- François Boulogne. http://www.sciunto.org GPG: 32D5F22F

2 2

Matlab Equlilavent Functions
by KRISHNAMOOORTHY P 18 Aug '16

18 Aug '16

Is there a Python Equivalent Functions for following matlab functions - strel - imdilate - imclose - bwmorph - bwareaopen

2 2

Re: Migration to Python 3.x
by Johannes Schönberger 12 Aug '16

12 Aug '16

As stated earlier, a big -1 from my side on moving to all Python 3.x for 0.14 already. Not because I personally don't think it provides some benefits, but let me explain: I don't see enough of a benefit of replacing a few np.dot's with the @ syntax or pure keyword based arguments for the few functions we add/change in one version jump. It doesn't make the code faster, more correct or more feature complete. The API will look and work the same from a users perspective from 2.7-3.5. Required features (which are usually rare) from newer numpy/scipy versions can be handled easily inside the respective functions with an exception. In my experience, many of the scikit-image users I know are actually less knowledgable about how to setup a new Python environment from scratch. And it seems the latest Ubuntu is still on 3.4 and Mac also doesn't ship with 3.5 - which leaves out the @ syntax anyway. Also, many of the cluster users are still stuck on 2.x for quite a while. I think, we will lose a significant amount of users without a real benefit. I don't see a compelling reason to lock out X% of users at this point. I can only judge by the feedback in this thread, but 3 out of 5 people seem to have problems with the proposed way forward. It would be nice if there was some way of obtaining installation statistics from PyPI or Anaconda to get a better picture here. The real benefit comes with 3.5, hence I propose to follow the current model to support 2.7-3.x and reevaluate the situation for 0.15. Eventually, 3.5 will be more widespread and in the meantime we do not really sacrifice anything on our side. Doing a find/replace on np.dot/__future__ will work in a year just as fine as it does now. Best, Johannes > On 10 Aug 2016, at 05:17, Nelle Varoquaux <nelle.varoquaux(a)gmail.com> wrote: > >> On 9 August 2016 at 19:54, Ralf Gommers <ralf.gommers(a)gmail.com> wrote: >> >> >> On Wed, Aug 10, 2016 at 2:46 PM, Nelle Varoquaux <nelle.varoquaux(a)gmail.com> >> wrote: >>> >>>> On 9 August 2016 at 19:17, Ralf Gommers <ralf.gommers(a)gmail.com> wrote: >>>> >>>> >>>> On Wed, Aug 10, 2016 at 1:55 PM, Nelle Varoquaux >>>> <nelle.varoquaux(a)gmail.com> >>>> wrote: >>>>> >>>>> On 9 August 2016 at 17:28, Juan Nunez-Iglesias <jni.soma(a)gmail.com> >>>>> wrote: >>>>>> @Emmanuelle I'm probably among the ones pushing hardest for this, and >>>>>> I >>>>>> can >>>>>> tell you, I can't wait for this change in policy, and would be sorely >>>>>> disappointed by having to work in an experimental branch of >>>>>> scikit-image. >>>>>> Both @-matmul and keyword-only arguments are, imho, compelling >>>>>> reasons >>>>>> to >>>>>> switch. (Imagine the amount of fiddling with the API that we could do >>>>>> with >>>>>> keyword-only arguments, without the annoying deprecation cycle!) >>>>>> >>>>>> @Ralf I would argue in favour of 3.5, for the above reasons and >>>>>> because >>>>>> anyone who had the temerity to update to 3.4 is very likely to >>>>>> subsequently >>>>>> move to 3.5. (Self-selected group of early adopters, plus no >>>>>> backwards >>>>>> incompatibility issues between the two versions.) >>>> >>>> >>>> I agree with this argument, I was just asking to clarify. @ is at least >>>> something interesting that's specifically added for scientific users, so >>>> imho 3.5 is the first 3.x release where in some cases the benefits may >>>> start >>>> to be worth the costs. >>>> >>>>> >>>>> That implies that even ubuntu users will have to install python from >>>>> another source than the package manager. Do you really want this? That >>>>> means that only fairly advance python users will be able to use the >>>>> latest scikit-image release. >>>> >>>> >>>> In the grand scheme of things, does Ubuntu matter much for this >>>> decision? >>>> There are way more Windows and OS X users, so if it's OK for them (which >>>> is >>>> not a given) then it should also be OK for those fewer and on average >>>> more >>>> computer-literate Ubuntu users. >>> >>> I don't have a good overview of what OS people are using, but in the >>> different research facilities I've worked or visited, it was always >>> linux based, and users where not really tech-savy. I checked on all of >>> the servers (UW's genome science, the Curie institute, UC Berkeley's >>> stats department, the Mines' machine learning computing facilities.) I >>> have access to, none have python3.5. Some of these servers are >>> "offline", thus conda is useless. All of these research institutes >>> have teams that use in some way image processing. >>> >>> I'll just also mentionned that we had a keynote at scipy this year >>> mentionning she was using python because she just did not have the >>> time anymore to code in C++ and Java. These are the kind of people >>> that may be using scikit-image, that may be interested in the latest >>> version of the package, and yet just not have the time to compile >>> python3.5 from scratch on an outdated server. >> >> >> Fair enough, but there are likely much more outdated servers with Python 2.7 >> than with Python 3.4 on them ..... > > Well… I think it is better to keep python2.7 support :) > All the clusters I have access to but 1 has python3. The oldest one is > a red hat based cluster with python2.6 (which was python2.3 not so > long ago). > > N > >> >> Ralf >> >> -- >> 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. >> To post to this group, send email to scikit-image(a)googlegroups.com. >> To view this discussion on the web, visit >> https://groups.google.com/d/msgid/scikit-image/CABL7CQjye5g5jppRk1hej2g2P3V…. >> >> For more options, visit https://groups.google.com/d/optout. > > -- > 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. > To post to this group, send an email to scikit-image(a)googlegroups.com. > To view this discussion on the web, visit https://groups.google.com/d/msgid/scikit-image/CAE-UAvT0C5z0jg84oDW0MtTiFko…. > For more options, visit https://groups.google.com/d/optout.

4 3

Translating Multi-Otsu Threshold from java
by Alexandre Fioravante de Siqueira 11 Aug '16

11 Aug '16

Hi everyone, I was thinking about using multi-Otsu thresholding for some research. I am used to use the ImageJ available plugin, http://imagej.net/Multi_Otsu_Threshold. Could you give me a hand on writing such a function which could do this for python? Maybe putting it into scikit-image. Or else, could you point me a better alternative? Thank you very much! Alex

2 5

Re: Migration to Python 3.x
by Juan Nunez-Iglesias 11 Aug '16

11 Aug '16

Hi everyone, First of all, I excitedly jumped on the bandwagon because Stefan mentioned 0.13, but I actually even I considered that a bit early for dropping Py2 when I read it. =) I would say that the right time to drop Py2 is either 0.15 or 1.0, and that we should follow a standard deprecation cycle. What this means is some warning (on the home page, or on installation, for example) that as of version <foo>.<bar>, scikit-image will be Python 3-only, with the previous release being an LTS release with Python 2 support. An important corollary to this thread is signing the Python 3 statement <https://python3statement.github.io/>, which pledges dropping Python 2 support by **2020**. We can commit to a longer timeline than envisioned by Stéfan's initial proposal, but I would like to commit to a timeline, because I think having the scikit-image logo on that page would definitely add momentum to the transition. Which it (cough) clearly needs. As Stéfan has noted, Ubuntu users haven't had 0.12 in the package manager in ages and the sky hasn't fallen. A long-term support release is *not* the same as abandoning our users. I would find it much less burdensome to backport certain bug fixes and critical features to 0.13.25 (or whatever) than to keep supporting 2.7 ad infinitum. The deprecation cycle in particular just bugs the hell out of me. About the benefits of switching, Johannes, although you argue that Python3 doesn't make the code "more correct", this is not strictly the case: keyword-only arguments, better readability (with @), and typing, *all* make it easier to avoid bugs. You can hardly claim that skimage is bug-free. I'll note that in my own project, gala, a user discovered a monster bug that will result in me issuing a correction to the paper: https://github.com/janelia-flyem/gala/issues/63 Both typing and keyword-only arguments would have prevented this bug. Emma, thank you so much for those statistics. They are so valuable. =) I agree *a lot* about outreach + docs, and growing our user base. But I think all those efforts should focus on Python 3 anyway. So anyway, I hope I've added some fuel to the fire with my bug disaster, above. =) And I hope we can agree on a timeline, even if the timeline is not quite as aggressive as Jupyter's or Stéfan's original proposal. Thanks all! Juan. On Thu, Aug 11, 2016 at 8:24 AM, Stéfan van der Walt <stefanv(a)berkeley.edu> wrote: > On 10 August 2016 at 01:03, Emmanuelle Gouillart < > emmanuelle.gouillart(a)nsup.org> wrote: > >> I completely agree that it would be great to obtain statistics about >> who uses Python 2.7 or 3.x but I can't see an easy way to do it. Could we >> have a button on the website linking to a small form asking whether >> people are using Python 2.7 or 3.x? Maybe it has already been mentioned >> on the mailing-list. >> > > I'll work on getting hold of some statistics from PyPA. > > >> 2) so, to estimate when the change should happen (0.14, 0.15?), we need >> to evaluate the "economics" of such a decision. How many users are going >> to be impacted? How much development time are we losing by not switching >> right now? How do we balance these two factors (or others)? >> > > I don't think the developer cost is very high right now. I wanted to test > the waters a bit and see how the rest of the team felt, but I think there > are enough compelling arguments to stick to 2.7-compatibility for now. We > can always revisit the issue again a year or so from now, when the > landscape might have changed. > > Thanks for all the feedback! > > 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. > To post to this group, send email to scikit-image(a)googlegroups.com. > To view this discussion on the web, visit https://groups.google.com/d/ > msgid/scikit-image/CABDkGQ%3DEzzSY1j9qy%2BD3VkzVP4zeHknBrqkBZ%3D9m7Q_ > H4qSvCA%40mail.gmail.com > <https://groups.google.com/d/msgid/scikit-image/CABDkGQ%3DEzzSY1j9qy%2BD3Vkz…> > . > > For more options, visit https://groups.google.com/d/optout. >

1 0