nipy / nilabels Goto Github PK

View Code? Open in Web Editor NEW

21.0 21.0 2.0 967 KB

Tools to automate simple manipulations and measurements of medical images and segmentations in nifti format.

License: MIT License

Python 100.00%

nilabels's Introduction

NIPY

Neuroimaging tools for Python.

The aim of NIPY is to produce a platform-independent Python environment for the analysis of functional brain imaging data using an open development model.

In NIPY we aim to:

Provide an open source, mixed language scientific programming environment suitable for rapid development.
Create software components in this environment to make it easy to develop tools for MRI, EEG, PET and other modalities.
Create and maintain a wide base of developers to contribute to this platform.
To maintain and develop this framework as a single, easily installable bundle.

NIPY is the work of many people. We list the main authors in the file AUTHOR in the NIPY distribution, and other contributions in THANKS.

Website

Current information can always be found at the NIPY project website.

Mailing Lists

For questions on how to use nipy or on making code contributions, please see the neuroimaging mailing list:

https://mail.python.org/mailman/listinfo/neuroimaging

Please report bugs at github issues:

https://github.com/nipy/nipy/issues

You can see the list of current proposed changes at:

https://github.com/nipy/nipy/pulls

Code

You can find our sources and single-click downloads:

Main repository on Github;
Documentation for all releases and current development tree;
Download the current development version as a tar/zip file;
Downloads of all available releases.

Tests

To run nipy's tests, you will need to install the pytest Python testing package:

pip install pytest

Then:

pytest nipy

You can run the doctests along with the other tests with:

pip install pytest-doctestplus

Then:

pytest --doctest-plus nipy

Installation

See the latest installation instructions.

License

We use the 3-clause BSD license; the full license is in the file LICENSE in the nipy distribution.

nilabels's People

Contributors

Stargazers

Watchers

Forkers

jhlegarreta chadkowski

nilabels's Issues

Remove phantom generator in an independent repository and reduce size of the test.

Phantom generator goes beyond the NiLabel purposes, and it is only naively used in testing.
Tests should be made smaller and phantom generator should be an independent repository.

How to convert connected components into labels

Edit: sorry, ignore this issue, found the solution.

Best wishes.

Use nouns as class names not verbs

For instance while the file itself is nicely named as a noun labels_manipulator, the class is named LabelsManipulate. This is applicable to other similar cases within the codebase. The rationale here is that each instance of a class is a "worker" (class) that "does some work" (method).

As a side-note, I'd rather name this class LabelManipulator rather than using the plural of the word "label".

Convert one multi-labeled segmentation file to individual slices '.stl' file

Hi there,

I am performing a vertebrae segmentation task and I've output multiple segmentation.nii.gz files. Each of the segmented niftis files contains different segments (segment 1,2,3...), corresponding different vertebraes labelled in the file.

My question is how to save the individual slices from each segmented nii.gz file using nilabels? Thank you in advance for your time and effort.

update links to niftynet and niftyseg

The reference repo for these are now the GitHub ones found here:
https://github.com/KCL-BMEIS

Update circleCi reference in the README

...as it got broken after transferring the repository on nipy.
(Update with https://circleci.com/gh/nipy/nilabels)

Consider refactoring NiLabel class

It's currently part of nilabel.main. Consider making it importable from nilabel directly. You may want to rename it as well, as currently it has the same name as the package itself. Maybe something like App.

Also, this class exposes the underlying "worker" objects, which goes against the rationale of the command design pattern:

Command decouples the object that invokes the operation from the one that knows how to perform it.

For instance to relabel, a call to nil.manipulate.relabel() is necessary, which means the caller needs to know the LabelsManipulate class interface. Instead, the "main" class should provide a relabel() method, which calls LabelsManipulate.relabel() (or any other implementation, should the implementation change in the future).

I would also recommend refraining from using short identifiers like NiL or nil (the second being more "dangerous"). Short identifiers are catchy, however prone to introducing compatibility issues, see for instance one of the problems created by the new async keyword introduced as part of Python 3.7

Standardise README section headers

I like the simplicity of the README file in general. I also like to introductory example. It looks helpful and gives a gist of what nilabel is doing.

I would however suggest using a more standardised layout in terms of the section headers. See for instance the section headers in the NiftyNet README.

Also, one general comment (which applies to bruker2nifti as well): "gift-SURG" should be spelled "GIFT-Surg"