Tesseract OCRは、過去に構築した環境で4.0が稼働している。
あれから6年、現在は5.3になっていた。
スキャナーで取り込んだ画像がPDFになり、それにOCRが掛かる仕掛けを作ってる。
これをUbuntu 22.04の環境で改めて構築する。
インストール
/home/samba/share/scan-request にPDFを置くと、
/home/samba/share/scan-result にOCRされたPDFが作られるようにする。
過去の記事を見ながら設定を進めてメモしていて、過去記事に書いていた詳細情報は省いている。
AlfrescoにOCR機能を追加してみる
Ubuntu18.04 ファイルが置かれたらOCRに掛ける仕組みの構築
※サーバーへのアクセスにはSambaを利用しているが、Sambaについてこの記事では取り扱わない。
Tesseract OCR
ドキュメントにあったバイナリーの入手先がこちら。
開発版をコンパイルして提供してくれているので、このリポジトリを追加。
$ sudo add-apt-repository ppa:alex-p/tesseract-ocr-devel
Repository: 'deb https://ppa.launchpadcontent.net/alex-p/tesseract-ocr-devel/ubuntu/ jammy main'
Description:
This PPA contains an OCR engine - libtesseract and a command line program - tesseract. The development version available here (currntly 5.0.0 ) is better in many aspects (functionality, speed, stability) but is not 100 % API compatible with version 4.0. Tesseract 4 added a new neural net (LSTM) based OCR engine which is focused on line recognition, but also still supports the legacy Tesseract OCR engine of Tesseract 3 which works by recognizing character patterns. Compatibility with Tesseract 3 is enabled by using the Legacy OCR Engine mode (--oem 0). It also needs traineddata files which support the legacy engine, for example those from the tessdata repository. Tesseract has unicode (UTF-8) support, and can recognize more than 100 languages "out of the box". Tesseract supports various output formats: plain text, hOCR (HTML), PDF, invisible-text-only PDF, TSV. The master branch also has experimental support for ALTO (XML) output.
More info: https://launchpad.net/~alex-p/+archive/ubuntu/tesseract-ocr-devel
Adding repository.
Press [ENTER] to continue or Ctrl-c to cancel.[Enter]
表示されたメッセージをDeepL先生に翻訳してもらった。
このPPAにはOCRエンジンであるlibtesseractとコマンドラインプログラムであるtesseractが含まれています。ここで利用可能な開発版(現在5.0.0)は、多くの側面(機能性、速度、安定性)において優れていますが、バージョン4.0とのAPI互換性は100%ではありません。Tesseract 4では、行認識に特化した新しいニューラルネット(LSTM)ベースのOCRエンジンが追加されましたが、文字パターンを認識することで動作するTesseract 3のレガシーOCRエンジンも引き続きサポートしています。Tesseract 3との互換性は、レガシーOCRエンジンモード(--oem 0)を使用することで有効になります。また、レガシーエンジンをサポートするtraineddataファイル(例えばtessdataリポジトリのもの)が必要です。Tesseractはユニコード(UTF-8)をサポートしており、100以上の言語を「すぐに」認識することができます。Tesseractは様々な出力フォーマットをサポートしています: プレーンテキスト、hOCR(HTML)、PDF、不可視テキストのみのPDF、TSV。masterブランチでは、ALTO(XML)出力も実験的にサポートしている。
Tesseract OCRをインストール。今日の最新版5.3がインストールされた。
$ sudo apt install tesseract-ocr tesseract-ocr-jpn tesseract-ocr-jpn-vert $ tesseract --version tesseract 5.3.1-22-g24da leptonica-1.82.0 libgif 5.1.9 : libjpeg 8d (libjpeg-turbo 2.1.1) : libpng 1.6.37 : libtiff 4.3.0 : zlib 1.2.11 : libwebp 1.2.2 : libopenjp2 2.4.0 Found SSE4.1 Found OpenMP 201511 Found libarchive 3.6.0 zlib/1.2.11 liblzma/5.2.5 bz2lib/1.0.8 liblz4/1.9.3 libzstd/1.4.8 Found libcurl/7.81.0 OpenSSL/3.0.2 zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.2 libpsl/0.21.0 (+libidn2/2.3.2) libssh/0.9.6/openssl/zlib nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.5.14
pdfsandwich
一緒に利用するpdfsandwichもインストールする。色々とできるツールだけに、多数のライブラリがインストールされる。
$ sudo apt install pdfsandwich $ pdfsandwich -version pdfsandwich version 0.1.7
pdfsandwichが使用するImageMagickで、PDFの読み書きができるようにする。
/etc/ImageMagick-6/policy.xml
<!-- <policy domain="coder" rights="none" pattern="PDF" /> --> <policy domain="coder" rights="read|write" pattern="PDF" />
Incron
Sambaの共有フォルダにファイルが置かれたら、スクリプトを起動するように、特定のフォルダを監視したい。
$ sudo apt install incron
スクリプトをrootで処理できるように、rootを追加。
/etc/incron.allow
root
監視フォルダと監視条件、起動するスクリプトを設定。
$ sudo incrontab -e
/home/samba/share/scan-request IN_CLOSE_WRITE /usr/local/bin/ocr.sh $@ $#
OCRするスクリプトを作成する。
過去のメモによれば
IN_CREATEフラグはファイルが作られたときに反応するので、共有フォルダにファイルが置かれたときに動作する。
OCRするスクリプトは同じフォルダにファイルを置くけれども、/tmpでファイルを作り、それを移動してくるので、このフラグでは反応しなくて都合が良い。
としていたが、Ubuntu 22.04では、mvしてもIN_CREATEイベントが発生するため、OCR結果を別のディレクトリに置かざるを得なかった。
仕方なく、scanディレクトリにファイルが置かれたら、scan-ocrディレクトリに結果が出力されるようにした。
その代わりに、イベントとしてIN_CLOSE_WRITEを使うことにしたので、ファイルのコピーが終わるのをなんとなく待つためのsleepを止めることにした。
/usr/local/bin/ocr.sh
#!/bin/bash # OCRした結果を保管するディレクトリ DESTDIR=/home/samba/share/scan-result # ファイルの種類を取り出す KIND=`file "$1/$2" | sed -e "s/^.*: //"` # PDFだったらOCRに掛ける if [[ $KIND =~ ^PDF.+$ ]]; then # 作業用のシンボリックリンクを作成 WORK="/tmp/$2" ln -s $1/$2 $WORK # 縦書き対応、時間がかかる #flock /tmp/ocr.lock pdfsandwich "$WORK" -rgb -lang jpn+jpn_vert # 横書きのみ、早い flock /tmp/ocr.lock pdfsandwich "$WORK" -rgb -lang jpn # 処理後のファイル名を生成 DEST=${WORK%.*}_ocr.${WORK##*.} # ファイルの属性だけをコピー cp --preserve=mode,ownership --attributes-only "$1/$2" "$DEST" # シンボリックリンクを削除 rm $WORK # できあがったファイルを指定のディレクトリに移動させる mv $DEST $DESTDIR fi
作成したスクリプトに実行権限を付ける。
$ sudo chmod +x /usr/local/bin/ocr.sh
その他
白黒とフルカラー
以前からフルカラーのPDFを取り扱っており、フルカラーでOCRに掛けているが、本当は白黒が一番精度が上がるといわれている。
以下のような条件のPDFで試してみた。
- 300DPIのフルカラー。
- わら半紙に黒で文字が書かれていて、捺印は朱色。
公開しづらい文書なので画像や読み取り結果は置けないけれど、この場合はカラーの方が精度が良かった。
紙に色が付いていたり、文字に色が付いていたりすると、結果は変わるかもしれない。
ファイルのサイズ
スキャナーから取り込んだ画像をPDFにする際、適切な圧縮が掛けられていなかった。
これは、年末に買った組み立て式の棚をPDFにしたもの。
情報量の割にサイズがでかすぎる…
$ pdfimages -list scan/20230117082609.pdf page num type width height color comp bpc enc interp object ID x-ppi y-ppi size ratio -------------------------------------------------------------------------------------------- 1 0 image 2448 3483 rgb 3 8 image no 7 0 300 300 11.3M 46% 2 1 image 2448 3483 rgb 3 8 image no 12 0 300 300 10.7M 44% 3 2 image 2448 3483 rgb 3 8 image no 17 0 300 300 10.7M 44% 4 3 image 2448 3483 rgb 3 8 image no 22 0 300 300 10.3M 42% 5 4 image 2448 3483 rgb 3 8 image no 27 0 300 300 6448K 26%
OCRに掛けたら、image→jpegに変換され、適切なサイズに圧縮されていた。
$ pdfimages -list scan-ocr/20230117082609_ocr.pdf page num type width height color comp bpc enc interp object ID x-ppi y-ppi size ratio -------------------------------------------------------------------------------------------- 1 0 image 2448 3483 rgb 3 8 jpeg no 11 0 300 300 1663K 6.7% 2 1 image 2448 3483 rgb 3 8 jpeg no 24 0 300 300 1474K 5.9% 3 2 image 2448 3483 rgb 3 8 jpeg no 37 0 300 300 1463K 5.9% 4 3 image 2448 3483 rgb 3 8 jpeg no 50 0 300 300 1603K 6.4% 5 4 image 2448 3483 rgb 3 8 jpeg no 63 0 300 300 1046K 4.2%
拡大して見比べれば、紙のちょっとしたグレー加減が違うかなとは思うけれども、普通のサイズで見ればほとんど差がない。
最初にPDFを作る時に適切な変換を掛けて、無駄を削減しなければ(今後の課題)。
さいごに
以前はソースから色々コンパイルしたのでちょっと大変だったけれども、今はパッケージをインストールして、チョロっと設定をするだけで、この環境が構築できる。
Tesseract OCRは開発版に追従していく形になるけれど、このパッケージについてはその方が良さそうなので、割り切ることにした。
構築が圧倒的に楽だし、仮に上手くいかなくても、仕事じゃないんで大した問題にはならないだろうな、と。
んー、incronが発生させるイベントが以前と違っていたのはなんでだろう?
コマンドラインからスクリプトを実行すると、同じディレクトリにファイルをmvしてもIN_CREATEイベントが発生しないところまでは行ったんだけれども、incronから呼び出されるとmvでIN_CREATEイベントが発生してしまうので、どうしても同じディレクトリにファイルを置くことができなかった。
回避できるからいいか、割り切って寝よう…
コメントはこちらから お気軽にどうぞ ~ 投稿に関するご意見・感想・他