-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Enhancement] Lower the restrictions of _resize method in BaseMergeCell #1959
[Enhancement] Lower the restrictions of _resize method in BaseMergeCell #1959
Conversation
Fix the bug met in using nasfpn which is mentioned at open-mmlab/mmdetection#5987. Avoid the strong restrictions of _resize function in BaseMergeCell: 1. When Downsampling the feature map, the feature map's shape must be divisible by the target size. We pad zero around feature map before max_pool2d opt to make it always divisible. (line 102 ~ 107) 2. Considering the different downsampling scale of H and W, shape[-2] and shape[-1] are involed in the definition of kernel_size. (line 110)
check flake8 & isort
mmcv/ops/merge_cells.py
Outdated
x = nn.ConstantPad2d( | ||
(padding_left, padding_right, padding_top, padding_bottom), | ||
0)( | ||
x) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we use F.pad
instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your suggestion, I will use the func from F replacing the one from nn.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your contribution! It could be better to add a unit test in tests/test_ops/test_merge_cell.py
to test the case that x1
or x2
cannot be devised by size
X_pad rename to padding_x Co-authored-by: Mashiro <57566630+HAOCHENYE@users.noreply.github.com>
format the code style after renameing the X_pad to padding_x
Mainly test the downsampling resize in BaseMergeCell. The smaller target size is set to (14, 7), the classical feature map's size in the last few stages of the backbone, which will product different downsampling scales in different dims.
add "# Copyright (c) OpenMMLab. All rights reserved."
@HAOCHENYE Why the unit_test, run lasted 22h, hasn't finished? Is there anything wrong with my code? |
mmcv/ops/merge_cells.py
Outdated
if x.shape[-2] % size[-2] != 0 or x.shape[-1] % size[-1] != 0: | ||
h, w = x.shape[-2:] | ||
h_t, w_t = size | ||
padding_h = (h // h_t + 1) * h_t - h | ||
padding_w = (w // w_t + 1) * w_t - w | ||
padding_left = padding_w // 2 | ||
padding_right = padding_w - padding_left | ||
padding_top = padding_h // 2 | ||
padding_bottom = padding_h - padding_top | ||
pad = (padding_left, padding_right, padding_top, | ||
padding_bottom) | ||
x = F.pad(x, pad, mode='constant', value=0.0) | ||
kernel_size = (x.shape[-2] // size[-2], x.shape[-1] // size[-1]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggest to keep naming rule consistent. Here we define padding_right
with full name "right" but padding_h
with Abbreviations h
。It could be better to rename padding_h
to padding_heigth
and padding_w
to padding_width
. Besides, does h_t
mean target height? If so, target_height
could be better.
tests/test_ops/test_merge_cells.py
Outdated
inputs_x = torch.randn([2, 256, 32, 32]) | ||
inputs_x = torch.randn([2, 256, 14, 7]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It could be better to test SumCell
and ConcatCell
with divisible and indivisible both
tests/test_ops/test_merge_cells.py
Outdated
"""resize to a smaller size by which the inputs_x can't be divisible. | ||
And There're different downsample scale on dim H & dim W. | ||
""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be comment like # resize to a smaller...
but not docstring starts with """
tests/test_ops/test_merge_cells.py
Outdated
"""resize to a smaller size by which the inputs_x can't be divisible. | ||
And There're different downsample scale on dim H & dim W. | ||
""" | ||
target_size = (14, 7) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should test divisible and indivisible size both.
format the variable name
Testing divisible and indivisible situations simultaneously
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
fix the bug when h is indivisible and w is divisible, the pad_w will be padded unreasonable. Co-authored-by: Zaida Zhou <58739961+zhouzaida@users.noreply.github.com>
fix the bug when w is indivisible and h is divisible, the pad_h will be padded unreasonable. Co-authored-by: Zaida Zhou <58739961+zhouzaida@users.noreply.github.com>
Hi, lint failed. After fixing the lint and refactoring the unit tests with |
make pad_h, pad_w more readable
use @pytest.mark.parametrize instead of 'for' methor
isort
…ll (open-mmlab#1959) * Fix the bug met in using nasfpn Fix the bug met in using nasfpn which is mentioned at open-mmlab/mmdetection#5987. Avoid the strong restrictions of _resize function in BaseMergeCell: 1. When Downsampling the feature map, the feature map's shape must be divisible by the target size. We pad zero around feature map before max_pool2d opt to make it always divisible. (line 102 ~ 107) 2. Considering the different downsampling scale of H and W, shape[-2] and shape[-1] are involed in the definition of kernel_size. (line 110) * Update merge_cells.py check flake8 & isort * Update merge_cells.py * Update merge_cells.py yapf * Update mmcv/ops/merge_cells.py X_pad rename to padding_x Co-authored-by: Mashiro <57566630+HAOCHENYE@users.noreply.github.com> * Update merge_cells.py format the code style after renameing the X_pad to padding_x * Update test_merge_cells.py Mainly test the downsampling resize in BaseMergeCell. The smaller target size is set to (14, 7), the classical feature map's size in the last few stages of the backbone, which will product different downsampling scales in different dims. * Update test_merge_cells.py add "# Copyright (c) OpenMMLab. All rights reserved." * Update merge_cells.py format the variable name * Update test_merge_cells.py Testing divisible and indivisible situations simultaneously * Update mmcv/ops/merge_cells.py fix the bug when h is indivisible and w is divisible, the pad_w will be padded unreasonable. Co-authored-by: Zaida Zhou <58739961+zhouzaida@users.noreply.github.com> * Update mmcv/ops/merge_cells.py fix the bug when w is indivisible and h is divisible, the pad_h will be padded unreasonable. Co-authored-by: Zaida Zhou <58739961+zhouzaida@users.noreply.github.com> * fix undefined error * Update merge_cells.py make pad_h, pad_w more readable * Update test_merge_cells.py use @pytest.mark.parametrize instead of 'for' methor * Update merge_cells.py * Update test_merge_cells.py isort * Update merge_cells.py isort Co-authored-by: Mashiro <57566630+HAOCHENYE@users.noreply.github.com> Co-authored-by: Zaida Zhou <58739961+zhouzaida@users.noreply.github.com>
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
Fix the bug met in using nasfpn which is mentioned at open-mmlab/mmdetection#3401.
Modification
Avoid the strong restrictions of _resize function in BaseMergeCell:
BC-breaking (Optional)
Does the modification introduce changes that break the backward-compatibility of the downstream repositories?
If so, please describe how it breaks the compatibility and how the downstream projects should modify their code to keep compatibility with this PR.
Use cases (Optional)
If this PR introduces a new feature, it is better to list some use cases here, and update the documentation.
Checklist
Before PR: