雑コラBotを作ろう①: Azure Functionsで簡易的なSlack BOTを作る

Michaelです。

前回、Azure FunctionsとFace APIを使った「雑コラBOT」を紹介しました。
今回からは、数回にわたってその作成の過程をご紹介します。1回目は、Azure Functionsでメッセージをそのまま返すオウム返しする簡易的なSlackのBOTを作成します。

構成

Slackに投稿したメッセージをAzure Functionsで受け、BOTの開始をSlackに通知します。

関数の作成とバインド設定

Azure Functionsの関数をJavaScriptで作成します。
関数のテンプレートから「Generic webhook」を選択し、JavaScriptで関数を作成します。

関数が作成されたら「統合」を選択し、トリガーの設定を変更します。
「Webhook type」をデフォルトの「Generic JSON」から「Slack」に変更します。

Slackカスタムインテグレーションの設定

Slackに投稿されたメッセージをAzure Functionsに送信するようにSlackを設定します。
SlackのAppディレクトリから「発信Webフック」を検索し、カスタムインテグレーションに追加します。

「発信Webフック」の設定を開き、メッセージを送信するURLを設定します。
URLには「https://{Functon App名}.azurewebsites.net/api/{関数名}?clientId={任意のclientId }」の形式でAzure Functionsの関数のURLを入力し、設定した「clientId」と「トークン」をメモにひかえておきます。
その他の項目は任意で設定をします。

clientIdとトークンの設定

Slackの設定が終わったら、控えておいたSlackの「clientId」と「トークン」をAzure Functionsに登録します。
関数の「管理」から「新しい関数キーの追加」をクリックします。

「名前」、「値」にそれぞれ先ほどのSlackの「clientId」、「トークン」を記入し、右の「保存」をクリックして設定を保存します。

関数のスクリプトエディタに戻り、「</>関数のURLの取得」をクリックします。
「キー」に追加したclientIdが追加され、選択するとSlackに設定したURLが表示されることが確認できます。

スクリプト

スクリプトは以下のように作成しました。
[crayon-6080acfab7eff455311477/]

スクリプトの説明

レスポンスを速くするため、単純な処理でメッセージを処理しています。

  1. フォームデータをオブジェクトに変換
    Slackから送信されるフォームデータを扱いやすいようにオブジェクトに変換します。
  2. slackbotからのメッセージの除外
    Slackの設定によりますが、slackbotからのメッセージで関数が起動してしまうことがあるため、「user_name」を参照してslackbotからのメッセージでは処理を中断させます。
  3. Slackにレスポンス
    Slackにレスポンスを返し、BOTの実行を通知します。

実行結果

Slackの設定したチャンネルにメッセージを投稿すると、BOTの開始を通知する「BOT Start!」のメッセージがBOTから返されました。

まとめ

ここまでが、Azure FunctionsでSlack BOTを作成するための基本の操作となります。
次回は、Azure Functionsで受けたメッセージからURLを抽出してAzure Queue Storageに格納するまでを作成します。


雑コラBotを作ろう

Michaelです。

今回は、Azure FunctionsとFace APIで「コラ画像」を自動的に作成する『雑コラBot』をご紹介します。

背景

古くから、顔ハメ看板やコラージュ、最近では顔交換アプリや「ディープフェイク」のように、顔を切り抜いて他人の顔を合成する、所謂「コラ画像」は、実用性や問題の有無を抜きにして人々の関心や好奇心をくすぐってきました。
弊社でも、社員のフォースに目覚めた姿などの「コラ画像」が業務の合間を縫って数多く作成され、社員にとっての束の間の息抜きとなっています。
しかし、業務が立て込めば「コラ画像」の作成は滞り、作成する社員、その公開を心待ちにする社員の双方がストレスを抱えて業務に悪影響を及ぼしかねないことが問題となっていました。
その問題を解決すべく開発されたのが、社員に代わって「コラ画像」を自動作成するBot、「雑コラBot」です。
(※事実にもとづいたフィクションです。)

Botの動作

Slackのチャンネルに画像のリンクを投稿すると・・・約30秒でBotがコラ画像が返ってきます!

※5倍速

雑コラBotのしくみ

