Translate

segunda-feira, 18 de abril de 2016

Live Kubuntu 16.04 Xenial beta2: Scanner e OCR

Kubuntu 16.04 Xenial beta2 com as primeiras configurações, 15 minutos após o início da sessão Live USB

O objetivo deste 4º teste de trabalho em Live USB (Pendrive) com o Kubuntu 16.04 Xenial beta2 é, simplesmente, aprofundar a vivência no KDE 5.5.5, — uma vez que, cedo ou tarde, substituirá meu atual “sistema principal” (Kubuntu 14.04 LTS / KDE 4.13.2), — após concluir o relato do 3º teste de trabalho com dúvidas sobre a oportunidade e o método dessa migração.

A sessão Live Kubuntu 16.04 Xenial beta2 foi carregada às 15:32 ou 15:35 (Desktop X Nokia Lumia) do dia 16 Abr. 2016, utilizando a ISO “Daily Build 16-Apr-2016 05:44” gravada em mídia USB (Pendrive) por comando “dd”.

FileZilla, instalado de passagem, para fazer upload de uma correção urgente

Marcos do percurso


  • Uma urgência inesperada exigiu a instalação do FileZilla para fazer upload de uma página “shtml”, rapidamente corrigida no Kate.

  • Uma iminência de prazo de devolução na Biblioteca (2º empréstimo) motivou a instalação do Xsane e do OCRFeed para acelerar o fichamento de trechos para referência.

  • Foi registrado um comportamento do Discover (plasma-discover), capaz de explicar determinadas falhas observadas em testes anteriores, — e de justificar a cautela “supersticiosa” de não fechá-lo logo após a instalação de algum aplicativo.

Enfim, o trabalho diário e as atividades pessoais prosseguiram sem qualquer perda de produtividade. — Pelo contrário, este 4º teste de trabalho em Live USB (Pendrive) com o Kubuntu 16.04 Xenial beta2 está quase como o trabalho normal em um sistema instalado (HD).

Essa normalidade, quase perfeição, talvez reflita os últimos ajustes e correções à ISO “Daily Build 16-Apr-2016 05:44”, — mas, também, o fato de que nesta sessão (ainda) não foram instalados tantos pacotes (Shutter, Kruler, lm-sensors, hddtemp, fancontrol, fonts-arkpandora, pyRenamer, mtp-tools, obexfs, obextool, gphoto2, gphotofs, gmtp, jmtpfs, mtpfs, gthumb, gnokii, Qlix), nem feitas tantas experiências malucas, como substituir o Discover pelo Muon Package Manager e depois des-substituir, por exemplo. — Enfim, os 3 testes anteriores podem ter ensinado a evitar algumas burradas.

Xsane: salvar automaticamente, pelo número das páginas, com incremento +2

Xsane


O scanner (USB) foi conectado somente na hora de iniciar o trabalho, e no minuto seguinte já foi reconhecido pelo Xsane.

O “Acquire preview” do Xsane foi utilizado apenas 1 vez, para um ajuste inicial do contraste.

A “seleção” (serrilhado) foi abandonada, — é mais seguro captar a mais, do que arriscar captar de menos, — para dispensar a necessidade de novo “preview” a cada página virada.

A numeração no padrão “0222-0223.jpg” foi abandonada em favor de um padrão simplificado, — “0222.jpg”, — uma vez que apenas 1 dos números seria automaticamente incrementado (opção “+2”).

O uso da escala de cinza (“Gray”) acelera a captura e gravação automática, — substituir “View” por “Save”, selecionar a Pasta e preencher o nome / número da página inicial: “0222.jpg”, — mas é possível obter um contraste mais nítido, com algum tempo de estudo e experimentação.

Sem afobação, — e conferindo periodicamente a numeração, para não acumular eventuais erros, — foram feitas 59 capturas (118 páginas) em 32 minutos. — É mais rápido scannear a mais (e deletar depois o que não for necessário), do que parar a todo instante, ao longo do processo, para ler, pensar e selecionar (apenas 2 trechos já estavam previamente assinalados). De qualquer modo, precisariam ser guardadas também as páginas com as notas numeradas, ao final dos 2 capítulos.

Por último, foram scanneadas as páginas iniciais (rosto, ficha, Índice, Prefácio do Autor à 2ª edição).

Em 300 dpi, “Full color range”, sem o contraste ideal, as imagens (páginas duplas) resultaram em arquivos de 1,1 a 1,5 MiB (total 8,1 MiB), — porém a rapidez do processo (diante do prazo) compensa o trabalho de deletar o excesso após o OCR, seleção e edição das fichas de referência.

