הטיה שוברת את OCR הרבה לפני שהרזולוציה עושה זאת

העצה שכולם נותנים לגבי סריקת טקסט היא להשתמש ברזולוציה הגבוהה ביותר שאתה יכול ולקבל את התאורה הנכונה. הרצתי את המנוע שהאתר הזה משתמש בו נגד קבוצה של תמונות שנפגעו בכוונה כדי לגלות איזה מהעניינים האלה, והתשובה לא הייתה. אותו משפט חזר בצורה מושלמת מתמונה שליש מהגודל המקורי, בצורה מושלמת מטקסט אפור על רקע אפור, ומושלם מ-JPEG שנשמר באיכות 25. מה שהרס את זה היה הטיית הדף בחמש מעלות. כל מספר למטה יצא מהריצה הזו, והם מצביעים על רשימת בדיקה שונה מהרגיל.

TL;DR: Tesseract קורא טקסט מעובד בצורה נקייה עד ששני דברים ספציפיים משתבשים. הטיה היא הראשונה: 0 עד 3 מעלות של הטיה נתנו שיעור שגיאות של 0% תווים, 5 מעלות נתנו 2.9%, 12 מעלות נתנו 16.7% ו-20 מעלות נתנו 32.4%. הגודל הוא השני, והוא צוק ולא שיפוע: הטקסט נשאר מושלם עד לגובה גדול של כ-7 פיקסלים ואז קרס ל-85.3% שגיאות ב-5.8 פיקסלים. ניגודיות נמוכה, טשטוש ודחיסת JPEG כבדה בקושי נרשמו. יישר את התמונה לפני שאתה עושה משהו אחר. כְּכ ממיר תמונה לטקסט מפעיל את המנוע בדפדפן שלך, כך שהתמונה לעולם לא מועלית.

כיצד הופקו המספרים הללו?

על ידי רינדור משפט ידוע, פגיעה בתמונה לכיוון אחד בכל פעם, קריאתה בחזרה וספירת העריכות הדרושות לתיקון התוצאה.

המדד הוא שיעור שגיאות אופי: מרחק לוונשטאין בין מה שהתמונה אמרה לבין מה שהמנוע החזיר, חלקי אורך האמת. שיעור שגיאה של 2% בשורה של חמישים תווים הוא תו שגוי אחד. הטקסט היה שלוש שורות המשלבות פרוזה, מספר חשבונית, תאריך, סכום מטבע, כתובת מייל ומספר טלפון, כי הטעויות החשובות בפועל קורות בסוג השני של תוכן ולא בראשון.

אזהרה אחת שייכת למעלה ולא קבורה. אלו תמונות מעובדות, לא תמונות. כל אחד מבודד משתנה בודד, שזו הדרך היחידה לייחס כישלון לסיבה, אבל תמונה אמיתית של עמוד מגיעה עם כמה בבת אחת: הטיה קלה, תאורה לא אחידה על פני הקפל, טשטוש תנועה בקצה אחד, ומצלמה שחידדה הכל לפני השמירה. הספים שלהלן הם אפוא המקרים הטובים ביותר. תצלום שנמצא ממש במגבלה על שני צירים יצליח יותר ממה שמציע כל מספר.

המנוע הוא דגם ה-LSTM של Tesseract 4 דרך Tesseract.js, שזה בדיוק מה שהכלי פועל, כך שאלו לא מספרים ממערכת אחרת.

כמה הטיה זה יותר מדי?

בין שלוש לחמש מעלות, שזה פחות הטיה ממה שהיית מבחין.

סִבּ	שיעור שגיאות תווים	דיווח על אמון
0 מעלות	0.0%	95
תואר אחד	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 מעלות השגיאות היו קטנות ויקרות. "תאריך" חזר כ- "Dateq" ו- "סה"כ" כ-"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%. JPEG שנשמר באיכות 25 וגודלו לחצי גודל נתן 0.0%.

הסיבה היא שהמנוע לא קורא את האפורים שלך. הוא מבייש את התמונה תחילה, הופך הכל לשחור ולבן עם סף שנבחר מהתמונה, וניגודיות נמוכה אחידה שורדת את הצעד הזה שלם. מה שלא שורד הוא ניגוד שמשתנה על פני העמוד, וזה מה שיוצר צל או הבזק טלפון: סף אחד לא יכול להתאים לשני חצאי התמונה.

