OpenCVをWindowsRTに移植した方法

OpenCVは、機能の拡張とともに、さまざまなプラットフォームへの移行を続けています。 そして、新しいプラットフォームは、他のコンパイラー、システムAPIの機能、テスト、そして多くの新しい冒険です。 この記事では、大規模でかなり確立されたプロジェクトを新しいハードウェアおよびソフトウェアプラットフォームに移植した経験を共有したいと思います。 Windows RTとは、カスタムWindowsランタイムアプリケーションを開発するための新しいAPIと、ARMベースのプロセッサ用のWindows RTオペレーティングシステムの両方を意味します。 主な目標は2番目のポイントであり、顧客が必要としていたのは彼であると言わなければなりません。

最初のアプローチ

CMakeベースのライブラリインフラストラクチャは、複数のプラットフォームへの再配置を何度も経験していますが、今回は電撃戦が失敗しました。 判明したように、cmake（当時はまだ2.8.11）は、Windows RTでのVisual Studioのプロジェクトの生成をサポートしていません。 ネットワークの空きスペースで回避策がすぐに見つかりました。VisualStudio for Windows用のプロジェクトを生成する代わりに、メイクファイルジェネレーターの1つを使用できます。 ビルドするには、make、nmake、またはNinjaを使用できます。ARMコンパイラでアセンブリの環境を設定するだけです。



既存のコードをコンパイルするための闘争の中で、多くの小さなニュアンスが浮上しています。 特に、ARMアーキテクチャ用の通常のWin32アプリケーションの構築は、ヘッダーファイルとVisual Studioプロジェクトのレベルで制限されています。 したがって、cmakeテストファイルとテストを正常にコンパイルするには、ハッキングを行わなければなりませんでした。_ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLEマクロをコンパイラのコマンドラインに追加します。 プラットフォームの検証を抑制します。 ライブラリと連携して開発するすべてのテストと例にも同じことが言えます。



マクロとコンパイルキーに関するすべての問題を解決するために、擬似ツールチェーンファイルがライブラリに追加されました。 「疑似」は、コンパイラ、OS、プラットフォームなどへのパスを指定せず、必要なフラグとマクロのみを追加するためです。 さらに、 Windows Platform SDKをインストールする必要がありました。 ARM用のCおよびC ++ランタイムからいくつかの静的ライブラリを追加します。



highguiモジュールのビルドを最後まで実行しようとして、ビデオとウィンドウを操作するために一部を犠牲にしなければなりませんでした。システムライブラリにはリンクに必要な機能がありません。 Windows RTでは、Windows用の古いAPI、GDI、Video For Windows、およびCOMの一部のサポートはありません。 FFmpeg'aのサポートも断念しなければなりませんでした。 これは優れた移植可能なライブラリですが、その統合には追加の努力が必要です。 その結果、ウィンドウもビデオI / Oもありませんでした。 Windowsは大きな損失ではありません。Windowsのサポートは、最終的なアプリケーションを作成するのではなく、プロトタイピングとデバッグにのみ必要です。 それどころか、ビデオ入出力は非常に必要なものであり、それに取り組む価値がありました。



さらに数個の歯車を締めました。テストは正常に組み立てられ、ARMタブレットでほぼ正常に実行されました。 しかし、メインライブラリのテストを正常にコンパイルして実行することは、戦いの半分でもありません。 OpenCV自体に加えて、アセンブラーとAndroidの組み込みで行われ、GCCを新しいプラットフォームにコンパイルし、インテルTBBのサポートを追加し、ビデオI / Oをサポートするように設計されたかなり多数の最適化を転送したかったのです。

ビデオI / O

Windows RTのアクティブな開発は、ビデオI / Oから始まりました。 Windows XPから、次のマルチメディアAPIであるMicrosoft Media FoundationがWindowsオペレーティングシステムに登場しました。 すぐに判明したように、これはARMを搭載したタブレット上のビデオ用の唯一のAPIです。 cv :: VideoCaptureの新しい実装は、デスクトップPCとタブレットPCの両方に大きなメリットを約束しました。 その時点のOpenCVは、古いDirect Showを含め、Windowsでビデオを操作するためのバックエンドをすでにサポートしています。 DirectShowに基づくcv :: VideoCaptureの実装は、 VideoInputライブラリを使用して実行されました。 VideoInputプロジェクトが生きており、おそらく何らかの方法でMedia Foundationによってサポートされていることが望まれました。 しかし、検死により、このプロジェクトは長い間放棄されており、私たちのライブラリのコピーでさえ、オリジナルに比べてはるかに進んでいました。 この仕事の大きなブレークスルーは、CodeProjectの発見でした。 Far East Evgeny Peregudaの同胞は、MediaFoundationをOpenCV（！）のプロジェクトに統合するためにVideoInputのようなライブラリを実装しました。 完了した仕事に感謝します。



