Hatena::ブログ(Diary)

Over&Out その後 このページをアンテナに追加 RSSフィード

2018-02-12

3D写真の機能をアプリに組み込める「Fyuse SDK」の使い方

Fyuse SDKを使うと、3D写真(=Fyuse)を撮る/見る機能をアプリに組み込むことができます。


f:id:shu223:20180212093040p:image:w600


本記事ではそんなSDKの使いどころや組み込み方法について紹介してみたいと思います。 ※念のため、このFyuseおよびFyuse SDKは、僕が所属しているFyusion社のプロダクトです。


ちなみに僕はiOSエンジニアなのでiOSの実装を紹介しますが、我々のSDKはiOS, Android, Webをサポートしています。


Fyuseとは

我々の3D写真フォーマット「Fyuse」は、静止画とも動画ともポリゴンベースの3Dモデルとも違うものです。App Storeにある同名のアプリでどんな感じかお試しいただくことができます。


f:id:shu223:20180212081601g:image





例として、僕はこんな場面でFyuseを撮ってます。※はてなダイアリーの制約で、ビューアを埋め込むことができなかったので、アニメーションGIFに変換して載せています。ぜひリンクから、Fyuseビューワで見てみてください。


f:id:shu223:20180212084457g:image

(とある街の道端にあった牛の像)


普通の写真だと、片面だけとか、前からだけになりますが、Fyuseでは立体物をマルチアングルで記録できます。



Fyuseアプリのタイムラインを見ていると、

  • 人(ファッション・コスプレ)
  • 像、彫刻、フィギュア、プラモデル
  • 壮大な景色

あたりはFyuseフォーマットが非常にマッチするなぁと思います。僕は普通に記録フォーマットのいち選択肢として日常使いしてます。


SDK導入事例

モノをいろんな角度から見れる、というところからEC系とは非常に相性が良く、車業界、ファッション業界、大手総合ECサイト等ですでにご愛顧いただいてます。


公開OKを確認できた国内事例ですと、"d fashion"さんの360°アングルでのコーディネート紹介ページがあります。

f:id:shu223:20180212083657j:image:w600


また中古車販売のガリバーさんにご利用いただいております。


「車」向けのFyuseについては会社のサイトでも詳しく紹介されてるのでぜひ見てみてください。



SDKの使い方:Fyuseを「撮影する」機能を組み込む

Fyuseを撮影する機能の実装は、Fyuse用のカメラを起動する → 撮影を開始する → 保存する という流れになります。


カメラの起動

1. `FYCamera`オブジェクトを作成する

private let camera = FYCamera()

2. `prepare`して、`startPreview`する

camera.prepare()
camera.startPreview(with: previewLayer)

`startPreview`には`AVCaptureVideoPreviewLayer`オブジェクトを渡します。

これでFyuse撮影準備完了です。


撮影開始/停止

それぞれメソッドを1つ呼ぶだけです。

camera.startRecording()
camera.stopRecording()

保存

撮影したFyuseをローカルに保存するにあたって、まずは撮影の完了イベントを受けるために`FYCaptureEventListener`プロトコルへの準拠を宣言しておき、

class ViewController: UIViewController, FYCaptureEventListener

FYCameraのリスナーとして追加しておきます。

camera.add(self)

すると、撮影中・完了時・失敗時に`fyuseCamera(_:captureEvent:)`が呼ばれるようになります。

func fyuseCamera(_ camera: FYCamera, captureEvent event: FYCaptureEvent) {
    switch event.captureStatus {
    case .inProgress:
        // 撮影中
    case .completed:
        // 撮影完了
    case .failed:
        // 撮影失敗
    }
}

ここで、保存する際には内部的に様々な処理を行うため、それらを非同期で実行するクラス`FYProcessingQueue()`を使用します。

private let processingQueue = FYProcessingQueue()!
processingQueue.processEntry(path) { 
    print("Fyuse is saved at \(path)")
}

これで撮影機能は完成。


f:id:shu223:20180212083923j:image:w250


SDKの使い方:Fyuseを「見る」機能を組み込む

