happyou.infoのブログ

ニュース収集サイトhappyou.infoのブログです。 国内外のあらゆる企業と組織、団体のウェブサイトの更新を収集します。 岡本将吾が運営しています。twitterは @happyou_info_ja です。

最近のテーブルパーサ

引き続き表のスクレイピングを諦めない。

最近試したテーブルパーサ

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. microsoftOSS。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/

Adobe PDF Extract API を動かしてみた

だいたい久しぶりにブログを書いた。 この手のサービスでは一番性能が良いと思われる。 これはとても辛い判断ではあるけれども、独自の実装は諦めることにした。 どうやっても勝てそうにない。

qiita.com

おそらくテーブル外のテキスト(タイトルや脚注)は別のAPIを使って拾えということなのだろう。

最近の開発(表のパースについて)

ブログをずっと更新していなかったので、最近について書きます。

引き続き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データや画像データに含まれるフォーム形式のデータ、または、表形式のデータを読み取り、機械判読可能なデータに変換するサービスです。

aws.amazon.com

2019年8月現在まだ日本語はサポートしていませんが、どのようなデータをパースできるのか実際に使ってみました。

条件

Excelで作成したデータをPDF形式で出力しAWS Textractにアップロードして認識させる。現実バージョンは、tabula-javaのテストに用いられているPDFデータをそのまま利用する。

  1. シンプルな表(罫線あり)
  2. シンプルな表(罫線一部のみ)
  3. シンプルな表(罫線なし)
  4. 複雑な表(罫線あり)
  5. 複雑な表(罫線一部のみ)
  6. 複雑な表(罫線なし→これはありえないのでパス)
  7. テキストの列挙
  8. 同じ構造の繰り返し
  9. 現実バージョン1
  10. 現実バージョン2
  11. 現実バージョン3
  12. 現実バージョン4

結果

(1) シンプルな表(罫線あり)

入力

f:id:happyou_info:20190716210654p:plain

f:id:happyou_info:20190717002958p:plain

出力

なし

評価: 表形式を認識できない。アラインメント(右寄せ)を調整してみたが認識できない。

(1-2) シンプルな表(罫線あり、大きなフォント)

入力:

f:id:happyou_info:20190801215725p:plain

出力:

f:id:happyou_info:20190801215836p:plain

評価:

大きなフォントに変換するとテーブルとテキストを認識する。

(2) シンプルな表(罫線一部のみ)

入力

[f:id:happyou_info:20190716210714p:plain

出力

f:id:happyou_info:20190801220528p:plain

f:id:happyou_info:20190716214928p:plain

評価: 表形式は認識できたが、正しく文字を認識できない。”col" の半角小文字の"L"を罫線と認識してしまっている。

(3) シンプルな表(罫線なし)

入力

f:id:happyou_info:20190716210728p:plain

出力

f:id:happyou_info:20190716215028p:plain

評価: 罫線がなくなると正しく認識できた!罫線が苦手のよう。

(4) 複雑な表(罫線あり)

入力

f:id:happyou_info:20190716210744p:plain

出力

f:id:happyou_info:20190716215043p:plain

評価:罫線があっても、parent, 2018, 2019を除くとほぼ正しく抽出できている

(5) 複雑な表(罫線一部のみ)

入力

f:id:happyou_info:20190716210757p:plain

出力

f:id:happyou_info:20190716215054p:plain

評価:

4に比べて精度が落ちている。

(6) 複雑な表(罫線なし→これは現実的にありえないのでパス)

(7) テキストの列挙

入力

f:id:happyou_info:20190716210807p:plain

出力

f:id:happyou_info:20190717010625p:plain

評価:パーフェクト

case7_2

入力

f:id:happyou_info:20190717001419p:plain

出力

f:id:happyou_info:20190717010543p:plain

評価:パーフェクト

case7_3

入力

f:id:happyou_info:20190717001449p:plain

出力

f:id:happyou_info:20190717001518p:plain

評価: 文字が認識できなくなる。

(8) 同じ構造の繰り返し

入力

f:id:happyou_info:20190716210837p:plain

出力

f:id:happyou_info:20190716215114p:plain

f:id:happyou_info:20190717011601p:plain

評価:

そもそもこの同じ構造を繰り返す形式はサポートしていないよう

(9) 現実バージョン1

入力

f:id:happyou_info:20190716210851p:plain

出力

f:id:happyou_info:20190716215124p:plain

評価: 親子関係が死んでいる以外はパーフェクト。フォントによるのかな?

(10) 現実バージョン2

入力

f:id:happyou_info:20190716210901p:plain
f:id:happyou_info:20190716210923p:plain

出力

f:id:happyou_info:20190717011850p:plain

評価:

パーフェクト。2ページ目は表と認識しないのも正解。

(11) 現実バージョン3

入力

f:id:happyou_info:20190716210937p:plain
case11

出力

f:id:happyou_info:20190716215147p:plain

評価

行が正しく認識できていない(odd行even行の色違いを認識しない)

  1. 現実バージョン4

入力

f:id:happyou_info:20190717005115p:plain

出力

f:id:happyou_info:20190717005131p:plain

評価:

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日]