公開されたコードを新しいcv :: VIdeoCapture実装のベースとして使用することにしました。 適応の過程で、アセンブラーの挿入を取り除き、ARMにリンクできなかった呼び出しの一部を置き換える必要がありました。 さらに、パイプラインの構造をわずかに変更したため、ビデオファイルの読み取りと書き込みが追加されました。 デスクトップでは、新しいcv :: VideoCaptureはカメラでうまく機能しましたが、タブレットでは不快な驚きがありました。 Win32サブシステム用にコンパイルされたARMのアプリケーションでは、MediaFoundationパイプラインは正常に初期化されましたが、ビデオを取得できませんでした。パイプラインがハングし、カメラからフレームが届きませんでした。 コンテナで動作するように構築されたアプリケーションでは、別の異常が観察されました。 MFEnumDeviceSources関数を使用してカメラを列挙すると、カメラインターフェイスへのポインターの代わりに大量のゴミとNULLが返されました。 すぐに明らかになると、最初のケースでは、システムブローカーが責任を負い、カメラやその他のデバイスへのアクセス権を監視します。 マニフェストを持たないWin32アプリケーションがあるため、カメラへのアクセスを許可できません。 2番目の場合、問題はMFEnumDeviceSources関数の実装にあります。むしろ、それが存在しないことにあります。 コンテナアプリケーションの禁止機能のリストに記載されており、禁止されている他の多くの機能とは異なり、まったく実装されていません。 より正確には、リンクエラーをなくすために、スタブが呼び出され、インターフェイスへのポインターと説明内のゴミの代わりにNULLを返します。 その結果、デスクトップシステム用のMedia Foundationをサポートすることができましたが、ARMでは問題が未解決のままでした。

最適化

次のステップは、 TBBライブラリのアセンブリと統合でした。 当時、このライブラリはすでにアルゴリズムを並列化するためのツールとして積極的に使用されていましたが、それをARM用のWindows RTに移植したいと考えていました。 しかし、適応を迅速に行い、血をほとんど出さないことはうまくいきませんでした。 TBBは、標準のシステムコールに加えて、プラットフォームごとに独自の低レベル同期プリミティブのセットを使用します。 以前のすべてのケースで、TBBを使用する必要がある場合、GCCコンパイラーが使用され、GCC固有の組み込み関数を含むブランチがライブラリコードで機能しました。 しかし、今回は新しいブランチが必要でした。 ライブラリ開発チームは、Windows RTのTBBをARMに移植するのを支援しました。 Vladimir Polin（ vpolin ）に感謝します。 Windows RTの安定したサポートは、TBB 4.1 update 4で登場しました。



ライブラリ自体のコードを整理した後、手は彼ら自身の開発と最適化の多くに達しました。 それらのほとんどは、AndroidおよびGCCコンパイラー用に作成されており、Windowsでビルドされたことはありません。



組み込み関数と組み込みアセンブラで行われた最適化から始めましょう。 本質的なビジネスは非常に良かった。 NEON命令のすべての組み込み関数とデータ型名は、GCCの組み込み関数と同じであり、実際にはコードの変更を必要としません。 唯一の例外はレジスタ変数です。 スタジオコンパイラを使用する場合、レジスタ名を明示的に指定することはできません。 特定のレジスターへの変数バインドは、Android NDKの古いバージョンで実行する必要がありました。コンパイラーは、同じレジスターを2回使用して、2回使用することがありました。



しかし、アセンブラーでは、すべてが非常に悪いことが判明しました。 Microsoftの新しいバージョンのコンパイラは、x86_64およびARMのインラインアセンブラをサポートしていないため、構文の違いをすばやく修正してアセンブラコードを転送するという考えを拒否する必要がありました。 コンパイラ組み込み関数を使用して最も重要な部分を書き直しましたが、ここでもいくつかの驚きがありました。 スタジオコンパイラには命令のVFPv3（ARM用の浮動小数点を使用した数学のハードウェア実装）の組み込み関数がなく、それらを明示的に使用する唯一の通常の方法は、アセンブラーで関数を完全に実装し、そのような関数を別のasmファイルに転送することです ビルドインフラストラクチャに大幅な変更が必要だったため、個別のアセンブラコンパイルを使用したアプローチはまったく適していませんでした。 また、コンパイラがアセンブラー関数の埋め込みを拒否し、呼び出しの最適化を実行することも重要です。 この問題は、__ emitキーワードを使用することによってのみ解決されました。 これにより、CまたはC ++コードのブロックに任意のマシンコードを挿入できます。 コールアグリーメントと命令のオペコードを知っていれば、欠けている組み込み関数を自分で作成できます。

