O reconhecimento óptico de caracteres pode rodar inteiramente dentro de uma aba do navegador. Neste site, o Imagem para texto carrega o mecanismo de reconhecimento Tesseract.js como WebAssembly, lê a imagem da memória local e devolve texto editável, então a imagem nunca é transmitida. O PDF para texto vai além e normalmente evita o mecanismo de reconhecimento por completo.
O caminho do PDF é o projeto mais interessante. A ferramenta percorre o documento página por página e lê primeiro qualquer camada de texto existente. Um PDF digital, exportado de um processador de texto ou de uma ferramenta de design, produz texto exato em cerca de um segundo e nunca baixa o mecanismo de reconhecimento. Só as páginas praticamente sem texto, ou seja, digitalizações e fotografias, são renderizadas em tamanho duplo e enviadas ao OCR. Essa abordagem em duas etapas significa que o download grande só é pago quando é realmente necessário, e as páginas digitalizadas são tratadas uma por vez, a alguns segundos cada.
O motivo de isso importar não é abstrato. Documentos digitalizados são a categoria que as pessoas menos se sentem à vontade para entregar: formulários assinados, cartas médicas, faturas, documentos de identidade, qualquer coisa fotografada em uma mesa. Um mecanismo de reconhecimento que roda localmente elimina a decisão por completo, porque não há cópia alguma sobre a qual raciocinar.
Imagem para texto
Leia o texto de uma foto, de uma captura de tela ou de uma digitalização. Várias imagens são processadas em ordem, e o resultado vai para uma caixa editável que você pode copiar ou baixar.
O que muda quando o reconhecimento roda no navegador
Um serviço de OCR baseado em servidor recebe seu arquivo, executa o reconhecimento no próprio hardware e devolve o texto. Uma ferramenta baseada em navegador baixa o mecanismo em vez do documento, e o tráfego flui na direção oposta.
| Reconhecimento na aba | Reconhecimento em um servidor | |
|---|---|---|
| O que passa pela rede | Arquivos de mecanismo e de idioma, em | Seu documento, fora |
| Cópias no disco de outra pessoa | Nenhum | No mínimo o upload, geralmente também um arquivo de resultado |
| Conta | Não necessário | Geralmente necessário para lotes ou arquivos maiores |
| Funciona offline após o primeiro carregamento | Sim | Não |
| Velocidade | Alguns segundos por página digitalizada | Mais rápido em lotes pesados |
| Verificável por você | Sim, no painel de rede | Não |
Vale conhecer um detalhe técnico, porque ele explica por que isso é possível sem configuração especial de servidor. O mecanismo é de thread única e não usa SharedArrayBuffer, então a página não precisa dos cabeçalhos de isolamento de origem cruzada que o WebAssembly com múltiplas threads normalmente exige. É por isso que um host estático comum consegue servi-lo.
O projeto em duas etapas do PDF para texto
A maioria dos PDFs que as pessoas chamam de digitalizações não é digitalização nenhuma. Um documento exportado de um processador de texto, de uma planilha ou de um gerador de relatórios contém caracteres reais, posicionados na página mas armazenados como texto. Reconhecer esses caracteres com OCR seria uma coisa estranha de fazer, porque introduz erros em dados que já eram exatos.
Etapa um: ler a camada de texto
A ferramenta abre o PDF com o PDF.js e pede a cada página seu conteúdo de texto, depois reconstrói a ordem de leitura a partir dos dados de posição, para que linhas e parágrafos saiam em uma sequência coerente. Essa etapa é rápida e sem perdas: os caracteres são os que o arquivo já contém, então não há nada a errar. Uma página é considerada como tendo camada de texto quando contém pelo menos 20 caracteres que não são espaços, o que é um critério deliberadamente baixo para que uma página com uma legenda realmente curta ainda seja lida diretamente.
Etapa dois: reconhecer apenas as páginas que precisam
As páginas que falham nesse teste são as que são realmente imagens, e seguem por outro caminho. Cada uma é renderizada em um canvas com o dobro do tamanho normal, convertida em PNG e entregue ao mecanismo de reconhecimento. Dobrar a escala de renderização importa mais do que parece, porque os modelos de OCR trabalham com traços e bordas, e uma página rasterizada na resolução de tela perde o detalhe fino de textos pequenos.
| Documento | O que a ferramenta faz | Download do mecanismo |
|---|---|---|
| PDF digital, todas as páginas têm texto | Lê a camada de texto em todas as páginas | Nenhum |
| PDF digitalizado, sem camada de texto | Renderiza todas as páginas em 2x e as reconhece | Um download, depois em cache |
| Documento misto, anexo digitalizado | Lê páginas de texto diretamente, reconhece o restante | Um download, usado para parte do arquivo |
O resultado informa qual caminho cada página seguiu. O resumo mostra a contagem de páginas, quantas vieram da camada de texto e quantas foram reconhecidas, e o corpo é dividido em blocos de página. Essa distinção é útil na prática: se um documento que você esperava ser digital mostra um monte de páginas reconhecidas, provavelmente ele foi impresso como imagem em algum ponto do caminho.
PDF para texto
Páginas digitais são lidas da camada de texto em cerca de um segundo. O mecanismo de reconhecimento só é carregado para páginas que são realmente imagens.
O que o mecanismo realmente baixa
Nada aqui é buscado quando a página carrega. O mecanismo chega sob demanda, na primeira vez que você clica no botão, e vale citar os números porque eles explicam tanto a demora quanto o comportamento offline depois.
- O núcleo tem cerca de 3.7 MB. Essa é a versão WebAssembly do modelo de reconhecimento, e é um único arquivo auto-hospedado, e não várias variantes.
- Os dados do idioma inglês têm cerca de 2.8 MB e é servido por este site, então o caso comum não precisa de terceiros. Juntos, a primeira execução em inglês puxa cerca de 6.5 MB, e o navegador mantém isso em cache.
- Os outros idiomas vêm de um CDN público de dados do Tesseract. O seletor lista doze idiomas no total; o inglês é local, e os outros onze, do chinês e japonês ao russo e árabe, são baixados no primeiro uso e armazenados em cache pelo mecanismo no IndexedDB.
- Mantém-se um worker por vez. Um worker mantém o núcleo mais os dados de idioma na memória, então trocar de idioma encerra o anterior em vez de acumular os dois.
- O suporte a SIMD é verificado antes de qualquer carregamento. O carregador valida primeiro uma pequena amostra de WebAssembly, porque a versão do mecanismo exige instruções vetoriais. Sem essa verificação, um navegador mais antigo falharia com um erro de compilação de baixo nível em vez de uma mensagem legível.
Como obter um resultado limpo
- Escolha o idioma antes de começar. É a única configuração que decide a precisão, e ela só se aplica às páginas que passam pelo reconhecimento. Um PDF digital a ignora por completo.
- Envie a origem mais nítida que você tiver. A foto original é melhor que uma captura de tela de uma visualização, e uma digitalização plana é melhor que uma foto de celular em ângulo. Se você só tem uma foto, um leve recorte no bloco de texto ajuda mais que qualquer configuração.
- Endireite e ilumine. Uma página girada alguns graus, ou iluminada de um lado com uma sombra atravessando o meio, custa mais precisão do que uma resolução mais baixa.
- Execute e leia a saída. A caixa de resultado é editável, então corrija nomes e números ali em vez de exportar e remendar depois.
- Confira o índice de confiança. Ele é informado como uma média de todo o arquivo. Um número baixo é um sinal para olhar a origem de novo, não um veredito sobre o texto.
Se uma foto precisa ser arrumada antes do reconhecimento, Recortador de imagem e Compressor de imagem os dois rodam localmente, então toda a cadeia, da foto bruta ao texto, pode ficar no dispositivo.
Onde o OCR ainda falha
Ser claro quanto a isso é mais útil do que uma alegação de confiança, porque os modos de falha são previsíveis e se concentram em como a origem foi produzida, e não no mecanismo.
- Artes de design e fundos coloridos. O modelo de reconhecimento foi treinado em documentos, não em pôsteres. Testado na própria capa azul-escura deste site, que tem letras grandes e estilizadas, o mecanismo devolveu um único hífen. Qualquer imagem em que o texto seja decorativo e não tipográfico é uma candidata ruim.
- Escrita à mão. O alvo é texto impresso. Anotações à mão, assinaturas e preenchimentos de formulário produzem resultados não confiáveis, e nenhuma quantidade de resolução corrige isso.
- Digitalizações ruins. Recibos térmicos apagados, faxes, fotocópias de fotocópias, páginas tortas no scanner. A precisão cai a cada um desses casos, e a ferramenta não tem como avisar quais palavras são duvidosas.
- Velocidade em páginas digitalizadas. O reconhecimento leva alguns segundos por página, e o trabalho ocorre na sua própria CPU, então a aba fica ocupada enquanto ele roda. Um documento digitalizado longo é um trabalho lento, e não instantâneo.
- Cobertura de idiomas. Apenas os doze idiomas do seletor. Qualquer outro não é suportado, e uma página que mistura dois alfabetos é lida com o único modelo que você escolheu, o que custa precisão no segundo idioma.
- O layout não é preservado. A saída é texto simples com marcadores de página. Colunas, tabelas e barras laterais saem como um fluxo linear, então um layout complexo precisa ser reformatado depois.
- PDFs protegidos por senha precisam ser desbloqueados antes. O leitor não consegue abrir um arquivo criptografado, e a ferramenta avisa isso em vez de falhar silenciosamente.
Quando um serviço baseado em servidor é a melhor resposta
O reconhecimento local é o padrão certo para um punhado de documentos e a ferramenta errada para alguns trabalhos específicos. Trezentas faturas digitalizadas, um arquivo cheio de escrita à mão, um alfabeto fora da lista suportada ou a exigência de uma saída estruturada que preserve a geometria das tabelas apontam todos na mesma direção, porque esses casos exigem capacidade de processamento ou modelos que uma versão de navegador não carrega.
O hábito útil é separar os dois casos antes de começar. Se o documento é sensível e o volume é pequeno, o caminho do navegador dá conta e o arquivo nunca se move. Se o volume é grande, o movimento certo é um serviço aprovado, e não cem execuções manuais, e a decisão sobre qual serviço usar é organizacional, não técnica. Essa divisão, e como ela se aplica a equipes que lidam com documentação de pessoal, jurídica ou clínica, é o tema de documentos sensíveis e a nuvem.