640x480 JPEG'nin en büyük boyutu nedir?


25

Birkaç saat içinde gece gökyüzünün belirli sayıda fotoğrafını çeken bir veri depolama aygıtı oluşturuyorum ve fotoğraflar çekildikten hemen sonra indirilecek. Hafıza kartı tüm fotoğrafları bir kerede kaydedebilmelidir.

Alınacak JPEG'ler 640x480 pikseldir ve hafıza kartında her biri için yeterli alan bulunması şarttır. Peki, 640x480 JPEG’in en büyük boyutu nedir?

Bunu anlamak için bazı test fotoğrafları çektim:

1.2.3.

  • "Stackoverflow" dosyasının dosya boyutu 73,774 bayttır.
  • Beyaz görüntünün dosya boyutu yalnızca 36,607 bayttır.
  • Ancak, damalı fotoğrafın dosya boyutu 149.339 baytta.

Dosya boyutunun karmaşıklıkla arttığını farz ediyorum.

Ne kadar karmaşık ve ne boyutta olacaklarını bilmeden, bellek kartına 100 640x480 JPEGS'e sığacak kadar yer nasıl kurabilirim? Bu yakalama cihazlarının çoğunu yaptığım için fazladan yer harcamak istemiyorum.


görüntü üreticisine bağlıdır. 100 kalitede JPEG kolayca boyutta patlayabilir. Kamera ve kamera ayarlarınız nedir?
John Dvorak

Test kamerası bir Canon Powershot A1100 IS'dir. Daha fazla bilgi için meta verileri kontrol edebilirsiniz, çünkü ne istediğinden emin değilim.
Blue Ice

1
DIF de gece gökyüzünün herhangi bir örnek fotoğraflarını Çekti. Q ayarları? Test olarak mı?
Carl B,

2
Bu ne için ? JPEG'in doğru format seçimi olduğuna emin misiniz?
Jack Aidley

3
Jack Aidleys yorumuna bazı arka plan eklemek: JPEG sıkıştırma resmi değiştirir. Daha küçük bir dosya boyutu elde etmek için varsayımlarda bulunur ve bilgileri atar. (% 100 kalitesine ayarlanmadıkça, bu durumda da sıkıştırılmamış bir format kullanabilirsiniz. Genellikle dijital fotoğraf makinesinin bunun için bir sert ve hatta ham ayarı vardır. Yıldızlar gibi tüm küçük noktaları saklamak istiyorsanız, aşağıdakilerden birini kullanın. bunlar). Bu aynı zamanda bir görüntünün boyutunu tamamen tahmin edilebilir hale getirecektir.
Hennes

Yanıtlar:


22

Burada JPEG dosya boyutları için bir üst sınır öneriyorum. Daha tipik jpeg boyutlarının tartışılması için Ilmari Karonen'in cevabına bakınız .

