HEIF を TXT に変換

このページが想定しているのはデスクトップでの場面です。写真はすでにパソコンの中にあります——携帯電話からコピーされ、ギャラリーから書き出され、同僚から送られ、バックアップから取り出されたものです。そして風景ではなく書類です。請求書、メーターの数値、手書きのメモ、契約書の 1 ページ、スキャンではなく写真で撮られたマニュアル 40 ページなど。

携帯電話上では、OS が写真の中の文字を選択できる機能を持っていることが多く、どんな Web サイトより速く済みます。デスクトップでこの形式のファイルを扱う場合、たいてい何もありません。サムネイルすら表示されないこともあります。ブラウザーのタブの中での文字認識は、何かをインストールせずに済む数少ない道の 1 つです。

文字認識エンジンは渡されたファイルを、何もデコードせずにそのまま読みます。これは意図的な設計です。読み込みの途中でキャンバスを経由させると透明度が黒く平坦化されてしまい、白い紙のスキャンではそれが読めるか読めないかの分かれ目になります。ただしその結果、扱える画像形式はエンジンに組み込まれた 6 つだけになります。BMP、JPEG、PNG、PBM、WebP、アニメーションでない GIF です。HEIF はその中になく、このサイトが提供する文字認識のコアのどこにも HEIF の読み込み処理は存在しません。

つまり作業は 1 回ではなく 2 回の変換になります。まずこのサイトで HEIF を PNG に変換し、次にその PNG から文字を読み取ってください。最初の段階を担うデコーダーは文字認識エンジンとは別のソフトウェアで、こちらは HEIF を読めます。だから HEIF から PNG や HEIF から JPG のページはそれぞれ単独で機能します。間に挟むファイルには PNG を選んでください。写真は撮影した機器の中ですでに一度圧縮されており、2 回目の非可逆な処理は、文字認識が識別しようとしているまさに細い線に影響してしまいます。

このサイトの他のすべてのペアは、うまくいくか、はっきり失敗するかのどちらかです。ある画像は別の画像になり、エンコーダーが処理できなければエラーになります。文字認識は種類が違います。ページが実際に何と書いてあったかにかかわらず、文字そのものに見える文字列を返します。

つまり出力は書き起こしではなく読み取り結果であり、元データと照らし合わせて確認する必要があります。これは読み飛ばしてよい注意書きではなく、このペアについてもっとも重要な実務上の事実で、結果をどう使うべきかを決めるものです。

用意されているモデルは英語、ドイツ語、フランス語、スペイン語の 4 つです。それぞれがその言語の字形と語彙を学習したモデルで、文字認識エンジンは選んだ言語の中だけで動作します。

間違った言語を選んでもエラーにはなりません。それがこの節をあえて設けている理由です。正しい答えを含まない集合の中でもっとも近い候補が返ってくるので、文章として流暢で、それらしい形をしていながら、内容は間違っています。結果がなぜかわからないほど奇妙に見えるなら、まずこれを確認してください。たいていの原因はここにあります。

文字認識はこのサイトの中でも際立って遅い処理で、最初のファイルにかかる待ち時間の大半は読み取りそのものではなく、数メガバイトの WebAssembly と言語モデルのダウンロードとコンパイルです。

そのコストは言語ごとに 1 回だけ払われ、そのセッションの間は保持されます。モデルはそのあとブラウザーにキャッシュされるので、明日また文書を処理してもダウンロードし直しにはなりません。実務上の帰結は直感に反します。20 ページのフォルダーをまとめて処理するほうが、1 枚ずつ変換するよりページあたりでははるかに効率的です。1 ファイルずつではなくまとめて処理してください。

携帯電話の写真では解像度が問題になることはめったにありません。1200 万画素あれば、ページがフレームの一部を占めているだけでも文字あたり十分な画素数があります。問題になるのは幾何学的な歪みと光です。

ページはカールさせず平らにして、椅子に座ったままではなく真上から、光は横から当てて自分の影が文字にかからないように撮影してください。この 3 点は、このページのどの設定よりも結果を左右し、斜めから撮られたページは、どれだけ解像度を上げても補えない誤りを生みます。

出力は平文です。読み取り順の単語と改行だけで、それ以外はありません。段組み、表のセル、見出し、ページ上の位置はありません。テキストファイルにはそれらを置く場所がないからです。

