diff --git a/README.md b/README.md index fca0fdf..a7c4621 100644 --- a/README.md +++ b/README.md @@ -1,136 +1,139 @@ [](https://join.slack.com/t/mdtoolkit/shared_invite/enQtNTQ3MjY2MzE0MDg2LWNjY2I2Njc5MTY0NmM0ZWIxNmQwZDRhYzk2MDdhM2QxYjliYTcwYzhkNTAxYmRkMDA0MjcyNDMyYjllNTZhY2M)


Copyright © German Cancer Research Center (DKFZ), Division of Medical Image Computing (MIC). Please make sure that your usage of this code is in compliance with the code license. -##Release Notes +## Release Notes **v0.1.0**: Updates to python 3.7, torch 1.4.0, torchvision 0.5.0, entailing a change in custom extensions NMS and RoIAlign (now in C++ and CUDA). Scalar monitoring is changed to torch-included tensorboard. Added qualitative example plots for validation and testing. Default optimizer is changed to AdamW instead of Adam to account for fix in weight-decay handling, norms and biases can optionally be excluded from weight decay. Introduced - optional dynamic learning-rate scheduling. A specific CUDA device can be selected via script argument.\ + optional dynamic learning-rate scheduling. A specific CUDA device can be selected via script argument. Added + tutorial.\ **v0.0.2**: Small fixes mainly regarding server-env settings (cluster deployment).\ **v0.0.1**: Original framework as used for the corresponding paper, with Python 3.6 and torch 0.4.1 dependencies, custom extensions NMS and RoIAlign in C and CUDA, scalar monitoring via plot files. ## Overview This is a comprehensive framework for object detection featuring: - 2D + 3D implementations of prevalent object detectors: e.g. Mask R-CNN [1], Retina Net [2], Retina U-Net [3]. - Modular and light-weight structure ensuring sharing of all processing steps (incl. backbone architecture) for comparability of models. - training with bounding box and/or pixel-wise annotations. - dynamic patching and tiling of 2D + 3D images (for training and inference). - weighted consolidation of box predictions across patch-overlaps, ensembles, and dimensions [3]. - monitoring + evaluation simultaneously on object and patient level. - 2D + 3D output visualizations. - integration of COCO mean average precision metric [5]. - integration of MIC-DKFZ batch generators for extensive data augmentation [6]. - easy modification to evaluation of instance segmentation and/or semantic segmentation.
[1] He, Kaiming, et al. "Mask R-CNN" ICCV, 2017
[2] Lin, Tsung-Yi, et al. "Focal Loss for Dense Object Detection" TPAMI, 2018.
[3] Jaeger, Paul et al. "Retina U-Net: Embarrassingly Simple Exploitation of Segmentation Supervision for Medical Object Detection" , 2018 [5] https://github.com/cocodataset/cocoapi/blob/master/PythonAPI/pycocotools/cocoeval.py
[6] https://github.com/MIC-DKFZ/batchgenerators

+A tutorial on how to add your own data set can be found under `experiments/tutorial.md`. + ## How to cite this code Please cite the original publication [3]. ## Installation Setup package in virtual environment ``` git clone https://github.com/MIC-DKFZ/medicaldetectiontoolkit.git. cd medicaldetectiontoolkit virtualenv -p python3.7 mdt source mdt/bin/activate python setup.py install ``` ##### Custom Extensions This framework uses two custom mixed C++/CUDA extensions: Non-maximum suppression (NMS) and RoIAlign. Both are adapted from the original pytorch extensions (under torchvision.ops.boxes and ops.roialign). The extensions are automatically compiled from the provided source files under medicaldetectiontoolkit/custom_extensions with above setup.py. However, the extensions need to be compiled specifically for certain GPU architectures. Hence, please ensure that the architectures you need are included in your shell's environment variable ```TORCH_CUDA_ARCH_LIST``` before compilation. Example: You want to use the modules with the new TITAN RTX GPU, which has Compute Capability 7.5 (Turing Architecture), but sometimes you also want to use it with a TITAN Xp (6.1, Pascal). Before installation you need to ```export TORCH_CUDA_ARCH_LIST="6.1;7.5"```. A link list of GPU model names to Compute Capability can be found here: https://developer.nvidia.com/cuda-gpus. Note: If you'd like to import the raw extensions (not the wrapper modules), be sure to import torch first. ## Prepare the Data This framework is meant for you to be able to train models on your own data sets. Two example data loaders are provided in medicaldetectiontoolkit/experiments including thorough documentation to ensure a quick start for your own project. The way I load Data is to have a preprocessing script, which after preprocessing saves the Data of whatever data type into numpy arrays (this is just run once). During training / testing, the data loader then loads these numpy arrays dynamically. (Please note the Data Input side is meant to be customized by you according to your own needs and the provided Data loaders are merely examples: LIDC has a powerful Dataloader that handles 2D/3D inputs and is optimized for patch-based training and inference. Toy-Experiments have a lightweight Dataloader, only handling 2D without patching. The latter makes sense if you want to get familiar with the framework.). ## Execute 1. Set I/O paths, model and training specifics in the configs file: medicaldetectiontoolkit/experiments/your_experiment/configs.py 2. Train the model: ``` python exec.py --mode train --exp_source experiments/my_experiment --exp_dir path/to/experiment/directory ``` This copies snapshots of configs and model to the specified exp_dir, where all outputs will be saved. By default, the data is split into 60% training and 20% validation and 20% testing data to perform a 5-fold cross validation (can be changed to hold-out test set in configs) and all folds will be trained iteratively. In order to train a single fold, specify it using the folds arg: ``` python exec.py --folds 0 1 2 .... # specify any combination of folds [0-4] ``` 3. Run inference: ``` python exec.py --mode test --exp_dir path/to/experiment/directory ``` This runs the prediction pipeline and saves all results to exp_dir. ## Models This framework features all models explored in [3] (implemented in 2D + 3D): The proposed Retina U-Net, a simple but effective Architecture fusing state-of-the-art semantic segmentation with object detection,


also implementations of prevalent object detectors, such as Mask R-CNN, Faster R-CNN+ (Faster R-CNN w\ RoIAlign), Retina Net, U-Faster R-CNN+ (the two stage counterpart of Retina U-Net: Faster R-CNN with auxiliary semantic segmentation), DetU-Net (a U-Net like segmentation architecture with heuristics for object detection.)



## Training annotations This framework features training with pixelwise and/or bounding box annotations. To overcome the issue of box coordinates in data augmentation, we feed the annotation masks through data augmentation (create a pseudo mask, if only bounding box annotations provided) and draw the boxes afterwards.


The framework further handles two types of pixel-wise annotations: 1. A label map with individual ROIs identified by increasing label values, accompanied by a vector containing in each position the class target for the lesion with the corresponding label (for this mode set get_rois_from_seg_flag = False when calling ConvertSegToBoundingBoxCoordinates in your Data Loader). 2. A binary label map. There is only one foreground class and single lesions are not identified. All lesions have the same class target (foreground). In this case the Dataloader runs a Connected Component Labelling algorithm to create processable lesion - class target pairs on the fly (for this mode set get_rois_from_seg_flag = True when calling ConvertSegToBoundingBoxCoordinates in your Data Loader). ## Prediction pipeline This framework provides an inference module, which automatically handles patching of inputs, and tiling, ensembling, and weighted consolidation of output predictions:




## Consolidation of predictions (Weighted Box Clustering) Multiple predictions of the same image (from test time augmentations, tested epochs and overlapping patches), result in a high amount of boxes (or cubes), which need to be consolidated. In semantic segmentation, the final output would typically be obtained by averaging every pixel over all predictions. As described in [3], **weighted box clustering** (WBC) does this for box predictions:





## Visualization / Monitoring By default, loss functions and performance metrics are monitored:



Histograms of matched output predictions for training/validation/testing are plotted per foreground class:


Input images + ground truth annotations + output predictions of a sampled validation abtch are plotted after each epoch (here 2D sampled slice with +-3 neighbouring context slices in channels):


Zoomed into the last two lines of the plot:


## License This framework is published under the [Apache License Version 2.0](LICENSE). diff --git a/experiments/tutorial.md b/experiments/tutorial.md index 4bac708..669ab06 100644 --- a/experiments/tutorial.md +++ b/experiments/tutorial.md @@ -1,100 +1,100 @@ # Tutorial ##### for Including a Dataset into the Framework ## Introduction This tutorial aims at providing a muster routine for including a new dataset into the framework in order to use the included models and algorithms with it.\ The tutorial and toy dataset (under `toy_exp`) are in 2D, yet the switch to 3D is simply made by providing 3D data and proceeding analogically, as can be seen from the provided LIDC scripts (under `lidc_exp`). Datasets in the framework are set up under `medicaldetectiontoolkit/experiments/` and require three fundamental scripts: 1. A **preprocessing** script that performs one-time routines on your raw data bringing it into a suitable, easily usable format. 2. A **data-loading** script (required name `data_loader.py`) that efficiently assembles the preprocessed data into network-processable batches. 3. A **configs** file (`configs.py`) which specifies all settings, from data loading to network architecture. This file is automatically complemented by `default_settings.py` which holds default and dataset-independent settings. ## Preprocessing This script (`generate_toys.py` in case of the provided toy dataset, `preprocessing.py` in case of LIDC) is required to bring your raw data into an easily usable format. We recommend, you put all one-time processes (like normalization, resampling, cropping, type conversions) into this script in order to avoid the need for repetitive actions during data loading.\ For the framework usage, we follow a simple workload separation scheme, where network computations are performed on the GPU while data loading and augmentations are performed on the CPU. Hence, the framework requires numpy arrays (`.npy`) as input to the networks, therefore your preprocessed data (images and segmentations) should already be in that format. In terms of data dimensions, we follow the scheme: (y, x (,z)), meaning coronal, sagittal, and axial dimensions, respectively. Class labels for the Regions of Interest (RoIs) need to be provided as lists per data sample. If you have segmenation data, you may use the [batchgenerators](https://github.com/MIC-DKFZ/batchgenerators) transform ConvertSegToBoundingBoxCoordinates to generate bounding boxes from your segmentations. In that case, the order of the class labels in the list needs to correspond to the RoI labels in the segmentation.\ Example: An image (2D or 3D) has two RoIs, one of class 1, the other of class 0. In your segmentation, every pixel is 0 (bg), except for the area marking class 1, which has value 1, and the area of class 0, which has value 2. Your list of class labels for this sample should be `[1, 0]`. I.e., the index of the RoI's class label in the sample's label list corresponds to its marking in the segmentation shifted by -1.\ If you do not have segmentations (only models Faster R-CNN and RetinaNet can be used), you can directly provide bounding boxes. In that case, RoIs are simply identified by their indices in the lists: class label list `[cl_of_roi_a, cl_of_roi_b]` corresponds to bbox list `[coords_of_roi_a, coords_of_roi_b]`. Please store all your light-weight information (patient id, class targets, (relative) paths or identifiers for data and seg) about the preprocessed data set in a pandas dataframe, say `info_df.pkl`. ## Data Loading The goal of `data_loader.py` is to sample or iterate, load into CPU RAM, assemble, and eventually augment the preprocessed data.\ The framework requires the data loader to provide at least a function `get_train_generators`, which yields a dict holding a train-data loader under key `"train"` and validation loader under `"val_sampling"` or `"val_patient"`, analogically for `get_test_generator` with `"test"`.\ We recommend you closely follow our structure as in the provided datasets, which includes a data loader suitable for sampling single patches or parts of the whole patient data with focus on class equilibrium (BatchGenerator, used in training and optionally validation) and a PatientIterator which is intended for test and optionally valdiation and iterates through all patients one by one, not discarding any parts of the patient image. In detail, the structure is as follows. Data loading is performed with the help of the batchgenerators package. Starting from farthest to closest to the preprocessed data, the data loader contains: 1. Method `get_train_generators` which is called by the execution script and in the end provides train and val data loaders. Same goes for `get_test_generator` for the test loader. 2. Method `load_dataset` which reads the `info_df.pkl` and provides a dictionary holding, per patient id, paths to images and segmentations, and light-weight info like class targets. 3. Method `create_data_gen_pipeline` which initiates the train data loader (instance of class BatchGenerator), assembles the chosen data-augmentation procedures and passes the BatchGenerator into a MultiThreadedAugmenter (MTA). The MTA is a wrapper that manages multi-threaded loading (and augmentation). 4. Class BatchGenerator. This data loader is used for sampling, e.g., according to the scheme described in `utils/dataloader_utils.get_class_balanced_patients`. It needs to implement a `__next__` method providing the batch; the batch is a dictionary with (at least) keys: `"data"`, `"pid"`, `"class_target"` (as well as `"seg"` if using segmentations). - `"data"` needs to hold your image (2D or 3D) as a numpy array with dimensions: (b, c, y, x(, z)), where b is the batch dimension (b = batch size), c the channel dimension (if you have multi-modal data c > 1), y, x, z are the spatial dimensions; z is omitted in case of 2D data. - `"seg"` has the same format as `"data"`, except that its channel dimension has always size c = 1. - `"pid"` is a list of patient or sample identifiers, one per sample, i.e., shape (b,). - `"class_target"` which holds, as mentioned in preprocessing, class labels for the RoIs. It's a list of length b, holding itself lists of varying lengths n_rois(sample). **Note**: the above description only applies if you use ConvertSegToBoundingBoxCoordinates. Class targets after batch generation need to make room for a background class (network heads need to be able to predict class 0 = bg). Since, in preprocessing, we started classes at id 0, we now need to shift them by +1. This is done automatically inside ConvertSegToBoundingBoxCoordinates. That transform also renames `"class_target"` to `"roi_labels"`, which is the label required by the rest of the framework. In case you do not use that transform, please shift and rename the labels in your BatchGenerator. 5. Class PatientIterator. This data loader is intended for testing and validation. It needs to provide the same output as above BatchGenerator, however, initial batch size is always limited to one (one patient). Output batch size may vary if patching is applied. Please refer to the LIDC PatientIterator to see how to include patching. Note that this Iterator is not supposed to go through the MTA, transforms (mainly ConvertSegToBoundingBoxCoordinates) therefore need to be applied within this class directly. -##Configs +## Configs The current work flow is intended for running multiple experiments with the same dataset but different configs. This is done by setting the desired values in `configs.py` in the data set's source directory, then creating an experiment via the execution script (`exec.py`, modes "create_exp" or "train" or "train_test"), which copies a snapshot of configs, data loader, default configs, and selected model to the provided experiment directory. `configs.py` introduces class `configs`, which, when instantiated, inherits settings in `default_configs.py` and adds model-specific settings to itself. Aside from setting all the right input/output paths, you can tune almost anything, from network architecture to data-loading settings to train and test routine settings.\ Furthermore, throughout the whole framework, you have the option to include server-environment specific settings by passing argument `--server_env` to the exec script. E.g., in the configs, we use this flag, to overwrite local paths by the paths we use on our GPU cluster. \ No newline at end of file