You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: docs/registry.md
+98-20
Original file line number
Diff line number
Diff line change
@@ -9,40 +9,29 @@ In MMCV, registry can be regarded as a mapping that maps a class to a string.
9
9
These classes contained by a single registry usually have similar APIs but implement different algorithms or support different datasets.
10
10
With the registry, users can find and instantiate the class through its corresponding string, and use the instantiated module as they want.
11
11
One typical example is the config systems in most OpenMMLab projects, which use the registry to create hooks, runners, models, and datasets, through configs.
12
+
The API reference could be find [here](https://mmcv.readthedocs.io/en/latest/api.html?highlight=registry#mmcv.utils.Registry).
12
13
13
14
To manage your modules in the codebase by `Registry`, there are three steps as below.
14
15
15
-
1. Create an registry
16
-
2. Create a build method
17
-
3. Use this registry to manage the modules
16
+
1. Create a build method (optional, in most cases you can just use the default one).
17
+
2. Create a registry.
18
+
3. Use this registry to manage the modules.
19
+
20
+
`build_func` argument of `Registry` is to customize how to instantiate the class instance, the default one is `build_from_cfg` implemented [here](https://mmcv.readthedocs.io/en/latest/api.html?highlight=registry#mmcv.utils.build_from_cfg).
18
21
19
22
### A Simple Example
20
23
21
24
Here we show a simple example of using registry to manage modules in a package.
22
25
You can find more practical examples in OpenMMLab projects.
23
26
24
27
Assuming we want to implement a series of Dataset Converter for converting different formats of data to the expected data format.
25
-
We create directory as a package named `converters`.
28
+
We create a directory as a package named `converters`.
26
29
In the package, we first create a file to implement builders, named `converters/builder.py`, as below
27
30
28
31
```python
29
32
from mmcv.utils import Registry
30
-
31
33
# create a registry for converters
32
34
CONVERTERS= Registry('converter')
33
-
34
-
35
-
# create a build function
36
-
defbuild_converter(cfg, *args, **kwargs):
37
-
cfg_ = cfg.copy()
38
-
converter_type = cfg_.pop('type')
39
-
if converter_type notinCONVERTERS:
40
-
raiseKeyError(f'Unrecognized task type {converter_type}')
Note: in this example, we demonstrate how to use the `build_func` argument to customize the way to build a class instance.
89
+
The functionality is similar to the default `build_from_cfg`. In most cases, default one would be sufficient.
90
+
`build_model_from_cfg` is also implemented to build PyTorch module in `nn.Sequentail`, you may directly use them instead of implementing by yourself.
91
+
92
+
## Hierarchy Registry
93
+
94
+
You could also build modules from more than one OpenMMLab frameworks, e.g. you could use all backbones in [MMClassification](https://github.com/open-mmlab/mmclassification) for object detectors in [MMDetection](https://github.com/open-mmlab/mmdetection), you may also combine an object detection model in [MMDetection](https://github.com/open-mmlab/mmdetection) and semantic segmentation model in [MMSegmentation](https://github.com/open-mmlab/mmsegmentation).
95
+
96
+
All `MODELS` registries of downstream codebases are children registries of MMCV's `MODELS` registry.
97
+
Basically, there are two ways to build a module from child or sibling registries.
98
+
99
+
1. Build from children registries.
100
+
101
+
For example:
102
+
103
+
In MMDetection we define:
104
+
105
+
```python
106
+
from mmcv.utils import Registry
107
+
from mmcv.cnn importMODELSasMMCV_MODELS
108
+
MODELS= Registry('model', parent=MMCV_MODELS)
109
+
110
+
@MODELS.register_module()
111
+
classNetA(nn.Module):
112
+
defforward(self, x):
113
+
return x
114
+
```
115
+
116
+
In MMClassification we define:
117
+
118
+
```python
119
+
from mmcv.utils import Registry
120
+
from mmcv.cnn importMODELSasMMCV_MODELS
121
+
MODELS= Registry('model', parent=MMCV_MODELS)
122
+
123
+
@MODELS.register_module()
124
+
classNetB(nn.Module):
125
+
defforward(self, x):
126
+
return x +1
127
+
```
128
+
129
+
We could build two net in either MMDetection or MMClassification by:
130
+
131
+
```python
132
+
from mmdet.models importMODELS
133
+
net_a =MODELS.build(cfg=dict(type='NetA'))
134
+
net_b =MODELS.build(cfg=dict(type='mmcls.NetB'))
135
+
```
136
+
137
+
or
138
+
139
+
```python
140
+
from mmcls.models importMODELS
141
+
net_a =MODELS.build(cfg=dict(type='mmdet.NetA'))
142
+
net_b =MODELS.build(cfg=dict(type='NetB'))
143
+
```
144
+
145
+
2. Build from parent registry.
146
+
147
+
The shared `MODELS` registry in MMCV is the parent registry for all downstream codebases (root registry):
0 commit comments