2

組み込みデバイスを、トリガーするたびに1つのjpeg圧縮フレームを返すカメラモジュールとインターフェイスしています。

3枚連続で撮影し(1/4秒あたり約1フレーム)、さらに画像を1つのファイルに圧縮したいと思います。ここでの前提は、時間的な冗長性が多く、したがって3つのフレーム間でさらに圧縮する余地がたくさんあることです(3つの別々のjpeg画像を送信する場合と比較して)。

ライブラリやOSを使用せずに、Cの組み込みデバイスにソリューションを実装します。

カメラは動きの少ない場所(背景に訪問者やスクリーンがない、枝が揺れる木など)で写真を撮るので、冗長性についての私の仮定はかなりしっかりしていると思います。

ファイルが最終的にpc/macで表示されるとき、3つのフレームを抽出するために何かを書く必要があることを気にしません(したがって、それは非標準のクルージである可能性があります)

したがって、実際の質問は次のとおりです。これらの3つの画像がすでにJPEG形式になっていることを考えると、これらの3つの画像を一緒に圧縮する最良の方法は何ですか(生の画像に戻すこともできますが、そうでない場合も同様です)。 。)

4

4 に答える 4

1

JPEG画像のデコード/変更/再コード化は画質を低下させる可能性がありますが、カメラはJPEGしかキャプチャできないため、最終的な画質が重要な要件になる可能性は低いと思います...

JPEG周波数領域でこれを行う簡単な方法は考えられませんが、画像1から画像2と3を解凍してから減算し、デルタ画像を取得することができます。これらははるかによく圧縮されるはずであり、受信者によって画像#1に追加されます。

圧縮ドメインで実行できる操作が役立つ場合があります。jpegのハフマン/RLEステージを解凍してから、DCT係数を直接処理する必要があります。この方法で画像の減算を行うことができますが、それ以上のアーティファクトが発生することはありません。

于 2010-04-27T20:37:17.893 に答える
1

私はこれを2番目の答えとして追加します。これは、あなたの問題をよりよく理解できるようになったため、最初の答えとは非常に異なっているためです。

jpegファイルを直接操作できる可能性は非常に低いと思います。圧縮ファイルでは、小さな変更がファイルの大部分に伝播する傾向があり、2つのファイルを多くの場所で比較できなくなります。

2つの提案があります。

1:画像を圧縮します。単純すぎるように思われますが、おそらくすでに考えているでしょうが、zipプロトコルはよく知られており、自由に利用でき、可能な限りの類似点を自動的に利用します。ここでも、カメラに3枚の写真を撮らせます。それらを圧縮して、それがどうなるかを見てください。

2:もう少し複雑ですが、3つのjpegをbmpに解凍し、bmpを連結して(次々に並べて)、jpegに再圧縮することができます。jpegプロトコルは、3つの画像の類似点を最大限に活用する必要があり、作業はあなたの観点からはかなり最小限です。

于 2010-04-27T23:33:05.143 に答える
0

私は大学以来信号を研究していませんが、あなたはロスレスビデオコーデックを探していると思います。

Huffyuvは古くからあり、ソースコードが利用可能です。基本的な概念は、各フレーム間のピクセルの変化を予測し、予測された変化と実際の変化の違いをエンコード(および圧縮)することです。

Lagarithは別のオープンソースコーデックです。

デコードされたJPEGフレームをこれらの各コーデックにフィードする必要があります。

于 2010-04-27T20:12:00.067 に答える
0

もし私があなたなら、今はあなたのシステムを使って手で3枚の写真を撮っているので、先に進む前にあなたの仮定を確認することができます。

私の推測では、動きを意図していなくても、わずかな翻訳が必要になると思います。機器の振動、風、さらには熱膨張でさえ、1ピクセルか2ピクセルだけあなたを遠ざけるのに十分かもしれません。それは、まっすぐなピクセルからピクセルへの圧縮を台無しにするでしょう。

他の要因は、太陽を横切る雲による光の変化、地面から漂う熱倍率、さらにはjpeg圧縮アーティファクトである可能性があります。

うまくいかないと言っているのではなく、最初に手作業で実行するだけです。

ストレージは非常に安価であるため、カメラに大きなSIMカード(またはその他)を追加することで、より多くの利益を得ることができます。

于 2010-04-27T20:31:25.573 に答える