縦書きの本をスキャンして OCR にかけると、一行ずつの文字はそれなりに合っているのに、出てきたテキストの並びがばらばらになっていることがある。二段組みの左の段と右の段が一行おきに交互になっていたり、柱や注釈が本文の途中に割り込んでいたりする。文字を読む仕事と、読んだ行を人が読む順に並べる仕事は別物で、後者を持っている日本語 OCR はそれほど多くない。NDLOCR-Lite は、その両方を持っている。
国立国会図書館が公開している OCR
NDLOCR-Lite は、国立国会図書館が ndl-lab/ndlocr-lite で公開している日本語 OCR である。コードと学習済みモデルの両方が CC BY 4.0 で公開されており、出典を示せば改変も再配布もできる。同館は所蔵資料のデジタル化とその全文テキスト化を進めており、その過程で作られたものが外部にも使える形で出ている、という成り立ちである。
同館にはもともと NDLOCR という、より多くのモデルを組み合わせた OCR がある。名前と構成から見て、NDLOCR-Lite はその軽量版という位置づけだと考えられる。ただし、両者の精度差を数値で示した一次資料は見つけられなかったので、ここは推測にとどめておく。確実に言えるのは、モデル 4 つ、合計およそ 150 MB という大きさであり、これはサーバーを持たない個人の端末でも動かせる規模だということである。
三つの段階
ページ画像が文字列になるまでに、NDLOCR-Lite は三つの段階を踏む。段階が分かれていることが、 冒頭で触れた「並びがばらばらになる」問題を防いでいる。
1. 行を見つける
DEIMv2 という物体検出モデルが、ページ全体から文字の行を探す。ページを 800 × 800 に収めて一度だけ推論し、行の位置を矩形として返す。このとき返ってくるのは行だけではない。本文の段やカラムにあたる領域も別のクラスとして返され、これが三段階目の材料になる。あわせて、その行がおよそ何文字くらいかの見積もりも返る。
2. 行を読む
切り出した行を PARSeq という文字認識モデルが読む。ここが独特で、入力の幅が違う三つのモデルを使い分ける。短い行は幅 256、中くらいの行は幅 384、長い行は幅 768。一段目が見積もった文字数でまず宛先を決め、実際に出てきた文字数がそのモデルの上限に届いていたら、取りこぼしを疑って一段大きいモデルに送り直す。
一つの大きなモデルで全部読めばよさそうなものだが、そうしない理由は解像度にある。幅 768 のモデルに三文字の見出しを入れると、一文字あたりに割り当てられる画素が無駄に多くなるかわりに、処理時間だけが長い行と同じだけかかる。逆に幅 256 のモデルに五十文字の本文を入れると、一文字が数画素に潰れて読めない。行の長さに合わせて器を選ぶ、という素朴な工夫である。
縦書きの行も、このモデルがそのまま読む。切り出した矩形が縦長だったら反時計回りに 90 度回してから入力する、というだけの処理で、認識モデルから見れば横書きと同じ形になる。
3. 行を並べる
最後に XY-Cut というアルゴリズムで読み順を決める。ページを格子に落として、縦方向と横方向それぞれに文字の量を集計し、値が最も長く続けて低いところ、つまり最も広い余白で切る。切った領域の中で同じことを繰り返す。行と行の距離を閾値で比べる素朴なやり方だと、段間の余白と行間の余白の区別がつかず、同じ段の行が別々のまとまりに割れてしまう。ページ全体の余白の構造を見ることで、そこを避けている。
縦書きへの対応は、この再帰の中に一行分だけ入っている。左右に切った領域では、その中の行が縦長のものばかりなら、子の領域を逆順に辿る。つまり右の段から読む。二段目で説明した 90 度回転とあわせて、縦書きは「行の中の処理」と「行の並べ方」の二か所で扱われていることになる。
得意な資料
三つの段階のどれも、図書館のデジタル化資料を相手にすることを前提に組まれている。得意なものは、そこから素直に決まる。
- 印刷された日本語の本文。最も想定されている入力である。同館は活字の評価に NDLOCR ver.2.1 と同じデータセットと手法を使ったと公表しているが、数値そのものは今回確認できなかった。実感としては、本文のように同じ大きさの文字が整然と並んでいる箇所ほどよく読める。
- 縦書き。前節のとおり、認識と読み順の両方で扱われている。縦書きと横書きが混ざったページでも、判定は行ごとに行われるので、ページ単位で指定し直す必要はない。
- 手書き。手書きを含むデータで学習されている。同館は v1.2.1 の時点で、1,065 枚の手書き画像に対する平均の文字誤り率を 0.268 と公表している。おおよそ四文字に一文字は間違う計算になるので、清書された原稿であっても、下読みの手間を減らす道具として使うのが現実的である。
- 段組みのある資料。二段組みの雑誌や報告書のように、段の境界がはっきりした余白で区切られているレイアウトは、XY-Cut が最も力を発揮する形である。
苦手な資料
では、うまくいかないのはどういう資料だろうか。三つの段階それぞれに、つまずきどころがある。
- 行がまっすぐでない画像。一段目は行を矩形で返す。本を開いて撮影したときの綴じ側の歪みや、斜めに置いたまま撮ったスキャンでは、矩形に文字が収まらず、上下が欠けたまま二段目に渡る。撮り直すか、傾きを直してから渡したほうが早い。
- 余白で区切られていないレイアウト。広告ページやポスターのように、要素が重なり合っていたり、余白ではなく罫線や色で区切られていたりすると、三段目が切る場所を見つけられない。文字自体は読めていても、並びは元の見た目と合わなくなる。
- 表。配布物には表の構造を扱うスクリプトが別に付いているが、本文の読み取りを行う三段の中には入っていない。表の中の文字は読めるものの、行と列の関係は失われ、セルの内容が並んだだけのテキストになる。
- 学習した文字セットの外にある文字。認識モデルが出力できるのは、あらかじめ決められた 7,141 文字だけである。常用漢字や旧字体は含まれる一方、絵文字のような記号は入っていない。文字セットにない文字は、別の文字に置き換わって出てくる。
- 横組みの欧文が主体の資料。日本語の資料で学習されているので、英文の論文やソースコードのスクリーンショットには向かない。この用途なら、欧文向けに作られた OCR のほうが確実である。
ブラウザで動かす
NDLOCR-Lite の配布物は Windows・macOS・Linux 向けのアプリケーションで、使うには端末にインストールする必要がある。一方で、モデルの実体は ONNX という、実行環境を選ばない形式で入っている。この形式はブラウザでも読めるので、インストールを挟まずに同じモデルを動かせる。
日本語 OCR は、そうやって NDLOCR-Lite をブラウザの中で動かすツールである。三つのモデルと文字セットを一度だけ端末にダウンロードし、以降はその場で推論する。画像はサーバーに送られない。契約書や個人情報を含む書類のように、クラウドの OCR に上げられないものを扱えるのは、この構成の副産物である。
残る問題は速度で、A4 一ページに数十秒かかる。専用のアプリケーションを入れたほうが速いのは、 今のところ動かしようがない。どこまで縮められるかは、まだ試している最中である。