より応答性の高いカメラ体験の実現

♪♪

Rob: こんにちは Camera Software Teamの Rob Simutisと Photos Teamの Sebastian Medinaです 私どものセッションへようこそ AVFoundationキャプチャクラスと PhotoKitフレームワークにおける たくさんの 新しい強力なAPIをご紹介します まず 写真の遅延処理について説明します 次に 実際にシャッターラグをゼロにして 瞬間を捉える方法をお見せします 3番目に 新しいResponsive Capture APIついて説明します 最後に アップデートされたビデオエフェクトに 対応するための別の方法について説明します iOS 13以降 AVCapturePhotoSettingの photoQualityPrioritization 列挙値を使用することで 応答性 つまり キャプチャして処理済みの写真を取得し 次の写真を撮影できるまでの時間を 変更できます アプリでは適切な応答性を実現するために さまざまな列挙値から選択できますが 画質に影響が出ます または 常にqualityを使用したい場合 ショット間の時間に 影響を与える可能性があります iOS 17でも このAPI は引き続き使用できますが より高品質な写真を取得しながら 希望のショットを取得できる 可能性を高めれる 新しい補完的なAPIを提供します 私のチームが セッションのために作成した このアプリについて説明します 各トグルスイッチを 「オン」に切り替えることで 今年の新機能を有効にすることができ コンセプトを1つずつ構築して より応答性の高い 写真撮影体験を実現していきます それでは 写真の遅延処理から始めましょう 現在 AVCapturePhotoOutputから 最高品質の写真を取得するには 写真をキャプチャするときに設定で photoQualityPrioritization列挙値で 「quality」を使用します 「balanced」と「quality」の場合 通常 ある種の複数フレームのフュージョンと ノイズリダクションが含まれます iPhone 11 Pro以降のモデルでは 最も高度な技術の1つが 「Deep Fusion」と呼ばれます これにより 高解像度の写真に 驚くほど鮮明なディテールが得られます このDeep Fusionショットでは オウムの羽が 非常にシャープで際立っています しかし これにはコストがかかります この処理は 次のキャプチャリクエストが 開始される前に完了する必要があり 完了までに時間がかかる場合があり ます 実際の例を見てみましょう Camera Software Teamが どのようにオフィスに通って 仕事を進めているのか プレゼンテーション資料をまとめています 同僚のDevinが最新の自転車技術で Apple Parkを移動しています タップしながら シャッターボタンが 1枚のショットで回転し終わるのを待って 次のショットを撮影します 仕上がりは素晴らしい Deep Fusionの写真です そのヒゲのディテールを見てください！ しかし タップしている間 処理は同期的に実行され ショットからショットまでの時間が 少し遅く感じられます ディテールが鮮明で良い写真が 撮れたかもしれませんが 私が求めていた写真とは ちょっと違うかもしれません イベントダイアグラムを確認してみましょう 設定を使用してAVCapturePhotoOutputの CapturePhotoメソッドを呼び出すと デリゲートはプロセスのさまざまな時点で コールバックを受け取ります たとえば resolvedSettingsの willBeginCaptureなどです カメラソフトウェアスタックは センサーからフレームを取得し 処理技術を使用してフレームを Deep Fusion画像へと融合します そして didFinishProcessingPhotoの デリゲートコールバックを通じて 写真が戻されます この処理は次のキャプチャが行われる前に 完了する必要があり 時間がかかる場合があります didFinishProcessingPhotoコールバックが 起動する前にCapturePhotoを 呼び出すこともできますが 前の写真の処理が 完了するまでは開始されません 写真処理を延期すると このタイムラインは縮小します 写真をリクエストすると それが適切な場合 新しいDidFinishCapturing DeferredPhotoProxyの デリゲートコールバックを介して 軽く加工された「プロキシ」写真を送ります このプロキシ写真をプレースホルダとして ライブラリに保存します そしてすぐに次の写真を撮ることができます カメラセッションが終了すると システムはあとで処理を実行して 最終の写真を取得します したがって アプリの設定で 写真の遅延処理をオンにすると 必要に応じてキャプチャ時に プロキシ写真を送るように キャプチャ セッションが再設定されます 以前と同じようにシャープで 非常に鮮明な写真を撮ることができます 最終処理を後回しにすることで その瞬間に もっと多くの写真を撮ることができます いいウイリーだ あのバイクは頑丈です これでいいです ヒゲも含めて 私のプレゼンには最高の写真です では 遅延処理された写真を 得るためにインタラクションする すべての部分を見てみましょう 以前のダブダブのプレゼンテーションから 簡単に復習すると 写真をキャプチャするために AVCaptureSessionを設定するとき AVCaptureDeviceInputと AVCaptureDevice つまりカメラをセッションに追加します 次に AVCapturePhotoOutputを セッションに追加します 特定のフォーマットまたは セッション プリセットを選択すると 通常は アプリがphotoOutputで capturePhotoを呼び出すときに 「Photo 」 セッションプリセットを選択します 遅延写真処理に適したタイプの写真の場合は didFinishCapturing Deferred Photo Proxy を使用してコールバックします そこからプロキシデータを フォトライブラリに送ります つまり 今ライブラリにあるのはプロキシ写真です しかし 最終的には最終的な画像を 使用または共有したいと思うでしょう 最終的な写真処理はリクエストに応じて オンデマンドで行われます ライブラリから画像データが返されるか デバイスがアイドル状態であるなど システムが適した条件であると判断すると バックグラウンドで実行されます それでは 同僚のSebastianに これを コード化する方法を教えてもらいましょう よろしく Sebastian ありがとう Rob こんにちは 私はSebastian Medinaです Photos Teamのエンジニアです 今日は 最近撮影した画像を PhotoKitに取り込み 遅延処理を トリガーする方法を説明します 次に 同じ画像をリクエストして PHImageManagerリクエストから 画像を受け取る際の新機能を示します ただし PhotoKitを使用して アセットを処理する前に 遅延処理用の新しいCamera APIが 設定されているかを確認する必要があります これにより私のアプリはPhotoKit経由で 送れる遅延写真プロキシ画像を 受け入れることができます では これを利用するコードを書いてみましょう AVCapturePhotoOutputおよび AVCaptureSessionオブジェクトの設定です これで セッションの構成を開始できます この場合 遅延処理を利用できるように セッションに タイプ写真のプリセットが必要です 次に キャプチャデバイスを取得して デバイス入力をセットアップします 次に 可能であれば デバイス入力を追加します 次にphotoOutputが 追加できるか確認してみます もしそうなら それを追加します さて 新しいものについてです 新しいautoDeferredPhotoDeliver Supported値がtrueかどうかを確認して キャプチャした写真を 遅延処理で送れるかどうかを確認します これが成功したら autoDeferredPhotoDeliverEnabledの プロパティで 新しい遅延写真配信を選択できます 遅延写真を有効にするために Cameraコードに追加する必要があるのは この遅延写真配信の チェックと有効化だけです 最後に セッション設定をコミットします これで capturePhotoメソッドの 呼び出しが行われると 受信するデリゲートコールバックは 遅延プロキシオブジェクトを保持します これらのコールバックの 1つの例を確認してみましょう この写真キャプチャコールバックでは 最近キャプチャした画像に関連する AVCapturePhotoOutputおよび AVCaptureDeferredPhotoProxy オブジェクトを Cameraから受信しています まず 適切な写真出力値の 受信の確認をお勧めします そのため error パラメーターの値を確認します さて ここからはPhotoKitを使って 画像をフォトライブラリに保存していきます 共有のPHPhotoLibraryに変更を加えます フォトライブラリへの書き込みアクセス権が 必要なことだけは注意してください 次に AVCaptureDeferredPhotoProxy オブジェクトから 写真データをキャプチャします

