Aynı sahnenin bazı JPEG dosyaları neden diğerlerinden daha büyük?


12

Sabit aydınlatma koşullarında statik bir sahneyi görüntülemek için bir Foscam FI8910W ip kamera kullanıyorum. Bir kare yakalamayı geri çektiğimde, boyutu yaklaşık 35 KB. Bunu tekrar tekrar yapabilirim ve her zaman 35 KB civarındadır, ancak elektronik görüntü yakalamanın doğasında bulunan çeşitli sesler nedeniyle biraz dalgalanır. Bu rastgele dalgalanma en fazla 1 KB düzeyindedir.

Her 2500 karede bir karenin görüntü boyutu aniden 70 KB düzeyindedir. Fotoğraf makinesi ısınırken termal gürültü düşünüyorsanız, yukarı doğru yavaş yavaş kayma olmaz. 1 kare 70 KB (ish) olur ve daha sonra 35 KB boyutunda karelere döner.

Bu daha önce farklı bir sahneye bakan başka bir koşu ile oldu. Ortak dosya boyutu 39 KB idi ve 10.000 kareden 4'ü 77 KB boyutundaydı. Görüntü boyutu histogramı şöyle görünüyordu:

JPEG boyutu histogramı

Sormadan önce, bu çerçevelerden birini kaydetmeyi başardım ve diğerleri gibi beklenen gürültü dalgalanmasını engelliyor gibi görünüyor. Yaklaşık 23.000'de kabaca aynı sayıda benzersiz renge sahiptirler. Bu yüzden tam olarak 1 kare için merceğe rastgele inen ve sonra uçan bir güve değil. Tamlık için, başka bir görüntü çalışması yaptım ve bu tipik bir görüntüdür (yansıma IR aydınlatıcıdır): -

37K tipik resim

Bu anomali görüntüsü: -

73K anomali görüntüsü

Fark olmadığını görebilirsiniz. Suaygırı özür dilerim. JPEG algoritmasına oldukça aşinayım ve bunun Foscam uygulamasında bir kodlama hatası dışında nasıl olabileceğini göremiyorum. Ancak, bazı JPEG dönüştürme işlevlerinde (ayrık kosinüs dönüşümü veya nicemleme gibi) doğal olarak kaotik bir şey olabilir mi? İstatistiksel olarak, dosya boyutunun normal bir dağılım beklenebilir ve 39 KB civarında gördüğüm budur. Sonra 77 KB'de birkaç aykırı değer var. Yani stokastik görünmüyor.

Bunun CS'de olması ve donanımda olmamasının nedeni, bu JPEG kodlama algoritması ile ilgili bir programlama kodu olgusu olabilir mi? Olası görünmüyor, ancak anomaliler rastgele ve nadirdir ve cihazla insan etkileşimi yoktur. JPEG kodlaması kararlı mı?

Bu fenomene aşina olmamanızın nedeni, görüntüler aynı göründükçe, hiç kimsenin dosya boyutlarına gerçekten bakmamasıdır. Dosya boyutu benim için kritik öneme sahip, bu yüzden fark ettim. Bu yaklaşık her 2500 karede bir nasıl olabilir?

Ek: -

İmgur yazılımı yüklenen dosyaları yeniden örneklediğinden, bu görüntüleri göndermek işe yaramayacaktır. Böylece 37K ve 73K dosyaları yayınlarken imgur her ikisini de 35K ile yeniden örnekledi. Bu görüntü işleme, veri sıkıştırma ve analiz ile uğraşan bir site için ironik gibi görünen bir Stack Exchange sorunu gibi görünüyor.

Bu benim görüntüleri işlemem. Normal bir görüntü ile anomali arasındaki normalleştirilmiş farktır. Görüntü beklediğiniz gibi, yüksek frekanslı bölgelerde JPEG gürültüsü var. Bu, tek renkli görünse bile bir RGB görüntüsüdür. Renk küpünde 8000 benzersiz renk vardır (gürültüyü temsil eder).

37K ve 73K görüntüler arasında normalleştirilmiş fark

Ek 2: -

İstendiği gibi, örnek çerçevelerden 4 normal çerçeve ve 2 anormal çerçeve indirilebilir . Farklı bir sahne, ama anormal davranış hala gerçekleşti, bu yüzden tutarlı olduğunu kanıtlıyor.


