唯物是真 @Scaled_Wurm

プログラミング(主にPython2.7)とか機械学習とか

コミックマーケット92で入手した技術系の同人誌のメモ(SIGNICO, SIGCOWW, Girls Manifold)

今回は機械学習系などでTwitterで見かけたのを入手した
気になった記事だけ触れます

SIGNICO 『SIGNICO vol.4』

SIGNICO
冊子版とPDF版があったのでPDF版を手に入れた

ミスマッチ判別機を用いたイラストの着色転写手法の提案

線画と色情報を表す参照用の画像を使って、指定した色風の画像を生成する
画像から色情報を抽出するようなネットワークと、抽出された色情報と線画を入力として画像を生成するネットワークと、抽出された色情報と線画がマッチしたものであるかどうかを判別するネットワークでGAN的なことをしている

自由にポーズを変えられる画像生成

OpenPoseを使うと画像から人間のポーズを抽出できる
この抽出されたポーズからGAN(pix2pix)を使って画像を生成している

ニューラルネットワークで画像圧縮

ニューラルネットワークを使った画像の圧縮手法のWaveOneの解説と再現実装(途中)

SIGCOWW 『COSMIC LO Vol.3』

SIGCOWW

冊子版を買ったら電子版のDLコードもくれたのが個人的にはよかった

深層学習とささやきフィルタによる音声変換

変換元の人の音声と変換先の人の音声のパラレルデータを作るために無響室に3時間篭ってもらった的なことが書いてあってデータづくりが大変そう
音声の変換については以下の論文の方法を使っているらしい
Voice Conversion Using Input-to-Output Highway Networks

2-Optで解く10万年巡回セールスマン問題

最近paizaの問題で巡回セールスマン問題を見かけたので個人的にはタイムリーな内容だった

2箇所の経路をつなぎ変えて経路長を短くしていく2-optをやっている
高速化として以下の様なことをしている(他にもある)

  • あらかじめ頂点ごとに近傍のリストをもっておいてその間だけつなぎ変えを考える
  • Don't Look Bitという一度つなぎ変えを試して改善しなかった頂点はその後見ないようにする処理
  • つなぎ変えが発生したときに周りの頂点のDon't Look Bitをオフにするために逆の近傍リストを使う

Girls Manifold 『Create Anime Characters With A.I.』

アニメ系の顔画像を髪の毛の色などの属性を指定して自動生成する方法の解説。英語の論文調でかなり詳しく書いてありました

デモサイトがこちら↓
make.girls.moe
配布していた同人誌と同じ内容が以下のURLで公開されている
http://make.girls.moe/technical_report.pdf

データセット作りに力を入れているっぽい
Danbooruなどから画像をクロールして取ってくると画風やクオリティの偏りがあるのでGetchu.comの画像を使っている
ErogameScape -エロゲー批評空間-エロゲーマーのためのSQL -エロゲーマーのためのSQL- のAPIを使ってURLのリストを取得している
集めてきた画像をlbpcascade animefaceで顔画像周辺を切り抜いている
OpenCVによるアニメ顔検出ならlbpcascade_animeface.xml - デー

髪の毛の色などの属性を指定して画像を自動生成できるようになっている
これに使う属性情報はIllustration2Vecの出力を利用しているらしい
Illustration2Vec: A Semantic Vector Representation of Illustrations

画像の生成はDRAGANというGANの一種を使用している
[1705.07215] How to Train Your DRAGAN
yusuke-ujitoko.hatenablog.com
Generatorの入力に属性の次元の乱数のベクトル、Discriminatorに属性の分類をさせている

他にも生成した画像の超解像も試していて、waifu2xではぼやけてしまうのでGANベースのモデルのSRGANを使っている(デモサイトの方では実装されていない)

BigQueryでアドホックなクエリを書くときに気をつけようかなと思うこと

最近Webのコンソールでクエリを書くときに気をつけようかなと思ったことをメモしておく

クエリにStandard SQLを使っているかLegacy SQLを使っているかを明記する

クエリの1行目に#standardSQL#legacySQLなどと書くことでどちらの種類のSQLを使うか指定できる
これを指定しておかないとコピペして実行するときなどに、違う方で動いてエラーになったりするのでできるだけ書いておく

パラメータの定数はできるだけわかりやすくまとめておく

クエリ中に含まれる条件などの定数は後から変えたくなったりすることも多い。普通にクエリ中に書いているとどれを変えればよいかわからなくなる
また同じ定数が複数回クエリに登場するときにそれぞれをリテラルとして書いておくと一括して修正するのが大変だったり漏れが発生したりしてしまいます

以下の記事でも書いたがUDFの関数として定数を定義してしまうとわかりやすい

雑な例を書くと以下のようにパラメータの定数をUDFとして定義してコメントを書いておくとあとから見てもわかりやすいしどこを変えればよいかは一目瞭然だと思う

#standardSQL

#集計の開始日
CREATE TEMPORARY FUNCTION START_DATE() AS ('20170701');
#集計の終了日
CREATE TEMPORARY FUNCTION END_DATE() AS ('20170731');

SELECT
  *
FROM `foo.bar*`
WHERE _TABLE_SUFFIX BETWEEN START_DATE() AND END_DATE()

何をするクエリか最初にコメントを書いておく

1行目にStandard SQLかLegacy SQLを書いた次の行にクエリの説明を書いておくとよいと思います

説明を書いておくとクエリの履歴の画面を見たときにわかりやすくなります
f:id:sucrose:20170730205528p:plain
また検索でも探しやすくなります。たとえば日付を書いておけば日付で検索したりもできます
後から必要なクエリは名前をつけて保存しておけばよい話ですが、使いまわす予定のないクエリを後から使いたくなったりもするので検索しやすくなっていると便利です
f:id:sucrose:20170730205715p:plain

WITH句を使ってできるだけ共通部分をまとめておく

共通の処理がクエリ中の複数箇所にコピペされていると修正するときに大変になるのでできるだけWITH句を使ってまとめる