TAP Object Detection API MAP вычисления, казалось бы, неправильно - PullRequest
0 голосов
/ 28 января 2019

Я не уверен, является ли это недоразумением с моей стороны или ошибкой в ​​коде API обнаружения объектов TF (OD), но я решил, что сначала попробую здесь, прежде чем отправлять сообщения на github.

По сути, я сравниваю две модели в тензорной доске, красная с зеленой.Я считаю, что красная модель немного лучше в общем MAP, MAP @ .50IOU, & mAP @ .75IOU.Тем не менее, зеленый лучше для всех карт, разделенных по размеру объекта: карта большая, средняя и маленькая (см. Изображение ниже с шагом 67,5 тыс., Где синяя стрелка).

Сейчас у меня нет докторской степени по математике, но я предположил, что если модель имеет более высокое значение mAP с небольшими средними и крупными объектами, у нее должно быть более высокое общее значение mAP ...

enter image description here

Вот точные значения: (Все значения получены с шагом 67,5 тыс., Без сглаживания)

                Red     Green
mAP             .3599   .3511
mAP@.50IOU      .5670   .5489
mAP@.75IOU      .3981   .3944
mAP (large)     .5557   .7404
mAP (medium)    .3788   .3941
mAP (small)     .1093   .1386

1 Ответ

0 голосов
/ 02 июля 2019

Я думаю, что способ получить больше понимания - это проанализировать статистику количества размеров ограничивающего прямоугольника (маленький, средний, большой) в вашем наборе данных.Вот ссылка для вычисления mAP , где API обнаружения объектов TF описывает, как рассчитываются маленькие и средние блоки.

Я могу себе представить, что причина этой проблемы в том, что у вас гораздо больше ограничивающих прямоугольников среднего размера, чем у ограничивающих прямоугольников большого размера.Кроме того, я бы пренебрегал производительностью небольших ограничивающих рамок, поскольку mAP меньше 0,01.

...