OCRFeeder X gocr


Na falta de experiência ou conhecimentos em OCR (reconhecimento ótico de caracteres), foi feita uma pesquisa por “ocr” no Synaptic, que exibiu 132 pacotes, — dos quais, 113 compõem o Tesseract, — e um exame rápido sugeriu OCRFeeder como a provável melhor opção (o que se confirmou logo no primeiro teste).

O palpite guiou-se menos por sua própria descrição, — que nem chega a citar o reconhecimento de texto em múltiplas colunas, — do que pelas descrições dos pacotes inclusos, e por exclusão de outros possíveis candidatos:

Given the images it will automatically outline its contents, distinguish between what's graphics and text and perform OCR over the latter. It generates multiple formats being its main one ODT.
It features a complete GTK+ graphical user interface that allows the users to correct any unrecognized characters, defined or correct bounding boxes, set paragraph styles, clean the input images, import PDFs, save and load the project, export everything to multiple formats, etc.

Ao marcar OCRFeeder para instalação, — 41 pacotes, inclusive 5 componentes do Tesseract, — foi constatado que não incluiria automaticamente o pacote específico para a língua portuguesa (“tesseract-ocr-por”), acrescentado então manualmente.

The Tesseract OCR engine was one of the top 3 engines in the 1995 UNLV Accuracy test. Between 1995 and 2006 it had little work done on it, but since then it has been improved extensively by Google and is probably one of the most accurate open source OCR engines available. It can read a wide variety of image formats and convert them to text in over 40 languages. This package includes the command line tool.

Já o “gocr”, foi selecionado, em seguida, — sem nenhuma lógica, — apesar da descrição  deixar claro que não seria capaz de lidar com texto em colunas:

Currently the program should be able to handle well scans that have their text in one column and do not have tables.

Havia pacotes com descrições bem mais promissoras, — como “cuneiform” (reconhecimento de layout e formatação), “gimagereader” (idem), “ocrad” (idem), “yagf” etc., — e qualquer um deles teria sido melhor candidato a “segunda opção”. Mas, enfim, não fazia sentido instalar coisas demais, em uma sessão Live.

Texto obtido pelo “gocr”

Bastou 1 teste para concluir que o “gocr” não seria a resposta imediata, — mesmo lidando com 1 página por vez. — No mínimo, exigiria maior estudo, em ocasião menos urgente.

OCRFeeder: resultado quase perfeito, apesar do baixo contraste das imagens

Já o OCRFeeder, apresentou resultados quase perfeitos, apesar do contraste insuficiente das imagens, scanneadas às pressas.

OCRFeeder: 6 páginas à média de 30 a 40 segundos por cada 2 páginas

Outro teste, no segundo dia, — com 9 imagens (18 páginas), — não se completou (a descobrir por quê).

Mas com 3 imagens (6 páginas) foi obtido sucesso, a uma média de 30 ~ 40 segundos por cada 2 páginas.

Avaliação preliminar de falhas do OCRFeeder nas páginas de Notas, com letras menores e mistura de línguas

Para um teste rápido, foram deixados de lados inúmeros recursos oferecidos pelo OCRFeeder, — como “projeto”, que exige algum aprendizado. — Os textos apenas foram copiados e colados (sem formatação) no LibreOffice, para destaque de algumas poucas falhas a corrigir.

Boa parte dessas falhas, — por serem recorrentes, — sugere que poderão ser corrigidas no próprio processo de reconhecimento, em futuros trabalhos, evitando sua repetição daí por diante.

A médio prazo, portanto, — com tempo para estudo, instalação em HD, dicionário de Português etc., — o OCRFeeder promete ser ainda mais produtivo.

Reação inicial do Discover ao clique em “Instalar” (Synaptic): atividade de CPU e pausa

Pacotes instalados pelo Discover


O Discover foi aberto às 15:53, — portanto, 20 minutos após o início da sessão Live USB, — para instalar Synaptic, Gimp, Chromium, Psensor, e ativar os repositórios não-livres.

Logo no primeiro item, registrou-se um “delay” de uns 20 segundos entre o clique para instalar Synaptic e o início efetivo do download.

Discover: download do Synaptic começou 30 segundos após o clique em “Instalar”

Como não havia intenção de documentar o processo, o mouse não foi passado, o tempo todo, sobre o botão azul de “1,3 MiB”, — recurso utilizado, nos testes anteriores, para exibir as indicações de “Install” (comando), “downloading”, “installing” e, por fim, “Remove” (instalação concluída).

