Docker
Linux上のChrome79
部分的な再構成が生成されると、再構成の位置合わせの出力に問題があるようです。
OpenSfMソースによると、各サブモデルからの各部分再構成は、大きなバンドル調整問題にスローされ、各部分再構成に適用されて整列された再構成ファイルに保存される類似性変換のセットとして出力されます。
ただし、実際には、部分的な再構築が1つだけ更新されているようです。 理由がわからないようです。
すべての部分再構成のすべてのポイントとショットが少なくとも1e-6の大きさで変更されることを期待しますが、これは各サブモデルの単一の部分再構成にのみ当てはまるようです。 他のすべての部分的な再構成は、各ショットとポイントを並べて比較すると同じです。
(補足として、バンドル出力を再構成全体に適用するだけでなく、類似性変換が生成されて剛体変換が作成される理由を理解することに興味があります。これにより、サブモデル間の境界がよりスムーズになると思いますか?外れ値取り扱い?)
複数の部分的な再構築も含む複数のサブモデルに分割されたデータセットで、OpenSfMのalign_submodelsステージをトリガーします。 これは、最小機能数を減らし、十分な数のエントリを持つデータセットに分割を設定することで簡単に達成できるはずです。
これは拡張ではなくバグかもしれないと思います。
ソースから、すべての部分的な再構築は常に整列されている必要がありますが、実際に整列で更新されているのは、現在分割/マージで使用しているインデックス0の部分でさえあるとは必ずしも言えません-これは、これらの場合にマージすると、雲が整列しなくなります。
それを見つけた。 どうやら、OpenSfMのapply_transformations(transformations)で使用されるitertools.groupbyメソッドは、すでにソートされたリストを渡す必要があります。そうしないと、エントリが正しくグループ化されません。 再構成はグループごとにロードされるため、位置合わせされていない再構成が再ロードされ、以前に位置合わせされたコンポーネントが上書きされます。
PRを099とmapillaryOpenSfMに少し送信します。 :多田:
素晴らしい! この@linusmartenssonを調べてくれてありがとう
問題ありません! それは楽しいコードベースです。 :贈り物:
OpenDroneMap / OpenSfMとmapillary / OpenSfMの両方に統合されたため、終了します。 :)
最も参考になるコメント
問題ありません! それは楽しいコードベースです。 :贈り物:
OpenDroneMap / OpenSfMとmapillary / OpenSfMの両方に統合されたため、終了します。 :)