Visionの最新情報

(音楽)

Brett Keatingです 今日は Visionフレームワークの 新しい点についてお話します Visionを始めたばかりなら これが Visionフレームワークの 初めてのセッションかもしれませんね だとしたら ようこそ それではまず Visionフレームワークの 重要な点を簡単におさらいします 題して“Visionフレームワークの事実” Visionは2017年に導入され 以来 Visionの提供するテクノロジーを使って 数千もの優秀なAppが開発されてきました Visionはコンピュータビジョンの アルゴリズムの集まりで 時間と共に増え続け 例を挙げると 顔認証や 画像分類や輪郭検出など数多くあります どのアルゴリズムも 使いやすくて 一貫性のある APIを通してできています 1つのアルゴリズムの実行方法を学べば すべてのアルゴリズムが実行できます また Visionはサポートしている すべてのプラットフォームで Apple Siliconを最大限に利用し 多くの Visionアルゴリズムのコアで 機械学習を行っています Visionが利用可能なのは tvOSと iOSと macOSで Macの Apple Siliconの性能を フルに活用します 最近追加された人物セグメンテーションが 画面に出ていますね

そしてデモでお見せするのが 手のポーズの検出機能

そしてこちらが アクションとVisionのサンプルAppで 身体ポーズの検出と軌跡解析を使用しています 本日の内容は まず初めに 新しいリビジョンの概要で 既存の要求へのアップデートに増幅した機能や パフォーマンスまたは精度の 向上が見られるかもしれません

まずは 文字認識の 新しいリビジョンについてです これは VNRecognizeTextRequest Revision3による3回目のリビジョンです この文字認識デバイスにより Live Text機能が実現します 複数の言語をサポートしており サポートされている言語を知るには supportedRecognitionLanguagesを 呼び出してください 新しい言語が追加されたので 少し例をお見せしましょう Visionでは新たに 韓国語がサポートされています Visionが韓国語のレシートを テキスト化している例です そしてこちらが日本語での同様の例で これも Visionで 新たにサポートされた日本語での 文字認識の結果を示しています 文字認識には 新たな 自動言語識別機能が登場しました 使用言語の認識を特定する際には今でも recognitionLanguagesプロパティを 使うことができます ですが Appのユーザーが どの言語を認識してみたいか 前もって分からなければどうでしょうか? 正確な認識モードの場合のみになりますが 文字認識デバイスに自動で 言語を検出させるには automaticallyDetectsLanguageを Trueに設定すればいいのです

これを使用するのはどの言語を認識するのか 分からない場合だけにする方が賢明です 言語検出は時には間違えることもあるからです どの言語を認識するのか 前もって知っている場合も Visionに言語を特定させ automaticallyDetectsLanguageを オフにしたままがいいでしょう

次はバーコード検出の3度目のリビジョンで VNDetectBarcodesRequest Revision3と呼ばれています このリビジョンでは内部で 機械学習を利用していて これまでのリビジョンとは大きく違っています バーコードが作られるシンボル体系は様々で 店の商品でよく見るものやQRコードの他に ヘルスケアAppで 使われる特殊なコードもあります Visionがサポートする シンボル体系を知りたい場合は supportedSymbologiesを呼び出してください

次はパフォーマンスについてです 機械学習を使っているせいもあり コードを1つずつではなく 一度に複数検出するので 複数のコードを含む画像の要求も速くなります 正確さも上がったため 多数のコードを含む画像でも 検出できるコードが増え さらには重複検出が起こる場合もあります バウンディングボックスの向上も コードによっては見られ 特に以前は戻されていた ean13のような ライナーコードの場合です 今ではバウンディングボックスは 目に見えるコードすべてを取り囲みます

そして機械学習モデルは 検出の正確性を妨げていた 曲面や反射などのアーティファクトを 無視できるようになっています

