しえログ

qiita との使い分けに悩んでる

CVPR2008 の Object Categorization using Co-Occurence, Location and Appearance メモ

概要

共起性と相対位置という2つのコンテキストを組み合わせて物体を分類する手法を提案。 意味・空間的な関連性に基づき、物体とラベルの対応度合いを最大化するために、系列ラベリング問題を解くための CRF(conditional random field) を利用している。 学習および評価には PASCAL 2007 と MSRC データセットを使用。

手法

Learning Spatial Context

学習というよりかは理解的な意味合いかな?

PASCAL 2007 および MSRC データセットにおけるセグメント化された領域及びその bouding box のラベルを ground truth として利用している。 画像 {I_1,…,I_n} があり、それぞれについて異なるカテゴリ {c_i, c_j \in \cal{C} \mbox{ s.t. } i \ne j } に属する物体が少なくとも2つある。 物体 { i } の bounding box を {\beta_i} とし、 以下のように定義する。

  • ラベル {c_i} の物体に対するラベル {c_j} の物体の重なり度合いのパーセンテージ: { O_{ij} = \frac{\beta_i / \beta_j}{\beta_i} }
  • それぞれの bouding box の重心の y 座標の差: { \mu_{ij} = \mu_{yi} - \mu_{yj} }

x 座標については水平方向の位置関係に意味が見い出せないので特に取り扱わない。 それぞれを3つ組にした空間情報記述子 { F_{ij} = (\mu_{ij}, O_{ij}, O_{ji})^{\mathrm{T}} } の特徴空間を4つのグループにベクトル量子化して俯瞰することで、自前で定義するよりも物体のペア間の関係性がより良い感じにできた。

Contextual Object Categorization Model

どう訳すべきかわからない。状況的物体カテゴリー分別法的な?

大まかな流れは以下の通り。

  1. 入力画像を信頼のおけるセグメンテーション手法でセグメント化する
    • 認識のために改良版 BoF *1と組み合わせる
  2. 各セグメントに対し信頼度に基づきラベル候補を割りあてる
  3. 各セグメントを位置及び物体の共起性による制約のもとで CRF のノードとしてモデル化する
    • ineraction potential {\phi_r(c_i, c_j)} を導入し、 {r = 1,..,4}above, below, inside, around )までの関係性について出現カウントを行列にまとめる
  4. local appearance, contextual agreement および spatial arrangements をもとにそれぞれのセグメントがカテゴリーラベルが与えられる
    • 関係性ごとの出現頻度(物体ごとの出現頻度を含む)を合計することで、最低限の共起性行列を得ることができる
    • 複数のラベルが割り当てられる確率をモデル化し、それを最大化させるような {\phi} を勾配法で探す
    • 数式めんどいから省略・・・

所感

  • 2008年とのこともあってこれまでの state-of-the-art な手法を超えたとはいってても最近はもうすでに何かいいやつ出てきてそう。
  • セグメンテーション手法何使ったのかな、言及してはいない気がする。
    • 書いてあった。Normalized Cut ベースの手法で行ってたみたいですね。
  • 数式もちょいちょい疑問残る箇所あったので機会あったら復習したい。

*1:Does image segmentation improve object categorization? 参照

業務関係者

昼飯は久々にモスバーガー食べた。小学生の頃からチーズバーガーとフィッシュバーガーの計2つと決めているけど、変わらぬ味で未だに飽きがこなくて良い。体重と健康は良くない。

最近は広告にまつわる研究開発で酒飲ませて飯食わせてもらってるわけなんですが、1日のスケジュールがガラリと変わりまして。 これまでは

朝: 開発、昼: 開発、夜: 開発

だったのが

朝: サーベイ、昼: 開発・検証、夜: 論文読み・勉強

と、PC 画面はちょいちょい見つつもキーボードは叩いてない時間のほうが多くなりました。 想像はしてたのですが大学院いた頃とほぼ同じようなスケジュールですね。学生のときは活動開始が昼からだったけど。

想像してなかったことかつツラミといえばこんな異動してすぐのペーペーが社内外のステークホルダーと色々やりとりしつつ進めないと何も始まらないことが多いところ。こっちからしたら向こうはデータ提供者サマという立場なので仲悪くならない程度にこちらの要求を突きつけて行かにゃならないのは何かスキル認定されてもいいと思う。