Slackには、画像のURLを投稿するとリンク先の画像がメッセージに表示されるという機能があります。これはBlob StorageのURLでも例外でなく、読み取り権限が有効であればSASがついていても画像を表示させられます。

 

なので、メッセージからURLを抽出して、画像をダウンロードして、顔を検出して、加工して、Blob Storageにアップして、画像のSAS付きURLをSlackに投稿すれば、あたかもBotがコラ画像を返してきたかのような動作をさせることができます。
今回のBotでは、以下のようにAzureのリソースを構成し、この動作を実現しています。


使っているサービスはAzure FunctionsとAzure Storage、Face APIの3つのみで、VM等を使わないサーバーレス構成となっています。Azure FunctionsはSlackとメッセージのやり取りをする2つのフロントエンド関数と画像処理をするバックエンド関数で構成し、それらをQueue Storageをトリガーに連携させています。

まとめ

今回は、Azure FunctionsとFace APIを使った「雑コラBot」をご紹介しました。
コラ画像を自動作成などとやっていることはしようもないBotですが、画像加工をモザイク処理に変更して投稿画像のプライバシー保護に役に立てるというような用途にも応用がききます。
次回からは、今回作成した雑コラBotの構成でAzure Functionsを使ったSlack Botの作成、設定方法をご紹介していきます。


Azure Functions: FaceAPIとOpenCVで顔検出をしてみた。③ -画像の加工-

Michaelです。

こんにちは、Michaelです。
今回から、Azure FunctionsとCognitive Servicesを使って画像内の顔を検出する仕組みを作成していきます。
3回目は、Azure FunctionsとOpenCVを使って、Face APIで顔検出した結果を画像に描画する仕組みを作成します。

今回の構成

前回の構成に、画像をOpenCVで加工し、Blobストレージに格納する仕組みを追加します。
画像の加工はFace APIで取得できる顔位置の枠(faceRectangle)を描き込むだけの簡単な加工にとどめます。

バインドの設定

画像の出力が追加されるため、「出力」のバインドを追加します。
関数の「統合」で、まず「+新しい出力」をクリックし「Azure Blob Storage」のバインドを選択します。
出力画像に関しては、入力ファイルのフォーマットを維持するように加工するため、「{name}_retouched.{extention}」を設定し、ファイル名、拡張子を入力ファイルと揃えています。

Pythonスクリプト

スクリプトは以下のように作成しました。
[crayon-6080acfab88d6535180337/]

スクリプトの説明

スクリプトの内容は以下の通りです。「02‐Face API未対応フォーマット判定」~「04‐顔検出結果をJSONで出力」は前回と変わらないため、前回の記事を参照ください。

01‐ライブラリのインポート
処理に必要なライブラリを指定してインポートします。
今回はOpenCVを使って画像の加工を行うため、「cv2」を追加しています。

05‐画像の読み込み
アップロードされた画像をOpenCVで加工可能なNumPy配列として読み込みます。

06‐検出した顔ごとに枠追加
Face APIで検出した顔それぞれについて「faceRectangle」の情報をもとに、顔を検出した位置を示す枠を描画します。判定された性別ごとに異なる色の枠がつくように加工をしています。

07‐加工済み画像を一時保存
加工した画像をファイルに保存します。
OpenCVでは、画像フォーマットが保存する拡張子で決定されますが、Blob出力用のパスには拡張子がないため、直接指定するとエラーが発生します。
そこで、判定した画像フォーマットを拡張子として画像を保存し、画像のパスをBlob出力用にリネームすることでこの問題を回避します。

実行結果

テストとして、男性1人が写ったJPEG画像「face1-01.jpg」をBlobストレージにアップロードしてみます。


アップロードされるとAzure Functionsが起動し、JPEG画像を保存したログが出力されました


Blobストレージを見ると、関数が完了した同時刻に「face1-01_result.json」とともに、「face1-01_retouched.jpg」のJPEG画像が出力されていました。この画像には、男性を検出したことを示す水色の枠が顔に描画されており、OpenCVで正常に画像加工ができていることがわかりました。


続いて、5人の子供が写ったPNG画像「face5-02.png」をBlobストレージにアップロードしてみます。


Azure Functionsのログでは、PNG画像を保存したログが出力され、フォーマットごとに処理できていることがわかりました。