基本的にはたったの2ステップ

  • 1. FYFyuseViewオブジェクトを作成する
@IBOutlet private weak var fyuseView: FYFyuseView!

ちなみにIBを使用せず次のようにコードから初期化してaddSubviewしてもokです。

private let fyuseView = FYFyuseView()

  • 2. 表示したいFyuseを`FYFyuse`オブジェクトとして1に渡す

`FYFyuse`オブジェクトは、先ほど`FYProcessingQueue()`で処理・保存した際に取得したパスを渡して初期化します。

fyuseView.fyuse = FYFyuse(filePath: path)

これだけです。

先ほど撮ったFyuseがインタラクティブに閲覧できるようになります。



More

基本機能の実装方法を解説しましたが、Fyuseは「撮る」「見る」だけでなくいろいろと機能を持ってまして、たとえば以下のようなものがあります。


Visual Search

3Dベースのディープラーニングを用いた物体検索

f:id:shu223:20180212090119j:image:w250


Car Mode

車をあらゆる角度からオンデバイスで認識し、きれいに車のFyuseを取れるようにする

f:id:shu223:20180212090334p:image:w480


Tagging

Fyuse同士をタグ付けで関連付けられる。

  • 車全体のFyuseのタイヤ部分に、タイヤにフォーカスして撮ったFyuseを関連付けたり

f:id:shu223:20180212090435p:image:w480


VR, AR & MR-ready

Fyuseで撮った人物や車等をVR/AR/MR環境にエクスポート可能

f:id:shu223:20180212090529p:image:w480


f:id:shu223:20180212090713g:image

(Fyuseの人物の背景を変え、エフェクトを載せるデモ)


Infinite Smoothness

空間内におけるフレーム間を動的に補完してスムーズに表示

  • この技術のおかげでファイルサイズは〜5MBと、非常に小さく済む

f:id:shu223:20160929041931p:image:w480


お問い合わせください

Fyuse SDKをサイトからダウンロードできるようにするのはまだ準備中です。気になった方はぜひお問い合わせください。

お問合わせは日本語でも可です。


ちなみに、今月(2018年2月)はエンジニアリングのトップと、ビジネスデベロップメント/マーケティングのトップが日本に行くので、直接ミーティングできると話も早いと思います。ぜひぜひこの機会に!


2017-12-31

2017年の反省

ふりかえり的なことは先月に書いたのですが、

実際のところこの記事は上澄みだけすくい取ったようなもので、ここには書いていない反省や葛藤がたくさんあります。


いま12月31日ですが、その葛藤はいまも現在進行系で自分の中にあるなーという気がするので、やはり2017年の振り返りというか主に反省を書いておきたいと思います。


反省1: アウトプットが減った

技術記事をあまり書かなかった

自分のブログ(これ)はほとんど「◯◯しました」系の自己PR記事だけになり、Qiitaでも(この12月のアドベントカレンダーの時期を除き)ほとんど記事を書いていませんでした


フリーランス時代は仕事を減らしてでも勉強時間を確保し、勉強したことをアウトプットしていましたが、会社員になると週5日が自動的に埋まってしまいますし、発信することへの意識もだいぶ下がってしまった*1感があります。


iOS 11 Samplerを出さなかった

iOS 7のころから4年続けていたiOS Samplerシリーズ、今年はついにサボってしまいました。


例年8月ぐらいから始めて、そこそこ時間をかけて実装して、9月の正式リリースに合わせて公開、というスケジュール感なのですが、今年のその時期はiOS 11 Programmingの執筆で手一杯で、まったく無理でした。


せめてもの足掻きとして(成果物の横展開的な発想で)ARKit-Samplerを公開しましたが、それもサンプル数がちょっとしかなく、追加更新もできず、例年とは大違いです。*2


iOS Samplerはそもそも「自分で新APIを使ってみて、どんなもんか把握しておく」という目的で始めたもので、今年はiOS 11 Samplerをつくってないので、iOS 11の新機能があまり(実感として)把握できてないという普通に宜しくない状況です。


