Da imagem ao fluxograma editável: uma explicação sem complicação

Resumo. Este artigo apresenta um projeto que recebe a imagem ou o PDF de um fluxograma, identifica suas formas, lê os textos, procura as conexões e organiza tudo em um formato que pode ser revisado e desenhado novamente. A proposta nasceu de uma situação fictícia: várias equipes enviam fluxogramas feitos de maneiras diferentes, e uma pessoa responsável pelo design precisa redesenhar cada um no padrão visual da organização. O sistema não substitui essa pessoa; ele tenta entregar uma primeira versão organizada para reduzir o trabalho repetitivo.

1. A situação que motivou o projeto

Imagine uma organização fictícia com várias equipes. Cada equipe registra seus processos do jeito que considera mais fácil. Uma usa uma ferramenta de apresentações, outra exporta um PDF, outra envia uma captura de tela e outra fotografa um desenho feito no papel.

Todos esses fluxogramas chegam a uma pessoa responsável pelo design. Antes de aplicar cores, fontes e tamanhos padronizados, ela precisa entender o conteúdo: quais são as etapas, onde existem decisões e para onde cada seta aponta. Muitas vezes, isso significa redesenhar tudo do zero.

Quando uma etapa muda, parte do trabalho se repete. O problema não é a criatividade do designer, mas o tempo gasto reconstruindo informações que já estavam no documento original.

O projeto surgiu para testar uma pergunta simples:

É possível transformar automaticamente uma imagem de fluxograma em uma base editável, deixando para a pessoa apenas a revisão e o acabamento?

O resultado esperado não é uma cópia perfeita da imagem. É uma representação organizada do processo: uma lista de etapas, decisões, textos e ligações. A partir dela, o fluxograma pode ser redesenhado no padrão desejado.

2. O que o computador precisa descobrir

Para uma pessoa, um losango com a frase “Pedido aprovado?” e duas setas é claramente uma decisão. Para o computador, a imagem começa como uma grande tabela de pequenos pontos coloridos, chamados pixels.

O programa precisa responder a três perguntas:

1. Quais símbolos aparecem? Por exemplo, retângulos, losangos e setas.
2. O que está escrito dentro deles? Por exemplo, “Validar pedido”.
3. Como eles estão ligados? Ou seja, qual etapa vem antes e qual vem depois.

Responder somente a uma pergunta não resolve o problema. Reconhecer o texto sem conhecer as formas mistura títulos, observações e etapas. Encontrar formas sem seguir as setas produz uma lista, mas não um fluxo. Por isso, o projeto divide o trabalho entre ferramentas especializadas.

Pequeno glossário

• Pipeline: sequência de etapas pelas quais o arquivo passa.
• Modelo de visão: programa treinado com exemplos para reconhecer elementos em imagens.
• YOLO: modelo de visão usado para localizar formas e pontas de seta.
• OCR: tecnologia que transforma texto presente em uma imagem em texto digitável.
• Tesseract: ferramenta de OCR usada pelo projeto.
• OpenCV: biblioteca usada para analisar linhas, bordas e outras características da imagem.
• Grafo: maneira de representar itens e suas ligações. No projeto, cada forma é um nó e cada seta é uma ligação.
• JSON: arquivo de texto organizado que outros programas conseguem ler e editar.
• Graphviz: ferramenta que recebe a descrição do grafo e desenha um novo diagrama.
• Dataset: conjunto de imagens e marcações usado para ensinar e avaliar o modelo.
• Confiança: número que indica o quanto o modelo considera provável que uma detecção esteja correta.

3. Como a solução funciona

Passo 1 — abrir a imagem ou o PDF

Imagens são abertas diretamente. Quando a entrada é um PDF, cada página é transformada temporariamente em imagem. Isso permite que todas as páginas sigam o mesmo caminho dentro do programa.

Passo 2 — encontrar os símbolos

