Skip to content

Conversation

@ArchieAlexArkhipov
Copy link
Owner

For code review

Copy link

@zimka zimka left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Вроде все ок, никаких баг не нашел.
Но есть проблема прямоугольного представления таблиц

@@ -1,124 +1,145 @@
_base_ = [
'../_base_/datasets/coco_detection.py',
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Общее замечание: лучше либо не менять стиль оформления кодовой базы вообще, либо делать это каким-то отдельным коммитом в начале/конце PR, что бы можно было смотреть дифф без изменения форматирования

dict(type='Collect', keys=['img', 'gt_bboxes', 'gt_labels'])
test_pad_mode=None,
),
dict(type="Resize", img_scale=(512, 512), keep_ratio=True),
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

В статье raining image равен 1024

category.
loss_center_heatmap (dict | None): Config of center heatmap loss.
Default: GaussianFocalLoss.
loss_wh (dict | None): Config of wh loss. Default: L1Loss.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

не очень важно, но здесь и в других местах докстринг не соответствут аргументам

@@ -8,8 +8,7 @@
from mmdet.core import multi_apply
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Кажется дифф файла centernet_head.py только стилистический, лучше его просто откатить на мастер

for j, ct in enumerate(gt_centers):
ctx_int, cty_int = ct.int()
ctx, cty = ct
scale_box_h = (gt_bbox[j][3] - gt_bbox[j][1]) * height_ratio
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Масштабирование пятна в gt-хитмапе логично в CenterNet при детекции объектов.
Но в CenterCycleNet ведь предсказываются вершины как keypoint - только xy без wh. В таком варианте кажется нет смысла менять размер пятна.

Так и получается как раз картина, при которой углам большой ячейки соответствуют огромные пятна, а угла маленькой - маленькие.

loss_v2c=loss_v2c,
)

def get_targets(self, gt_bboxes, gt_labels, feat_shape, img_shape, c2v_pred, v2c_pred):
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Кажется, что подача данных ячеек таблицы в виде COCO-датасета приводит к некорректно реализации Cycle-CenterNet.

Из схемы Cycle-CenterNet в статье и иллюстраций однозначно видно, что сеть предсказыает не-прямоугольные ячейки таблицы.

Но здесь на вход уже подаются прямоугольные ячейки, значит для них можно создать только таргет-хитмап по прямоугольной сетке, значит сеть научится предсказывать только такой прямоугольные ячейки

)
w = 1 - torch.exp(-pi * D_cv)
pairing_weight[batch_id, 2 * idx + k, cty_int, ctx_int] += w
pairing_weight[batch_id, 2 * idx + k, v_y_int, v_x_int] += w
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Кажется, что в код написан корректно, и хотя локация соседа (v_y_in, v_x_int) появится 4 раз у ячеек-соседей, прибавление веса будет каждый раз в разные канал.
Но все же я бы здесь для теста на 1 раз поставил бы assert (pairing_weight[...] == 0), чтобы удостовериться что все ок, а затем бы заменил += на присваивание - так чуть более понятно получится

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants