Esta e a parte em que o projeto deixa de parecer apenas um detector e passa a parecer um produto completo.
O Pipeline
Deteccao Cria Estrutura
O detector nao resolve identidade sozinho. Ele organiza a imagem em regioes semanticamente uteis. Esse recorte importa. Com isso, OCR e matching visual recebem inputs muito melhores.
OCR Resolve Texto
Ao trabalhar sobre o crop do titulo, o OCR enfrenta um problema muito mais limpo do que se tivesse que interpretar a carta inteira. Isso reduz ruido. Essa composicao entre modelos e uma das melhores decisoes do projeto.
Scryfall Resolve Conhecimento de Dominio
Em vez de replicar toda a base de conhecimento de cartas, o sistema usa a API do Scryfall para obter nome canonico, oracle text, preco e printings.
DINOv2 Resolve Impressao
Quando texto nao basta para diferenciar printings, o crop de art vira embedding e e comparado com as artes das impressoes candidatas. Esse passo muda o pipeline de "nome da carta" para "qual impressao e essa?". E ai que a identificacao realmente aparece.
Propagacao de Erros
Esse e o risco central de pipelines compostos. Ganhos pequenos no começo podem render muito no fim. Essa alavanca e real. Por isso, mexer cedo na cadeia costuma pagar mais.
Conclusao
O projeto acerta ao tratar identificacao como orquestracao entre especialistas: detector, OCR, API de dominio e modelo de similaridade visual. Nao e excesso de etapas. Essa e a diferenca entre demo e sistema util.
Na ultima parte, vamos olhar para a aplicacao web, operacao e evolucao do sistema em producao.
Further Reading
- Solucao completa:
docs/solution.md - Detection service:
web/services/detection.py - OCR service:
web/services/ocr.py