A IA consegue reparar rasgos e riscos? Números de viabilidade

Sim, e este post registra as medições que a levaram de esperança no roteiro a recurso em produção: o que o pipeline costumava fazer com digitalizações danificadas, os números da prova de conceito que justificaram construir a etapa e os resultados de ponta a ponta da versão que agora roda por trás da caixa de seleção “Reparar riscos e rasgos”.

O que o pipeline fazia com uma foto rasgada antes

A restauração não tinha etapa de inpainting: nada que pudesse remover uma região e sintetizar uma substituta. Verificado em um retrato muito rachado: dentro das regiões de rosto, o dano sumia incidentalmente (o modelo de rostos ressintetiza o recorte inteiro) e então reaparecia abruptamente na fronteira da mescla, uma rachadura que para na bochecha, o que pode parecer pior do que nenhum reparo. Em todo o resto, o dano era realçado: a passagem de nitidez definia as bordas dos rasgos como se fossem detalhe, e o colorizador tingia as linhas brancas das rachaduras como conteúdo da cena.

Prova de conceito

Sujeito de teste: um retrato em preto e branco de 510×817 com uma teia de rachaduras na emulsão. Hardware: uma sandbox deliberadamente fraca, só de CPU, então cada tempo é um pior caso. Duas etapas: uma rede de detecção de riscos (do projeto de código aberto “Bringing Old Photos Back to Life” da Microsoft^[2]) produz uma máscara de danos; o modelo de inpainting LaMa^[1] então preenche só as regiões mascaradas em blocos de 512 px, ambos no provedor de CPU do ONNX Runtime^[3].

A máscara de danos cobriu 18.4% dos pixels desta foto muito danificada. Resultado de qualidade: a teia de rachaduras foi removida do rosto, das roupas e do fundo, sem falsos positivos prejudiciais: a toalha de renda, a armadilha clássica para detectores de riscos, sobreviveu.

O que entrou em produção, medido de ponta a ponta

A etapa de produção roda primeiro na ordem de restauração, para que as rachaduras nunca sejam coloridas ou realçadas antes da remoção. A detecção roda com lado menor de 256 e uma dilatação de máscara de 2 px; o inpainting é por retalhos na resolução nativa, limitado a 12 retalhos por foto, com as maiores regiões de dano vencendo. Duas invariantes são impostas, não esperadas: só pixels mascarados são escritos (cada pixel não danificado da saída é idêntico byte a byte ao da entrada) e um crivo de cobertura pula a etapa inteiramente quando a área detectada é menor que 0.5% (nada que valha reparar) ou maior que 35% (mais provavelmente textura mal detectada do que dano).

Uma revisão posterior de produção acrescentou ao crivo automático um segundo discriminador, mais afiado: a forma. A cobertura sozinha não distingue um rasgo fino de ruído do detector, mas a geometria dos dois difere em uma ordem de grandeza: um rasgo é longo e fino, ruído são manchas. Para cada componente conexo da máscara, com caixa delimitadora b_w×b_h e área em pixels A, pontuamos

Pontos de calibração da bancada: um gráfico de marketing limpo pontua um alongamento máximo de 2.4; a digitalização com teia de rachaduras pontua 29.8. O limiar de 6 fica bem afastado de ambos, e cada execução de produção registra sua cobertura e seu alongamento, para que o crivo continue sendo ajustado com tráfego real, e não com duas fotos.

Dois controles: com a caixa desmarcada, a etapa nunca rodou e os tempos coincidiram exatamente com o pipeline anterior. Em uma foto quase limpa, o detector marcou só os 0.81% de pixels genuinamente danificados (restos de rachaduras nos cantos e poeira), com zero falsos positivos em rostos, renda ou textura.

Por que é opcional e não padrão

O modo de falha conhecido do reparo automático de danos são os falsos positivos: um detector que marca arames de cerca, fios de cabelo ou renda como riscos vai apagar conteúdo real, e um modelo de inpainting é muito bom em apagar coisas. Duas fotos de controle são evidência, não um benchmark. A etapa, portanto, é lançada como uma caixa de seleção explícita, e cada execução registra seu valor de cobertura de danos para que os limiares possam ser ajustados com tráfego real antes de qualquer promoção a padrão. Também rejeitamos o atalho de enviar fotos a uma API generativa externa de imagens: esta ferramenta processa fotos transitoriamente na nossa própria infraestrutura, e uma re-renderização generativa completa desvia a identidade; o objetivo é reparar o dano, não repintar o seu parente.