反省2: 「自分にとって唯一の技術スタック」で遅れをとってきている

「最近のiOS開発」がキャッチアップできてない

会社ではSwift書いてませんし、新しい技術の勉強としても、機械学習とかMetalとか3Dまわりをやってたので、

こういうあたりが全然キャッチアップできてません。ずっとiOSしかやってないエンジニアが、そのiOSでもメインストリームから遅れをとっている感。焦りがあります。


アプリ開発に対して腰が重くなった

ちょっと前までは、「iOSアプリをゼロから実装して、申請して、ストアに出す」という一連の流れは「簡単」という感覚だった気がするのですが、今ではすっかり腰が重くなり、既存アプリをアップデートするにしても、非常に大変な作業のように感じてしまいます。


経験を積んで作業の見通しがより正確にできるようになった(ので、大変に感じる)という面もあるかもしれませんが、割り切りが下手になった、頭でっかちになってしまった、という面が大きいように思います。


また、前述した、最近のベストプラクティスについてキャッチアップできてない、というところもあると思います。


自分はそもそもアイデアを形にするところが楽しくてiOSをやってきたので、アプリ開発へのフットワークの軽さは取り戻したいところです。


反省3: アメリカで働いてるのに、アメリカで勝負してない

僕は元来保守的で、不安やプレッシャーを過度に抱えたくないので、1つの重要なチャレンジをしているときは他のチャレンジは諦めてよい、と自分を赦すところがあります。


で、2017年は

  • 今は英語よりも新しい技術(Metalや機械学習)を勉強するのが重要
  • いまはとにかく本の執筆(iOS 11 Programming)が最重要

みたいな状況が続き、英語とか、アメリカ社会にあまりまともに向き合っていない1年でした。


具体的には、

  • 会社が健康保険も負担してくれてるのに、なんだかよくわからないし調べるのも面倒だから日本に帰ったときに病院行こう
  • そろそろクレジットヒストリーがたまって条件の良いカードをつくれそうだけど調べるのが面倒だから最初につくった日系企業のカードをずっと使ってる

とか、諸々そういう話。


あと、こうして日本語での発信を続けているのもそうだし、未だに会議で全然みんなが何言ってるのかわからない程度の英語力を放置しているのもそう。


同じ時期にサンフランシスコの会社に就職し、グリーンカード取得を見据えて働いている友人等を見ていると、しっかりアメリカと向き合って暮らしているな、と思います。「海外で暮らす」ということに伴う様々な困難に対して、彼らはしっかり向き合い、乗り越えている。僕はただ避けているだけ。せっかく海外で働いているのに、これでは世界が広がっていかない


総括

2017年の反省点をつらつらと書きました。単純に心構えや時間の使い方を改善するだけで対策できそうなところもありますが、これらの根底には、会社員とフリーランス、アメリカと日本、というところでの自分の中での葛藤、あるいは切り替えの中途半端さがあるように思います。そういうフワフワしたところのせいで、この1年の4分の3ぐらいは有意義だったものの、残り4分の1ぐらいはなんだか中途半端に過ごしてしまったような。2018年はこのへんの問題にちゃんと向き合い、優先度をしっかりもって行動したい所存です。


*1:仕事の依頼が来ても基本的には受けられないので。

*2:iOS Samplerシリーズは、だいたい公開時からサンプル数が20前後ありますが、それはたまたまではなくて、意識してそこまで持っていってます。(数の)驚きがないと、広がっていかないので。

2017-11-20

サンフランシスコで就職して1年が経ちました

昨年9月28日に『フリーランスを休業して就職します』という記事を書いてサンフランシスコの会社に就職し、早1年が経ちました。


実際にはもう1年と2ヶ月ほど経ってまして、この2ヶ月間、何度も記事を書こうと思いテキストエディタを開きつつ、まとめきれずに途中で断念・・・ということを繰り返してました。ブログ記事1つにまとめるには多くのことがありすぎました。


