scikit-image aims to be the reference library for scientific image analysis in Python. We accomplish this by:
being easy to use and install. We are careful in taking on new dependencies, and sometimes cull existing ones, or make them optional. All functions in our API have thorough docstrings clarifying expected inputs and outputs.
providing a consistent API. Conceptually identical arguments have the same name and position in a function signature.
ensuring correctness. Test coverage is close to 100% and code is reviewed by at least two core developers before being included in the library.
caring for users’ data. We have a functional 2 API and don’t modify input arrays unless explicitly directed to do so.
promoting education in image processing, with extensive pedagogical documentation.
We are inclusive. We continue to welcome and mentor newcomers who are making their first contribution.
We are community-driven. Decisions about the API and features are driven by our users’ requirements, not by the whims of the core team. (See SKIP 1 — scikit-image governance and decision-making.)
We serve scientific applications primarily, over “consumer” image editing in the vein of Photoshop or GIMP. This often means prioritizing n-dimensional data support, and rejecting implementations of “flashy” filters that have little scientific value.
We value simple, readable implementations over getting every last ounce of performance. Readable code that is easy to understand, for newcomers and maintainers alike, makes it easier to contribute new code as well as prevent bugs. This means that we will prefer a 20% slowdown if it reduces lines of code two-fold, for example.
We value education and documentation. All functions should have NumPy-style docstrings 3, preferably with examples, as well as gallery examples that showcase how that function is used in a scientific application. Core developers take an active role in finishing documentation examples.
Much in the same way that the Zen of Python 5 and PEP8 guide style and implementation details in most Python code, this guide is meant to guide decisions about the future of scikit-image, be it in terms of code style, whether to accept new functionality, or whether to take on new dependencies, among other things.
To find out more about the history of this document, please read the following:
The use of NumPy arrays was the most supported of the statement’s components, together with the points about inclusivity, mentorship, and documentation. We had +1s from Mark Harfouche, Royi Avital, and Greg Lee, among others.