おまけに胆力低すぎのコミュ障にとってはスラックで話しかけるのも一苦労だし、自分の事前知識が足らないおかげで「えっ」「えっ」みたいなやり取りすることもしばしばで。これまで自分が主体で管理することが多かったパブリッククラウドなどの検証用インフラ環境もいちいち他のグループ上長に許可取らなきゃだったりもらえる権限もアレだったりするのも輪をかけてたりする。まぁここいらはきっとそのうち慣れてくると信じたいが・・・。

研究開発といえば院時代もなんだかんだで最後の修論研究は医療画像システムだった。あのときの外部関係者は病院の心臓外科医の先生1人だった上に発案が向こうだったのでとても気が楽だったなぁ。今の片付いて次の研究に移るとしたらこっちがデータ提供元になったりしての産学連携とかやってみたいぞ。

ECCV2016 の Visual Relationship Detection with Language Priors メモ

ブログでは読んだ論文についても軽くメモっていければいいなとか。 最初はできるだけ読む本数増やしたいのでアブストのまとめを載せるだけで済ますのも多くなりそうだけど所詮自分メモなので悪しからず。


著者

Lu, Cewu and Krishna, Ranjay and Bernstein, Michael and Fei-Fei, Li

概要

  • 物体と述語のより頻繁な共起性をもとにそれらの視覚情報を学習し、それらにおける複数の関係性を予測するモデルを提案した
  • 言語系の先行研究をベースに関連研究を上回る成果を出した
  • 提案モデルは多くの関係性を数少ないサンプルから見つけ出した
  • 関係性を理解することが画像検索の改善に繋がったことを示した

手法

  1. 生画像から R-CNN で物体候補となる bouding box を検出
  2. visual appearance module(中で CNN を利用)と language module (中で word2vec を利用)という2つの提案モジュールでスコアリング
  3. 物体と関係性についてそれぞれのモジュールのパラメータを学習
  4. mAP で評価

所感

ちょろっとしか触れられていないけど訓練データにはない関係性を見つけ出す zero-shot learning も達成してるっぽい。 アルゴリズム擬似コードもありがたく掲載してくれているし自前で簡単な CNN でも組んだら実装してみるのも面白いかもしれない。

最近も頑張って色々やってる

先日超久々にブログを再開するぞ、と意気込んだはいいものの早速1つ前の記事が約20日前になってる。 今年は日記兼ねたこんなポエムも頻度高めに綴っていければいいなぁ。と毎年思ってる気がしなくもない。

早いもので会社で部署異動をしてから2ヶ月が過ぎ去りやがりました。 オフィスに安くて美味しいコーヒー淹れてくれるカフェがあったり自習に困らないぐらいの蔵書のある共有本棚に囲まれて生活できているおかげか新生活にもなんとか慣れてきた気がします。 正直異動だけでここまで周りの雰囲気が変わるとも思ってもいなかったので戸惑わないことも無いのですが会社のイチ歯車という意味ではやることやるだけなのでまぁ頑張っています。

そんなわけで最近やっていることをざっくりと。

  • 機械学習のお勉強
  • 画像処理のお勉強(コンピュータビジョン周り)
  • 統計のお勉強
  • 広告関連のお仕事
  • Python3
  • R

下2つのプログラム言語系以外は現チームメンバーからしたらすべてノービス状態です(正直 R もか・・・。 大学院に在籍していたころになんちゃってでやっていた画像処理周りの数少なすぎる知見のおかげでなんとかチーム内での人権は保てている気がするけど気を抜いたらすぐにやられそう。 サーバエンジニアやってた5年間の貯金も活かせないこともないのでしばらくはお賃金もらえるとは思うけども・・・。

勉強だけじゃなくてちゃんと研究もやりたいし面白い結果も残したいので古今東西の論文ちゃんと読まないとな。 学んだことを実際にコードでシミュレーションしてアウトプットするってのもなるべくやっていく1年にしたい。

安定結婚問題( Gale-Shapley アルゴリズム)

クリスマスだし、有名なマッチングアルゴリズムぐらい書いておこうと思って書いた。

安定結婚問題

安定結婚問題(あんていけっこんもんだい、英: stable marriage problem)とはデイヴィッド・ゲールと ロイド・シャプレイによって1962年に提示された問題である。 安定結婚問題は {\displaystyle n} n人の男性と {\displaystyle k} k人の女性、および、各個人の選好順序からなる。選好順序とは各個人の好みに基づき異性全員と自分自身を全順序で並べたリストである。ここで、「自分自身」とは誰とも結婚せずに独身のままでいることを意味し、「参加者全員が独身であるよりも望ましい相手と結婚している」マッチングは個人合理性(英: individuality rationality)を満たすと定義される。安定結婚問題の解は安定なマッチングである。安定結婚問題に対し、互いに現在組んでいる相手よりも好きであるペア(以下ブロッキングペアとする)が存在せず、全員が個人合理性を満たすマッチングを安定マッチング(英: stable matching)という。

安定結婚問題 - Wikipedia

シミュレーション

python3, numpy でやってみた。 無駄とバグはあるかもしれません。

n 人どうしのマッチングを考慮しており、各行ごとに 0 〜 n-1 をシャッフルした n 次正方行列を ndarray で生成し、ペアとなった結果を表示します。

n次正方行列による優先順位行列を用いて安定結婚問題を解くシミュレーション

結果

4人同士のマッチング

$ python3 gale_shapley.py 4
[[2 1 0 3]
 [0 2 3 1]
 [1 2 3 0]
 [2 0 3 1]]
[[1 2 0 3]
 [1 3 0 2]
 [0 2 3 1]
 [0 2 1 3]]
Engaged  (0, 2)
Engaged  (1, 0)
Engaged  (2, 1)
Already engaged  (0, 2)
Already engaged  (1, 0)
Engaged  (3, 3)
[[0 2]
 [1 0]
 [2 1]
 [3 3]]

5人同士のマッチング

$ python3 gale_shapley.py 5
[[3 4 2 0 1]
 [1 0 4 3 2]
 [0 4 3 1 2]
 [1 4 2 0 3]
 [0 4 2 1 3]]
[[3 2 4 1 0]
 [3 1 2 4 0]
 [2 1 4 0 3]
 [2 1 0 4 3]
 [0 1 3 4 2]]
Engaged  (0, 3)
Engaged  (1, 1)
Engaged  (2, 0)
Already engaged  (1, 1)
Discard  (1, 1)
Engaged  (3, 1)
Already engaged  (2, 0)
Engaged  (4, 4)
Already engaged  (3, 1)
Already engaged  (2, 0)
Already engaged  (4, 4)
Discard  (4, 4)
Engaged  (1, 4)
Already engaged  (2, 0)
Already engaged  (1, 4)
Engaged  (4, 2)
[[0 3]
 [1 4]
 [2 0]
 [3 1]
 [4 2]]

モンティホール問題シミュレーション

Python の勉強も兼ねて投稿。

モンティホール問題

「プレーヤーの前に閉まった3つのドアがあって、1つのドアの後ろには景品の新車が、2つのドアの後ろには、はずれを意味するヤギがいる。プレーヤーは新車のドアを当てると新車がもらえる。プレーヤーが1つのドアを選択した後、司会のモンティが残りのドアのうちヤギがいるドアを開けてヤギを見せる。

ここでプレーヤーは、最初に選んだドアを、残っている開けられていないドアに変更してもよいと言われる。プレーヤーはドアを変更すべきだろうか?」

モンティ・ホール問題 - Wikipedia

シミュレーションコード

実際にシミュレーションしてみる。 コードは Python の3系。

モンティホール問題シミューレション

結果

出力の一例。

$ python3 ./montyhall.py
No change:  0.33271
Change:  0.66709

ドアは変更しましょう。

プログラミングのための確率統計

プログラミングのための確率統計

DataNodeのConfigured Capacity

CDH4.2.0で。

HDFSのWebUIみたり、コマンドラインで
hdfs dfsadmin -report
したときに表示されるDataNodeごとのConfigured Capacity。

どうやら計算方法がdfs.datanode.data.dirに指定したディレクトリそれぞれに対してFile#getTotalSpace()を取得した値の合計をとっているらしい。

なので例えば、本番ではパーティション4つに分けるつもりでhdfs-site.xml設定したとして
それをテスト環境でも使いまわしたいときに同じパーティションに
ディレクトリを4つ作っただけだとConfigured Capacityは本来の4倍のサイズになる。

Used(GB)については単にduした値を合計しているらしく
こちらは本来の利用容量と変わりないため、その他の項目の計算に狂いが出てくる。
当然WebUIのUsed(%)のゲージもおかしくなり、パッと見での判断が辛い。