Обновить
Комментарии 9
О, я как раз портировал на свой TensorFlow for C#: github.com/losttech/YOLOv4 (пока не оттестировано и использует невыпущенные версии библиотек)
Кстати, не могли бы Вы написать развёрнутый пост про Darknet? Как просто на нём написать, например, Actor-Critic. Интересует практика использования для research и (если есть опыт) сравнение с TF/Pytorch. Плюс небольшой туториал на примере простой сети какой-нибудь.
Ссылка на пайторч ведёт на пустой репозиторий.
В нем есть ссылкочки на Branch-и. Добавил их в статью.

Красачики, поздравляю :)


Учитывая, что mAP 50 на СОСО всего лишь чуть больше года назад пробили, 55 на быстрой сеточке — вообще кайф.

AlexeyAB, можете пояснить, почему ранее координаты предсказывались следующим образом:
bx=σ(tx)+cx; by=σ(ty)+cy; bw=pw*e^tw; bh=ph*e^th.
Сейчас, согласно этому:
bx=2*σ(tx)-0.5+cx; by=2*σ(ty)-0.5+cy; bw=pw*(2*σ(tw))^2; bh=ph*(2*σ(th))^2 так?
1. Про координаты x,y:
Раньше bx=σ(tx)+cx; by=σ(ty)+cy;
Теперь bx=2*σ(tx)-0.5+cx; by=2*σ(ty)-0.5+cy;
Раньше требовало бесконечно больших значения для tx или ty чтобы объект поместить на границу ячейки. Теперь же достаточно чтобы tx ~= 1 или ty ~= 1. Page 8, para 4.3 arxiv.org/pdf/2004.10934.pdf



2. Про координаты w,h:
Раньше bw=pw*e^tw; bh=ph*e^th
Теперь bw=pw*(2*σ(tw))^2; bh=ph*(2*σ(th))^2

Раньше, производная была слишком большая при tw>1 или th>1 — экспоненциальная зависимость. Из-за этого вся сеть оптимизировалась в основном только под W и H.
— В YOLOv3 этой проблемы почти не было, т.к. использовался только 1 ближайший анкер, поэтому tw и th были близки к 1.
— В YOLOv4 используются несколько анкеров для одного объекта, если IoU > 0.2 (20%), поэтому может быть tw~=4 th~=4 — это генерирует дельту exp(4)=54.6, в то время как остальные дельты около [0 — 1]. Поэтому ширина и высота объекта перетягивает одеяло на себя.

Можно было использовать (4*σ(x)) вместо (2*σ(x))^2, но во втором варианте функция проходит через 1 при x=0, что лучше, т.к. x изначально инициализируется 0+-малое значение, и w,h тогда будут равны анкеру — а анкеры это наиболее часто встречаемые размеры объектов.

Как работает iou_thresh: У нас используется iou_thresh=0.2, т.е. если предположим
— ground_truth w=100 h=100 (square area=10000)
— и anchor w=45 h=45 (square area=2025)
то IoU = 2025/10000 = 0.2025 — это значение проходит порог iou_thresh=0.2, а значит этот anchor будет использоваться для этого ground_truth. Но анкеры с w и h ниже этих значения — не будут использоваться.

Соответственно для ground_truth(w=100 h=100) нам надо увеличить анкер
— для квадратных объектов (w=45 h=45) максимум в ~2.2 раза (увеличить w и h)
— для прямоугольных (w=90 h=23) максимум в ~4.3 раза (увеличить h) — вот здесь может быть небольшая проблема, т.к. 4.3 > 4.0

Спасибо за ответ. Жаль, что в статье не было сказано про w и h.
А есть еще более производительные конфигрурации под CPU?

Интересна детекция при разрешении ~1024x512(достаточно мелкие объекты диктуют такой размер входа).
И при этом ~50FPS на Xeon 4210R.
Инференс на openvino int8.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.