OCR e dados

Já foi dito que para se trabalhar com programação é importante desenvolver os algorítimos com foco nos dados. O problema que eventualmente surge é a captura dos mesmos. Sim a captura é o primeiro passo para se ter dados crus quando somente temos papéis para obtê-los.

Certo, derivei, pois na introdução do meu artigo, falo em programação, dados e algorítmos, mas na realidade o que quero é apresentar um “procedimento” pessoal, que uso quando preciso de obter estes dados de fontes em papel.

Este procedimento se baseia neste artigo, de Thadeu Penna, que li e marquei, há uns dois anos.

Ele utiliza os softwares gimp e tesseract para tratar as fontes e o processo, apesar de intrincado, é bem simples e funciona. Diferente dele, eu não uso o plugin do gimp, mas o xsane, diretamente, para realizar minhas digitalizações.

Para fontes, relativamente limpas, basta se utilizar o software tesseract nas imagens digitalizadas, i.e. sem tratar no gimp, pois o mesmo é excelente em termos qualidade de reconhecimento, facilidade de utilização.

Fácil ? Em termos pois vale para alguém que tenha o QI com mais de dois digitos e use a linha de comando, caso contrário, resignar-se-à em sofrer com os banners bordados e coloridos dos software de fabricantes e aquele treco enjanelado, que muitos ainda insistem em usar.

Procedimento:

  1. Instale e ajuste o driver de scanner (use o xsane para isto): apt-get install xsane.
  2. Instale o tersseract;. apt-get install tesseract-ocr tesseract-ocr-por
  3. Digitalize as fontes em preto e branco ou cinza, gerando arquivos .tif ou .png, com uma resolução em torno de 350dpi (quando mais “suja” a fonte, maior deve ser a resolução)
  4. Trate, caso seja necessário usando o gimp, segundo o Thadeu:

Para um bom aproveitamento do programa de ocr é importante preparar a imagem a ser reconhecida. Para o meu caso, 350dpi foi o de melhor aproveitamento: menos de 200 nem pensar e mais de 600 também não melhorou muito. O texto estava em fontes de 14pt, é possível que um texto em 10 ou 12pt necessitem de uma maior resolução.

No Gimp, vá para Camadas → Cores → Limite. Esta operação vai transformar a figura escaneada em tons de cinza em uma figura preto e branco. O triângulo preto do meio, na janela Limite determina quem será branco e quem será preto. Escolha um valor bem alto: eu movi para 220 (o máximo 255)

Note que estes passos acima são para fontes com muito ruído (manchas, pits, etc) e que a versão atual do tesseract, aceita .png, com ótimos resultados.

Finalmente utiliza-se a linha de comando com apenas o seguinte comando:

$ tesseract imagem.png imagem.txt -l por

Eu sempre que recebo alguma informação interessante – cartas de banco, folhetos de programas de fidelidade, apólices de seguro, contratos, extratos, etc – digitalizo e deixo em .txt para ler posteriormente ou utilizar dados já digitados para inserir em bancos de dados que eventualmente desenvolvo.

Os resultados são impressionantes.

Anúncios

“Witty” – Um webserver em C++

Sempre que se fala em web applications algumas soluções sempre entram em cena como plataformas em potencial: JBoss, Tomcat, ASP.NET, PHP, …. Mas, já pensou se pudessemos desenvolver nossas aplicações web em C++?

“Witty” (Wt – contração de Web Toolkit) é uma dessas possibilidades. O ganho de performance é enorme e suporta mais que o dobro de conexões simultâneas do que qualquer uma das soluções heavy duty pode te dar. E ainda é totalmente free!

Aplicação, ao estilo do antigo GMail, escrita com o "witty"

Dê uma olhada nos exemplos (aqui). Esse toolkit é impressionante!

Se ficou interessado, o link para download  e para a documentação é esse aqui.

Happy new year and happy with old tools

É fim de ano e estive olhando os códigos que produzi durante 2011 e observei algumas melhorias obtidas na produção.