O YOLO funciona como um marcador visual. Ele desenha uma caixa ao redor de cada elemento reconhecido e informa o tipo provável e sua confiança.

Os nomes usados no código aparecem em inglês porque seguem uma convenção comum em projetos de programação:

• process: uma atividade, normalmente desenhada como retângulo;
• decision: uma decisão, normalmente desenhada como losango;
• terminator: início ou fim do fluxo;
• input_output: entrada ou saída de dados;
• connector: ponto usado para continuar o fluxo;
• arrow_head: ponta da seta, usada para descobrir a direção.

Esses nomes não são exibidos para substituir as palavras do fluxograma. Eles apenas informam ao programa qual forma deverá ser usada na reconstrução.

Passo 3 — ler o texto

Depois de encontrar uma forma, o programa recorta somente sua parte interna e envia esse pequeno recorte ao Tesseract. Essa leitura localizada reduz a interferência de setas, bordas e textos próximos.

O OCR pode cometer erros, principalmente quando as letras são pequenas, a imagem está desfocada ou a borda da forma encosta no texto. Por isso, o texto reconhecido permanece disponível para revisão.

Passo 4 — seguir as linhas e as setas

O OpenCV ajuda a destacar bordas e segmentos de linha. O programa procura uma ponta de seta, identifica o símbolo próximo a ela e acompanha os segmentos na direção oposta até encontrar a provável origem.

Essa etapa é conservadora: quando não existe uma linha visível, o sistema prefere deixar a ligação ausente em vez de inventar uma relação. Uma ligação omitida pode ser adicionada na revisão; uma ligação falsa pode mudar o sentido do processo sem chamar atenção.

Passo 5 — organizar o resultado

As informações são gravadas em JSON. Nesse arquivo, nó significa uma forma do fluxograma e aresta significa uma ligação entre duas formas.

Um exemplo reduzido é:

{
  "nodes": [
    { "id": "n1", "type": "process", "text": "Validar pedido" },
    { "id": "n2", "type": "decision", "text": "Está aprovado?" }
  ],
  "edges": [
    { "source": "n1", "target": "n2" }
  ]
}

Em linguagem comum, esse trecho diz: existe uma etapa chamada “Validar pedido”, depois existe uma decisão chamada “Está aprovado?”, e a primeira leva à segunda.

Passo 6 — desenhar novamente

O Graphviz recebe essa estrutura e calcula uma nova posição para os elementos. Uma decisão volta a ser um losango, um início ou fim volta a ter forma arredondada e as conexões são redesenhadas.

O projeto pode gerar SVG, PNG e PDF. O SVG é útil porque mantém textos e formas em formato vetorial, sem perder qualidade quando a imagem é ampliada.

4. Por que o JSON é tão importante

Gerar apenas uma nova imagem esconderia os erros dentro de outro arquivo visual. O JSON permite conferir cada texto e cada ligação antes da publicação final.

Essa separação também ajuda o designer do cenário fictício. Em vez de redesenhar o documento inteiro, ele pode corrigir um nome, trocar o tipo de uma forma ou ajustar uma ligação. Depois, o programa publica novamente o fluxograma com o padrão de cores e formas escolhido.

No futuro, o mesmo JSON poderá alimentar outros formatos, como Mermaid ou BPMN, sem executar novamente o reconhecimento da imagem original.

5. Estudo de caso 1 — o fluxo de trabalho do designer

Considere três equipes fictícias preparando fluxogramas para um mesmo manual interno. A primeira entrega um PDF em preto e branco. A segunda usa cores e sombras. A terceira envia uma captura de tela com letras pequenas.

Antes da conversão

O designer precisa abrir cada arquivo, interpretar o processo, criar novamente todas as formas, copiar os textos e refazer as setas. Além disso, precisa decidir como traduzir estilos diferentes para um único padrão visual. Se houver dúvida sobre uma conexão, é necessário voltar à equipe responsável.

Com o conversor

