每個人都對掃描文字的建議是使用盡可能高的解析度並正確使用照明。 我運行了這個網站用來對付一組故意損壞的圖像來找出其中哪些問題，答案都不是。 同一句話完美地從原始大小的三分之一圖片中恢復，完美地來自灰色背景上的灰色文字，完美地來自以質量 25 保存的 JPEG。 是什麼破壞了頁面五度。 下面的每個數字都來自那個運行，它們指向與通常的清單不同的清單。
TL;DR: Tesseract 讀取乾淨的文字，直到有兩個特定的問題出現問題。 傾斜是第一個：0 到 3 度的偏差給出 0% 的字元錯誤率，5 度給出 2.9%，12 度給出 16.7%，20 度給出 32.4%。 大小是第二個，它是一個懸崖而不是一個斜坡：文字保持完美到大約 7 像素的資本高度，然後在 5.8 像素處崩潰到 85.3% 的錯誤。 低對比度、模糊和重型 JPEG 壓縮幾乎沒有記錄。 在你做任何其他事情之前，先拉直圖片。 那個 圖像到文字轉換器 在瀏覽器中運行引擎，因此永遠不會上傳圖片。
這些數字是如何產生的？
透過渲染已知的句子，一次以一種方式損壞圖像，重新閱讀，並計算修復結果所需的編輯。
度量是字元錯誤率：圖像所說的內容與引擎返回的內容之間的距離，除以真相的長度。 五十個字元行的 2% 錯誤率是一個錯誤的角色。 文字是三行混合散文、發票號碼、日期、貨幣金額、電子郵件地址和電話號碼，因為在實踐中重要的錯誤發生在第二種內容而不是第一種內容中。
一個警告屬於頂部而不是埋在。 這些是渲染圖像，而不是照片。 每個變數都隔離了一個變數，這是將失敗歸因於一個原因的唯一方法，但是頁面的真實照片會同時出現幾個：輕微傾斜，不均勻的光線，在一邊的運動模糊，以及在保存之前銳化一切的相機。 因此，以下閾值是最佳情況。 一張在兩個軸上正確處的照片會比任何一個數字所暗示的更糟。
引擎是透過 tesseract.js 的 Tesseract 4 的 LSTM 模型，這正是工具運行的，所以這些不是來自不同系統的數字。
多少偏差太多？
三到五度之間，這比你注意到的要小。
| 輪流 | 字符錯誤率 | 報告了信心 |
|---|---|---|
| 0度 | 0.0% | 95 |
| 1度 | 0.0% | 95 |
| 2度 | 0.0% | 95 |
| 3度 | 0.0% | 94 |
| 5度 | 2.9% | 91 |
| 8度 | 7.8% | 82 |
| 12度 | 16.7% | 70 |
| 20度 | 32.4% | 66 |
三度什麼都沒有發生，然後它從架子上掉下來。 原因在於引擎的工作原理：它找到文字行，然後將每一行切成字元。 一條傾斜線穿過幾行像素，因此切片穿過一些字母的頂部和其他字母的底部，並要求模型對片段進行分類。
在 5 度時，錯誤很小而且很昂貴。 「過時的」以「日期Q」和「總共」的「totg）回來。 兩者都是人類直接閱讀的單字中的一個字母，兩者都坐在發票號碼和一個人不檢查的情況下要複製的貨幣金額旁邊。
手持一頁的電話通常會出現超過五度。 這是在運行任何東西之前值得修復的唯一一件事，並且修復是免費的：旋轉圖片直到線路平整。
在 OCR 失敗之前，文字可以有多小？
比你預期的要小，直到它完全停止工作。
| 圖像寬度 | 大寫字母高度 | 錯誤率 | 信心 |
|---|---|---|---|
| 1600 像素 | ~29 像素 | 0.0% | 95 |
| 800 像素 | ~14 像素 | 0.0% | 95 |
| 533 像素 | ~10 像素 | 0.0% | 92 |
| 400 像素 | ~7 像素 | 0.0% | 84 |
| 320 像素 | ~6 像素 | 85.3% | 41 |
| 240 像素 | ~4 像素 | 100.0% | 0 |
相同的三行以原來大小的四分之一完美讀取，每個大寫字母大約七像素高。 再往下一步，輸出無法使用，然後為空。
那是懸崖，而不是漸層，它改變了建議。 「使用您擁有的最高解析度」並沒有錯，但它描述了大多數圖片沒有的問題。 網頁的螢幕截圖、標誌的照片、印刷信的手機照片：所有這些都遠遠超過七像素的字母高度。 他們更常擁有的是傾斜。
懸崖咬的地方是遠處的作物。 節日照片背景中的文字，街對面的標誌，全頁掃描的一線小字，螢幕解析度。 如果字母在 100% 變焦時很難閱讀，那麼引擎也靠近它的地板。
低對比度會破壞讀數嗎？
不，這是最與我預期相矛盾的結果。
#8A8A8A 的灰色文字在 #BDBDBD 的灰色背景上以 0.0% 的錯誤率和 95 的信心，與白色上的黑色相同。 整個影像的三像素高斯模糊得出 0.6%。 以質量 25 保存並縮放到一半大小的 jpeg 得到 0.0%。
原因是引擎沒有讀你的灰色。 它首先將圖像二分化，將所有內容變成黑白，並從圖片中選擇閾值，而統一的低對比度則完好無損地倖存下來。 無法生存的是整個頁面的變化，這是陰影或手機閃光產生的：一個閾值不能適合圖像的兩半。
因此，有用的照明建議比通常的更窄。 即使是照明也很重要。 明亮的照明沒有。 一張昏暗、光線充足的頁面照片，在中間有一個陰影的明亮照片。
為什麼兩列佈局會被爭奪？
因為閱讀順序是一種佈局判斷，而引擎僅憑幾何就完成了。
我在共享的基準上並排渲染了兩個文字區塊，每塊三行。 結果交錯了：
LEFT ONE RIGHT ONE LEFT TWO RIGHT TWO LEFT THREE RIGHT THREE
每個字都是正確的。 訂單沒用。 引擎在三個垂直位置找到六行文字，並讀取每一行，這是一張表格的正確行為，兩列散文的錯誤行為。
真正的報紙頁面或學術 PDF 通常會在這方面倖存下來，因為列之間的排水溝足夠寬且一致，足以檢測頁面分割步驟。 佈局的螢幕截圖，兩個鬆散的塊並排，這是這種工具的常見情況，通常不是。
可靠的解決方案是作物。 運行一列，複製結果，然後運行另一列。 這聽起來很費力，大約需要十五秒鐘，這比重建一個句子被洗牌的段落還要少。
可以讀筆跡嗎?
不可靠，邊界是關於字母是否接觸而不是它們是否看起來非正式。
如果不提供一張會有混合變數的照片，我無法測試真正的筆跡，所以我測試了三種降低規律性的字體作為替身：
| 字體 | 錯誤率 | 信心 |
|---|---|---|
| 漫畫 sans MS | 0.0% | 95 |
| 刷腳本 MT | 5.9% | 67 |
| 斯內爾 圓手 | 20.6% | 55 |
Comic Sans 是非正式的，對引擎來說非常清晰，因為它的字母是一致的寬度的獨立形狀。 Snell Roundhand 是一個連線的腳本，五分之一的角色回來了。
這才是真正的區別。 Tesseract 的模型經過印刷類型訓練，並希望將一條線切成離散字形。 連網書寫沒有乾淨的切點，因此在辨識有機會之前，分割失敗。 真正的筆跡比 Snell Roundhand 更糟，而不是更好，因為它也因字母而異。
如果您需要閱讀手寫，這是錯誤的工具，其他所有 Tesseract 前端也是如此。 該工作需要一個受過筆跡訓練的模型。
哪個角色出錯了？
看起來像數字的字母，方向是一致的。
我渲染了一行通常的嫌疑犯並將其讀回：
truth: O0 l1I 5S 8B 2Z rn/m
read: 00 111 5S 8B 2Z rn/m
資本 O 變成零。 小寫 L 和大寫 I 都成為數字 1。 最擔心的是，5 對 S 和 8 對 B，反擊正確，RN 對 M 也是如此。
模式是將帶有數字形字形的孤立字母讀為數字。 在 Running Prose 中，這很少重要，因為它周圍的語言模型將結果拉回單字。 在參考代碼、序號或車牌中，沒有周圍的字可以提供幫助，而這正是這種工具的使用方式。
校對任何混合字母和數字且沒有空格的字串。 它是引擎自信錯誤的一類輸出。
信心分數告訴你什麼？
大致是頁面的進展，而不是您關心的數字是否正確。
該工具將引擎的平均字置信度顯示為高、中或低，高 85 及以上。 與測量的誤差率相反，該映射在邊緣是廣泛的明智和樂觀的：
| 箱子 | 信心 | 標籤 | 實際錯誤率 |
|---|---|---|---|
| 乾淨的 | 95 | 殷 | 0.0% |
| 5度偏斜 | 91 | 殷 | 2.9% |
| 12度偏斜 | 70 | 媒介 | 16.7% |
| 320 像素寬 | 41 | 低級 | 85.3% |
| 連接腳本 | 55 | 低級 | 20.6% |
低分是一個可靠的警告：所有得分低於 60 的東西都被真正打破了。 高分是比看起來更弱的證據。 5 度的案例得分為 91，介面稱為高，同時在發票行中悄悄地破壞一個單字。
將其用作煙霧警報器而不是保證。 低意味著不要費心閱讀輸出。 高意味著整個頁面進展順利，這與每個角色都是正確的不同。
每種語言下載的費用是多少？
0.67 到 2.82 兆位元組，一次，然後被快取。
引擎每種語言需要一個訓練有素的資料檔案。 由於該工具僅運行 LSTM 模型，因此它拉取了整數化的最佳品質集，這比大多數 OCR 寫入引用的檔案要小得多。 從 CDN 中測量 庫預設為：
| 語 | 下載 | 語 | 下載 |
|---|---|---|---|
| 英語 | 2.82 兆位元組 | 印地語 | 1.32 兆位元組 |
| 俄國的 | 2.56 兆位元組 | 孟加拉人 | 1.31 兆位元組 |
| 西班牙人的 | 2.00 兆位元組 | 韓國的 | 1.50 兆位元組 |
| 日本 | 1.94 兆位元組 | 德國人 | 1.27 兆位元組 |
| 中文（簡化） | 1.64 兆位元組 | 葡萄牙 | 1.33 兆位元組 |
| 阿拉伯語的 | 1.58 兆位元組 | 義大利人 | 1.58 兆位元組 |
| 法國人 | 0.67 兆位元組 |
所有 13 人加起來約 21 MB，這不到一張現代手機的照片。 中文或日文必須是巨大的的普遍假設在這裡並不成立：中文簡化為 1.64 MB，比英語小，因為該文件儲存的是模型而不是字形庫。
為什麼第一次運行比第二個慢？
因為第一個是下載並啟動引擎，第二個只是閱讀。
語言的第一次運行包含 tesseract 的 webassembly 版本，獲取該語言的資料檔案，並初始化一個工作者。 之後，工作人員在頁面中保持活力，並且數據檔案被瀏覽器快取，因此同一種語言的第二張圖像立即開始。 切換語言會重新初始化工作者，但不會重新下載任何已經取得的內容。
認可本身很快。 在這台機器上，讀取三線測試影像對於清潔版本來說需要 186 毫秒，而損壞的版本需要 70 到 125 毫秒，所有這些都在運行的工作人員身上。 對於一整頁的文字，期望一兩頁而不是十分之一，但您注意到的第一次運行等待是設定，而不是閱讀。
一旦語言被緩存，該工具根本無法使用網路，這是一種真正的離線能力，而不是行銷線。
在執行 OCR 之前，您應該對圖像做什麼？
三件事，依這個順序，第一件事比其他兩件事加起來更重要。
- 拉直它。 旋轉直到文字行平整。 三度是免費的，五度是免費的。
- 裁剪到文字。 這修復了列問題，刪除分段器必須拒絕的背景，並使文字在框架中佔有更大的份額。
- 別管其他一切。 不要磨刀，不要提高對比，不要用手轉換成黑白。 無論如何，引擎二進製，銳化濾鏡增加了以前沒有的字母邊緣的振鈴。
值得添加而不是刪除的是分辨率，但前提是您靠近地板。 從 7 像素大寫高度到 14 像素，在測量中沒有任何變化。 從 6 到 7 改變了一切。
什麼時候 OCR 是錯誤的工具？
當圖片不是文字時，文字是手寫的，當您想要的東西是可搜尋的文件而不是字元塊時。
OCR 為您提供沒有結構的單字：沒有標題、沒有表格單元格、沒有您可以信任的段落邊界、沒有跨複雜佈局的閱讀順序。 截圖中的報價或照片中的地址完全正確。 對於將掃描的報告轉換為可編輯的內容，這是幾個步驟中的第一個。
如果您想要的是圖片的描述而不是其中印有的文字，那就是完全不同的模型和不同的工具。 如果來源是產生而不是掃描的 PDF，則文字已經在檔案中：直接提取它可以保留佈局並且不會丟失任何圖像辨識量都無法匹配。
為什麼它在瀏覽器中運行？
因為人們透過 OCR 發送的圖片是他們最不想上傳的。
收據、銀行信件、處方、護照、身分證、合約照片、私人談話截圖。 通常的選擇是一個網站，它可以拍攝您的圖像，在您一無所知的伺服器上處理它，並保留它保留的任何東西。
這裡的引擎在頁面中運行，在工作者中運行。 圖像被解碼為標籤記憶體，在那裡讀取，然後出現文字。 沒有上傳，沒有隊列，也沒有儲存的副本，在第一次運行之後，整個事情都離線工作。 成本是一次性語言下載，非常大的圖像受標籤可以容納的內容限制。
這個網站還沒有做的兩件事，它們屬於同一管道：拉直照片的頁面並將其裁剪到文字中。 兩者都必須發生在您已經擁有的任何檢視器中，這是上面工作流程中一個尷尬的接縫。 之後的內容被涵蓋：如果來源是幾頁的照片， 組合圖像指南 處理將結果重新組合在一起。
