問題タブ [demosaicing]

私は OpenGL Bayer デモザイキング アルゴリズムに取り組んでおり、テクニックを一見うまく機能させることができましたが、出力に時折不具合が発生し、その理由を理解できないようです。ここで画像を参照してください: https://imgur.com/a/gz5YL . ストライプは表面の特定のスケールでのみ発生し、ほとんどのスケール (おそらく 99%) ではグリッチはありません。

頂点シェーダー:

フラグメント シェーダー:

頂点は次のように定義されます

フィルターは GL_NEAREST に設定されています。texSize は、アップロードされたテクスチャ イメージのピクセル単位のサイズです。便宜上(?)、同じ頂点座標とテクスチャ座標 [0,1] を使用し、縦横比を維持するために mvp をオルソに設定します。私は Qt5.5 MSVC32 を使用していますが、グリッチは非常に異なるハードウェアで再現されています。

私はさまざまなマッピング手法を試しました (テクスチャ座標の調整など)。それらのいくつかは、他のものよりも優れた結果を生成するように見えます (グリッチの頻度が低い)。そのため、テクスチャ座標が十分に正確ではないなどの理由が考えられます。ある時点で、縦横比を維持するために mvp を使用しなかった場合、問題は解決したと少なくとも思っていましたが、想像しただけで、違いが生じる可能性がありますか?

何がこれを引き起こしているのでしょうか？

一部のコードは、graphics.cs.williams.edu/papers/BayerJGT09/ の功績によるものです。

サンプルの CFA 画像は www.cs.unc.edu/~lazebnik/spring09/assignment1.html からのものです。

更新 6.12.2015: ここで指を交差させておきますが、正規化されていないテクスチャ座標を使用して取得することで、うまくいったと思います

texture/texture2D の代わりに。ファンキーなテクスチャ座標調整をすべて元に戻し、[0, size] 頂点を次のように入力しました。

最初のテストでは良好な結果が得られました。時期尚早であるかどうかは、後でわかります。これが解決策だったとしても、正規化された座標でテクセルをヒットできなかった理由はまだわかりません。

Java プログラムが読み取るバイナリ ファイルから Java でイメージを作成することになっています。ファイルはベイヤー フィルター センサーから取得されます。このファイルは、各ピクセルのバイナリ値で構成されています。すべてのピクセルは 10 ビットで表されます。バイナリ データから画像を構築するには、デモザイキング アルゴリズムを記述する必要があります。1024*1280 ピクセルがあります。したがって、1280*1024*10 = 13107200 ビット = 1638400 バイトが画像サイズです。Java でそのようなアルゴリズムを実装した人はいますか? 誰かが助けてくれたらうれしいです。どうもありがとう。

Pi NoIR カメラからの長時間露光をスタックしようとしています。

picamera raw 形式は、例に基づいて numpy 配列にアンパックできます: http://picamera.readthedocs.io/en/release-1.10/recipes2.html#raw-bayer-data-captures

この numpy 配列を rawpy ( https://github.com/letmaik/rawpy ) 画像に変換して後処理およびデモザイクするにはどうすればよいですか?

RAW ベイヤー画像を直接 YUV 形式にデモザイクしようとしていますが、時間が重要です。私が見つけたオンラインアルゴリズムは、RAW->RGB、次にRGB->YUVを通過します。直接的な方法はありますか？c++/python/Pseudo コードは大歓迎です、ありがとう!

cv::cvtColor()生のベイヤー画像を画像に変換する機能を再現したいと考えていRGBます。COLOR_BayerBG2BGR、またはCOLOR_BayerBG2BGR_VNG、およびのように、いくつかの異なる方法がありますCOLOR_BayerBG2BGR_EA。ただし、これらの各アプローチが使用する補間方法に関する情報は見つかりません。出版物または特許への参照がいくつかあるはずです。誰でも知っていますか？

私のアプリケーションは、計算量の多いほぼリアルタイムのワークロードを処理しており、可能な限り高速化する必要があります。このソフトウェアは C++ で書かれており、Linux のみを対象としています。

私のプログラムは、3096px x 2080px で 25 fps を提供できる専門の天体カメラから 6.4 メガピクセルの RAW データ バッファを取得します。このストリームは、高品質の線形補間ディベイヤー アルゴリズムを使用して、リアルタイムでディベイヤーされます。HQ 線形補間ディベイヤー アルゴリズムは常に計算量が多くなることはわかっていますが、プログラムの他の領域を高速化したいと考えています。

GPU が RGBA ピクセル バッファー上でより効率的に動作することは、私の理解 (プロファイリングによって証明されています) であるためです。しかし、私はこれを修正して喜んでいます。

最初に、私は非常に単純な for ループ (以下) を書きましたが、もちろん恐ろしい結果になりました。

上記のコードでは、13 fps のフレーム レートが得られました。私の次の実験は、すべての要素が 255 に等しいバッファを初期化し、次のコードを使用することでした。

上記のコードにより、ループが大幅に高速化されました。現在、i7-7700 ラップトップで 23.9 fps を達成しています。ただし、このコードを古いマシンで実行すると、依然として非常に残念なフレーム レートが得られます。古いマシンがデベイヤーに苦労していることは知っていますが、プロファイリングを行うと、RGBA バッファーへの変換が重大な問題を引き起こしていることが明確に示されています。

SSE 組み込み関数を使用してこれをより効率的に行うことができる可能性があることを読みましたが、SSE 組み込み関数の経験はありません。

オンラインで見つけた多くの SSE の例を試しましたが、動作しません。したがって、SSE の経験がある人がこの問題を解決してくれると助かります。

ソフトウェアがはるかに古いハードウェアで実行される可能性があるため、2 または 3 を超える SSE をターゲットにすることはできません。

誰かが私を正しい方向に向けることができれば幸いです。