Hatena::ブログ(Diary)

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

2017-06-07

【iOS 11】ARKitについてWWDCのラボで聞いてきたことのメモ

iOS 11から追加された、AR機能を実装するためのフレームワーク「ARKit」についてWWDCのラボ(Appleのデベロッパに直接質問できるコーナー)で聞いたことのメモです。注目のフレームワークなので行列ができてましたが、丁寧に色々と教えてくれたので、忘れないうちに書いておこうと思います。


f:id:shu223:20170608032933j:image:w600

(WWDCセッションスライドより)


既存実装とどう共存させるか?

先日の記事にも書いたのですが、今働いている会社のアプリ「Fyuse」はスマホで3D的な写真を撮るアプリで、その撮影を補助するために、撮影対象の周囲に3Dの「ARガイド」を表示するという機能をAVFoundation+Metal+SceneKit+独自の画像処理ライブラリ(トラッキング等)で実装しました。


f:id:shu223:20170606094825g:image


ARKitを使うとなると、要iOS 11以上、要A9以上のプロセッサという条件を満たす必要があるわけですが、当然2017年現在では多くのアプリはこれよりもっと広いiOSバージョン、iOSデバイスをサポートしたいはずです。


で、まず聞いたのは、そういう既存実装とARKitを共存させるのに、

if <# iOS 11以上 #> && <# A9以上 #> {
    // ARKitを使う実装
} else if <# 既存実装を使う条件 #> {
    // 既存実装
} else {
    // それ以外
}

みたいなのを避ける方法があったりしませんか?と。



回答:ない。ARKitを使うにはiOS 11以上、A9以上が必要だ。



・・・はい。そりゃそうですね。変な質問してすみません。でもせっかく来たので食い下がって聞いてみました。


「他のAR利用アプリもiOS 10以下はまだ切れないと思うけどみんなどうしてるの?たとえばポケモンGoとか」



回答:知らない。



・・・はい。そりゃそうですよね。(もし知ってても言えないですしね)



既存実装と比較したARKitのアドバンテージは何だと思うか?

質問が悪かったので、「じゃあ既に実装が済んでいて、ARKitを使うとなると既存実装にプラスしてバージョンわけが必要というデメリットがありつつ、それでもARKitを使う理由はあるのか」という観点から、我々の既存実装と比較したARKitを使うメリットについて聞いてみました。



→ 回答:

  • Appleの純正フレームワークは公開APIよりもっと下のレイヤーを利用した実装ができるので、サードパーティ製の実装よりもハードウェアに最適化されている。よってバッテリー消費量や処理速度の面で優れていると考えられる
  • ユーザーがタップしなくても、ARのセッションを開始した時点でシーンの解析が完了している(これは厳密には我々の用途にとってはアドバンテージではないが、「違い」ではある)
  • デバイスの姿勢も考慮してキーポイントを抽出してるので、デバイスを動かすと云々(すみません、実はこのへんちょっとよくわかりませんでした)

結局のところ、ARのシーンとしてはどういうものが検出できるのか

我々の要件としては、水平面に何かを置きたいわけじゃなくて、対象オブジェクトを囲むように3Dノードを表示したいわけです。


f:id:shu223:20170606094825g:image


ところがARKitは検出した床やテーブル等の水平面に何かを置く実装しか見当たらないので、「こういうのってARKitでできるの?」ということを聞いてみました。



で、回答としては、今のところ「水平方向」(horizontal)の「平面」(plane)しか検出しないそうです。


`ARPlaneAnchor.Alignment` というenumがありますが、実はまだ `horizontal` という要素ひとつしかなくて、`vertical` というのはまだありません。つまり壁のような「垂直方向の平面」を検出したり、我々のアプリのように人間や銅像や動物といった任意のオブジェクトを検出したり、そういうことは現状ではサポートしてないようです。


なので、ポケモンGoのようにキャラクターの3Dモデルを表示するタイプのARにはいいですが、我々のアプリのような用途や、実世界のものに合わせて何か情報を表示したり、みたいなタイプのARにも現状では向いてなさそうです。



