Mailman 3 August 2016 - scikit-image

Re: skimage and opencv
by Emmanuelle Gouillart 22 Sep '16

22 Sep '16

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

Task board
by Stefan van der Walt 14 Sep '16

14 Sep '16

Hi, everyone As Juan mentioned recently, it's becoming harder to keep track of the motion of the project as a whole. Sometimes, tickets lounge unattended for an unacceptable long time. I can think of two main routes for improving the situation: 1) Improve our team structure, so that individuals take responsibility for moving certain aspects of the project forward. 2) Processes / systems to help us get a grasp on the current state of things I have some ideas around (1) that need fleshing out, but in the mean time I was looking at http://zube.io to address part of (2). Do you have any experience with this system? Zube can be compared against HuBoard, gh-board, and ZenHub. A test scikit-image board is here: https://zube.io/projects/4670/kanban (it's vanilla, I haven't done anything with it yet) Let me hear your thoughts. Stéfan

3 5

Re: Management of PRs, issues, and threads
by Emmanuelle Gouillart 10 Sep '16

10 Sep '16

Hi Juan, thanks for bringing these issues to light. How about we tackle the queue of open PRs from its two ends? That is, for the new PRs we have this manager system (we still need to decide how to assign them), and at the same time we go through old PRs to try to unblock or (worst case) close them? Best, Emma On Mon, Aug 22, 2016 at 02:47:16PM +1000, Juan Nunez-Iglesias wrote: > 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.

3 2

Distance Estimation
by Chris Spencer 31 Aug '16

31 Aug '16

Hi, Can scikit-image be used for supervised learning? I have training data, where each sample is composed of a raw RGB image, a black-and-white image mask showing the laser projection onto the image, and the laser range finder distance measurements in millimetres. Is there any algorithm in scikit-image that I could use to train a predictor that could estimate the distance at each pixel in an image? I've gone through all the examples, and none of them seemed to directly apply. The image segmentation example seemed to be the closest, but that didn't use supervised learning, so I wasn't sure how I could adapt it's code. Can this goal be accomplished with sckit-image? If not, is there another library and algorithm you could recommend? Regards, Chris

2 2

IHC Image color deconvolution
by Koundinya Desiraju 31 Aug '16

31 Aug '16

In this tutorial, http://scikit-image.org/docs/dev/auto_examples/color_exposure/plot_ihc_colo… After color deconvolution the haematoxylin and DAB channels were plotted in grayscale but I want to show them in respective colors. For example, I want to show DAB channel in brown. Can anyone kindly post How to do that? Thanks, Koundinya

4 4

Re: Migration of mailing list to @python.org
by Jaime Lopez Carvajal 31 Aug '16

31 Aug '16

Hi Stefan, I know you must be working on several topics at same time, I wish to have your commitment. Best wishes, Jaime On Wednesday, August 31, 2016 at 4:52:31 PM UTC-5, stefanv wrote: > > Hi Jaime > > On Wed, Aug 31, 2016, at 14:02, Jaime Lopez Carvajal wrote: > > Do you have a possible date when you are going to activate the scikit- > image version on mailman python? > > Because I check it and it is currently empty. > > BTW, I dont have any rush, I just want to know. > > Thanks for the reminder---I'll proceed to back up the Google Groups to > that archive, and then switch everyone over. > > Stéfan >

1 0

Re: Fwd: PyData Community Cookbook - August Update
by Alexandre Fioravante de Siqueira 31 Aug '16

31 Aug '16

Dear all, have you figured it out? The deadline is tomorrow, and I would really like to participate. Thanks! Alex Em quarta-feira, 31 de agosto de 2016 15:37:06 UTC+2, Egor Panfilov escreveu: > > Sounds interesting, and I'd be glad to contribute. Although, it is not > clear what kind of content do authors expect. I believe that the vast > majority of `skimage` functionality is already well-described in the > documentation and conference notebooks. > If someone of `skimage` original authors could prepare a draft of the > planned chapter (i.e. table of contents), I think it would be quite easy to > make it happen soon and in the best possible way. > > Regards, > Egor > > 2016-08-30 22:22 GMT+03:00 Emmanuelle Gouillart: > >> Probably we would not include the chapter as published on the website, >> the idea would be more to take some of the materials for the user guide. >> >> On Tue, Aug 30, 2016 at 10:06:42AM -0700, Stefan van der Walt wrote: >> > On Mon, Aug 29, 2016, at 13:44, Emmanuelle Gouillart wrote: >> > > is it something that we could re-use for the documentation of >> > > scikit-image, in the user guide for example? >> >> > Good question! Let's ask Andy (on CC). >> >> > Stéfan >> > >