文字認識とバーコード検出双方のリビジョンが 形成する技術的な土台が支えているのは ドロップインUI要素の VisionKitのAPIで バーコードや文字をスキャンし 戻せるよう設定します 我々のSDKへの実に素晴らしい追加内容で その詳細についてのセッション 「VisionKitで機械可読コードやテキストを キャプチャする」をご覧ください 本日お話する最後の新リビジョンは オプティカルフローの リクエストのリビジョンで VNGenerateOpticalFlow RequestRevision2と呼ばれます バーコード検出と同様にこの新リビジョンでも 最新の機械学習を内部で使っています

オプティカルフローは長期研究されてきた コンピュータビジョン問題ですが 文字やバーコードのような 日常的なものの検出に比べ その内容について 知られていないかもしれません オプティカルフローが分析するのは 2つの連続する画像で 典型的には動画のフレームです ユースケースに応じて動作を対象にするのは 2つの隣接フレームだったり 間のフレームを少し抜いたりしますが どの場合でも 2つの画像は 時系列順であるべきです

分析では 動作の方向と規模が どのくらいかを検出し 言い換えると 最初の画像の どのくらいの部分を“動かせば” 2つ目の画像に正しく 位置付けられるのかを検出します VNPixelBufferObservationがその結果で 画像のすべての場所での このような動作を表します これは2チャンネルの画像で 1チャンネルは Xの規模を もう1つはYの規模を表し 両方合わせて この2D画像に 配置された各ピクセルに 2Dベクトルを形成した後入力として提供された 画像内の対応する位置に 位置づけられるわけです 実際に見てみましょう 着信動画があり いくつかの フレームが送られてくる場合ですが 特にこの2枚の画像を見てください 犬が浜辺で走っています 左の画像から右の画像で 犬は少し左へと動いたようです この動作をどのように検出して表すのでしょう

オプティカルフローの実行で 下のような画像が出ます 色の濃い部分は動作が認められた部分で まさに犬の形にそっくりだと分かります このシーンで動いているのは犬だけだからです この画像で運動ベクトルの表示に 使っているのは“擬色”で―” カラーパレットにベクトルの XとYをマッピングするものです この擬色の提示では“赤”の色相が 主に左への動きを示しています 1つのフレームでの例を見たところで 動画クリップ全体を見てみましょう 浜辺で水のボトルを取りに行く犬の 短い動画に対し オプティカルフローを実行します 左側がリビジョン1を使用した結果で 右側は新しい機械学習ベースの リビジョン2を使った結果です リビジョン2での改善が見て分かるでしょうか? 一番 明らかだと思われるのは ボトルの動きがもっと正確に 捉えられている事です 検出された犬の動きも 改善された部分がありますね 私は尻尾が最も明確だと思いますが 耳の動きも新リビジョンではよく分かりますね リビジョン1では少し 背景ノイズも入っていますが リビジョン2では一貫して背景は不動のままです このテクノロジーの仕事ぶりを ご理解いただけたでしょうか ではAppでの使い方について 少し掘り下げて行きましょう 明らかに主なユースケースは 動画での局所運動の発見です これはセキュリティビデオの ユースケースに直接使え 背景から分離した局所運動を 直接 識別します オプティカルフローは セキュリティカメラのような 固定カメラに最適だと言わざるを得ません 動画の中で動いているオブジェクトの追跡には Visionのオブジェクト トラッカーも使用できますが トラッカーの初期化場所を 知っている必要があります オプティカルフローはここでも役に立ちます コンピュータビジョンや 画像処理経験をお持ちなら オプティカルフローの結果を利用すれば 動画処理能力を更に高められます 動画の補間や動作分析を行う場合などは オプティカルフローの情報が 非常に有益になります リビジョン1と2におけるその他の違いについて 詳しく見ていきましょう リビジョン1は常に入力時と同じ解像度の オプティカルフロー場を戻します リビジョン2もデフォルトでそうなっていますが わずかな違いがあり その理由は リビジョン2は機械学習ベースなので 基礎的モデルの出力は ほとんどの入力画像より 解像度が低いという事です そのためリビジョン1の デフォルト動作に匹敵するには アップサンプリングが必要で バイリニア法で行っています アップサンプリングとは 何かを画像でお見せします 左側は ネットワーク出力を拡大した一部で 解像度が低いためにピクセル化しています フローフィールド全体は 7対5のアスペクト比です 右側は同じフィールドから取った 同じ部分ですが オリジナルの画像解像度に アップサンプルしてあります 恐らくアスペクト比も違い 16対9ぐらいでしょうか フローフィールドの端がバイリニア法の アップサンプリングで スムーズになっていますね アスペクト比が異なる可能性があるために アップサンプリング処理の一環として フロー画像はストレッチされ フローフィールドを画像に起こった内容と 適合させようとします ネットワーク出力に直接 作業している場合は フロー結果をオリジナルの 画像にマッピングする際 同じように解像度とアスペクト比を 計算しましょう

