ターミナルでの炎上のさせ方

f:id:sugyan:20170809005307p:plain

話題になってたコレが面白いなーと思って

ターミナル上でそれっぽく再現させてみた。 こんなかんじ。

f:id:sugyan:20170809005416g:plain

(これの作成は以前に作ったttyrecからGIFアニ生成やつ にて) memo.sugyan.com

そんなに細かくなくても大丈夫であればターミナルの縦横のマスでもできそうだなーと思って 256色のターミナルなら黒→赤→黄→白の間でも12段階くらいの変化が出せるので

描画系はtermbox-goを使えば簡単に出来た。色はRGBでは指定できなそうだったのでカラーコードを直指定で。 github.com

いちおう最下段の値、ノイズの載せ方を少し工夫した。

最下段は前のコマからの差分が大きくなりすぎないように変化量を制限。 あとどうしてもチラつきやすいので1段分余計に計算して、下から2段目以降を表示に使用。

ノイズは各セルに一定範囲で加減するが、上に行くに従って少しずつ暗くなるように期待値が僅かに負の値になるような乱数に。

とりあえずはこれで何となく炎っぽい動きになった、かな? 最下段の値の変化のさせ方をもっと時系列に滑らかにするともう少し良くなりそうな気はする。

色のパターンを変えるだけでこういうのも作れて面白い

f:id:sugyan:20170809011031p:plain

builderscon tokyo 2017 に参加した

builderscon.io

昨年は不参加だったので、今年が初参加。

https://scontent-nrt1-1.cdninstagram.com/t51.2885-15/e35/20481806_1195358713934417_200836583476166656_n.jpg

話した

折角なので何か話してみよう、と応募したところ無事に通ったので、以下のセッションでトークをさせていただきました。

DeepLearningによるアイドル顔識別を支える技術 - builderscon tokyo 2017

資料はこちら。

speakerdeck.com


基本的にはこのブログに書いてきたことのまとめ的な内容で、今まで他の勉強会とかでもちょいちょい話していたし 自分的にはあまり新しい内容もなくてアレかなぁ…という感じもあったけど、 さすがにこれくらいの規模のカンファレンスだと僕のことをまったく知らない人も聴きに来て下さっていたようで。

そんな方々に少しでも「知らなかった、を聞く」を提供できていたら何よりです。


個人的には1時間枠で喋るというのが初めてだったので、当然緊張したし時間配分的なものも難しくて大変でした。 とりあえず誰か1人にでも「すごい」って思えてもらえたら嬉しいな、くらいの気持ちで挑んだ。 時間に余裕があったおかげで少しデモで実際に動いてるものや画面などを見せながら出来たので良かったかな、と思います。


初日最初の枠で発表おわったので気持ちに余裕が出来たので、枠が空いてるようならLTも飛び込んでしまえ、と 午後から申し込んだ。

speakerdeck.com

作ったもの自体は TOKYO IDOL FESTIVAL 2016 のタイムテーブル画像化ツールを作った - すぎゃーんメモ のものの使い回しだけど、今年は予想以上に多くの人たちに使ってもらえて嬉しかったので自慢したかった。ただそれだけです。@さんがタイムテーブルネタで被るよう順番を組んでくれたおかげでタイトルだけで出落ちの笑いが取れて良かったです。

聞いた

前夜祭は内容については口外NGということで「面白かった」としか書けないけど、良い企画でした。

本編では 幾つか聞いた中で特に面白かったのは以下の3つ。

builderscon.io

builderscon.io

builderscon.io


横山三国志は完全にネタな内容なのに(人のこと言えないけど) たくさんの工夫や応用のアイデアが詰め込まれていて、とても面白かった。

階差機関、HADOのあたりは本当にまったく触れたことも無いような世界の話だったので、まさに「知らなかった、を聞く」ことが出来たトークでした。 こういう 特定の技術やプログラミング言語のコミュニティだけではなかなか出会えなそうな話に触れられたのはとても良かったと思います。


他にも気になっていたけど聴きに行けなかったトークも幾つかあるので、後で資料を拝見して追いかけたいと思います。

楽しかった

こういう大きめのカンファレンスに参加するのも久しぶりだったので、懇親会などで久々の方とかと会えたり また初めましての方ともご挨拶してお話できて、とても楽しかったです。

運営スタッフの皆様、素晴らしいトークをして下さった方々、聴いて下さった方々、ありがとうございました!

「TensorFlowはじめました2」を読んだ

TensorFlowはじめました2 機械学習で超解像─Super Resolution (NextPublishing)

TensorFlowはじめました2 機械学習で超解像─Super Resolution (NextPublishing)

「TensorFlowはじめました」を読んだ - すぎゃーんメモ で読ませていただいた「TensorFlowはじめました」の第2弾。

今回はレビュアーとして声をかけていただき、微力ながら協力させていただきました。有山さん、ありがとうございます!!

最初の第1章ではTensorFlowの基礎、データフローグラフの概念などが前作同様に丁寧に解説されていて、TensorFlowに触れたことがない/前作を読んでいない方でも問題なく入りこめるようになっていると思います。

第2章以降の、今作のテーマである「超解像」については私自身はまだ触れたことがなかったので勉強になりました。

第3章では今回も奮闘記となっており「予想に反し上手くいかない」「原因を推察する」「改善し試してみる」という過程がとても丁寧に書かれていて、とても面白いです。

第4章ではさらに踏み込んで質を向上させるための実験、評価についても触れていて、こちらも大変勉強になりました。

今回も参考文献に私の「すぎゃーんメモ」も載せていただいていて、光栄であります。最近あまり何も書けていないので頑張らねば。。。

KarabinerからHammerspoonへ

そろそろ新しいMacBook欲しい… けど El Capitan から Sierra になるとKarabinerが使えなくなるって話だし… とか色々不安があり躊躇していた。 代替、というかちゃんと設定すれば代替できそうなHammerspoonが良さげだったので それを使ってKarabinerからの脱却を試みてみた。

Hammerspoon

www.hammerspoon.org

Mac OSの様々な操作を自動化するためのツールで、ユーザがLuaスクリプトで設定を書くことでOSの様々な機能を使えるようにブリッジしてくれる。

Key Remap

基本的に 以下の記事のコピペで大丈夫そう。

qiita.com

自分は以下のように書いた。

local function keyStroke(mods, key)
  return function() hs.eventtap.keyStroke(mods, key, 0) end
end

local function remap(mods, key, fn)
  return hs.hotkey.bind(mods, key, fn, nil, fn)
end

-- global
remap({'ctrl'}, 'h', keyStroke({}, 'delete'))
remap({'ctrl'}, '[', keyStroke({}, 'escape'))
remap({'ctrl'}, 'j', keyStroke({}, 'return'))
remap({'ctrl', 'cmd'}, 'j', keyStroke({'cmd'}, 'return'))

-- disable when a specific application is active
local remapKeys = {
  remap({'ctrl'}, 'b', keyStroke({}, 'left')),
  remap({'ctrl'}, 'f', keyStroke({}, 'right')),
  remap({'ctrl'}, 'n', keyStroke({}, 'down')),
  remap({'ctrl'}, 'p', keyStroke({}, 'up')),
  remap({'ctrl'}, 'y', keyStroke({'cmd'}, 'v'))
}

local function handleGlobalAppEvent(name, event, app)
  if event == hs.application.watcher.activated then
    if name == 'iTerm2' or name == 'Code' then
      for i, key in ipairs(remapKeys) do
        key:disable()
      end
    else
      for i, key in ipairs(remapKeys) do
        key:enable()
      end
    end
  end
end

appsWatcher = hs.application.watcher.new(handleGlobalAppEvent)
appsWatcher:start()

hs.hotkey.bindで指定したキー操作時の振る舞いを指定できるので、hs.eventtap.keyStrokeで置き換えたいキー操作を指定してそれをemitさせるfunctionをセットする。pressedfn, releasedfn, repeatfnと3種類の振る舞いを定義できるので注意。リマップは基本的にpressedfn, repeatfnを同じkeyStrokeを起こすfunctionにしておけば良さそう。

あと上述記事にもある通りiTermやVSCodeなどのターミナルやエディタではそれぞれ独自にキーバインド設定できたりするし リマップによる変換があると逆にそれが災いして期待した動作にならなかったりするので、applicationの切り替え時にイベントを取得してdisable()/enable()するように。

別にすべてのリマップを無効にする必要は無かったりもするので、常に有効にしておきたいものとは別に切り替え対象のリマップのkeybindだけを保持しておいて それらだけを有効化/無効化の対象にした。

Sticky Shift

Karabinerでもう一つお世話になっていたのが、所謂sticky-shift的なものをセミコロン;で行う、というもの。

セミコロン;を押した後にキーを押す、という操作でShiftキー押しながらの操作を代替する。(別に使うのはセミコロンじゃなくてもいいのだけど 最も一般的なのがこれ、なのかな)

openlab.ring.gr.jp

AquaSKKを使っていると変換位置の指定の際にShiftキーを多用することになりつらいので、ずっとこの方法にお世話になっていたし、すっかりそれに慣れてしまっていた。

Karabinerでは AquaSKK で ; (セミコロン) を Sticky Shift に使う - Qiita のように設定して使っていたのだけど、これもHammerspoonでどうにか。

local stickyShift = false
local targets = {}
for i = 96, 122 do
  targets[hs.keycodes.map[string.char(i)]] = true
end

hs.hotkey.bind({}, ';', function()
  if hs.keycodes.currentMethod():find('AquaSKK') then
    stickyShift = true
  else
    hs.eventtap.keyStrokes(';')
  end
end)

keyTap = hs.eventtap.new({hs.eventtap.event.types.keyDown}, function(event)
  if stickyShift and targets[event:getKeyCode()] then
    event:setFlags({shift = true})
  end
  stickyShift = false
end):start()

stickyShiftという変数を持っておいて、入力ソースがAquaSKKのときに;が押されたらフラグを立てる。それ以外のときは普通にそのまま;keyStrokeをemitするだけ。

keyDownイベントを監視し、stickyShiftフラグが立っていて かつtargetのkeyCode(母音と主な子音だけで良いのだけど とりあえず全アルファベットを対象にしている)だったら、setFlagsを使ってshiftが押されている状態にイベントを書き換える。stickyShiftフラグは継続させる必要ないので強制的にfalseに戻す。

これで今まで通りに;を使ったsticky-shiftでの日本語入力ができるようになった。

ひらがなモードのときだけフラグを変えて ASCIIモードなら;はそのまま通す、とかも出来れば良いのだけど、入力ソースの判別までは出来ても 現在の入力モードが何か、までは取る方法が分からなかった(無い?)ので;を普通に打ちたい場合は普通に英字入力に切り替えるしかない。 まぁこれはKarabinerのときもそうだったし仕方ない。

あと どういうわけか、SierraだとVisual Studio Code上でAquaSKKがまったく効かなくて、ひらがなモードに入ることすらできないようだ。キー設定とかそういう問題じゃなさそうで どうにもならないんだけど、、他の人は普通に使えているのだろうか…?

まぁVSCodeはコード書くものだし日本語の文章書きたいときは他のアプリケーションを使えばいいか…ということで割り切る(この記事の下書きはAtomで書いてる)。

Launcher

あとよく使っていたのがhotkeyでのアプリ切り替え。cmd+ctrl+左手で打てるキー の組み合わせでターミナル/エディタ/ブラウザ/チャット/ツイッター などをサクサク切り替えたくて 以前はSlatePhoenix、もしくは有料アプリのShortcutsなんかを使っていたりもしたけど、これもHammerspoonで解決できるようになったのでLauncherアプリは不要になった。

local function launcher(mods, key, appname)
  hs.hotkey.bind(mods, key, function()
    hs.application.launchOrFocus('/Applications/' .. appname .. '.app')
  end)
end

launcher({'cmd', 'ctrl'}, 'q', 'iTerm')
launcher({'cmd', 'ctrl'}, 'w', 'Visual Studio Code')
launcher({'cmd', 'ctrl'}, 'e', 'Google Chrome')
launcher({'cmd', 'ctrl'}, 't', 'Twitter')
launcher({'cmd', 'ctrl'}, 's', 'Slack')

Key Repeat

あとそういえばkarabinerで便利だったのがキーリピート間隔の設定だったのだけど、 システム環境設定での設定可能範囲を超える場合はdefaultsコマンドで設定すれば良いだけ、というのをググって知ったので 問題なかった。

$ defaults write -globalDomain KeyRepeat -int 1
$ defaults write -globalDomain InitialKeyRepeat -int 10

とかやって再起動すれば反映される(システム環境設定での変更ではKeyRepeat2InitialKeyRepeat15が最小値っぽい)

雑感

とりあえずKarabinerが無くても困らない程度の設定は出来たっぽい。他にもカスタマイズしたければinit.luaを頑張って書けば色々できそうではある。

しかしまぁKarabinerがSierraでも動いてくれるのが何よりだし このHammerspoonだって いつまたMac OSの変化で使えなくなってしまうか分からないし

こうしてMacの変更に振り回されて色々と苦労しないといかんのはどうにからならないもんかなぁ、と思ってしまう

Google Code Jam 2017: Qualification Round

プログラミングコンテスト Google Code Jam

以前にAOJを始めた ものの 情けないことに結局2週間くらいで止まってしまい、それ以来ずっとこれ系からは離れてしまっていたけど、Code Jamは何故か毎年チャレンジしている(毎回すぐ予選落ちしてるけど)ので、今年も挑戦してみた。

Qualification Roundは27時間のオンライン予選。その時間中に4問のうち幾つかを解いて25pt以上獲得すれば次に進める、というもの。

土曜の夜に時間を見つけて取り組んでみた。 C++でやりたかったけど、色々と思い出せる気がしなかったので全部Rubyでやった。

A. Oversized Pancake Flipper

長さSのパンケーキ列を与えられて、長さKのflipperを使ってすべてを表面にするための最低操作回数、もしくは不可能であるか、を求める

sample input:

3
---+-++- 3
+++++ 4
-+-+- 4

sample output:

Case #1: 3
Case #2: 0
Case #3: IMPOSSIBLE

とにかく端から順番に見ていって、裏(-)があればそこを起点にK個ひっくり返しカウントし、逆端まで到達する位置まで行ったら最後に全部表(+)になっているかどうか判定すれば答えは出せるはず、ループ回数もせいぜいS * Kでたいしたことない。

こんな感じで

t = gets.to_i
t.times do |i|
  s, k = gets.split(' ')
  s = s.split('').map { |c| c == '+' }
  a = 0
  (s.size - k.to_i + 1).times do |m|
    next if s[m]
    k.to_i.times do |n|
      s[m + n] = !s[m + n]
    end
    a += 1
  end
  ok = true
  k.to_i.times do |m|
    next if s[s.size - m - 1]
    ok = false
    break
  end
  puts "Case ##{i + 1}: #{ok ? a : 'IMPOSSIBLE'}"
end

普通にrangeを書いてeachを使うべきか…?

B. Tidy Numbers

与えられたN以下の数のうち最大の、「数字が左から昇順に並ぶ数」を求める。

sample input:

4
132
1000
7
111111111111111110

sample output:

Case #1: 129
Case #2: 999
Case #3: 7
Case #4: 99999999999999999

Nからスタートして順番にデクリメントしていって一つ一つ昇順になっているかどうか判定していってもいいけど、そうすると10^18になるlarge datasetで詰むのは目に見えている。

もう最初から数値だと思わずに、法則に従う数字の列だと思って操作していけばいいか、と。132129になる。1325だと1299になるし 13246だと12999が答えになるはず、とか考えると 「右から降順になっているかチェックして、違反していたらその桁の値を1つ小さくしてそこから右を全部9にする」を繰り返せば解に辿り着きそう。最上位桁が0になったら削る。 計算量も桁数 * 9回程度だから一瞬で出る。

ということで

t = gets.to_i
t.times do |i|
  n = gets.strip.split('').map(&:to_i)
  loop do
    ok = true
    (n.size - 1).times do |j|
      next unless n[j] > n[j + 1]
      ok = false
      n[j] = n[j].to_i - 1
      ((j + 1)..(n.size - 1)).each do |k|
        n[k] = 9
      end
      n.slice!(0) if n[0] == 0
      break
    end
    break if ok
  end
  puts "Case ##{i + 1}: #{n.join}"
end

C. Bathroom Stalls

問題を理解するのに時間かかった…。 要するに 並んでいる長さNのstallの列を選択によって分割したときの右と左ができるだけ長い列になるよう埋めていく、という法則に従ってK人が使用したときの最大値と最小値を求める、ということになる

sample input:

5
4 2
5 2
6 2
1000 1000
1000 1

sample output:

Case #1: 1 0
Case #2: 1 0
Case #3: 1 1
Case #4: 0 0
Case #5: 500 499

1000だったら1人目によって500499に分割され、次は2人目によって500が分割され250249になる、そうすると3人目は499249249で真っ二つに、…という感じの流れになる。 対象が奇数のときは(n-1)/2が2つ に分けられるけど、偶数のときはn/2n/2-1と違う長さに分けられることに気をつけないといけない。

最初は[N]の1要素配列から始めてshiftした値を分割して それを降順で後ろに突っ込むqueueみたいな形でK回操作を繰り返せば答えが出るのでは?と思ったけど、偶数の同じ値が続いたときに124, 124 -> 62, 61, 62, 61のように降順に並ばないことに気付き、苦し紛れに操作のたびにqueueをsort!するという暴挙に出たところsmall datasets 1はどうにか通ったけど、10^6くらいのdatasetだと当然のように計算が終わらなくて死ぬ。

同じ値が何度も登場することに気付いたので それぞれの出現回数を持って操作していけばいいのか!とすぐに気付いて{ N => 1 }から始まるHashを用意。keys.maxを取り出して、対応するvalueを key: (m-1)/2 や key: m/2-1 などに加える。というのを繰り返せばよい。取り出したvalueの総計がKを超えたら既にK人が使用した、ということで そのときの値が答えになる。

t = gets.to_i
t.times do |i|
  n, k = gets.strip.split(' ').map(&:to_i)
  a = { n => 1 }
  y = z = n
  total = 0
  loop do
    m = a.keys.max
    v = a.delete(m)
    y = m / 2
    z = m.even? ? m / 2 - 1 : m / 2
    a[y] = 0 unless a.include?(y)
    a[y] += v
    a[z] = 0 unless a.include?(z)
    a[z] += v
    total += v
    break if total >= k
  end
  puts "Case ##{i + 1}: #{y} #{z}"
end

問題文からはこういう形になることが全然想像つかなかったので、解いていて面白かった。

D. Fashion Show

一応問題は読んだけど、ちょっと時間があまり無かったのと 確実に解けるような気がしなかったので捨てた…

結果

A, B, C でlarge datasetまで正答で65ptで終了。

TensorFlowによるDeep Learningでのアイドル顔識別モデルの性能評価と実験 その2

以前に試した、アイドル顔識別の性能評価。

memo.sugyan.com

それから半年以上も経ってデータ数も増えたし ちょっと確かめたいこともあったので、再び試してみた。

新データセット

前回は 40人×180件 で 計7,200件 を用意したけど、今回はもう少し多めにデータが集まっていたので(卒業などでもうアイドルではなくなってしまった子も居るけど…)、今回は 120人×200件 で 計24,000件 を抽出してデータセットを作成した。

実際にラベル付けしたデータから抽出してみると、元が同じ画像なのに加工や顔検出器のブレなどで別の顔画像として登録されてしまっているもの、明らかに同じ日・同じ場所で連写していて「ほぼ同じ顔画像」と思われるもの などの重複が結構あることに気付いて、頑張って出来る限り排除した。

前回もある程度は人力でチェックしていたけど、今回は学習済みモデルに食わせた中間層出力の分布距離の近いもの、などを調べて機械的に検出した。それでも完全には排除できていないかもしれないけど…。

中身をザッと眺めるとこんな感じになる。

f:id:sugyan:20170220233000j:plain

120人。ほぼ自分でラベル付けしたものなので僕はだいたい見分けがつくけど、普通の人にはちょっと難しいかもしれないですね。

果たして自作の分類モデルはどれだけ見分けられるようになるのか。

Cross Validation で改めて評価

今回は用意したデータセットを5つに分割し、120人それぞれの160件ずつを学習に用い 40件ずつを評価に用いる、という分け方で前回同様に複数パターンで試してみた。 ちょっと時間と金がかかるので使ったのは5パターン全部ではなく3パターンだけ…

前回と同じ構造・同じパラメータ数のモデルを使って学習させ、評価データにおける正答率の変化を調べた。

f:id:sugyan:20170221205722p:plain

右上の方を拡大すると

f:id:sugyan:20170221205727p:plain

40,000 stepくらいで93%くらいには到達するものの、そこから先は続けても94%には到達せず…というところ。 前回のときより僅かに下がったか…?

lossに使っているcross entropyはある程度まで確実に減少している。

f:id:sugyan:20170221205732p:plain

まぁ重複精査したのもあるし、1人あたりの学習件数はそんなに変わらないのに3倍の分類数になっても同程度の精度は出ている、ってことで。

学習時の入力画像distortion再考

今のモデルは、CIFAR-10用のモデルを参考に 入力画像は96x96のサイズだがデータセットは一回り大きく112x112のサイズで用意しており、そこからtf.random_cropを使ってランダムに96x96の領域で切り取って使う、という形式 (評価時は常に中央部分を切り取って使う)。 なので、データセットに使う顔画像収集・管理ツールでも 検出された顔領域が96x96に収まるサイズに拡大・縮小した上で、そこを中心として周辺を含む112x112で切り取ってデータセット用に保存している。

しかし CIFAR-10のような一般分類タスクと違って、この顔識別タスクでは一応分類すべき領域が既に分かっているわけで (一応、というのは 自作顔検出器の精度がそれほど高いわけではなく実際にはそれほど正確に中央の96x96領域に顔がすっぽり収まっているデータばかりではない、というのがある)。 このtf.random_cropを利用せずに学習時も常に中央の領域だけを使う、としたときにどれだけ精度が落ちるか(もしくは意外と落ちないのか)も検証してみた方が良かったかな…(今回はしていない)。

で、違う方法としてtf.image.sample_distorted_bounding_boxを利用できると思ったのでやってみた。 これは物体位置特定タスク(object localization)などの学習なんかに使うためのもののようで、「与えられた画像サイズ(shape)」に対し「指定した矩形領域(bounding boxes)」の領域を一定以上の割合で含む新しい領域をランダムで決定し、それを切り取るための情報を出力してくれる。

つまり[height, width, channels][112, 112, 3]の画像に対し [y_min, x_min, y_max, x_max][8.0/112.0, 8.0/112.0, 104.0/112.0, 104.0/112.0]顔部分があるはずの矩形領域を指定することで、その領域を必ず指定した割合以上含むランダムな領域を得られる。 割合は1.0を指定すれば必ずその指定した矩形以上の大きさの領域が得られるが、それでは全体的に大きく切り取り過ぎてしまうためtf.random_cropのときに最も外れて切り取られた場合と同等の(80.0*80.0)/(96.0*96.0)の値を指定することにした。

縦横比もレンジを指定して制限することができ、デフォルトでは3:4-4:3となっているが 今回の顔画像データセットにおいては縦横の歪みは殆ど無いはずなので9:10-10:9と指定した。 最終的にはこうして得られたランダム領域で切り取った僅かに歪んだ画像を96x96にresizeして学習時の入力とする。

    bounding_boxes = tf.div(tf.constant([[[8, 8, 104, 104]]], dtype=tf.float32), 112.0)
    begin, size, _ = tf.image.sample_distorted_bounding_box(
        tf.shape(image), bounding_boxes,
        min_object_covered=(80.0*80.0)/(96.0*96.0),
        aspect_ratio_range=[9.0/10.0, 10.0/9.0])
    image = tf.slice(image, begin, size)
    image = tf.image.resize_images(image, [96, 96])

例として

f:id:sugyan:20170221211750p:plain

こんな112x112の画像を使ってdistortionをかけてみる。濃い色の部分が顔部分が入っているべき中央の96x96の領域となる。

従来のtf.random_cropを使った場合は

f:id:sugyan:20170221211757j:plain

という感じで、tf.image.sample_distorted_bounding_boxを使った場合は

f:id:sugyan:20170221211803j:plain

という感じになる。

同じ縮尺で場所だけ変えて切り取る従来のものより、様々なサイズのブレを吸収して学習できそうに思える。

結果

従来のtf.random_cropを適用させていた部分をtf.image.sample_distorted_bounding_boxを適用するよう書き換えて 同様にそれぞれ3パターンのデータセットで学習させ、評価データにおける正答率の変化を調べた。 結果は…

f:id:sugyan:20170221205739p:plain

んん…?

3パターンそれぞれの平均値を取って元のものと比較して…

f:id:sugyan:20170221205747p:plain

!!!特に大きな変化なし!!!

むしろ92〜93%くらいに到達するまでが遅くなってしまっている(計算時間は大きな違いは無さそうだった)。

うーん、distortionの方式はあんまり関係なかったか… もうちょっと明らかな改善になることを期待していたのだけど…

誤答の詳細を調べる

では93%程度の精度が出ている場合、残りの7%はどんな入力に対して誤答をしてしまっているの?

あるデータセットで誤答した画像を幾つか抽出してみた。

f:id:sugyan:20170222014440j:plain

簡単な傾向としては、

  • 眼鏡や手指などで隠れてしまっている部分があるもの
  • あまり正面向きではないもの、傾いてしまっているもの
  • 目を瞑っているもの

なんかはやはり間違いやすいのかな…。

実験: 正答評価方法の変更

前述のように顔検出器の精度がそれほど良くないために単純に変な大きさで切り取られているっぽいものも幾つかあり、それらは評価の微調整で解決できそうな気もした。

評価時はデータセット112x112の画像からtf.image.resize_image_with_crop_or_padを使って中央部分96x96を切り取って分類器への入力としていたけど、同時に88x88, 104x104の、「一回り小さく切り取ったもの」「一回り大きく切り取ったもの」も用意し、それぞれ96x96にリサイズして3種類の画像を分類器に入力する。 その3種類の入力に対する出力で「最大の値を得たもの」を分類結果として使うとどうだろうか。

image = tf.image.decode_jpeg(...)
image1 = tf.image.resize_image_with_crop_or_pad(image, 88, 88)
image1 = tf.image.resize_images(image1, [96, 96])
image2 = tf.image.resize_image_with_crop_or_pad(image, 96, 96)
image2 = tf.image.resize_images(image2, [96, 96]) # これはリサイズする必要ないのだけど
image3 = tf.image.resize_image_with_crop_or_pad(image, 104, 104)
image3 = tf.image.resize_images(image3, [96, 96])
inputs = tf.stack([
    tf.image.per_image_standardization(image1),
    tf.image.per_image_standardization(image2),
    tf.image.per_image_standardization(image3)
])
logits = tf.nn.softmax(model.inference(inputs))
values, indices = tf.nn.top_k(logits)

という形で3つの画像をまとめて分類器に入力し、その結果のtf.nn.top_kを取ると それぞれの分類結果の値とインデックスが得られる。 通常はこのindicesの真ん中のもの、すなわち96x96を入力した場合の出力のインデックスが分類結果として 正解ラベルと合っているか否か、を見るのだけど、 もしかすると他のサイズで切り取ったものの方が 違う結果としてより高いスコアを出しているかもしれない。

_, top_value_indices = tf.nn.top_k(tf.transpose(values))
answer = tf.gather(indices, tf.squeeze(top_value_indices))

ということでtf.nn.top_kから得られたvaluesを転置させて最大の値を出力しているのが何番目かを求め、indicesからそれを抽出する。 これを分類結果のラベルとして使って正解と照らし合わせる。 勿論96x96のもので最大の出力が得られていればそのまま使われるし、それが微妙な値で誤答していても他のサイズで高い値の正解を導く可能性がある。

という形で評価してみたところ、あるデータセットで学習したモデルで評価用データに対し

4527/4800 (94.312 %)

から

4573/4800 (95.271 %)

と、正解率が僅かに上昇した。さらに細かく92x92100x100も加えて5種類に入力を増やすと4584/4800 (95.500 %)に。

…しかしまぁ確かにある程度は正解が増えたけど 分類に余計な計算の手間がかかるだけだし、どちらかというと顔検出の精度を上げて出来るだけ同じサイズで学習・評価をできるようにした方が良さそうな気がする。

今のOpenCVを使った簡易顔検出ではまだまだ誤検出も多いし、ここを改善するのが先決かな、と。

まとめ・考察

  • 改めてデータセットを作成し、やはり93〜94%程度の精度であることを確認した
  • 学習データの加工は変えても結局あまり効果は無かった
  • どんな画像に対し誤答するかの傾向を少し調べた
  • 評価データの顔サイズのバラつきは評価方法を工夫することで少しは吸収できる見込み

眼鏡や指などで顔の一部が隠れているものなんかは、もっとデータを増やすことで誤答を減らせそうな気はする。 目を瞑っていたり極度の変顔とか、あまりに普段の表情と違うものはそれでも難しいかもしれないけれど…。

出来るだけ同じサイズの顔画像になるようデータセットを作っていたつもりではあったけど、まだバラつきがあってその影響を受けているらしいことが分かった。 もっと精度を上げるにはより高精度に顔領域を検出してデータセットも改善していく必要がありそうだ。

しかし、誤答例を見てるとまだ「これは普通に正しい大きさで分かりやすく写ってるし 正答してくれても良さそうなのに…」と思うものもある。 もう少し誤答の傾向は調べてみる価値がありそうな気もする。

その他

今回使ったデータセットも公開はしないですが 欲しい方がいらっしゃったら個別に連絡いただければと思います。

TensorFlow 0.12 のEmbedding Visualizationを動かす

=== 追記 2017.06 ===

書いてから時間が経ち 情報が古くなってしまっていましたが、最近の変更に合わせた補足を含む記事を書いていただきました。ありがとうございます!

fuchami.hatenadiary.jp

=== 追記ここまで ===

というTweetをしたところ、結構な反応があったので せっかくなので記事にしておく。

元々自分が知ったのはこの記事からだったのですが。 qiita.com

どうやらTensorFlow 0.12(現時点ではまだRC0)にはTensorBoardに"Embedding Visualization"というのが追加されたそうで。

https://www.tensorflow.org/versions/r0.12/how_tos/embedding_viz/index.html

これに従って可視化したい変数を保存しておけば、tensorboardでそれらを可視化できる、ということで 自分のこれまでに作ってきたアイドル顔画像の分類器とデータセットを使って冒頭のTweetの画面は出来たのだけど、誰もがそういうイイカンジの分類器やデータを持っているわけじゃなくてすぐには触れないかも、と思ったのでデモ用のリポジトリを作っておきました。

github.com

中身

TensorFlowは学習済みのモデルも提供していて、1000クラスの画像分類を行うInception-v3なんかを簡単に動かして試せるようになっている。

https://www.tensorflow.org/versions/master/tutorials/image_recognition/index.html#usage-with-python-api

ので、今回はそれを使ってみることにした。

tensorflow.models.image.imagenetclassify_image.pyというのが入っていて、これを使うと学習済みのモデルをダウンロードして使えるようになる。

from tensorflow.models.image.imagenet import classify_image

classify_image.maybe_download_and_extract()
classify_image.create_graph()

with tf.Session() as sess:
    sess.run(...)

便利!

で、そのclassify_image.pyに以下のようなコメントが書いてある。

    # Some useful tensors:
    # 'softmax:0': A tensor containing the normalized prediction across
    #   1000 labels.
    # 'pool_3:0': A tensor containing the next-to-last layer containing 2048
    #   float description of the image.
    # 'DecodeJpeg/contents:0': A tensor containing a string providing JPEG
    #   encoding of the image.
    # Runs the softmax tensor by feeding the image_data as input to the graph.

つまり'DecodeJpeg/contents:0'に入力のJPEGバイナリを入れて、'pool_3:0'を取り出せばその画像の特徴成分が抽出できるはず、と。 普通にImageNetの画像を入れて分類結果を見ても面白くないので、なんか違った画像を入力して特徴を可視化してみよう。

というところで自分のスマホを漁ってみたら、何故かうどんの写真がいっぱい出てきたので 今回のデモにはそれらを同梱しておきました。(ラーメンも1枚混ざってる)

f:id:sugyan:20161205015626p:plain

で、これらを入力してsess.run(pool_3)みたいに実行するとその画像に対する2048個の中間層出力が得られるので、これらを集めることで可視化対象の2D Tensorを得られる。 これを変数に入れてtf.train.Saverで保存すれば良いだけ、らしい。

embedding_var = tf.Variable(tf.pack([tf.squeeze(x) for x in outputs], axis=0), trainable=False, name='pool3')
sess.run(tf.variables_initializer([embedding_var]))
saver = tf.train.Saver([embedding_var])
saver.save(sess, <checkpoint path>)

これで点は表示されるけど、ラベルとか画像は別のファイルに書き出して関連付ける必要があるらしい。

config = projector.ProjectorConfig()
embedding = config.embeddings.add()
embedding.tensor_name = embedding_var.name
summary_writer = tf.train.SummaryWriter(<checkpoint dir>)

...

embedding.metadata_path = metadata_path
embedding.sprite.image_path = image_path
embedding.sprite.single_image_dim.extend([100, 100])
projector.visualize_embeddings(summary_writer, config)

ラベルについてはTSVとのことで、今回はファイル名だけを付けておいた。TensorBoard上でクリックすると表示されるはず。

f:id:sugyan:20161205021832p:plain

サムネ画像については、順番に並べたsprite画像を用意する必要がある、とのことで今回のように入力の元画像が全部分かっていればあらかじめ作っておくこともできるけど、 いちおうtf.concatとかで画像を表現するtensorを繋げて作ったりもできる。

デモ用画像は300x300で用意したけど、リサイズして100x100を繋げたものを生成するようにした。

thumbnail = tf.cast(tf.image.resize_images(tf.image.decode_jpeg(jpeg_data), [100, 100]), tf.uint8)

...

size = int(math.sqrt(len(images))) + 1
while len(images) < size * size:
    images.append(np.zeros((100, 100, 3), dtype=np.uint8))
rows = []
for i in range(size):
    rows.append(tf.concat(1, images[i*size:(i+1)*size]))
jpeg = tf.image.encode_jpeg(tf.concat(0, rows))
with open(image_path, 'wb') as f:
    f.write(sess.run(jpeg))

これで、以下のような画像が生成されるはず。

f:id:sugyan:20161205021851j:plain

で、めでたくデータが生成されて保存されればtensorboardで動かせる。 10数点しかないと寂しい感じになってよく分からないけど、雰囲気くらいは味わえるのでは…

あんまり特徴から分布を上手く作れている気もしないけど、T-SNEで次元削除した場合は釜揚げうどんが近いものになっているのは確認できた。

f:id:sugyan:20161205021838p:plain

注意点

Qiitaの参照記事にも書いてあるけど、0.12rc0ではまだちょっとバグもあるようで たぶんpython3だと上手く動かなくて、lib/python3.5/site-packages/tensorflow/tensorboard/plugins/projector/plugin.pyとかを書き換えてやる必要がありそう。

既に報告されていて修正も進んでいるようなので次のリリースでは直っていると思うけども…