最近のテーブルパーサ
引き続き表のスクレイピングを諦めない。
最近試したテーブルパーサ
table-transformer
GitHub - microsoft/table-transformer: Table Transformer (TATR) is a deep learning model for extracting tables from unstructured documents (PDFs and images). This is also the official repository for the PubTables-1M dataset and GriTS evaluation metric. microsoftのOSS。transformer。PDFは一旦画像に落とす。1ページ内の複数テーブルの認識が怪しい。性能はまだまだ。
PyMuPDF
最近テーブルのスクレイピングに対応した。 Page - PyMuPDF 1.23.8 documentation 検出アルゴリズムがlineとtextの2種類。lineは検出(fs2と同じくらい性能が良い)。 textは “virtual” columnを発見するとのことだが性能はまだまだ。
unstructured.io
github.com なんかものすごい勢いで色々なものを寄せ集めて全部対応するらしい。テーブル対応の評価は、今やってる。
nohgat
GitHub - facebookresearch/nougat: Implementation of Nougat Neural Optical Understanding for Academic Documents 未評価。良さそうに見えるんだが。
みな考えることは同じで、悩みも同じ。解決策はない。 www.youtube.com https://www.reddit.com/r/LocalLLaMA/comments/1854d06/table_extraction_from_pdf/
2022年
一度はあきらめましたが、引き続き表のパースをやっていきたいと思います。 PDFも画像もすべてやっていくぞ。
最近の開発(表のパースについて)
ブログをずっと更新していなかったので、最近について書きます。
引き続きHTML/PDF中のテーブルをパースするfs2の開発を続けています。 テーブルのOCRについては以下のようなサービスやライブラリがあることを認識しています。どれも機能や品質、価格に一長一短があり、 やはりfs2を作らなければいけないと気持ちを強くしています。
tabula-java camelot AWS Textract Microsoft Azure Form recognizer Cascade tabnet PDF to Excel or CSV (https://www.sejda.com/pdf-to-excel) Kaptiche https://www.sensiple.com/kaptiche Kanverse https://www.kanverse.ai/intelligent-document-processing IBM Watson Table Understanding https://cloud.ibm.com/docs/discovery-data?topic=discovery-data-understanding_tables Google Document AI https://cloud.google.com/solutions/document-ai
AWS Textractについて調べた
AWS Textractは、PDFデータや画像データに含まれるフォーム形式のデータ、または、表形式のデータを読み取り、機械判読可能なデータに変換するサービスです。
2019年8月現在まだ日本語はサポートしていませんが、どのようなデータをパースできるのか実際に使ってみました。
条件
Excelで作成したデータをPDF形式で出力しAWS Textractにアップロードして認識させる。現実バージョンは、tabula-javaのテストに用いられているPDFデータをそのまま利用する。
- シンプルな表(罫線あり)
- シンプルな表(罫線一部のみ)
- シンプルな表(罫線なし)
- 複雑な表(罫線あり)
- 複雑な表(罫線一部のみ)
- 複雑な表(罫線なし→これはありえないのでパス)
- テキストの列挙
- 同じ構造の繰り返し
- 現実バージョン1
- 現実バージョン2
- 現実バージョン3
- 現実バージョン4
結果
(1) シンプルな表(罫線あり)
入力
出力
なし
評価: 表形式を認識できない。アラインメント(右寄せ)を調整してみたが認識できない。
(1-2) シンプルな表(罫線あり、大きなフォント)
入力:
出力:
評価:
大きなフォントに変換するとテーブルとテキストを認識する。
(2) シンプルな表(罫線一部のみ)
入力
出力
評価: 表形式は認識できたが、正しく文字を認識できない。”col" の半角小文字の"L"を罫線と認識してしまっている。
(3) シンプルな表(罫線なし)
入力
出力
評価: 罫線がなくなると正しく認識できた!罫線が苦手のよう。
(4) 複雑な表(罫線あり)
入力
出力
評価:罫線があっても、parent, 2018, 2019を除くとほぼ正しく抽出できている
(5) 複雑な表(罫線一部のみ)
入力
出力
評価:
4に比べて精度が落ちている。
(6) 複雑な表(罫線なし→これは現実的にありえないのでパス)
(7) テキストの列挙
入力
出力
評価:パーフェクト
case7_2
入力
出力
評価:パーフェクト
case7_3
入力
出力
評価: 文字が認識できなくなる。
(8) 同じ構造の繰り返し
入力
出力
評価:
そもそもこの同じ構造を繰り返す形式はサポートしていないよう
(9) 現実バージョン1
入力
出力
評価: 親子関係が死んでいる以外はパーフェクト。フォントによるのかな?
(10) 現実バージョン2
入力
出力
評価:
パーフェクト。2ページ目は表と認識しないのも正解。
(11) 現実バージョン3
入力
出力
評価
行が正しく認識できていない(odd行even行の色違いを認識しない)
- 現実バージョン4
入力
出力
評価:
4つのテーブルは認識しているが、行を認識できていない。
まとめ
- テーブルにはキー(ヘッダ)とバリューが存在するが、現時点でのバージョンでは何がキーで何がバリューかを認識できない。
- 一般的にPDFデータには文字情報が含まれているが、その文字情報は利用していないよう(もったいない)。飽くまで画像のOCR。
- 抽出できるかどうかはフォントに依存するよう。
- CSVを生成するところでミスが多い。
- 罫線が苦手のよう。
インボイスや申請書の認識(フォーム)の成績は結構よいとのことですので、表(テーブル)の認識はまだまだこれからのようですね。日本語版を作るのはおそらく大変でしょう。
happyou.infoの新元号対応完了
新元号令和に対応しました。
令和1/5/1 Wed May 01 00:00:00 JST 2019 [令和1/5/1] 令和01/5/1 Wed May 01 00:00:00 JST 2019 [令和01/5/1] R1.5.1 Wed May 01 00:00:00 JST 2019 [R1.5.1] R01.5.01 Wed May 01 00:00:00 JST 2019 [R01.5.01] 令和01年5月01日 Wed May 01 00:00:00 JST 2019 [令和01年5月01日] 令和1年5月01日 Wed May 01 00:00:00 JST 2019 [令和1年5月01日] 令和元年5月01日 Wed May 01 00:00:00 JST 2019 [令和01年5月01日] H31.4.30 Tue Apr 30 00:00:00 JST 2019 [H31.4.30] H31.5.01 Wed May 01 00:00:00 JST 2019 [H31.5.01] 平成31年4月30日 Tue Apr 30 00:00:00 JST 2019 [平成31年4月30日] 平成31年5月1日 Wed May 01 00:00:00 JST 2019 [平成31年5月1日] 平成32年1月1日 Wed Jan 01 00:00:00 JST 2020 [平成32年1月1日] 令和2年1月01日 Wed Jan 01 00:00:00 JST 2020 [令和2年1月01日] 令和2年5月01日 Fri May 01 00:00:00 JST 2020 [令和2年5月01日]