レイク・タホに別荘を借りて会社のみんな(とそのファミリー)で連休を過ごしたり、同僚の帰省(ミズーリ州)についていってサンフランシスコとは全く違うアメリカを体験したりといった「楽しい思い出」もあるし、英語について色々と試行錯誤したり学んだりしたこともあるし、会社でどんな感じで仕事してるか/現地でどう生活してるかというのもあるし・・・ということを書いてると永遠にまとまらなそうなので、本記事では「入社を決めた当初の目的に対しての達成度はどうか」というあたりについて書こうと思います。


f:id:shu223:20170616204618j:image:w600

(オフィスの屋上でビールの図)


状況のおさらい

まずは前提となる状況について書いておきますと、

  • 2016年10月、サンフランシスコのスタートアップ「Fyusion」にiOSエンジニアとして就職
  • ビザはH-1B
  • 僕がちょうど30人目の社員
    • 今は40人ぐらい?
  • 入社時点では日本人は僕ひとり
    • 今はリサーチ(研究開発)チームに日本人の同僚が一人います。

詳細は冒頭にも挙げた昨年の記事に書いてあります。


Fyusion入社の目的:欲しいスキルが得られそうだった

これも昨年の記事に書いたことですが、謳歌していたフリーランスをやめてFyusionに就職することにした理由は、シンプルに言うと「欲しいスキルが得られそうだったから」です。


具体的には以下の4つ。

  • コンピュータビジョン
  • 3Dプログラミング
  • 機械学習
  • 英語

で、Fyusionは

  • CEOは、3D点群処理のオープンソース・プロジェクト「Point Cloud Library (PCL) 」の設立者であり、OpenCVのコミッタでもある
  • 他のファウンダー陣・メンバーも、ロボット工学・3Dコンピュータビジョン・機械学習とかの博士号もってる人がゴロゴロ(スタンフォード等の名門だったり、CVPRベストペーパーを取った人もいたり)
  • 提供しているサービスもそれらの技術をベースとしている
  • もちろん英語を使う

というわけで、完璧に条件が揃っていたので、これはもう行くしかないということで入社を即決しました。


プラス、これはスキルというよりは経歴面での話ですが、「サンフランシスコの会社で働き、ちゃんと通用した」という実績が得られるのは、もし今後またフリーランスをやる際にも、海外の会社に対して安心材料になるかなと考えていました。


この1年での達成度:技術面

まず、3Dプログラミング・機械学習については、結構達成感があります。いや、どちらも初心者レベルなのですが、何年も前から興味がありつつ、結局ほとんど手を付けられなかった分野で、少なくともスタートを切ることができた、というのは自分にとって非常に大きい。


3Dプログラミングは、ワールド座標とかそういう3Dの基本のキも知らないところから、アプリ内でもSceneKitを利用した機能を実装できたし、ここでSceneKitをさわってたおかげで書籍でARKitについて書くことができました*1


機械学習については、弊社の優秀なリサーチエンジニアが、学習させたモデルをMetal Performance Shaders(MPSCNN)を使ってiOSデバイス側で動かすところまでやってしまうので、残念ながら社内の仕事では自分の出番がほぼなかったのですが、自分にそのへんの仕事がまわってくるようにと、

といったことができたので、スタート地点としては満足です。


コンピュータビジョンに関しては、正直なところ知見が深まった感はあまりありません。そのへんのコアなアルゴリズムはリサーチチームが実装(C++)を含めて担当するし、その中身を聞いて理解するにはアカデミックな知識も英語力も不足しているので、及び腰になってしまいます。とはいえこの分野で新たに知ったことも多いし、機械学習もこの分野に関連してるので、進んだといえば進んだといえるかも。


あと、当初の目標としては考えてなかったですが、弊社はプロダクト内でMetalをガッツリ使ってるので、実務でMetalを使う機会があったのもよかったです。OpenGL ESには以前から興味がありつつ手を付けられてなかったので、同じくGPUインターフェースレイヤのMetalをいじれるようになったのは自分にとってかなり大きい収穫でした。


この1年での達成度:英語