どういう水平方向の平面が認識されるかについても教えてくれたのですが、ある程度の大きさが必要で、たとえばイスの座面は十分な広さがあるので水平面として検出されるが、背もたれの上(伝わりますかね?)みたいな狭いものは水平面としては検出されないと。



ただもう一つ提案として言ってくれたのは、検出したキーポイントはAPIから取れるので、それらを使って自分で垂直方向の面なり何なりを再構成することならできる、と言ってました。これはありかもしれません。


深度情報は使用しているのか?

たとえばiPhone 7 PlusのようにDepth(デプス/深度)を取れるようなデバイスの場合、それを使ってより精度良く検出するような処理を内部でやってたりするのか?ということを聞きました。



回答:使ってない



普通のカメラだけで精度良く動くようなアルゴリズムになっていて、デバイスによる処理の差異はないそうです。


おわりに

結論としては、我々の用途には今のところは合ってなさそうです。が、今後のアプリ開発の可能性を広げてくれる非常におもしろいフレームワークであることには代わりはないので、プライベートでは引き続き触っていこうと思っています。


2016-12-01

Metalのコンピュートシェーダに関する諸々

Metal の compute shader について。随時書いていきます。


[[ thread_position_in_grid ]] って何?

こういう感じで、カーネル関数の引数から受け取れるやつ。

kernel void
add_vectors(const device float4 *inA [[ buffer(0) ]],
            const device float4 *inB [[ buffer(1) ]],
            device float4 *out [[ buffer(2) ]],
            uint id [[ thread_position_in_grid ]])
{
    out[id] = inA[id] + inB[id];
}

変数名としては id, gid, tid となっているのをよく見かける。


Metal Shading Language Specification / Guide』によると、

thread_position_in_grid identifies its position in the grid.

とシンプルに書かれている(4.3.4.6 Attribute Qualifiers for Kernel Function Input)。


これだけじゃその名前が表現している以上のことがわからないのでグリッドやスレッドの説明も引っ張ってくると、

When a kernel is submitted for execution, it executes over an N-dimensional grid of threads, where N is

one, two or three. A thread is an instance of the kernel that executes for each point in this grid, and

thread_position_in_grid identifies its position in the grid.

Threads are organized into threadgroups. Threads in a threadgroup cooperate by sharing data through

threadgroup memory and by synchronizing their execution to coordinate memory accesses to both

device and threadgroup memory. The threads in a given threadgroup execute concurrently on a

single compute unit12 on the GPU. Within a compute unit, a threadgroup is partitioned into multiple

smaller groups for execution.

ちょっとよくわからない。。


ここの回答にわかりやすい説明があった。

`thread_position_in_grid` is an index (an integer) in the grid that takes values in the ranges you specify in `dispatchThreadgroups:threadsPerThreadgroup:`. It's up to you to decide how many thread groups you want, and how many threads per group.

In the following sample code you can see that `threadsPerGroup.width * numThreadgroups.width == inputImage.width` and `threadsPerGroup.height * numThreadgroups.height == inputImage.height`. In this case, a position in the grid will thus be a non-normalized (integer) pixel coordinate.


なるほど、`dispatchThreadgroups:threadsPerThreadgroup:` を呼ぶときに渡すサイズ(`threadsPerGroup`と`numThreadgroups`)によって「グリッド」の範囲が決まり、`thread_position_in_grid` はそのグリッド内のインデックスを保持する、と。


テクスチャのサイズを取得

カーネル関数が、たとえば以下のように定義されていれば、