A principal, e que não posso mais perder de vista, sem dúvidas, é a documentação.

Documentação de projetos é sempre muito chato e aparentemente inútil, mas vejo, mais uma vez que os livros estavam certos: é a parte principal de qualquer projeto. Conclusão que cheguei, após reler o ROADMAP do meu projeto “cinco” e ver que, mesmo em passadas lentas e distantes, eu segui uma linha de ação que converge para um fechamento. Nos anos anteriores, sempre tinha a sensação, ao rever códigos, que deveria reescrevê-los pois não existia uma linha mestra determinada pela documentação que revi há pouco e que me deu inspiração para criar este post.

Entretanto, os livros não são muito “amigos” quando não determinam um modo “ótimo” de fazer as coisas e deixando isto a critério do programador.

Testei muitas ferramentas nestes últimos anos e estou certo que as melhores persistem. Aqui relaciono o estado atual do conjunto que elegi e pretendo me fidelizar.

Faço isto pois em vários e-mails para amigos, sinto que esta é uma necessidade comum e que no fim das contas todos estamos procurando uma zona de conforto e establidade que nos permitam concentrar esforços em produção de códigos ou textos, e não de familiarização com “novidades”.

Sistema operacional – GNU/Linux – Debian

Desnecessário dizer que o windows não presta para uso de desenvolvimentos “sérios”. Tenho dúvidas se a equipe de produção da M$ utiliza aquilo para desenvolver o windows. Suspeito que eles tenham um unix deles de uso interno ou mesmo utilizam o linux. A ferramenta Windows é totalmente voltada para usuários finais. Desktops principalmente. No que diz respeito aos servidores eles devem ter um segmento distinto de “transformação”, ou seja, pegam as idéias advindas da cultura unix e “empacotam” com aquelas “janelas” tradicionais.

Sempre senti necessidade, desde o início de minha carreira, de um sistema confiável, simples e que fosse de custo acessível, preferencialmente gratuito, para atividades de desenvolvimento. O objetivo é bem simples: não ser pego de surpresa por uma “virada” na forma de apresentação ou políticas de marketing.

A primeira “pedrada” que me atingiu, e que me fez pensar assim, veio na mudança de DOS para Windows. Na mesma época eu também lidava com outro sistema, VMS, que passado alguns anos foi sendo mumificado pelas sucessivas aquisições da Digital pela Compaq e desta pela HP e enfim o sistema caiu no esquecimento. Junto com ele toda uma gama de conhecimentos e horas de dedicação foram soterradas e daí nasceu a minha grande ” birra” com sistemas fechados. Enfim, nos idos de 1995, encontrei um sistema que antes eu resistia em aceitar por ser da linhagem “unix” mas, após entendê-lo,  com ele permaneço até hoje.

O que eu poderia esperar de um sistema em termos de estabilidade, confiabilidade, padronização e custos, foi plenamente atendido pela plataforma que, de quebra, me inseriu numa cultura que sobrevive desde os idos de 1968, ou seja, tem quase a minha idade.

O GNU/Linux é o patrocinador desta minha tranquilidade e por isto me dedico tanto a utilizá-lo. Fiz amigos e inimigos, tentando evangelizá-los, pois queria que tivessem o mesmo benefício que eu possuo.

Editor de texto – não sei quanto ao mundo “javanizado” ou “.netzado” mas com certeza quem desenvolve usando uma linguagem de verdade ou mesmo tem necessidade de economizar bandas ao manter um servidor de web é um adepto declarado da “tela preta”. Neste con”texto”, perdoem-me o trocadilho – optei por me desenvolver no vi. Certamente quando usava DOS passei um bom tempo usando o Boxer e gostava das facilidades de gerenciamento de textos e arquivos, bem como sua estabilidade. Mas era “pago” e cheguei a comprar uma versão. Logo vi que manter aquelas atualizações iria me custar caro ou me obrigar a “piratear”. Pensei: se usam vi, deve ter algo bom. E tem: é versátil, possui versões para todas as plataformas e consequentemente pode ser usado e abusado. Me empenhei em aprender os “cabalísticos” modos e comandos para depois notar que não eram tão complexos, e nem poderiam. Me firmei com o Vim, com o qual mantenho um relacionamento há uns 6 anos pelo menos.

