Мелкие объекты теряются: как проверить датасет до смены детектора

Если детектор пропускает мелкие детали, сначала измерьте, какие объекты остаются видимыми на входе модели. Разберём размерные срезы recall и выберем следующий эксперимент.

Размер исходного файла ещё не размер объекта

На камере видны крупные коробки и маленькие этикетки. Общий recall приемлемый, но важные для проверки этикетки постоянно теряются. Замена детектора кажется естественным шагом. Перед ней стоит посмотреть, сколько пикселей занимает этикетка после подготовки входа: исходный кадр мог уменьшаться в несколько раз.

Для каждой размеченной рамки сохраните ширину и высоту в исходных пикселях, а затем пересчитайте их после масштабирования изображения. При сохранении пропорций обе стороны умножаются на один коэффициент; padding сам размер объекта не меняет. Если изображение растягивается по осям, коэффициенты будут разными. Анализ должен повторять настоящий preprocessing.

Группы размеров задавайте по смыслу задачи либо по явно записанным границам. Термины small/medium/large в стандартном COCO-отчёте имеют собственное определение площади. Если вы вводите «мелкий объект — сторона меньше восьми пикселей на входе», назовите это локальным срезом, чтобы его не перепутали с COCO AP small.

Посчитаем recall по уже сопоставленным объектам

Предположим, для каждой истинной рамки уже определено, нашлась ли соответствующая детекция при фиксированных классе, пороге уверенности и IoU. Это сопоставление должно быть взаимно однозначным: одна рамка прогноза не закрывает два объекта. В примере используем готовый результат matched, чтобы сосредоточиться на размерном отчёте.

Кадр шириной 1920 пикселей уменьшается до 640. Из шести объектов первые три становятся меньше восьми пикселей по короткой стороне. Проверим их полноту отдельно. Численность истинных объектов идёт в знаменатель, поэтому пропуски не исчезнут из отчёта.

objects = [(12, 15, False), (18, 20, False), (21, 24, True),
           (60, 80, True), (90, 100, True), (120, 150, True)]
scale = 640 / 1920
groups = {"tiny_input": [], "other": []}
for width, height, matched in objects:
    shortest = min(width, height) * scale
    group = "tiny_input" if shortest < 8 else "other"
    groups[group].append(matched)
for group, matches in groups.items():
    recall = sum(matches) / len(matches)
    print(group, "n=", len(matches), "recall=", round(recall, 3))
assert sum(groups["tiny_input"]) == 1
assert len(groups["tiny_input"]) == 3

У tiny_input полнота 1/3, у остальных — единица. Значит, общий recall 4/6 скрывал локальный провал. Откройте уменьшенные кадры с рамками: если нужная деталь превратилась в несколько неразличимых пикселей, модели трудно восстановить информацию, которую preprocessing уже отбросил.

Следующие варианты проверяются экспериментом: больший вход, более близкая камера, тайлы исходного изображения или другой набор обучающих примеров. Тайлы сохраняют детали, но увеличивают число проходов модели и требуют объединения результатов на границах. Сравнивайте качество вместе с задержкой и количеством ложных срабатываний на целевом устройстве.

Отдельно проверьте разметку мелких объектов. На нечётких кадрах границы могут различаться на пару пикселей, что сильно меняет IoU маленькой рамки. Не снижайте критерий только ради красивого числа: согласуйте, насколько точная локализация нужна следующему действию, и используйте одинаковое правило для всех версий.

В отчёте сохраните размеры кадра, способ масштабирования, вход модели, границы локальных групп и условия сопоставления. После изменения разрешения пересчитайте эти срезы. Так вы увидите, исчез ли провал именно там, где была гипотеза, и не заплатили ли за него недопустимой задержкой.

Для следующего шага пригодится оценка точности рамок по mAP.

В платном курсе «Computer Vision Engineer: от детекции и Doc-AI до продакшна» вы готовите наборы для детекции и оцениваете модели по качеству, скорости и стоимости инференса. С такими отчётами можно обосновать изменение разрешения или способа обработки кадров. Откройте программу курса.