世界最高性能を誇る画像処理ライブラリHALCONが、国内の市場において高い評価を受けているのには決定的に優れた機能があるためです。その決定的な優位性を具体事例を含めて、多様化する画像処理のニーズにHALCONがいかに柔軟なソリューションを提供するかを紹介します。
まず最初にHALCONの特長機能として紹介したいのが、画像処理アプリケーションの統合開発環境HDevelopです。通常の場合、画像処理ライブラリを購入するとVisual Studioなどの環境にて、C、C++、VBといった言語で関数をコールして開発することになります。それに対して、HALCONの開発環境であるHDevelopは、特定の関数を選択すると対応したパラメータ設定画面が表示され、設定が完了するとプログラムウインドウに追加されていきます。画像処理の検証には、利用するアルゴリズム、関数の順序、パラメータの調整といった試行錯誤を繰り返し行いますが、その際に中間の画像や領域、XLD(Extended Line Description)データといった情報を参照しながら、ステップ実行しながら対話形式でプログラムを作成することが可能です。
また、HALCONには1400を超える優れた関数群が提供されており、ひとつのタスクであっても様々なアプローチで検証することができます。これらの関数群と、HDevelopの開発環境を組み合わせることで、各画像処理課題に対して数時間の作業で実現の可否を判断することが可能です。
さらに、標準で800種類を超えるサンプルプログラムおよび画像が提供されているため、スクラッチから開発するのではなく、これらのサンプルをベースに開発することで効率を上げることができます。1400の関数すべてに対して日本語のオンラインドキュメントが用意されていて、各関数が内部的にどのような計算を行っているかを参照できるように完備されています。
パターンマッチング技術は、画像処理ライブラリの最も重要な機能のひとつと言えます。対象物のパターン(形状)を事前にモデル登録し、その形状を検査画像からサーチするということが目的ですが、そこには多くの技術的課題が存在します。
同一の照明条件において、回転・スケール変化がない対象物をサーチする場合、どんな画像処理ライブラリであってもある程度の精度・速度・ロバスト性を実現します。ただし、これらの条件が少しでも崩れると、その結果はライブラリによって大きく変動します。例えば、回転が入っただけで検索時間が2倍以上に膨れ上がったり、照明環境が変化したり遮蔽が起こると、パターンを見つけられないということもありえます。
例えば右図に示すように、コルクの断片をコルクの板の上に置き、そのコルク断片を移動させながらサーチしたとします。背景がコルクであるため、画像全体に渡って非常に多くのエッジが発生し、さらに対象物のコルクが回転するためサーチには多くの時間を要することが予想されます。しかしHALCONの場合は、内部の特殊な最適化手法により、VGA(640×480)画像において10ms以下の速度を実現します。
上記のようなパターンマッチングの精度・速度・ロバスト性といった観点では、実際に対象とされている画像に対して評価を実施すれば、HALCONの優位性を明確に理解していただけます。ここでは、パターンマッチングに求められる追加機能について紹介します。
【1】 「パラメータ自動計算」
パターンマッチングには条件に応じていくつかのパラメータ設定が必要となります。これらのパラメータが最適に設定されないと、マッチング結果に大きく影響してきます。HALCONでは対象物の形状、検索画像のコントラストおよびノイズレベルなどを考慮して、パターンマッチングで必要とされるパラメータの一切をすべて自動計算してくれる"auto"パラメータ機能を搭載しています。これにより、現場のオペレータがマッチングに関する経験を持たなくとも、簡単にパターン登録・サーチが実現できます。
【2】. 「人工モデル」
パターンマッチングにおいて形状を登録する際、対象物を撮像した画像から形状を取得するケースが一般的です。しかし、対象物によっては照明の反射によって実際の形状とは異なる不必要なエッジまでモデル登録され、その結果としてマッチングのスコア(マッチング率)が低く判定されてしまうことがあります。その影響で、サーチができない、位置精度が低下するといった問題が起こりえます。この問題に対して、HALCONは人工的に作成した画像からモデルを生成する機能を用意しており、事前に対象物の形状を把握している場合は、その形状を任意に作成することで理想的なモデルを登録することができます。
右図では、画像から生成したモデル(左上)と人工モデル(右上)を示しています。画像から生成したモデルは個体特有のノイズや形状パターン以外の情報も含んでしまっていますが、人工モデルを利用することによりロバストなパターンマッチングを実現していることがわかります(下)。
さらにHALCON 8.0以降、CADデータからダイレクトにパターンマッチング用のモデルを生成できるようになりました。つまり、事前に電子部品などのCADデータを準備できれば、上記のような人工画像の作成すら必要なくなります。
右図では、CADデータから生成した3種類のモデル(上)、その3つのモデルを利用した複数モデルマッチング(※1)を実現していることを示しています。
(※1)HALCONでは複数のパターンを登録し、異なるパターン同士の重なりなどの関係を考慮して、複数のモデルパターンを同時にサーチすることが可能です。
【
3】 「カラーマッチング」
近年のカラーカメラの普及により、カラー画像に対してパターンマッチングを行いたいという要求が増えてきました。通常はRGBの各画像に個別にマッチングをかける必要がありましたが、HALCONではRGB画像に存在するすべてのエッジに対してマッチングをかけることができます。
【4】 「縦・横スケーリング」
パターンマッチングのスケーリングは360度全体に対して一律にしか設定できないことが多いです。正方形をモデル登録すると正方形のまま膨張収縮するものしか見つけられず、例えば横方向だけに膨らんだ長方形を見つけることは難しいです。HALCONでは、スケーリングの設定を縦方向、横方向に個別に指定することができるため、対象物の変動に柔軟に対応できます。右図では1つのモデルから、縦方向、横方向に大きさが変動する対象物を全て検出しています。