אז הגרסה השימושית של עצות התאורה צרה יותר מהרגיל. אפילו התאורה חשובה. תאורה בהירה לא. תמונה עמומה ומוארת באופן שווה של עמוד מנצחת תמונה בהירה עם צל באמצע.

מדוע פריסה של שתי עמודות יוצאת מקושקשת?

כי סדר קריאה הוא שיפוט פריסה, והמנוע עושה אותו מגיאומטריה בלבד.

ריכנתי שני בלוקים של טקסט זה לצד זה, שלוש שורות כל אחד, על קווי בסיס משותפים. התוצאה חזרה שזור:

LEFT ONE RIGHT ONE LEFT TWO RIGHT TWO LEFT THREE RIGHT THREE

כל מילה נכונה. ההזמנה חסרת תועלת. המנוע מצא שש שורות טקסט יושבות בשלושה מיקומים אנכיים וקורא כל שורה לרוחבה, שזו ההתנהגות הנכונה לטבלה והשגויה עבור שתי עמודות פרוזה.

דף עיתון אמיתי או PDF אקדמי שורדים את זה לעתים קרובות, מכיוון שהמרזב בין העמודות רחב ועקבי מספיק כדי ששלב פילוח העמודים יזהה. צילום מסך של פריסה עם שני בלוקים רופפים זה ליד זה, וזה המקרה הנפוץ לכלי מסוג זה, לרוב לא.

התיקון האמין הוא לחתוך. הפעל עמודה אחת, העתק את התוצאה ולאחר מכן הפעל את השנייה. זה נשמע עמל ולוקח כחמש עשרה שניות, שזה פחות מבנייה מחדש של פסקה שמשפטיה נדבו.

זה יכול לקרוא כתב יד?

לא אמין, והגבול הוא אם האותיות נוגעות ולא אם הן נראות לא רשמיות.

לא יכולתי לבדוק כתב יד אמיתי בלי לספק תמונה, שיהיו לו משתנים מעורבים, אז בדקתי שלושה גופנים של סדירות פוחתת כסטנד-אין:

פונט	שֶׁפ	ביטחון
קומיקס ללא 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 ו-Capiti שניהם הפכו לספרה 1. הזוגות שאנשים דואגים להם הכי הרבה, 5 נגד S ו-8 נגד B, חזרו נכון, וכך גם RN נגד m.

התבנית היא שאות מבודדת עם גליף בצורת ספרה נקראת כספרה. בהפעלת פרוזה זה רק לעתים רחוקות חשוב, כי מודל השפה סביבו מושך את התוצאה בחזרה למילה. בקוד ייחוס, מספר סידורי או לוחית רישיון, אין מילה מסביב לעזור, ושם בדיוק נעשה שימוש בכלי מסוג זה.

הגהה כל מחרוזת המשלבת אותיות וספרות ללא רווחים. זהו סוג הפלט האחד שבו המנוע טועה בביטחון.

מה אומר לך ציון הביטחון?

איך הלך הדף בערך, ולא אם המספר שאכפת לך ממנו נכון.

הכלי מראה את ביטחון המילים הממוצע של המנוע כגבוה, בינוני או נמוך, עם גבוה ב-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 מגה-בייט

כל השלושה עשר ביחד מגיעים לכ-21 מגה-ביט, שזה פחות מתצלום אחד מטלפון מודרני. ההנחה המקובלת שסינית או יפנית חייבת להיות עצומה לא מתקיימת כאן: סינית פשוטה היא 1.64 מגה-בייט, קטנה מאנגלית, מכיוון שהקובץ מאחסן דגם ולא ספריית גליפים.

מדוע הריצה הראשונה איטית יותר מהשנייה?

כי הראשון מוריד והתנעה של מנוע, והשני הוא רק קריאה.

ההרצה הראשונה של שפה מביאה את המבנה של WebAssembly של Tesseract, מביאה את קובץ הנתונים של השפה הזו ומאתחלת עובד. לאחר מכן העובד נשאר בחיים בדף וקובץ הנתונים נשמר במטמון על ידי הדפדפן, כך שתמונה שנייה באותה שפה מתחילה מיד. החלפת שפות מאתחלת מחדש את העובד אך אינה מורידה מחדש שום דבר שכבר הובא.