手紙や領収書はこの処理によく耐えます。2 段組みのページは、文字認識が行のように見えるものすべてを横切って読むため、内容が入り混じります。数値の表は列のない数字の羅列に崩れ、フォームはラベルと値が解きほぐしにくい形で隣り合ってしまいます。そうした書類には、一度に 1 つの区画だけを撮影するほうが、実際に使える結果を得られます。

段落の間の空行はそのまま残り、1 つの文が折り返されているように見える行も結合されません。これは未完成なのではなく意図的な設計です。どちらの整形も、レイアウトについての推測にすぎず、詩や住所の羅列、表はどれも、改行が並べ替えられると意味を失うからです。

ダウンロードするファイルは読み取られたそのままの姿で、それを整形し直す判断は、両方を見比べられるエディターの中であなた自身が行うべきものです。それが正しい順序です。書類を黙って再整形してしまう変換ツールは、見つけたものをそのまま渡す変換ツールよりずっと信用しにくいものです。

文章には余裕があります。文の中で読み間違えられた 1 文字はたいてい目立ち、読む側が気づかないうちに補って読んでしまいます。数字にはそうした冗長性がありません。金額、口座番号、メーターの数値、日付の中の誤った 1 桁は、正しい数字とまったく同じに見え、文の中に矛盾を示すものは何もありません。

人々が写真に撮る書類は圧倒的に数値中心のもの——請求書、領収書、明細書、検針票、手紙の中の参照番号——なので、有効な習慣は、テキストを文章の下書きとして扱い、どこかへ送る前にすべての数字を写真と照らし合わせて確認することです。

写真がアップロードされることはありません。それ以外の何かも同様で、これはあえて手を加えた部分です。文字認識ライブラリは通常、ワーカースクリプトと WebAssembly のコア、言語モデルを、経路をすべて上書きしない限りサードパーティの CDN から取得します。ここではその 3 つすべてがこのサイト自身から配信されます。

この違いは見た目以上に重要です。写真自体はどのみち外へ出ませんが、給与明細を読み取っている人が、その事実を住所や見ているページと一緒にコンテンツネットワークへ知らせることになってはいけません。それらのサードパーティ URL のどれかが再び現れれば、ビルドを失敗させるテストが存在します。

テキストファイルは派生物であり、誤る可能性のあるものです。記録として残るのは元の HEIF のほうです。このサイトではそれをかけがえのないものにしている理由もあります。このサイトはこの形式を読めますが書き出すことはできません。デコーダーは静的サイトが守れる形でライセンスされていますが、エンコーダーはそうではないからです。

書類が重要なら両方を残し、検索できる文字の隣に人に見せられるページがあるように、写真を PDF にも変換しておくことを検討してください。見せられる画像と検索できる文字——その組み合わせこそ、この作業を始めるほとんどの人が本当に求めているものです。

ここのモデルは活字体で訓練されており、それをよく読み取ります。清潔で真っすぐで、程よい大きさの一般的な書体の文字はほぼ完璧に返ってきます。見慣れない装飾書体、非常に小さい文字、強い斜体はどれも精度を落とし、かすれた FAX や何世代も複製されたコピーは大きく精度を落とします。

手書きは程度の問題ではありません。筆記体のメモ、署名、領収書に手書きされた金額、手で記入されたフォームは、単語らしく見えて実際には何にも対応しない出力を生みます。写真の中で価値ある部分が手書きなら、正直な答えは自分でタイプすることであり、この変換はその周りの活字部分——フォーム、レターヘッド、裏面の規約など——に使ってください。

フォルダーの中身が混在している場合——書類の写真もあれば風景写真もあり、すでに別の形式のものもある場合——変換のあとではなく前に仕分けしてください。文字認識はこのサイトでもっとも遅い処理で、文字を含む 12 枚を見つけるために 40 枚の写真すべてに処理をかけるのは、午後の時間の使い方として賢くありません。

もう 1 つ先に決めておく価値があるのが言語です。この設定は置いたものすべてに適用され、初期化された認識エンジンはそのセッションの間保持されます。ドイツ語だけのフォルダーなら、設定は 1 回で 40 回の高速な読み取りが済みます。2 つの言語が混ざったフォルダーには、途中で設定を切り替えて 2 回に分けて処理するほうがよく、初期化のコストが 1 回余分にかかるだけで、それらしい誤りだらけのファイルを避けられます。