Blobに出力された「face5-02_retouched.png」の画像を確認すると、5人それぞれの顔に枠が描画されていました。子供のため性別判定は甘いですが、性別ごとに色分けもできていることがわかりました。

まとめ

Azure FunctionsとOpenCVを組み合わせることで画像加工アプリケーションを簡単に構成することができました。OpenCVとFace APIの組み合わせでモザイク処理や黒目線処理も簡単にできるため、アップロードするだけで顔にマスク処理をするアプリケーションも作成できます。


Azure Functions: FaceAPIとOpenCVで顔検出をしてみた。② -Face APIの利用-

Michaelです。

こんにちは、Michaelです。
今回から、Azure FunctionsとCognitive Servicesを使って画像内の顔を検出する仕組みを作成していきます。
2回目は、Azure FunctionsとCognitive ServicesのFace APIを使い、Blobストレージにアップロードされた画像の顔検出結果を取得する仕組みを作成します。

今回の構成

Blobストレージにアップロードされた画像をトリガーにAzure Functionsを起動します。
Azure Functionsでアップロードされた画像をFace APIに送り、顔の検出結果をJSONとしてBlobストレージに格納します。

※ Cognitive Services Face APIの登録に関しては「Cognitive Services: Face APIの顔検出をPythonで試してみた」を参照ください

バインドの設定

Azure Functionsを起動する「トリガー」と結果をBlobストレージに書き出す「出力」のバインドを設定します。
関数の「統合」から、まず「トリガー」をクリックし「Azure Blob Storage」のバインドを選択します。

「Blob parameter name」に任意の名称、「Path」、「Storage account connection」に監視を行うBlobコンテナーのパスとそのストレージアカウントを設定します。パスパターンとして「{name}.{extention}」を設定しておくことで、他のバインドからパスパターンを参照できるようにしています。

「トリガー」と同様に「出力」バインドも「Azure Blob Storage」を選択し、「Blob parameter name」、「Path」、「Storage account connection」をそれぞれ設定します。
「Path」にはアップロードした画像の名称が出力のJSONファイル名に反映されるよう、「{name}_result.json」を設定しています。

Pythonスクリプト

スクリプトは以下のように作成しました。

[crayon-6080acfab915f048261377/]

スクリプトの説明

スクリプトの内容は以下の通りです。

01‐ライブラリのインポート
処理に必要なライブラリを指定してインポートします。
Face APIに対するリクエストを実行するため、外部ライブラリ「requests」を使用しています。
※ 「requests」については
前回の手順で予めインストールしておきます。

02‐Face API未対応フォーマット判定
トリガーとしてアップロードされたファイルがFace APIの対応フォーマット(JPEG、PNG、BMP、GIF)に該当するか判定します。
Azure Functionsでは、os.environ["トリガーバインド名"]に格納されたパスにアップロードデータのコピーがあるため、標準ライブラリ「imghdr」を使用して画像フォーマットを判定し、対応フォーマットのみを選別します。

03‐Face APIで顔検出
Face APIにリクエストをして、画像内の顔を検出します。
Azure FunctionsのPython関数では、アップロードされたBlobのパスを取得できないため、JSON形式でのリクエストができませんが、Face APIはバイナリ形式のリクエストにも対応しているため、os.environ["トリガーバインド名"]のパスにあるアップロードデータのコピーで直接リクエストし、顔の検出を行います。

04‐顔検出結果をJSONで出力
Face APIで出力された結果をそのままJSON形式で出力します。
os.environ["出力バインド名"]のパスに出力したいデータを保存するとBlobストレージに格納されます。

実行結果

テストとして、JPEG画像を「face-01.jpg」としてBlobストレージにアップロードしてみます。


Azure Functionsのログを見ると、アップロードされた4秒後に関数が開始され、順次ログを出力しながら約10秒で関数が完了しました。

Blobストレージを見ると、関数が完了した同時刻に「face-01_result.json」の名称でJSONファイルが出力されていました。バインドで設定したパスパターンが出力ファイル名に反映されていることがわかりました。


出力されたJSONの内容は以下になります。Face APIの出力がそのままBlobストレージに出力できていました。
[crayon-6080acfab9167105365101/]
続いて、画像ではないJSONデータ「face-02.json」をBlobストレージにアップロードしてみます。