kernel void computeShader(texture2d<float, access::read> tex [[ texture(0) ]],

この引数texに渡されてくるテクスチャのサイズは、

    float w = tex.get_width();
    float h = tex.get_height();

という感じで取得できる。


2016-11-13

iOS/MetalのシェーダをWebGL/GLSLから移植する

Metalでグラフィック処理を行うにしろ並列演算を行うにしろ、GPUに処理をさせるためのシェーダを書かないといけないわけですが、これがまだ情報が少なくて、「こういうシェーダを書きたいんだけど、誰かもう書いてないかな・・・」というときに参考になる近いものとかはそうそう都合よく出てこないわけです。


ただ、WebGL/GLSLの情報はググると山ほどあって、GLSL Sandbox という、Web上で編集できてプレビューできてシェアできるサイトもあり、何がどうなってそうなるのか理解できない難しそうなものから、ただの円といったシンプルなものまで、既に偉大な先人たちのサンプルがたくさんアップされています


f:id:shu223:20161113192400j:image:w600



Metalのシェーダというのは正しくは Metal Shading Language といいまして、C++をベースとする独自言語なのですが、まー概ねGLSLと一緒です。


実際にやってみたところ、GLSL -> Metal Shader の移植はほとんど単純置き換えで済み、Swift 2をSwift 3に直すのよりも簡単という感覚でした。


f:id:shu223:20161113192821j:image


いずれも画像等のリソースは使用しておらず、iOSデバイス上で、GPUによってリアルタイム計算されたものです。


実際のところ自分はゲーム開発やVJをやったりしているわけではないので、こういう派手なエフェクトではなく、線とか円とかグラデーションとかのもっと単純なものをMetalで動的描画したいだけだったりするのですが *1、移植が簡単に行えることがわかっていれば、GLSLを参考にMetalシェーダを書けるというのはもちろんのこと、GLSL Sandboxで動作確認しつつシェーダを書いて、できたものをiOSに移植する、ということもできるので、個人的にはMetalシェーダを書く敷居がグッと下がりました。


というわけで、以下GLSLのコードをMetalに移植する際のメモです。


雛形となるプロジェクトを作成する

プロジェクトテンプレートに "OpenGL ES" はあっても "Metal" というのはないのですが、"Game" というのがあり、次の画面で [Game Technology] の欄で Metal を選択すると、シンプルなMetalのプロジェクトが生成されます。


f:id:shu223:20161113194605j:image:w500


これをベースに、GLSLのコードを移植して来やすいように次のように手を入れました。(現時点ではGLSL SandboxのコードをiOSで動かしてみるべく、フラグメントシェーダだけに手を入れています)


1.「画面の解像度」をフラグメントシェーダに渡す

多くのGLSLのサンプルでは、xy平面における座標を 0.0〜1.0 に正規化した状態で取り扱っています。ピクセルベースの座標値をシェーダ側で正規化できるよう、画面の解像度をシェーダに渡すよう修正します。


まずはシェーダ側。下記のように引数に float2型の "resolution" を追加します。

fragment float4 practiceFragment(VertexInOut     inFrag      [[stage_in]],
                                   constant float2 &resolution [[buffer(0)]])

次にSwift側。下記のようにバッファを用意して、

var resolutionBuffer: MTLBuffer! = nil
let screenSize = UIScreen.main.nativeBounds.size
let resolutionData = [Float(screenSize.width), Float(screenSize.height)]
let resolutionSize = resolutionData.count * MemoryLayout<Float>.size
resolutionBuffer = device.makeBuffer(bytes: resolutionData, length: resolutionSize, options: [])

フラグメントシェーダ関数の引数にバッファをセットします。

renderEncoder.setFragmentBuffer(resolutionBuffer, offset: 0, at: 0)

こんな感じで正規化した座標値を算出します。

float p_x = inFrag.position.x / resolution.x;
float p_y = inFrag.position.y / resolution.x;
float2 p = float2(p_x, p_y);

GLSL Sandboxはスクリーンが必ず正方形なのですが、iOSデバイスはそうではないので、比率が変わらないようどちらもx方向の解像度(つまり幅)で割っています。


2. 「経過時間」をフラグメントシェーダに渡す

ほとんど同様です。シェーダ側では、引数に float型の "time" を追加します。

fragment float4 practiceFragment(VertexInOut     inFrag      [[stage_in]],
                                   constant float2 &resolution [[buffer(0)]],
                                   constant float  &time       [[buffer(1)]])

Swift側。下記のようにバッファを用意して、

var timeBuffer: MTLBuffer! = nil
timeBuffer = device.makeBuffer(length: MemoryLayout<Float>.size, options: [])
timeBuffer.label = "time"

フラグメントシェーダ関数の引数にバッファをセットします。インデックスが変わる点に注意。

renderEncoder.setFragmentBuffer(timeBuffer, offset: 0, at: 1)

時刻の更新時にバッファを更新します。

let pTimeData = timeBuffer.contents()
let vTimeData = pTimeData.bindMemory(to: Float.self, capacity: 1 / MemoryLayout<Float>.stride)
vTimeData[0] = Float(Date().timeIntervalSince(startDate))

GLSLを移植する際の改変点

GLSL を Metal に移植してくる準備が整いました。ほとんど同じ、と書きましたが細部はやはり違います。以下、大まかな移行ポイントです。

  • GLSLのフラグメントシェーダでは、最後に gl_FragColor にvec4値をセットすることで出力とするが、return で float4 なり half4 なりを返す

(例)GLSLの場合

gl_FragColor = vec4(color, 1.0 );

Metalの場合

return float4(color, 1.0);
  • 関数はプロトタイプ宣言が必要
    • これがないと、ビルド時に "No previous prototype for function 〜" というwarningが出る
  • vec2, vec3, vec4 -> float2, float3, float4
  • ivec2, ivec3, ivec4 -> int2, int3, int4
  • mat2, mat3, mat4 -> float2x2, float3x3, float4x4
    • コンストラクタも微妙に違う(float2x2ならfloat2を2つ渡す。公式ドキュメントp15あたり)
  • const -> constant
  • mouse.x, mouse.y -> 適当に0.5とか

また出てきたら追記します。


GLSL Sandboxから移植してみる

GLSL Sandboxでいくつかピックアップして上記手順でMetalに移植し、iOSで動かしてみました。それぞれの移植にかかった時間は5分ぐらいです。ほとんど単純置き換えで済みました。


http://glslsandbox.com/e#36694.0

f:id:shu223:20161113193424g:image


http://glslsandbox.com/e#36538.3

f:id:shu223:20161113193507g:image

※デフォルトのITERATIONS 128では3fpsぐらいしか出なかったので、ITERATIONS 64に変更


http://glslsandbox.com/e#36614.0

f:id:shu223:20161113194708g:image


まとめ

GLSLをMetalに移植する手順について書きました。


上にも書きましたが、Metalをさわりはじめたときはシンプルなものすら書き方がわからなくて四苦八苦したので、「GLSLのコードも参考になるんだ!」と気付いたときはMetalの敷居がグッと下がった気がしました。


MetalはiOS 10からニューラルネットワーク計算のライブラリも追加されたこともあり、自分的に今一番熱い分野です。引き続きシェーダの具体的な書き方や、SceneKitを併用して3D空間内のノード上にMetalでテクスチャを動的描画する方法、デバッグツールの使い方等、色々と書いていきたいと思います。



*1:線とか円とかの単純なものでも、カメラプレビューで動的かつリアルタイムに、かつ他の重い画像処理と一緒に、といった場合、そして描画数が多かったり毎フレームの更新が必要な場合、やはりUIKitやCoreGraphicsでは厳しい場面が出てきます。

2016-07-20

TensorFlowをiOSで動かしてみる

TensorFlow に iOS サポートが追加された というニュースを見かけたので、ビルドして、iOSで動作させてみました。


f:id:shu223:20160720074930j:image:w240

たまたま目の前にあった扇風機もバッチリ認識してくれました)