640X480 32 bit bitmap görüntü için piksel depolama alanı şu şekilde hesaplanabilir ( bu cevaba göre, ancak Ignacio Vazquez-Abrams'ın yorumuna ve bu cevaba göre düzeltilmiş ):

Dosyaya sıkıştırma uygulanmadığını varsayarsak, 0.3MP olan 307.200 piksel vardır. Kullanışlı masaya bak

Her piksel 32 bit bilgi içeriyorsa, o zaman

  1. 307,200 * 32 = 9,830,400 bilgi bit
  2. Bayt değeri olmak için 8 bit'e bölün
  3. 9,830,400 / 8 = 1228800 bayt (Veya 1,17 Mb)

Bu, sıkıştırılmamış bir bitmap'in boyutudur ve jpeg dosyasının boyutu için üst sınır olmalıdır (gerçekte, JPEG formatı sıkıştırma kullandığından , resimleriniz özellikle gece çekiyorsanız, çok daha küçük olmalıdır) çok fazla siyah içerdiğini düşündüğüm gökyüzü, sorunuzdaki en büyük örnek resmin yalnızca 0,14 MB olduğunu unutmayın.

Bununla birlikte, özel konunuzla ilgili olarak, bu üst sınır kullanılsa bile, 100 görüntü yalnızca 117 MB boyutunda ve 128 MB kadar küçük bir bellek kartı görmeye başladığımdan bu yana çok uzun zaman geçti. Şu anda mevcut herhangi bir hafıza kartının ihtiyaçlarınızı karşılamak için yeterli kapasiteye sahip olacağını düşünüyorum.

Görünüşe göre maksimum jpeg dosya boyutu sorunu bazı tartışmalara tabidir. Bu Yığın Taşması cevabı, piksel başına 20.25 baytlık bir teorik veya maksimum 5.9 MB boyutunda bir teorik olarak ortaya koyuyor, ancak bu boyutta bir görüntü üretmek için jpeg formatının sıkıştırma planının kasıtlı olarak kötüye kullanılması gerekiyor. Bir kamera tarafından üretilen bir şey.


1
Maalesef sıkıştırılmamış bitmap değeri bile bir miktar düşüktür, çünkü paketlemeyi varsaymaktadır. Paketten çıkarılmış bir bitmap, piksel başına 32 bit kullanır ( hizalama nedeniyle), dosya boyutunu% 33 oranında artırır.
Ignacio Vazquez-Abrams

IgnacioVazquez-Abrams @ teşekkürler. Kabul edilen bir cevabın doğru olduğunu varsaydığım için aldığım şey bu.
ForeverWintr

1
@ IgnacioVazquez-Abrams - "Hizalama", işlemcinin belirlediği bir özelliktir (depolama ortamı değil) ve veriler işleme için RAM'deyken uygundur. Depolama amacıyla, 32-bit bir kelime hizalaması bir gereklilik değildir ve kesinlikle bir savurganlık değildir. Ambalaj verileri, özellikle% 25'lik bir tasarruf için depoya yazmaya başlamadan önce yaygın bir işlemdir. Ham formatı için her pikseli tam 3 byte depolayan dijital kameralar gördüm.
talaş

1
“... kesinlikle bir savurganlık.” Şu günlerde. Birçok ay önce, döngü tasarrufu sağlayan bir özellik olarak kullanılırdı (ne kadar süreceği göz önüne alındığında, yüke uyum sağlamanız gerekmez).
Ignacio Vazquez-Abrams

3
Uygulamada, bazı sistemler RGB görüntü verilerini bellekte piksel başına 4 bayt olarak saklayabilirken , hemen hemen tüm görüntü dosyası biçimleri piksel başına en çok 3 bayt kullanır (dördüncü baytta depolanan gerçek bir alfa kanalı olmadığı sürece). Aşağıdaki cevaba bakınız.
Ilmari Karonen

35

Sadece kontrol etmek için, ForeverWintr analizini deneysel olarak test edeyim .

JPEG sıkıştırması için en kötü giriş görüntüsü (veya herhangi bir sıkıştırma, gerçekten), teorik olarak sıkıştırılamaz olan, düzgün bir şekilde rastgele RGB gürültüsüdür. Netpbm araçlarını kullanarak biraz üreteyim :

$ rawtoppm < /dev/urandom 640 480 > rnd.ppm
$ pnmtopng < rnd.ppm > rnd.png
$ du -b rnd.*
923772  rnd.png
921615  rnd.ppm

Düzgün rastgele RGB gürültüsü, kayıpsız PNG formatı
(Tek tip rastgele RGB gürültüsü, kayıpsız PNG formatı, 903 kb)

Not (2017 Mart): Emin görüntü yukarıdaki oldukça değilim idi (. Kuvvetle bu ima altındaki renk yönetimi hakkında bir yorum bile var) Ben ilk bu cevabı yazdım ve 2013 yılında geri yüklerken PNG biçiminde yazık ki, it would Görünüşe göre sessizce JPEG'e çevrilmiş, burada görsel karşılaştırmayı işe yaramaz hale getirmiş.

PNG sınama görüntüsünü yeniden yüklemeye çalıştım, ancak görünüşe göre imgur'da rastgele bir PNG dosya boyutu sınırına çarpıyor ve otomatik olarak JPEG formatına dönüştürülüyor. Bu sorunu çözmenin bir yolu olup olmadığından emin değilim, ancak en azından bir Linux kutusuna erişiminiz varsa, kendi test resimlerinizi oluşturmak için verilen komutları her zaman yeniden çalıştırabilirsiniz. Her durumda, sıkıştırma kalitesinin doğrudan görsel karşılaştırmasını önlemek dışında, bu, aşağıdaki analizi hiçbir şekilde geçersiz kılmaz.

Tamam, sıkıştırılmamış PPM dosyası 640 × 480 × 3 = 921,600 bayt uzunluğunda, minimum PPM başlığı için 15 bayttır, beklendiği gibi. PNG formatını kullanarak kayıpsız şekilde sıkıştırmaya çalışmak, büyüklüğü 2157 byte artırarak, muhtemelen PNG başlıkları ve meta verileri tarafından alınır ve sıkıştırılabilir veriyi sıkıştırmaya çalışan sıkıştırma algoritmasında muhtemelen biraz verimsizliği artırır.

(Evet, bu piksel başına 3 bayt değil, 4 değil; alabilirsiniz bir grafik dosya biçimi olarak basit olarak hakkındadır bile PPM biçimini, diskte piksel başına bir işe yaramaz dördüncü byte depolamak için dilsiz yeterli değildir vardır. Açabilir bazı olmak hizalama nedenleriyle bunu hafızaya kaydetme avantajı, özellikle alfa kanalını kaydetmeniz gerekiyorsa, ancak bu sebepler görüntüyü bir dosyaya yazarken geçerli değildir.)

Tamam, peki ya JPEG? Önce sıkıştırma kayıplarını en aza indirmeye çalışalım (kalite = 100, kroma alt örneği yok, kayan nokta DCT). Ne yazık ki, pnmtojpegel kitabı tüm ilgili seçeneklerin nasıl ayarlanacağını net bir şekilde açıklamıyor (özellikle, -sampleseçenek sadece libjpeg belgesindeki bir dosyaya atıfta bulunan "Sihirbazlar için Seçenekler" bölümünde listelenmiştir), bunun yerine GIMP. Ortaya çıkan dosya şöyle görünür:

897249  rnd.jpg

JPEG sıkıştırılmış RGB gürültüsü, kalite = 100, kroma alt örneği yok
(JPEG sıkıştırılmış RGB gürültüsü, kalite = 100, kroma alt örneği yok, 876 kb)

Ne, daha küçük olabilir? Saf sesin sıkıştırılamaz olduğunu söylemedim mi? Mesele, normal JPEG sıkıştırma değil, hatta maksimum kalitede olduğu oldukça kayıpsız. Görüntünün GIMP'de yeniden açılması ve orijinal ile karşılaştırılması, bazı piksellerin renk değerlerinin bir veya iki adımda (256'dan) değiştirildiğini görebilir. Bunlar, JPEG sıkıştırma algoritmasının "aldattığı" ve burada bir parça attığı pikseller, başka bir yerde, değişimin farkedilmeyeceğini tahmin ediyordu. Nitekim, yardımsız insan gözüne göre, sonuç orijinalden oldukça ayırt edilemez, ancak atılan bitler, başlık için muhasebe ve ek yükü kodladıktan sonra bile, dosya boyutunda ölçülebilir bir düşüşe neden oluyor.