ההכרה עצמה מהירה. במכונה זו, קריאת תמונת שלוש השורות ארכה 186 מילישניות עבור הגרסה הנקייה ובין 70 ל-125 מילישניות עבור הפגומים, הכל על עובד שכבר פועל. עבור עמוד שלם של טקסט צפו לשנייה או שתיים ולא לעשירית אחת, אבל ההמתנה הראשונה שתבחין בה היא הגדרה, לא קריאה.

ברגע ששפה נשמרת במטמון הכלי עובד ללא רשת כלל, שהיא יכולת לא מקוונת אמיתית ולא קו שיווקי.

מה עליך לעשות לתמונה לפני הפעלת OCR?

שלושה דברים, בסדר הזה, והראשון חשוב יותר מהשניים האחרים ביחד.

1. ליישר אותו. סובב עד ששורות הטקסט יהיו ברמה. שלוש מעלות זה בחינם, חמש לא.
2. חתוך לטקסט. זה מתקן את בעיית העמודות, מסיר רקע שהסלח צריך לדחות, והופך את הטקסט לחלק גדול יותר של המסגרת.
3. תעזוב את כל השאר בשקט. אין לחדד, לא להעלות את הניגוד, אין להמיר לשחור ולבן ביד. המנוע ממילא בינארי, ומסנן חידוד מוסיף צלצול סביב קצוות האותיות שלא היו שם קודם.

הדבר ששווה להוסיף במקום להסיר הוא רזולוציה, אבל רק אם אתה ליד הרצפה. מעבר מגובה הון של 7 פיקסלים ל-14 פיקסלים לא שינה דבר במידות. מעבר מ-6 ל-7 שינה הכל.

מתי OCR הוא הכלי הלא נכון?

כאשר התמונה אינה של טקסט, כאשר הטקסט כתוב בכתב יד, וכאשר הדבר שאתה רוצה הוא מסמך שניתן לחיפוש ולא בלוק של תווים.

OCR נותן לך את המילים ללא מבנה: ללא כותרות, ללא תאי טבלה, ללא גבולות פסקה שאתה יכול לסמוך עליו, ללא סדר קריאה על פני פריסה מורכבת. לציטוט מתוך צילום מסך או כתובת מחוץ לתמונה שמתאימה בדיוק. להמרת דוח סרוק למשהו שניתן לעריכה הוא הראשון מבין כמה שלבים.

אם מה שאתה רוצה זה תיאור של תמונה ולא של המילים המודפסות בה, זה דגם אחר לגמרי וכלי אחר. ואם המקור הוא PDF שנוצר במקום נסרק, הטקסט כבר נמצא בקובץ: משיכתו החוצה שומרת ישירות על הפריסה ולא מאבדת דבר, ששום כמות של זיהוי תמונה לא יכולה להשתוות אליו.

למה זה פועל בדפדפן?

מכיוון שהתמונות שאנשים הכניסו דרך OCR הן התמונות שהם הכי פחות רוצים להעלות.

קבלות, מכתבי בנק, מרשמים, דרכונים, תעודות זהות, תמונה של חוזה, צילום מסך של שיחה פרטית. האלטרנטיבה הרגילה היא אתר שלוקח את התמונה שלך, מעבד אותה בשרת שאתה לא יודע עליו כלום ושומר על כל מה שהוא שומר.

כאן המנוע פועל בדף, ב-A Worker. התמונה מפוענחת לזיכרון הכרטיסיות, נקראה שם והטקסט מופיע. שום דבר לא מועלה, אין תור ואין עותק מאוחסן, ואחרי הריצה הראשונה כל העניין עובד במצב לא מקוון. העלויות הן הורדת השפה החד-פעמית ושתמונות גדולות מאוד מוגבלות על ידי מה שהכרטיסייה יכולה להכיל.

שני דברים שהאתר הזה עדיין לא עושה, וששייך לאותו צינור: יישור דף מצולם וחיתוך הטקסט. שניהם צריכים לקרות בכל צופה שכבר יש לך, שהוא התפר המביך היחיד בזרימת העבודה שלמעלה. מה שבא אחרי מכוסה: אם המקור הוא תמונה של מספר עמודים, המדריך לשילוב תמונות עוסק בהרכבת התוצאות.