本記事では最終的にうまくいった手順を書いています。この手順をなぞってみるにあたってTensorFlowや機械学習・ディープラーニングについての専門知識は不要ですのでぜひお試しください!


ビルド手順

(2017.4.15追記)v1.1.0 RC2 のビルド

現時点での最新Release(候補)である v1.1.0 RC2 も、tensorflow/contrib/makefile/build_all_ios.sh を実行するだけでビルドできました。


(2016.8.22追記)v0.10.0 RC0 のビルド

現時点での最新Releaseである v0.10.0 RC0 は、上記手順でビルドしようとすると compile_ios_tensorflow.sh を実行するところでコケてしまったのですが、今は各ビルドの手順がまるっと入ったスクリプトが用意されているようです。

tensorflow/contrib/makefile/build_all_ios.sh

依存ライブラリのダウンロードからiOSアーキテクチャ向けビルドまで、これ一発でokでした。


(※旧バージョンでの手順)v0.9.0 のビルド

iOSサポートバージョンであるv0.9.0をチェックアウトして、以下の手順でビルドしていきます。手順はこの通りになぞるだけですし、ほぼスクリプトを実行するだけで非常に簡単です(が、実行時間がかなりかかります)。


  • スクリプトを実行して Eigen や Protobuf 等の依存ライブラリをダウンロード
