Aumento de dados com bounding boxes em detecção: formatos, erros e boas práticas

O Habr publicou um artigo sobre uma causa comum e pouco visível de falhas no treinamento de modelos de detecção de objetos: não a arquitetura da rede, mas o que acontece com os bounding boxes (bbox), as molduras retangulares de anotação, depois que as aumentações são aplicadas.

Onde a anotação mais costuma quebrar

O autor lista erros típicos que não derrubam o código com uma exceção, mas estragam em silêncio o conjunto de treinamento: um formato de coordenadas especificado incorretamente (coord_format), confusão entre coordenadas normalizadas e absolutas, operações de recorte agressivas demais e o surgimento de caixas vazias depois da filtragem de objetos que saíram do quadro. Esses erros não causam uma falha explícita no pipeline: o modelo simplesmente treina com rótulos distorcidos, e a queda de qualidade resultante é atribuída à arquitetura ou aos hiperparâmetros, embora a causa esteja no pré-processamento.

O problema se agrava porque datasets e bibliotecas diferentes usam, historicamente, convenções diferentes para armazenar as coordenadas dos bbox: em alguns casos são coordenadas absolutas em pixels dos cantos superior esquerdo e inferior direito, em outros são valores normalizados de zero a um em relação ao tamanho da imagem, e em outros ainda são as coordenadas do centro da caixa junto com largura e altura. Basta confundir essas representações uma única vez ao passar a anotação entre etapas do pipeline para que o treinamento continue sem erros, enquanto o modelo aprende a procurar objetos onde eles realmente não estão na imagem.

• Biblioteca analisada: Albumentations
• Formatos de bbox compatíveis: COCO, YOLO, pascal_voc
• Parâmetros-chave: A.BboxParams, min_area, min_visibility
• Problema típico: o RandomCrop costuma ser inadequado para tarefas de detecção
• Fonte: Habr

Como configurar o Albumentations corretamente?

O artigo trata do lado prático usando o Albumentations, uma das ferramentas de aumentação de imagens mais difundidas em visão computacional. Ele examina os formatos de bbox aceitos pela biblioteca, a configuração correta do A.BboxParams e a função de min_area e min_visibility, que definem o tamanho ou a visibilidade mínima que um objeto precisa manter após a transformação para que sua caixa ainda seja considerada válida, em vez de descartada ou distorcida.

O Albumentations é muito usado justamente porque transforma de forma sincronizada a imagem e a anotação associada: ao girar, espelhar ou redimensionar a imagem, a biblioteca recalcula automaticamente as coordenadas de todos os bbox, poupando o desenvolvedor de escrever essa lógica manualmente. Mas essa mesma automação vira fonte de problemas quando os parâmetros do A.BboxParams são definidos de forma errada: a biblioteca não vai emitir erro, apenas recalculará as coordenadas conforme o formato indicado (ainda que incorreto), e o desenvolvedor ficará com um pipeline de aumentação que formalmente funciona, mas na prática está estragado.

Por que o RandomCrop nem sempre é uma escolha segura

O texto dá atenção especial ao motivo pelo qual o RandomCrop comum, uma aumentação popular em classificação de imagens, muitas vezes se mostra uma solução ruim justamente para detecção de objetos. Ao recortar o quadro de forma aleatória, objetos nas bordas podem ser cortados parcial ou totalmente, e sem uma filtragem posterior cuidadosa com min_area e min_visibility, a anotação fica com caixas distorcidas ou até vazias, que o modelo trata como dados de treinamento válidos.

O material é voltado a quem trabalha com os formatos de anotação populares COCO, YOLO e pascal_voc e quer entender por que as aumentações "não funcionam", isto é, por que adicionar transformações padrão prontas não melhora as métricas do modelo e às vezes até as piora. O valor prático da análise está em deslocar o foco da depuração dos hiperparâmetros e das arquiteturas para uma fonte de problemas muito mais prosaica, porém frequente: a correção das transformações geométricas aplicadas à anotação, que especialistas em visão computacional costumam subestimar no início de um projeto.

Para equipes que trabalham com datasets de anotação industriais, esse tipo de análise é especialmente útil na transição entre formatos: por exemplo, quando os dados estão anotados em COCO, mas o treinamento usa uma arquitetura que espera YOLO, ou vice-versa. A conversão manual entre esses formatos é uma fonte frequente de erros difíceis de detectar, e o artigo basicamente oferece um checklist do que vale verificar antes de culpar a própria arquitetura ou a falta de dados pela baixa qualidade do modelo.