はじめに
こんにちは、API・バックエンドチームの成田です。
日々、レコメンドエンジンの開発や各種APIの作成・管理などを行っています。今回は画像処理を用いた取り組みとして、「OpenvCVを利用したサムネイル画像のクロップ推定」についてのお話です。
日経電子版では毎日約1,000本の記事が配信され、それぞれの記事の多くには画像がついています。現在、画像には用途ごとにいくつかの種類が存在しますが、今回はそのうち2つを扱います。1つはオリジナルの無加工高解像度画像で、撮影した写真、作成した図表そのものです。そして、もう1つはオリジナルをクロップ・リサイズした画像で、こちらは主にサムネイルとして利用することを目的としています。
旧CMS→新CMSへ
日本経済新聞社で記事や画像のデータを管理しているCMSシステム群の刷新を控えています。旧CMSではオリジナル画像とサムネイル画像をそれぞれ別ファイルとして保持していました。新CMSに代わるとオリジナル画像のみの保持となり、画像とは別にメタデータとしてサムネイル用クロップパラメータを持つようになります。
クロップパラメータとは、imgix（画像ファイル配信用CDN）にわたすパラメータで、クロップの中心座標（fp-x、fp-z）とズーム率（fp-z）から成ります（参考）。これにより、オリジナル画像からサムネイル画像を生成し配信可能です。そこで、旧CMSでの記事でもこのパラメータを推定し、メタデータに追加することで、CMS移行の前後で処理を統一させることが可能となり、副次効果として、アプリ用・PC用などサムネイル画像の解像度を自由に決めることが出来るようになります。
テンプレートマッチングと特徴点マッチングを利用したクロップ推定
全体の流れ
クロップパラメータの推定用に今回はテンプレートマッチングと特徴点マッチングを活用することを考えます。全体のフローとしては以下のようになります。2種類のスケール推定を行っている点、テンプレートマッチングを場合によって2回行っていることが特徴です。これをAWS Lambda上で動かしています。以下、個別技術について説明していきます。
テンプレートマッチング
テンプレートマッチングとは、入力画像からテンプレート画像と最も類似する箇所を探索する手法で、物体検出や物体追跡に使われる手法です。下のように、クロップ画像をテンプレート画像とし、どこからクロップされた可能性が高いかを計算します。
この手法では、2枚の画像のスケール（縮尺）が異なると、以下のようにマッチングの精度が低くなってしまいます。サムネイル画像はただクロップされているだけでなく、解像度も変更されているケースがほとんどなので、両者のスケール比を推定し、揃える処理を挟む必要があります。
ナイーブなスケール推定
実際に記事や画像の管理では、縦長のオリジナル画像の上下を削って縮小してサムネイル画像として使っています。
この処理であれば、2枚の画像の幅の比率がスケール比となるので、扱いが簡単です。一方で、画像の上下だけでなく、左右も削って縮小してサムネイル画像とするケースもありますが、この場合は単純な計算では推定できないので、特徴点マッチングと呼ばれる手法を使います。
特徴点マッチングによるスケール推定
特徴点マッチングとは、2つの画像それぞれで、回転・スケールに対して頑健な特徴点を大量に抽出し、似た特徴点をマッチングする方法です。こちらの手法も物体検出や物体追跡によく使われています。特徴点としてはSIFTやSURFが有名ですが、今回は改良版となるAKAZEを使用します。
特徴点マッチングの例を下に示します。このように2枚の画像はサイズが違いますが、同じ箇所、例えばデンシバ君の目や鼻で特徴点がマッチングされているのがわかります。このように2枚の画像で対応する点をとっていき、精度がより高い20組を選びスケール比の計算に使います。
例えば、下の図では特徴点が3組の場合の例です。この3つの特徴点同士の距離をそれぞれ測り、3つの画像間距離比の中央値をスケール比とします。実際には20組なので、画像ごとに20C2=190通りの距離を測ります。そして、380個の画像間距離比の中央値をスケール比とします。
この手法の問題点としては、計算に時間がかかることです。環境にもよりますが、メモリ2048MBのAWS Lambdaでの実行時間は2秒ほどかかります。コスト削減のため、まずは上記のナイーブなスケール推定を行ってからテンプレートマッチングを行います。そして、マッチングの精度（画素値の誤差）が悪い場合のみ、この特徴点マッチングによるスケール推定をし、テンプレートマッチングを再度行うというような工夫を行っています。