アップサンプリングを スキップする選択肢を選ぶなら keepNetworkOutputを リクエスト時にオンにしましょう これで 生のモデル出力になります 4つの computationAccuracy設定が リクエストに適用可能で 利用可能な出力解像度を 選べるようになっています 各精度に対する解像度がこの表に出ていますが 検証に含まれるピクセルバッファの幅と高さを 必ずチェックしましょう ネットワーク出力や Visionのアップサンプリングを 使う場合の決定基準とは? 既にオプティカルフローを使っていて 動作の後方互換性を保ちたいなら デフォルトの動作がベストでしょう 出力のアップサンプルを望み バイリニア法が認められ 追加のメモリやレイテンシを 得る価値がある場合も同様です 最大解像度が不要で急いで対応物が形成したり トラッカーを初期化したいだけなら ネットワーク出力がベストです 最大解像度が必要でも 自分のアップサンプリング方法を使うのなら ネットワーク出力も正しい選択肢になり得ます 新アルゴリズムのリビジョンは これで網羅しました 次は Visionフレームワークの大掃除の内容と その影響についてお話していこうと思います 顔認証および顔ランドマーク検出は 5年前の Visionリリース時に初めて導入され 各アルゴリズムのリビジョン1とされました 以来 2つの新しいリビジョンをリリースし どちらもより効果的で正確な テクノロジーを使っています それゆえ Visionフレームワークから アルゴリズムのリビジョン1を削除し リビジョン2と3のみを 残しておくことになりました ですが リビジョン1を使っていても大丈夫です リビジョン1に特化したコードや リビジョン1しか含まない SDKにコンパイルされたコードも サポートは続けられます 可能なのかと疑いますか? リビジョン1が内部で実行するアルゴリズムを この図では “リビジョン1の 検出器”と呼んでいます 同様に リビジョン2のものは “リビジョン2の検出器”です Visionのこのリリースでは リビジョン2の検出器の出力を使って リビジョン1のリクエストを満たしました そして リビジョン1のリクエストは 非奨励としてマークされます これによりリビジョン1の検出器は 完全に削除でき Visionフレームワークの 合理化が維持できたわけです その利点は複数あり とりわけ重要なのが ディスクのスペースの節約で OSリリースや SDKのダウンロードや インストールの経費が削減されました Vision専門家の皆さんは 首をかしげているかもしれませんね “リビジョン2は1と違って 逆さまの顔を戻すけど” “Appによっては影響を受けるのでは?”と 確かにそうですが リビジョン1の動作を維持するために 我々は予防策を講じています リビジョン2の検出器から 逆さの顔を戻したりしません 同様に リビジョン2の顔ランドマーク検出器も リビジョン1に合わせた結果を戻します 実行時間は同じですが 正確さは大きく改善していると 実感するはずです どの場合でもこの変更はApp側に コードの調整を要求することなく 今まで通りに作動します

ですが 皆さんに行動喚起を行いたいと思います リビジョン1で満足しないでください 遥かに優れた選択肢があるのですから 最新のリビジョンがお勧めで つまりは リビジョン3を お勧めするという事です

もちろん その主な理由は 最新のテクノロジーが最高レベルの精度と パフォーマンスを提供し 誰しも満足できるからです 何度も確立しては色々と話を聞いたりした今 また繰り返しになりますが デフォルト動作に頼るより常にリビジョンを 明確に指定したほうが良い結果が出るものです これで大掃除のお話は終わりです 今度 お話するのは Visionフレームワークを使った Appのデバッグが容易になった事です Visionに Quick Lookの プレビューサポートを加えました Visionに特化した変化があるのでしょうか? デバッガの VNObservationsに マウスを持ってきて クリックするだけで 入力画像の結果が視覚化されます Xcode Playgroundsでも利用可能になっています 実際にお見せする方がどんな利点があるのか 分かりやすいですね Xcodeのデモに移ります

