JCV AR SDK Android統合ドキュメント

目次

1.統合の準備

  • 1.1 リソースファイルの使用

  • 1.2 Android Studio ランタイム環境の設定

  • 1.3 JNI の難読化

2.SDK のアクティベーション

  • 2.1 ライセンスファイルを使用したアルゴリズムライブラリの認証

  • 2.2 モデルファイルの使用

  • 2.3 スタンプファイルの使用

3.シングルおよびダブル入力モード

  • 3.1 シングル入力モード

  • 3.2 ダブル入力モード

  • 3.3 最適化されたシングル入力モード

  • 3.4 最適化されたダブル入力モード

  • 3.5 入力モードの切り替え

4.SDK の API の使用

  • 4.1 SDK ハンドルの初期化

  • 4.2 カメラプレビューのテクスチャとデータの取得

  • 4.3 カメラプレビューのテクスチャとデータの処理

  • 4.4 フレーム処理フロー

  • 4.5 SDK ハンドルの解放

5.JNI API の概要

  • 5.1 STMobileCommon

  • 5.2 STMobileHumanActionNative

  • 5.3 STMobileFaceAttributeNative

  • 5.4 STBeautifyNative

  • 5.5 STMobileStickerNative

  • 5.6 STSoundPlay

  • 5.7 STMobileStreamFilterNative

  • 5.8 STMobileFilterNative

  • 5.9 STMobileObjectTrackNative

  • 5.10 STHumanAction

6.回転と方向に関する手順

  • 6.1 カメラの方向

  • 6.2 HumanAction API の方向

※一部コードが資料の都合上途切れている部分があります。サンプルコードと同じ内容が記載されておりますので、該当のサンプルコードにてご確認お願い致します。

1 統合の準備

1.1 リソースファイルの使用

  • Android Studio プロジェクトを開きます。ライセンスファイル、モデルファイル、スタンプなどのファイルを JCV AR SDK ディレクトリからプロジェクトのアセットフォルダーにコピーします。

  • ライセンスファイルの名前を「SenseME.lic」に変更し、アセットフォルダーにコピーします。

  • face_attribute_x.x.x.model や M_SenseME_Action_x.x.x.model を含むモデルファイルをアセットフォルダーにコピーします。

  • スタンプパッケージを "2D"、"3D"、"hand_action"、"deformation"、"segment" に分類し、アセットフォルダーにサブフォルダーを作成します。スタンプを分類し、名前が同じアイコンと一緒に、それぞれサブフォルダーにコピーします。アイコンがない場合は "なし" と表示されます。分類方法はカスタマイズできます詳細はサンプルの FileUtils ファイルをご参照ください。

  • アセットフォルダーに "filter_xx" という名前のフィルターカテゴリフォルダーを作成し、後で使用できるようにカスタム分類フィルターモデルを適切なフォルダーにコピーします。

1.2 Android Studio ランタイム環境の設定

  • 初めてサンプルプロジェクトを開くと、"NDK が見つかりません" というメッセージが表示される可能性があります。[プロジェクト] を右クリックし、[モジュール設定を開く]、[SDK の場所]、[Android NDK の場所] の順にクリックして、NDK のパスを設定します。

  • サンプルの JNI の部分をプロジェクトに統合するには、build.gradle プロジェクトに JNI の部分の依存関係を追加します。

1.3 JNI の難読化

  • プロジェクトで STMobileJNI を引用するには、次のようにプロジェクトの proguard-rules.pro ファイルに JNI の難読化を追加します。

2 SDK のアクティベーション

2.1 ライセンスファイルを使用したアルゴリズムライブラリの認証

  • SDK は、アルゴリズムライブラリの権限をライセンスファイルと照合します。 認証された後にのみ、SDK の機能を使用できます。

  • SenseME.lic ファイルをアセットフォルダーにコピーした後、統合するために、次のように STLicenseUtils ユーティリティクラスの checkLicense() 関数のみを呼び出すことができます。

  1. まずlicenseファイルの内容を読み込みます。

  2. ローカルに保存されているアクティブコードを取得します。

  3. 利用可能なアクティベーションコードがない場合は、生成します。

  4. checkActiveCode* コマンドを直接実行して、アクティベーションコードが有効であるかどうか確認します。

  5. 確認に失敗した場合は、別のアクティベーションコードを生成します。

  6. 生成に失敗した場合は、エラーメッセージが表示されます。成功すると、新しいアクティベーションコードが保存され、成功したことを示すメッセージが表示されます。