Cada documento passa pelas seis etapas descritas anteriormente. O sistema entrega um JSON e uma primeira versão redesenhada. Os itens de baixa confiança e as ligações ausentes continuam exigindo revisão humana.

O designer passa a concentrar seu tempo em três tarefas: confirmar se o processo foi compreendido corretamente, corrigir as exceções e aplicar decisões visuais que realmente exigem julgamento. O trabalho mecânico de recriar caixas e copiar palavras pode ser reduzido.

O que esse cenário não promete

Esse caso explica o objetivo do produto, não mede economia real de tempo. Para afirmar quantas horas foram poupadas, seria necessário acompanhar vários documentos, registrar o tempo antes e depois e comparar pessoas e níveis de complexidade diferentes.

Também não se trata de um caso ligado a uma organização específica. A história é fictícia e serve apenas para mostrar um problema plausível.

6. Estudo de caso 2 — quando o primeiro modelo falhou

O segundo estudo aconteceu durante o desenvolvimento e ajuda a entender por que um teste aparentemente bom pode falhar no mundo real.

Contexto inicial

O primeiro modelo foi treinado com imagens sintéticas simples: formas grandes, fundo limpo e poucas variações. Nos testes feitos com imagens produzidas pelo mesmo gerador, os números pareciam promissores.

Quando esse modelo recebeu um fluxograma com aparência de documento — formas menores, linhas finas e várias ramificações — ele não encontrou nenhum dos 14 símbolos esperados usando a confiança mínima normal de 0,25. Reduzir esse valor para 0,05 revelou apenas um losango com confiança muito baixa. O problema não estava no JSON: o modelo não estava reconhecendo a entrada.

O que foi alterado

Foi criado um segundo conjunto sintético mais parecido com documentos. Ele contém 224 páginas: 160 para treinamento, 32 para validação e 32 para teste. As páginas têm fundo branco, formas cinza, linhas finas, textos curtos e ramificações laterais.

O treinamento passou a usar imagens de 640 pixels para preservar detalhes. Ele foi interrompido depois da sexta época, quando o caso de aceitação já apresentava os objetos esperados e os resultados no conjunto sintético haviam estabilizado.

O Tesseract também foi instalado e ajustado. Antes disso, apenas o pacote Python que conversa com o Tesseract estava presente; o programa de OCR propriamente dito ainda não estava instalado. São duas partes diferentes.

Resultado observado

No mesmo fluxograma documental usado como caso de aceitação, a comparação foi:

Resultado no único documento	Primeiro modelo	Modelo ajustado
Símbolos encontrados	0 de 14	14 de 14
Textos preenchidos	0 de 14	14 de 14
Textos exatamente corretos	0 de 14	12 de 14
Ligações corretas encontradas	0 de 15	14 de 15
Ligações falsas	0	0

Os dois textos não reconhecidos de forma exata continuaram compreensíveis: “Dia de sol?” perdeu um espaço, e “Jogar futebol” recebeu uma exclamação. A ligação ausente saía da decisão “Cansado?” em direção a “Jogar futebol”.

O documento original não é publicado porque sua licença de redistribuição não pôde ser comprovada. Ele foi usado localmente durante o desenvolvimento e influenciou o momento de parar o treinamento. Portanto, esse resultado deve ser chamado de caso de aceitação, e não de teste cego.

O que aprendemos

O resultado mostra que aproximar os exemplos de treinamento do tipo de documento esperado pode melhorar muito um caso específico. Ele não prova que o sistema funciona com qualquer fluxograma.

Em outros estilos, principalmente diagramas coloridos, com sombras ou estrutura de mapa de site, o desempenho ainda foi parcial ou nulo. Os bons números obtidos nas imagens sintéticas medem principalmente a família de imagens criada pelo próprio gerador.

7. Como experimentar o projeto

O código está disponível no repositório do projeto. O guia completo explica instalação, treinamento, pastas e configurações.

Depois de instalar o projeto e possuir um modelo treinado, uma imagem pode ser processada assim:

flowchart-converter exemplo.png `
  --model caminho\para\best.pt `
  --output-dir output

Um JSON já revisado pode ser transformado em SVG, PNG e PDF sem repetir o reconhecimento:

flowchart-render fluxo.json `
  --output-dir output\publicacao `
  --format svg `
  --format png `
  --format pdf

O repositório possui atualmente 30 testes automatizados. Eles verificam partes como o formato do JSON, o tratamento das classes, a leitura localizada, a reconstrução de conexões e a geração dos arquivos. Esses testes protegem o comportamento do código, mas não substituem uma avaliação com muitos documentos reais.

8. Limitações e próximos passos

O sistema funciona melhor com formas regulares, textos legíveis e linhas bem definidas. Ainda existem dificuldades com:

• setas curvas, cruzadas, interrompidas ou apagadas;
• fotografias inclinadas, sombras e baixa iluminação;
• escrita manual e fontes incomuns;
• palavras como “Sim” e “Não” escritas ao lado das setas;
• diagramas muito diferentes daqueles usados no treinamento;
• várias conexões próximas umas das outras.

O próximo passo mais importante não é eliminar completamente a revisão humana. É criar uma interface em que a pessoa possa ver as partes incertas, corrigir textos e reposicionar ligações com rapidez.

Também será necessário montar um conjunto de avaliação formado por documentos reais, com licenças claras e respostas esperadas. Assim será possível medir separadamente o reconhecimento das formas, a leitura dos textos e a reconstrução das ligações.

9. Conclusão

Transformar uma imagem de fluxograma em um diagrama editável exige mais do que reconhecer desenhos. O programa precisa localizar símbolos, ler palavras, seguir setas e reconstruir a ordem do processo.

A solução divide esse trabalho: o YOLO encontra os elementos, o Tesseract lê os textos, o OpenCV procura as linhas e o Graphviz organiza uma nova apresentação. O JSON mantém o resultado aberto para conferência e correção.

No cenário fictício, isso pode reduzir a parte repetitiva do trabalho do designer. No experimento real, o primeiro modelo falhou e o segundo resolveu quase todo um caso documental, mas ainda não generalizou para todos os estilos. Essa diferença é importante: o projeto já demonstra um caminho útil, mas continua sendo uma ferramenta experimental que precisa de revisão humana e avaliação mais ampla.

10. Referências

1. CANNY, John. A Computational Approach to Edge Detection. IEEE Transactions on Pattern Analysis and Machine Intelligence, v. PAMI-8, n. 6, p. 679–698, 1986.
2. MATAS, Jiří; GALAMBOS, Charles; KITTLER, Josef. Robust Detection of Lines Using the Progressive Probabilistic Hough Transform. Computer Vision and Image Understanding, v. 78, n. 1, p. 119–137, 2000.
3. SMITH, Ray. An Overview of the Tesseract OCR Engine. Ninth International Conference on Document Analysis and Recognition, p. 629–633, 2007.
4. GANSNER, Emden R.; KOUTSOFIOS, Eleftherios; NORTH, Stephen C.; VO, Kiem-Phong. A Technique for Drawing Directed Graphs. IEEE Transactions on Software Engineering, v. 19, n. 3, p. 214–230, 1993.
5. OPENCV. Canny Edge Detection e Hough Line Transform. Documentação oficial. Acesso em 30 ago. 2026.
6. ULTRALYTICS. Model Training with Ultralytics YOLO. Documentação oficial. Acesso em 30 ago. 2026.
7. TESSERACT OCR. Command Line Usage. Documentação oficial. Acesso em 30 ago. 2026.
8. GRAPHVIZ. dot — hierarchical layouts of directed graphs. Documentação oficial. Acesso em 30 ago. 2026.
9. GRANGEIRO, Pedro. Reconhecimento de fluxograma e conversor. Código-fonte, documentação, testes e dados de benchmark, 2026.