cd tensorflow
tensorflow/contrib/makefile/download_dependencies.sh

  • protobuf をビルド&インストール
cd tensorflow/contrib/makefile/downloads/protobuf/
./autogen.sh
./configure
make
sudo make install

ここで、僕の環境では `./autogen.sh` 実行時に

Can't exec "aclocal": No such file or directory at /usr/local/Cellar/autoconf/2.69/share/autoconf/Autom4te/FileUtils.pm line 326.
autoreconf: failed to run aclocal: No such file or directory
shuichi-MacBook-Pro-Retina-15inch:protobuf shuichi$ ./configure
-bash: ./configure: No such file or directory

というエラーが出ました。”aclocal”というのは、”automake”パッケージに含まれているらしいので、automakeをインストール。

brew instal automake

で、改めて

./autogen.sh
./configure
make
sudo make install

  • iOS native版のprotobufをビルド
cd ../../../../..
tensorflow/contrib/makefile/compile_ios_protobuf.sh

  • iOSアーキテクチャ向けにTensorFlowをビルド
tensorflow/contrib/makefile/compile_ios_tensorflow.sh

サンプルをビルドする

`tensorflow/tensorflow/contrib/ios_example` に2種類のサンプルがあります。


simple と名付けられたサンプルアプリは、今回ビルドした static library をアプリ内に組み込む際の最小実装としての参考にはなりそうですが、デモとして見て楽しい機能があるわけではないので、本記事ではもう一方の camera の方を紹介します。


まず、このファイルをダウンロードして、解凍すると入っている、

  • imagenet_comp_graph_label_strings.txt
  • tensorflow_inception_graph.pb

の2つのファイルを、`tensorflow/contrib/ios_examples/camera/data` に置きます。*1


この Inception というのはGoogleが提供する画像認識用の学習済みモデルのようです。


cameraサンプル実行例

cameraサンプルを実行すると、すぐにカメラが起動します。身近のものを色々と映してみました。(リアルタイムカメラ入力に対する認識結果を表示してくれます)


MacBook

f:id:shu223:20160720080028j:image:w240


"Notebook" "Laptop" どっちでも正解!


扇風機

f:id:shu223:20160720074930j:image:w240


"Electric Fan" 正解!


椅子

f:id:shu223:20160720080106j:image:w240


"Folding Chair"(折りたたみ椅子) 惜しい。。ですが、そもそも `imagenet_comp_graph_label_strings.txt` には chair が3種類しかなくて、その中では一番近いと言ってもいいかもしれません。


iPhone

f:id:shu223:20160720080129j:image:w240


"iPod"・・・惜しい!iPhoneなのでほぼ正解と言ってもいいかもしれません。


パフォーマンス

今回cameraサンプルを試したデバイスはiPhone 6だったのですが、認識はまだまだリアルタイムとは言い難く、数秒単位の遅延がある感じでした。まだiOS向けにビルドできるようになったというだけでiOSにおける GPU Accelerated はされてないですし、パフォーマンスの最適化はまだまだこれからのようです。


(2017.4.15追記)v1.1.0 rc2 / iPhone 7 で試したところ、それなりにリアルタイムで動きます。`contrib/ios_examples` 配下のコミットログを見たところ、Metal等による最適化はまだされてないようですが、いくつかパフォーマンスに関連しそうな改善はあったようです。

(追記ここまで)


ちなみにiOS 10 で Accelerate.framework に追加された BNNS (Basic neural network subroutines) や MetalPerformanceShaders.framework に追加されたCNNのAPIを使用する最適化もissueに挙がっています。


MPSCNNについてはいくつか記事を書いたのでよろしければ:


ビルド手順の情報ソース

iOSサポートバージョンである0.9.0トップ階層にあるREADMEを見ても、iOSについては書かれていません