これは・・・アメリカの会社で働いているという観点でみると、かなりダメだと思います。いまだにミーティングでのみんなの議論(自分以外 vs 自分以外)についていけません。日本語でも口数が多い方ではないので、そもそも会話の絶対量が少ない。この感じだとあと3年いても無理な気がします。


とはいえ、入社以前の自分から比べてどうか、という観点だと、飛躍的に向上したともいえます。表現の引き出しは増えたし、チャットではわりと苦もなくコミュニケーションできてます。相手が少しゆっくり話してくれて、話すべき明確な用事(タスクとか、仕様とか)があれば、ちゃんと意思疎通できます。ほんの数年前まで2,3行の英語メール書くにも辞書引きながら10分とかかけてたのを思うと、また入社面接でも相手の言ってることが5%も理解できなかったのを思うと、大きな進歩だなと。


ただ、これまではどうも技術に逃げてしまってたところがありました。英語の勉強より技術の勉強、楽しい会話ができなくても技術で認めてもらえばいい、と。

これだとせっかくの「英語を使わざるを得ない環境」がもったいないので、会話量を増やすべく対策を打っていこうと思います。


この1年での達成度:実績面

まず、1年以上は働く、というのは目安として考えていました。日本と比べて社員をクビにしやすいアメリカでは、実力不足の社員はやはり切られます。1年いれば、ちゃんと通用した、といえるんじゃないかなと。これは達成です。


それとは別に「会社で技術力が認められている」ことが客観的にわかりやすい事実として、プロモート(昇進)しました。


採用時は Lead Software Engineer だったのが、Senior Principal Engineer になりました。


f:id:shu223:20171120075700j:image:w500

(新しくしてもらった名刺)


収入も当初のものから年収にしてn百万円上げてもらったので、サンフランシスコの会社で働き、貢献し、評価されている、というわかりやすい証明ができてよかった、と思っています。



ちなみにうちの会社、CEO、CTO、SVP Engineering、SVP Webのファウンダー陣全員が現役バリバリでコード書きます。これの何がいいって、エンジニアが正当に評価される、という実感がハッキリあります。


たとえばある時期、僕はiOSリポジトリのコードを抜本的に改善すべく、iOSチームメンバーのマインドから変えていかないと、ということでレビュー依頼が自分に振られていないものまで結構細かくコメントをつけていたことがありました。頼まれてもないのに人のコードにケチをつけるというのは下手したら相手から嫌われかねないし、自分でコード書いて新機能とかを実装する方がよっぽど楽しいのですが、どうしても必要だと思った(汚染が広がる一方なのを食い止めたかった)のでやってました。


で、そんなある日、CEOから「いつもグレイトなレビューをありがとう!」っていうメッセージが。


CEOがプルリクのレビューコメントを見て、しかもその良し悪しが評価できるって、良くないですか?これはやはり経営陣が現役でコード書いてるならではかなと思います。「昔はバリバリ書いてた」でも厳しいでしょう。あの機能をつくったとか、そういう見えやすい仕事以外での貢献も評価される環境はエンジニアにとって非常に働きやすいなと。


まとめ

まとめると、

  • 技術面・・・手応えあり
  • 英語・・・もっと話さないといけないけどそれでも進歩はあった
  • 実績面・・・アメリカで通用してるぞという明確なものが得られた

という感じで、ここまでの進捗は上々です。


ただこれはコミュニケーション力に難のある僕に対するファウンダー陣や同僚の理解/協力があってこその結果で、「おれはもう世界のどこでもバリバリやれる」という自信がついたかというと、まったくそんなことはないわけで。会社にも、アメリカにももっと食い込んでいけるようにならないとなぁ、というのが今後の要努力ポイントです。


*1:ARKitは、レンダリングはSceneKitや他のフレームワークに任せるようになっている

2017-08-30

コロラド州デンバーで開催されたiOSカンファレンス「360|iDev 2017」に登壇した話 #360iDev

今月の8月13日〜16日にかけて、アメリカ合衆国コロラド州デンバーにて開催された「360|iDev 2017」にて登壇してきました。


Shuichi Tsutsumi

(発表中の様子)