スクリプトでフォーマット判定を行っているため、Azure Functionsのログを見ると正常に処理が中断されていることがわかりました。

まとめ

Azure FunctionsのPython関数は、C#やJavaScriptのようにバインドのパスパターンをスクリプトで参照できないため、入出力の方法にひと工夫が必要になりますが、今回のようにパスパターンに大きな変更がなければ簡単に設定して処理を組むことができました。
次回は、今回の処理にOpenCVを使いして、検出した顔の情報を画像に描画してみます。


Azure Functions: FaceAPIとOpenCVで顔検出をしてみた。① -Python3と外部ライブラリの導入-

Michaelです。

こんにちは、Michaelです。
今回から、Azure FunctionsとCognitive Servicesを使って画像内の顔を検出する仕組みを作成していきます。
初回は、Azure FunctionsにPython3とOpenCVを導入してみます。

※この記事は以下のサイトを参考に作成しています。
・https://qiita.com/Akira-Isegawa/items/f3c8d14ee43049459264
・https://prmadi.com/running-python-code-on-azure-functions-app/

Python3の導入

Azure Functionsでは、Python 2.7.8がデフォルトで利用できるバージョンとなっています。
下記のスクリプトをテスト実行してPythonのバージョンを表示すると、「2.7.8」であることが確認できます。
まずこれを、Python 3.6.4にアップデートします。

※Azure Functionsの作成、及びPython関数の作成に関しては、Azure Functions:キューメッセージをトリガーとしたPython関数を作成してみる」を参照ください。
[crayon-6080acfab99ca641751624/]

Azure Functionsのポータルを「プラットフォーム機能」→「高度なツール (Kudu)」をクリックし、「Kudu」を開きます。

Kudu画面上部のメニューから「Debub console」→「CMD」をクリックします。


ディレクトリ一覧とコマンドプロンプトが表示されるため、一覧から「site」→「tools」を選択、もしくはコンソールで「cd D:\home\site\tools」を実行して「D:\home\site\tools」のディレクトリに移動します。

下記コマンドで「D:\home\site\tools」のディレクトリにPython 3.6.4をインストールします。
[crayon-6080acfab99d1934056824/]
インストールしたPython 3.6.4をAzure Functionsで実行できるようするには、python.exeを「D:\home\site\tools」直下まで移動する必要があります。
下記コマンドで、python.exeの格納されているディレクトリ以下をすべて、「D:\home\site\tools」の直下に移動させます。
[crayon-6080acfab99d4483106544/]
以上を実行したら、Azure FunctionsのPython関数に戻り、最初のPythonスクリプトでPythonのバージョンを確認します。
関数の実行ログに「3.6.4」と表示され、バージョンが変更されていることが確認できました。

ライブラリのインストール

上記の手順でPythonをインストールすると、pipを使ってライブラリを管理できるようになります。
Pythonにライブラリを追加する場合には、「Kudu」のCMDコンソールで下記のコマンドを実行します。
[crayon-6080acfab99d6782393521/]
OpenCVをインストールする場合は、ライブラリ名を「opencv_python」として実行します。
[crayon-6080acfab99d8401841401/]
下記コマンドでインストールされているライブラリの一覧を表示すると「opencv-python」がインストールされていることが確認できます。
[crayon-6080acfab99da168065398/]

また、Python関数でOpenCVをインポートしてみると、インポートエラーは発生せず、ライブラリが読み込まれていることが確認できました。
[crayon-6080acfab99dc777641787/]

まとめ

Azure Functionsでは、デプロイパッケージを使わず、Kudoで直接ライブラリを追加できるため、追加でライブラリが必要になった場合でもいちいちデプロイパッケージを作り直す必要がなく便利です。
次回は、Azure FunctionsからCognitive ServicesのFace APIを使い、画像の顔検出を試してみます。


Cognitive Services: Translator Text API v3を試す

Michaelです。

今回は、バージョンアップしてv3になったTranslator Text APIを試してみます。

Translator Text API v3の変更点

Translator Text API v3では、リクエストがJSONに変更されており、XMLだったv2に比べ格段に使いやすくなりました。
1リクエストで複数言語に同時翻訳が可能になったほか、言語検出、翻字、辞書による代替翻訳の検索といった言語分析機能も強化されており、翻訳に限らず様々な用途に利用できるようになっています。
Translator Text API v3で利用できる機能は、以下の通りです