上述したビルド手順は`contrib/makefile` 配下のREADMEに書かれています。

関連情報を以下にまとめておきます。


サンプルのソースコードを読んでみる

サンプルは全編Objective-C++で書かれています。読んでもわからないだろうと思いつつ、せっかくなので読んでみます。


tensorflow_utils

モデルとラベルデータを読み込むメソッドと、認識結果を返すメソッドを持つユーティリティクラスのようです。

tensorflow::Status LoadModel(NSString* file_name, NSString* file_type,
                             std::unique_ptr<tensorflow::Session>* session);
tensorflow::Status LoadLabels(NSString* file_name, NSString* file_type,
                              std::vector<std::string>* label_strings);
void GetTopN(const Eigen::TensorMap<Eigen::Tensor<float, 1, Eigen::RowMajor>,
             Eigen::Aligned>& prediction, const int num_results,
             const float threshold,
             std::vector<std::pair<float, int> >* top_results);

汎用的に使えそう。


ios_image_load

画像ファイルを読み込むクラス。

std::vector<tensorflow::uint8> LoadImageFromFile(const char* file_name,
             int* out_width,
             int* out_height,
             int* out_channels);

プロジェクトには追加されているけど使われてないっぽい。


CameraExampleViewController

サンプル本体。肝っぽいところだけを拾っていくと、


`std::unique_ptr<tensorflow::Session>` なメンバ変数を定義して、

std::unique_ptr<tensorflow::Session> tf_session;

viewDidLoadのタイミングでモデルを〜.pbファイルからロード

tensorflow::Status load_status =
  LoadModel(@"tensorflow_inception_graph", @"pb", &tf_session);

で、カメラからのリアルタイム入力が得られるたびに呼ばれるデリゲートメソッドを見てみると、

- (void)captureOutput:(AVCaptureOutput *)captureOutput
didOutputSampleBuffer:(CMSampleBufferRef)sampleBuffer
       fromConnection:(AVCaptureConnection *)connection {
  CVPixelBufferRef pixelBuffer = CMSampleBufferGetImageBuffer(sampleBuffer);
  [self runCNNOnFrame:pixelBuffer];
}

CMSampleBufferRef から CVPixelBufferRef を取得して `runCNNOnFrame:` を呼んでいるだけのようです。


`runCNNOnFrame:` はコードが若干長いですが、このへんと、

tensorflow::Tensor image_tensor(
    tensorflow::DT_FLOAT,
    tensorflow::TensorShape(
        {1, wanted_height, wanted_width, wanted_channels}));
auto image_tensor_mapped = image_tensor.tensor<float, 4>();
tensorflow::uint8 *in = sourceStartAddr;
float *out = image_tensor_mapped.data();

このへんが肝っぽいです。

if (tf_session.get()) {
  std::string input_layer = "input";
  std::string output_layer = "output";
  std::vector<tensorflow::Tensor> outputs;
  tensorflow::Status run_status = tf_session->Run(
      {{input_layer, image_tensor}}, {output_layer}, {}, &outputs);
  if (!run_status.ok()) {
    LOG(ERROR) << "Running model failed:" << run_status;
  } else {
    tensorflow::Tensor *output = &outputs[0];
    auto predictions = output->flat<float>();

    // ラベル取得
  }
}

が、すみません、それぞれ何をやっているのかを解説するにはTensorFlowの処理をちゃんと理解する必要がありそうです。。(勉強します)


自分のアプリに組み込む

試せていませんが、こちら に手順が示されていました。

  • ユニバーサルなstatic library(libtensorflow-core.a)をビルドしてプロジェクトに追加する
    • [Library Search Paths] にも追加。