Win32 APIのクリーンアップ

OpenCVの準備を整える最後のステップは、コンテナ化されたアプリケーションの認定テストに合格することでした。 これは、マーケットプレイスのすべてのアプリケーションの前提条件です。

まず、リンカーのフラグに/ appcontainerを追加する必要がありました。 次に、使用されたシステムAPIのストリッピングが行われました。 Win32呼び出しのすべてのANSIバージョン、およびInitializeCriticalSectionなどのExバージョンを持つ関数の一部は不名誉に陥りました。



GetTempFileName関数には特別な注意を払う必要がありましたが、この関数はWin32 APIによって一目では目立ちませんでした。 OpenCVでは、tempfile呼び出しで使用されます。 GetTempFileNameには、コンテナで使用できる適切な対応物がありません。 見つかった唯一のオプションは、Windowsランタイムライブラリからの呼び出しです。 関数のコードはここで取得され 、通常のアプリケーションをビルドするときにWindowsランタイムにリンクする方法は次のとおりです。



GetTempFileNameに加えて、TLS（スレッドローカルストレージ）との相互作用関数の代替はありませんでした。 しかし、この場合、代替案はすぐに見つかり、まったく待たなかった場所-C ++ 11。 新しいC ++標準には、TLSデータを操作するためのツールが含まれており、システム依存のAPIから言語構造に移行することができました。



TLSで動作するようにWin32 API呼び出しを新しい言語構成で置き換えることは、認証テストの最後のステップでした。 スプラッシュ画面、すべての機会のアイコン、およびテストアプリケーションの説明を追加すると、テストは緑色に変わりました。

継続的インテグレーション

コードの移植と並行して、プロジェクトのテストインフラストラクチャを開発する作業が進行中でした。 残念ながら、ARMを搭載したタブレットでリモートでテストを実行する方法は受け入れられなかったため、すべての自動テストはデスクトップで行われ、タブレットは手動でテストされました。



最初のレーキは、 appcert.exeテストの統合とともに地平線上に現れました。 これは、マーケットプレイスの標準アプリケーション認定テストであり、実行可能ファイルといくつかのライブラリとして実行されます。 テストにはコマンドラインインターフェイスがあり、コンソールから手動で実行できます。 しかし、彼がBuildbotのステップリストに追加されるとすぐに、興味深い驚きが始まりました。 最初に、テストは追加のコンソールを生成し、すべての出力をそれらに書き込みます。 そのため、Buildbotは何も入力しません。 第二に、手動モードではテストが2〜3分間の力で通過するという事実にもかかわらず、20分間割り当てられた時間内に終了に達しない場所でテストがフリーズします。



Jenkinsでの同様の手順の統合について議論するために、パラドックスの解決策がMSDNフォーラムで見つかりました。 認定テストに合格するには、アクティブなユーザーセッションが必要です。 そのJenkins 、そのBuildbotは、アクティブセッションを持たないシステムサービスのコンテキストでテストマシン上でノードを実行します。 フリーズを克服するには、サービスとしてのBuildslaveの開始をオフにし、Windows 8でテストノードに自動ログインし、Buildslaveを標準のスタートアップに追加する必要がありました。 新しいモードでは、テストのハングが解消されましたが、複数のコンソールの問題は関連したままでした。







Windows 8を搭載したタブレットでOpenCVを使用するMarketplaceのアプリケーション例

おわりに

作業の全体的な結果：OpenCVは、ARMアーキテクチャとx86アーキテクチャの両方の製品アプリケーションですぐに使用できます。アルゴリズム部分全体が動作し、TBBとの並列化、ほとんどの一般的な形式での画像の読み書きがサポートされます。 xamlアプリケーションに統合のいくつかの例を実装しました。 ビデオの入出力には問題がありますが、実践が示しているように、この機能は最終的なアプリケーションのコードではほとんど役に立ちません。 いずれにしても、既存のカメラまたはビデオデコードパイプラインに統合する必要があります。 さらに、このプラットフォームは自動テストにあまり適していないことが経験上示されているため、長い質問ではこの質問を延期しないでください。 インフラストラクチャの問題は、予想よりもかなり長くかかる場合があります。



さて、どうやら、あまり人気のないプラットフォームのために、Windowsランタイムのサポートの開発に対する顧客の関心は大幅に減少し、コミュニティの愛好家にスムーズに伝わりました。 Windows RTでのOpenCVの開発に興味がある場合は、ぜひご参加ください（ OpenCV貢献方法 、 http：//itseez.com/jobs/ ）！