자동차번호판 인식기술은 이미 많은 곳에서 활성화되고 검증 받은 OCR기술 중에 하나입니다.
주차관리 와 과속단속 등 많은 곳에서 이미 사용되고 있습니다.
위와 같은 자동차번호판 인식 기술은 인식 폼이 정해진 OCR기술 중의 하나로, 주민등록증 OCR인식 기술과 유사한 성격을 가지고 있습니다.
하지만, 비정형 폼에서 어떤곳에서 어떤 형태로 나타나는 자동자번호판 인식 기술은 주차관제시스템에서 사용하는 OCR기술과는 다른 성격입니다. 즉, 주차용 자동차번호판 인식기술은 OCR엔진에서 얼마나 정확히 글자를 판독할 수 있느냐 여부가 관건이라면, 자동차 과태료 용지에 나타나는 자동차번호판은 읽어온 글자를 정합성을 검증해야 하는 데이터 분석기술이 주된 역할입니다.
▲ 자동차 번호판 인식 OCR 기술의 종류
구분 |
정형 자동차번호판 OCR인식 |
비정형 자동차번호판 OCR인식 |
비고 |
주요 사용처 |
주차관제, 과속 위반차량, 주정차위반 차량 단속 등 |
과태료 위반고지서, 자동차등록증 원부 등 |
|
정형여부 |
정형화된 형태 |
비정형 형태(텍스트 위주, 이미지도 있음) |
|
OCR 기술 |
OCR 문자인식 기술이 중요 |
OCR 엔진 보다는 데이터 분석기술이 중요 과제임 |
|
시장형태 |
활성화(경쟁상태임) |
비활성화(초기단계) |
▲ 자동차 번호판 인식 OCR 기술중 비정형 인식의 난이도
즉, OCR+에서는 정형화된 자동차번호판 인식기술이 아닌, 비정형이며 데이터화된 텍스트 중에서 정확한 자동차번호판을 텍스트로 추출하는 작업입니다.
상식적인 수준에서 생각해보면, 주차관제시스템과 같은 OCR기술이 완벽한 현재, 비정형 데이터 중에 자동차 번호판을 골라내는 것은 아주 쉬운 일이라고 생각할 수 있습니다.
그러나, 비정형 데이터 중에서 자동차번호판을 추출하는 것은 매우 어려운 일입니다.
왜냐하면, 자동차번호판이 “123허1234”와 같은 구조로 되어 있으나, 실제 비정형 테이터에서는 중간 한글이 “영어” 또는 “슷자”로 판독되기 때문입니다.
* 참고, 2024년 현재 자동차번호판에서 사용중인 중간한글은 35개 입니다
(가,거,고,구,나,너,노,누,다,더,도,두,라,러,로,루,마,머,모,무,버,보,부,서,소,수,어,오,우,저,조,주,하,허,호)
또한, 자동차번호판에서 직접 읽어오는 방식이 아니라, 인쇄된 종이에서 읽기 때문에 그 글씨 크기도 작고, 다른 글씨와 섞어서 인쇄되기도 하며, 고지서 발급자가 황당한 띄어쓰기를 해서 다른 숫자와 혼동되는 등 OCR엔진에서 잘못 읽어올 가능성이 많이 내재하고 있습니다.
▲ OCR 엔진의 종류 및 한글 OCR기술
과거의 OCR엔진은 주로 구글OCR, 어도비OCR, Abbyy사의 레티아엔진 등이 쓸만한 OCR엔진이었습니다.
이런 엔진들은 개발단계부터 영어위주로 되어 있기 때문에 자동차번호판의 “123허1234”에 있는 중간한글을 영어 또는 숫자로 치환하는 오류가 많이 발생했습니다.
하지만, 2020년 이후로 네이버 클로바 OCR은 한글인식에 획기적인 성능을 보여주고 있습니다.
마치 네이버 파파고 한국어 번역이 구글 트랜스레이트 보다 뛰어난 성능을 보여주는 것과 맥락을 같이 한다고 할 수 있습니다.
한글은 전 세계관점에서 보면 아주 외딴섬 글자 입니다. 시장규모도 비교적 작은 편이고요.
세계의 다수 국가에서는 로마자 (영어, 불어, 독어, 러시아어 등)를 사용하기 때문입니다.
한글 처리를 완벽하게 하기 위해서는 한국어 문장처리도 어느 정도 진행되어야 합니다.
단순히 글자 인식기술은 약간이라도 흐릿한 글자인 경우 문맥을 파악하지 않으면 멍청한 결과를 보여주기 때문입니다.
다행이 외딴섬인 한글과 한국어 기술을 네이버에서 진화시킨 덕택에 자동차번호판의 “123허1234”를 중간한글을 쓸만한 상태로 읽어낼 수 있습니다.
만약 네이버에서 한글인식 기술을 향상시키지 않았다면 자동차과태료 OCR기술은 “자동차번호판” 추출도 아주 어려운 과제 입니다.
네이버 클로버 OCR엔진 덕택에 자동차번호판 추출이 쉬워 졌다고는 하지만, 상대적으로 쉽다는 이야기 입니다.
절대적 관점에서는 매우 어려운 과제 입니다. 아래의 사례를 보면서 왜 자동차번호판 추출이 어려운 과제인지를 알아 보도록 하겠습니다.
사례 1 |
차동차번호 패턴이 위치한 곳이 3개 이나, |
||
이미지 |
|
||
추출텍스트 |
|
||
OCR+결과 |
추출 텍스트가 최소 자동차번호 패턴에 일치하지 않아서 추출하지 못함 (OCR + 운영결과 약 5천건 중 1건에 해당하는 지극히 저빈도 사례임) |
► 참고(아래 도표) - 1차 추출 가능한 자동차번호 패턴
1차 자동차 번호 추출 |
패턴 및 설명 |
1순위 - 중간한글(자동차번호 중간한글과 달라도 |
(^|\s|:)(\d{2,3}[가-힣]{1}\d{4})(?=\s|$) 2또는3자리 숫자 + 한글 1자리 + 4자리 숫자 (중간 공백인 경우를 포함) |
2순위 - 1순위 검색결과 검색 개수가 0인 경우에는 |
(^|\s)(\d{2,3}([a-zA-Z]{1,2}|\s+)\d{4})(?=\s|$) 2또는3자리 숫자 + 영어알파벳 1자리 또는 2자리 + 4자리 숫자 |
3순위 - 1, 2순위에 일치하지 않는 경우, |
별도의 펑션으로 운영 |
사례 2 |
차동차번호 패턴이 위치한 곳이 3개 이나, |
||
이미지 |
|
||
추출텍스트 |
없음 |
||
OCR+결과 |
추출 텍스트가 최소 자동차번호 패턴에 일치하지 않아서 추출하지 못함 (서울시 강서구청만 유일하게 자동차 번호를 납부자이름과 같이 병행해서 적고 있기 때문에 나타나는 오류임) |
사례 3 |
차동차번호 패턴이 위치한 곳이 2개 이나, |
||
이미지 |
|
||
추출텍스트 |
|
||
OCR+결과 |
추출 텍스트가 최소 자동차번호 패턴에 일치하지 않아서 추출하지 못함 (만약 이런 건이 자주 발생한다면 userDB에 [대괄호] 패턴을 등록하면 정상적으로 추출 가능하나, 실무자들의 의견은 서울 중구청 장애인 관련 과태료만 이런 이상한 방식을 사용하기 때문에 수작업 조치 하는 쪽으로 의견일치를 봄) |
위의 3가지 단편적인 사례를 보더라도, 일견 단순한 자동차번호 추출 작업이 아니라는 것을 알수 있습니다.
때문에 OCR+에서는 자동차번호 추출을 위한 로직을 다음과 같이 하고 있습니다.
1. 자동차과태료 인덱스 + 자동차번호 패턴로직
2. 복수의 자동차번호 추출건 상호간 우선순위 비교 로직
3. 기존 등록된 DB와 비교 검증
1번 항목은 불필요한 항목을 배제하기 위함입니다.
OCR+에서는 비정형 데이터 중에서 자동자번호 패턴 로직만 사용하게 될 경우에는 불필요한 패턴이 다수 생성됩니다.
이러한 불필요한 데이터를 줄이기 위해서 “차량번호, 부과대상”이라는 인덱스가 있는지 여부를 동시에 검색합니다.
단, 패턴 검색에서 검색 결과가 없는 경우에 한해서 사용중입니다.
2번 항목은 매우 유용한 자동차번호 추출 로직입니다.
OCR엔진에서 추출한 자동차번호는 보통 3개에서 ~ 5개 정도입니다.
위에 사례에서 살펴본 것처럼(또는 전자납부번호 오류 사례와 같은 이유) OCR엔진은 오류 판독의 가능성을 가지고 있습니다.
아무리 훌륭한 네이버 크로바 OCR엔진이라고 하더라도 OCR엔진의 기본적인 한계입니다.
그래서 다수의 추출된 자동차번호를 비교해서, 그 우선순위를 정하고 우선순위에 맞는 자료를 사용자에게 보여줍니다.
이 로직을 통해 완벽하지 않은 검증인 경우 파란색으로, 검증자체가 성립하지 않은 경우 빨간색으로 표시된 자동차 번호를 OCR+ 추출해 사용자의 판단을 도와 줍니다.
▲ 자동차 번호판 인식 OCR 추출 우선순위
1. 유형을 3가지로 분류한다. - 번호판 중간한글이 모두 같은 경우 - 번호판 중간한글이 모두 표준글자인 경우 - 번호판 길이가 모두 7자리인 경우(또는 8자리인 경우) |
2. 총 8개의 케이스로 구분한다(이너 케이스는 별도로직 적용한다) - 케이스 1 : 어레이 카운트도 1인 경우(딕셔널리 카운트는 배제 함) : 파란색으로 함 - 케이스 2 : 어레이 카운트도 복수이면서, 딕셔널리 키가 1인 경우 - 케이스 3 : 어레이 카운트가 복수이면서, 딕셔널리 키도 복수인 경우 케이스 3의 이너 케이스 1 : 복수 후보인 경우 1순위 : dict value가 1보다 크면서, max인 것 케이스 3의 이너 케이스 2 : 2순위는 dict value가 모두 1인 경우는 len이 8자리 인것 - 케이스 4 : 딕셔너리 밸류가 1보다 크면서, 동시에 max값인 경우 : 까만색 - 케이스 5 : 딕셔너리 벨류가 모든 딕셔너리 키 값이 동일한 경우 : 이너 케이스로 분리함 - 케이스 6 : 번호판 중간 한글 검증해서, 모두 같은 경우 (즉, 한글은 같지만 앞 뒷 숫자 또는 자릿수가 다른 경우) 케이스 6의 이너 케이스 1: 랭쓰가 같은 경우 : 먼저나온것을 선택 : 빨간색 케이스 6의 이너 케이스 2 - 랭쓰가 다른 경우 : 8자리 중 먼저나온 것을 선택 : 파란색 - 케이스 7 : 중간 한글이 다른 경우 케이스 7의 이너 케이스 1 : 매치 건이 1건만 있는 경우 : 빨간색 케이스 7의 이너 케이스 2 : 매치 건이 2건 이상인 경우 : 케이스 7의 이너 케이스 2의 이너 케이스 1 : 랭쓰가 같은 경우 : 먼저나온것을 선택 : 빨간색 케이스 7의 이너 케이스 2의 이너 케이스 2 : 랭쓰가 다른 경우 : 8자리 중 먼저나온 것을 선택 : 빨간색 케이스 7의 이너 케이스 3: 매치 건이 없는 경우 : 먼저나온 데이터 선택: 빨간색 - 케이스 8 : 결과값이 없는 경우에 적용되는 로직 |
간단하게 이야기 하자면, 복수로 추출된 데이터 셋을 상호간에 비교해서 동일한 건수가 많은 것을 우선순위로 하는 로직입니다,
단, 이곳에 확정된 로직, 번호판 중간 한글 유무 등을 비교해서 확정된 로직이 우선순위를 확보하게 된다는 의미입니다.
일견 간단해 보이는 자동차번호판 추출 로직도 실제 구현하자고 하면 꽤 많은 경우의 수가 나타납니다.
추출하는 방식부터, 패턴을 정하고, 인덱스를 부여해도 OCR엔진의 한계로 인해서 위와 같이 매우 복잡한 로직을 정하지 않고, 단순히 OCR에서 읽어준 데이터를 뿌려준다면 실제 업무에 사용하기 힘든 자료가 될 수 밖에 없습니다.
위와 같은 패턴이나 로직은 1백건, 2백건의 문제가 아니라 무수한 데이터와 실무자와 소통을 기반으로 하고 있습니다.
단순한 프로그램가 만든 프로그램인 경우 그 한계를 나타내는 지표이기도 합니다.
3번 항목은 1번과 2번 항목에서 나올 수 있는 가능성을 0%로 만들기 위해서 사용합니다.
즉, 현재 캐피탈(또는 리스사)에서 소유하고 있는 차량번호를 DB화 하고, 그 DB와 비교해서 최종 오류여부를 판별합니다.
만약 소유하고 있는 차량번호 DB가 없다면, 지금까지 추출한 자동차 차량번호를 DB화 하는 과정을 별도로 만들어 줍니다.
이상으로 비정형 자동차과태료 용지에서 자동차번호를 추출하는 과정을 최대한 간단하게 설명하고자 했습니다.
▲ 자동차 번호판 인식 OCR 기술이 중요성
실제로 자동차번호 추출은 자동차과태료에서 추출하는 데이터 중 중하 정도 난이도 입니다.
실제 더 어려운 로직이 있는 곳은 사고일시, 사고장소, 과태료 추출입니다.
하지만, 그 중요도는 최상이기 때문에 단 0.001%의 오류도 없는 클린한 데이터를 생성하기 위해서 OCR+는 정교한 로직을 사용하고 있습니다.
감사합니다.