同じシーンの一部のJPEGファイルが他のJPEGファイルよりもはるかに大きいのはなぜですか?


12

Foscam FI8910W ipカメラを使用して、一定の照明条件下で静的なシーンを表示しています。フレームグラブを引き戻すと、サイズは約35 KBです。これは何度も行うことができ、常に約35 KBですが、電子画像キャプチャに固有のさまざまなノイズのために多少変動します。このランダムな変動は、せいぜい1 KB程度です。

2500フレームごとに、フレームの画像サイズは突然70 KBのオーダーになります。カメラのウォームアップ中に熱ノイズが発生すると考えている場合、上向きの緩やかなクリープはありません。1フレームは70 KB(ish)になり、35 KBサイズのフレームに戻ります。

これは前に別の実行で別のシーンを見ているときに起こりました。当時の一般的なファイルサイズは39 KBで、10,000フレームのうち4個は77 KB程度でした。画像サイズのヒストグラムは次のようになりました。

JPEGサイズヒストグラム

質問する前に、これらのフレームの1つを保存することができましたが、他のすべてのフレームが予想されるノイズ変動を妨げるように見えます。彼らは約23,000でほぼ同じ数のユニークな色を持っています。したがって、正確に1フレームの間レンズにランダムに着地してから飛び立つmothではありません。完全を期すために、別の画像を実行しましたが、これは典型的な画像の例です(反射はIRイルミネータです):

37Kの典型的な画像

これは異常画像です:-

73K異常画像

違いはありません。カバを失礼します。私はJPEGアルゴリズムにかなり精通しており、Foscamの実装でのコーディングエラー以外にこれがどのように起こるかはわかりません。しかし、いくつかのJPEG変換関数(離散コサイン変換や量子化など)には本質的に混chaとしたものがありますか?統計的には、ファイルサイズの正規分布が予想されますが、これは約39 KBです。次に、77 KBにいくつかの外れ値があります。したがって、確率論的には見えません。

これがハードウェアではなくCSにある理由は、これがJPEGエンコーディングアルゴリズムに関連するプログラミングコード現象である可能性があると私が尋ねているからですか?可能性は低いようですが、異常はランダムでまれであり、デバイスとの人間のやり取りはありません。JPEGエンコーディングは安定していますか?

この現象に慣れていないのは、画像が同じように見えるので、ファイルサイズを実際に見ている人がいないためです。ファイルサイズは私にとって非常に重要なので、気づきました。およそ2500フレームごとにこれをどのように行うことができますか?

補足:-

imgurソフトウェアがアップロードされたファイルを再サンプリングするため、これらの画像の投稿はうまくいきません。37Kと73Kのファイルを投稿している間、imgurは両方を35Kに再サンプリングしました。これはStack Exchangeの問題のようで、画像処理、データ圧縮、分析を扱うサイトにとって皮肉なようです。

これが私の画像処理です。これは、通常の画像と異常の間の正規化された差です。画像は予想どおり、高周波数領域にJPEGノイズがあります。モノクロに見えても、これはRGB画像です。カラーキューブには8000個の一意の色があります(ノイズを表します)。

37K画像と73K画像の正規化された差

補足2:-

要求に応じて、4つの正常なフレームと2つの異常なフレームをサンプルフレームからダウンロードできます。これは別のシーンですが、異常な動作がまだ発生しているため、これは一貫性があることを証明しています。


大きな画像のEXIF / ICMPフィールドを見ましたか?カメラが追加情報をそこに保存しているのかもしれません。
-MBaz

含まれている最初の2つの画像は両方ともほぼ同じサイズで、約36kです。なぜ彼らは70kと言っているのですか?おそらく、画像アップロードサイトはそれらを再エンコードしていますか?
ピーターK。


1
私の古いニコンでは、jpegとrawイメージの両方を取得できます。生の異常な画像をキャプチャしようとします。

うわー、この質問は一年前に聞かれましたが、まだ回答がありません。OPはそれを理解しましたか?
ラクシットコタリ

回答:


1

私の推測では、オートフォーカスまたは絞りは、結果の画像にさらに多くの高周波要素が含まれる方法で短時間変化するものです。

たとえば、滑らかなオブジェクトからテクスチャオブジェクト(滑らかなカバのように布のドレープなど)にフォーカスが移動し、後者の詳細なテクスチャサーフェスの場合、JPEGは非常に大きなサイズになる傾向があります。

他の誰かがすでに述べたように、画像のEXIFデータをチェックして、アパーチャや焦点距離などのコアパラメータの変化がないかどうかを確認することをお勧めします。このような画像サイズの顕著な違いについては、カメラの意見においていくつかの基本的なパラメーターが異なる可能性が非常に高いです。


0

「CMOS」センサーでは、「PURPLE FRINGING」または「Sensor Bloom」問題として知られる現象に遭遇するのが一般的です。これについては後で詳しく説明します。

ただし、PFがセンサーブルームの原因であるかどうか、またはその逆であるかどうかについて実際にいくつかの議論があることを伝えて、これを前書きする必要があります。これらの効果は、センサー内で捕捉された光のスパイクを引き起こす場合に過負荷を引き起こす結果的な効果の結果である可能性があります。ファイルを大きくする。

過負荷はマゼンタ(または紫)の範囲で発生すると信じていますが、この現象は非常にまれです。

センサーを巨大なアイスキューブトレイのように考えてください。異常が原因で1つのコンパートメントが水(光)で溢れた場合...隣接するコンパートメントなどに溢れ出し、そのバッチに対してわずかに大きな体積のアイスキューブのバッチが発生する可能性があります。(おそらく、より大きなファイルサイズとカラーデータの説明)

これは最良の推測であり、上記の詳細情報に役立つリンクが見つかりました-私の評価が間違っている場合に問題を特定するのに役立つ追加の技術情報と同様に。

このリンク http://toothwalker.org/optics/chromatic.htmlを確認してください

RGBは減法混色の色空間であることに注意してください。特定の波長の光を除去することにより、光による色(色素に対する)を操作します。一部の色の波長は他の波長よりも長くなっています。

このページには、異常の説明にも役立つ優れた光学レッスンがあります。


2
-1これが問題の答えだとは思わない。なぜ1つのフレームに突然センサーがブルームするのでしょうか?差分ファイルには、それまたは紫色のフリンジは表示されません。また、ファイルを2倍に大きくすることもありません。
オッリNiemitalo

また、RGBは加法色空間CMYKは減法色空間です。RGBでは、「紫」はR + B
MSalters
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.