A menos que se faça esse “mouse over” no botão azul (tamanho do pacote), não há indicações muito evidentes do que possa estar acontecendo (ou deixando de acontecer).

O exame retrospectivo das Capturas de tela, — em rápida sequência, tipo slide-show, — acabou chamando atenção para o deslocamento horizontal do “botão de tamanho do pacote” (azul).

Logo acima, — na Barra de ferramentas, — o botão cinza-verde de “No updates” também se desloca levemente para a direita.

O motivo desse vai-vem, é que o botão “Installed”, — opção da Barra de ferramentas para listar o que existe instalado no computador (em oposição a “Discover”, para descobrir novidades), — transforma-se em “Indicador de andamento”, passando a exibir “Installing...”.

Além de “Discover”, “Installed”, e “No Updates”, essa Barra de ferramentas simplificada oferece apenas uma seta à esquerda (voltar ao início), o campo de Busca, e um ícone de “Menu” à direita, para mais algumas opções.

Esse tipo de “navegação” extremamente simplificada é uma tendência rumo aos dispositivos móveis, — não entulhar a tela do celular, nem complicar a cabeça do usuário móvel, — e é muito provável que, na telinha miúda, a transformação do botão “Installed” em “Indicador de andamento” salte à vista, como um letreiro luminoso da Broadway.

Não é o que acontece na tela do “desktop”, — nem desperta a atenção do usuário do Synaptic, acostumado com indicações sistemáticas e inequívocas, e sem hábito de usar o antigo “Descobridor do Muon”.

Observa-se que essa pausa não ocorreu, em nenhum momento, ao documentar detalhadamente o comportamento do Discover no 3º teste de trabalho Live Kubuntu Xenial beta. Mas pode ter ocorrido, — inclusive, com duração maior, — nos testes anteriores, em que o Synaptic não foi instalado corretamente, e não funcionou, mesmo após 3 tentativas (e no final, o próprio Discover não abria mais).

Não que pareça muito provável, — pois nas tentativas anteriores o “mouse over” no botão azul “1,3 MiB” foi utilizado para ativar a exibição das fases ”Downloading”, “Installing” e “Remove” (indicador de instalação concluída, ao que se presume), — mas, sempre é uma descoberta a mais sobre o comportamento do Discover atual (plasma-discover).

Discover: marcar “Software restricted by copyright or legal issues (multiverse)

Digno de nota, também, que após marcar no Discover os repositórios “Restricted” seguem-se uns 40 a 50 segundos de intensa atividade de CPU e Rede, — sem nenhum clique “manual” para atualização das informações (“Recarregar”, no Synaptic), e sem qualquer indicação aparente.

Faz sentido, — não exigir que um novo usuário de celular precise “aprender” (e lembrar) a necessidade de “Recarregar” (“manualmente”!) informações dos repositórios etc., — e deixa até meio envergonhado o usuário pré-histórico, acostumado a um Synaptic “carroça”, “complicado” etc.

Discover: recarregamento automático após marcar repositórios “Restricted” (39 atualizações disponíveis)

Porém, ao final dessa atualização automática, — e não informada ao usuário, — o botão cinza-verde passa de “No updates” para “39 updates”.

Então, se o usuário novato não “inventar” de ativar um obscuro repositório “Restricted”, — escondido num sub-sub-menu lá no canto da direita, — não haveria atualização “automática” das informações dos repositórios?

Também faz sentido, — trata-se de uma sessão “Live USB” (e com um “daily build” em plena reta de chegada), onde não faz sentido trabalhar dias seguidos (sem desligar), muito menos atravancar a Memória com dezenas de atualizações em ritmo frenético. — É de se supor que, ao instalar o Kubuntu 16.04 Xenial no HD (após o lançamento oficial), o comportamento do sistema seja outro.

Busca do “Update Manager” no Menu K do Kubuntu 16.04 Xenial beta2 em Live USB

Alguma atualização automática das informações parece haver, — embora, após 2 dias, nenhuma notificação apareça no Painel, e o “Update manager” precise ser procurado, digitando “muon” no Menu K.

Ativação de repositórios “Restricted” no Discover: Menu → Advanced → Configure software sources (18 Abr.)

Às 20:40 do terceiro dia (18 Abr. 2016), — ao abrir o Discover para printar o caminho dos repositórios “Restricted”, — ele já registrava 74 atualizações disponíveis.

Enfim, o Discover tem, — guardado no Menu, — a opção “Check Updates”, que também pode ser acionada por “Ctrl-R” (lembra o “Recarregar” do Synaptic).

Acionado o Ctrl-R, o número de atualizações oferecidas passou para 86, — incluindo o próprio Discover.