機能 内容
Translate テキストの翻訳
Transliterate テキストの翻字
Detect テキストの言語情報を取得
BreakSentence 文章の境界の位置を特定
Dictionary Lookup テキストの意味と類似する単語や慣用句を取得
Dictionary Examples 単語の例文を取得

Translator Text API v3の使用

Translator Text API v3の翻訳機能をPythonで試してみます。
Web APIなのでリファレンス通りにデータを整形してリクエストすれば結果が返ってきますが、これまでのようにXMLに整形してリクエストし、返ってきたXMLを再度整形して辞書に戻すといった煩わしい処理が必要なくなったため、非常にシンプルなスクリプトで利用できます。
APIキーもv2のキーがそのまま使えるため、キーの再取得も必要ありません。
[crayon-6080acfaba257282081080/]
スクリプトでは翻訳先言語に「ja-JP」(日本語)と「es」(スペイン語)の2言語を設定し、「hello」と「world」を翻訳していますが、それぞれ同時に指定言語に翻訳できていました。
[crayon-6080acfaba25e592414776/]

まとめ

JSONでのリクエストが主なCognitive Servicesの中で、XMLでのリクエストが求められるAPIだったこともあり、Translator Text APIは少し取り付きにくい存在でしたが、JSONでリクエストができるようになったので非常に扱いが容易になりました。
言語分析も大幅にアップデートされているようなので、これを機会に利用してみてはいかがでしょうか。


Azure Machine Learning Studio: PowerShellによるWeb Serviceのデプロイと運用を検証する② エンドポイント作成編

Michaelです。
今回は、前回に引き続きAzure Machine Learning Studio (ML Studio)のPowerShell用モジュール「AzureMLPS」を使用して、PowerShellによるWeb Serviceのデプロイと運用について検証していきます。
2回目は、PowerShellを使ってモデルとWeb Serviceエンドポイントの作成を行っていきます。

Web Serviceエンドポイント作成フロー

前回も紹介したように、Web Serviceのデプロイと運用をするために以下の3操作をプログラムで実行してみます。

1. 学習用Web Serviceでモデルを作成
2. 予測用Web Serviceにエンドポイントを追加
3. 追加したエンドポイントのモデルを置換

1. 学習用Web Serviceでモデルを作成

それでは、実際にPowerShellでAzure ML Studioを操作してみます。
まずは、AzureMLPS とモデル名等の各種設定を定義しておきます。学習用Web Serviceで作成したモデルはAzure Storageに保存されるため、書き込みのためにストレージアカウント名とキーも設定しておきます。

[crayon-6080acfabaabe600796254/]
続いて、学習用Web Serviceでモデルを作成します。モデル作成のスクリプトは以下のようになります。
[crayon-6080acfabaac4680501632/]
なお、モデル作成ジョブの設定値は学習用Web Serviceの「Batch Execution」リファレンスの「Sample Request Payload」を参照して設定して下さい。

上記スクリプトを実行すると学習用Web Serviceが実行され、成功すると指定したBlob Storageの指定ディレクトリにモデル(.ilearner)とその精度評価データ(.csv)が出力されます。

2. 予測用Web Serviceにエンドポイントを追加

次に、予測用Web Serviceにエンドポイントを追加します。
Web Serviceには、作成段階で1つのデフォルトエンドポイントが作成されますが、このエンドポイントはモデルの更新ができないため、1モデルを更新しながら運用する場合でも、1つは新規エンドポイントを作成する必要があります。
エンドポイントを追加するスクリプトは以下のようになります。
[crayon-6080acfabaac7205749688/]
上記スクリプトまでを実行するとWeb Serviceにエンドポイントが追加されます。ここで作成されるエンドポイントはデフォルトエンドポイントのコピーであるため、まだ予測モデルは適用されていません。試しに、モデル作成時に使用した評価データをテストデータとして予測してみると、データが全く異なるため実際の分類とは異なるスコアリングがされたデータが返ってきました。

・予測モデルの精度評価

・作成したエンドポイントの精度評価

3. 追加したエンドポイントのモデルを置換