2.2 モデルファイルの使用

  • FileUtils ファイルを使用して、サンプルのモデルファイルを管理します。AssetsManager を使用してモデルファイルにアクセスできます。モデルファイルの使用方法については、サンプルをご参照ください。

2.3 スタンプファイルの使用

  • 制御下のスタンプファイルを SD カードにコピーし、パスを取得します。スタンプの変更時は、SDK の API にパスを割り当てます。

  • FileUtils ツールクラスの copyStickerZipFiless() 関数を使用して、スタンプをコピーできます。

  • FileUtils ツールクラスの getStickerFiles() 関数を実行して、レンダリング用にスタンプのパスを取得します

  • サブフォルダーでファイルをコピーするには、サンプルのメソッドをご参照ください。必要に応じて、メソッドをカスタマイズすることも可能です。

3 シングルおよびダブル入力モード

3.1 シングル入力モード

  • シングル入力モードでは、カメラはテクスチャをコールバックすることによってのみデータを取得します。HumanAction を含む特定の API では、検知用のバッファーデータを入力する必要があります。そのため、glReadPixel() 関数を使用して、ARGB 形式でバッファーデータを取得する必要があります。

  • メリット: バッファーをコールバックする必要がありません。統合およびデータ処理が簡単です。

  • デメリット: glReadPixel() 関数は、ローエンドのマシンでは時間が掛かります。画像形式は ARGB です。顔検知で必要な場合は、グレースケールに変換する必要があります。

3.2 ダブル入力モード

  • ダブル入力モードでは、カメラはテクスチャとデータバッファーを同時にコールバックします。

  • メリット: シングル入力モードと比較すると、ダブル入力モードでは glReadPixel() を必要としません。画像形式は NV21 です。直接、グレースケース画像を取得できます。

  • デメリット: データバッファーのコールバックを使用して、HumanAction を計算します。他の API で使用するために回転およびミラーリングされるため、統合が複雑になります。ARGB 形式を使用する場合は、変換する必要があります。スレッド同期問題もあります。

  • 注記: ダブル入力モードでは、スレッド同期問題、および mGlSurfaceView.requestRender() のタイミングに特に注意してください。

3.3 最適化されたシングル入力モード

  • シングル入力最適化モードは、シングル入力モードに基づいて glReadPixel() を介してバッファーを取得します。取得したバッファーを使用して複数のスレッドでレンダリングおよび検知処理を行います。

  • メリット: シングル入力モードよりフレームレートが高くなり、時間が掛かる検知処理ではパフォーマンスが大幅に向上します。

  • デメリット: 統合が複雑です。スレッドの同期化により、レンダリングが 1 フレーム遅れます。

3.4 最適化されたダブル入力モード

  • ダブル入力最適化モードは、ダブル入力モードに基づいてカメラのコールバックテクスチャを削除します。バッファーを使用したテクスチャのアップロードにより、テクスチャを取得し、そのバッファーを使用して複数のスレッドで検知処理を行います。

  • メリット: シングルおよびダブル入力モードと比べて、フレームレートが高くなり、時間が掛かる検知処理ではパフォーマンスが大幅に向上します。

  • デメリット: 統合が複雑です。テクスチャを手動でアップロードする必要があります。スレッドの同期化により、レンダリングが 1 フレーム遅れます。

3.5 入力モードの切り替え

  • サンプルでは、異なる入力モードを使用できます

  • 異なる入力モードに切り替えるには、サンプルの CameraActivity.java ファイルをご参照ください。

4 SDK API の使用

4.1 SDK ハンドルの初期化

4.1.1 HumanAction API の初期化

  • HumanAction API を初期化するには loadModel を実行しますが、この処理は時間が掛かります。そのため、非同期に初期化してください。本バージョンでは、サブモデル追加用の API が提供されています。初期化に必要なmodelのみを使用し、後でさらにサブモデルを追加すれば、初期化にかかる時間を削減できます。

  • 初期化中に、シナリオに応じて画像またはビデオを設定するか、または必要に応じて修正します (詳細については STMobileHumanActionNative.java ファイルをご参照ください)。

  • HumanAction API を使用して、モデルを動的に追加または削除し、リソースの割り当てを改善できます。非同期に呼び出すこともできます (詳細については、CameraDisplayDoubleInput.java ファイルをご参照してください)。

