Já pensou subir um serviço, com um simples docker run e ter um OCR ilimitado disponível para seu sistema? Você pode usar, comercializar, e fazer absolutamente qualquer coisa com o OCR.

Você pode usar para leitura de documentos, validação de prints, e muito mais.

Pois bem, hoje falarei sobre um projeto que criei e pode te economizar tempo e dinheiro no seu próximo projeto.

Contexto

Alguns tipos de negócio demandam o trabalho com documentos e imagens. Seja para uma inscrição, autenticação, certificados, comprovantes, documentos oficiais, etc.

Outros tipos de negócios precisam fazer validações em imagens para garantir que não tenham mensagens ofensivas, e uma simples validação com palavras reservadas e score para simplificam a vida.

Seja lá qual for sua demanda, se você precisa extrair texto de imagens, você precisa de um OCR.

O Tesseract OCR foi originalmente desenvolvido pelo laboratório da Hewlett Packard, o desenvolvimento do Tesseract é patrocinado pela Google desde 2006 e hoje reside no GitHub.

Mas e se pudéssemos ter o Tesseract como uma API, para que facilmente você possa transformar em um microsserviço para sua empresa?

Pois bem o projeto github.com/luizcarlosfaria/TesseractOCRWebApi tem a função de ser uma API ao redor da linha de comando Tesseract entregando a capacidade de um OCR como uma API HTTP.

Tudo isso como um container docker (OCI) que está a um docker run de distância de você.

Mas e as API’s das plataformas e Clouds?

Acredito que o primeiro ponto é validar e ver se ele atende sua demanda. Para muitas empresas, usar o Tesseract será a única alternativa para ter um OCR.

Para outras, ele será usado como pré-validação, um passo a mais que evitará o custo de chamada de API, algo que permita validar previamente com base em algumas características.

Isso porque o custo de um OCR como serviço, hospedado em uma cloud pode não ser tão interessante, seja porque você terá um custo de rede elevado ou porque terá um custo de chamada de API elevado.

Então é possível que você entre em um cenário de “buscar economizar chamadas”, e talvez essa não seja a melhor estratégia, em vez disso, fazemos chamadas gratuitas locais, com o Tesseract como API e só usamos API’s pagas em último caso.

Aqui estão os custos do Textract da AWS.

Já o GCP do próprio Google possui essa tabela de preços.

Escala

Se você já tem algum lugar para rodar sua aplicação, estamos falando de um serviço com capacidade de escala ao infinito, e capaz aguentar qualquer throughput, já que estamos falando de um serviço standalone que não precisa de orquestração ou coordenação.

Note, eu não estou dizendo que uma única instância aguentará demanda infinita, longe disso, estou dizendo que a falta de dependência com elementos externos permite executar um número ilimitado de instâncias, em qualquer topologia imaginável.

Você escala: se precisar, o quanto precisar, até o limite da sua cloud ou infra.

Já do ponto de vista da tecnologia, tanto o projeto quanto o próprio Tesseract são gratuitos.

Aplicabilidade

Validação de Documentos

Checagem de palavras ofensivas.

Digitalização de Documentos (físicos)

Digitalização de documentos antigos (jornais etc).

Como disse, para alguns esse será seu único OCR, esse é o cenário do nosso bot de moderação do telegram que possui mais de 20 mil profissionais técnicos espalhados em diversos grupos.

A moderação de todo o conteúdo é feito pelo bot, e uma parte dessa tarefa é moderar as imagens que chegam aos grupos.

Qualidade

Você deve avaliar a qualidade do serviço e escolher se faz sentido ou não para seu projeto.

Exponha o projeto aos seus piores problemas. Não acredito em bala de prata e que ele será melhor que Google, AWS ou Microsoft, entretanto talvez seja o suficiente.

Há casos em que você usa o Tesseract para uma pré-validação, antes e de enviar para uma API de extração melhor.

A escolha é sua.

Como usar?

version: '3.4'

services:
  tesseractapi:
    image: ghcr.io/luizcarlosfaria/tesseractocrwebapi/tesseract-ocr-aspnet-webapi:2.2.0
    environment:
    - ASPNETCORE_HTTP_PORTS=8080
    volumes:
    - ./ocr/tests:/data
    ports:
    - "8080:8080"

docker compose up

Essa configuração serve para você subir a aplicação na porta 8080 do container e expor diretamente na porta 8080 do host.

Mas em cenários reais é ideal que a aplicação não exponha nenhuma porta no host e ao invés disso o acesso seja interno ou que você exponha o serviço através de um API Gateway ou Proxy Reverso.

Evoluções

Uma das características importantes desse tipo de projeto é a sua finitude. Ou seja, ele nasceu para ser pequeno, sem vocação para muitas novas funcionalidades.

Ele nasceu pequeno, e sua vocação é entregar um OCR com tesseract e só.

• Não é escopo dele gerar notificações (seja para billing ou para conclusão). Ao invés disso, o serviço que chamar essa API deve fazê-lo.
• Não é escopo dele, consumir filas e ser assíncrono. Ao invés disso, o chamador dessa API pode consumir uma fila e lidar com o fluxo assíncrono.
• Não é escopo dele tratar segurança: se necessário, use um API Gateway ou Proxy Reverso na frente.
• Não é escopo dele ser um broker de OCR com múltiplas implementações.
• Não é escopo dele ser responsável por chamar outras API’s de OCR remotas de cloud providers como GCP, AWS, Azure ou afins. Ao invés disso, ele é uma das implementações.

Dessa forma esse projeto nasceu para ser simples, de escopo limitado, com pouca demanda por evolução.

Esse projeto é um projeto simples, com poucas linhas de código e baixa complexidade em relação à sua capacidade de entregar resultado.

Serve como demonstração de como entendendo bem os conceitos ao redor de containers e aplicações distribuídas, é possível entregar resultado de forma bem desacoplada.

Esse foi um bom exemplo de projeto que saiu do uso de Controllers para Minimal API’s.

Aproveitei para criar a classe DisposableFile e remover alguns try/finally, que serve à nossa demonstração de tratamento de exceções e clean code.

Implict Operators

Eu tendo a gostar de métodos de conversão mais expressivos, “ConvertXXXToYYYY(XXX x)” ou “FromXPTO(xpto itemToConvert)” que ao bater o olho no nome, logo entendo do que se trata e o que faz.

Mas nesse projeto, pela sua simplicidade, resolvi usar operadores implícitos.

O objetivo era pegar um cenário bem simples e demonstrar a abordagem. De um lado, daria para tornar o código menos verboso e mais limpo, mas de outro, daria para entender até que ponto gera estranheza e desconforto.

Foi um bom exemplo, bem isolado, pequeno, para fazer esse tipo de teste.

Essa natureza minimalista permite que esse tipo de abordagem seja adotada sem trazer muito prejuízo.

Mas definitivamente, em um cenário maior, de escala, com centenas ou milhares de artefatos, seria dolorido ver esse tipo de abordagem propagada o tempo todo.

Faz lembrar linguagens fracamente tipadas ou linguagens de scripting, e isso gera enorme estranheza.

Claro que pontualmente faz algum sentido, mas é importante ficar atento.

Conclusão

Mais uma vez estamos falando de diversas tecnologias envolvidas nessa jornada.

Não é nada de outro mundo, mas é algo que todo arquiteto precisa se familiarizar, porque é assim que alguns problemas serão resolvidos.

Visite o projeto, teste e compartilhe | github.com/luizcarlosfaria/TesseractOCRWebApi