2 1

Re: Migration of mailing list to @python.org
by Jaime Lopez Carvajal 31 Aug '16

31 Aug '16

Hi Stefan, Do you have a possible date when you are going to activate the scikit-image version on mailman python? Because I check it and it is currently empty. BTW, I dont have any rush, I just want to know. Thank in advance, Jaime On Wednesday, May 18, 2016 at 6:36:07 PM UTC-5, stefanv wrote: > > Hi, everyone > > I would like to migrate the mailing list over to mailman on Python.org. > We're currently on Google Groups, but we don't have good archives or > predictable permalinks based on message-id, and message export is a pain > (I've scraped the entire list content, but needless to say that is less > than ideal). > > I will port the content and automatically subscribe existing members. > > Let me know if you have any objections. > > Best regards > Stéfan >

2 1

Inclusive community statement
by Stefan van der Walt 31 Aug '16

31 Aug '16

Dear contributors and users You may know that I am not very fond of Codes of Conduct in general. I think they are well intentioned, but they are also often aggressive, use words more commonly associated with law enforcement, and may leave one feeling a tad scared and unenthusiastic. At the same time, I do think it is important to be inviting to newcomers of all groups, and to make that clear on our website. What would you say to a "Community Guidelines" or "How We Work (together)" statement on the scikit-image front page? Something along the lines of: "We welcome each and every contributor to scikit-image. Our aim is enthusiastic and productive collaboration, to build an excellent software library, and to have a ton of fun doing it. We encourage one another to be gentle in criticism of others' work, humble in acknowledging our own mistakes, and generous in our praise. If you ever feel like you are not being treated as well as you should, please get in touch with one of the project leads. We are committed to making this community a safe and welcome space." Best regards Stéfan

2 2

Fwd: PyData Community Cookbook - August Update
by Stefan van der Walt 31 Aug '16

31 Aug '16

Hi everyone Is anyone interested in writing a scikit-image chapter for the following book? Stéfan ----- Original message ----- From: Andy Ray Terrel <andy(a)numfocus.org> Subject: PyData Community Cookbook - August Update Date: Sat, 20 Aug 2016 07:14:58 -0500 Hello everyone, You are receiving this email because you were either invited and committed to join our project. Please feel free to forward this message to a more appropriate list or person. For questions please email pydata- cookbook(a)numfocus.org. Katy Huff and myself are starting a project to build a cookbook of advanced material for the PyData community. The cookbook will be published by Addison-Wesley. We have invited a number of contributors to see if such a project would have some interest and received overwhelmingly positive feedback. The book will cover several major topics, organized as such, with some sample packages: - IDE: IPython/Jupyter - Data Structures / Numerics: NumPy, Pandas, Xray, PyTables - Viz: Matplotlib, Bokeh, Seaborn, yt - Algorithms / Science: SciPy, Scikit-learn, Scikit-image, statsmodels, sympy, gensim - Performance / Scale: Cython, Numexpr, Numba, Dask, pyspark We expect each submission to be about 15 - 20 pages describing an example of the power of each library. While we have reached out to the projects about putting each submission together we are happy to accept chapters for libraries we did not initially identify. To facilitate the book we have put together a repository for collecting and reviewing submissions at https://github.com/pydata/pydata-cookbook . We are asking for submissions in rst but would appreciate any other files, such as jupyter notebooks or code, for a digital appendix as well. If you read this far and are interested in contributing. The proposed schedule is the following: Sept 1: Submit a pull request with a title, abstract and author list for the submission. Nov 15: Submit a completed chapter. Dec 31: Reviews for chapters finished. Jan 31: All chapter revisions due. Thanks for you time! -- Andy R. Terrel, PhD President, NumFOCUS andy(a)numfocus.org

4 5

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 29 Aug '16

29 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 21 Aug '16

21 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 10 Aug '16

10 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

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

10 Aug '16

Your suggestions have been very helpful and allowed me to make good progress. Do you know where I can find the Python source code for the edge filters in MatPlotlib? Thanks. Dipu Dipankar Ganguly Consultant: Strategy/Technology/Commercialization Bothell, WA Cell: 408-203-8814 email: dipugee(a)gmail.com http://www.linkedin.com/in/dipugee > On Aug 9, 2016, at 2:42 PM, Stéfan van der Walt <stefanv(a)berkeley.edu> wrote: > > Hi Dipu > > On 9 August 2016 at 14:40, Dipankar “Dipu” Ganguly <dipugee(a)gmail.com <mailto:dipugee@gmail.com>> wrote: > Sorry to bother you again. I am having trouble with "from skimage import xyz” commands. I am using Python 3.5 with Jupyter from Navigator. I am wondering if I am running into version mismatches. > > Yes, I am afraid we don't have an xyz submodule. > > Perhaps you can share some code with us, along with the error messages you are seeing? > > Stéfan > > -- > 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/CABDkGQnhpOQemWLzN5G2ACwwXgL… <https://groups.google.com/d/msgid/scikit-image/CABDkGQnhpOQemWLzN5G2ACwwXgL…>. > For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

1 0

Re: Migration to Python 3.x
by Stéfan van der Walt 10 Aug '16

10 Aug '16

Hi Nelle On 9 August 2016 at 18:55, Nelle Varoquaux <nelle.varoquaux(a)gmail.com> wrote: > 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. > Ubuntu users haven't had the latest scikit-image for quite a while, unfortunately. We are working on fixing that, but not many people have noticed. Stéfan

1 0

Re: Migration to Python 3.x
by Nelle Varoquaux 09 Aug '16

09 Aug '16

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.

1 0

Re: Migration to Python 3.x
by Ralf Gommers 09 Aug '16

09 Aug '16

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 ..... Ralf

1 0

Re: Migration to Python 3.x
by Nelle Varoquaux 09 Aug '16

09 Aug '16

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. 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/CABL7CQhEaD0uy0SyrcNO_j%2BDs…. > > For more options, visit https://groups.google.com/d/optout.

1 0

Re: Migration to Python 3.x
by Ralf Gommers 09 Aug '16

09 Aug '16

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. Ralf

1 0

Re: Migration to Python 3.x
by Nelle Varoquaux 09 Aug '16

09 Aug '16

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.) 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. > > Juan. > > On Wed, Aug 10, 2016 at 8:14 AM, Stéfan van der Walt <stefanv(a)berkeley.edu> > wrote: >> >> Hi Ralf >> >> On 9 August 2016 at 15:09, Ralf Gommers <ralf.gommers(a)gmail.com> wrote: >>> >>> Hi Stefan, do you propose then to drop Python 3.4 at the same time (@ is >>> >= 3.5)? >> >> >> Yes, I guess I am. But if that's too much of a stretch, I will be open to >> >= 3.4. >> >> 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/CABDkGQmSC7Q7jZJDBuhutj2PXjQ…. >> >> 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 email to scikit-image(a)googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/scikit-image/CA%2BJHcKSM0sERcWwSMXc4dk6uh…. > > For more options, visit https://groups.google.com/d/optout.

