まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:recognition

IBM Watson の画像認識 API である Visual Recognition を使った類似画像検索サービスを作り、そのソースコードを公開しました:
https://github.com/dotnsf/imageSearchDemo


コードは Node.js で作りました。プロジェクト自体に(著作権フリーな)サンプル画像もいくつか含まれていますが、サンプル画像を置き換えて使うことでご自身が所有している画像を使った類似画像検索サービスにすることも可能です。

また基本的に Watson API は使いやすいものばかりだと思ってますが、このサンプルアプリもその特徴を最大限に活かして、単純に「学習させたい画像を用意すれば動く」ようにしました。細かな実装内容はソースコードを参照ください。


上記 github 上のリポジトリの README.md の中に使い方も(英語で)記載していますが、このブログでは日本語での簡単な使い方とカスタマイズについて紹介します。前提としてログインできる CentOS/RHEL のインスタンスに git と Node.js がインストールされている環境をご用意ください。また最終的なウェブアプリケーションは IBM Bluemix 上で動かすことにします(この場合は cf コマンドもインストールしておいてください)。異なるプラットフォームでも動くと思いますが、適宜読み替えてください。


準備

何はともあれ、IBM Watson の API を利用するためには IBM Bluemix のアカウントが必要です。まだアカウントをお持ちでない場合はトップページの「フリーアカウントを作成」ボタンから 30 日間無料で使えるトライアルアカウントを作成できます:
2017012601


Bluemix のアカウントでログインし、カタログ内 "Watson" カテゴリの "Visual Recognition" を選択して、この API を追加してください:
2017012602


なお作成時に "Free" プランを選択すると1日に 250 API call まで無料で利用できるプランになります。本格的に利用する場合はその下の "Standard" プランを検討ください:
2017012603


Visual Recognition API を作成後に、ダッシュボードから作成した同サービスを選択して、サービス資格情報から資格情報を確認します(なければ追加します)。そして "api_key" の値(下図ではモザイクにしています)がこの後必要になるのでメモしておきます:
2017012604


改めて github からソースコードを用意します。いくつかの方法がありますが、git が使える場合は git clone してください(または zip をダウンロードして展開してください):
$ git clone https://github.com/dotnsf/imageSearchDemo
$ cd imageSearchDemo

ソースコードを展開したディレクトリの直下に settings.js というファイルがあります。この中の exports.vr_apikey の値を先程メモした Visual Recognition API の API Key の値に書き換えて保存してください:
2017012605


他はそのままでも動きます。なお、exports.limit の値(デフォルトだと 5)はウェブアプリケーションで類似画像を検索した結果として、上位いくつまでの結果を表示対象とするかの数値です。学習させる画像の数などにもよりますが、必要に応じて書き換えて使ってください。

最後に、この後の学習時に必要な Node.js のミドルウェア: watson-developer-cloud を npm でインストールしておきます:
$ npm install watson-developer-cloud

この結果、プロジェクトのホームディレクトリ(imageSearchDemo)に node_modules というフォルダが作られていれば watson-developer-cloud の導入に成功したことになり、学習処理が行えるようになります。


画像の学習

最終的には類似画像を検索する仕組みを作りますが、そのためにはあらかじめ検索結果となる画像を学習させておく必要があります(学習させた画像の中から類似画像を探します)。そして学習のためにはある程度の枚数の画像が必要です。

上記ソースコードの public/images/ の中にはサンプルとして著作権フリーな画像が含まれています。これらをそのまま使って学習させることもできますし、手元にある画像で類似画像検索システムを作りたい場合はそれらを使うこともできます(その場合は public/images/ 以下のサンプル画像を全て削除した上で、ご自身の画像をこのフォルダ内に格納してください):
2017012606


そして、以下のコマンドを実行すると public/images/ フォルダ以下にある画像を Watson に学習させます(上記の settings.js ファイルの編集を忘れずに行っておいてください):
$ node learnImages.js
imagelearn_xxxxxx

学習が正しく行われた結果、画面には imagelearn_xxxxxx という文字列が表示されます。これが collection_id と呼ばれるもので、後述の Watson API Explorer などでこの API を実行する際には必要になります。またこのコマンドの実行後に setting.js の最終行に以下のような1行が追加されているはずです:
exports.vr_collection_id = 'imagelearn_xxxxxx';