4.1.2 顔属性 API ハンドルの初期化

  • 顔属性 API ハンドルを初期化します。

4.1.3 美化 API ハンドルの初期化

  • 美化 API ハンドルを初期化します。

4.1.4 スタンプ API ハンドルの初期化

  • スタンプ API ハンドルを初期化します。

4.1.5 フィルター API ハンドルの初期化

  • フィルター API ハンドルを初期化します。

4.1.6 一般的なオブジェクトのトラッキング API ハンドルの初期化

  • 一般的なオブジェクトのトラッキング API ハンドルを初期化します。

4.2 カメラプレビューのテクスチャとデータの取得

  • AndroidManifest.xml ファイルを追加して、システムカメラの権限を有効にします。

  • ダブル入力モードでは、2 つのコールバックメソッド (バッファーとテクスチャ) を使用するように Android カメラを設定します。シングル入力モードでは、テクスチャをコールバックするように設定します。

  • Android カメラからテクスチャを取得します (詳細については、サンプルの CameraDisplayDoubleInput.java ファイル、および CameraProxy.java ファイルをご参照ください)。

  • Android カメラからバッファーを取得します (詳細については、サンプルの CameraDisplayDoubleInput.java ファイル、および CameraProxy.java ファイルをご参照ください)。

4.3 カメラプレビューのテクスチャとデータの処理

4.3.1 テクスチャの前処理 (シングル入力モードとダブル入力モードで同様の手順)

  • カメラコールバックテクスチャは水平で、通常は OES 形式です。これを GL_TEXTURE_2D 形式に変換し、回転とミラーリングを適用して、携帯電話の画面上でプレビュー画像が直立するようにします (つまり、システムのフロントカメラで撮った写真と同じ結果)。

  • 容易に統合また利用できるように、デモではテクスチャ前処理クラス GLRender の preProcess() 関数を提供して、効率性を向上します。カメラのコールバックバッファーを使用して HumanAction を検知する際は、preProcess() 関数で readPixel コマンドを実行しないでください。 preProcess() 関数の 2 番目のパラメーターを NULL に設定してください。

  • カメラからテクスチャを取得するには、デモで GLRender クラスの preProcess() 関数の使用に関する概要をご参照ください。入力テクスチャを処理した場合は、preProcess() 関数を呼び出さないでください。

  • 前処理済みのテクスチャは、美化、スタンプ、およびフィルター API で使用できます。

4.3.2 データ処理

  • ダブル入力モードでは、カメラのコールバックバッファーデータを使用して HumanActionDetect プロセスを実行して、HumanAction 結果を取得します。テクスチャが回転およびミラーリングされているため、バッファー内のデータは処理されていません。 HumanAction の方向とテクスチャは一致しないため、後で API で使用できるよう、HumanAction の回転およびミラーリング機能を使用して、データを処理し、HumanAction の方向とテクスチャの方向を合わせます。

  • シングル入力モードでは、処理済みテクスチャを使用して、glReadPixel コマンドでバッファーデータを取得します。バッファーを使用して、HumanAction API から結果を計算します。方向はテクスチャの方向と同じであり、データを回転およびミラーリングする必要はありません。

4.4 フレーム処理フロー

注記: 本セクションで説明する美化、スタンプ、フィルター API には、OpenGL 環境が必要です。OpenGL スレッドで実行する必要があります。

  • HumanAction API の使用

4.4.1 HumanAction API の使用

  • HumanActionDetect 設定は、デフォルトではすべてを検知します。必要に応じて設定をカスタマイズできます。たとえば、前景と背景をセグメント化するには、"|" で結合した ST_MOBILE_SEG_BACKGROUND を追加します。ジェスチャを検知するには、適切な設定を追加してください。

  • HumanActionDetect API を以下のように使用します。

  • 顔の表情に関しては、STMobileHumanActionNative API の STMobileExpression コマンドをご参照ください。検知 API は、HumanAction API の結果から入力を受け取り、表情をそれぞれ出力します。以下に示します。

