Aumento de Bounding Box em Detecção: Formatos, Erros e Melhores Práticas

Um artigo publicado na plataforma Habr é dedicado a uma razão comum e frequentemente ignorada para falhas no treinamento de modelos de detecção de objetos: não a própria arquitetura de rede, mas o que acontece com caixas delimitadoras (bbox) — retângulos de anotação — após as ampliações serem aplicadas.

Onde o marcado se quebra com mais frequência

O autor lista erros típicos que não causam falha de código com uma exceção, mas silenciosamente corrompem o conjunto de dados de treinamento: formato de coordenadas especificado incorretamente (coord_format), confusão entre coordenadas normalizadas e absolutas, operações de corte muito agressivas e o aparecimento de caixas vazias após filtrar objetos que saíram do quadro. Tais erros não causam uma falha explícita do pipeline — o modelo simplesmente treina em marcação distorcida, e a queda de qualidade resultante é atribuída à arquitetura ou hiperparâmetros, embora a causa esteja no pré-processamento.

O problema é agravado pelo fato de que diferentes conjuntos de dados e diferentes bibliotecas historicamente usam diferentes convenções para armazenar coordenadas de bbox: às vezes são coordenadas de pixel absoluto dos cantos superior esquerdo e inferior direito, às vezes valores normalizados de zero a um relativos às dimensões da imagem, e às vezes — coordenadas do centro da caixa junto com largura e altura. Basta confundir essas representações uma vez ao passar marcação entre estágios do pipeline para o treinamento continuar sem erros, mas o modelo aprende a encontrar objetos não onde realmente estão na imagem.

• Biblioteca discutida: Albumentations
• Formatos de bbox suportados: COCO, YOLO, pascal_voc
• Parâmetros principais: A.BboxParams, min_area, min_visibility
• Problema típico: RandomCrop frequentemente funciona mal para tarefas de detecção
• Fonte: Habr

Como configurar corretamente Albumentations?

O artigo analisa o lado prático da questão usando o exemplo da biblioteca Albumentations — uma das ferramentas mais comuns de aumento de imagem em visão computacional. Discute os formatos de bbox suportados pela biblioteca, configuração correta do parâmetro A.BboxParams, bem como o propósito dos parâmetros min_area e min_visibility, que determinam o tamanho mínimo ou a visibilidade de um objeto após transformação para que a bbox seja considerada válida em vez de descartada ou distorcida.

Albumentations é amplamente usada precisamente porque pode transformar sincronicamente uma imagem e sua marcação associada — ao girar, refletir ou alterar a escala de uma imagem, a biblioteca recalcula automaticamente as coordenadas de todos os bbox nela, poupando ao desenvolvedor a necessidade de escrever essa lógica manualmente. Mas essa mesma automação se torna uma fonte de problemas se os parâmetros de A.BboxParams forem definidos incorretamente: a biblioteca não produzirá um erro, simplesmente recalculará as coordenadas de acordo com o formato especificado (mesmo que incorreto), e o desenvolvedor obterá um pipeline de aumento formalmente correto, mas de fato corrompido.

Por que RandomCrop nem sempre é uma opção segura

Atenção especial no material é dedicada ao motivo pelo qual RandomCrop comum — um aumento popular para classificação de imagem — frequentemente se mostra uma solução ruim especificamente para detecção de objetos. Quando um quadro é cortado aleatoriamente, objetos nas bordas podem ser cortados parcial ou completamente, e sem filtragem posterior cuidadosa através de min_area e min_visibility, a marcação contém caixas distorcidas ou caixas completamente vazias, que o modelo percebe como dados de treinamento válidos.

O material é dirigido para quem trabalha com formatos de marcação populares COCO, YOLO e pascal_voc e quer entender por que as ampliações "não funcionam" — ou seja, por que adicionar transformações padrão prontas para uso não melhora, e às vezes até piora, as métricas do modelo. O valor prático de tal análise é que ela muda o foco de depuração de hiperparâmetros e arquiteturas para uma fonte muito mais mundana, mas frequente de problemas — a correção das transformações geométricas da marcação, que especialistas em visão computacional frequentemente subestimam no início de um projeto.

Para equipes que trabalham com conjuntos de dados de marcação industrial, tal análise é especialmente valiosa no estágio de transição entre formatos: por exemplo, quando os dados são marcados em formato COCO, mas o treinamento é conduzido em uma arquitetura que espera formato YOLO, ou vice-versa. Conversão manual entre tais formatos é uma fonte frequente de erros esquivos, e o material essencialmente oferece uma lista de verificação de coisas que valem a pena verificar antes de atribuir a baixa qualidade do modelo à própria arquitetura ou falta de dados.