最後に、エンドポイントのモデルを新規に作成したモデルで置換します。
モデル置換に使用するPatch-AmlWebServiceEndpointコマンドレットは若干設定の複雑なコマンドレットで、設定値に設定先エンドポイント、Blob Storage上のモデルのパスのほか、置換する予測用Experiment上のモデルの名称を指定する必要があります。

モデルのパスについてはモデル作成時のレスポンスを参照すれば取得でき、予測用Experiment上のモデルの名称についてはGet-AmlTrainedModelコマンドレットで取得できます。
エンドポイントのモデルを置換するスクリプトは以下のようになります。
[crayon-6080acfabaacb552077661/]
上記スクリプトを実行するとエンドポイントのモデルが置き換わり、新規作成したモデルで予測ができるになります。モデル置換後のエンドポイントで再度評価データをスコアリングしてみると、モデル評価と全く同じスコアリング結果が得られていることがわかりました。

・予測モデルの精度評価

・モデル置換前の精度評価

・モデル置換後の精度評価

まとめ

今回は、1つのモデルについて学習からエンドポイント作成までを行いました。この一連の流れが、モデルとエンドポイントの作成の基本となり、ループ処理を加えることでバッチ的に複数のモデルとエンドポイントを作成できます。
次回は、作成したスクリプトにループ処理を追加して複数のモデルとエンドポイントを作成してみます。


Azure Machine Learning Studio: PowerShellによるWeb Serviceのデプロイと運用を検証する① 準備編

Michaelです。
今回から、Azure Machine Learning Studio (ML Studio)のPowerShell用モジュール「AzureMLPS」を使用して、PowerShellによるWeb Serviceのデプロイと運用を検証していきます。
初回は、PowerShellでWeb Serviceをデプロイするための基本となるExperimentの作成とWeb Service作成を行います。

Web Serviceの運用

機械学習を業務に活用する場合、予測モデルの作成とそれをアプリケーション連携させる仕組みが必要になります。Azure ML Studioでは、GUI上で容易に予測モデルとWeb Service (API)を作成することができるため、機械学習初心者でも比較的簡単にモデル作成から、アプリケーション連携、運用までを行うことができます。

反面、Azure ML Studioを使った機械学習の運用を考える場合、GUIベースというサービスの特徴が運用上の足かせとなる場合が出てきます。例えば、店舗を全国展開しており、気候、風土が予測に影響をするようなケースでは、全国一括したモデルを運用するより、地域、店舗ごとの数十、数百のモデルを用意して運用するほうが多くの場合で精度が高くなります。このような多数のモデルの運用をGUIで管理するのは非現実的です。
そこで、多数のモデルを運用することを想定して、GUIでなくプログラムによるAzure ML Studioのモデル運用を考えてみます。

PowerShellによるWeb Serviceのデプロイと運用

Azure ML Studio では、Web Serviceにエンドポイントを追加して、モデルを置き換えることにより複数のモデルを1つのWeb Serviceで運用することができます。モデルの作成に関しては、学習用Web Service (再学習API)を使用すれば、データセットに合わせて作成することができるため、以下の3つの操作をプログラムで実装できれば、Web Serviceのデプロイ、運用を簡略化、自動化できるはずです。

1. 学習用Web Serviceでモデルを作成
2. 予測用Web Serviceにエンドポイントを追加
3. 追加したエンドポイントのモデルを置換

AzureMLPSには、これらの操作を実行できるコマンドレットが含まれるため、PowerShellを使用することで、Web Service運用の自動化ができます。
今回は、PowerShellを使用したWeb Service運用を行う上で必要となる学習用Web Serviceと予測用Web Serviceを作成していきます。

学習用Web Serviceの作成

まずは、個々のモデルを作成するための学習用ExperimentとWeb Serviceを作成します。
学習用Experimentは、作成したモデルをBlobに書き出すための「Web Service Output」を「Train Model」に、モデル評価値を書き出すための「Web Service Output」を「Evaluate Model」にそれぞれ接続します。


「Web Service Output」の設定を識別しやすいようにプロパティーから、出力の名称を任意で設定します。


入力データがモデル毎に変わるため、「Import Data」のパラメータを外部変数に設定しておきます。今回はデータをBlob Storageから取得するため、「Path to container, directory or blob」をWeb Service ParameterとしてWeb Serviceから変更できるように設定します。