Daha büyük görüntülerin EXIF ​​/ ICMP alanlarına baktınız mı? Belki kamera orada fazladan bilgi saklıyor.
MBaz

Dahil edilen ilk iki resim kabaca aynı boyuttadır: yaklaşık 36k. Neden 70k olduklarını söylüyorsun? Belki resim yükleme sitesi onları yeniden kodluyor?
Peter K.


1
Eski Nikon'um hem jpeg hem de ham görüntü almama izin veriyor. Ham bir anormal görüntü yakalamaya çalışırdım.

Vay be, bu soru bir yıl önce soruldu ve hala bir cevap almadı. OP çözdü mü?
Rakshit Kothari

Yanıtlar:


1

Tahminim, otomatik netleme veya diyafram açıklığıyla elde edilen görüntünün daha yüksek frekanslı öğeler içereceği şekilde kısaca değişiyor.

Örneğin, odak pürüzsüz bir nesneden dokulu bir nesneye (yumuşak su aygırı gibi kumaş örtü gibi), ikinci detay doku yüzeylerinin bulunduğu bir şekilde hareket ederse, JPEG oldukça büyük bir boyut alır.

Başka birinin belirttiği gibi: diyafram ve odak mesafesi gibi temel parametrelerde değişiklik olup olmadığını görmek için görüntü EXIF ​​verilerini kontrol etmek iyi bir fikir gibi görünüyor. Görüntü boyutunda bu kadar çarpıcı bir fark için, kameranın görüşüne göre bazı temel parametrelerin farklı olması muhtemeldir.


0

"CMOS" sensörleri ile "MOR FRINGING" veya olası "Sensor Bloom" sorunları olarak bilinen bir fenomenle karşılaşmak yaygındır.

Bunu önceden anlatmalıyım, ancak aslında PF'nin Sensor Bloom'un nedeni olup olmadığı hakkında bir tartışma olduğunu söyleyebilirim veya bunun tersi, ancak sonuçta: her ikisi de lensdeki veya kamera sensörünün kendisindeki anormalliklerin sonucu olabilir - veya her ikisi. Bu etkiler, sensörde, sırayla yakalanan ışıkta bir artışa neden olacaksanız aşırı yüklenmeye neden olan bir ara etkinin sonucu olabilir. DOSYAYI BÜYÜK YAPMAK.

Aşırı yüklenmenin eflatun (veya mor) aralıkta meydana geldiğine inanıyorum ve bu fenomen oldukça nadirdir.

Sensörü büyük bir buz küpü tepsisi gibi düşünün ..... moda gibi bir ızgarada düzenlendi. Bir bölme anormallik nedeniyle su (ışık) ile DOLDURURSA ... bitişik bölmelere dökülebilir ve böylece, bu parti için biraz daha büyük hacimli buz küplerine neden olabilir. (Muhtemelen daha büyük dosya boyutunu açıklamak ... VE renk verileri)

Şimdi bu en iyi tahmin ve yukarıda hakkında daha fazla bilgi ile yararlı bulabilirsiniz bir bağlantı buldum - AS WELL AS benim değerlendirme yanlış varsa sizin için sorunu izole yardımcı olabilir bazı ek teknik bilgi.

Bu bağlantıya göz atın http://toothwalker.org/optics/chromatic.html

RGB'nin çıkarıcı bir renk alanı olduğunu unutmayın. Işık yoluyla (pigmentlere karşı) renk, belirli dalga boylarındaki ışığı kaldırarak manipüle edilir. Bazı renk dalga boyları diğerlerinden daha uzundur.

Sayfada, anormalliği de açıklamaya yardımcı olabilecek harika bir optik dersi var.


2
-1 Bunun sorunun cevabı olduğunu düşünmüyorum. Neden aniden bir çerçevede sensör çiçeklenmesi olur? Fark dosyası bunu veya mor saçaklamayı göstermez. Ayrıca dosyayı 2 kat daha büyük yapmaz.
Olli Niemitalo

Ayrıca, RGB katkı maddesi renk alanı CMYK çıkarıcı olanıdır.
RGB'de
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.