1 0

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

09 Aug '16

@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.) Juan. On Wed, Aug 10, 2016 at 8:14 AM, Stéfan van der Walt <stefanv(a)berkeley.edu> wrote: > Hi Ralf > > On 9 August 2016 at 15:09, Ralf Gommers <ralf.gommers(a)gmail.com> wrote: > >> Hi Stefan, do you propose then to drop Python 3.4 at the same time (@ is >> >= 3.5)? >> > > Yes, I guess I am. But if that's too much of a stretch, I will be open to > >= 3.4. > > 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/CABDkGQmSC7Q7jZJDBuhutj2PXjQTDGDirxafVw-GFuqcN%3DK1_A% > 40mail.gmail.com > <https://groups.google.com/d/msgid/scikit-image/CABDkGQmSC7Q7jZJDBuhutj2PXjQ…> > . > > For more options, visit https://groups.google.com/d/optout. >

1 0

Re: Migration to Python 3.x
by Stéfan van der Walt 09 Aug '16

09 Aug '16

Hi Ralf On 9 August 2016 at 15:09, Ralf Gommers <ralf.gommers(a)gmail.com> wrote: > Hi Stefan, do you propose then to drop Python 3.4 at the same time (@ is > >= 3.5)? > Yes, I guess I am. But if that's too much of a stretch, I will be open to >= 3.4. Stéfan