Mas confesso que alguns problemas me deixam meio insatisfeito com o vim. Os modos diferenciados, as facilidades adicionadas que não existem no vi original e que o tornam meio dependente de plataformas, e a sua “desintegração” com o sistema – falta de shell (me faz dar Ctrl-Z), me fizeram tentar outra evolução: o Emacs.

No início, quando buscava um editor confiável, tentei usar o Emacs, mas esbarrei nas suas “teclas estranhas” e também no seu onipresente lisp (nunca entendi direito lisp), mas estudando-o um pouco desde outubro deste ano, estou cada vez mais convencido do poder de integração e gerenciamento que este “sistema operacional capaz de editar textos” está me propiciando.

Recentemente descobri o “org mode” e me surpreendi que todas as ferramentas de controle de projeto estão lá. Mapas mentais, todo list, planner, notes, agenda, calendário, time keeper, etc, etc, etc (sim três) pois o sistema é bem extenso.

Então a minha migração está iniciada, mas ainda dependo do vim e do recente gerenciador de dados (PIM) que estou usando, mas pretendo migrar de vez no ano que vem e sossegar até o fim com o emacs.

PIM – j-pilot

Este software é sem dúvida o que me fez rever toda a minha agenda, contatos, e todo list. Ainda é um processo de transição. Ele foi iniciado com o achado de um PDA o meu velho visor edge (um palm pilot) adquirido e abandonado em 2002. Usei-o por um mês, que foi suficiente para rever todos os meus conceitos de concentração de dados em um ambiente sob “o meu” controle, não em posse do “google”. O google está com umas “viadagens” de modificar o lay-out e que, na minha opinião ficaram uma “merda”. Lenta, bloated e “desnecessariamente” clean. Aquilo esteve bom desde 2005 quando comecei a usar, mas sinceramente, não estou gostando mais. Portanto a minha meta é continuar centralizando tudo neste velho j-pilot até que eu tenha domínio completo do orgmode do emacs. Mas para isto, passei por muitas ferramentas até achar o “ponto texto” do negócio de gerenciamento de informações pessoais.

Compilador/Debugger – não vou me estender muito: gcc/gdb. Quem quiser que os aprenda para saber do seu valor.

Web language – PHP – sim é lame, mas foi ela que através do maravilhoso framework Codeigniter, me fez tomar contato com o modelo M-V-C (model-view-control) que passei a adotar em meu projeto “cinco” em linguagem “c”.

Web design – blueprint. CSS dá trabalho e o blueprint tira. Resumindo, não sou designer.

Banco de dados – SQLite e Firebird. Conceito e aplicação. Gosto do mysql, mas apenas um sgdb que rode em windows me satisfaz. O outro, sqlite, pretendo usar, como foi falado no site oficial, com o objetivo de eliminar o fopen.

Relatórios – formato pdf.

Suítes office – deixo isto para os meus usuários. Quando preciso, uso o br-office, especificamente o oocalc.

Gerenciador de dinheiro – gnu cash simples, fácil e eficiente.

Edição de imagens – Gimp.

Navegação web – qq navegador padrão do sistema que estiver instalado. Não tenho mais o fetiche por estas “coisas”. Depois que transformaram a web em “televisão”, passei a não mais ligar para estes “aparelhos de tv” metidos a software. Lixo e propaganda? Basta pegar o carro e rodar pela cidade olhando para os outdoors.

Este conjunto de ferramentas é o que eu uso e pretendo usar daqui por diante e ir eliminando, cada vez mais as interfaces via mouse, pois estou com uma LER em função do uso excessivo de planilhas e Gnu/Cash desde setembro.

Enfim, Feliz ano novo a todos.

{}’s

MaRZ

Ferramentas indispensáveis

