Mailman 3 August 2014 - scikit-image

Re: skimage and opencv
by Emmanuelle Gouillart Sept. 22, 2016

Sept. 22, 2016

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

GSoC 2014: Congratulations!
by Stefan van der Walt Aug. 23, 2014

Aug. 23, 2014

Hi everyone I'd like to congratulate Vighnesh and Rishabh who just successfully completed the 2014 Google Summer of Code with scikit-image. We have a whole lot to show for it! Thank you, guys, for all your hard work and dedication. For those of you who haven't been following, Vighnesh has been building Region Adjacency Graph infrastructure and algorithms under the very thorough mentorship of Juan. Catering to my nitpicking was Rishabh, who developed a remote, sandboxed execution framework that gives us an interactive gallery (preview at [0]). This was fun, and I look forward as much to our future collaboration! Regards Stéfan [0] http://sharky93.github.io/docs/gallery/auto_examples/

3 2

GSoC Recap Post
by Vighnesh Birodkar Aug. 17, 2014

Aug. 17, 2014

Hello I just wrote a post giving a quick recap of this years GSoC. http://vcansimplify.wordpress.com/2014/08/17/gsoc-2014-signing-off/ I would like to have the link to the homepages of Johannes Schönberger and Guillaume Gay, so that I can link them in my post. Thanks Vighnesh

1 0

Re: Release notes
by Johannes Schönberger Aug. 15, 2014

Aug. 15, 2014

Thanks for letting us know. I have not thought of this, but I can definitely see this happening in our case as well. Separate files in a subdirectory sound as a good workaround. What do the other think? Johannes Schönberger On Aug 14, 2014, at 2:12 PM, Thomas Caswell <tcaswell(a)gmail.com> wrote: > As a side note, mpl has been doing something similar and having > everyone work on the same file leads to a stupendous amount of > conflicts. We are moving to having a folder to create files in and > then re-assembling them at release time. > > Tom > > On Thu, Aug 14, 2014 at 12:21 PM, Stéfan van der Walt <stefan(a)sun.ac.za> wrote: >> On Thu, Aug 14, 2014 at 1:38 PM, Johannes Sch önberger <jsch(a)demuc.de> wrote: >>> Just a reminder: before merging a PR in the future, we want to make sure, that the changes are documented in `doc/release/release_dev.txt`. >> >> Ouch, good point--thanks for the reminder. >> >> Stéfan >> >> -- >> You received this message because you are subscribed to the Google Groups "scikit-image" group. >> To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > > > -- > Thomas Caswell > tcaswell(a)gmail.com > > -- > 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 2

Re: Release notes
by Thomas Caswell Aug. 14, 2014

Aug. 14, 2014

As a side note, mpl has been doing something similar and having everyone work on the same file leads to a stupendous amount of conflicts. We are moving to having a folder to create files in and then re-assembling them at release time. Tom On Thu, Aug 14, 2014 at 12:21 PM, Stéfan van der Walt <stefan(a)sun.ac.za> wrote: > On Thu, Aug 14, 2014 at 1:38 PM, Johannes Sch önberger <jsch(a)demuc.de> wrote: >> Just a reminder: before merging a PR in the future, we want to make sure, that the changes are documented in `doc/release/release_dev.txt`. > > Ouch, good point--thanks for the reminder. > > Stéfan > > -- > You received this message because you are subscribed to the Google Groups "scikit-image" group. > To unsubscribe from this group and stop receiving emails from it, send an email to scikit-image+unsubscribe(a)googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Thomas Caswell tcaswell(a)gmail.com

1 0

Release notes
by Johannes Schönberger Aug. 14, 2014

Aug. 14, 2014

Hi everyone, Just a reminder: before merging a PR in the future, we want to make sure, that the changes are documented in `doc/release/release_dev.txt`. Johannes Schönberger

2 1

Re: We need help working on code coverage for Cython code
by Johannes Schönberger Aug. 14, 2014

Aug. 14, 2014