1 0

Re: Migration to Python 3.x
by Ralf Gommers 09 Aug '16

09 Aug '16

On Wed, Aug 10, 2016 at 9:58 AM, Stéfan van der Walt <stefanv(a)berkeley.edu> wrote: > Hi Emmanuelle > > > On 9 August 2016 at 14:44, Emmanuelle Gouillart < > emmanuelle.gouillart(a)nsup.org> wrote: > > >> It may be a silly idea, but can't we do it the other way around, that is >> have an experimental branch where developers who wish to write >> Python3-only code can work, and in which commits to master are merged if >> they are Python 3 compatible? It could give us some time to evaluate >> whether most developers want to write code that is not compatible with >> Python 2. >> > > I don't think that's a silly idea, but I also don't think that addresses > two of the points I raised: > > - Remove developer overhead associated with keeping both Python 2 and > 3-isms in mind > > I'd like developers to start thinking in Python 3, not the other way > around. Barriers for Python 3 implementations should be removed, not > raised, given that that's the direction we'll have to move eventually. > > - Utilize new language features such as the @-operator and required > keyword arguments > > These are not available unless we make Python 3 the default. > Hi Stefan, do you propose then to drop Python 3.4 at the same time (@ is >= 3.5)? Ralf

1 0

Re: Migration to Python 3.x
by Emmanuelle Gouillart 09 Aug '16

09 Aug '16

Hi StÃ©fan, about backporting, what kind of backporting mechanism do you have in mind? Merging commits by hand, or something more elaborate? It may be a silly idea, but can't we do it the other way around, that is have an experimental branch where developers who wish to write Python3-only code can work, and in which commits to master are merged if they are Python 3 compatible? It could give us some time to evaluate whether most developers want to write code that is not compatible with Python 2. Best, Emma On Tue, Aug 09, 2016 at 02:23:34PM -0700, StÃ©fan van der Walt wrote: > Hi everyone, > The previous migration thread stalled, and I would like to revisit the issue. > Here is my proposal: > 1. All code written for the 0.13 release of scikit-image should still be Python > 2.7 and 3.x compatible. > 2. 0.13.x will be declared a "Long Term Support" release, with all point > releases supporting Python 2.7 until 2020 > 3. Non-API-breaking features from 0.14 and later *may be backported* to 0.13.x > as needed / requested. > 4. Any new code written after 0.13 will be Python 3.x only (but see #3 above). > My motivations are to: > - Remove developer overhead associated with keeping both Python 2 and 3-isms in > mind > - Reduce testing and maintenance overhead associated with multiple Python > versions > - Utilize new language features such as the @-operator and required keyword > arguments > Please let me know if you have any strong feelings to the contrary. > Best regards > StÃ©fan

2 1

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

09 Aug '16

Hi Stefan: Sorry to bother you again. I am having trouble with "from skimage import xyz” commands. I am using Python 3.5 with Jupyter from Navigator. I am wondering if I am running into version mismatches. Thanks. Dipu Dipankar “Dipu” Ganguly dipugee(a)gmail.com Cell: 408-203-8814 > On Aug 9, 2016, at 2:34 PM, Stéfan van der Walt <stefanv(a)berkeley.edu> wrote: > > Hi Dipu > > On 9 August 2016 at 14:30, Dipankar “Dipu” Ganguly <dipugee(a)gmail.com <mailto:dipugee@gmail.com>> wrote: > Thanks again Stefa. Very helpful. I will try using these. I am assuming, I will also find tools to read .jpg images as numpy arrays, my immediate need. > > You assume correctly :) If you take a look at the user guide I mentioned earlier, you will find examples of how to do that. > > from skimage import io > image = io.imread('my_image.jpg') > > Best regards > Stéfan > > -- > 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/CABDkGQnfVhr%3DB94rU8EtoMD06… <https://groups.google.com/d/msgid/scikit-image/CABDkGQnfVhr%3DB94rU8EtoMD06…>. > For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