以上が設定出来たら、一度Experimentを実行、完了させ、下部メニューバーの「SET UP WEB SERVICE」の「Deploy Web Service [Classic]」を選択して学習用Web Serviceを発行します。

予測用Web Serviceの作成

まずは、予測用ExperimentとWeb Serviceを作成します。
学習用Experimentの画面に戻り、「Predictive Web Service [Recommended]」を選択して予測用Experimentを作成します。


作成された予測用Experimentを再度実行して正常に完了することを確認し、下部メニューバーの「DEPLOY WEB SERVICE」の「Deploy Web Service [Classic]」を選択して予測用Web Serviceを発行します。


まとめ

今回は、ここまでとなります。次回は、実際にPowerShellをモデルとWeb Serviceエンドポイントを作成していきます。


新しくなったAzure Machine Learning:概要編

Michaelです。
今回から複数回にわたり、新しくなったAzure Machine Learning (Azure ML)について紹介していきます。初回は、Azure MLに追加された新サービス「Azure Machine Learning Services」の概要について紹介します。

Azure MLの新サービス

9/25から9/29に行われたマイクロソフトのイベント「Ignite 2017」において、いくつかの新サービス、機能拡張が発表されました。その中でAzure MLにも新サービス「Azure Machine Learning Services (以下Azure ML Services)」が追加され、従来のAzure MLは、「Azure Machine Learning Studio (以下Azure ML Studio)」というサービス名に変更されました。

Azure ML Servicesの背景

従来のAzure ML (現Azure ML Studio)は、ブラウザ上のGUIで機械学習の実験・モデル作成からAPI化まで可能なクラウドサービスとして提供されてきました。GUIのためツールとして非常に使い勝手の良いサービスですが、クラウドサービスという性質上、特に以下のような制約についての改善要望が多かったようです。

・マシンスペックが変更できない…GPGPUのような高速コンピューティングが利用できない
・Web APIしか利用できない…社内規制でクラウドに出せないデータを扱えない
・Deep Learningに対応していない…カスタムで扱えなくもないが、Azure ML Studioへの導入は面倒

Azure ML Servicesは、これらの要望に対し、AIの統合開発環境を提供する形で応えたものとなります。Azure ML Servicesでは、Azure ML Studioよりも柔軟にAIモデルを開発するために、AI開発・運用で必要な「データ加工」、「モデル作成」、「デプロイ・運用」の作業を一元的に管理でき、かつAIモデルのデプロイ先も自由に選択できるように設計されています。

Azure ML Servicesのコンポーネント

Azure ML Servicesは、「Workbench」、「Experimentation service」、「Model management service」の3つのコンポーネントで構成されており、それぞれの機能としての位置づけは以下のようになります。

Workbenchは、デスクトップアプリケーションとして提供され、データ加工からモデル作成までを行います。開発は、Azure ML StudioのようなGUIではなく、コーディングベースとなりますが、以下のような多様な環境、言語、フレームワークに対応しています。

項目 対応環境
OS Windows 10、Windows Server 2016、macOS Sierra、macOS High Sierra
言語 Python、R
フレームワーク Microsoft Cognitive Toolkit(CNTK)、Tensorflow、Chainer、Spark ML、Caffe2、PyTorch他
連携可能IDE Visual Studio、Visual Studio Code、Jupyter Notebook、PyCharm他

Experimentation serviceは、モデルの学習環境や履歴を管理するためのサービスで、モデル作成を実行する環境や学習済みモデルの精度等のパラメータを容易に比較、参照できるようになっています。学習済みモデル自体が個々に保存、管理されるため、過去に作成されたモデルが最適であった場合でも再学習することなく、再現性のあるモデルを選択できるようになっています。


Model management serviceは、作成されたモデルをデプロイし、管理・運用するためのサービスです。作成したモデルをLinux ベースのDockerコンテナーとしてデプロイでき、対応する環境であればAzure環境だけでなく、オンプレミス環境やIoTのようなエッジデバイスにも適応することができます。運用する上でのモデルのバージョン管理や再学習の自動化といったこともできるため、モデルを実運用に展開した後の管理も非常に簡単に行うことができます。

まとめ

