How to change the parameter value of this Anchor in the pkl file
xiongjiuli opened this issue · comments
in the /.../nndetection_data/Task101_lymphnode/det_models/Task101_lymphnode/RetinaUNetV001_D3V001_3d/fold0/plan.pkl
the output about the anchor:
Key: anchors, Value: {'width': [(23.0, 37.0, 53.0), (46.0, 74.0, 106.0), (92.0, 148.0, 212.0), (92.0, 148.0, 212.0)], 'height': [(8.0, 11.0, 19.0), (16.0, 22.0, 38.0), (32.0, 44.0, 76.0), (64.0, 88.0, 152.0)], 'depth': [(15.0, 20.0, 18.0), (30.0, 40.0, 36.0), (60.0, 80.0, 72.0), (120.0, 160.0, 144.0)], 'stride': 1}
My object label is generally small, WHD is generally about (8-20), so my anchor value is very small, but the boxes in the final results are very large, and then I found that the anchor value in the pkl file is very large, so I want to change the initial anchor value.
Q1: How to change the parameter value of this Anchor in the pkl file? Do I just read this pkl file and modify it and save it?
Q2: But isn't nndetection free to choose the best hyperparameters? Why does anchor's initialization not match my dataset so well
thx a lot!
Hey,
Q1: yes, you can simply load, modify and save again :)
Q2: The axis names are a bit off here since I initially followed the torchvision parameter naming but switched the axes at some point. width, height, depth are mapped to z,y,x in the code.
The sizes of the first level of anchors is the grid where the anchors are the most dense and thus the sizes there are pretty close to the mean size of the objects in your dataset, usually with deviations towards the upper and lower end of the spectrum. height and depth thus seem quite reasonable. For deeper levels, the anchor sizes simply follow the strides of the network, i.e. if the anchor has a size of 4 on level 1 and there is a stride 2 pooling it will have size 8 on level 2 -> the last levels get really large and only very few objects are mapped to those anchors.
In general, the anchors are determined via an heuristic (i.e. the anchors are chosen such that on average the largest IoU between them and ground truth objects is achieved) which works well in the vast majority of cases but might fail in some rare instances. I think it might be worth a try to check out a smaller anchor initialisation in your case. Note: Since ATSS is used as the matcher, the dependence on very accurate anchors sizes is slightly reduced in nnDetection since it determined the IoU threshold during training varies dynamically.
Best,
Michael
This issue is stale because it has been open for 30 days with no activity.