텍스트 스캔에 대해 모두가 제공하는 조언은 가능한 한 가장 높은 해상도를 사용하고 조명을 올바르게 사용하라는 것입니다. 나는 이 사이트가 사용하는 엔진을 고의적으로 손상된 이미지 세트에 대해 실행하여 그 중 어떤 문제를 찾았는지 알아냈고 그 대답은 둘 다였습니다. 같은 문장이 원래 크기의 1/3에 완벽하게, 회색 배경의 회색 텍스트에서 완벽하게, 그리고 품질 25에서 저장된 jpeg에서 완벽하게 돌아왔습니다. 그것을 망친 것은 페이지를 5도 기울였습니다. 아래의 모든 숫자는 그 실행에서 나왔고 그들은 평소와 다른 체크리스트를 가리킵니다.
TL;DR: Tesseract는 두 가지 특정한 일이 잘못될 때까지 깔끔하게 렌더링된 텍스트를 읽습니다. 기울기가 첫 번째입니다. 0~3도의 왜곡은 0%의 문자 오류율을 제공하고, 5도는 2.9%, 12도는 16.7%, 20도는 32.4%를 제공했습니다. 크기는 두 번째이며 기울기보다는 절벽입니다. 텍스트는 약 7픽셀의 자본 높이까지 완벽하게 유지된 다음 5.8픽셀에서 85.3% 오류로 축소되었습니다. 낮은 대비, 흐림 및 무거운 JPEG 압축이 거의 등록되지 않았습니다. 다른 작업을 수행하기 전에 그림을 똑바로 하십시오. 그만큼 이미지 대 텍스트 변환기 브라우저에서 엔진을 실행하므로 사진이 업로드되지 않습니다.
이 숫자는 어떻게 생성되었습니까?
알려진 문장을 렌더링하고, 한 번에 한 번씩 이미지를 손상시키고, 다시 읽고, 결과를 복구하는 데 필요한 편집을 계산합니다.
메트릭은 문자 오류율입니다. 이미지가 말한 것과 엔진이 반환한 것 사이의 Levenshtein 거리를 진실의 길이로 나눈 값입니다. 50자 줄의 2% 오류율은 하나의 잘못된 문자입니다. 텍스트는 산문, 송장 번호, 날짜, 통화 금액, 이메일 주소 및 전화번호를 혼합한 세 줄이었습니다. 실제로 중요한 실수는 첫 번째가 아닌 두 번째 종류의 콘텐츠에서 발생하기 때문입니다.
한 가지 주의 사항은 묻히지 않고 상단에 있습니다. 사진이 아닌 렌더링된 이미지입니다. 각각의 변수는 하나의 변수를 분리하는데, 이는 원인에 대한 실패를 귀속시킬 수 있는 유일한 방법이지만, 페이지의 실제 사진은 여러 가지와 함께 한 번에 도착합니다. 따라서 아래 임계값이 가장 좋은 경우입니다. 두 축의 한계에 있는 사진은 어느 숫자에서나 암시하는 것보다 더 나쁩니다.
엔진은 Tesseract.js를 통한 Tesseract 4의 LSTM 모델이며, 이는 도구가 실행하는 것과 정확히 일치하므로 다른 시스템의 숫자가 아닙니다.
얼마나 많은 왜곡이 너무 많습니까?
3도에서 5도 사이로, 당신이 눈치채지 못할 정도의 기울기가 있습니다.
| 교전 | 문자 오류율 | 보고된 신뢰 |
|---|---|---|
| 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 |
3도 동안 아무 일도 일어나지 않고 선반에서 떨어집니다. 그 이유는 엔진 작동 방식에 있습니다. 텍스트 줄을 찾은 다음 각 줄을 문자로 분할합니다. 기울어진 선은 여러 행의 픽셀을 가로지르므로 일부 문자의 상단과 다른 문자의 하단을 자르고 모델을 분류해야 합니다.
5도에서 오류는 작고 비쌌습니다. "날짜"는 "DateQ" 및 "Total"로 돌아왔습니다. 둘 다 사람이 똑바로 읽을 수 있는 단어 안에 있는 단일 문자이며 둘 다 사람이 확인하지 않고 복사할 송장 번호와 통화 금액 옆에 있었습니다.
페이지 위에 손으로 들고 있는 전화기는 일상적으로 5도 이상 나옵니다. 이것은 무엇이든 실행하기 전에 수정할 가치가 있는 단일 항목이며 수정은 무료입니다. 선이 수평이 될 때까지 그림을 회전하십시오.
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 |
동일한 세 줄이 원래 크기의 4분의 1에서 완벽하게 읽히며 각 대문자는 각 대문자 높이가 약 7픽셀입니다. 한 단계 더 아래로 내려가면 출력이 사용할 수 없었고 비어 있습니다.
그것은 그라디언트가 아니라 절벽이며 조언을 바꿉니다. "최고의 해상도를 사용하십시오"는 틀리지 않지만 대부분의 사진에는 없는 문제를 설명합니다. 웹 페이지의 스크린샷, 간판 사진, 인쇄된 편지의 전화 사진: 이 모든 것이 7픽셀 이상의 문자 높이를 가지고 있습니다. 그들이 더 자주 가지고 있는 것은 기울기입니다.
절벽이 물고 있는 곳은 멀리서 작물입니다. 휴일 사진의 배경, 거리를 가로 지르는 표지판, 화면 해상도의 전체 페이지 스캔 안에 작은 글씨 라인. 100% 줌에서 글자를 읽기 어렵다면 엔진도 바닥에 가깝습니다.
낮은 대비가 읽기를 망치는가?
아니요, 이것은 내가 예상한 것과 가장 모순되는 결과였습니다.
#BDBDBD에서 회색 배경에 있는 #8a8a8a의 회색 텍스트는 0.0%의 오류율과 95의 신뢰도로 다시 읽습니다. 전체 이미지에 3픽셀 가우스 블러가 0.6%를 제공했습니다. 품질 25에서 저장하고 절반 크기로 확장한 JPEG는 0.0%를 제공했습니다.
그 이유는 엔진이 회색을 읽지 않기 때문입니다. 이미지를 먼저 이진화하여 모든 것을 그림에서 선택한 임계값으로 흑백으로 바꾸고 균일한 낮은 대비가 그 단계에서 손상되지 않고 살아남습니다. 살아남지 못하는 것은 그림자나 전화 플래시가 생성하는 것입니다. 한 임계값은 이미지의 양쪽 절반에 맞을 수 없습니다.
따라서 유용한 버전의 조명 조언은 일반적인 것보다 좁습니다. 조명조차도 중요합니다. 밝은 조명은 그렇지 않습니다. 희미하고 고르게 켜진 페이지 사진은 가운데에 그림자가 있는 밝은 사진을 능가합니다.
2열 레이아웃이 스크램블된 이유는 무엇입니까?
읽기 순서는 레이아웃 판단이고 엔진은 지오메트리에서만 그것을 만들기 때문입니다.
공유 기준선에서 각각 3개의 줄을 나란히 두 개의 텍스트 블록을 렌더링했습니다. 결과는 인터리브로 돌아왔다.
LEFT ONE RIGHT ONE LEFT TWO RIGHT TWO LEFT THREE RIGHT THREE
모든 단어가 맞습니다. 주문은 쓸모가 없습니다. 엔진은 3개의 수직 위치에 있는 6줄의 텍스트를 발견하고 가로질러 각 행을 읽습니다. 이는 테이블에 대한 올바른 동작이고 두 개의 산문 열에 대한 잘못된 하나입니다.
열 사이의 홈통이 넓고 페이지 분할 단계가 감지할 수 있을 만큼 충분히 일관성이 있기 때문에 실제 신문 페이지 또는 학술 PDF는 종종 이를 견뎌냅니다. 이러한 종류의 도구의 일반적인 경우인 두 개의 느슨한 블록이 나란히 있는 레이아웃의 스크린샷은 종종 그렇지 않습니다.
신뢰할 수 있는 수정은 자르는 것입니다. 한 열을 실행하고 결과를 복사한 다음 다른 열을 실행합니다. 힘들게 들리고 약 15초가 걸리며, 이는 문장이 섞인 단락을 재건하는 것보다 적습니다.
그것은 필체를 읽을 수 있습니까?
확실하지 않으며 경계는 글자가 비공식적으로 보이는지 여부보다 닿는지 여부에 관한 것입니다.
나는 혼합 변수가있는 사진을 제공하지 않고 실제 필기를 테스트 할 수 없었으므로 스탠드 인으로 규칙성이 감소하는 세 가지 글꼴을 테스트했습니다.
| 글꼴 | 오류율 | 자신감 |
|---|---|---|
| 코믹 산 MS | 0.0% | 95 |
| 브러시 스크립트 MT | 5.9% | 67 |
| 스넬 라운드핸드 | 20.6% | 55 |
Comic Sans는 비공식적이고 엔진에서 완벽하게 읽을 수 있습니다. 그 문자는 일관된 너비의 별도 모양이기 때문입니다. Snell Roundhand는 연결된 스크립트이며 캐릭터의 5분의 1이 잘못 돌아 왔습니다.
그것이 진정한 차이입니다. Tesseract의 모델은 인쇄된 유형에 대해 교육을 받았으며 선을 개별 글리프로 자르기를 기대합니다. 연결된 쓰기에는 명확한 컷 포인트가 없으므로 인식이 기회를 얻기 전에 세분화가 실패합니다. 진정한 필기체는 Snell Roundhand보다 더 나쁘고 Letter to Letter에도 다르기 때문에 낫지 않습니다.
필기 읽기가 필요한 경우 잘못된 도구이며 다른 모든 Tesseract 프론트 엔드도 마찬가지입니다. 그 직업에는 필기 훈련을 받은 모델이 필요합니다.
어떤 캐릭터가 잘못되었나요?
숫자처럼 보이는 글자와 방향이 일관적입니다.
나는 평범한 용의자의 한 줄을 렌더링하고 그것을 다시 읽었습니다.
truth: O0 l1I 5S 8B 2Z rn/m
read: 00 111 5S 8B 2Z rn/m
자본 O는 0이 되었습니다. 소문자 L과 자본 I은 모두 Digit 1이 되었습니다. 사람들이 가장 걱정하는 쌍은 S에 대해 5, B에 대해 8, M에 대한 RN과 마찬가지로 올바르게 돌아왔습니다.
패턴은 숫자 모양의 글리프가 있는 고립된 문자를 숫자로 읽는 것입니다. 실행에서 산문을 둘러싼 언어 모델이 결과를 단어로 되돌리기 때문에 이것은 거의 중요하지 않습니다. 참조 코드, 일련 번호 또는 라이선스 번호판에는 도움이 되는 주변 단어가 없으며 바로 이러한 종류의 도구가 사용되는 곳입니다.
공백이 없는 문자와 숫자를 혼합하는 모든 문자열을 교정합니다. 엔진이 자신있게 잘못된 출력의 한 클래스입니다.
자신감 점수는 무엇을 말합니까?
페이지가 어떻게 흘러갔는지, 관심 있는 번호가 맞는지 여부가 아닙니다.
이 도구는 엔진의 평균 단어 신뢰도가 높음, 중간 또는 낮음, 85 이상으로 높음으로 표시됩니다. 측정된 오류율에 대해 해당 매핑은 에지에서 광범위하게 합리적이고 낙관적입니다.
| 한 상자 | 자신감 | 라벨 | 실제 오류율 |
|---|---|---|---|
| 깨끗하다 | 95 | 고매한 | 0.0% |
| 5도의 왜곡 | 91 | 고매한 | 2.9% |
| 12도의 왜곡 | 70 | 중위의 | 16.7% |
| 320픽셀 폭 | 41 | 음매하고 울 | 85.3% |
| 연결된 스크립트 | 55 | 음매하고 울 | 20.6% |
낮은 점수는 신뢰할 수 있는 경고입니다. 60점 미만의 점수를 받은 모든 것이 진정으로 깨졌습니다. 높은 점수는 보기보다 약한 증거입니다. 5도 케이스는 91점을 받았는데, 이는 인터페이스가 높게 부르는 인보이스 라인의 단어를 조용히 엉망으로 만드는 동시에 인터페이스가 높다고 부르는 것입니다.
보증이 아닌 화재 경보기로 사용하십시오. low는 출력을 읽는 것을 귀찮게하지 않는다는 것을 의미합니다. 높다는 것은 페이지 전체가 잘 되었다는 것을 의미하며, 이는 모든 캐릭터가 옳은 것과 같지 않습니다.
각 언어를 다운로드하는 데 비용이 얼마나 듭니까?
0.67~2.82MB 사이에서 한 번, 캐시됩니다.
엔진에는 언어별로 훈련된 데이터 파일이 필요합니다. 이 도구는 LSTM 모델만 실행하기 때문에 대부분의 OCR 쓰기 인용 파일보다 훨씬 작은 정합된 최상의 품질 세트를 가져옵니다. CDN에서 측정된 라이브러리는 기본적으로 다음과 같습니다.
| 언어 | 다운로드하다 | 언어 | 다운로드하다 |
|---|---|---|---|
| 영문학의 | 2.82MB | 힌디어 | 1.32MB |
| 러시아의 | 2.56MB | 벵골 사람 | 1.31MB |
| 스페인 사람 | 2.00MB | 한국의 | 1.50MB |
| 일본의 | 1.94MB | 독일의 | 1.27MB |
| 중국어(간체) | 1.64MB | 포르투갈의 | 1.33MB |
| 아라비아 말 | 1.58MB | 이탈리아 사람 | 1.58MB |
| 프랑스인 | 0.67MB |
13개 모두가 함께 약 21MB에 이르며, 이는 현대 전화기에서 찍은 사진 한 장 미만입니다. 중국어 또는 일본어가 엄청나게 되어야 한다는 일반적인 가정은 여기에 포함되지 않습니다. 중국어 간체는 1.64MB로 영어보다 작습니다. 파일이 글리프 라이브러리가 아닌 모델을 저장하기 때문입니다.
첫 번째 실행이 두 번째 실행보다 느린 이유는 무엇입니까?
첫 번째는 엔진을 다운로드하고 시작하고 두 번째는 읽기 때문입니다.
언어의 첫 번째 실행은 Tesseract의 WebAssembly 빌드를 가져오고 해당 언어의 데이터 파일을 가져오고 작업자를 초기화합니다. 그 후 작업자는 페이지에서 살아 있고 데이터 파일은 브라우저에 의해 캐시되므로 동일한 언어의 두 번째 이미지가 즉시 시작됩니다. 언어를 바꾸면 작업자가 다시 시작되지만 이미 가져온 것을 다시 다운로드하지 않습니다.
인식 자체가 빠릅니다. 이 기계에서 3줄 테스트 이미지를 읽는 데는 클린 버전의 경우 186밀리초, 손상된 이미지의 경우 70~125밀리초가 소요되었습니다. 모두 이미 실행 중인 작업자입니다. 전체 페이지의 경우 10분의 1이 아닌 1초 또는 2초가 예상되지만 첫 번째 실행 대기 시간은 읽기가 아니라 설정입니다.
언어가 캐시되면 이 도구는 네트워크 없이 작동하며, 이는 마케팅 라인이 아닌 진정한 오프라인 기능입니다.
OCR을 실행하기 전에 이미지에 대해 무엇을 해야 합니까?
이 순서로 세 가지가 있고 첫 번째는 다른 두 가지를 합친 것보다 더 중요합니다.
- 그것을 곧게 펴십시오. 텍스트의 선이 수평이 될 때까지 회전합니다. 3도는 무료, 5도는 무료입니다.
- 텍스트로 자릅니다. 이렇게 하면 열 문제가 수정되고 세그먼트가 거부해야 하는 배경이 제거되며 텍스트가 프레임의 더 큰 부분을 차지합니다.
- 다른 모든 것을 내버려 두십시오. 날카롭게 하지 말고, 대비를 높이지 말고, 손으로 흑백으로 변환하지 마십시오. 어쨌든 엔진은 바이너리를 만들고 선명하게 필터링하면 이전에는 없었던 문자 가장자리 주위에 울리는 추가 기능이 있습니다.
제거하는 것보다 추가할 가치가 있는 것은 해상도이지만 바닥 근처에 있는 경우에만 가능합니다. 7픽셀 자본 높이에서 14픽셀로 이동하여 측정값이 변경되지 않았습니다. 6에서 7로 모든 것이 바뀌었습니다.
OCR이 잘못된 도구는 언제입니까?
그림이 텍스트가 아닐 때, 텍스트를 손으로 쓴 경우, 원하는 것이 문자 블록이 아닌 검색 가능한 문서일 때.
OCR은 제목이 없고 표 셀이 없고 신뢰할 수 있는 단락 경계가 없고 복잡한 레이아웃에 걸쳐 읽기 순서가 없는 구조가 없는 단어를 제공합니다. 스크린샷의 인용문이나 정확히 맞는 사진의 주소를 보려면. 스캔한 보고서를 편집 가능한 것으로 변환하는 것은 여러 단계 중 첫 번째 단계입니다.
당신이 원하는 것이 인쇄된 단어가 아니라 그림에 대한 설명이라면 완전히 다른 모델과 다른 도구입니다. 그리고 소스가 스캔되지 않고 생성된 PDF인 경우 텍스트가 이미 파일에 있습니다. 직접 가져오면 레이아웃이 유지되고 아무 것도 손실되지 않습니다.
이것이 브라우저에서 실행되는 이유는 무엇입니까?
사람들이 OCR을 통해 넣은 사진은 가장 업로드하고 싶지 않은 사진이기 때문입니다.
영수증, 은행 편지, 처방전, 여권, 신분증, 계약 사진, 사적인 대화의 스크린샷. 일반적인 대안은 이미지를 가져와서 전혀 모르는 서버에서 처리하고 보관하는 모든 것을 유지하는 사이트입니다.
여기에서 엔진은 작업자에서 페이지에서 실행 중인 WebAssembly입니다. 이미지가 탭 메모리로 디코딩되고 거기에서 읽히면 텍스트가 나타납니다. 업로드된 것이 없고 대기열과 저장된 복사본이 없으며 처음 실행한 후에는 전체가 오프라인에서 작동합니다. 비용은 일회성 언어 다운로드이며 매우 큰 이미지는 탭에 담을 수 있는 범위에 의해 제한됩니다.
이 사이트가 아직 하지 않고 동일한 파이프라인에 속하는 두 가지 작업: 사진에 찍힌 페이지를 곧게 펴고 텍스트로 자르는 것입니다. 둘 다 이미 가지고 있는 뷰어에서 발생해야 하며, 이는 위의 워크플로에서 어색한 솔기입니다. 다음 내용이 다룹니다. 출처가 여러 페이지의 사진인 경우, 이미지 결합에 대한 가이드 결과를 다시 합치는 것을 다룬다.
