Azure Machine LearningのOpenCV Image Readerを試してみた

2014年12月22日月曜日

このエントリは Azure Advent Calendar 2014 の22日目のものです。昨日はtatsuakisakaiさんの Service Bus メッセージングを使ってみよう~Topic & Subscription でした。

 今日はAzureの中でも比較的新しめの機能、ML(Machine Learning)について取り上げます。前回 のエントリで書こうとしてイマイチ収まらなかったネタのリバイバルです。

この1年少々、Azureには怒涛の勢いで新機能が追加されています。2年ほど前までは機能面でAWSよりも見劣りする箇所の多かったAzureですが、今では一定のクセがあるものの機能的にはだいぶ差が縮んでいます。



そんな中、AWSに加えてGoogleのクラウドサービスをもぶっちぎってAzureがPreview提供しているのが Machine Learning(機械学習)機能です。これは、BingやXbox Liveなどの中で利用されている機械学習の仕組みをAzure上に展開してサービスとして提供する形のものです。

こう聞くと「おや?」と思う方も居るかもしれません。Google I/O 2014でGoogleの似たような仕組みを使ってワールドカップの対戦結果予想をやってたよね?? と。

私も例に漏れずそのように考えてGoogle Prediction APIを調べた組です。そしてがっかりしました。
  • API面ではもう1年も更新がないし
  • アクティブにメンテされていた頃のProduct Managerが辞してから結構な時間が経ってるし
  • Prediction Galleryという半コミュニティドリブンのアルゴリズムギャラリーが1件たりと存在しないし
「あっ、これはいつ年(度?)末大掃除食らってもおかしくないや」という状況に見えました。

そんな時にちょうどAzureのMachine Learning機能を見つけて、あまりのモダンさに驚きました。
  • それなり以上によく出来たStudio(Web UIでのモデル構築ツール)
  • 豊富な組み込みアルゴリズムとサンプルデータ(学習用に素晴らしい)
  • 「なんなら複雑なことはRで書けばええよ」というフリーダム感
  • AzureのストレージやHadoopクラスタ、SQLサーバなどともつなぎこみ放題
という感じです。すごいですね。

さて、そんなことをつらつらと書いていたところ、ごく最近 機能アップデートがおこなわれていたことに気付きました。
なかでも一際目を引くのが
  • Pre-trained Cascade Image Classifier module for face detection, using OpenCV library.
  • Image Reader module that uses OpenCV library to read images from Azure Blob storage
です。OpenCVのインテグレーションが…! どこまで行ってしまうのかAzureは。
ということで今回はさっそくOpenCVのImage Readerモジュールを試してみました。

  
 大体こんな感じでImage Readerを配置します。データソースにはAzureのStorageを利用するので、ここではお試し用に新設しました。

Image Readerがどういうデータを返してくれるのかイマイチ分からなかった(というかドキュメントまだないぽよい)ので、Azure Storage Explorer を使ってPNG画像をいくつかアップロードしました。
そして実際に走らせてみると、いきなりエラーで止まります。
Error 0048: Error while opening the file: filename.png.
という感じです。

なんだろなー、PNGダメなのかなー、などと考えつついろいろな画像を投入してみると、きちんと結果データを出してくれるものもありました。
違いを探していくと、どうも一定以上のサイズの画像は受け付けてくれないようです。
$ convert -size 1x1 gradient:blue g1_1.png$ convert -size 10x10 gradient:blue g10_10.png
$ convert -size 100x100 gradient:blue g100_100.png
$ convert -size 1000x1000 gradient:blue g1000_1000.png
 という具合で1x1 -> 10x10 -> 100x100 -> 1000x1000とピクセル数の段階をつけてみたところ100x100と1000x1000の間に壁があるらしい。このへんでほんのりと察しつつ、あとは二分探索で調べていきました。
結果、65536pxを超える画像は解析できないことが分かりました。

さて、それでこのImage Readerがどんな 結果を返してくれるか、なのですが
Image Name,Red1,Red2,Red3,Red4,Red5,Red6,Red7,Red8,Red9,Red10,Red11,Red12,...
cvtest01.png,42,42,42,42,42,42,42,42,42,42,42,42,...
という形式です。要はピクセルを左上から舐めていき右下までの連番がカラム名につけられて、値はその8bit値という具合です。
なお、Red1, Red2, ... といってRed<width*height>の次はGreen1, Green2, ..., Blue1, Blue2, ..., Blue<width*height>と続いていきます。

確かなImage Readerだった。
しかしこれ使いやすいのかなーと思うと、微妙な感じがします。
少なくとも、Web上から拾ってきた画像をごっそり解析するには向かないでしょう。解析対象画像のサイズやアスペクト比がばらばらでは同カラムに全然別の位置のピクセル情報が格納されることになります。
このため、Azure Storageへの格納前に一定の寸法へのリサイズとstrideがずれないような正規化をおこなう工夫がまず必要でしょう*1。

そして、仮に画像解析用途で考えると、Image Readerの出力である24-bitの色情報は過多なケースが多そうです。これまた事前処理の時点で16-bit程度やさらに少ない色解像度へと落としておいたり、あるいはRedのみを利用するように減色・パッキングをおこなって実効8-bit情報として解析できるようにしたり、などのhackによって計算量を低減するとお得に解析できそうです(あっ、リサイズと減色の際には誤差拡散法などを利用すると後で自らの分析の邪魔になるノイズを加えることになりがちな気がするので注意して)。

猛烈に発展途上感がする機能ですが、きっと工夫次第でいろんな使い道があるのでしょう。


これからもAzureの機会学習機能の動向に注目ですね!

*1: Rの文化圏ではこういうデータが普通なのかなーとも思ったのですが、width/heightの解析情報すらカラム出力されないのでいくらなんでも加工して使いづらいですね。ゆえに前処理される前提だろうと読みました

0 件のコメント:

コメントを投稿