Azure ML Servicesは、ディープラーニング対応やオンプレミス、エッジデバイスでの運用など、従来からのAzure ML Studioではできなかった柔軟なAI運用が可能となります。
Azure ML Studio のようなGUIベースではないため、誰でも簡単に使えるというようなものではありませんが、広く使われ、ナレッジも多い「CNTK」や「TensorFlow」、「Chainer」といったフレームワークが使用できるため、始めるにあたっての障壁もそれほど大きくはないのではないでしょうか。
次回は、Azure ML Services を実際に使用していくためのAzureでの設定を紹介します。
お楽しみに。


Cognitive Services: HoloLens で撮影した動画をVideo APIでブレ補正してみた② 操作編 (プレビュー)

Michaelです。
前回、「Cognitive Services: HoloLens で撮影した動画をVideo APIでブレ補正してみた① 準備編」として、Video APIの概要とAPIキーの取得方法を説明しました。2回目の今回は、取得したAPIキーを使用して実際にVideo APIの「Stabilization」機能を使って動画のブレ補正を試してみます。

Video APIの利用手順

動画を扱うVideo APIでは、Face APIやComputer Vision APIのような静止画向けAPIと比べ解析、変換に時間がかかるため、APIの利用方法が異なり、下記の3ステップで動画解析、および結果の出力を行います。

1. Video APIへの動画の登録
2. 解析・変換の進捗確認
3. 補正済み動画のダウンロード

Video APIへの動画の登録

まずは、Video APIに解析する動画をAPIに登録します。
動画登録は、他のVision カテゴリのAPIと同じく、ヘッダにAPIキー、本文に対象の動画のURLを設定し、POSTメソッドでリクエストを行います。
Video APIが他のVisionカテゴリのAPIと異なるのは、登録が成功した場合に、ステータスコード202 (Accepted)が返され、レスポンス本文に情報が返されない点です。続く手順で必要になる、進捗確認用のURLは、レスポンスヘッダの「operation-location」を参照します。

[crayon-6080acfabb3a8349805829/]
レスポンスヘッダの「operation-location」を参照すると以下のようなURLが確認できます。(このURLは、生成されてから24時間有効です。)
[crayon-6080acfabb3ae270024736/]

解析・変換の進捗確認

レスポンスヘッダの「operation-location」で得られるURLに対してGetメソッドでリクエストをすると、動画変換の進捗を確認することができます。レスポンス本文の「status」を参照すると進捗状況に合わせて「Not Started」⇒「Uploading」⇒「Running」⇒「Succeeded / Failed」とステータスが変化するため、定期的に状況をチェックして変換が完了するのを待ちます。Video APIでは、1分間のリクエストが5回に制限されているため、コードでは15秒ごとに進捗を確認するように設定しています。

[crayon-6080acfabb3b1571501476/]
変換が完了すると「Succeeded」のステータスとともに、レスポンス本文の「resourceLocation」から変換済み動画のダウンロード用URLが取得できます。(URLは、生成されてから24時間有効です。)
[crayon-6080acfabb3b4030085579/]

補正済み動画のダウンロード

動画のダウンロードはダウンロード用URLに対しGETメソッドでリクエストをします。
動画はファイルサイズが大きくなるため、ダウンロードは1KBのチャンクに分けて複数回書き込むようにしています。

[crayon-6080acfabb3b7973858696/]

動画のブレ補正実行

ここまでで作成した3つの関数を使い、以下のコードで実際にStabilization機能のブレ補正を実行してみました。
今回は、BLOBストレージに保存した動画データを使い、補正された動画をローカルに保存しています。

[crayon-6080acfabb3b9968514437/]
元の動画と補正された動画を比較すると以下のようになります。
効果を確認するために、あえて強くブレが発生するように撮影をしてみましたが、比べるとVideo APIで補正をした動画は機材を使ったようにブレのない、滑らかな動画に変換されていることがわかりました。

[embedyt] http://www.youtube.com/watch?v=PmZ20YrVrUo[/embedyt]

まとめ

今回は、Video APIで動画のブレ補正をしてみましたが、カメラで処理しきれかったブレも滑らかな動画に補正できており、Video APIの性能を実感することができました。
プレビュー版のためか、制限として100MB以下の動画しか対応しないものの、現在は無料で試すことができるため、ちょっとした動画のブレ補正に試してみてはいかがでしょうか。
次回もお楽しみに。