フォトライブラリの変更を行うため 関連する PerformChangesインスタンスメソッドを 設定する必要があります あらゆるアセットをセーブするのと同じように PHAssetCreationRequestを使用します 次に リクエストに応じて 「addResource」メソッドを呼び出します パラメーターにはnewPHAssetResourceType 「.photoProxy」を使用します これはPhotoKitに画像の遅延処理を トリガーするよう指示するものです 次に 以前にキャプチャした プロキシ画像データを追加できます この場合 オプションは使用しません ここで重要なことは 遅延処理を必要としない画像データに この新しいリソースタイプを使用すると エラーになるということです エラーについて言えば 完了ハンドラ内でエラーを確認してみます とても簡単です アプリケーションが 適切であると判断した場合は 完了ハンドラ内で 成功とエラーを処理してください ここで アセットを取得したいとします これはPHImageManager リクエストを通じて実現できるので そのためのコードを調べます パラメータには PhotoKit経由で送信した 画像のPHAssetオブジェクト 返される画像のターゲットサイズ およびコンテンツ モードがあります デフォルトのPHImageManagerオブジェクトを 取得します 次に imageManagerオブジェクトを使用して requestImageForAssetメソッドを 呼び出すことができます パラメーターには 以前にフェッチしたアセットや ターゲットサイズ コンテンツ モードを使用します この場合 オプションは使用しません これで resultHandlerを通じて コールバックを処理できるようになりました resultImageはUIImageであり infoは画像に関する辞書です 現在 最初のコールバックは情報辞書キー PHImageResultIsDegradedKeyを持つ 低解像度の画像を保持しますが 最後の画像コールバックは保持しません そう ここで確認できます PhotoKitで 加工画像を作成できるようになったことで デベロッパが requestImageForAssetメソッドから 二次画像を受け取るとれる新しいAPIを 導入する良い機会になりました 遅延処理中の画像が完成するまでに 時間がかかる場合があるため その間にこの新しい 二次画像を表示できます この新しい画像を受け取るには PHImageRequestOptionsの新しい allowSecondaryDegradedImageを使います この新しい画像は requestImageForAssetメソッドからの 現在の2つのコールバックの 間に配置されます 画像に関する情報辞書と PHImageResultIsDegradedKey のエントリがあり これは今日最初の イメージ コールバックで使用されます 何が起こっているのかを わかりやすく説明するために 現在 requestImageForAssetメソッドで 2つの画像を提供します 最初の画像は 最終的な高画質画像を準備する間に 一時的に表示するのに適した 低画質画像です この新しいオプションを使用すると 現在の2つの画像のうち 最終画像の処理中に表示する 新しい高解像度画像が提供されます この新しい画像を表示すると 最終画像の処理が完了するまでの間 ユーザーはより快適なビジュアル体験を 得ることができます では これを利用するコードを書いてみましょう ただし今回は PHImageRequest Optionsオブジェクトを作成します 次に 新しい allowSecondaryDegradedImage オプションをtrueに設定します これで リクエストは新しい二次画像 コールバックを送り返す必要性を認識します ここでは 先に作成した requestImageForAssetメソッドを 再利用できます ただし作成したばかりの画像リクエスト オプションオブジェクトを追加します 新しいセカンダリ画像情報辞書は 最初のコールバックと同様に PHImageResultIsDegradedKeyの true値を保持するため ここでそれを確認します 新しい二次画像表現を 受け取るのはこれで終わりです アプリを最適にサポートするために 必ず結果ハンドラ内で 画像を処理してください これで 遅延処理を使用して 画像を写真ライブラリに追加する方法と 最終画像の処理が 完了するのを待っている間に アプリで表示する画像リクエストから 高品質の二次画像を 受け取る方法がわかりました これらの変更は 新しい遅延処理 PhotoKitの変更とともに iOS 17 tvOS 17 macOS Sonoma 以降で利用可能になります ここで Robに引き継ぎます より応答性の高いカメラを作成するための 新しいツールについて詳しく説明するために すばらしいですね ありがとうSebastian! 遅延写真処理を 快適に体験していただくために 詳細を見ていきましょう まずはフォトライブラリから始めます 遅延写真処理を使用するには プロキシ写真を保存するための 写真ライブラリへの書き込み権限が必要です また アプリで最終写真を表示する必要や 何らかの方法で写真を変更する場合は 読み取り権限が必要です ただし みなさんの顧客に代わって 最大限のプライバシーと 信頼を維持するために 必要最小限のアクセスのみを リクエストする必要があることを 忘れないでください また プロキシを受け取ったら そのfileDataRepresentationを できるだけ早くライブラリに 取り込むことを強くお勧めします アプリがバックグラウンドになっている場合 システムがアプリを一時停止するまでの 実行時間が限られています メモリの負荷が大きくなりすぎると バックグラウンドのウィンドウ中に アプリがシステムによって自動的に 強制終了される可能性があります できるだけ早く プロキシをライブラリに取り込むことで 顧客のデータ損失の可能性を 最小限に抑えることができます 次に 通常 フィルタの適用など 写真の ピクセルバッファに変更を加えた場合 またはAVCapturePhoto File Data Representationカスタマイザを使用して AVCapturePhotoのメタデータや その他のプロパティに変更を加えた場合 これらは処理が完了すると 有効になりません これは 後でPhotoKit APIを使用して 写真を調整するために行う必要があります また コードは同じセッション内で 遅延プロキシと非遅延写真の 両方を処理できる必要があります すべての写真が追加の手順を必要として 処理できるわけではないからです たとえば「quality」の photoQualityPrioritizaion列挙値で 撮影されたフラッシュキャプチャは Deep Fusion写真のようにショット間の 節約の恩恵を受ける方法では処理されません また AVCapturePhotoSettingsには オプトインまたはオプトアウトの プロパティがないことに 気づくかもしれません これは延期された写真の処理が 自動的に行われるためです オプトインすると より長い処理時間が 必要な写真を撮影する場合 プロキシが送信されます ふさわしくない場合は 最終的な写真が送信されますので ショットごとにオプトインまたは オプトアウトする必要はありません 必要なのは キャプチャセッションを開始する前に AVCapturePhotoOutputに isAutoDeferredPhotoProcessingEnabledを trueとして指定することだけです 最後に ユーザーエクスペリエンスについて 話しましょう 写真の遅延処理により ショット間の時間が短縮され 最高の画質が得られます しかし それは最終処理を 後の時点まで遅らせるだけです ユーザーが共有や編集のために すぐに画像を必要とし 私達が提供する 最高品質の写真には あまり興味がないようなアプリであれば 遅延写真処理の使用を避けるのが 合理的かもしれません この機能は iPhone 11 Pro および11 Pro Max以降の iPhoneで利用可能です また AVCapturePhotoOutputの操作と ライブラリのアクセス許可の処理に関する 素晴らしい関連ビデオもあります さて ゼロシャッターラグに移り スケートボードについて話しましょう Camera Software Teamの移動手段の 今後のプレゼンテーションのために 私たちはスケートパークに行って 映像を撮りました iPhone 14 Proのアクションモードで 同僚を撮影しているのですが スライド用に高品質のヒーローアクション ショットも撮りたいと考えています ただし ネタバレに注意してください 私はスケートボードはしません 私はシャッターボタンをタップして 宙に浮いている同僚のTomoを撮りました カメラロールで写真を確認すると こんな感じでした ジャンプの最高潮のところで シャッターを押しましたが 写真は着地時です それはまさに 私が望んでいたものとは違います 何か起こったのでしょう？ シャッターラグです シャッターラグが発生しました 「シャッターラグ」は キャプチャをリクエストして センサーから 1つ以上のフレームを読み取って 写真に合成して配信するときの 遅延と考えることができます ここで 時間は左から右に進みます 左が古いフレーム 右が新しいフレームです フレーム5が カメラのファインダーにあるとします 現在 AVCapturePhotoOutputの設定で capturePhotoを呼び出すと カメラのパイプラインが センサーからフレームを取り込み始め 私たちの処理技術を適用します キャプチャされたフレームのブラケットは フレーム5以降から始まります 得られるのは フレーム6から9 またはそれ以降の写真です 1秒あたり30フレームの場合 各フレームは 33ミリ秒間ファインダ―に表示されます 大したことないように聞こえますが 実際にはアクションが終わるまでに それほど時間はかかりません Tomoが着地するには 十分な長さだったので 私はそのヒーローショットを撮り損ねました ゼロシャッターラグを有効にすると カメラパイプラインは 過去のフレームの ローリングリングバッファを保持します さて ファインダーに映るのはフレーム5です タップしてキャプチャすると カメラパイプラインが 少しタイムトラベルを行い リングバッファからフレームを取得して それらを結合すると 欲しかった写真が手に入ります そこで アプリの設定ペインの 2番目のトグルを使用して ゼロシャッターラグを有効にすると Tomoが宙に浮いたときに シャッターボタンをタップすると プレゼンテーションに望んでいた 「ヒーロー」ショットの1つが得られました アプリでシャッターラグをゼロにするために 必要なことをお話ししましょう まったく何もありません！ iOS17以降にリンクしたアプリの AVCaptureSessionPresetsと AVCaptureDeviceFormatsで isHighestPhotoQualitySupportedが trueの場合 ゼロシャッターラグを有効にしました ただし テスト中に 希望する結果が得られない場合は AVCapturePhotoOutput .isZeroShutterLagEnabledを falseに設定してオプトアウトできます また 出力がセッションに接続されたら isZeroShutterLagSupportedが trueかどうかを確認することで photoOutputが構成されたプリセット またはゼロシャッターラグのフォーマットを サポートしているかどうかを確認できます フラッシュキャプチャ マニュアル露出用の AVCaptureDeviceの設定や ブラケットキャプチャ および 複数のカメラからの同期フレームである 構成写真配信などの 特定のタイプの静止画キャプチャでは ゼロシャッターラグは得られません カメラパイプラインは リングバッファからフレームを取得するため 過去に戻っているので キャプチャを開始するジェスチャと 写真出力のphotoSettingsの 送信の間に 長い遅延がある場合 ユーザーは 写真に手ぶれを引き起こす 可能性があります したがって タップイベントと写真出力の CapturePhoto API 呼び出しの間に行う 作業を最小限に抑える必要があります より応答性のある写真体験を 実現するための機能の締めくくりとして 次に Responsive Capture APIについて説明します これは顧客が 重複したキャプチャを撮影したり 写真の品質を調整して ショット間の時間を優先したり 次の写真をいつ撮影できるかについて 優れたUIフィードバックを提供したり できるようにするAPIのグループです まず メインAPIである レスポンシブキャプチャです スケートパークに戻り 先ほどの2つの機能を有効にすると 1秒間に約2枚の写真を撮ることができます わかりやすくするために 映像の速度を落としています 1秒あたり2フレームでは 空中での Tomoの動きはあまり見えませんが これが最終的に最高の写真になりました かなり良いですが もっと良くできるか見てみましょう ここで3番目と4番目のスイッチをオンにし Responsive Capture機能を有効にします Fast Capture Prioritization もう少し詳しく説明しましょう でもその前に 公園に戻りましょう！ そして もう一度試してみましょう レスポンシブキャプチャを使用すると 同じ時間でより多くの写真を撮れるので ちょうどいい写真を撮るチャンスが増えます そして 私のプレゼンテーションの 冒頭に撮った「ヒーロー」の写真があります チームもきっと気に入ってくれるでしょう！ 設定メソッドを使用したAVCapturePhoto Output.capturePhotoの呼び出しは センサーからのフレームをキャプチャし それらのフレームを 最終的な非圧縮画像に処理し 写真をHEIC または JPEGにエンコードするという 3つの異なる段階を経ると 考えることができます エンコードが完了すると 写真出力はデリゲートの didFinishProcessingPhoto コールバックを呼び出すか 遅延写真処理APIをオプトイン している場合は 適切なショットであれば おそらくdidFinishCapturing Deferred Photo Proxyを呼び出します ただし「キャプチャ」フェーズが完了し 「処理」が開始されると 理論的には 写真出力によって別のキャプチャが 開始される可能性があります そして今 その理論は現実となり アプリで利用できるようになりました メインのResponsive Capture APIを オプトインすると 写真出力がこれらのフェーズと重なり 別のリクエストが処理フェーズにある間に 新しい写真キャプチャリクエストを 開始できます より高速で一貫性のある連続ショットを 顧客に提供できます これにより 写真出力で使用される ピークメモリが増加するため アプリも大量のメモリを使用している場合 システムへの負荷に注意してください この場合 オプトアウトすることをお勧めします タイムライン図に戻ります ここでは2枚の写真を続けて撮影します デリゲートは写真Aの willBeginCaptureForsolvedSettingsおよび DidFinishCaptureForsolvedSettingsに対して コールバックされます しかし その場合 写真がエンコードされて配信される 写真AのdidFinish Processing Photo コールバックを取得する代わりに 写真Bの最初のwillBeginCaptureFor resolvedSettingsを取得できます 現在2つの処理中の 写真リクエストがあるため コードがインターリーブされた 写真のコールバックを 適切に処理していることを 確認する必要があります オーバーラップした応答性の 高いキャプチャを取得するには まずゼロシャッターラグがサポート されている場合は それを有効にします レスポンシブキャプチャのサポートを 受けるには オンにする必要があります AVCapturePhotoOutput isResponsiveCaptureSupported APIを使用して 写真出力がプリセットまたはフォーマットで サポートしていることを確認し AVCapturePhotoOutputを 設定してオンにします .isResponsiveCaptureEnabledを true に設定します 先ほど 「fast capture prioritization」を 有効にしたので それについて簡単に説明します 写真出力用にオンにすると 複数の写真出力が検出されます キャプチャは短期間で行われ これに応じて ショット間の 時間を維持するために 写真の品質を最高の品質設定から よりバランスのとれた 「balacned」品質設定に調整します これは写真の品質に影響を与える可能性が あるためデフォルトではオフになっています カメラアプリの設定ペインでは これを 「Prioritize Faster Shooting」 と呼びます デフォルトでは一貫したショット間の時間 がより重要であると考えているため カメラアプリに対してデフォルトで オンにすることを選択しましたが アプリや顧客によっては 異なる選択が可能です もうご想像のとおり 写真出力の 「isFastCapturePrioritizationSupported」 プロパティで サポートされているかどうかを確認できます また サポートされている場合は 自分または顧客の場合に その機能を使用したい場合は 「isFastCapturePrioritizationEnabled」を trueに設定できます ここで ボタンの状態と 外観の管理についてお話しましょう 写真出力は 次のキャプチャを開始する 準備ができているとき または処理中のインジケータを提示でき 写真キャプチャボタンを 適切に更新することができます これは AVCapturePhotoOutput CaptureReadiness と呼ばれる列挙型の値によって行われます 写真出力は「notRunning」 「ready」 および3つの 「not ready 」状態に なる可能性があります 「Momentarily」「waiting for capture」 または「waiting for processing」です 「not ready」列挙型は 設定してCapturePhotoを呼び出すと キャプチャと写真配信までの 待ち時間が長くなり 前に説明したシャッターラグが 増加することを示しています アプリは新しいクラス AVCapturePhotoOutputReadinessCoordinator を使用して状態変更をリッスンできます Photo Outputの 準備状態が変更されると 指定したデリゲートオブジェクトへの コールバックが行われます Responsive Captureまたは Fast Capture Prioritization APIを 使用しない場合でも このクラスを使用できます Readiness Coordinatorと Readiness enumを使用して シャッターの可用性を伝え ボタンの外観を変更する方法を 次に説明します このセッションのアプリは 「not ready」列挙値を処理するとき キャプチャボタンのユーザー インタラクションイベントをオフにして 複数のタップで追加のリクエストが 誤ってエンキューされ 長いシャッターラグが発生するのを防ぎます タップして 設定リクエストを含む CapturePhotoがエンキューされると captureReadiness状態は .readyと.notReadyMomentarily 列挙値の間になります Flashキャプチャは.notReady WaitingForCapture状態になります フラッシュが発光するまで 写真出力はセンサーからフレームを 取得していないためボタンは暗くなります 最後に ゼロシャッターラグのみを使用し 今年の他の機能を使用しない場合は .notReadyWaitingForProcessing 列挙値が現在の準備状態である間 各写真のキャプチャと処理が完了するときに スピナーが表示される可能性があります そこで レディネスコーディネーターを コードで利用する方法を紹介します まず 写真出力の レディネスコーディネーターを作成し 準備状態に関する コールバックを受け取る 適切なデリゲートオブジェクトを設定します 次に 各キャプチャ時に 通常どおりに写真設定をセットアップします 次に それらの設定に対する キャプチャリクエストの 準備状態の追跡を開始するように レディネスコーディネーターに指示します 次に 写真出力で CapturePhotoを呼び出します 次に レディスコーディネーターは captureReadinessDidChange デリゲートコールバックを呼び出します 受信した準備列挙値に基づいて キャプチャ ボタンの状態と外観を更新し 次にいつキャプチャできるか 顧客に最適なフィードバックを提供します Responsive Captureおよび Fast Capture Prioritization APIは A12 Bionicチップ以降の iPhoneで利用でき Readiness Coordinatorは AVCapturePhotoOutputが サポートされていればどこでも利用できます これで アプリですべての新機能が有効になり 可能な限り最も応答性の高い カメラエクスペリエンスが得られ 非常にシャープで高品質の写真が得られます エクスペリエンスを向上させるために それらをすべて使用する必要はありません アプリに適したものだけを使用できます 今日のセッションは ビデオエフェクトのアップデートで終了します これまで macOSのコントロールセンターには カメラ ストリーミング機能の オプションが提供されていました センターフレーム ポートレート そしてスタジオ照明などです macOS Sonomaでは ビデオエフェクトをコントロールセンターから 独自のメニューに移動しました カメラや画面共有のプレビューが表示され ポートレートモードやスタジオ照明などの ビデオエフェクトを有効にできます ポートレートおよびスタジオ照明は 明暗度を調整できるようになり スタジオ照明はより多くのデバイスで 利用できるようになりました そして「リアクション」と呼ばれる 新しいエフェクトタイプが追加されました ビデオ通話中に 発言者を中断せずに続けさせながら アイデアが気に入っていることを表現したり 良いニュースについて 賛意を表したりしたい場合があります リアクションは 風船 紙吹雪などとビデオを シームレスに融合します リアクションはポートレートおよび スタジオ照明エフェクトに従います これらはアプリでコードを変更する 必要がなく すぐに使用できる システムレベルのカメラ機能です ポートレートおよびスタジオ照明 エフェクトの詳細については 詳細については 「カメラキャプチャの新機能」をご覧ください ビデオストリームでリアクションを 表示する方法は3つあります まず macOSの 新しいビデオエフェクトメニューの 下のペインにある リアクションエフェクトをクリックします 次に アプリは AVCaptureDevice.performEffectを リアクションタイプに対して 呼び出すことができます たとえば アプリのビューの1つに 一連のリアクションボタンがあり 参加者がクリックして 反応を実行できるとします 3番目に リアクションが有効な場合 ジェスチャでリアクションを送れます これを確認してみましょう サムズアップ サムズダウン 2つのサムズアップで花火 ハート 1つのビクトリーサインで風船 2つのサムズダウンで雨 2つのビクトリーサインで紙吹雪 そして私の個人的なお気に入りである 角2つでレーザーを使うことができます いやあ 素敵なエフェクトがいっぱいです キャプチャセッションで使用したい AVCaptureDeviceFormatの reactionEffectsSupported プロパティを確認することで リアクションエフェクトの サポートを確認することができます AVCaptureDeviceには ジェスチャ認識がいつオンになっているか いつリアクションエフェクトが 有効になっているか知るために 読み取りまたは キー値を観察できるプロパティがあります これらはユーザーのコントロールのため アプリで オンまたはオフの切り替えは できないことに注意してください iOSでも同じ考えです 参加者はコントロールセンターに移動して ジェスチャ認識をオンまたはオフにします これが行われたときにキー値を観察できます ただし iOS上のアプリで エフェクトをトリガーするには プログラムで行う必要があります それでは それを行う方法を見てみましょう 「canPerformReactionEffects」 プロパティがtrueの場合 ReactionTypeメソッドの PerformEffectは リアクションを ビデオフィードにレンダリングします アプリにはエフェクトを トリガーするボタンが必要です ジェスチャを介して受信したリアクションは 検出に使用されるキューに応じて performEffectを呼び出したときとは 異なるビデオ内の場所に レンダリングされる場合があります AVCaptureDeviceが キャプチャセッションで認識し ビデオコンテンツにレンダリングできる サムズアップやバルーンなどさまざまな リアクションエフェクトすべてに対応する AVCaptureReactionTypeという 新しい列挙型があります 「AVCaptureDevice.available ReactionTypes」プロパティは 設定されたフォーマットまたは セッションプリセットに基づいて AVCaptureReactionTypesの セットを返します これらのエフェクトには 独自のビューに配置できる 組み込みのシステム UIImageも用意されています 新しい関数AVCaptureReaction Type.systemImageNameから リアクションのsystemNameを取得できます この関数はAVCaptureReactionTypeを受け取り UIImage systemNameコンストラクタで 使用する適切な文字列を返します また リアクションエフェクト が進行中であることを通知するAPI その名も AVCaptureDevice .reactionEffectsInProgressがあります ユーザーが複数のリアクションエフェクトを 順番に実行すると それらが一時的に重なる可能性があるため ステータスオブジェクトの配列が返されます Key-Valueの観察を使用すると これらの開始と終了を知ることができます Voice-over-IP会議アプリの場合 特に帯域幅の理由で 発信者がビデオをオフにしている場合 この情報を使用して 効果に関するメタデータを リモートビューに送信することもできます たとえば 別の発信者の代わりに UIにエフェクトアイコンを表示できます ビデオストリームへの エフェクトアニメーションのレンダリングは ビデオエンコーダにとって 困難な場合があります これらにより コンテンツの複雑さが増し エンコードするにはより大きなビットレート バジェットが必要になる場合があります Key-Valueにより reaction EffectsInProgressを観察し レンダリングの実行中に エンコーダを調整できます アプリで可能な場合は エフェクトのレンダリング中に エンコーダの ビットレートを上げることができます または VideoToolboxを通じて 低遅延ビデオエンコーダを使用し MaxAllowedFrameQPVTCompression PropertyKeyを設定している場合は 次に サポートされている解像度や フレームレートおよびビットレート層を含む さまざまなビデオ構成を使用して アプリでテストを実行し エフェクトの進行中にそれに応じて MaxAllowedFrameQPを 調整することをお勧めします MaxAllowedFrameQPの値が低いと エフェクトのフレームレートが低下し ビデオのフレームレートが 低くなってしまうことに注意してください 2021年のセッションの「VideoToolboxによる 低遅延ビデオエンコーディング」には この機能の使用に関する 詳細な情報が含まれています また エフェクトの進行中は ビデオフレームレートが変化する 可能性があることにも注意してください 例えば AVCaptureSessionを毎秒60フレームで 実行するように設定した場合 エフェクトが実行されていない間は 毎秒60フレームになります しかし エフェクトが進行している間は 1秒あたり30フレームなど異なる フレームレートが表示されることがあります これはポートレートおよび スタジオ照明エフェクトに従い 終了フレームレートが指定した値よりも 低くなる可能性があります そのフレームレートを確認するには デバイスで設定しているフォーマットの AVCaptureDeviceFormat.videoFrameRateRange ForReactionEffectsInProgress を確認してください 他のAVCaptureDeviceFormat プロパティと同様 これはアプリに対する情報であり コントロールできるものではありません macOSおよび連係カメラを 使用するtvOSアプリでは リアクションエフェクトが 常に有効になります iOSとiPadOSでは アプリケーションは Info.plistを変更するとオプトインできます オプトインするには UIBackgroundModes配列で VoIPアプリケーションカテゴリ であることをアドバタイズするか 値YESを指定してNSCamera ReactionEffectsEnabledを追加します リアクションエフェクトと ジェスチャー認識は iPhone 12などのA14チップ以降を 搭載したiPhoneやiPad Apple Silicon Macや Intel Mac 連係カメラデバイスを 使用したApple TV USB-C iPadやApple Silicon Macに 接続されたApple Studioディスプレイ USB-C iPadや Apple Silicon Macに接続された サードパーティ製カメラで使用できます 以上が新しいAPIをカバーした 本セッションの内容になります 画質を向上させた最も応答性の高い 写真アプリを作成するための 新しい可能性を提供する 遅延写真処理 ゼロシャッターラグおよび 応答性の高い キャプチャAPIについて説明しました また 新しい「リアクション」を含む 更新されたビデオエフェクトを使用して ユーザーが実際に自分自身を 表現する方法についても説明しました 素晴らしい新機能の数々に対する みなさんの反応が楽しみです ありがとうございました ♪♪