Commit 54a066bf authored by mashun1's avatar mashun1
Browse files

ootdiffusion

parents
Pipeline #1004 canceled with stages
detectron2.data package
=======================
.. automodule:: detectron2.data
:members:
:undoc-members:
:show-inheritance:
detectron2.data.detection\_utils module
---------------------------------------
.. automodule:: detectron2.data.detection_utils
:members:
:undoc-members:
:show-inheritance:
detectron2.data.datasets module
---------------------------------------
.. automodule:: detectron2.data.datasets
:members:
:undoc-members:
:show-inheritance:
detectron2.data.samplers module
---------------------------------------
.. automodule:: detectron2.data.samplers
:members:
:undoc-members:
:show-inheritance:
detectron2.data.transforms module
---------------------------------------
.. automodule:: detectron2.data.transforms
:members:
:undoc-members:
:show-inheritance:
detectron2.engine package
=========================
.. automodule:: detectron2.engine
:members:
:undoc-members:
:show-inheritance:
detectron2.engine.defaults module
---------------------------------
.. automodule:: detectron2.engine.defaults
:members:
:undoc-members:
:show-inheritance:
detectron2.engine.hooks module
---------------------------------
.. automodule:: detectron2.engine.hooks
:members:
:undoc-members:
:show-inheritance:
detectron2.evaluation package
=============================
.. automodule:: detectron2.evaluation
:members:
:undoc-members:
:show-inheritance:
detectron2.export package
=========================
.. automodule:: detectron2.export
:members:
:undoc-members:
:show-inheritance:
API Documentation
==================
.. toctree::
checkpoint
config
data
engine
evaluation
layers
model_zoo
modeling
solver
structures
utils
export
detectron2.layers package
=========================
.. automodule:: detectron2.layers
:members:
:undoc-members:
:show-inheritance:
detectron2.model_zoo package
============================
.. automodule:: detectron2.model_zoo
:members:
:undoc-members:
:show-inheritance:
detectron2.modeling package
===========================
.. automodule:: detectron2.modeling
:members:
:undoc-members:
:show-inheritance:
detectron2.modeling.poolers module
---------------------------------------
.. automodule:: detectron2.modeling.poolers
:members:
:undoc-members:
:show-inheritance:
detectron2.modeling.sampling module
------------------------------------
.. automodule:: detectron2.modeling.sampling
:members:
:undoc-members:
:show-inheritance:
detectron2.modeling.box_regression module
------------------------------------------
.. automodule:: detectron2.modeling.box_regression
:members:
:undoc-members:
:show-inheritance:
Model Registries
-----------------
These are different registries provided in modeling.
Each registry provide you the ability to replace it with your customized component,
without having to modify detectron2's code.
Note that it is impossible to allow users to customize any line of code directly.
Even just to add one line at some place,
you'll likely need to find out the smallest registry which contains that line,
and register your component to that registry.
.. autodata:: detectron2.modeling.META_ARCH_REGISTRY
.. autodata:: detectron2.modeling.BACKBONE_REGISTRY
.. autodata:: detectron2.modeling.PROPOSAL_GENERATOR_REGISTRY
.. autodata:: detectron2.modeling.RPN_HEAD_REGISTRY
.. autodata:: detectron2.modeling.ANCHOR_GENERATOR_REGISTRY
.. autodata:: detectron2.modeling.ROI_HEADS_REGISTRY
.. autodata:: detectron2.modeling.ROI_BOX_HEAD_REGISTRY
.. autodata:: detectron2.modeling.ROI_MASK_HEAD_REGISTRY
.. autodata:: detectron2.modeling.ROI_KEYPOINT_HEAD_REGISTRY
detectron2.solver package
=========================
.. automodule:: detectron2.solver
:members:
:undoc-members:
:show-inheritance:
detectron2.structures package
=============================
.. automodule:: detectron2.structures
:members:
:undoc-members:
:show-inheritance:
detectron2.utils package
========================
detectron2.utils.colormap module
--------------------------------
.. automodule:: detectron2.utils.colormap
:members:
:undoc-members:
:show-inheritance:
detectron2.utils.comm module
----------------------------
.. automodule:: detectron2.utils.comm
:members:
:undoc-members:
:show-inheritance:
detectron2.utils.events module
------------------------------
.. automodule:: detectron2.utils.events
:members:
:undoc-members:
:show-inheritance:
detectron2.utils.logger module
------------------------------
.. automodule:: detectron2.utils.logger
:members:
:undoc-members:
:show-inheritance:
detectron2.utils.registry module
--------------------------------
.. automodule:: detectron2.utils.registry
:members:
:undoc-members:
:show-inheritance:
detectron2.utils.memory module
----------------------------------
.. automodule:: detectron2.utils.memory
:members:
:undoc-members:
:show-inheritance:
detectron2.utils.analysis module
----------------------------------
.. automodule:: detectron2.utils.analysis
:members:
:undoc-members:
:show-inheritance:
detectron2.utils.visualizer module
----------------------------------
.. automodule:: detectron2.utils.visualizer
:members:
:undoc-members:
:show-inheritance:
detectron2.utils.video\_visualizer module
-----------------------------------------
.. automodule:: detectron2.utils.video_visualizer
:members:
:undoc-members:
:show-inheritance:
# Benchmarks
Here we benchmark the training speed of a Mask R-CNN in detectron2,
with some other popular open source Mask R-CNN implementations.
### Settings
* Hardware: 8 NVIDIA V100s with NVLink.
* Software: Python 3.7, CUDA 10.1, cuDNN 7.6.5, PyTorch 1.5,
TensorFlow 1.15.0rc2, Keras 2.2.5, MxNet 1.6.0b20190820.
* Model: an end-to-end R-50-FPN Mask-RCNN model, using the same hyperparameter as the
[Detectron baseline config](https://github.com/facebookresearch/Detectron/blob/master/configs/12_2017_baselines/e2e_mask_rcnn_R-50-FPN_1x.yaml)
(it does no have scale augmentation).
* Metrics: We use the average throughput in iterations 100-500 to skip GPU warmup time.
Note that for R-CNN-style models, the throughput of a model typically changes during training, because
it depends on the predictions of the model. Therefore this metric is not directly comparable with
"train speed" in model zoo, which is the average speed of the entire training run.
### Main Results
```eval_rst
+-------------------------------+--------------------+
| Implementation | Throughput (img/s) |
+===============================+====================+
| |D2| |PT| | 62 |
+-------------------------------+--------------------+
| mmdetection_ |PT| | 53 |
+-------------------------------+--------------------+
| maskrcnn-benchmark_ |PT| | 53 |
+-------------------------------+--------------------+
| tensorpack_ |TF| | 50 |
+-------------------------------+--------------------+
| simpledet_ |mxnet| | 39 |
+-------------------------------+--------------------+
| Detectron_ |C2| | 19 |
+-------------------------------+--------------------+
| `matterport/Mask_RCNN`__ |TF| | 14 |
+-------------------------------+--------------------+
.. _maskrcnn-benchmark: https://github.com/facebookresearch/maskrcnn-benchmark/
.. _tensorpack: https://github.com/tensorpack/tensorpack/tree/master/examples/FasterRCNN
.. _mmdetection: https://github.com/open-mmlab/mmdetection/
.. _simpledet: https://github.com/TuSimple/simpledet/
.. _Detectron: https://github.com/facebookresearch/Detectron
__ https://github.com/matterport/Mask_RCNN/
.. |D2| image:: https://github.com/facebookresearch/detectron2/raw/master/.github/Detectron2-Logo-Horz.svg?sanitize=true
:height: 15pt
:target: https://github.com/facebookresearch/detectron2/
.. |PT| image:: https://pytorch.org/assets/images/logo-icon.svg
:width: 15pt
:height: 15pt
:target: https://pytorch.org
.. |TF| image:: https://static.nvidiagrid.net/ngc/containers/tensorflow.png
:width: 15pt
:height: 15pt
:target: https://tensorflow.org
.. |mxnet| image:: https://github.com/dmlc/web-data/raw/master/mxnet/image/mxnet_favicon.png
:width: 15pt
:height: 15pt
:target: https://mxnet.apache.org/
.. |C2| image:: https://caffe2.ai/static/logo.svg
:width: 15pt
:height: 15pt
:target: https://caffe2.ai
```
Details for each implementation:
* __Detectron2__: with release v0.1.2, run:
```
python tools/train_net.py --config-file configs/Detectron1-Comparisons/mask_rcnn_R_50_FPN_noaug_1x.yaml --num-gpus 8
```
* __mmdetection__: at commit `b0d845f`, run
```
./tools/dist_train.sh configs/mask_rcnn/mask_rcnn_r50_caffe_fpn_1x_coco.py 8
```
* __maskrcnn-benchmark__: use commit `0ce8f6f` with `sed -i ‘s/torch.uint8/torch.bool/g’ **/*.py; sed -i 's/AT_CHECK/TORCH_CHECK/g' **/*.cu`
to make it compatible with PyTorch 1.5. Then, run training with
```
python -m torch.distributed.launch --nproc_per_node=8 tools/train_net.py --config-file configs/e2e_mask_rcnn_R_50_FPN_1x.yaml
```
The speed we observed is faster than its model zoo, likely due to different software versions.
* __tensorpack__: at commit `caafda`, `export TF_CUDNN_USE_AUTOTUNE=0`, then run
```
mpirun -np 8 ./train.py --config DATA.BASEDIR=/data/coco TRAINER=horovod BACKBONE.STRIDE_1X1=True TRAIN.STEPS_PER_EPOCH=50 --load ImageNet-R50-AlignPadding.npz
```
* __SimpleDet__: at commit `9187a1`, run
```
python detection_train.py --config config/mask_r50v1_fpn_1x.py
```
* __Detectron__: run
```
python tools/train_net.py --cfg configs/12_2017_baselines/e2e_mask_rcnn_R-50-FPN_1x.yaml
```
Note that many of its ops run on CPUs, therefore the performance is limited.
* __matterport/Mask_RCNN__: at commit `3deaec`, apply the following diff, `export TF_CUDNN_USE_AUTOTUNE=0`, then run
```
python coco.py train --dataset=/data/coco/ --model=imagenet
```
Note that many small details in this implementation might be different
from Detectron's standards.
<details>
<summary>
(diff to make it use the same hyperparameters - click to expand)
</summary>
```diff
diff --git i/mrcnn/model.py w/mrcnn/model.py
index 62cb2b0..61d7779 100644
--- i/mrcnn/model.py
+++ w/mrcnn/model.py
@@ -2367,8 +2367,8 @@ class MaskRCNN():
epochs=epochs,
steps_per_epoch=self.config.STEPS_PER_EPOCH,
callbacks=callbacks,
- validation_data=val_generator,
- validation_steps=self.config.VALIDATION_STEPS,
+ #validation_data=val_generator,
+ #validation_steps=self.config.VALIDATION_STEPS,
max_queue_size=100,
workers=workers,
use_multiprocessing=True,
diff --git i/mrcnn/parallel_model.py w/mrcnn/parallel_model.py
index d2bf53b..060172a 100644
--- i/mrcnn/parallel_model.py
+++ w/mrcnn/parallel_model.py
@@ -32,6 +32,7 @@ class ParallelModel(KM.Model):
keras_model: The Keras model to parallelize
gpu_count: Number of GPUs. Must be > 1
"""
+ super().__init__()
self.inner_model = keras_model
self.gpu_count = gpu_count
merged_outputs = self.make_parallel()
diff --git i/samples/coco/coco.py w/samples/coco/coco.py
index 5d172b5..239ed75 100644
--- i/samples/coco/coco.py
+++ w/samples/coco/coco.py
@@ -81,7 +81,10 @@ class CocoConfig(Config):
IMAGES_PER_GPU = 2
# Uncomment to train on 8 GPUs (default is 1)
- # GPU_COUNT = 8
+ GPU_COUNT = 8
+ BACKBONE = "resnet50"
+ STEPS_PER_EPOCH = 50
+ TRAIN_ROIS_PER_IMAGE = 512
# Number of classes (including background)
NUM_CLASSES = 1 + 80 # COCO has 80 classes
@@ -496,29 +499,10 @@ if __name__ == '__main__':
# *** This training schedule is an example. Update to your needs ***
# Training - Stage 1
- print("Training network heads")
model.train(dataset_train, dataset_val,
learning_rate=config.LEARNING_RATE,
epochs=40,
- layers='heads',
- augmentation=augmentation)
-
- # Training - Stage 2
- # Finetune layers from ResNet stage 4 and up
- print("Fine tune Resnet stage 4 and up")
- model.train(dataset_train, dataset_val,
- learning_rate=config.LEARNING_RATE,
- epochs=120,
- layers='4+',
- augmentation=augmentation)
-
- # Training - Stage 3
- # Fine tune all layers
- print("Fine tune all layers")
- model.train(dataset_train, dataset_val,
- learning_rate=config.LEARNING_RATE / 10,
- epochs=160,
- layers='all',
+ layers='3+',
augmentation=augmentation)
elif args.command == "evaluate":
```
</details>
# Change Log
### Releases
See release log at
[https://github.com/facebookresearch/detectron2/releases](https://github.com/facebookresearch/detectron2/releases).
### Notable Backward Incompatible Changes:
* 03/30/2020: Custom box head's `output_size` changed to `output_shape`.
* 02/14/2020,02/18/2020: Mask head and keypoint head now include logic for losses & inference. Custom heads
should overwrite the feature computation by `layers()` method.
* 11/11/2019: `detectron2.data.detection_utils.read_image` transposes images with exif information.
### Config Version Change Log
* v1: Rename `RPN_HEAD.NAME` to `RPN.HEAD_NAME`.
* v2: A batch of rename of many configurations before release.
### Silent Regression in Historical Versions:
We list a few silent regressions since they may silently produce incorrect results and will be hard to debug.
* 04/01/2020 - 05/11/2020: Bad accuracy if `TRAIN_ON_PRED_BOXES` is set to True.
* 03/30/2020 - 04/01/2020: ResNets are not correctly built.
* 12/19/2019 - 12/26/2019: Using aspect ratio grouping causes a drop in accuracy.
* release - 11/9/2019: Test time augmentation does not predict the last category.
# Compatibility with Other Libraries
## Compatibility with Detectron (and maskrcnn-benchmark)
Detectron2 addresses some legacy issues left in Detectron. As a result, their models
are not compatible:
running inference with the same model weights will produce different results in the two code bases.
The major differences regarding inference are:
- The height and width of a box with corners (x1, y1) and (x2, y2) is now computed more naturally as
width = x2 - x1 and height = y2 - y1;
In Detectron, a "+ 1" was added both height and width.
Note that the relevant ops in Caffe2 have [adopted this change of convention](https://github.com/pytorch/pytorch/pull/20550)
with an extra option.
So it is still possible to run inference with a Detectron2-trained model in Caffe2.
The change in height/width calculations most notably changes:
- encoding/decoding in bounding box regression.
- non-maximum suppression. The effect here is very negligible, though.
- RPN now uses simpler anchors with fewer quantization artifacts.
In Detectron, the anchors were quantized and
[do not have accurate areas](https://github.com/facebookresearch/Detectron/issues/227).
In Detectron2, the anchors are center-aligned to feature grid points and not quantized.
- Classification layers have a different ordering of class labels.
This involves any trainable parameter with shape (..., num_categories + 1, ...).
In Detectron2, integer labels [0, K-1] correspond to the K = num_categories object categories
and the label "K" corresponds to the special "background" category.
In Detectron, label "0" means background, and labels [1, K] correspond to the K categories.
- ROIAlign is implemented differently. The new implementation is [available in Caffe2](https://github.com/pytorch/pytorch/pull/23706).
1. All the ROIs are shifted by half a pixel compared to Detectron in order to create better image-feature-map alignment.
See `layers/roi_align.py` for details.
To enable the old behavior, use `ROIAlign(aligned=False)`, or `POOLER_TYPE=ROIAlign` instead of
`ROIAlignV2` (the default).
1. The ROIs are not required to have a minimum size of 1.
This will lead to tiny differences in the output, but should be negligible.
- Mask inference function is different.
In Detectron2, the "paste_mask" function is different and should be more accurate than in Detectron. This change
can improve mask AP on COCO by ~0.5% absolute.
There are some other differences in training as well, but they won't affect
model-level compatibility. The major ones are:
- We fixed a [bug](https://github.com/facebookresearch/Detectron/issues/459) in
Detectron, by making `RPN.POST_NMS_TOPK_TRAIN` per-image, rather than per-batch.
The fix may lead to a small accuracy drop for a few models (e.g. keypoint
detection) and will require some parameter tuning to match the Detectron results.
- For simplicity, we change the default loss in bounding box regression to L1 loss, instead of smooth L1 loss.
We have observed that this tends to slightly decrease box AP50 while improving box AP for higher
overlap thresholds (and leading to a slight overall improvement in box AP).
- We interpret the coordinates in COCO bounding box and segmentation annotations
as coordinates in range `[0, width]` or `[0, height]`. The coordinates in
COCO keypoint annotations are interpreted as pixel indices in range `[0, width - 1]` or `[0, height - 1]`.
Note that this affects how flip augmentation is implemented.
We will later share more details and rationale behind the above mentioned issues
about pixels, coordinates, and "+1"s.
## Compatibility with Caffe2
As mentioned above, despite the incompatibilities with Detectron, the relevant
ops have been implemented in Caffe2.
Therefore, models trained with detectron2 can be converted in Caffe2.
See [Deployment](../tutorials/deployment.md) for the tutorial.
## Compatibility with TensorFlow
Most ops are available in TensorFlow, although some tiny differences in
the implementation of resize / ROIAlign / padding need to be addressed.
A working conversion script is provided by [tensorpack FasterRCNN](https://github.com/tensorpack/tensorpack/tree/master/examples/FasterRCNN/convert_d2)
to run a standard detectron2 model in TensorFlow.
# Contributing to detectron2
## Issues
We use GitHub issues to track public bugs and questions.
Please make sure to follow one of the
[issue templates](https://github.com/facebookresearch/detectron2/issues/new/choose)
when reporting any issues.
Facebook has a [bounty program](https://www.facebook.com/whitehat/) for the safe
disclosure of security bugs. In those cases, please go through the process
outlined on that page and do not file a public issue.
## Pull Requests
We actively welcome your pull requests.
However, if you're adding any significant features (e.g. > 50 lines), please
make sure to have a corresponding issue to discuss your motivation and proposals,
before sending a PR. We do not always accept new features, and we take the following
factors into consideration:
1. Whether the same feature can be achieved without modifying detectron2.
Detectron2 is designed so that you can implement many extensions from the outside, e.g.
those in [projects](https://github.com/facebookresearch/detectron2/tree/master/projects).
If some part is not as extensible, you can also bring up the issue to make it more extensible.
2. Whether the feature is potentially useful to a large audience, or only to a small portion of users.
3. Whether the proposed solution has a good design / interface.
4. Whether the proposed solution adds extra mental/practical overhead to users who don't
need such feature.
5. Whether the proposed solution breaks existing APIs.
When sending a PR, please do:
1. If a PR contains multiple orthogonal changes, split it to several PRs.
2. If you've added code that should be tested, add tests.
3. For PRs that need experiments (e.g. adding a new model or new methods),
you don't need to update model zoo, but do provide experiment results in the description of the PR.
4. If APIs are changed, update the documentation.
5. Make sure your code lints with `./dev/linter.sh`.
## Contributor License Agreement ("CLA")
In order to accept your pull request, we need you to submit a CLA. You only need
to do this once to work on any of Facebook's open source projects.
Complete your CLA here: <https://code.facebook.com/cla>
## License
By contributing to detectron2, you agree that your contributions will be licensed
under the LICENSE file in the root directory of this source tree.
Notes
======================================
.. toctree::
:maxdepth: 2
benchmarks
compatibility
contributing
changelog
# Read the docs:
The latest documentation built from this directory is available at [detectron2.readthedocs.io](https://detectron2.readthedocs.io/).
Documents in this directory are not meant to be read on github.
# Setup Builtin Datasets
Detectron2 has builtin support for a few datasets.
The datasets are assumed to exist in a directory specified by the environment variable
`DETECTRON2_DATASETS`.
Under this directory, detectron2 expects to find datasets in the structure described below.
You can set the location for builtin datasets by `export DETECTRON2_DATASETS=/path/to/datasets`.
If left unset, the default is `./datasets` relative to your current working directory.
The [model zoo](https://github.com/facebookresearch/detectron2/blob/master/MODEL_ZOO.md)
contains configs and models that use these builtin datasets.
## Expected dataset structure for COCO instance/keypoint detection:
```
coco/
annotations/
instances_{train,val}2017.json
person_keypoints_{train,val}2017.json
{train,val}2017/
# image files that are mentioned in the corresponding json
```
You can use the 2014 version of the dataset as well.
Some of the builtin tests (`dev/run_*_tests.sh`) uses a tiny version of the COCO dataset,
which you can download with `./prepare_for_tests.sh`.
## Expected dataset structure for PanopticFPN:
```
coco/
annotations/
panoptic_{train,val}2017.json
panoptic_{train,val}2017/ # png annotations
panoptic_stuff_{train,val}2017/ # generated by the script mentioned below
```
Install panopticapi by:
```
pip install git+https://github.com/cocodataset/panopticapi.git
```
Then, run `python prepare_panoptic_fpn.py`, to extract semantic annotations from panoptic annotations.
## Expected dataset structure for LVIS instance segmentation:
```
coco/
{train,val,test}2017/
lvis/
lvis_v0.5_{train,val}.json
lvis_v0.5_image_info_test.json
```
Install lvis-api by:
```
pip install git+https://github.com/lvis-dataset/lvis-api.git
```
Run `python prepare_cocofied_lvis.py` to prepare "cocofied" LVIS annotations for evaluation of models trained on the COCO dataset.
## Expected dataset structure for cityscapes:
```
cityscapes/
gtFine/
train/
aachen/
color.png, instanceIds.png, labelIds.png, polygons.json,
labelTrainIds.png
...
val/
test/
leftImg8bit/
train/
val/
test/
```
Install cityscapes scripts by:
```
pip install git+https://github.com/mcordts/cityscapesScripts.git
```
Note: labelTrainIds.png are created using cityscapesescript with:
```
CITYSCAPES_DATASET=$DETECTRON2_DATASETS/cityscapes python cityscapesscripts/preparation/createTrainIdLabelImgs.py
```
They are not needed for instance segmentation.
## Expected dataset structure for Pascal VOC:
```
VOC20{07,12}/
Annotations/
ImageSets/
Main/
trainval.txt
test.txt
# train.txt or val.txt, if you use these splits
JPEGImages/
```
# Configs
Detectron2 provides a key-value based config system that can be
used to obtain standard, common behaviors.
Detectron2's config system uses YAML and [yacs](https://github.com/rbgirshick/yacs).
In addition to the [basic operations](../modules/config.html#detectron2.config.CfgNode)
that access and update a config, we provide the following extra functionalities:
1. The config can have `_BASE_: base.yaml` field, which will load a base config first.
Values in the base config will be overwritten in sub-configs, if there are any conflicts.
We provided several base configs for standard model architectures.
2. We provide config versioning, for backward compatibility.
If your config file is versioned with a config line like `VERSION: 2`,
detectron2 will still recognize it even if we change some keys in the future.
"Config" is a very limited abstraction.
We do not expect all features in detectron2 to be available through configs.
If you need something that's not available in the config space,
please write code using detectron2's API.
### Basic Usage
Some basic usage of the `CfgNode` object is shown here. See more in [documentation](../modules/config.html#detectron2.config.CfgNode).
```python
from detectron2.config import get_cfg
cfg = get_cfg() # obtain detectron2's default config
cfg.xxx = yyy # add new configs for your own custom components
cfg.merge_from_file("my_cfg.yaml") # load values from a file
cfg.merge_from_list(["MODEL.WEIGHTS", "weights.pth"]) # can also load values from a list of str
print(cfg.dump()) # print formatted configs
```
Many builtin tools in detectron2 accepts command line config overwrite:
Key-value pairs provided in the command line will overwrite the existing values in the config file.
For example, [demo.py](../../demo/demo.py) can be used with
```
./demo.py --config-file config.yaml [--other-options] \
--opts MODEL.WEIGHTS /path/to/weights INPUT.MIN_SIZE_TEST 1000
```
To see a list of available configs in detectron2 and what they mean,
check [Config References](../modules/config.html#config-references)
### Best Practice with Configs
1. Treat the configs you write as "code": avoid copying them or duplicating them; use `_BASE_`
to share common parts between configs.
2. Keep the configs you write simple: don't include keys that do not affect the experimental setting.
3. Keep a version number in your configs (or the base config), e.g., `VERSION: 2`,
for backward compatibility.
We print a warning when reading a config without version number.
The official configs do not include version number because they are meant to
be always up-to-date.
# Use Custom Dataloaders
## How the Existing Dataloader Works
Detectron2 contains a builtin data loading pipeline.
It's good to understand how it works, in case you need to write a custom one.
Detectron2 provides two functions
[build_detection_{train,test}_loader](../modules/data.html#detectron2.data.build_detection_train_loader)
that create a default data loader from a given config.
Here is how `build_detection_{train,test}_loader` work:
1. It takes the name of a registered dataset (e.g., "coco_2017_train") and loads a `list[dict]` representing the dataset items
in a lightweight, canonical format. These dataset items are not yet ready to be used by the model (e.g., images are
not loaded into memory, random augmentations have not been applied, etc.).
Details about the dataset format and dataset registration can be found in
[datasets](./datasets.md).
2. Each dict in this list is mapped by a function ("mapper"):
* Users can customize this mapping function by specifying the "mapper" argument in
`build_detection_{train,test}_loader`. The default mapper is [DatasetMapper](../modules/data.html#detectron2.data.DatasetMapper).
* The output format of such function can be arbitrary, as long as it is accepted by the consumer of this data loader (usually the model).
The outputs of the default mapper, after batching, follow the default model input format documented in
[Use Models](./models.html#model-input-format).
* The role of the mapper is to transform the lightweight, canonical representation of a dataset item into a format
that is ready for the model to consume (including, e.g., read images, perform random data augmentation and convert to torch Tensors).
If you would like to perform custom transformations to data, you often want a custom mapper.
3. The outputs of the mapper are batched (simply into a list).
4. This batched data is the output of the data loader. Typically, it's also the input of
`model.forward()`.
## Write a Custom Dataloader
Using a different "mapper" with `build_detection_{train,test}_loader(mapper=)` works for most use cases
of custom data loading.
For example, if you want to resize all images to a fixed size for Mask R-CNN training, write this:
```python
from detectron2.data import build_detection_train_loader
from detectron2.data import transforms as T
from detectron2.data import detection_utils as utils
def mapper(dataset_dict):
# Implement a mapper, similar to the default DatasetMapper, but with your own customizations
dataset_dict = copy.deepcopy(dataset_dict) # it will be modified by code below
image = utils.read_image(dataset_dict["file_name"], format="BGR")
image, transforms = T.apply_transform_gens([T.Resize((800, 800))], image)
dataset_dict["image"] = torch.as_tensor(image.transpose(2, 0, 1).astype("float32"))
annos = [
utils.transform_instance_annotations(obj, transforms, image.shape[:2])
for obj in dataset_dict.pop("annotations")
if obj.get("iscrowd", 0) == 0
]
instances = utils.annotations_to_instances(annos, image.shape[:2])
dataset_dict["instances"] = utils.filter_empty_instances(instances)
return dataset_dict
data_loader = build_detection_train_loader(cfg, mapper=mapper)
# use this dataloader instead of the default
```
Refer to [API documentation of detectron2.data](../modules/data) for details.
If you want to change not only the mapper (e.g., to write different sampling or batching logic),
you can write your own data loader. The data loader is simply a
python iterator that produces [the format](./models.md) your model accepts.
You can implement it using any tools you like.
## Use a Custom Dataloader
If you use [DefaultTrainer](../modules/engine.html#detectron2.engine.defaults.DefaultTrainer),
you can overwrite its `build_{train,test}_loader` method to use your own dataloader.
See the [densepose dataloader](../../projects/DensePose/train_net.py)
for an example.
If you write your own training loop, you can plug in your data loader easily.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment