TensorFlowによるDCGANでアイドルの顔画像生成 その後の実験など

memo.sugyan.com

の続編。

あれから色々な変更しつつ実験してみたりしたのでその記録。 結論を先に書くと、これくらい改善した。

f:id:sugyan:20161012032542j:plain

DCGAN ざっくりおさらい

  • Generator: 乱数の入力から画像を生成する
  • Discriminator: 入力した画像がGeneratorが生成したものか学習データのものかを判別する

という2種類のネットワークを用意し、お互いを騙す・見破るように学習を行うことで Generatorが学習データそっくりの画像を生成できるようになる、というもの

学習用画像の増加

前回の記事では90人の顔画像データから生成していたけど、あれから収集を続けて もう少し多く集まったので、今回は260人から集めた顔画像100点ずつ、計26,000件を学習に使用した。

Feature matching

openai.com

の記事で紹介されている "Improved Techniques for Training GANs" という論文を読んで、使われたコードも読んでみまして、正直何やっているのか分からない部分が多く理解できていないことだらけなのだけど その中の "3.1 Feature matching" のところは分かりやすく効きそうだったので取り入れてみた。

原理としては、「Discriminatorの中間層出力には分類のための特徴(feature)が含まれるはずなので、それがGeneratorによるものと学習データ由来のものとで似たようなものになっていれば(学習データに近いものがGeneratorから生成されている、ということになるので)より良いはず」ということのようだ。

なので、Discriminatorの最終出力(入力画像が学習データのものか否かを判定するもの)の1つ前の、4回の畳み込みを行った段階での出力をそれぞれ(Generator由来の画像を入力した場合/学習データの画像を入力したとき)で取得し、各mini batchごとの平均値の差分が少なくなるよう 適当な倍率を掛けてGeneratorのloss値として加えた。

    def build(self, input_images,
              learning_rate=0.0002, beta1=0.5, feature_matching=0.0):
        """build model, generate losses, train op"""
        generated_images = self.g(self.z)[-1]
        outputs_from_g = self.d(generated_images)
        outputs_from_i = self.d(input_images)
        logits_from_g = outputs_from_g[-1]
        logits_from_i = outputs_from_i[-1]
        if feature_matching > 0.0:
), feature_matching))
            features_from_g = tf.reduce_mean(outputs_from_g[-2], reduction_indices=(0))
            features_from_i = tf.reduce_mean(outputs_from_i[-2], reduction_indices=(0))
            tf.add_to_collection('g_losses', tf.mul(tf.nn.l2_loss(features_from_g - features_from_i), feature_matching))
        tf.add_to_collection('g_losses', tf.reduce_mean(tf.nn.sparse_softmax_cross_entropy_with_logits(logits_from_g, tf.ones([self.batch_size], dtype=tf.int64))))
        tf.add_to_collection('d_losses', tf.reduce_mean(tf.nn.sparse_softmax_cross_entropy_with_logits(logits_from_i, tf.ones([self.batch_size], dtype=tf.int64))))
        tf.add_to_collection('d_losses', tf.reduce_mean(tf.nn.sparse_softmax_cross_entropy_with_logits(logits_from_g, tf.zeros([self.batch_size], dtype=tf.int64))))

後述するけれど、従来の方法だと 学習を続けていくと生成画像が全体的に白っぽく薄くなる、という現象があって、おそらくこれはDiscriminatorが画像を判別する際に全体の色合いなどは注視しないからなのではないかと思われ(以前の記事で実験しているように、人間の感覚とは全然違う特徴抽出しているようだ)、 それを防ぐためにも このfeature matchingと同様のものを最終出力の画像にも適用してみた。

         logits_from_g = outputs_from_g[-1]
         logits_from_i = outputs_from_i[-1]
         if feature_matching > 0.0:
+            mean_image_from_g = tf.reduce_mean(generated_images, reduction_indices=(0))
+            mean_image_from_i = tf.reduce_mean(input_images, reduction_indices=(0))
+            tf.add_to_collection('g_losses', tf.mul(tf.nn.l2_loss(mean_image_from_g - mean_image_from_i), feature_matching))
             features_from_g = tf.reduce_mean(outputs_from_g[-2], reduction_indices=(0))
             features_from_i = tf.reduce_mean(outputs_from_i[-2], reduction_indices=(0))
             tf.add_to_collection('g_losses', tf.mul(tf.nn.l2_loss(features_from_g - features_from_i), feature_matching))

比較結果が以下の動画。左側が従来の普通のDCGAN、右側がfeature matchingを加えたもの。


DCGAN with feature matching

左側は全体的にずっとガチャガチャと目まぐるしく変化していて落ち着かない感じなのが、右側は比較的早い段階から顔っぽいものが出来てゆるやかに安定していくように変化している様子が伺える。また左は14,000stepくらいから全体的に白っぽく薄くなっていっているのが 右側では起こらなくなっているのも確認できる。

Learning rate, Batch size

しかし上記の方法でもどうにも限界があるようで ある程度まではキレイに顔っぽいものが生成するようになっても、まだまだ崩れたものになってしまう場合も多い。 変化を観察していると10,000stepくらいでそれなりのクオリティになって、そこからは30,000stepくらいまで続けてもあまり変化が見られない、という感じだった。

どうにかもっと良い画像が生成されるように改善されないか、とlearning_rateをデフォルトより小さめにしてみたり、batch_size128よりもっと大きくしてみたりもしたけど、結局どれもそれほど効果は無さそうだった。

Discriminatorの出力を見る

とはいえ Generatorは無限の乱数入力から無限のパターンを生成するわけで、すべてがキレイな顔画像になるわけがない というのは当たり前といえば当たり前。ならば複数生成されるものから上手くいったものだけ自動で抽出できれば良いのでは?

ということで学習済みのGeneratorとDiscriminatorを使って、mini batchで生成される複数の画像をDiscriminatorに通した結果のsoftmax値の高い順に表示してみた。

    # 乱数mini batchから画像を生成する
    images = sess.run(dcgan.g(dcgan.z)[-1])
    # discriminatorの出力にsoftmaxかけたものを反転してtop_kを抽出
    # `0`を高く出力したもの `1`を高く出力したもの 上位10件ずつの値とindexが取れる
    values, indices = tf.nn.top_k(tf.transpose(tf.nn.softmax(dcgan.d(images)[-1])), 10)
    for x in sess.run([values, indices]):
        print(x.tolist())
    # top_kで得たindicesを使って生成画像から抽出し、縦横に連結
    rows = []
    for cols in tf.split(0, 2, tf.gather(images, indices)):
        rows.append(tf.concat(3, tf.split(1, 10, cols)))
    result = tf.squeeze(tf.concat(2, rows), [0, 1])
    # 余計な次元を削減してjpeg画像に変換して出力
    img = tf.image.encode_jpeg(tf.image.convert_image_dtype((result + 1.0) / 2.0, tf.uint8))

    filename = os.path.join(FLAGS.images_dir, 'out.jpg')
    with open(filename, 'wb') as f:
        print('write to %s' % filename)
        f.write(sess.run(img))

f:id:sugyan:20161012011133j:plain

上段が、Discriminatorのsoftmax出力が0で高かったもの上位。自分のDCGAN実装ではこれはDiscriminatorがGeneratorによる画像だと判定したもの。下段が、softmax出力が1で高かったもの上位 すなわち学習データと判定されたもの(うまく騙せたもの)、となる。

うーん、確かに下段のものの方がキレイに出来ているものが多いような気もするけど、別に全部が良いわけでもないし 上段にもそれなりのものが出てきてたりするし… これも以前の記事で確認した通り、モデルが判別する特徴は人間の感覚と全然ちがうからあまり当てにはならない、のかも知れない…。

Web UIで入出力を調べる

ならば入力の値を弄ってどうにかすることはできないか、と思ったのだけど Generatorはブラックボックスすぎて「どんな値を入力すると どんな画像が生成されるか」が直感的にはまったく分からない。

ので、入力値を色々変えて実験できるよう こんなWeb UIを作ってみた。

f:id:sugyan:20161012012411p:plain

入力乱数を16次元の数値として、それらは実際には小数値なのだけど分かりやすいように0-255の整数値に置き換えてスライダーなどで操作できるように。それらの値に応じてAPI経由でその入力値からGeneratorによる顔画像生成を行い結果を描画。そのときの入力値を32文字のhex stringで表現して再現に使えるようにする。

というもの。Reactとか勉強しながらMaterial-UIで作ってみた。

入力値を操作する

このUIで色々とランダムな入力で試してみると、例えばすごく崩れる顔がどんな入力から生まれるのかが把握できる。

82763953b2740fef4d321dde7af002f7 f:id:sugyan:20161012014750p:plain

75cd0382329c4a341e296530c615b674 f:id:sugyan:20161012014758p:plain

54795b1ef616f55d2cd32f288a3f41f2 f:id:sugyan:20161012014800p:plain

という感じに。 これらを幾つか抽出して雑に平均を取ってみると

samples = %w(
  82763953b2740fef4d321dde7af002f7
  75cd0382329c4a341e296530c615b674
  54795b1ef616f55d2cd32f288a3f41f2
  b21ce031415c8abb73d8200bc115476c
  b0064a3e5ec757ae09898814edd94264
  2e790129bd66adfc8796201ff947259a
  097c5a73700498603e43ab439a854a83
  2a57676c479b4953d1694c45074229a2
  584bcb88c0609c61161ef62cab740b98
  725f3fe61612a4becf920302e936b022
  618b23b2189ea810998968b7dc60e4b5
  0f254708a300a458f504d97fcba07442
)

lists = samples.map do |hex|
  hex.scan(/.{2}/).map(&:hex)
end
avg = lists.transpose.map do |a|
  a.inject(&:+).to_f / a.size
end
puts avg.map { |e| format('%02x', e) }.join
$ ruby average.rb
5b605461755d86826d6b6348b168598d

というのが得られ、これを入力として使ってみると…

5b605461755d86826d6b6348b168598d f:id:sugyan:20161012015218p:plain

と、およそ顔とも分からないようなすごいのが出力されることが分かる。

逆に、そこそこキレイに上手く生成されたものを集めて平均を取ってみると

samples = %w(
  e7a8fea0affc366aa0fc77911c54201a
  c5c3ede294e988a1e8ebb7941def3297
  a1b3f8d8be647c6775cd94e184bb4f08
  75dcabe39c9f8b7e908ecd88546e2c9d
  a582debdcf74d579b990ce7123a48675
  ede6a4fc6cdab7828677e7dd6a998880
  d6e1a99db03f44a29fc49c9427c70569
  fcd35bd348836cc7a18d92d29367196c
  e789ec78b2cf2ba5e5bd9f87723e913f
  f788ded2733f4eb7e7fa9acc2a4aae26
  b2c5b8d3a6b54bd5e7e1cc90838774cf
  dcd9b5bb87a86ec8c3dbace763a65d5c
  c8f8a9e199e244e0f59ab4db62466783
)

lists = samples.map do |hex|
  hex.scan(/.{2}/).map(&:hex)
end
avg = lists.transpose.map do |a|
  a.inject(&:+).to_f / a.size
end
puts avg.map { |e| format('%02x', e) }.join

cbbfc4c798a26ba1babeaeaf53865766 f:id:sugyan:20161012015859p:plain

と、とても自然なイイカンジの画像が生成されることが確認できる。

この「良い例」と「悪い例」の差分を取って、「悪い入力」から「良い入力」へ向かうベクトルを乱数入力値にオフセットとして加えてやれば、より良い結果が生まれやすいのでは!? ということでやってみた結果がこれ。

f:id:sugyan:20161012030450j:plain

入力値の範囲が狭められたことで ちょっと似たり寄ったりなものが多いような気もしないでもないけど、より高確度で比較的安定した顔画像が得られるようになった。 一応ちゃんとそれぞれ髪型や顔の角度・表情は違っているし、悪くないと思う。

この「入力値にオフセットを加える」手法で、例えば「左向きの顔が出力される入力」「右向きの顔が出力される入力」を調べて差分ベクトルを入力値に加えることで右向きばかりのものが生成されるようになったり、表情や髪・肌の色とか 色んな要素を調節しつつ生成できるようになることが期待できる。(まだそこまでは出来ていない。そういった特徴を抽出するのもなかなか面倒…。)

今後の展望

もうちょっと、入力値の良い取り方などは研究してみたいところ。金髪とかショートとか離れ目とか笑顔とか、様々な成分を指定して自由に自分好みの顔を生成できるようになる、のが目標かな。

あとは複数の顔をモーフィングで遷移するアニメーションとか作ると面白そうだと思っているので、そういうのも生成するUIを作ってみたいと思っている。

そもそもDCGANでの生成がこれが限界なのかどうか。さらに改良する方法や、またDCGANではない生成方法も調べて試してみたいところ。

Repository

"Write Code Every Day" 1年

元記事
John Resig - Write Code Every Day
日本語訳
毎日コードを書くこと - snowlongの日記

この記事を読んだときは「へー」くらいにしか感じていなかったのだけど、

1年前の10月5日のjava-ja.OSSでのid:t-wadaさんの発表を聴いて、実際に身近な知っている人たちが実践しているのを知って、「よし自分もやってみよう」と始めたのがきっかけ。

www.slideshare.net

元記事で

  • ブログ記事を書いたりすることは、コードを書いた上でのプラスアルファでなければならない(まずコードを書き、余裕があればそれに加えて他のことをしてもよい)
  • インデントの修正やコードの見た目の調整は(書いたコードに)含めない。可能であればリファクタリングも含めない(これらの全ては、日中の仕事でなければ許可されることだ)。
  • 必ずコードは真夜中より早い時間に書かれること。
  • コードはオープンソースとしてGithubにアップすること。

というルールを定めていたのは出来るだけ従うようにしたけど 実際ぜんぜん出来なくて、package.jsonGemfile.lockの更新だけになってしまう日もあったり 日付を跨いでのcommitで稼いでしまっている日もあったけど、「とりあえず1日も欠かさずに1年は続ける」というのだけ決めていたのは守った。

「草を生やす」は、それだけを目的にしてしまうのはアレだし賛否あるでしょうけども 分かりやすくモチベーションになるし、ってことで何となく始めるときに決めた。 それを継続するために、アイドルの遠征いくときもMBP担いでいって出発前の空港や遠征先のカフェでコード書いたり、女の子と飲みに行ったときも酔っ払いながらスマホからコード編集してpushしたり、それなりに泥臭く頑張って続けてみた。

終盤(9月末)は会社から出すオーエスエスにコントリビュートする仕事?をさせていただいたおかげでラクになりました

なんだかんだで緑色で埋まっているとやっぱり嬉しい気持ちにはなる。

成果

…は正直ほとんど無くて、

とかそれくらい。「OSS!」って感じのものはなく趣味のアイドル顔識別関連が主で、学習パラメータの数字を変更しただけ、の日なんかもあってショボい感じはある…

でも普段仕事では使わないRuby, Python, JavaScriptとかをそれなりに好き勝手に書くことができて楽しかった。

変化

  • コードのことを考える時間は圧倒的に増えた

これを始めるまでは四六時中 推しのアイドルちゃんのことくらいしか考えてなかったと思うけど、「毎日何かを書く」って意識していると 通勤中とか昼食で丸亀製麺まで歩く間のちょっとした時間とかも「今日は何をやればノルマ達成できるかな…」とか考えるようになって 短時間で(その日のうちに)pushできる形にするにはどうしたら…とか 実際に作業している時間以上に影響は大きかったと思う。

  • 「毎日続ける」ことに慣れる

アイドル顔画像識別の学習データ集めとか、実際ちょっとした思い付きでは簡単には出来なかったと思うのだけど、これを続けている中で「毎日少しずつ方法を改善しながらコツコツやっていけばそれなりの量が貯まるだろう」っていう予測が出来たし続けていける自信もあったし こういう少し大きめのプロジェクト(?)も毎日続けて積み重ねることである程度のものが達成できる、という感覚が掴めた、と思う。

  • 自信…?

当然、始める前は「こんなの自分に出来るかな…?」とか思ってたけど、意外とまぁなんとかなって 話を聞いて思い立った翌日からすぐに始めてちゃんと1年間は続けることができたので 自分の行動力と継続力を多少は信頼できるようになったかな、と。

今後

とはいえやっぱり「毎日欠かさず」ってずっと続けるのは疲れるので、これからは 今までの感覚は維持しつつも「毎日」にはそれほどこだわらずにやっていこうかな〜と。

でもまぁなかなかエキサイティングな1年を過ごすことが出来たと思うので、やったことない人は挑戦してみるのをオススメします。

ISUCON6 予選敗退で終わってしまった

ISUCON6id:uzulla さんと id:moznion さんとチーム「[=======> ] 80%」で出場して、予選通過できず敗退しました。

残念…。

前日までの準備

かくかくしかじかでこの3人で出場することには決まったものの、とにかく2人とは一緒に仕事もしたことないし 顔合わせして練習が必要ですね、ということで8月末と9月前半、2回集まって過去問を使って練習会をした。

まず使用言語。2人はPHP強いけど僕は1行も書いたことないし、Goは3人ともある程度は出来そうだけどまぁやっぱりPerlが(最近は全然さわってないにしても)業務でも使って慣れているし安心かな、ということでPerlで。

役割分担としては、

という感じで。

インフラ・ミドルウェア周り完全にuzullaさんにお任せすることになってしまい、負担が大きくなかなかアプリのコードまで見てもらう余裕を作れず申し訳なかったです。ベンチマークまわしてログを解析してボトルネックを見つけ出す、とかもほぼ任せっきりでやってもらってしまいましたが とにかくそのへんのオペレーションやチューニングは完全に信頼できてとても良い仕事をしていただいて、本当に感謝しております。

アプリのコードはmoznionさんと練習もして息を合わせて作業することができて良かったです。お互いローカル環境でも動作確認程度には動かせるようにしつつコードを読んで動作・仕様を把握し。ログからボトルネックを確認できたらまずそこを解消するためにどう変更するか方針をちゃんと相談し、分担できるところは分担して作業。出来るだけちゃんとプルリクを作ってレビューした上でmerge。お互い無駄なミスや手戻りすることなくスムーズに出来たんじゃないかと思っています。

場当たり的に重そうなところを変更していくのではなく、しっかりログを解析してボトルネックを把握して潰し効果を確認し、また次のボトルネックが分かったらそこを潰す、という流れを繰り返す。2回の練習でその感覚はかなりついて手応えはあった(し、実際当日も効果あった)ので 練習会は本当にやっておいて良かったと思います。

当日・前半

気兼ねなく声出して議論しながら作業できる会議室を確保できたのでそこに集合、準備万端で競技開始。

uzullaさんがAzureについてはかなり使い込んで詳しくなってくれていたおかげで最初のサーバ立ち上げや初期セッティングは練習通りでスムーズに。

こちら側も練習通りにコードをGitHub repositoryに入れてローカルで環境作って…(Perl 24.0なんて入ってなかった!!1 plenv installからだ!!!)

アプリ・DBが2個に分かれてるのか…面倒だな、はやめに統一できるならしてしまいたい、ということでボトルネック計測と並行でその作業から。 isutarの方はごっそり移行できそうだったので慎重に変更しつつisudaに統一して2アプリ間での無駄なやりとりを削減。 (11:30頃)

MySQLクエリ解析の結果keywordを長さ順に全件取得してるのが重い、ということが分かったので、これはとりあえず変更されるものではないしlengthカラムを別に保持してそれで引くようにしよう、と。 (11:45頃)

これだけでそれなりの効果が出て、18,515点で一気に断トツ首位へ。このへんまでの流れ練習通りでとてもスムーズに出来て良かった。 f:id:sugyan:20160918225859p:plain

そもそもこのkeywordの長さ順クエリってhtmlify時に置換すべきキーワードを探すための正規表現を作るだけのためのものだし、毎回引く必要はなくて正規表現はアプリで保持しておいてentryが追加・削除されたときだけ(実際にはベンチマークで削除操作は無かったっぽい?)作り直せばいいじゃないか、ということでPOST時に作ってRedisに正規表現文字列を持たせるよう変更。encode_utf8とかdecode_utf8を挟まないとRedisに入らない、とかでハマってPerlムズい、ってなったりしたけど、そんなに無駄にハマり続けたりすることもなく完了 (12:40頃)

これもしっかり効果が出て、追いついてきていた2位チームを一気に引き離して 40,321点に。 f:id:sugyan:20160918230952p:plain

ここまでは良かった…。

当日・後半

ここからtotal_entriesをRedisに載せたり starをRedisに載せる闇改修をmoznionさんが行ったりしている間に、14時過ぎに10万点超えのチームに一気に抜かされ。

やはりhtmlifyの結果そのものをキャッシュしていかないとダメだ、という話になったが、entryが追加されるごとに正規表現も変更されhtmlifyの結果も変更されないといけないはずだから、単純にはキャッシュできないよな…と悩む(ここでもっと更新されるべき内容を精査するとか考えを巡らせるべきだった)

とにかくアクセスの多いのは/だから、ここで表示される10件だけなら毎回POSTされるたびに作っても1秒以内のレスポンスは出来るし効果があるでしょう、ということで新規entryが投稿されるたびに/で表示される10件だけhtmlifyの結果をRedisに載せて使うように。 (15:10頃)

これで64,434点くらいまでは伸びたが、10万点にはとても届きそうにない…

htmlifyの結果を全部をキャッシュに載せようとするとどうしてもPOST時に関連entryの結果を更新できそうにない、別プロセスでどうにか出来ないか…?と取り組み始めて、アプリ内でforkしてみたりRedisをJobQueue代わりに使って裏のワーカープロセスでhtmlify結果を作ってキャッシュに載せる、とかを試みたが、どれも上手くいかずスコアは伸びず… 結局この悪戦苦闘が17時過ぎまでいっても大きな効果を出せず、すべて戻すことに…

その間にサーバ側で様々なチューニングを行ったuzullaさんの変更がプラスされて、再起動テストなどしていたところ 72,018点という結果が出たのでそれを最終スコアとして時間切れで競技終了。

最終的なコードなどはこちら : https://github.com/uzulla/isucon6-q

反省

予選通過ラインは9〜10万点ということで、どうにもそのラインまで届かせることはできなかった。 序盤で確実にスコアを伸ばしていったのは良かったが、そこから先の大幅な点数アップに辿り着けなかったのは力不足だった。

ある程度のリンク作成ミスがあってもスコア計算としてはとにかく成功GETレスポンスが多ければそのミスを上回る効果があった、という話を後で聞いて、もっとミスを恐れずに貪欲にキャッシュしていくべきだったか、と思ったり。そのへんは試算が足りていなかったし、moznionさんも提案して実装しようとしてくれたところに「元の実装と挙動が変わることになるのは納得いかない」と変なこだわりを持って撥ね除けてしまったのが良くなかった。 そもそもstarのキャッシュとかで結構元の実装と挙動違う実装にしていてベンチマークを通していたのだからそんなこだわりを捨ててとにかくベンチマークが通って高い得点を出すことができるのなら色々試してみても良かった。

というかキャッシュに関しても「POST時に全部作ってGET時は読むだけ」みたいな形でやり始めて思考停止してしまっていたので良くなかった。「POST時には関連するものだけ破棄して、GET時に作ってキャッシュする」という形をちゃんと想定していたら正しい実装でももっとスコアは伸ばせていたのかもしれない。どういうわけか当日はこういう考えが思い浮かんでいなかった。

感想

取り組み甲斐のある良い問題で、楽しく挑戦することができました。 他の出場者の方々もレベル高く、やはり簡単には勝てないのだな、と痛感いたしました。様々な参加エントリを読んで復習していきたいと思います。

出題・運営の皆様ありがとうございました!

一緒にチームを組んで戦ってくださった id:uzulla さん、 id:moznion さん、ありがとうございました!!

Links

TOKYO IDOL FESTIVAL 2016 のタイムテーブル画像化ツールを作った

日本最大規模のアイドルの祭典・"TOKYO IDOL FESTIVAL"(通称TIF)。

今年は明日からの8/5〜8/7の3日間の日程で、始まります。

TOKYO IDOL FESTIVAL 2016

で、こういったフェスってステージが複数あって観たいステージが幾つもあるなか、どの時間にどれを見るか とか決めるのが大変で、そういうのを解決するためのツールみたいなのを多くの人たちが作っていたりしますね。 今回のTIF 2016でも幾つかそういうのが有志によって公開されています。

今年はメインのタイテ情報がJSONで取得できるようになっていたのでこういったツールも作りやすい環境になっていたかと思います。

で、自分も何か作ろうかな…と思って

自分の場合、タイテ情報ってけっこう画像をそのままダウンロードしたりWebで載ってるものをスクリーンショットで保存して使うことが多くて。ネットワークの繋がらないところでもすぐに確認できるのが便利なので。

なので自分で組んだ自分だけのタイテを一枚絵の画像でダウンロードできるようなのがあればいいな、と思ったのでそういうのを作ってみた。

条件を指定して絞り込んで表示した一覧から自分が行きたいものだけを選択すると、それだけを抽出してこういった画像を生成する、というだけのもの。

↓例 f:id:sugyan:20160804230856p:plain

技術的にも難しいことは特にしてなくて

  • サーバサイド: RailsJSON APIを用意
    • 公式タイムテーブル情報は定期タスクでfetch & parseして整形しキャッシュに突っ込んでおいてそれを読むだけ
    • 選択したものを元にRMagickでテキスト描画しつつ画像を生成
  • クライアントサイド: ReactでUI生成
    • データは全件取得した上で絞り込みによる表示変更
    • 生成結果の画像を表示切り替えで雑にSPAっぽく

という感じ。

Repository : https://github.com/sugyan/tif2016-mytt

JSのビルドには最近webpackを使うようにしていて、開発時にはwebpack-dev-serverを使った。

などを参考にして、webpack-dev-server --inlineなどでソース変更時に再ビルドとリロードが自動で走るようにしつつ配信しておき、Rails側では

module ApplicationHelper
  def javascript_include_tag(*sources)
    if Rails.env.development?
      opts = {
        src: '//localhost:8080/javascripts/main.js'
      }
      return content_tag(:script, '', opts)
    end
    super(*sources)
  end
end

みたいな感じで開発時のみJSがそっちを向くように設定したら捗った。

Asset Piplineを使わずに/public以下に直接成果物を配置すればいいかな、と思ったけど本番の更新時にキャッシュとか制御できるか不安だったので結局一度/assets以下に吐いてAsset Piplineでfingerprint付きのpathで配信するようにした…。


と、こんな感じで作ったアプリをHerokuにdeployしてちょっとお知らせしてみたところ 色んな界隈のヲタクの方々から400RTくらい拡散していただいて。どれくらいPVあったかは分からないけど 使ってくれたヒトが作った画像を載せてくれて「それどうやって作ったの?」「ここから!」みたいにTwitter上でクチコミで広まったりして、思っていた以上に使ってもらえて、作った甲斐あったわー という感じでとても嬉しい。

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

著者の有山さんとは、TensorFlowでの独自の画像データセットの分類に取り組む同士(?)として勉強会などでお話する機会があり、そんな縁もありまして有り難いことに献本ということで読ませていただくことができました。

第1章の「TensorFlowの基礎」では最初にまずデータフローグラフの「構築」と「実行」で分かれているという概念について、丁寧に説明されていてとても良かったです。いきなり何も知らずに公式Tutorialだけ始めていた自分は、こういう概念について理解するのが遅かった…。

第2章ではCIFAR-10の学習モデルと評価。公式Tutorialの英語を問題なく読めて ある程度のCNNの知識があれば困らないかもしれないけど こうやって日本語で解説されているものがあるというのは(数ヶ月前の自分のように)新しく始める人にとってはとても有り難いだろうなと思います。

第3章ではもうちょっと踏み込んで、TensorFlowでのデータ保存・読込や可視化について。

第4章「CIFAR-10奮闘記」がとても面白かった。 モデル構成や学習データを変えつつ評価結果を確認し、と試行錯誤を繰り返しながら少しずつ正答率を上げる方法を模索していく。自分もアイドル顔識別でそういった試行錯誤を続けていたので とても共感できる内容でした。何をどうすれば正答率が上がる、ってなかなか感覚的な部分もあったりして 最良の道はそう簡単には見つけだせないんですよね…。


というわけで新たにTensorFlowを使って機械学習・画像分類とかをやってみたい、というヒトにはとてもオススメの1冊でした。本当にあと数ヶ月はやくこれが出ていれば僕も最初の躓きが少なかっただろうに…!

巻末の参考文献に私の「すぎゃーんメモ」も載せていただいていて、非常に光栄であります。 この先も続く挑戦の道のり、楽しみにしています!ありがとうございました!!

TensorFlowで顔識別モデルに最適化した入力画像を生成する

f:id:sugyan:20160710002948p:plain

動機

elix-tech.github.io

の記事を読んで、「可視化」の項が面白いなーと思って。 引用されている図によると、人間の目にはまったく出力クラスとは関係なさそうに見える画像でもCNNによる分類器は騙されてしまう、ということのようだ。

なるほど分類モデルの方を固定しておいて入力を変数として最適化していけば任意の出力に最適な入力を得ることができるのか、と。 自分でもやってみることにした。

分類モデル

TensorFlowによるDeep Learningでのアイドル顔識別モデルの性能評価と実験 - すぎゃーんメモ の記事で使ったモデルとデータセットで、ここではCross Validation用にデータを分けずに7,200件すべてを学習に使い20,000 step進めたものを用意した。

このモデルは学習したアイドルたちの顔画像に対してはかなりハッキリと分類できるようになっていて、試しに幾つかを入力して得た分類結果の上位3件をtf.nn.top_k(tf.nn.softmax(logits), k=3)で出力してみると

・例1: エルフロート・マアヤさん (label_index: 10)

f:id:sugyan:20160705200332j:plain

[0.9455398321151733, 0.016151299700140953, 0.013260050676763058] [10, 38, 7]
[0.9314587712287903, 0.02145007625222206, 0.0140310600399971] [10, 7, 38]
[0.9718993306159973, 0.0045845722779631615, 0.0037077299784868956] [10, 2, 17]
[0.9961466789245605, 0.001244293642230332, 0.0008690679096616805] [10, 7, 31]
[0.9985087513923645, 0.0003244238905608654, 0.0003135611186735332] [10, 30, 7]

・例2: フラップガールズスクール・横山未蘭さん (label_index: 13)

f:id:sugyan:20160705200355j:plain

[0.9963579773902893, 0.0019185648998245597, 0.0008565362659282982] [13, 20, 25]
[0.9986739158630371, 0.0006054828991182148, 0.00040348240872845054] [13, 19, 31]
[0.9996882677078247, 0.00011850777082145214, 6.301575194811448e-05] [13, 31, 20]
[0.9860101938247681, 0.006886496674269438, 0.0037682976108044386] [13, 19, 20]
[0.9992870688438416, 0.0002755637979134917, 0.00010664769797585905] [13, 19, 20]

・例3: じぇるの!・針谷早織さん (label_index: 24)

f:id:sugyan:20160705200406j:plain

[0.9933986663818359, 0.004436766263097525, 0.0004516197368502617] [24, 2, 36]
[0.9997298121452332, 6.973237032070756e-05, 5.891052205697633e-05] [24, 8, 2]
[0.9980282187461853, 0.000929205387365073, 0.000297865248285234] [24, 2, 36]
[0.9958142638206482, 0.0027367006987333298, 0.0004832764097955078] [24, 21, 20]
[0.991788923740387, 0.002572949742898345, 0.0013722123112529516] [24, 2, 26]

という具合に、正しいindexの番号の出力が0.9以上になるくらいのものとなっている。

このモデルを騙して誤識別させるような画像を生成する、というのが今回のテーマ。

inputs

今回は入力画像が変数となるので、そのサイズ(今回の場合は96 x 96 x 3)の変数を用意する。取り得る値の範囲は0.0 - 1.0とする。

import tensorflow as tf

with tf.variable_scope('input') as scope:
    v = tf.get_variable('input', shape=(96, 96, 3), initializer=tf.random_uniform_initializer(0.0, 1.0))

inference

学習済みのモデルにこの変数を入力として与え、分類結果を得る。 ただ、元々このモデルはJPEGなどの画像から復元した0 - 255の値をとるtf.uint8Tensortf.image.per_image_whiteningによって変換したものを入力として取るようにしていたので、それに従って同じように変換する。

image = tf.mul(tf.clip_by_value(v, 0.0, 1.0), 255.5)
input_image = tf.image.per_image_whitening(image)
# 以前までの記事で使っていた識別器。今回はbatch sizeを1とする
r = Recognizer(batch_size=1)
logits = r.inference(input_image)

loss

上記で得られた結果と、「理想とする出力」の差分が今回の損失の値になる。 単純に引き算なんかでも良いかもしれないけど、分類モデルの学習と同様にCross Entropyを使ってみることにする。

losses = tf.nn.sparse_softmax_cross_entropy_with_logits(logits, [FLAGS.target_class])

train

定義したlossを最小化する手続き。これも適当にAdamOptimizerを使っておく。 学習によって値を更新していくのは入力変数vのみ。

train_op = tf.train.AdamOptimizer().minimize(losses, var_list=[v])

replace tf.image.per_image_whitening

これだけで学習させていけるかなーと思ったのだけど、実際にSession作ってtrain_opを実行してみると

...
tensorflow.python.framework.errors.InvalidArgumentError: We only handle up to Tensor::dims() up to 8, not 0
         [[Node: gradients/Relu_grad/ReluGrad = ReluGrad[T=DT_FLOAT, _device="/job:localhost/replica:0/task:0/cpu:0"](gradients/Sqrt_grad/mul_1, Relu)]]
Caused by op 'gradients/Relu_grad/ReluGrad', defined at:
...

みたいなエラーが出てしまう。 よく分からないのだけど、入力に変数を使っているときにReluがあると傾きを計算できないの…?TensorFlowのバグなんだろうか、、

tf.image.per_image_whiteningがやっているのは画像の各画素値から平均値とか分散とか求めて引いたり割ったりしているだけなので、そのあたりのソースを参考にtf.nn.reluを使っているところだけ除外して

# image = tf.image.per_image_whitening(image)
mean, variance = tf.nn.moments(image, [0, 1, 2])
pixels = tf.reduce_prod(tf.shape(image))
stddev = tf.sqrt(tf.maximum(variance, 0))
input_image = tf.sub(image, mean)
input_image = tf.div(input_image, tf.maximum(stddev, tf.inv(tf.sqrt(tf.cast(pixels, tf.float32)))))

と書き換えてみたら無事に学習できるようになった。

結果

これで学習を進めていくと、1000 step程度でlossは十分に減少し、softmaxの目標indexの出力は0.999を超えるくらいになる。

$ python optimal_inputs.py --target_class 10
0000 - loss: 4.388829 (0.012415)
0001 - loss: 4.170918 (0.015438)
0002 - loss: 3.950892 (0.019238)
0003 - loss: 3.728565 (0.024027)
0004 - loss: 3.509432 (0.029914)
0005 - loss: 3.291546 (0.037196)

...

0997 - loss: 0.000944 (0.999057)
0998 - loss: 0.000942 (0.999058)
0999 - loss: 0.000941 (0.999060)

で、この学習終了後の変数vを画像として出力してみると。

output_image = tf.image.convert_image_dtype(v, tf.uint8, saturate=True)
filename = 'target-%03d.png' % FLAGS.target_class
with open(filename, 'wb') as f:
    f.write(sess.run(tf.image.encode_png(output_image)))

(ちなみにこういったランダム要素の多い画像をjpeg出力するときはchroma_downsamplingオプションをFalseにしないとかなり情報が落ちてしまうようなので注意。結構ハマった)

f:id:sugyan:20160709224905p:plain

いちおう拡大してみると

f:id:sugyan:20160709225048p:plain

にわかには信じがたいけど、このデタラメ模様にしか見えないような画像が 今回の分類器に最適化された入力画像、となる。 実際にこの画像から分類器にかけてtf.nn.top_k(tf.nn.softmax(logits), k=3)を出力してみると、

with open('target-010.png', 'rb') as f:
    img = tf.image.decode_png(f.read())
img.set_shape([96, 96, 3])
inputs = tf.expand_dims(tf.image.per_image_whitening(img), 0)
logits = r.inference(inputs, FLAGS.num_classes)
softmax = tf.nn.softmax(logits)

...

with tf.Session() as sess:
    print(*[x.flatten().tolist() for x in sess.run(tf.nn.top_k(softmax, k=3))])

結果は

[0.9992352724075317, 0.00031209649750962853, 0.00014285057841334492] [10, 31, 18]

となり、確かにindex 10のものが0.999以上の値になっている。 つまり、この分類器からすると

f:id:sugyan:20160709235237j:plainf:id:sugyan:20160709224905p:plain

どちらも非常に高い確度で同じ人物だと認識する、ということになる。マジかよ。

こんなデタラメ模様のどこに特徴が隠れているんだ…。

実験

ちなみに一応、他のindexに最適化された画像もそれぞれ生成してみた。

f:id:sugyan:20160710001524p:plain

という感じで、どれもそれぞれ対応するindexに対し0.999くらいのsoftmax出力になる画像なのだけど、人間の目にはデタラメ模様にしか見えない。

ということは、ランダムな値ではなく別の画像を初期値として そこに人間の目には分からないような最適化を加えたものを作ることもできるわけで。 先ほどのマアヤさん (label_index: 10)の画像を変数の初期値として、異なるindexに最適化された画像を作ると

フラップガールズスクール・横山未蘭さん (label_index: 13)

f:id:sugyan:20160710002258p:plain

[0.9998733997344971, 4.3967520468868315e-05, 2.7816629881272092e-05] [13, 20, 31]

・じぇるの!・針谷早織さん (label_index: 24)

f:id:sugyan:20160710002305p:plain

[0.9999223947525024, 1.816232907003723e-05, 1.359641919407295e-05] [24, 4, 2]

というように、ちょっとしたノイズが載っているだけのように見えるけれど 分類器の結果は完全に別の人物としての高確度の識別をしてしまう。 不思議〜〜〜。

実際、顔画像を収集している中でたまにOpenCVによる顔検出で誤検出された壁紙の模様とか「まったく人間の顔ではないもの」が たまに高確度であるアイドルさんとして識別されることがあったりして不思議に思っていたけど、こういう結果を見るとまぁ起こり得るんだろうなぁと納得できる。むしろこんな意味わからん誤認識をするくせに94%とかの精度が出る方が不思議だわ…。

Source code

github.com

EC2のGPU instanceで Ubuntu 16.04 + TensorFlow 0.9.0 の環境をつくる

memo.sugyan.com

の続き(?)。 この記事を書いたところ、「Ubuntu 16.04でもこうすれば簡単にCUDAインストールできるよ」とアドバイスをいただきました。ありがとうございます。

qiita.com

というわけで これを使ってやってみた。

g2.2xlargeで、Ubuntu 16.04 LTS (Xenial Xerus)のAMIを使ってインスタンスを立ち上げ、上記記事の通りに操作するだけでCUDA 7.5, cuDNN 4がインストールされる。

あとは(自分はPython3.5を使うので)

$ sudo yum install python3-pip
$ sudo pip3 install --upgrade https://storage.googleapis.com/tensorflow/linux/gpu/tensorflow-0.9.0-cp35-cp35m-linux_x86_64.whl

とやるだけで TensorFlow 0.9.0 がGPUで動いた。やっぱりソースから自分でビルドする必要はなさそうだ。