The `compile_ios_tensorflow.sh' script builds a universal static library in tensorflow/contrib/makefile/gen/lib/libtensorflow-core.a. You'll need to add this to your linking build stage, and in Search Paths add tensorflow/contrib/makefile/gen/lib to the Library Search Paths setting.

  • libprotobuf.a と libprotobuf-lite.a をプロジェクトに追加する。
    • [Library Search Paths]にも追加

You'll also need to add libprotobuf.a and libprotobuf-lite.a from tensorflow/contrib/makefile/gen/protobuf_ios/lib to your Build Stages and Library Search Paths.

  • [Header Search paths] を追加

The Header Search paths needs to contain the root folder of tensorflow, tensorflow/contrib/makefile/downloads/protobuf/src, tensorflow/contrib/makefile/downloads, tensorflow/contrib/makefile/downloads/eigen-eigen-, and tensorflow/contrib/makefile/gen/proto.

  • [Other Linker Flags] に `-force_load` を追加

In the Linking section, you need to add -force_load followed by the path to the TensorFlow static library in the Other Linker Flags section. This ensures that the global C++ objects that are used to register important classes inside the library are not stripped out. To the linker, they can appear unused because no other code references the variables, but in fact their constructors have the important side effect of registering the class.

  • bitcodeを無効にする

The library doesn't currently support bitcode, so you'll need to disable that in your project settings.


まとめ

TensorFlowをiOS向けにビルドし、付属のサンプルを動かしてみました。パフォーマンスの最適化等、まだまだこれから感はありますが、扇風機や椅子、ノートパソコンやiPhone等、大きさも形も全然違うものを認識してくれて未来を感じます。


試してみるだけなら機械学習やTensorFlowについての専門知識を必要としませんし、ぜひお手元で動かしてみてください!


次のステップとしては、下記記事で紹介されているテンソルの計算部分に特化してSwiftで書かれたライブラリと比較したりしつつ、ちゃんとTensorFlowでやっていることを理解したいと思います。


また、本記事同様に「とりあえず動かしてみる」シリーズとして、こちらもよろしければどうぞ:


*1:ちなみにこのとき、 https://github.com/miyosuda/TensorFlowAndroidDemo/find/master にある同名ファイルを使っても、ちゃんと動きません。参考

2016-04-16

GLKView の描画内容を AVAssetWriter を用いて動画としてエクスポートする

すごい雑なメモですが、ちゃんと書くにはまだ理解が足りてなくて、かといってローカルに放置するとまた同じことを一から自分で調べそうな気がするので、とりあえずアップ。


※古いコードを流用している部分もあるため、一部ObjC、一部Swiftです。


やりたかったこと

標題の通り、「GLKView の描画内容を AVAssetWriter に渡して動画として書き出す」ということがやりたかった。リアルタイムに処理する必要があって、要件としては20fps。


AVAssetWriterInputPixelBufferAdaptor オブジェクトがあって、

@property (nonatomic, strong) AVAssetWriterInputPixelBufferAdaptor *pixelBufferAdaptor;

こう生成した CVPixelBufferRef があって、

CVPixelBufferRef pixelBuffer = NULL;
CVPixelBufferPoolCreatePixelBuffer(nil, self.pixelBufferAdaptor.pixelBufferPool, &pixelBuffer);

ここに GLKView への描画内容を反映すれば、

[self.pixelBufferAdaptor appendPixelBuffer:pixelBuffer withPresentationTime:timestamp];

こんな感じで AVAssetWriter で動画エクスポートできる。


・・・ということはわかっていたけど、CVPixelBuffer に GLKView の描画内容をどうやったら渡せるのかがわからなかった。


試した方法1: テクスチャキャッシュを利用して OpenGL の FBO を書き出す

ググッてこちらで見つけた方法。以下にコードがある。

`CVOpenGLESTextureCacheCreate` と `CVOpenGLESTextureCacheCreateTextureFromImage` なるメソッドを使用してテクスチャキャッシュなるものを生成して Frame Buffer Object (FBO) を云々する(処理内容を理解できていないので適切な説明ができない)。GPUImage と同様の方法らしい。


自分のプロジェクトに移植してみたがうまく動かず、上のコードと何が違うのかにらめっこしていたが、READMEをよく読むと 元コードもちゃんと動作してない と書いてあり、リファレンスコードなしであれこれ試行錯誤する時間もないので、いったん別の方法を考えることに。


試した方法2: GLKView のスナップショットを取得する

UIView のスナップショット取得はそれなりに重い印象があったのと、リアルタイム処理(20fps)の必要がありなるべくUIKitのレイヤーで処理したくなかったので当初は思いついても頭から除外していた選択肢。


ただ方法1が頓挫して、今日中に落とし所を見つけたかったので、少々フレームレートが落ちてもいいので試してみよう、ということでこっちでやることに。


下記によると、GLKView の描画内容は `renderInContext:` ではスナップショットとれないらしい。Core Graphics だからそりゃそうか。

You need to grab the view's framebuffer pixel data using OpenGL ES. You can't do it with renderInContext:.


で、同回答にリンクがあったのが下記。

GPUImage の作者 Brad Larson さんの回答。`glReadPixels()` でピクセルデータを取り出す方法と、テクスチャキャッシュを利用する方法が提示されている。後者は方法1で断念した方向なので厳しい・・・


前者の `glReadPixels()` を利用する方法は、下記に UIImage に変換するまでのコードがあった。

- (UIImage*)snapshotRenderBuffer {

    // Bind the color renderbuffer used to render the OpenGL ES view
    // If your application only creates a single color renderbuffer which is already bound at this point, 
    // this call is redundant, but it is needed if you're dealing with multiple renderbuffers.
    // Note, replace "_colorRenderbuffer" with the actual name of the renderbuffer object defined in your class.
    glBindRenderbufferOES(GL_RENDERBUFFER_OES, viewRenderbuffer);

    NSInteger dataLength = backingWidth * backingHeight * 4;
    GLubyte *data = (GLubyte*)malloc(dataLength * sizeof(GLubyte));

    // Read pixel data from the framebuffer
    glPixelStorei(GL_PACK_ALIGNMENT, 4);
    glReadPixels(0.0f, 0.0f, backingWidth, backingHeight, GL_RGBA, GL_UNSIGNED_BYTE, data);

    // Create a CGImage with the pixel data
    // If your OpenGL ES content is opaque, use kCGImageAlphaNoneSkipLast to ignore the alpha channel
    // otherwise, use kCGImageAlphaPremultipliedLast
    CGDataProviderRef ref = CGDataProviderCreateWithData(NULL, data, dataLength, NULL);
    CGColorSpaceRef colorspace = CGColorSpaceCreateDeviceRGB();
    CGImageRef iref = CGImageCreate(
                                    backingWidth, backingHeight, 8, 32, backingWidth * 4, colorspace, 
                                    kCGBitmapByteOrder32Big | kCGImageAlphaNoneSkipLast,
                                    ref, NULL, true, kCGRenderingIntentDefault);

    // (sayeth abd)
    // This creates a context with the device pixel dimensions -- not points. 
    // To be compatible with all devices, you're meant to keep everything as points and a scale factor;  but,
    // this gives us a scaled down image for purposes of saving.  So, keep everything in device resolution,
    // and worry about it later...
    UIGraphicsBeginImageContextWithOptions(CGSizeMake(backingWidth, backingHeight), NO, 0.0f);
    CGContextRef cgcontext = UIGraphicsGetCurrentContext();
    CGContextSetBlendMode(cgcontext, kCGBlendModeCopy);
    CGContextDrawImage(cgcontext, CGRectMake(0.0, 0.0, backingWidth, backingHeight), iref);

    // Retrieve the UIImage from the current context
    UIImage *image = UIGraphicsGetImageFromCurrentImageContext();

    UIGraphicsEndImageContext();

    // Clean up
    free(data);

    return image;
}

(結局 Core Graphics を経由するのか。。)


で、最終的に以下の回答に行きつく。


あれ、`snapshot` なんてメソッドあったっけ?と思って調べてみたら、GLKView に元から用意されていた・・・!

@property (readonly, strong) UIImage *snapshot;

最終的にうまくいった方法

guard let cisnapshot = CIImage(image: snapshot) else { fatalError() }
drawImage = cisnapshot.imageByCompositingOverImage(drawImage)

glView.ciContext.render(
    drawImage,
    toCVPixelBuffer: pixelBuffer,
    bounds: drawImage.extent,
    colorSpace: CGColorSpaceCreateDeviceRGB())

上記コードの前提

  • GLKView の `snapshot` メソッドで取得した UIImage が `snapshot` に入っている
  • `drawImage` は諸々の処理を経由した CIImage オブジェクト

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 |