HALCONではサブピクセル精度の計測を、柔軟かつ簡易に実現する方法を提供しています。それはXLD(eXtended Line Description)というデータ形式によって実現されます。XLDデータは、サブピクセルの各位置座標をグループ化した、点列データの集合体として表されます。
HALCONでは、すべてのピクセルに対してサブピクセル用の座標軸を持つため、各ピクセルごとのサブピクセル精度を持った点を集合体にしたものがXLDとなります(右図)。
例えば右図(左)に示すように、画面に黒く写っている対象物の境界の曲率を求めたいというタスクがあるとします。まず、HALCONの「edges_subpix」という関数を用いると、この場合はコントラストが明確に出ているためXLDオブジェクトが1つの集合体として抽出できます。次にこれを、円弧成分が異なるもの同士に分割します。円弧成分が異なるということは分割点において曲率が大きく変化することを意味しますので、「segment_contours_xld」という関数を用いて、曲率を指定することで1つにまとまっていたXLDオブジェクトを各円弧成分に分割することができます。最後に、「fit_circle_contours_xld」という関数を用いてXLDを円近似すれば、高精度に各円弧成分の曲率を求めることができます。
ここで注目したいのは、このような2次元平面における複雑な計測処理も、たった3個の関数コールで柔軟に実現できるという点です。その他にも、領域データでは一般的なブロブ解析などの便利な機能が、サブピクセル精度のXLDデータにも適応できる関数が用意されています。
■ edges_subpix: 画像上のエッジをXLDとして抽出する
■ segment_contours_xld: XLDを直線成分と円弧成分に分割する
■ fit_circle_contour_xld: XLDを円近似する
■ select_shape_xld: XLDのブロブ解析を行う
■ union_straight_contours_xld など: XLD同士を結合する
金属やガラス表面におけるキズ検査や文字認識などでは、反射や輝度ムラにより通常の2値化ではうまく処理が実現できない場合が多くあります。このような場合HALCONでは、まず対象画像を平滑化することでベースのコントラストを算出します。そこからオフセットを設定することで、興味の対象である領域のみを抽出することができます(右図)。画像の各要所においてダイナミックに閾値を設定するということから、この特殊な2値化手法を『動的しきい値法』と呼んでいます。
例えば下図のように、金属表面のキズを抽出したいというタスクがあるとします。原画像(左)に対し、通常の2値化では輝度ムラも発生しているため、キズの領域を抽出することができませんい(中央左)。これに対して、動的閾値法を用いると、画像全体に対して均等にセグメンテーションを実現できます(中央右)。あとは、モフォロジーやブロブ解析を行うことで、キズの領域だけを抽出することが可能です(右)。