ウェブアプリケーションとして利用

では学習した内容を使った類似画像検索ウェブアプリケーションを作成します。今回は IBM Bluemix 上のランタイムとして作成するので、SDK for Node.js ランタイムを1インスタンス作成します:
2017012607


アプリケーション名は適当にユニークなものを指定します。この例では dotnsf-imagesearch という名前のランタイムを作っています:
2017012608



合わせてソースコードの manifest.yml ファイルを更新します。具体的には name と host 両方の値を、実際に作成するアプリケーション名と同じものにします:
2017012609


ここまで準備できたらアプリケーションをデプロイします。cf コマンドを使ってログインし、プッシュします:
$ cf login -a http://api.ng.bluemix.net/
   :
   :

$ cf push

しばらくするとアプリケーションの転送とステージングが完了して、ランタイムが起動した旨のメッセージが表示されます:
2017012601


この段階でアプリケーションにアクセス可能です。PCかスマホのブラウザでアプリケーションの URL (上記の例だと http://dotnsf-imagesearch.mybluemix.net/)を指定して開くと、このような画面が表示されます:
2017012601


「参照」ボタンをクリックして、類似画像の対象となる画像を選択します。今回は学習データの中に野球ボールがあったので、それが検索できるかどうかを調べる目的で、学習データとは異なる野球ボール画像を指定してみることにします:
野球ボール


画像を指定すると画面が暗転して、類似画像検索が行われます:
2017012602


しばらくすると結果が得られて画面の暗転が戻ります。画面を下にスクロールすると学習データの中の類似画像候補が指定数(デフォルトでは5)表示されます。一番左に野球ボールが検索できているのがわかります。まあこんな感じのウェブアプリケーションサンプルです:
2017012603


画像を学習する部分は learnImages.js で実装しています。学習時に与えるメタデータ(画像検索の結果と一緒に取得できるテキスト情報)の内容を変更する場合はこのファイルをカスタマイズしてください。またウェブアプリケーション部分は app.js で、そしてウェブアプリケーションの見栄え部分は public/ フォルダ内の index.html に依存しています。見栄えを含めたウェブアプリケーションの挙動の変更はこれらのファイルを自由にカスタマイズしてお使いください(ソースコードは MIT ライセンスで配布しています)。



なお、API Key や collection_id を利用して実際に Visual Recognition API を実行する場合は、こちらの Watson API Explorer をお使いいただくのが便利です。仮に作成した collection_id を一度削除するような場合はこの画面から DELETE を実行いただくことができます:
https://watson-api-explorer.mybluemix.net/apis/visual-recognition-v3

また、Watson Visual Recognition API の関数リファレンスはこちらを参照ください:
https://www.ibm.com/watson/developercloud/visual-recognition/api/v3/



ゆるキャラを画像で検索するサービスを作って公開してみました:
http://yuru.mybluemix.net/

まず最初に、自分はある程度ゆるキャラに詳しいと思っています。積極的な興味というよりは、マンホールに詳しくなっていると、最近はそのマンホールのデザインにゆるキャラが使われることが珍しくなくなってきたので、自然と(?)ゆるキャラにも詳しくなってしまうのでした。。
2017011500
 

さて、ゆるキャラに限らないのですが、イマドキ何かを調べようとした時にはまず『ググる』のが定番です。ただ、それは調べるためのキーワードが分かっている場合です。ゆるキャラの場合、名前が分かっていれば名前でググれば確実ですし、名前が分からなくても出身地とかが分かれば「ゆるキャラ 東京都」などで検索すればいくつか候補が見つかるのでそこから調べる方法もあります。

しかし問題は名前も出身地も分からず、検索するためのキーワードがない場合です。例えば目の前に着ぐるみそのゆるキャラ本体がいて、写真は撮れるんだけど、そのゆるキャラがなんという名前で、どこのゆるキャラで、どんな特徴を持っているのか、、、といった情報を調べる具体的な方法がなかったように感じていました。

といった背景もあり、「画像からゆるキャラを調べる」ことができるようなウェブサービスを作ってみた、という経緯です。いわゆる「類似画像検索」を行うため、コグニティブエンジンである IBM WatsonVisual Recognition API を使って実装してみました:
http://yuru.mybluemix.net/


使い方はシンプルで、ウェブサイトをPCかスマホのブラウザで開き、ファイル選択ボタンを押して、ローカルシステムやフォトライブラリ等から目的の画像を選択するだけです:
2017011501


PC の場合に限り、目的の画像ファイルを画面上部のこの辺りにドラッグ&ドロップしても構いません:
2017011502


例えばこの画像のゆるキャラを調べてみることにしました。まあ有名なヒトなので答はわかっているのですが、ちょっとトリッキーなアイテムも写っていて普段と違う画像になっているので、いいサンプルかな、と:
く


この画像を選択するか、画面内にドラッグ&ドロップすると画面が暗転して検索が始まります:
2017011503


暗転から戻ると、検索結果として候補キャラが画面下部に表示されているはずです。最大で100件表示されます:
2017011504


今回の画像の場合、下の方にそれっぽいのが見つかりました:
2017011505


該当する結果の画像をクリックすると、そのゆるキャラの情報がポップアップします。ご存知「くまモン」でした。なお PC であればマウスオーバーでも表示されます:
2017011506


まだまだ学習量が充分ではなく、第一候補となることはまだ珍しいとか、(着ぐるみの写真ではなく)絵の場合には精度が落ちるとか、横から写した画像に弱いとか、背景画像に左右されることが多いとか、まだまだ問題はありますが、一応動くものが作れたと思ってます。

実際の用途としてはある程度いけるかな、と思ってます。もちろん精度高く検索できることが理想ですが、上記で書いたように「名前が分かれば色々調べる方法はあるんだけど、肝心の名前が出てこない」のを解決するツールとして考えると、検索結果の候補の中に含まれていれば、それはそれでオッケーかな、と。


なお、今回のサービスは Visual Recognition の中では現時点でベータ版の /v3/collections/ で始まる API を使って開発しています。今後の仕様変更などがあった場合にサービスがどうなるか何とも言えませんが、なるべく対応させていく予定です。合わせてもう少し学習データの量を増やして検索精度を上げられないか、がんばってみます。


JavaScript で AJAX を多く使ったことがある人にとって、「クロスドメイン問題」は一度は体験する、避けて通れない問題だと思います。

簡単に補足すると、例えば異なる aaa.com と bbb.net という2つのドメイン間で AJAX の実行を許可しない、という問題です。以下の例では aaa.com ドメイン内に www.aaa.com というアプリケーションサーバーと、api.aaa.com という API サーバーがあり、bbb.net というドメイン内に api.bbb.net という API サーバーがあることを想定しています。www.aaa.com と api.aaa.com は同一ドメインなので、何の制約もなく AJAX で API を実行できるのですが、ドメインの異なる api.bbb.net に用意された API を www.aaa.net から AJAX で実行しようとすると、このクロスドメイン問題の制約に引っかかって実行できない、というものです:
2016121303

ちなみにこのクロスドメインの制約はあくまで「ウェブブラウザの制約」です。ドメインをまたいだ API を実行するような JavaScript はウェブブラウザが許可しない、という意味です。なので、例えば www.aaa.com 上の Java アプリケーションや PHP アプリケーション、はたまたサーバーサイド JavaScript である Node.js アプリケーションなどから api.bbb.net 上の API を実行する、という場合は何の制約もなく動きます。

またこの問題は api.bbb.net 側で「他のドメインからの AJAX 実行を許可する」という設定をしておけば回避することができます。具体的には API サーバーの HTTP レスポンスヘッダに Access-Control-Allow-Origin を含めるようにして、そこに "*"(どこからでも許可する)とか "*.aaa.com" (aaa.com からのリクエストは許可する)とかいった値が返されるような設定になっていれば使える、ということです(つまり API 側で許可するよう設定されている必要があります):
2016121304


さて、先日 curl で IBM WatsonVisual Recognition API (画像認識 API)を使っていてふと気付いたことがあります。curl は -i オプションを使うと HTTP レスポンスヘッダが表示されるようになるので、これを ON にしてデバッグしていました・・・:
2016121301


ん??
2016121302


上記で説明した "Access-Control-Allow-Origin" が HTTP レスポンスヘッダに含まれてます。しかも値が * ということは、この API はどこからでも AJAX で呼べるということ!?

以前にこの記事を作ってた頃は、このヘッダはなかったと記憶してる(Chrome Extension なので回避できている、という認識でした)。いつ仕様が変わったんだろ・・・

試しに、curl で実行したのと同様の Visual Recognition API を実行する HTML ファイルを作ってみました(実行する場合、ソースコード内の (APIKEY) 部分は自分の Visual Recognition API サービスインスタンスの API キーを指定してください:
<html>
<head>
<title>DHTML</title>
<script src="https://code.jquery.com/jquery-2.0.3.min.js"></script>
<script>
function classify(){
  var imgurl = $('#imgurl').val();
  var url = "https://gateway-a.watsonplatform.net/visual-recognition/api/v3/classify?api_key=(APIKEY)&version=2016-05-20&url=" + encodeURI( imgurl );
  $.ajax({
    type: "GET",
    url: url,
    success: function( data ){
      var html = "<img src=\"" + imgurl + "\"/><br/><table border=\"1\">";
      var classes = data.images[0].classifiers[0].classes;
      for( i = 0; i < classes.length; i ++ ){
        var obj = classes[i];
        var class_name = obj['class'];
        var class_score = obj['score'];
        html += ( "<tr><td>" + class_name + "</td><td>" + class_score + "</td></tr>" );
      }
      html += "</table>";
      $('#result').html( html );
    },
    error: function( XMLHttpRequest, textStatus, errorThrown ){
      console.log( "error: " + textStatus );
    }
  });
}
</script>
</head>
<body>
<input type="text" name="imgurl" id="imgurl" value=""/>
<input type="button" value="classify" onClick="classify();"/>
<hr/>
<div id="result"></div>
</body>
</html>

これをウェブブラウザからローカルファイル扱いで開き(URL は file:/// で始まる)、画像 URL をテキストボックスに入れて classify ボタンをクリックします。すると・・・
2016121305


↑ 全く異なるドメイン(というかローカルファイルシステム)からの HTTP リクエストであるにも関わらず、AJAX 内で呼び出している Visual Recognition API が正しく実行され、画像認識結果を表示することができました。こりゃ便利!

IBM Bluemix を通じて提供されている Watson API の1つ Visual Recognition(画像認識) API に「類似イメージ検索」というベータ版の新機能が追加されました:
https://new-console.ng.bluemix.net/catalog/services/visual-recognition/


2016101101


この API はその名の通り、「ある画像に似た画像を(あらかじめ登録しておいた画像群の中から)探す」というものです。個々の REST API としては画像の登録や削除、そして類似検索といった機能が用意されており、それらを組み合わせて実装することになります。また他の Watson API 同様、検索した結果に対してはスコアという検索結果に対する自信の数値根拠が合わせて返される、という特徴があります。


またこの類似画像検索 API のデモサイトも公開されています。選択した画像に似た画像が表示される、というものです。一度使ってみると、どういったことが可能になるのか、というイメージが付きやすくなると思います:
https://similarity-search-demo.mybluemix.net/

2016101201


このブログは公私混同を売りにしている(笑)こともあるので、実際に自分のサービスを使って試してみた様子を以下に紹介します。自分の場合は(お約束ですが)マンホールマップの画像を使わせていただきました。複数の種類のマンホール画像をあらかじめ登録しておいて、後から登録していないマンホール画像を指定して類似検索した時に同じ絵柄のマンホールを見つけることができるかどうか!? という挑戦です。

実はこの挑戦はかなりハードルの高い挑戦でもあります。なぜなら「単にマンホールとして認識」されてしまうと、登録画像は全てマンホールなので「似た絵柄のマンホール」を探すことができないと思われるからです。またマンホールの外側にある部分の類似性は無視してほしいわけですが、その辺りの所、ワトソンはどうなのよ!? ということを確認するための実験的要素の強い作業です。

なおこちらのページのマンホール画像はあらかじめ登録しておく画像の1つとしています:
2016101202


詳しくは API Reference を参照いただきたいのですが、あらかじめ画像を登録する際には画像データに加えて、JSON 形式のメタデータファイルを用意する必要があります。このメタデータに登録された内容は検索結果に含まれて返されることになるものです。そのため ID や作成日時、作成ユーザーといった情報をこのメタデータに加えておくと、画像検索した結果から作成ユーザー情報まで取り出す、ということも可能になります。

今回は登録するデータとしてこの画像と、



画像に加えて、こんな内容のメタデータを用意しておきました:
{
  "id":120002,
  "username":"morimo_t",
  "created":"2010-08-17 22:03:26",
  "text":"川崎市の色蓋。よく通る道路だったのにはじめて気がつきました。",
  "address":"神奈川県川崎市幸区堀川町",
  "lat":35.53229904174805,
  "lng":139.697998046875,
  "nice":5
}

↑細かい説明は省きますが、画像検索した結果にこの画像が含まれていた場合に、これらのメタデータと合わせて結果が取得できる、というためのものです(なのでメタデータが不要であれば空オブジェクトでも構いません)。このように画像とメタデータの組み合わせを登録する画像全てに対して用意しておきます。

実際に画像を登録する前にいくつか準備が必要です。まず当たりまえですが、IBM Bluemix にログインし、Visual Recognition サービスを追加しておきます:
2016101203


サービス追加後、「サービス資格情報」の「資格情報の表示」を選択して、認証情報の "api_key" の値を確認しておいてください(この後で使います):
2016101204


ここからは curl を使って REST API を実行するので、Linux か Mac のユーザーはターミナルを開いてください。Windows ユーザーの場合、curl は別途インストールする必要があります。以下のサイトから環境にあった Windows 用 curl をダウンロードし、インストールしてください:
https://curl.haxx.se/download.html

2016101205


curl コマンドを使う準備ができたら実際に REST API を実行してみましょう。画像を登録するにはまず入れ物(「コレクション」といいます)を用意します。ちなみに類似画像検索はこのコレクション単位で実行して、回答を取得することになります。上記デモサイトのようにショッピング用の商品画像から類似画像を探す、という使い方であれば商品の画像を登録するコレクションを作って、そこに商品画像をまとめて登録して検索する、という使い方をすることになります。

今回は「類似マンホール検索」が目的なので、マンホール画像だけを登録するコレクションをあらかじめ作っておくことにします(そしてそこにはマンホール画像以外は登録しないようにします)。新たにコレクションを作成するにはこの REST API を実行します:
# curl -X POST -F "name=XXXXXXXX" "https://gateway-a.watsonplatform.net/visual-recgnition/api/v3/collections?api_key=(apy_key)&version=2016-05-20"

メソッドは POST で、マルチパートフォームデータとして name パラメータでコレクションの名前(上の例では "XXXXXXXX")を指定します。また URL パラメータで Visual Recognition サービスを参照して確認した api_key と、version("2016-05-20")を指定して実行します。

この実行が成功すると、指定した名前のコレクションが作成され、以下のような実行結果 JSON が返ってきます:
{
  "collection_id": "XXXXXXXX_xxxxxx",
  "name": "XXXXXXXX",
  "status": "available",
  "created": "2016-10-11T05:58:47.129Z",
  "images": 0,
  "capacity": 1000000
}

"name" に指定したコレクション名が入っていて、その名称に "_xxxxxx" という形式が付いた "collection_id" が得られているはずです。この後からはこの collection_id を使って API を実行するので、この値をメモしておきましょう。またこのコレクションには現在 0 枚の画像が登録されており("images" の値)、最大で 1000000 枚の画像が登録できる、という状態になっているようです。

では入れ物ができたので、この入れ物に画像を登録します。画像ファイル名が image.png、対応するメタファイル名が image.json である場合、以下の API を実行します:
# curl -X POST -F "image_file=@image.png" -F "metadata=@image.json" "https://gateway-a.watsonplatform.net/visual-recgnition/api/v3/collections/XXXXXXXX_xxxxxx/images?api_key=(apy_key)&version=2016-05-20"

マルチパートフォームデータで画像ファイルとメタデータファイルを POST メソッドで送り、URL パラメータの中で collection_id を指定しています。この API の実行が成功すると、このような JSON が返ってきます:
{
  "images": [
    {
      "image_id": "mmmmmm",
      "image_file": "image.png",
      "created": "2016-10-11T16:12:16.435Z",
      "metadata": {
        "id":120002,
        "username":"morimo_t",
        "created":"2010-08-17 22:03:26",
        "text":"川崎市の色蓋。よく通る道路だったのにはじめて気がつきました。",
        "address":"神奈川県川崎市幸区堀川町",
        "lat":35.53229904174805,
        "lng":139.697998046875,
        "nice":5
      }
    }
  ],
  "images_processed": 1
}

実行結果として image_id などが生成されています。また metadata の中身は指定してメタデータファイルの中身になっているはずです。

この時点でコレクションの状態を確認してみることにします。コレクションの状態を確認するにはこの APIを実行します:
# curl "https://gateway-a.watsonplatform.net/visual-recgnition/api/v3/collections/XXXXXXXX_xxxxxx?api_key=(apy_key)&version=2016-05-20"

実行が成功すると、以下のような JSON が返ってきます。画像が1つ登録されたので "images" の値が 0 から 1 に変化しています:
{
  "collection_id": "XXXXXXXX_xxxxxx",
  "name": "XXXXXXXX",
  "status": "available",
  "created": "2016-10-11T05:58:47.129Z",
  "images": 1,
  "capacity": 1000000
}

こんな調子であらかじめ登録しておく画像(=検索対象となる画像)をすべて登録しておきます。なお、コレクションに追加できる画像は(API Reference によると) 2MB 以内にするべきとのこと。また1つのコレクションに 1000000 (100万)画像まで登録できることになっていますが、1つのファイルを登録するのに仮に1秒かかるとすると、100 万画像で 100 万秒、つまりノンストップで行っても約 11.5 日かかる計算になります。派手に使う場合は準備に2週間~程度かかる、という心づもりが必要になりますね。

全ての画像が登録されたら、最後に類似画像認識を実行してみます。今回はこの画像を検索してみました(この画像はコレクションには登録していません):



↑上記で紹介した登録画像と同じ絵柄のマンホール画像です。この画像を search.png として保存し、以下の REST API を実行します:
# curl -X POST -F "image_file=@search.png" "https://gateway-a.watsonplatform.net/visual-recgnition/api/v3/collections/XXXXXXXX_xxxxxx/find_similar?api_key=(apy_key)&version=2016-05-20&limit=5"

collection_id を指定して、マルチパートフォームデータが画像ファイルを POST 送信しています。またこの例では URL パラメータに limit=5 を指定して、類似度の上位5つまでを取得するように指示しています。

この API が正しく実行されると、以下のような結果が取得できます:
{
  "image_file": "5137462154683827112.png",
  "similar_images": [
    {
      "image_id": "2f98c6",
      "image_file": "120002.png",
      "score": 0.7548828,
      "created": "2016-10-11T15:22:25.824Z",
      "metadata": {
        "address": "神奈川県川崎市幸区堀川町",
        "created": "2010-08-17 22:03:26",
        "id": 120002,
        "lat": 35.53229904174805,
        "lng": 139.697998046875,
        "nice": 5,
        "text": "川崎市の色蓋。よく通る道路だったのにはじめて気がつきました。€‚",
        "username": "morimo_t"
      }
    },
    {
      "image_id": "d20e86",
      "image_file": "804002.png",
      "score": 0.7416992,
      "created": "2016-10-11T15:59:02.442Z",
      "metadata": {
        "id": 804002,
           :
           :
      }
    },
    {
      "image_id": "b6f1e7",
      "image_file": "1594034.png",
      "score": 0.74121094,
      "created": "2016-10-11T15:17:22.733Z",
      "metadata": {
        "id": 1.594034e+06,
           :
           :
      }
    },
    {
      "image_id": "f0bb1f",
      "image_file": "1888484723171738767.png",
      "score": 0.73828125,
      "created": "2016-10-11T15:31:14.768Z",
      "metadata": {
        "id": 1.888484723171739e+18,
           :
           :
      }
    },
    {
      "image_id": "9f72ed",
      "image_file": "90003.png",
      "score": 0.72998047,
      "created": "2016-10-11T15:31:21.935Z",
      "metadata": {
        "id": 90003,
           :
           :
      }
    }
  ],
  "images_processed": 1
}

この形式だとわかりにくいので、実行結果を表&画像にしてみました:
#画像スコア
10.7548828
20.7416992
30.74121094
40.73828125
50.72998047


なんとも評価の難しい結果になりました。まず1位は期待通りに、事前に登録しておいた同じ絵柄のマンホールを取得することができました!これは素晴らしい!! そして問題は2位以下です。これらはマンホールの絵柄としては明らかに異なり、「類似画像」としてはふさわしくないのですが、そのスコアが1位の画像と大差ない、という結果になりました。

まず今回登録した画像には正解(というか、同じ絵柄のマンホール)が1つしかないので、それが1位になってることは評価に値すると思っています。ただ間違いである2位との差がほとんどないというのも実は厄介で、「似た画像はこの1つだけです」という判断をさせたり、正解が1個もないような検索時に「似た画像はありません」という判断をするのが難しくなってしまうのでした。うーむ・・・

一方で、今回は 500 枚のマンホール画像を事前に登録したのですが、この枚数が少なすぎた可能性はありますね。

とはいえ、最初に触れているように、今回の検証は「マンホールの絵柄の類似性を確認できるか?」というかなりハードルの高い検証をしたつもりでしたが、ある程度は判断できているようにも見えます。今後は登録画像枚数も増やした上で再度色んなパターンで検証することになると思ってます。



なお、この類似画像検索 API の詳細については API Reference を参照ください:
http://www.ibm.com/watson/developercloud/visual-recognition/api/v3/#collections


昨年末、マンホールマップIBM Watson の画像認識機能を組み込んだ、という記事を紹介しました:
マンホールマップに画像認識機能を組み込む

この記事を作成した当時、Visual Recognition(画像認識)の API は V2 というバージョンでしたが、その後のバージョンアップで V3 になりました。ただその時点では V2 もしばらく使えるということだったのでマンホールマップ側は放っておいたのですが、いつの間にか V2 は使えなくなっており、マンホールマップの画像認識機能が動かなくなってしまっていました(要するに僕の手抜きでした、失礼しました)。

改めて V3 に対応させようとして、上記リンク先で紹介したような手順でマンホール画像の学習をさせて・・・と思っていたら信じられないことが!!!

上記リンク先ページ内でも説明しているのですが、もともと IBM Watson の画像認識サービスでは「マンホール」を識別する機能(正確には classifier)がありませんでした。そのため(自分でカスタマイズする classifier に)「マンホール画像を学習」させて、「その上で(自分でカスタマイズした classifier を使って)マンホール識別」を行う、という手順が必要になり、その内容を紹介したのが上記リンク先ページでした。

が、今回 V3 を試してみて気付いたのは「バージョン V3 では始めからマンホールが識別できるようになっている!」ということです。要するに学習などのカスタマイズを行うまでもなく、標準機能としてマンホールが識別対象として登録されていたのでした。ワトソンに何が起こったのか・・・


・・・唯一思い当たる節があるとすれば、私ですw σ(^^; 先程から紹介しているように、V2 の頃にマンホールを学習させ、識別機能をマンホールマップに組み込みました。マンホールマップはそこそこ(苦笑)のアクセス数を誇る位置情報付きマンホール情報サイトであり、マンホール情報ページへのアクセスがある度に画像認識の識別 API が実行され、そしてその多くは「マンホール」として認識されていたはずでした。要するに「マンホール」と認識されるアクセスがワトソン側にもそこそこあったはずなのです。元々の機能ではマンホールを対象としていなかったはずなのですが、カスタマイズされた結果のマンホールがそれだけの人気があったとすると・・・ と都合よく妄想しただけですが、可能性がないとは言い切れないではないですかっ!


というわけで、現在のマンホールマップでは V3 に対応した識別機能が復活しています。そしてこのマンホール識別はワトソンの標準識別対象になっているものをそのまま使っている、ということを付け加えておきます。
2016090601


マンホールマップ(PC版)
マンホールマップ(スマホ版)


このページのトップヘ