以下、本発明に係る車両ナンバー情報読取システムの一実施形態について、駐車場に設置された車両ナンバー情報読取システムに適用し、図面に基づいて説明する。尚、以下に示す実施形態は、本発明の好適な具体例であり、技術的に好ましい種々の限定を付している場合もあるが、本発明の技術範囲は、特に本発明を限定する記載がない限りこれらの態様に限定されるものではない。
図1は本発明の一実施形態に係る車両ナンバー情報読取システムにおけるシステム構成の説明図である。
図1において、MPは実際に車両を駐車するための駐車スペースである。この駐車スペースMPの付近には、第1入場レーン10aと第2入場レーン10b、第1出場レーン20aと第2出場レーン20b、各入場レーン10a,10bの車両進行方向前後及び各出場レーン20a,20bの車両進行方向前後に配置された第1ループ11aと第2ループ11b、各入場レーン10a,10b及び各出場レーン20a,20bを区画するように配置されたメインアイランド12aとセンターアイランド12bとサイドアイランド12c、とを備えている。
各アイランド12a,12b,12cには、各入場レーン10a,10b及び各出場レーン20a,20bを挟むように互いに対向するもの同士で対として車両の出入りを検出するための発光トリガーセンサー13又は受光トリガーセンサー14が設けられている。また、各入場レーン10a,10bのメインアイランド12aとセンターアイランド12bとには、発券機15、通信ライン16、ゲートバー18を備えたゲート装置17、撮像装置19、が設けられている。さらに、各出場レーン20a,20bのメインアイランド12aとセンターアイランド12bとには、通信ライン16、ゲートバー18を備えたゲート装置17、撮像装置19、出口精算機22、が設けられている。
また、図1において、21は出口精算機とは別に事前に清算処理を行うことができる事前精算機、23は事前精算機21用の通信ライン、24はイーサネット(登録商標)、50a及び50bは車両である。さらに、図1において、30は駐車場管理室である。
駐車場管理室30は、サーバー31、管理端末としてのパーソナルコンピュータ(PC)等の演算処理装置(以後、単に「管理PC」と称する。)32、データベース(DB)33、とを備えている。
データベース33は、契約車データベース(DB)33a、在車データベース(DB)33b、画像データベース(DB)33c、テンプレート文字データベース(DB)33d、を備えている。
発光トリガーセンサー13から赤外線ビームが各受光トリガーセンサー14に向けて照射され、この間への車両50a又は車両50bの進入によって赤外線ビームが遮光されるとトリガーオン(ON)となる。
この際、各入場レーン10a,10bにおいては、車両50a又は車両50bの金属部分が第1ループ11aに検知されて車両有りと判断された場合のみ、トリガーオンと判断されるようにAND構成を採用しており、人や小動物の通過によってトリガーオンとはならないようになっている。
各撮像装置19は、通信ライン16を介して発券機15又は出口精算機22と接続されている。また、発券機15と出口精算機22とは同一アイランド12a,12bのゲート装置17と接続されている。さらに、撮像装置19は、イーサネット(登録商標)24を通じて他の撮像装置19や管理PC32とLAN(Local Area Network)接続されている。
駐車場スペースMPの一角に設置された事前精算機21は、管理PC32と通信ライン23で接続され、各出場レーン20a,20bから離れた場所(例えば、ビル等の出入り口付近や駐車エリアMPの一角等に設置し、事前に清算することで清算後の所定時間内(例えば、5分)であれば出口精算機22での清算を不要とするものである。従って、この事前精算機22の設置場所は限定されるものではない。
尚、第1,第2出場レーン20a,20bは、第1,第2入場レーン10a,10bの車両進行方向を反転させた構成になっているため、その詳細な構造の説明は省略する。
図2は上述した撮像装置19の構成を示したものである。撮像装置19は、中央演算処理部(CPU)34、メモリー35、外部入力部36、外部通信部37、LANボード38、カメラ39、キャプチャーボード40、フラッシュ41、インターフェイス42、を備え、バス43を介して相互接続されている。また、撮像装置19は、各入場レーン10a,10b及び各出場レーン20a,20bの何れに設置されたものでも同じ構成であるが、個々の装置IDやLAN接続のためのIPアドレス等を異ならせることによって撮像装置19の特定を行うことができる。従って、入出場処理のプログラム自体は後述するように各入場レーン10a,10bと出場レーン20a,20bとでは若干異なる仕組みに成っている。
通常、発光トリガーセンサー13は、常に赤外線ビームを照射しており、受光トリガーセンサー14が物体によって遮蔽されることで撮像装置19にトリガー信号が入力され、フラッシュ41を焚きカメラ39で撮像する。その際に周辺の光量を計測する光センサー等(図示せず)を用いてフラッシュ41を制御するか、カメラ39のレンズ部にオートアイリス機構を仕組んでもよい。
本実施の形態においては、撮像した画像はカメラ39からキャプチャーボード40で静止画像化され、予めプログラムされたアプリケーションソフトウエアがCPU34上で動作し、車両50a又は車両50bのナンバープレートの抽出及びナンバー情報の二値化や画像圧縮データの生成などを行い、これをメモリー35に保存する。
第1,第2入場レーン10a,10bの撮像装置19の例では、メモリー35には契約車の画像圧縮データが多数保存されている。実施例ではデータ保存はメモリー35としたが、HDD(ハードディスク)やコンパクトフラッシュ(登録商標)などの記憶デバイスを用いてもよい。また、アプリケーションソフトウエアのプログラムなどは予めメモリー35の一部に書き換え不可能に保存されている。パターンマッチング処理は、予めプログラムされたアプリケーションソフトウエアがCPU34上で動作し、撮像画像から生成した画像圧縮データとメモリー35上に保存された画像圧縮データを比較して処理を行う。また、ナンバープレート抽出、二値化、画像圧縮データの生成、さらにパターンマッチング処理などの一連の動作を専用の画像ボードを設けて行うことも可能である。
具体的には、図1で例示した構成の駐車場の場合、入場時に撮像したナンバープレートの画像データを過去の撮像プレート画像データとしてメモリー35に記憶し、出場時に撮像したナンバープレートの画像データを直近の撮像プレート画像データとし、これら新旧の撮像プレート画像データを比較する。
尚、過去の撮像プレート画像データとしては、契約車両の駐車と一時利用車両の駐車とが混在する有料駐車場等の場合には、契約車両のナンバープレートの画像データを過去の撮像プレート画像データとしてメモリー35に記憶し、駐車場への入場時に撮像したナンバープレートの画像データを直近の撮像プレート画像データとして契約車か否かを判定する際に用いる場合等もある。
ここで、パターンマッチング処理とOCR処理とでは、利点と欠点(得意と不得意)がある。即ち、パターンマッチング処理では、ノーマッチング(合致しない)の原因(パターンマッチング処理の弱点)として、入場時と出場時に車両進入角度(姿勢)が、例えば反対方向に異なる方向に曲がりながらレーンに進入した車両の画像のパターンマッチング処理はノーマッチングになりやすい。
このことは、比較するナンバープレートの画像同士の歪みの方向が異なることにより、各々のナンバープレートの文字の形が異なるためにノーマッチングとなりやすい。これに対してOCR処理では、文字1つ1つを読み取ってテキストに置き換えているため、入場時と出場時に逆方向に歪んだナンバープレートの画像を撮像した場合でも、それらの画像同士を比較する訳ではないのでナンバープレートの文字は正常に認識できる。
OCR処理の弱点は、ナンバープレートの文字がかすれていたり、汚れている場合に文字と認識できないか、最も似ている他のテキストを当てはめてしまうため、誤認識が生じることもあるが、パターンマッチング処理では入場時と出場時の画像同士を直接比較するために、ナンバープレートの文字のかすれや汚れも含めて同一の車両かどうかが判断され、誤認識が生じ難いとされている。
パターンマッチング処理は処理速度が速く、出場レーン20a,20bでのパターンマッチング処理では入場台数分のデータからベストマッチング(一番マッチングスコアが高い=合致点数が高い)を選択すればよいから、対象数は在車数に限られ処理対象数が少ない。また、入場レーン10a,10bでは対象数は定期契約車に限られる。これに対してOCR処理では、常に全ての文字の可能性を考慮して一文字づつ認識処理するため、処理全体に時間がかかる。入場レーン10a,10bや出場レーン20a,20bの撮像装置19側でパターンマッチング処理とOCR処理の両方を実行すると全体の処理に時間がかかり、それをカバーするためにCPU34のクロック周波数の速いものを採用したり、内部のメモリー35の容量をアップさせなければならず、装置のコストアップとなる。
図3を基にパターンマッチング処理を説明する。
例えば、図3(イ)に示すように、入場時(又は出場時)の車両進行方向が右折状態である場合、車両50のナンバープレート51は左に曲がった姿勢で入場することとなる。従って、その際のナンバープレート51の画像も図3(イ)に示すように曲がって撮像される。
これに対し、図3(ロ)に示すように、入場時(又は出場時)の車両進行方向が略直進状態である場合、ナンバープレート51は直進(平面)姿勢で入場することとなる。従って、その際のナンバープレート51の画像も図3(ロ)に示すように撮像される。
一方、図3(ハ)に示すように、出場時(又は入場時)の車両進行方向が左折状態ある場合、ナンバープレート51は右に曲がった姿勢で出場することとなる。従って、その際のナンバープレート51の画像も図3(ハ)に示すように曲がって撮像される。
パターンマッチング処理を概念的に言うと、画像圧縮データ同士を重ね合わせて、その一致する部分の多さで点数をつけ、それが予め設定した閾値以上であれば「マッチング」とし、閾値以下であれば「ノーマッチング」となり、これを撮像したものと保存してあるものとで総当たり処理して、「マッチング」のなかの「ベストマッチング」を選択する。
ここで、入場時と出場時とのナンバープレート51の関係が、図3(イ)と図3(ロ)又は、図3(ロ)と図3(ハ)というように、一方のみがずれた状態であれば比較的高いスコアでマッチングするが、図3(イ)と図3(ハ)とのように、互いに逆方向にずれた場合には比較的低いスコアとなり、場合によっては「ノーマッチング」となってしまうことがある。
この際、この状態であっても常に「マッチング」するように閾値を下げたり、アルゴリズムを変更すると、本当に異なるナンバープレート同士を「マッチング」と見なしてしまう「ミスマッチング」が生じる危険性がある。
このように、車両の姿勢の食い違いにより画像の歪み方向が大きく異なるナンバープレート画像同士では比較的スコアが低く「ノーマッチング」と判定されることがあるが、仮に、OCR処理する場合では図3(イ)、図3(ロ)、図3(ハ)において全て正常にナンバー情報を認識し、例えば、テキストデータ「名古屋400わ0444」を処理結果として得ることができる(尚、この「名古屋400わ0444」のナンバー情報を有する車両は、一連番号の1桁目に「0」は採用されないため実在しない)。
次に、図4のフロー図を参照してOCR処理の説明をする。
このOCR処理を概念的に説明すると、画像に含まれる文字部と予め設定された形態(フォント)の文字との「テンプレートマッチング処理」を行うものである。
まず、図4の(1)でナンバーを抽出し(パターンマッチング処理で抽出された画像を使用する)、(2)ナンバーの文字部だけを抽出し(同様にパターンマッチング処理の前処理で抽出済み)、(3)でそれらを要素別に分け(後述する図11でも説明している)、(4)で文字のDBに保管してある様々な文字のデータと比較して1文字づつ「総当たり」で当てはめ、(5)でその結果をテキストデータとして出力する。また(5’)として、その際に各要素の合致度、確からしさを採点しており、その最高点の文字を割り当てている。
OCR処理は対象となる文字のデータ数が多いと処理時間が長くかかるため、駐車場の入出場レーンで採用するには、高速の処理が必要でありCPUのクロック周波数の速いものが必要で、それを多数の処理装置に設置するとコストが増大する。そこで、管理PC32のように他に高速の処理を司る用途のためにハイスペックなPCがある場合は、そこでOCR処理を行わせることで、CPUの高速化のコストアップが全体のコストに影響され難くすることも可能である。
ただし、OCR処理を行うための画像を送信するのにも時聞がかかるため、複数のレーンの画像を一箇所で集中的にOCR処理し、その結果を入出場レーン側に返すといったシステムだけで駐車場の入出場を管理するには、画像送信と結果の返信に常に数秒の時間を待たねばならず、これだけでの運用は現実的でない(常にレスポンスが遅い)。
そこで、上述したパターンマッチング処理とOCR処理の利点と欠点に鑑みて、本発明の実施例による車両ナンバー情報読取システムでは、図5から図11に示すような処理を実行する。
図5は車両入場時における発券機15の動作フローを示し、ステップS1で第1ループ11aがオンかオフかを判断し、オンであればステップS2に進みトリガー受付許可信号を(A)に示すそのレーンに設置された撮像装置19へ送信する。
また、ステップS3でパターンマッチング処理結果を含む駐車データを(B)に示す撮像装置19から受信し、ステップS4でパターンマッチング処理結果を判断し、ノーマッチングであればステップS5に進み、(B’)に示す撮像装置19からOCR処理結果がNO(合致無し)を受信した場合、ステップS6へと移行して案内放送を開始する。
さらに、ステップS7で発券機15の発券釦を押下すると、ステップS8で駐車券が発行され、ステップS9で駐車券もしくは定期券が抜き取られたか否かを判断し、抜き取られたらステップS10でゲートバー18が開く。
また、ステップS11で車両50a又は車両50bが第2ループ11bを通過したか否かを判断し、通過していればステップS12でゲートバー18が閉じ、ステップS13で入場時刻、券No等の駐車データを更新すると共に、トリガー受付禁止指令を(C)に示す撮像装置19へと送信する。
また、ステップS7で発券機15の発券釦が押下されなければ、ステップS14に進み定期券が挿入されたか否かを判断し、挿入されればステップS9に進み、挿入されなければステップS7で待機をし続ける。
この様に、入場レーン10a又は入場レーン10bでは、契約車に対しては通常はパターンマッチング処理結果が「マッチング」となってゲート開信号が出力され、一般車に対してはパターンマッチング処理結果が「ノーマッチング」となって、発券釦が押下された場合に駐車券が発行され、駐車券を抜き取るとゲート開信号が出力され、夫々第2ループ11bを通過するとゲートが閉じ、その後駐車データに入場時刻、券No等が付加されたデータとトリガー受付禁止信号が撮像装置19へと送信される。
図6は車両入場時の撮像装置19の動作フローを示し、ステップS21でトリガー入力がオンかオフかを判断し、オフであればステップS22で(A)に示すようにそのレーンに設置された発券機15からトリガー受付許可信号を受信するが、受信されない場合はステップS21のトリガー入力判断を繰り返す。
また、ステップ21でトリガー入力がオンの場合はステップS23でトリガー受付許可か禁止かを判断し、許可状態の場合はステップS24で適宜にフラッシュ発光撮像すると共に画像キャプチャーを実行し、ステップS25でナンバープレート抽出処理を行い、ステップS26で(D)に示すようにナンバー位置情報を含む駐車データと画像を管理PC32へ送信する。
さらに、ステップS27で画像圧縮データを生成し、ステップS28でパターンマッチング処理を実行した後、ステップS29でパターンマッチング処理結果を判断し、ステップS30で(B)に示すようにパターンマッチング処理結果を含む駐車データを発券機15へ送信する。
ここで、そのまま待機している状態で車両50a又は車両50bが駐車スペースMP内に入場するとステップS31に進み、(C)に示すように発券機15から入場時刻や券ナンバーなどを含む更新された駐車データ及びトリガー受付禁止指令を受信し、ステップS32で(E)に示すように駐車データと画像圧縮データを管理PC32へ送信する。
一方、ステップS29でノーマッチングだった場合には、ステップS33へと移行し、(E)に示すように管理PC32からOCR処理結果を受信したか否かを判断し、受信していればステップS34でOCR処理結果を含む駐車データを発券機15へ送信する。
図7は車両入場時における管理PC32の動作フローであって、ステップS41で(D)に示すように撮像装置19からナンバー位置情報を含む駐車データ及び画像を受信し、ステップS42でOCR処理を実行する。
また、ステップS43で契約車DB33aの検索を行った後、ステップS44で該当車が有るか無いかを判断し、該当車が無ければステップS45でOCR処理で得られたナンバープレート情報のみをデータにセットしてステップS46で(E)に示すようにOCR処理結果として撮像装置19へ送信した後に、ステップS47で画像を画像DB33cに保存する。
さらに、ステップS48で(F)に示すように撮像装置19から駐車データと画像圧縮データを受信し、ステップS49で在車情報を在庫DB33bに保存する。
また、ステップS50で車両50a又は車両50bが契約車か否かを判断し、契約車でなければステップS53で蓄積台数が有るか否かを判断し、蓄積台数が有ればステップS51へと移行する。また、契約車でない場合にはステップS54でタイムアウトか否かを判断し、タイムアウトであればステップS51に進み蓄積台数やタイムアウトの初期化を行い、ステップS52で(F’)に示すように駐車データと画像圧縮データを各出口の撮像装置19へ送信する。
ステップS44で該当車があればステップS55に進みOCR処理で得られたナンバープレート情報と契約車DBから抽出した情報をデータにセットして、ステップS46に進む。また、ステップS50で契約車であればステップS51へ進む。
このように、契約車以外の情報の場合には、予め設定した台数若しくは時間が経過するまでは駐車場データと画像圧縮データを配信せず、例えば、一般車が10台連続して入場したら、10台分まとめて駐車場データと画像圧縮データを各出場レーンの撮像装置19へ配信するようになっており、入場の度にデータを複数の出口レーンの撮像装置19へ返信する場合に比較して、LANのトラフィックを混雑させるのを極力避けることができると共に、時間のかかる画像の送受信を少しでも速く実行するように工夫されている。
図8は車両出場時における出口精算機22の動作フローを示し、ステップS61でそのレーンの第1ループ11aがオンであるかオフであるかを調べ、第1ループ11aがオンであればステップS62でトリガー受付許可指令を(G)に示すそのレーンに設置された撮像装置19に送信する。
また、ステップS63でパターンマッチング処理結果を含む駐車データを(H)に示すように受信した後に、ステップS64でパターンマッチング処理結果を調べる。
ここで、ノーマッチングであればステップS65に進み、(H')に示す撮像装置19からOCR処理結果がNO(合致無し)を受信した場合には、ステップS66へ進み案内放送を開始し、ステップS67で駐車券が挿入されたか否かを判断し、挿入されていればステップS68で料金が発生したか否かを判断し、料金が発生していればステップS69に進み料金精算処理を実行する。
また、ステップS70で出口のゲートバー18が開き、次にステップS71で第2ループ11bを車両50a又は車両50bが通過したか否かを調べ、通過していればステップS72でゲートバー18が閉じ、ステップS73で出場時刻などの駐車データを更新し、(J)に示すようにトリガー受付禁止指令を撮像装置19へ送信する。
一方、ステップS67で駐車券が挿入されなければ、ステップS74で定期券が挿入されたか否かを判断し、定期券が挿入されていなければステップS67に戻り、挿入されていればステップS75に進む。
また、ステップS64でマッチングしていればステップS68に進み、ノーマッチングであってもステップS65で(H')に示す撮像装置19からのOCR処理結果が合致しているか否かを調べ、合致していればステップS68に進む。
図9は車両出場時における撮像装置19の動作フローを示し、ステップS81でトリガー入力がオンであるかオフであるかを判断し、オフであればステップS82で(G)に示すそのレーンに設置された出口精算機22から受付許可指令を受信するが、受信されない場合はステップS81のトリガー入力判断を繰り返す。
また、ステップS81でトリガー入力がオンした場合はステップS83でトリガー受付許可か禁止かを判断し、許可状態の場合はステップS84で適宜にフラッシュ発光撮像すると共に画像キャプチャーを実行し、ステップS85でナンバープレート抽出処理を行う。 さらに、ステップS86で、ナンバー位置情報を含む駐車データと画像を(K)に示す管理PC32に送信した後、ステップS87で画像圧縮データを生成し、ステップS88でパターンマッチング処理を行う。
また、ステップS89でパターンマッチング処理結果がどうかを判断し、ステップS90でパターンマッチング処理結果を含む駐車データを(H)に示す出口精算機22へ送信する。
ここで、そのまま待機しているうちに車両50a又は車両50bが駐車スペースMPから出場すると、ステップS91に進み、出場時刻や券Noなどの更新された駐車データ及びトリガー受付禁止指令を(J)に示す出口精算機22から受信し、ステップS92で契約車か否かを判断する。
ここで、契約車でなければステップS93で駐車データと画像圧縮データを削除し、ステップS94で駐車データ削除指示を(M)に示す各出場レーンの撮像装置19と管理PC32へ送信する。
一方、ステップS89でノーマッチングだった場合には、ステップS95に進み(L)に示す管理PC32からOCR処理結果を受信したか否かを調べ、ステップS96でOCR処理結果を含む駐車データを(H')に示す出口精算機22へ送信する。
また、ステップS92で契約車であれば、ステップS97で駐車データを(N)に示す各入場レーンの撮像装置19へ送信すると共に、ステップS93に戻る。
さらに、ステップS83でトリガー受付禁止の場合には、ステップS98で配信受付処理を行った後にステップS81に戻る。
図10は出場時における管理PC32の動作フローであって、ステップS101で(K)に示す撮像装置19からナンバープレート位置情報と画像を受信し、ステップS102でOCR処理を行う。
また、ステップS103で在車DB33bのデータを検索し、ステップS104で該当車が有るか否かを判断する。該当車がなければ、ステップS105でOCR処理結果のみをデータにセットして、ステップS106でOCR処理結果として(L)に示す撮像装置19へ送信する。
さらに、ステップS107で画像を画像DB33cに保存した後に、ステップS108で(M)に示す撮像装置19から、駐車データと画像圧縮データを削除する旨の指示指令を受信し、ステップS109で在車DB33bから駐車データを削除する。
一方、ステップS104で該当車があれば、ステップS110に進み、OCR処理で得られたナンバー情報と在車DBから抽出した情報をデータにセットして、ステップS106に進む。
この際、パターンマッチング処理でノーマッチングの場合でも、正常にナンバープレートが撮像されて、OCR処理結果から在車情報を検索して該当するものが見つかれば「マッチング」(=合致するものがある)と同様に扱う。また、各レーン10a,10b,20a,20bの撮像装置19でパターンマッチング処理をするのと同時に画像をLANで管理PC32に送信する。
パターンマッチング処理を撮像装置19で実行している時には内部CPUがフル稼働しているが、画像送信などの通信処理は専用のLANボード38(若しくは単にLAN専用回路)が司るため、並列処理で画像を送信してもパターンマッチング処理が遅くはならない。
OCR処理はCPUにかかる負荷が大きいため、ハイスペックなCPUを搭載した管理PC32に画像を送信してそれを基にOCR処理させ、結果だけを撮像装置19に返信させる。
この際、撮像装置19は管理PC32に画像を送信する際に、画像の中に含まれるナンバープレートの位置データを付加して送信する。
管理PC32は、ナンバープレート位置情報を含む画像エリアだけ、ナンバープレート画像抽出とOCR処理することで、OCR処理の時聞を短くできる。
図11はOCR処理の動作フローであって、ステップS111で一連番号を抽出し、ステップS112ではその一連番号の位置から他の各文字や番号の領域を算出し、ステップS113でまず一連番号の数字を認識してその結果は図示しないがメモリーに保管しておき、ステップS114では車種番号を認識して同様にその結果をメモリーに保管しておき、ステップS115では陸運支局名を認識するが、その際には文字DB33d内の陸運支局名DBにある陸運支局名のテンプレートとの比較を行なって、最もスコアの高い陸運支局名をOCR処理結果としてメモリーに保管する。
尚、文字認識時のスコアとは、各テンプレート(陸運支局名として登録された文字の文字形状)との比較を行い、合致する度合いが高いものに高いスコアをつけ、合致度が低いほど低いスコアとし、最も合致度が高いテンプレートの文字(支局名)をOCR認識結果として採用する。
ただし、実際のOCR処理には誤認識を防止するために他の特徴による判定手法なども同時に採用しており、単なる絵合わせだけではないが、簡単なため、ここでは単にテンプレートに絵合わせを行なって、最も絵の輪郭のズレが少ないものに高スコアをつけるものとする。
実施例では、完全に合致した場合にはスコアが100点とし、低スコアの閾値を50点とする。また、20点以下の場合には「該当なし」や「認識不可」として、あえて低いスコアの文字を認識結果として採用しないこととしている。
また、前述の一連番号と車種番号の認識についても同様に、数字の文字形状に対しての絵合わせによって最も高いスコアの数字を認識結果として採用するものであるが、数字の場合には陸運支局毎の文字形状の差異が無く、後からの書き換えの必要が無いため、0〜9までの10種類の数字の文字形状のテンプレートデータは文字DBではなく、OCR処理プログラムの中に持たせている。
次のステップS116では、まずパターンマッチング処理の段階におけるマッチングスコアが予め設定した閾値以上かどうかを判定する。この場合のマッチングスコアは、入場レーンでの一般車であれば、ほとんど低スコアであり、ノーマッチとなっているもので、パターンマッチングによる判定の閾値と同じスコアを設定してもよい。
よって、ノーマッチの場合のナンバーのOCRにおいては、ステップS116ではマッチングスコア閾値以上でNOとなり、ステップS117へと移行する。
ステップS117では、用途名の認識を行なうが、前述の陸運支局名と同様に、文字DB33d内の仮名文字DBにある仮名文字のテンプレートとの比較を行なって、最もスコアの高い仮名文字をOCR処理結果としてメモリーに保管する。ただし、この場合の仮名文字DBにおいて認識処理に比較対照として参照する仮名文字のテンプレートは、前述のステップS115の陸運支局名認識でOCR処理結果としてメモリーに保管された陸運支局名毎に異なるテンプレートとなっており、その中から最もスコアの高い仮名文字をOCR処理結果としてメモリーに保管する。次のステップS118でも、まずパターンマッチング処理の段階におけるマッチングスコアが予め設定した閾値以上かどうかを判定し、パターンマッチング処理でノーマッチの場合にはステップS118ではマッチングスコア閾値以上でNOとなり、次のステップS119に進み、メモリーに保管してある各文字のOCR処理結果を出力し(ナンバー全体のOCR処理結果として次の処理に使用できる状態とする)、RETURNで元の処理に戻る。
前述のステップS116でマッチングスコアが閾値以上だった場合には、YESとなりステップS120に移行して陸運支局名のOCRスコアが閾値以下かどうかを判定し、閾値以上であればステップS117に移行するが、<閾値以下?>がYESだった場合にはステップS121に移行してその際の陸運支局名を抽出した文字画像と、認識結果(OCRスコア)を文字DB33d内の陸運支局名低スコア文字DBに保存してからステップS117に移行する。
また、前述のステップS118でマッチングスコアが閾値以上だった場合には、YESとなりステップS122に移行して用途名(仮名)のOCRスコアが閾値以下かどうかを判定し、閾値以上であればステップS119に移行するが、閾値以下だった場合にはステップS123に移行してその際の用途名を抽出した文字画像と、認識結果(OCRスコア)、ならびにその際の陸運支局名のOCR処理結果を文字DB33d内の仮名低スコア文字DBに保存してからステップS119に移行する。
図12は本発明の実施例による車両ナンバー情報読取システムにおける駐車データの内容を示す図である。前述のマッチングスコアやOCR処理結果は駐車データに含まれて、その後の在車管理や出庫履歴管理に活用されることになる。また、OCR処理結果は例えば一般車として駐車券を取って入場した車両のドライバーが、駐車券を紛失してしまった場合など、ドライバーが車両のナンバーを申告することですぐさま該当する車両の在車管理データより入場時刻が判明し、駐車券の再発行なども確実に行なえる。
また、OCR処理結果から駐車場施設利用者の陸運支局名の統計を採り、どの地域からの来場者が多いかなどが解析できれば顧客ニーズにあったサービスの展開も可能となる。
さらに、一連番号データの末尾が偶数か奇数かによって入場を制限するような利用形態も可能である。
また、ブラックリストや盗難車等のナンバー情報を登録して通報することも容易となり、この様に単に入場・退場時の車両判定を正確に行うためにはパターンマッチング処理だけでも問題ないが、OCR処理には他の使い勝手があるためにどちらも精度良く認識することができるのが好ましい。
図13は本発明の実施例の低レベル合致度文字閲覧手段を示し、図13の上段は用途名(仮名)低スコアリスト表示状態のモニタ正面図、図13の下段は陸運支局名低スコアリスト表示状態のモニタ正面図である。
これらの表示画面は管理PC32のディスプレイに表示させたもので、通常の管理PC画面(図示せず)から係員操作によって遷移してこの図に示した画面61に移行される。
画面61には、その全体にリスト表示部62が設定されているが、操作の便宜性の確保のために下部にファンクション表示部63が設けられている。
このファンクション表示部63は、図示しないキーボード装置のファンクションキー(F1〜F12)に割り当てられた操作内容を表示する。また、リストの選択は図示しないマウスなどのポインティングデバイスを使用したり、図示しないキーボード装置のカーソルキー(←↓→↑)で移動させて選択することができる。
用途名低スコアの例では、OCR認識した仮名名の順で、OCRスコアの高い順にソートして表示されており、その際の陸運支局名も示されている。画面右側には、OCR処理の際に使用された画像と、その際にテンプレートとして使用された画像も同時に比較閲覧可能となっている。このリストでは仮名の画像とテンプレートを比較して、あきらかに異なる文字形状が見つかった場合には、ファンクションキーで「登録」を押下し、該当するテンプレートを変えることもできる。
また、その際に一度の登録で切替えるのではなく、複数の画像を登録し、別途それらを輪郭・位置・角度補正等をおこなったうえで、それら複数の画像データを平均化するなどの適正な画像処理を施してから、テンプレートを入れ替えるのも良い。
このように、仮名名が陸運支局毎に表示されているのは、文字DB内で陸運支局名毎に使用されている仮名が保存されているからであるが、全ての陸運支局名で全ての仮名が整理されていない場合には、複数の陸運支局で共通の仮名を採用するようなデータテーブルが別途用いられている。陸運支局名の低スコアリストも同様に、陸運支局毎にOCRスコアの高い順にソートして表示されており、画面右側には、OCR処理の際に使用された画像と、その際にテンプレートとして使用された画像も同時に比較閲覧可能となっている。同様にこのリストでは陸運支局名の画像とテンプレートを比較して、あきらかに異なる文字形状が見つかった場合には、ファンクションキーで「登録」を押下し、該当するテンプレートを変えることもできる。その際に一度の登録で切替えるのではなく、複数の画像を登録し、別途それらを平均化するなどの適正化処理を施してから、テンプレートを入れ替えるのも良い。図の例ではご当地ナンバーとして新規採用された「富士山」で、テンプレートと実際の画像の差異が多数リストアップされており、これらを「登録」していくことで、陸運支局名のOCRスコアが向上し、全体的にOCR処理結果が向上することで、ナンバー情報の認識精度が改良されていく。
なお、本発明の実施例で説明した駐車場システムにおいては、パターンマッチング方式とOCR方式を撮像装置19と管理PC32とで別個に処理しているが、これらをすべて管理PC32で行うか、逆に全て撮像装置内でおこなうことも、本発明の請求の範囲に含まれる。さらに、複数の駐車場において、OCR登録されたテンプレートデータを共有し、遠隔地でのDB間で共同して精度の向上を図ることも有効であり、本発明の応用の範囲といえる。
加えて、本発明の実施形態は実施例で説明した様な入口出口の車路において撮像するシステムの駐車場に留まらず、車両を駐車エリア毎に管理して駐車料金精算前の車両を駐車エリアから退出不可状態に拘束する装置を備えたフラップ式駐車場にも使用可能であり、その場合には撮像装置を駐車エリア周辺に個々の駐車エリア毎に設置したり、複数の駐車エリアをまとめて撮像したり、さらに撮像装置のカメラ部が複数の駐車エリアを巡回しながら監視する様な形態であっても、本発明で述べたナンバー情報認識の技術を採用するも可能である。