ここで、ユーザーによる適用事例を紹介します。
通常、球面上にあるキズを検出しようとすると、搬送系の位置決めも考慮して照明を均等に当てることが困難です。そのため、球面の外側までキズとして検出されてしまいます。しかしHALCONの動的しきい値法を用いると、うまくキズの部分だけを欠陥として抽出できます(右図)。
HALCONの特出した機能の1つとして、解析範囲の絞込みが挙げられます。解析範囲を絞り込むことで、パターンマッチング、フィルタ、エッジ抽出などの後処理を限定的な範囲に対してのみ行えます。これにより高速化が図れるだけでなく、複雑な処理を極めて簡易化することもできます。
矩形で解析範囲を絞り込むことは当然ながら、HALCONの大きな特長は、前処理で得られた領域を利用して解析範囲を絞り込むことができる点にあります。
例を挙げると、2値化して得られた領域に対し、各種モフォロジー、ブロブ解析を行った結果、興味の対象となる範囲を領域オブジェクトとして限定したとします。その領域オブジェクトに解析範囲を絞り込むことで、後処理を数段に簡易化することが可能となります。
例えば、右図の画像のように、ワイヤーボンディング後、金属ワイヤーが正しくICチップ上のパッドとリードフレーム端子を接続しているかどうかの検証をしたいという事例があります。この事例における課題として、金属ワイヤーの背景が位置によって変化するため、金属ワイヤーと背景とのコントラストが位置によって大きく変化することが挙げられます。
また
このような課題に対してHALCONを使った場合の処理手順を紹介します。
(i) 通常の2値化を用いて大まかにICチップを含む明領域を抽出します。
(ii) 形状特徴量解析(ブロブ解析)や各種領域処理を用いてICチップの部分だけの領域を抽出します。
(iii) Aで得られたICチップの領域の位置・傾きから、相対的に、ICチップ上のボンディングのボールはんだ部分、リードフレーム端子上のボールはんだ部分をそれぞれ含んだ領域を生成します。

(iv) ここでHALCONの特長機能である解析範囲の絞込みを、Bで求めた領域に適応することでボールはんだが並んだ周辺領域のみの画像を得ることができます。
(v) Cで得られた画像に対して、ボールはんだ部分のみを、2値化処理および形状特徴量解析(ブロブ解析)によって抽出します。これにより、ワイヤー両端のはんだ位置の座標を大まかに取得することができます。
(vi)
次に、このワイヤー両端のはんだ位置から、ワイヤーが配置されているであろう範囲を想定して、人工的に矩形領域を作成します。ワイヤーボンダー設計者であれば、どの範囲にワイヤーがおさまるべきかは既知の情報です。
(F)
Eで生成した矩形領域を1つずつ選択し、その矩形領域に対して解析範囲を絞り込みます。右図では左側の一番上の矩形領域での処理を表示しています。
@で直線的なエッジの抽出を行います。
Aにてワイヤーを形成するXLDのみを、XLDデータの形状特徴量解析により選出し、背景の影響でワイヤーのエッジが断片的に抽出されてしまっている部分を結合して1つのエッジとします。
Bにて、Aで抽出されたワイヤーのエッジにスムージング処理を施すことにより、ばらつきのある結合部分を含めて、最終的に柔軟にワイヤーのみのエッジを検出することができます。
(G)
Fの処理を繰り返すことで、
以上のように、(i)から(G)の処理により、一見すると不可能に思われる、複雑な背景のある中で、ボンディングされた金属ワイヤーのみを抽出することが可能となります。ワイヤーを正しく抽出できて初めて、屈曲率の計算や折れなどの検査を実現できます。
バリエーションモデル(分散モデル)は、印刷検査やフレキシブル基板などのいわゆるシートものの検査などに広く活用されている機能です。文字の印刷や回路パターンの短絡・ショートを検出する際、良品サンプルとの画像差分では判断が厳しくなり過ぎてしまいます。それを、ある程度の許容を持たせるために良品画像を複数トレーニングすることで、分散モデルを作成することができます。また、複数枚のトレーニング用良品画像を用意できない場合でも分散モデルを1枚の画像から取得できるようになっています。さらに、特にラインセンサーによる画像サイズの増大によるメモリ消費量の問題に対して、トレーニングが終了したら使用したトレーニング画像を開放する、などメモリ管理を中心とした配慮も実装されています。バリエーションモデル作成から、検査までの手順を以下に示します。
バリエーションモデル生成の流れ
例えば、右図のように、“MVTec”というロゴが印刷されており、印刷のかすれや印刷ずれがないかどうかの品質検査を行うというタスクがあるとします。上に示したバリエーションモデルの生成手順のAあるいはBのどちらかの方法で良品として許容する範囲を考慮して、バリエーションモデルを作成します。
良品として判断できる"幅"を考慮したバリエーションモデルを生成した結果が右図です。バリエーションモデルを利用することで、印刷のかすれや印刷ずれが良品の許容範囲を超えた場合のみ、欠陥部分として検出することができます。