Yani bu maksimum kalite idi; pnmtojpegvarsayılanlar gibi daha tipik ayarlar ne durumda (kalite = 75, alt örnekleme etkin)? Hadi deneyelim:

$ pnmtojpeg < rnd.ppm > rnd2.jpg
$ du -b rnd2.jpg
185128  rnd2.jpg

JPEG sıkıştırılmış RGB gürültüsü, kalite = 75, kroma örnekleme
(JPEG sıkıştırılmış RGB gürültüsü, kalite = 75, kroma örnekleme, 184 kb)

Vay, 901'den 184 kb'ye kadar! Bu oldukça agresif bir sıkıştırma olsa da, görüntüleri yakından karşılaştırırken kesinlikle farkı anlayabilirsiniz. Bunların çoğu, temelde renk (% / doygunluk) verilerinin% 75'ini ortadan kaldıran kroma alt örneklemesinden dolayıdır. GIMP'de alt örnekleme devre dışı bırakılmış şekilde denemek, büyütülmüş olsa bile hala orijinal görünüme oldukça yakın görünen (en azından insan gözüne) 350,618 baytlık bir dosya verir.

Neyse, bunun ana fikri olduğunu göstermektir, gürültülü senin gece gökyüzü fotoğrafları olabileceğini nasıl olursa olsun, ve seçtiğiniz nasıl yüksek kaliteli olursa olsun, sadece orada hiçbir şekilde bir 640 × 480 JPEG dosyası 900 önemli ölçüde daha büyük olsun kb. (Fotoğraf makineniz buna çok megabaytlık bir Exif renk profili eklememişse veya aynı derecede aptalca bir şey değilse, yani.) Ve daha tipik JPEG sıkıştırma ayarları kullanıyorsanız, maksimum makul dosya boyutu yaklaşık 200 kb'ye kadar düşer. .


4
teorik olarak sıkıştırılamaz sadece kayıpsız sıkıştırma için olsa, değil mi?
Daniel Beck

1
@DanielBeck: Doğru. Açıkçası, sadece bir kısmını atmak için istekliysanız, istediğiniz kadar veriyi sıkıştırabilirsiniz. (Temelde JPEG sıkıştırmasının yaptığı budur, sadece kayıp kısımların insan gözüyle fark edilemeyeceği ve geriye kalanların da kompakt bir şekilde kodlanabileceği şekilde yapmaya çalışır. Gürültü hala çok zor bir durumdur. Kayıplı bir sıkıştırma algoritmasının bile gürültü ile yapabileceği tek şey, bunun parçalarını atmaktır.)
Ilmari Karonen

Belki bu sadece benim, ama ikinci görüntü birinciden daha parlak görünüyor.
Bogdacutu

@Bogdacutu: Olmamalı, her zaman tarayıcınızın renk yönetimi vb. İle garip bir şeyler yapması mümkün olsa da, her ikisini de bir grafik düzenleyiciye yüklemeyi ve renk değerlerini karşılaştırmayı deneyin.
Ilmari Karonen

@Ilmari'de güzel yazı.
ForeverWintr
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.