トークのタイトルは "Deep Learning on iOS" で、スライドはこちら。



持ち時間が45分もあったので、スライドの内容プラス、トークの序盤・終盤でライブデモを2つ(配布されているモデルを使用した一般物体認識/自分で学習させたモデルを使用したロゴ認識)実施しました。



360 iDev カンファレンスについて

raywenderlich.com の毎年の恒例記事 "Top 10 iOS Conferences" に3年連続でエントリーしている、歴史と由緒あるカンファレンスです。



参加人数は今年は250人程度とのこと。



開催場所のコロラド州デンバーは、カリフォルニアから東に行った、アメリカのちょうど真ん中あたりにあります。


f:id:shu223:20170831034407j:image:w400


登壇の経緯

相変わらず招待されたとかではなくて、4月に出したCfPが採択されての登壇でした。今年の3月にtry! Swift TokyoのLTで話した内容 *1 の完全版をどこかでやりたくて、応募しました。



ちなみに今年のCfPはいまのところ4つのカンファレンスに応募して、3勝1敗(通った: try! Swift, 360iDev, iOSDC, 落ちた: UIKonf)です。


カンファレンスの様子

スピーカーは飛行機代が出るのと、会期中のホテルはカンファレンスが用意してくれます。


開催前日の夜はスピーカーディナー。


360iDev Speaker Dinner

(写ってないように見えますが、写ってます。。)


スピーカーディナーは今までちょっと苦手意識があったのですが、今回はAltConfのオーガナイザーやってて僕のことを覚えててくれた人や、日本語勉強してて僕のブログを読んでくれている(!)人、ベルリンのカンファレンスで同じくスピーカーだった人とかもいて、今回は非常に楽しめました。



会場はホテル内にあり、最大4トラックが同時進行します。


360iDev_20170814_8536

(ゲストスピーカー用の一番広い会場)



SlackにはポケモンGOチャンネルやNintendo Switchでマリオカートやるチャンネルとかもありました。


f:id:shu223:20170830194636j:image:w400

(会場から届くとこにフリーザーが出たのでみんなで狩るの図 )



ランチのシステムがユニークで、カンファレンスでもらえるバウチャー持って、フードトラックが集まる公園まで行って、自分で好きなのを注文して食べる、という形式。


f:id:shu223:20170830194757j:image:w600


観光にもなるし、会場の外の空気を吸えるので非常にいい仕組みだと思いました。



こちらはスポンサーブースでももらった、Firebaseのハンドスピナー、ホットソース、ウッドステッカー。


f:id:shu223:20170830195001j:image:w400


ハンドスピナーは(置いて回すときは)回転中もロゴが見えるし、色で個性も出しやすいので企業やサービスのグッズとしては結構いいのではないでしょうか。



僕の出番は2日目のランチ前。


f:id:shu223:20170830195157j:image:w400

(いよいよ次…)



出る直前はソワソワしましたが、話し始めたら緊張は忘れて、練習時よりもうまくしゃべれたと思います。

Shuichi Tsutsumi


Shuichi Tsutsumi


デモもうまくいったし(バックアッププランもたくさん用意しておいた)、終わった後「良かったよ」と声もかけてもらえました。


ただ正直な所、今回のトークの「内容」については100%最高と思える所まで持っていけたとは思ってなくて、悔やまれる部分もあります。そこらへんは結局のところ自分の準備不足、努力不足に帰結するので、今後精進します。(詳しくは後述)



まぁそんなわけでちょっと発表内容については勝手に凹んだりしてたのですが、かの世界的に有名なiOSチュートリアルサイト "raywenderlich.com" の『360|iDev 2017 Conference Highlights』(360iDevのハイライト)という記事で、なんと僕のセッションが紹介されてました。


f:id:shu223:20170830204903j:image:w400


"Can't miss"(必見!)と書いてあったので、嬉しかったです。


準備段階での悩み

