[Fix] Fix the dimension and yaw hack of FCOS3D on nuScenes

[Tai-Wang]

Thanks for your contribution and we appreciate it a lot. The following instructions would make your pull request more healthy and more easily get feedback. If you do not understand some items, don't worry, just make the pull request and seek help from maintainers.

Motivation

Please describe the motivation of this PR and the goal you want to achieve through this PR.
Due to inconsistent definition of nuscbox and our cambox, the transformation of dimension and yaw is required in the pre-processing and post-processing.

Modification

Please briefly describe what modification is made in this PR.

1. Dimension and yaw transformed to our cambox in the pre-processing.
2. Corresponding transformation in the post-processing functions.
3. Because the yaw angle defined in our cambox is the global yaw instead of local yaw, we move the transformation in the kitti/nuscenes mono dataset into get_target_3d of fcos3d head.
4. Fix the minor errors caused by the change of cam_intrinsic when applying RandomFlip3D.
5. Remove the hack in the mono3d visualization code.

BC-breaking (Optional)

Does the modification introduce changes that break the back-compatibility of the downstream repos?
If so, please describe how it breaks the compatibility and how the downstream projects should modify their code to keep compatibility with this PR.
Json files of nuScenes and KITTI datasets need to be regenerated.

Use cases (Optional)

If this PR introduces a new feature, it is better to list some use cases here, and update the documentation.

Checklist

1. Pre-commit or other linting tools are used to fix the potential lint issues.
2. The modification is covered by complete unit tests. If not, please add more unit test to ensure the correctness.
3. If the modification has potential influence on downstream projects, this PR should be tested with downstream projects.
4. The documentation has been modified accordingly, like docstring or example tutorials.

[Wuziyi616]

Good job! Can we verify the correctness by doing some visualizations? It would be great if you can post results in demo, browse_dataset and visualization while doing model inference below.

[codecov]

Codecov Report

Merging #744 (8c3ae13) into master (0369fa5) will decrease coverage by 0.50%.
The diff coverage is 47.45%.

❗ Current head 8c3ae13 differs from pull request most recent head a8a432c. Consider uploading reports for the commit a8a432c to get more accurate results

@@            Coverage Diff             @@
##           master     #744      +/-   ##
==========================================
- Coverage   49.46%   48.95%   -0.51%     
==========================================
  Files         165      208      +43     
  Lines       10675    15856    +5181     
  Branches     1617     2532     +915     
==========================================
+ Hits         5280     7762    +2482     
- Misses       5078     7596    +2518     
- Partials      317      498     +181     

Flag	Coverage Δ
unittests	48.95% <47.45%> (-0.51%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
mmdet3d/core/anchor/__init__.py	100.00% <ø> (ø)
mmdet3d/core/bbox/structures/box_3d_mode.py	92.10% <ø> (ø)
mmdet3d/core/evaluation/indoor_eval.py	10.67% <0.00%> (ø)
mmdet3d/core/evaluation/kitti_utils/eval.py	32.23% <0.00%> (-0.07%)	⬇️
mmdet3d/core/points/base_points.py	83.52% <ø> (ø)
mmdet3d/core/points/cam_points.py	93.75% <ø> (ø)
mmdet3d/core/points/depth_points.py	93.75% <ø> (ø)
mmdet3d/core/points/lidar_points.py	93.75% <ø> (ø)
mmdet3d/core/post_processing/box3d_nms.py	30.23% <ø> (-21.26%)	⬇️
mmdet3d/core/visualizer/__init__.py	100.00% <ø> (ø)
... and 170 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update cbf194f...a8a432c. Read the comment docs.

[Wuziyi616]

I think we also need to update FCOS3D page with new checkpoints, and modify the compatibility docs.

[Tai-Wang]

I think we also need to update FCOS3D page with new checkpoints, and modify the compatibility docs.

Yes, that's why I add a label WIP :)

[Tai-Wang]

An example to illustrate the correction of camera intrinsic matrix in the RandomFlip3D.
The original image and the corresponding 3D bounding box:

Our image flip is typically based on the horizontal center (e.g. a 1600x900 image is flipped around u=800 pixels). However, the horizontal position of camera center in the image is typically not strictly equal to 800 (for example, sometimes 780 or 820), so it will yield errors when flipping images without manipulating the camera intrinsic matrix accordingly.
Without modifying the camera intrinsics, the visualization will be:

With our correction, it will be:

So we can see the necessity of modifying the camera intrinsics and have an intuitive feeling of the yielded error from this example.

[yezhen17]

Awesome! After this pr is merged I will check on visualization on the coordinate system refactor branch.

[yezhen17]

Awesome! After this pr is merged I will check on visualization on the coordinate system refactor branch.

Oh sorry, I should not have approved since there is still work going on.

[Isaac-xie]

@Tai-Wang Hi, I'm confused about this modification. In transfroms_3d.py I only see changes about centers_2d and cam2img.
First, the ux of cam2img is changed, but the ux change only causes the image to be panned and not flipped.
Secondly, after the image is flipped, the yaw angle is changed, doesn't this parameter need to be modified?