Um bom profissional tem uma caixa de ferramentas que o acompanha onde quer que vá e também possui outras em sua oficina ou local de trabalho que não podem ser carregadas, mas são igualmente indispensáveis.

O profissional programador normalmente possui uma biblioteca de sua confiança que pode ser comparada à caixa de ferramentas portátil. Entretanto quando temos que mudar de plataforma, estas ferramentas devem ser “recalibradas” ou mesmo substituídas.

Um grande passo a ser dado, para se ter esta compatibilidade à disposição é utilizar um conjunto de ferramentas versáteis e padronizadas.

Por estas e outras, tenho estudado algumas bibliotecas existentes e apanhado algumas idéias para uso em meus desenvolvimentos.

Ainda não consegui a tal caixa de ferramentas portátil (a.k.a portável) de modo que eu possa levar a qualquer lugar, mas estou próximo de algumas que são bastante úteis. Descrevo-as aqui, além das triviais, as que não são de uso freqüente e que normalmente me fazem perder tempo procurando ou lembrando de seus nomes. Observem-se que as man pages e os apropos ajudam, mas nem sempre trazem a resposta que você procura na hora certa.

Da próxima vez que forem analisar um código, e esta é uma boa prática, feito por gurus, utilize estes facilitadores. Tenho tido muito sucesso com eles ao ler códigos complexos que você pode baixar diretamente dos repositórios Linux. Na verdade eles também ajudarão se por acaso você tiver acesso aos “exemplos” (código fonte nem em sonho) que acompanham os outros produtos que se vêem por aí. Basta copiar a codebase fornecida para um Linux perto de você ou usar os famigerados Msys/MingW ou Cygwin.

gcc Simplesmente “o” compilador, não preciso dizer nada sobre ele, o manual é bem completo.
vim Este é “o” editor. Dispensa comentários.
indent Este funciona na linha de comandos, mas o vim dá conta dele muito bem com o gg=G, explicado pelo Fred em outra ocasião
cflow Acompanha o gcc e imprime de vários modos as chamadas e chamadores de um programa
cscope É uma ferramenta interativa que permite navegar pelos fontes (.c .h ) buscando por elementos específicos e mostra na tela suas referências, lembre-se de “periscópio” e entenda. Serve para quickies do tipo quantas vezes a rotina xyz é usada, onde foo aparece.
ctags As exuberantes tags do c. Gera um arquivo tags no diretório onde foi rodado (podendo ser usado recursivamente) contendo os símbolos do programa e serve para o vim fazer saltos diretos via ctrl-] e ctrl-t
splint Este é o tirano do bem. Não tem jeito de convencer o splint a ser carinhoso. Se seu código contiver erros ele nem começa. Quando vocẽ pensa que não tem erros aí ele te mostra a quantidade de caca. Se tentar fazer tudo que ele pede, será mais fácil ler, se o código estiver em braille.
objdump Quando o fred falar em assembly, basta usar esta ferramenta no programa já compilado e obter a listagem para por a mão na massa
ldd Imprime a lista de bibliotecas que um programa depende, útil também para reparar problemas no linux e checar dependências
nm Imprime a lista de símbolos – as rotinas que você ou outro – incluiu nas bibliotecas ( lib***.so) dinâmicas, bom para ver os pontos de chamadas das rotinas da lib.
strings Este é bem legal… Localiza as strings dentro de um “executável” e com outra ferramenta “hexedit” podemos corrigir erros de português ou trocar ‘ficheiro’ por ‘arquivo ‘ dentro destes programas
sum Um checksum rápido para saber se dois fontes ou mesmo executáveis são de versões diferentes
strace/ltrace Matadores – traça as chamadas, ponteiros, contadores, etc. Requer leitura atenta do manual.
gdb Gnu debbuger – sem comentários
file Ajuda a descobrir o tipo de arquivo (elf, data, etc..)
gprof Depois de compilar o seu programa com a chave -p e rodá-lo, perceba que é gerado um arquivo gmon.out no mesmo diretório. Sobre este arquivo gerado o gprof irá obter as estatísticas do seu programa.
time Rode seu programa com time myprog e veja quanto tempo gastou
clock Esta é uma rotina interna do standard c e serve para contar o tempo gasto nas rotinas