今回は悩みまくりました。CfPを出した時点では、WWDC17開催前で、つまりCore MLの発表前で、Metal Performance Shaders の CNN API (MPSCNN) 使って実際にiOSデバイス上でGPU AcceleratedでCNN走らせてる人って当時はあまりいなくて、情報もものすごく少なかったので、まだ価値があったわけですよ。


それが、Core MLが発表されて、MPSCNNのレイヤーを直接たたく意味はあまりなくなってしまった。敷居がグッと下がって、注目度がバーンと上がって、プレイヤーもドッと増えて。


Core ML使うとiOS側の実装云々よりもほとんど機械学習側での知見と努力がモノを言うのだけど、Courseraのコースやっただけの自分はまだ人様に講釈するようなレベルではないし。。


悩みに悩んで、

  • MPSCNNであればiOS 10でも使える
  • BNNSとの使い分け
  • Core ML+Visionはどこをどう簡単にしたか
  • デモ

という話で構成しました。こういう切り口としては、わかりやすく、かつ理解と興味がつながっていくようにうまく説明できたと思います。



ただ、try! SwiftでのLT含め、そもそもの僕がこの分野でプライベートの時間を使って勉強したり勉強会やカンファレンスで登壇したりしてきたのは、「いろいろと革新的で面白いことができそう」というワクワク感からで、ここをほとんど「実践」できないまま登壇して、結果的に自分のトーク内容にもその「ワクワク感」があまりこめられなかったなと。理想的には、もっと色々な実案件をやったり大量のデモをつくってみたりして、そういうのを紹介しつつ、どう、おもしろそうでしょう、というところから話を展開したかった。WWDCの発表で大幅に当初の思惑が狂ったとはいえ、既存の知見をこねくりまわしてどう発表に落とし込むかに準備時間の大半を使ってしまったなと反省しています。


その後のデンバー滞在/リモートワーク

生まれて初めてのデンバー行きで、「この広いアメリカ、同じ場所をもう一度訪れるチャンスはそうそうないかもしれない」と思い、滞在を1週間ほど延長して、リモートワークしてました。これが最高に良かったのですが、facebookに日々色々と書いてたのでここでは割愛します。


f:id:shu223:20170830202708j:image:w400

(皆既日食中のデンバー)


おわりに

360iDev登壇、デンバーの旅、反省点も含め、非常に良い経験になりました。これもあって執筆が遅れていたのですが、今必死で巻き返しております・・・!



*1:LTは5分だったので、具体的なことはほとんど何も説明できなかった

2017-07-25

Core ML vs MPSCNN vs BNNS #fincwwdc

昨日FiNCさんのオフィスで開催された「WWDC2017振り返り勉強会」で『Core ML vs MPSCNN vs BNNS』というタイトルでLTしてきました。



iOS 11で追加されたCore MLが非常に注目を集めていますが、「既存の機械学習フレームワークを使って学習させたモデル(のパラメータ)をiOS側に持ってきて推論を実行する」ということ自体はiOS 10からあって、そこに不便さがあったので広まらず、Core MLでやっと使われるようになった、という側面はもちろんありつつも、いややはりそれでも単にそういうことがiOS 10できるようになったということ自体が知られていなかっただけなのではと。




確かに自分も Metal Performance Shaders のCNN APIを用いた機能を実装しようとしたときに、情報があまりに少なく、何ができて何ができないのか、どうやるのかがよくわからなかった、ということがありました。


で、そのへんをシンプルに説明したら、もっと興味をもつ人も出てくるんじゃないかなと思い、実装手順を3ステップで解説してみました。


  • Step 1: モデルをつくる

f:id:shu223:20170725070344j:image:w600


  • Step 2: ネットワークを実装する

f:id:shu223:20170725070345p:image:w600

f:id:shu223:20170725070347p:image:w600


  • Step 3: 推論の実行処理を書く

f:id:shu223:20170725070346p:image:w600



意外と簡単そう/使えそうではないでしょうか?



ところが・・・


f:id:shu223:20170725070348p:image:w600


f:id:shu223:20170725070349p:image:w600


っていうつらさがあり、他にも色々と面倒な点があり、やっぱりCore ML & Visionのおかげで各段に便利になった、という話でした。