De acordo com o Synaptic, — que confronta a versão instalada com a versão mais atual, — o que está rodando aqui é plasma-discover 5.5.5-0, enquanto a versão disponível nos repositórios já é 5.6.2-1.

Synaptic: busca, marca e aplica download e instalação enquanto “Rebuilding search index”

Pacotes instalados pelo Synaptic


Mais tarde, ainda no primeiro dia (16 Abr. 2016), o Synaptic foi utilizado 3 vezes: — às 16:45, para instalar ttf-mscorefonts-installer; — às 17:34, para instalar FileZilla; — às 21:15 para instalar OCRFeeder, Xsane, e (para comparação) Gocr. — No quarto dia (19 Abr.), foi instalado o pyRenamer.

O exame repetido e detalhado do funcionamento do Discover, — ao longo de 4 testes de trabalho em Live Kubuntu 16.04 Xenial alpha e beta, — estava a pedir um exame também do Synaptic.

Foi constatado, por exemplo, que ao ser aberto ele também ocupa intensamente a CPU, — “Rebuilding search index”, — por cerca de 1 minuto ou mais.

No entanto, não trava os movimentos do usuário, — você pode digitar no campo de busca, desde o primeiro segundo, e os resultados são exibidos de imediato.

Além disso, — ao contrário da “animação” inicial do Discover, — a ocupação da CPU pelo Synaptic não prossegue ad infinitum. Uma vez realizada a tarefa, ela cessa, e ponto final.

Você pode, inclusive, fechar o Synaptic, se arrepender, — e reabrir dentro de alguns minutos, — sem que o processo se repita.

Fuso horário e o mistério dos minutos


Ao carregar, o Kubuntu 16.04 Xenial beta2 exibiu a mesma hora “herdada” do sistema, — sem alterá-la para a hora UTC daquele momento, — por isso, não foi feita a configuração imediata para o Fuso horário oficial de Brasília (“São Paulo”).

Somente às 23:57, o Relógio do Painel apresentou avanço para o horário de Londres (2:57), e foi feita a configuração do Fuso horário, — porém, manteve-se a diferença em relação ao celular, que já marcava 0:00.

Por consequência, todas as Capturas de tela do primeiro dia, — salvas em padrão “YYYY-MM-DD_HH-mm-SS_Kx.png”, — aparecem no Dolphin com “hora” 3 horas anterior à indicada em seus nomes (que é a hora real de Brasília, assim como a hora exibida pelo Relógio nos prints).

Quanto à diferença de 3 minutos entre as horas do computador e do celular, vem sendo observada, já há algumas semanas, — tanto em sessões Live USB quanto em sessões Mint e Kubuntu instalados (HD), — ainda sem explicação, uma vez que tanto o computador quanto o celular estão configurados para sincronização automática a partir de servidores confiáveis (ao que se supõe).

Durante a sessão Live USB, essa diferença chegou a 7 minutos, porém a média foi de 5 minutos na maior parte do tempo, — até 23:03 do terceiro dia (18 Abr.), quando finalmente as horas do computador e do celular se harmonizaram.

Temperatura, uso de Memória e Swap ao amanhecer do 4º dia da sessão Live USB Kubuntu Xenial beta2

Ao amanhecer do quarto dia (19 Abr. 2016), os relógios do computador e do celular seguiam sincronizados, com diferença de poucos segundos.

______
A sessão Live Kubuntu 16.04 Xenial beta2 foi carregada às 15:32 (Painel) ou 15:35 (Nokia Lumia) do dia 16 Abr. 2016, utilizando a ISO “Daily Build 16-Apr-2016 05:44” gravada em mídia USB (Pendrive) por comando “dd”.
• Este relato foi publicado inicialmente às 16:59 (Painel e Blogspot) ou 17:04 (Windows Phone) do dia 18 Abr. 2016, com 1 imagem de apresentação + 12 parágrafos (Abertura, “Fuso horário e o mistério dos minutos”, “Marcos do percurso”); e desenvolvido até 3:00 do dia 19 Abr., com 13 imagens editadas no Gimp, ainda na sessão Live Kubuntu 16.04 Xenial beta2.
• O relato foi completado por volta das 16:00 do quarto dia (19 Abr. 2016), com mais 2 imagens; e a sessão Live USB será encerrada por volta das 16:35, cerca de 73 horas desde o início.

— … • … —

Kubuntu



Testes de trabalho em “Live USB”


Postado por Mboaba às segunda-feira, abril 18, 2016
Marcadores: , , , , ,

2 comentários:

Assinar: Postar comentários (Atom)