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,
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
I'm sure that other devs/users will have things to add to this
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.
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
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.
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
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:
> (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.
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
Can this goal be accomplished with sckit-image? If not, is there another
library and algorithm you could recommend?
I know you must be working on several topics at same time, I wish to have
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.
have you figured it out? The deadline is tomorrow, and I would really like
Em quarta-feira, 31 de agosto de 2016 15:37:06 UTC+2, Egor Panfilov
> 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.
> 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
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
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."
Is anyone interested in writing a scikit-image chapter for the
----- 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
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-
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
- IDE: IPython/Jupyter
- Data Structures / Numerics: NumPy, Pandas, Xray, PyTables
- Viz: Matplotlib, Bokeh, Seaborn, yt
- Algorithms / Science: SciPy, Scikit-learn, Scikit-image, statsmodels,
- 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
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