最後にAccelerateフレームワークのBNNSの使いどころについてWWDC17のMetal Labで聞いた話が出てきます。


f:id:shu223:20170725073011p:image:w600



(登壇の様子 by yucovin さん)


なぜこの話をしたのか

上の説明だけを読むとまるでMPSCNNの普及活動をしている人みたいですが、動機はそこではなくて、来月登壇する アメリカのiOSカンファレンス で、"Deep Learning on iOS" というタイトルで発表することが決まっていて、


f:id:shu223:20170725070350p:image:w600


で、これってWWDC17開催前にCfPを出して通ったやつなので、応募当時はMPSCNNの話をするつもりだったのに、Core MLが出てしまって事情が変わってしまった、どうしよう、という。。


じゃあCore MLの話をすればいいじゃん、と思うかもしれません。その通りかもしれません。でも僕自身がまだあまり試せてないのと、Core MLの場合はiOS側が便利になりすぎてむしろ機械学習フレームワーク側(Kerasとか)がメインになるけどそっちは初心者とすらいえないレベルだし、ってことでMPSCNNの方に解説を寄せよう、という試行錯誤の中で「こんな切り口はどうだろう」と考えたのが昨日の発表なのでした。


実際に話してみて、正直なところコレジャナイ感はちょっとありました。もうちょっとワクワクする感じにならないか、実例とかデモとかを増やす感じでブラッシュアップしてみようと思ってます。(来月のカンファレンスは発表時間が45分もあるので、個々の解説ももうちょっと丁寧にやる予定)


おわりに

WWDCには参加したものの、そのままアメリカにいたのでこういう振り返り勉強会に参加できず(※例年勉強会発表ドリブンで新APIを勉強していた)、あっちではこういうLTで気軽に登壇できる勉強会もあまりないので、1ヶ月後というわりとWWDC勉強会としては珍しいタイミングで開催された本イベントは大変ありがたかったです。


LTですが非常に中身の濃い発表が多く、勉強になりました。懇親会で出てくる料理もさすがFiNCさん、ヘルシーで美味しいものばかりでした。どうもありがとうございました!


追記:BNNSについていただいたコメント

Facebookでsonsonさんからコメントいただきました。


f:id:shu223:20170725124035p:image:w400


BNNSとMPSCNNの使い分けは,難しいけど,電力と計算スピードのバランスかなぁと思います.


あと,GPUのメモリとCPUのメモリ間の転送に時間がかかるので,オーバーヘッドをカバーできるくらい,データや計算量大きくないと,GPUは意味ないでしょう.

BNNSは,SIMDなので,これも当然CPUのコンテキストスイッチのためのオーバーヘッド(ノーマルモードとSIMDモードの切り替え)があるのですが,GPUほどではないので,小さいネットワークだとGPUよりBNNSの方が速いというのはありそうです.


まぁ,なんで,電力と速度の限界に挑戦する場合は,ベンチマークとって極限を目指そうって感じですかねw


なるほど、単に「CNNの計算はGPUが向いてるでしょ」とか「Appleの人も言ってた」とかってだけでBNNSのことは忘れようとか言ってちゃいけないですね。確かにGPU↔CPU間の転送速度のボトルネックとGPUによる高速化がどれぐらい見込まれるかのバランスによる、というのは非常に納得です。また「SIMDモードへの切り替えのオーバーヘッド」(はあるがGPUとの転送ほどではない)というあたりもまったく考慮できてなかったところです。


CPU、GPUの負荷がそれぞれどれぐらいか、というのはXcodeで簡単に見れますが、GPU↔CPU間の転送状況を見る方法もあるのでしょうか?GPUまわりの計測・デバッグ手法はもうちょっと勉強したいところです。


ちなみにsonsonさんは例の(私も参加させていただく)クラウドファンディング本で「Core ML」のパートを担当されます。


7/28まで買えるみたいなのでまだの方はぜひご検討を!


2009 | 08 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2013 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2014 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2015 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2016 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 11 | 12 |
2017 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2018 | 02 |