4.4.2 FaceAttribute API の使用

  • FaceAttribute API の入力パラメーターは、HumanAction パラメーターの出力をベースとします。そのため、顔属性を実行する前に HumanAction パラメーターを設定します。

4.4.3 美化 API の使用

  • 目の拡大や顔のスリム化などの美化 API 関数もまた、HumanAction をベースとしています。

  • 美化パラメーターの設定

4.4.4 スタンプ API の使用

  • スタンプ機能を有効にするには、顔データを利用できるようにします。そのため、事前に HumanAction API を実行してください。

  • スタンプを変更するには、STMobileStickerNative API の changeSticker 関数を呼び出し、スタンプパスを入力します (setShowSticker 関数の使用に関する概要をご参照ください)。

  • スタンプを変更するには、STMobileStickerNative API の changeSticker 関数を呼び出し、スタンプパスを入力します (setShowSticker 関数の使用に関する概要をご参照ください)。

  • スタンプを変更後、StickerNative API の getNeededInputParams 関数を実行して、現在のスタンプに携帯電話センサーが必要かどうかを確認します。

  • スタンプを変更後、STMobileStickerNative API の getTriggerAction 関数を実行して、現在のスタンプでサポートされているジェスチャ、前景、背景などの情報を取得します。戻り値は long で返されます。

  • getTriggerAction 関数の戻り値に応じて、humanActionDetect 関数の config コマンドをリセットし、効率を向上します。たとえば、現在のスタンプでサポートされている顔とジェスチャのみを検知するには、次の設定を使用します。

  • スタンプにサウンド機能が追加されました。自動的に、または TriggerAction API によってサウンドが再生されるようにスタンプをデザインできます。JNI の部分の STSoundPlay.java ファイルで、スタンプをデザインすることもできます。サンプルの STSoundPlay に従って、必要に応じてサウンドの再生をカスタマイズできます。

4.4.5 フィルター API の使用

  • フィルター API を使用する:

4.4.6 一般的なオブジェクトのトラッキング API の使用

  • 一般的なオブジェクトのトラッキング領域を設定する

  • 一般的なオブジェクトの対象領域をトラッキングする

  • 一般的なオブジェクトのトラッキング API ハンドルをリセットする

4.5 SDK ハンドルの解放

  • OpenGL リソースは、OpenGL スレッドで解放される必要があります。

  • 非 OpenGL リソースを解放する

5 JNI API の概要

5.1 STMobileCommon

  • 本 API は、画像形式やエラーコードなどの静的定数と、いくつかの静的関数を定義します。詳細については STMobileCommon.java ファイルをご参照ください。

5.2 STMobileHumanActionNative

  • HumanAction API を作成および検出する際に利用できる設定オプションを定義します。詳細については STMobileHumanActionNative.java ファイルをご参照ください。

5.3 STMobileFaceAttributeNative

  • 顔属性 API。詳細については STMobileFaceAttributeNative.java ファイルをご参照ください。

5.4 STBeautifyNative

  • 美化 API。必要に応じて選択できます。詳細については STBeautifyNative.java ファイルをご参照ください。

5.5 STMobileStickerNative

  • スタンプ API。詳細については STMobileStickerNative.java ファイルをご参照ください。

5.6 STSoundPlay

  • STSoundPlay はサウンドスタンプの実装のために設計されたものです。

5.7 STMobileStreamFilterNative

  • GPU フィルター API。OpenGL スレッド内で実行する必要があります。詳細については STMobileStreamFilterNative.java ファイルをご参照ください。

5.8 STMobileFilterNative

  • CPU フィルター API。詳細については STMobileFilterNative.java ファイルをご参照ください。

5.9 STMobileObjectTrackNative

  • 一般的なオブジェクトトラッキング API。詳細については、STMobileObjectTrackNative.java ファイルをご参照ください。

5.10 STHumanAction

6 回転と方向に関する手順

6.1 カメラの方向

  • フロントカメラ: CameraInfo.orientation は、大抵の携帯電話のフロントカメラでは 270、特殊な電話では 90 に設定されています。

  • リアカメラ: CameraInfo.orientation は、大抵の携帯電話のリアカメラでは 90、特殊な電話では 270 に設定されています。

6.2 HumanAction API の方向

  • デバイスセンサーの方向によって、HumanActionDetect API の入力方向を決定します。

Last updated

Was this helpful?