Editores

Há uma guerra aí fora que dura anos: Editors War.

Passando por várias cateogorias, bases de trabalho, plataformas encontramos aficcionados, alguns até com índole tribal, quando o assunto é editor de texto predileto.

Uns justificam que são completos, outros que são fáceis de manusear. Tem os WISYWIG, tem os espartanos, os livres, os especializados.

Essencialmente esta guerra existe pois sabemos que não se consegue editar uma linha de código sequer sem um bom editor. Bem, na verdade, poderíamos usar o cat para isto, mas não seria muito prático.

Já fiz vários testes com editores. Desde o velho Sidekick, Wordstar e finalmente o Boxer – quando na plataforma DOS, passando pelo VAX TPU/VAX EDIT, vi no Solaris e no linux cheguei a testar o Emacs para finalmente chegar e parar no Vim. Não quero fazer ode a ele, mas recomendo que se visite o site e baixe o livro gratuito – do Steve Oualine. Além de ser uma ótima referência, o autor tem outros, inclusive sobre C, no site dele.

Mas o que eu gostaria de citar aqui não é o Vim, mas o avô dele: o ed.

Acho este editor essencial. Saber dominá-lo é um ótimo modo de se abster das grandes “facilidades” do mundo moderno, para poder valorizá-las depois.

Este editor – o ed – tem uma história singular: veio de um mais velho ainda – o qed. O ed foi desenvolvido pelo Sr. Ken Thompson, um dos autores do Unix e do prórpio C.

O manual do qed, que pode ser obtido aqui e vale à pena ser estudado (tem o do ed também só não achei o link), inclusive usando o próprio código fonte. Ele contém os comandos básico de edição e dá um bom entendimento do que vem a ser buffer, string e comandos estilo “sopa de letra”. É no mínimo interessante, editar um arquivo e depois “imaginar” o resultado, para somente aí executar o comando de listar: 1,$p e ver o que está carregado “na memória”.

A sensação é de estar mexendo diretamente nos bytes na memória, sem a tal “abstração” requerida no mudo moderno do mouse. Sim. É você com a mão nos circuitos do computador.

A matemática envolvida já se manifesta aí, pois você imagina uma matriz, com linhas e colunas de letras e emite comandos simples sobre elas.

No início é simplesmente FRUSTRANTE, principalmente para aqueles que não tem nem idéia do que estão fazendo na frente de uma “tela preta” com um $ no canto.

Com um pouco de prática, mais ou menos uns dois ou três dias, vocẽ já estará  “pensando” com as partes do seu código fonte dentro da sua imaginação.

No fim de uma semana, creio que tendo dominado o instrumento – no caso o ed – você passa a contar com ele como ferramenta e explorar as possibilidades.

Eu cheguei a esta conclusão quando brigava com outro editor – o sed – pois permite o manuseio fácil de expressões regulares. Esta porta – expressões regulares  – que me abriu foi o conhecido Aurélio Marinho Jargas, quando comprei o seu pequeno livro, que tem grátis na net, sobre Expressões Regulares da Novatec. Vale à pena baixar e usar as famosas RE. Tem gente que gosta de sudoku para fazer ginástica cerebral. Eu recomendo as expressões regulares.

Uma vez dominadas estas duas técnicas relativamente simples – o uso do ed e as RE – você estará apto a mergulhar no mundo do Vim.

Penso que você pode até tentar fazer código num bloco de notas qualquer ou usando uma linda IDE turbinada, mas se quiser ir ao pote de conhecimento, comece dominando o seu editor de textos primeiro e, por experiência própria, indico o Vim como a ferramenta mais básica do nosso toolkit.

Numa palestra do autor, Bram Moolenar, ele mesmo diz que não conhece todos os recursos do Vim, por isto nem tente aprender tudo num dia só. Leva-se anos para aperfeiçoar e no início é um sofrimento real.

{}’s

MaRZ