Hi, This would indeed be a great feature, but unfortunately I am lacking the time to contribute to it at the moment and foreseeable future. Johannes On Thursday, August 7, 2014 9:56:14 PM UTC-4, Matthew Brett wrote: > > Hi, > > Over on another mailing list, we've hit a big problem trying to work > out coverage on a large amount of Cython code. > > As y'all probably know, there's no automated way of checking code > coverage on Cython code at the moment. > > The Cython developers have done some work on this [1] but it is > currently stalled for lack of developer time to work on it. > > We'd really like to get this working, and the Cython developers have > offered to help, to get this started. > > Can anyone help us out by a) joining an interactive discussion for 15 > minutes or so with the Cython developers to get us started b) helping > with a short burst of coding that will follow, we estimate a few days. > > I think this is something many of us need, and it would also be a > thank you to the Cython team for their work, which we all use so much. > > Cheers, > > Matthew > > [1] http://trac.cython.org/cython_trac/ticket/815 >

1 0

FYI - implementation of CIECAM02 in Python
by njs＠vorpus.org Aug. 14, 2014

Aug. 14, 2014

Hi scikit-imageers, I don't have time to prepare a PR, but just as a heads-up in case anyone else wants to do so -- I wrote a complete, tested implementation of the CIECAM02 forward and inverse transforms in Python (BSD-2), which might be a nice extension to skimage.color: https://github.com/njsmith/pycam02ucs/blob/master/pycam02ucs/ciecam02.py I'm pretty confident in its correctness; the only place where it disagrees with Mark Fairchild's spreadsheet implementation, it turns out the spreadsheet is (was) wrong :-). It could probably be optimized further -- it is vectorized, but I didn't go to any great efforts to extract redundant temporaries or perform operations in-place. It's a pretty direct implementation of the equations. The API may not be exactly the scikit-image's taste ATM either -- I forget whether you prefer to use the 0-1 or 0-100 scale for XYZ (this code uses 0-100 b/c that's what the spec uses). And CIECAM02 is a weird space -- the forward transform spits out 7 named dimensions, and the inverse transform needs 3 of these, but is quite flexible about which 3, so I treat each dimension as a separate array instead of stacking them into one. That tree also has an implementation of forward and inverse transforms to the CAM02-UCS perceptually uniform space (Luo et al, 2006): https://github.com/njsmith/pycam02ucs/blob/master/pycam02ucs/cam02ucs.py -n

1 0

Re: We need help working on code coverage for Cython code
by Ralf Gommers Aug. 12, 2014

Aug. 12, 2014

Hi Matthew, On Fri, Aug 8, 2014 at 3:55 AM, Matthew Brett <matthew.brett(a)gmail.com> wrote: > Hi, > > Over on another mailing list, we've hit a big problem trying to work > out coverage on a large amount of Cython code. > > As y'all probably know, there's no automated way of checking code > coverage on Cython code at the moment. > > The Cython developers have done some work on this [1] but it is > currently stalled for lack of developer time to work on it. > > We'd really like to get this working, and the Cython developers have > offered to help, to get this started. > Would be great to get this working. Can anyone help us out by a) joining an interactive discussion for 15 > minutes or so with the Cython developers to get us started b) helping > with a short burst of coding that will follow, we estimate a few days. > This request isn't scikit-image specific, is it? Maybe you can ask on the numpy mailing list to get more responses? Cheers, Ralf I think this is something many of us need, and it would also be a > thank you to the Cython team for their work, which we all use so much. > > Cheers, > > Matthew > > [1] http://trac.cython.org/cython_trac/ticket/815 > > -- > 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. >

1 0

Re: We need help working on code coverage for Cython code
by Juan Nunez-Iglesias Aug. 8, 2014

Aug. 8, 2014

A honking good idea! ... But I am very much flat out for the next 2-3 months, so I will have to watch from the sidelines... Thank you! Juan. On Fri, Aug 8, 2014 at 11:55 AM, Matthew Brett <matthew.brett(a)gmail.com> wrote: > Hi, > > Over on another mailing list, we've hit a big problem trying to work > out coverage on a large amount of Cython code. > > As y'all probably know, there's no automated way of checking code > coverage on Cython code at the moment. > > The Cython developers have done some work on this [1] but it is > currently stalled for lack of developer time to work on it. > > We'd really like to get this working, and the Cython developers have > offered to help, to get this started. > > Can anyone help us out by a) joining an interactive discussion for 15 > minutes or so with the Cython developers to get us started b) helping > with a short burst of coding that will follow, we estimate a few days. > > I think this is something many of us need, and it would also be a > thank you to the Cython team for their work, which we all use so much. > > Cheers, > > Matthew > > [1] http://trac.cython.org/cython_trac/ticket/815 > > -- > 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. >

1 0