右図は、実際にバリエーションモデルによる品質検査を行った結果であり、左側が
欠陥部分の検出に関して、右図のように、バリエーションモデルに対して明るい欠陥
近年、画像処理に求められる精度がますます高まってきており、より高解像度な画像をより速く処理することが必要となってきています。例えばラインセンサーカメラを用いて取得した大容量の画像を処理するには、十分なメモリ確保が必要となります。しかしながら、Windows 32bitではアプリケーション当たり2GBまでしかメモリ確保をできないという制約が出てきます。ただし、HALCONは既に古くから64bit OSに対応しており、Windows XP 64bitやWindows Vista 64bitなどで利用可能であるため、まったく問題ありません。
また、CPUのマルチコア化が進み、画像処理アプリケーションにおいても、複数の処理を各プロセッサに有効に分割した並列処理を行うことで、たとえ大容量の画像であっても処理の高速化を図ることが可能です。マルチコアCPUへの対応においても、HALCONは早期に実現しており、2001年初頭にリリースされたHALCON6.0から対応しています。このことからもHALCONの開発元であるMVTec社の先見性を伺い知れます。
並列処理といっても手法によりレベルが異なり、HALCONのリエントラントな関数を用いて、ユーザーが独自に並列処理を作成するプログラムレベルとHALCONが自動的に各プロセッサへと処理を分担するオペレーターレベルがあります(下図)。
この機能はHALCON 6.0での対応から最新バージョンHALCON 8.0のリリースまでに、既に多くの改善・改良が行われてきました。バージョンアップのたびに、並列処理による高速化・効率化を向上させるため、処理の並列化を行うことによるオーバーヘッドの削減や、オペレータ毎に効果的な並列化がなされるような最適化が適用されています。特に顕著に更新されたHALCON 8.0では、適用するかどうかも選択可能なスレッドプールを利用した最適化、依存性の減少、同期のためのオーバーヘッドの大幅な削減などを実現しました。これにより、コア数が増えてオーバーヘッドが多くなることで逆に処理時間がかかっていたような場合や、あまり大きな効果を得られなかった小さな画像を扱う場合においても、並列処理が有効となりました。
右図に、HALCONの関数の1つである画像の加算を行うオペレーター“add_image”を1000×1000の画像にオペレーターレベルでの並列処理を適用した結果を示します。ここでは、HALCON 7.1とHALCON 8.0との比較を行っています。HALCON 7.1 では、“add_image”のような高速オペレーターは並列処理アーキテクチャを利用しても恩恵を得られなかったのですが、HALCON 8.0ではコア数が増えるにつれて高速化を実現しています。その他にも、例えばCPU × 2 の環境下で評価した結果、“sobel_amp”で約5倍、“threshold”で約1.5倍、“gauss_image”で約2倍の速度向上を実現しています。
形状特徴量解析(ブロブ解析)のために、HALCONは豊富な形状特徴パラメータと高速な解析処理を提供しています。画像処理では、例えば2値化処理を行った後に領域の形状特徴量を利用することがよくあります。単純な矩形や円形だけでなく様々な形状の領域が抽出されている中で、目的とする特定の領域(Region)を選出したいとします。そのような場合に対して、HALCONでは60以上の形状特徴量を基準として領域の抽出・利用が可能です。HALCONが提供するRegion(領域)と、XLD(サブピクセル点列データ)に関する形状特徴量の一覧をそれぞれ以下に示します。
|
特徴量 |
内容 |
|
'area' |
領域の面積(画素数) |
|
'row' |
中心の行座標(インデックス) |
|
'column' |
中心の列座標(インデックス) |
|
'width' |
領域の幅 |
|
'height' |
領域の高さ |
|
'row1' |
領域の左上コーナの行座標(インデックス) |
|
'column1' |
領域の左上コーナの列座標(インデックス) |
|
'row2' |
領域の右下コーナの行座標(インデックス) |
|
'column2' |
領域の右下コーナの列座標(インデックス) |
|
'circularity' |
真円度 |
|
'compactness' |
コンパクト性 |
|
'contlength' |
XLDの長さ |
|
'convexity' |
凸面度 |
|
'rectangularity' |
矩形度 |
|
'ra' |
等価楕円の長軸半径 |
|
'rb' |
等価楕円の短軸半径 |
|
'phi' |
等価楕円の方向 |
|
'anisometry' |
Anisometry |
|
'bulkiness' |
Bulkiness |
|
'struct_factor' |
StructureFactor |
|
'outer_radius' |
領域を囲む最も小さい円の半径 |
|
'inner_radius' |
領域内に含まれる最も大きい円の半径 |
|
'inner_width' |
領域にフィットする、軸に平行な最大矩形の幅 |
|
'inner_height' |
領域にフィットする、軸に平行な最大矩形の高さ |
|
'dist_mean' |
中心から領域境界までの平均距離 |
|
'dist_deviation' |
中心から領域境界までの距離の偏差 |
|
'roundness' |
丸み |
|
'num_sides' |
多角形の辺数 |
|
'connect_num' |
連結要素の数 |
|
'holes_num' |
ホールの数 |
|
'max_diameter' |
領域間の最大距離 |
|
'orientation' |
領域の方向 |
|
'euler_number' |
オイラー数 |
|
'rect2_phi' |
領域を囲む最も小さい矩形の方向 |
|
'rect2_len1' |
領域を囲む最も小さい矩形の長さ(の半分の長さ) |
|
'rect2_len2' |
領域を囲む最も小さい矩形の幅(の半分の長さ) |
Regionデータ (ピクセル単位の領域データ)の主な形状特徴量
|
特徴量 |
内容 |
|
'area' |
オブジェクトの面積 |
|
'area_points' |
XLD点の面積 |
|
'row' |
中心の行座標(インデックス) |
|
'column' |
中心の列座標(インデックス) |
|
'row_points' |
XLD点の重心の行インデックス |
|
'column_points' |
XLD点の重心の列インデックス |
|
'width' |
領域の幅 |
|
'height' |
領域の高さ |
|
'row1' |
領域の左上コーナの行座標(インデックス) |
|
'column1' |
領域の左上コーナの列座標(インデックス) |
|
'row2' |
領域の右下コーナの行座標(インデックス) |
|
'column2' |
領域の右下コーナの列座標(インデックス) |
|
'circularity' |
真円度 |
|
'compactness' |
コンパクト |
|
'contlength' |
XLDの長さ |
|
'convexity' |
凸面度 |
|
'ra' |
等価楕円の長軸半径 |
|
'rb' |
等価楕円の短軸半径 |
|
'phi' |
等価楕円の方向 |
|
'ra_points' |
XLD点の等価楕円の長軸半径 |
|
'rb_points' |
XLD点の等価楕円の短軸半径 |
|
'phi_points' |
XLD点の等価楕円の方向 |
|
'anisometry' |
Anisometry |
|
'anisometry_points' |
XLD点のAnisometry |
|
'bulkiness' |
Bulkiness |
|
'struct_factor' |
Structurefactor |
|
'outer_radius' |
領域を囲む最も小さい円の半径 |
|
'orientation_points' |
XLD点の方向 |
|
'rect2_phi' |
領域を囲む最も小さい矩形の方向 |
|
'rect2_len1' |
領域を囲む最も小さい矩形の長さの半分の長さ |
|
'rect2_len2' |
領域を囲む最も小さい矩形の幅の半分の長さ |
XLDデータ (サブピクセル単位のデータ)の主な形状特徴量
領域情報は、右図に示すように、画像範囲に対して、各ピクセルが領域に属する「1」、属さない「0」のバイナリ形式で保持して扱うことが一般的です。この場合のデメリットを3つ挙げます。
まず初めに、領域データの大きさに関わらず画像サイズと同じだけのデータ量を必要とすることが挙げられます。領域データにアクセスするためには先頭ピクセルから走査し、目的の領域にたどり着く必要があるために、アクセスに手間がかかります。
次に、バイナリ形式の場合、あるピクセルを表現するのに1つの値しか持てないために、基本的には領域同士の重なりを表現できないことが挙げられます。例えば、ラベリング処理後の領域集合において、別々の領域として抽出された領域Aと領域Bにモフォロジー処理の結果で重なりが生じたとしても、あるピクセルの属性が領域Aと領域Bのどちらにあるのか、あるいは重なりが生じたピクセルについては、複数の属性値を保持するのか、など、その定義と取り扱いが複雑になります。
最後に、バイナリ形式で領域を表現する場合、領域へのモフォロジー処理やアフィン変換処理などの結果、画像範囲(例えば640×480)の外に出てしまう場合、画像範囲の外(例えば[-10, -30]の値など)での領域をどう定義するか、その領域に対してどう処理を行うか、対処するためには事前に画像範囲の外の領域の定義を行うなど特別な配慮が必要となることが挙げられます。
HALCONは領域データの取り扱いに関しても優れた設計思想に基づいています。HALCONではRegion(領域)データをバイナリデータ形式ではなく、「ランレングス表現」と呼ばれるデータ構造で保持しています。
右図に簡単なRegionデータ(ピンク色の部分)と右表にランレングス表現によるRegion(領域)データの持たせ方の例を示す。ランレングス表現ではRegion(領域)を行単位で管理しており、各行を複数の「ラン」で定義します。
各「ラン」は開始点と終了点の位置情報を持っています。右図の例では、画像サイズ7×5に対して、Run1が(1,1)から始まり(1、4)で終わり1行目の情報を1つのランで定義できます。同様に2行目はRun2とRun3の2つのランで定義されています。Run2が(2、2)で始まり(2、2)で終わり、1ピクセル分穴があり、Run3が(2、4)で始まり(2、5)で終わります。
3行目は1つのランで表現され、Run4が(3、2)で始まり(3、5)で終わります。0行目、4行目にはRegionデータは存在しないためRunも必要ありません。
以上のように、バイナリデータで領域を定義すると画像サイズ(7×5)分の大きさ・データ量が必要となることに対して、ランレングス表現では4つのランで定義することができます。
HALCONではランレングス表現でRegion(領域)データを定義することにより、Region(領域)データへの高速アクセスを実現しています。Region(領域)データとして存在しない部分の情報はもともと保持していないため、例え大容量の画像を扱う場合であっても、目的のRegion(領域)データへのアクセスを簡単に行うことができます。さらに、Region(領域)同士の重なりを定義することができ、また、変換によって画像範囲の外に出てしまったRegion(領域)も表現することが可能です。つまり、バイナリデータ形式で領域データを定義する際の問題点を全て解消できます。
補足として、これまでバイナリ形式での領域表現との比較を行ってきましたが、実際の表現では、ビットよりもバイトへアクセスする方がはるかに容易であるため、1ピクセル当たり1バイトで表現されることもよくあります。この場合、「ランレングス表現」でRegion(領域)を表現することにより、メモリ消費量も大幅に抑えることができることになります。
Region(領域)データ構造などの基本設計は、その定義の上に様々な画像処理機能が成り立っているために、データ構造としてはより優れていると分かっていても、根幹である基本設計を後から変更することは極めて困難です。HALCONでは設計当初からRegion(領域)をランレングス表現で定義する優れた設計コンセプトを導入しており、各フィルター系、モフォロジー系による処理の多機能性・高速性を実現しています。