顔ランドマークを検出して顔観察を戻すという シンプルな日常的作業です まずは 顔ランドマークの リクエストを設定します 分類に入れられる画像があれば それを表示します 次に 配列を宣言して結果を維持します

autoreleasepoolの中で リクエストハンドラを その画像でインスタンス化し それからリクエストを実行します 全てが上手く行けば リクエストから 結果を取得できるわけです 実行してみて 結果取得の後に ブレークポイントを見ていきましょう では デバッガ内を見ます マウスを結果に持っていくと 3つの顔を検出した事を示しています いいですね　入力画像には 確かに3つの顔があります ですが どの観察がどの顔なのか 判断する方法は? ここで役に立つのが Quick Look プレビューサポートです ここでそれぞれの目の アイコンをクリックすると 結果を視覚化してくれます 顔ランドマークの座標や バウンディングボックスを表す 画像が表示されます

最初の観察が画像のどこなのか これで分かります

次を押せば2つ目の観察その次は3つ目の観察が 表示されるわけです

次のブレークポイントですが デバッグコンソールに 顔観察をプリントするコードを実行します ご想像どおり顔情報がプリントされる デバッグコンソールではどの顔がどれで プリントされた座標から結果が正しいかを 瞬時に判断するのはかなり困難な事です

ですが ここでもう1つ注意すべき点があります autoreleasepoolの導入でリクエストハンドラを 無理やりスコープ外に出した事に お気づきでしょうか リクエストハンドラはスコープ外なので Quick Lookプレビューサポートを 結果に使ってみましょう ご覧のようにオーバーレイは描かれますが 画像は出てきません

覚えておきたい点です リクエストハンドラを使って 観察を生成したいなら スコープ内に入れておかないと Quick Lookプレビューサポートは オリジナル画像が表示できません 画像のリクエストハンドラが 入力画像のある場所にあるためです 問題なく機能しますが画像は出てきません Quick Lookプレビューサポートは Xcode Playgroundで 特に役立つという事が 簡単な実験から見て取れます それを見てみましょう バーコードの画像分析のための 簡単な Playgroundsです コードを説明するよりも少し修正を加えて 結果に与える影響を見ていくことにしましょう 異なるシンボル体系を持つ 2つのバーコードの画像に リビジョン2を使用します すべての結果を要求すれば すべてが一度に表示され 最後には最初の結果がまた表示されます

リビジョン2には2つほど問題がありますね 1つ目は 最初のバーコードを検出していません そして2つ目のバーコードを2回検出しています そしてバーコードに線を引いているだけで 完全なバウンディングボックスではありません

ではリビジョン2の代わりに リビジョン3を使ったら?

まずは 両方のバーコードが検出されています そして線の代わりに 完全な バウンディングボックスです Quick Lookプレビューサポートの 素晴らしい点は 結果を可視化するのに様々な効用関数を書く 必要が無くなった事です デバッガや Xcode Playgroundで画像に直接 重ねて表示できます

Visionでの Quick Look プレビューサポートは以上です これでどの観察がどれのものか 判断しやすくなりました 画像リクエストハンドラがスコープ内にあれば 入力画像と一緒に使えますし Xcode Playgroundサポートで Visionフレームワークコードの ライブチューニングが容易になれば幸いです 本日は Visionの重要な アップデートについてお話しました 簡単にまとめると 新たなリビジョンを加えたのは 文字認識と バーコード検出と オプティカルフローです

リビジョンの更新を続ける際に 古いものを排除することで リビジョンを最新の状態に保ち 最新かつ最高のテクノロジーを使いましょう また Quick Lookプレビューサポートで Visionのデバッグ用Appを はるかに使いやすくしました それでは皆さんご清聴ありがとうございました