2 1

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

09 Aug '16

Thanks again Stefa. Very helpful. I will try using these. I am assuming, I will also find tools to read .jpg images as numpy arrays, my immediate need. Dipu Dipankar “Dipu” Ganguly dipugee(a)gmail.com Cell: 408-203-8814 > On Aug 9, 2016, at 11:40 AM, Stéfan van der Walt <stefanv(a)berkeley.edu> wrote: > > Hi Dipu > > On 9 August 2016 at 08:35, Dipankar “Dipu” Ganguly <dipugee(a)gmail.com <mailto:dipugee@gmail.com>> wrote: > I now need to convert “.jpg" and DICOM images into arrays that I can operate on using numpy and other Scikit-image algorithms/tools. What tools/packages could I use for the conversions (Images —> numpy arrays)? > > You can use pydicom to load the DICOM images to numpy arrays: > > http://pydicom.readthedocs.io/en/stable/working_with_pixel_data.html <http://pydicom.readthedocs.io/en/stable/working_with_pixel_data.html> > > Thereafter, scikit-image can process them: > > http://scikit-image.org/docs/stable/user_guide/numpy_images.html <http://scikit-image.org/docs/stable/user_guide/numpy_images.html> > > If you have more advanced DICOM needs, such as working with multiple slices, or reading meta-data, you may want to look at dcmstack and nibabel as well. > > Best regards > Stéfan > > > -- > 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/CABDkGQm16z6YUJO77MXPeDTsQMR… <https://groups.google.com/d/msgid/scikit-image/CABDkGQm16z6YUJO77MXPeDTsQMR…>. > For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

2 1

Migration to Python 3.x
by Stéfan van der Walt 09 Aug '16

09 Aug '16

Hi everyone, The previous migration thread stalled, and I would like to revisit the issue. Here is my proposal: 1. All code written for the 0.13 release of scikit-image should still be Python 2.7 and 3.x compatible. 2. 0.13.x will be declared a "Long Term Support" release, with all point releases supporting Python 2.7 until 2020 3. Non-API-breaking features from 0.14 and later *may be backported* to 0.13.x as needed / requested. 4. Any new code written after 0.13 will be Python 3.x only (but see #3 above). My motivations are to: - Remove developer overhead associated with keeping both Python 2 and 3-isms in mind - Reduce testing and maintenance overhead associated with multiple Python versions - Utilize new language features such as the @-operator and required keyword arguments Please let me know if you have any strong feelings to the contrary. Best regards Stéfan

1 0

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

09 Aug '16

Thank you Stefan. That was very helpful. I now need to convert “.jpg" and DICOM images into arrays that I can operate on using numpy and other Scikit-image algorithms/tools. What tools/packages could I use for the conversions (Images —> numpy arrays)? Best. Dipu Dipankar Ganguly Consultant: Strategy/Technology/Commercialization Bothell, WA Cell: 408-203-8814 email: dipugee(a)gmail.com http://www.linkedin.com/in/dipugee > 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>.

2 1

Image edge detection
by Dipankar Ganguly 08 Aug '16

08 Aug '16

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

2 1

Cropping Image With Edge Detection Results
by Michael Alonge 02 Aug '16

02 Aug '16

Hello, I have produced a 2D binary edge map from the canny edge detection tool that identifies circle-like edges in my photo. My question is if my binary edge map has many edges that enclose a space, how can I use this map to crop the original photo to make many smaller photos of those enclosed spaces. <https://lh3.googleusercontent.com/-KCm4EGMW85I/V6DOCVSpTQI/AAAAAAAACeM/WraI…> In the image above, one can see 6 circle-like objects whose perimeter has been detected. From this, I would like to create 6 arrays that represent the portions of the original image enclosed by these edges. What tools might I use to achieve this? Thank you

2 2