Sonuç olarak, tüm dijital görüntüler yalnızca 0 - 255 arasındaki piksel değerleri değil midir?

Resimlerle ilgili inanılmaz derecede basit (aptal?) Birkaç sorum var; özellikle görüntü formatları ve piksel değerleri.

Affet beni, fotoğrafçı değilim. Ben sadece görüntülerle çalışan biriyim ve bana göre onlar sadece sayı ve satır sütunlarıdır.

Benim sorularım:

Çekirdekte, fotoğraflar yalnızca 3 kanal piksel değerinde [0, 255] X RBG ise, iki resim formatı arasında nasıl bir fark olabilir? Yani, RAW'ı TIFF'den farklı kılan şey, bunların tümü 0-255 arasındaki değerlerle sınırlı değil midir? Sayı, sayıdır - yalnızca bir ayar formatı mümkün olmamalı mı? Veya, aynı yüksekliğe ve genişliğe sahip iki görüntü aynı dosya boyutuna sahip olmamalı mı?

Ayrıca, sayısal bir bakış açısından, 32 bit görüntülerden farklı bir 16 bit görüntü gibi bir şey yapan şey nedir? Yine, bir görüntü sadece 0 -255 arasında tamsayı değerleri olan bir dizidir.

Bu perspektife devam ederek, bir bilgisayarın dosya sistemindeki bir görüntünün 0-255 arasında sadece 3 kanallı bir tamsayı dizisi olduğu gibi, bir görüntüyü örneğin JPG gibi kayıp bir formatta sıkıştırmanın amacı nedir? Sıkıştırma algosunun bazı piksel değerlerini 254'ten 255'e ya da her neyse değiştirdiğini söyleyin. Yani? Bu, dosya boyutunda herhangi bir tasarruf sağlar veya görsel kaliteyi nasıl etkiler?

Görüntü verilerini depolamanın birçok farklı yolu olduğunu biliyorum. Ancak 3 kanallı temel bir RBC görüntüsünden başka bir şey sormuyorum. Tek bildiğim, eğer biri bana bunlardan birini verirse, şimdi bir dizi numaram var. Bir sayı dizisinin neden 0 - 255 arasındaki bazı diğer sayı dizilerinden farklı olabileceğini bilmek için hiçbir nedenim yok. Umarım bu mantıklı olur. Bu soru RAW formatı ile sınırlı değildir! Aksine, herhangi bir piksel değer dizisi hakkında

Maalesef, temel öncülünüz yanlış: bir görüntü , değer başına 8 bitlik bir RBG piksel dizisi olarak kodlanabilir, ancak başka birçok yol vardır:

• bir bit / kanallı bir kanal (saf siyah ve beyaz),
• ile bir kanal x bit / kanal (gri tonlama biçimleri, X , genellikle 256 veya 65536 değerleri veren, 8 ya da 16 olacaktır)
• çeşitli palet tabanlı formatlar (cf.GIF)
• Tam renkli (en azından teoride) istediğiniz bit derinliği ile istediğiniz kadar kanal.

Ve bu düzenleme / görüntüleme sırasında bilgisayarın RAM'inde depolanan görüntü için. Var olan çeşitli RAW resim formatlarını görmezden geliyorum (burada ve bu yazının geri kalanında).

Fotoğraf çekimi için en yaygın olanı 8, 16 veya 32 bit / kanallı 3 kanaldır (genellikle tam sayı, ancak en azından bazı programlar dahili olarak 32 bit kayan nokta sayılarıyla çalışır). Genelde, özellikle program katman kullanımına izin verdiğinde 4. bir kanal (alfa) vardır. Ve bir yerlerde, resim dizisinin boyutlarının kaydedilmesi gerekir.

Bu farklı biçimlerin çeşitli nedenleri vardır. Bellek içi format için, verilerin büyüklüğü ve hız olarak kullanılan önemli bir husus (bir 8 bit kanalın 4 32 bit kanaldan daha hızlı kullanılması için daha hızlı). Bunlar bugünlerde daha az önemli, ancak çeşitli renk alanlarıyla tam renk yönetimine sahibiz. Bunlardan bazıları (örneğin prophoto RGB), görünür şeritlenmeyi önlemek için komşu renkler arasındaki farkları küçük tutmak için en az 16 bit / kanala ihtiyaç duyar. Tedaviler daha karmaşık hale geldikçe, 32 bit kayan nokta sayıları kullanmanın avantajları vardır (renklerin 0.0 ile 1.0 arasındaki değerlerle kodlandığı ve işlem bu aralığın dışındaki ara değerlere izin verir).

Görüntüyü dosyada saklamak ve aynı hafıza içi verilere yeniden yüklemek istiyorsanız, her kanal için en az im-hafıza formatı kadar bit kullanmanız gerekir. görüntü boyutları, bit derinliği ve renk uzayı.

Bu görüntülerin kullanıcıları, görüntüyle ilgili bazı ek bilgileri de depolamayı severler (başlık, başlık, görüntüyü alan vb.). Yine bu bilgileri saklamanın çeşitli yolları var.

Sonra görüntü verilerini dosya depolamak için sıkıştırmanın farklı yolları vardır. En basit olanlardan biri, tekrarlanan bir piksel değeriyle karşılaştığınızda sayımı ve piksel değerini kaydettiğiniz RLE'dir (Çalışma Uzunluğu Kodlaması). Jpeg gibi diğerleri ise çok daha karmaşıktır, fakat aynı zamanda çok daha fazla sıkıştırma sağlar. Örneğin, jpeg bir kosinüs dönüşümü kullanır ve (daha az görünür) yüksek frekanslı bilgiyi atarak, bilgi kaybı maliyetinde yüksek sıkıştırma oranları verir (buna daha fazlası var, ancak bu çok uzun sürüyor).

Bu, bilgileri diskte depolamak için zaten birçok yol sunar, ancak seçtiğiniz yol ne olursa olsun, görüntünün yüklenmesinde doğru yorumlamaya izin vermek için biçimin iyi belirtilmesi gerekir.

Daha sonra, örneğin mevcut formatların her zaman idare edemediği kayıpsız sıkıştırma tekniklerinde sürekli bir gelişme vardır.

Bu yüzden, saklanan bilgilerin doğruluğu, kullanılan disk alanı ve okuma, yazma ve aktarma hızı arasındaki çeşitli dosya biçimleriyle sonuçlanıyoruz (sıkıştırılmamış bir TIFF'nin boyutunu ve iyi kalitede bir jpg'yi karşılaştırın) .

Bellek içi bir görüntü işlenirse, bir veya daha fazla dizi şeklinde olacaktır. Bu noktada, orijinal dosya formatı artık bir rol oynamamalı . Verilerinizi 8 bit / kanal ile ele aldığınızı varsayacağım.

Ancak, işlenmiş bir görüntünüz veya ham bir görüntünüz olup olmadığını bilmeniz gerekir, çünkü bunlar arasında iki önemli fark vardır:

• Ham görüntüler tipik olarak piksel başına 1 renge sahiptir ve pikseller, genellikle 4 piksel kare başına 2 yeşil, 1 kırmızı ve 1 mavi piksel içeren bir Bayer dizisinde düzenlenir . Değerler sahne yoğunluğuyla orantılıdır (çok düşük ve çok yüksek değerler hariç).
• işlenmiş görüntüler, 3 sayısal değer içeren bir 2D kayıt dizisi olarak veya renkli düzlemler olarak (R, G, B'nin her biri için bir tane olmak üzere 3 2D dizileri) düzenlenebilir. Ek olarak, değerler genellikle sahne yoğunluklarıyla orantılı değildir . Daha kötüsü, piksel değerleri ve sahne yoğunluğu arasındaki kesin ilişki görüntünün sahip olduğu işleme bağlıdır. Ve renkler arasındaki denge insan gözünün tepkisine karşılık gelecek şekilde ayarlandı (Beyaz Dengesi, kırmızı ve mavi yeşile göre büyütülür).

Öyleyse, piksel başına 3 renk değerine sahip ham bir görüntü elde ederseniz, bu ham görüntünün zaten bir tedavisi olmuştur (en azından ya demosaicing veya 4 ham pikselin 1 görüntü pikseline basit bir şekilde bindirilmesi ). Bunun kabul edilebilir olup olmadığı, başvurunuza bağlı olacaktır.

Çekirdekte ise, fotoğraflar yalnızca 3 kanal piksel değerindedir [0, 255] X RBG,

Ancak fotoğraflar "çekirdekte sadece" bile 3 piksel değeri " değil ". Bilgisayar ekranları genellikle bir dizi RGB pikselinden oluşur, bu nedenle bir görüntüyü bilgisayar ekranında görüntülemek istiyorsanız, bir noktada sahip olduğunuz görüntü verilerini ne olursa olsun bir RGB piksel dizisine eşlemelisiniz, ancak bu veriler yalnızca görüntü verilerinin belirli bir gösterimi. Görüntüdeki veriler hiç bir piksel değerleri akışından oluşmayabilir. Bir görüntüden piksel değerleri elde etmek için verilerin nasıl biçimlendirildiğini bilmeniz gerekir.

o zaman iki resim formatı arasında nasıl bir fark olabilir? Yani, RAW'ı TIFF'den farklı kılan şey, bunların tümü 0-255 arasındaki değerlerle sınırlı değil midir?

Bunlar iki iyi örnektir, çünkü bu formatlardan hiçbiri mutlaka dikdörtgen bir RGB değerleri dizisine sahip değildir.

RAW, tek bir format değildir - doğrudan bir görüntü sensöründen kaydedilmiş verileri içeren dosyalar için bir tür yakalama adıdır. Bu nedenle, bir RAW dosyası, çeşitli sensör sitelerinden okunan voltajları temsil eden bir değerler dizisi içerebilir. Bunlar siteleri gibi görüntü piksel, ancak konum değil RGB piksel. RGB piksellerini bir RAW dosyasından almak için, bu verileri sensör, o andaki kamera ayarları vb. Bilgileri bağlamında yorumlamanız gerekir. Başka bir deyişle, bir hex editöründe bir RAW dosyası açabilirsiniz. ve istediğine bak, ama tek bir RGB değeri bulamazsın.

TIFF, etiketli resim dosyası formatını ifade eder ve çok ilginç bir formattır çünkü bir resmin birçok farklı sunumunu içerebilir. Tek bir TIFF dosyası, bir minik resim, ekran çözünürlüğü resmi ve baskı çözünürlüğü resmi gibi çeşitli boyutlarda "aynı" resmi içerebilir ve ayrıca renkli ve gri tonlamalı sürümleri de olabilir. Faks makinelerinin genellikle verilerini TIFF dosyaları olarak gönderdiğini biliyor muydunuz? RGB piksellerini bir TIFF dosyasından çıkarmak için, yalnızca TIFF biçimini değil, aynı zamanda bu dosyadaki belirli görüntü temsil biçimini de anlamanız gerekir.

Sayı, sayıdır - yalnızca bir ayar formatı mümkün olmamalı mı?

Hayır. Çok sayıda farklı görüntü formatları vardır çünkü insanlar her biri farklı ihtiyaçlara hizmet eder. JPEG'nin kayıplı sıkıştırması, çok küçük görüntü dosyaları elde etmek için mükemmeldir, ancak birkaç kez düzenlenmesi gereken görüntüler için iyi değildir. Bazı biçimler kullanır örmek çok hızlı birkaç farklı çözünürlüklerde görüntü okumayı yapar. Ve böylece ... her format kendi avantaj ve ödün karışımını sunar.

Veya, aynı yüksekliğe ve genişliğe sahip iki görüntü aynı dosya boyutuna sahip olmamalı mı?

Hayır, bu korkunç olurdu. Her görüntü dosyasının boyutu esasen width * height * 3(24 bit renk varsayarak) olması gerekiyorsa, çok fazla depolama alanı israf edersiniz . Fotoğrafların çoğu, çok fazla fazlalık içeriyor, yani aynı rengin birçok kez tekrarlandığı bölgeler. Depolama alanından tasarruf etmek için, bu gereksiz bilgileri elimine etmenin çoğu zaman bir anlamı vardır. Bunu yapmanın bir yolu, örneğin çalışma uzunluğu kodlamasıdırveya RLE. Örneğin, ardışık 4195 piksellik bir bölgeniz varsa, tümü beyaz olan birçok beyaz pikseli saklamak yerine "sonraki 4195 piksellerin hepsinin {255, 255, 255}" olduğunu belirtmek çok daha etkilidir. dosya. RLE aslında bazı görüntü formatlarında kullanılır, ancak birçok format daha fazla alan kazandıran çok daha karmaşık şemalara sahiptir ve bu da bir sabit sürücüde veya hafıza kartında daha fazla görüntü saklayabileceğiniz anlamına gelir. Ayrıca görüntüyü bir başkasına göndermeyi çok daha hızlı hale getirir.

Bu perspektife devam ederek, bir bilgisayarın dosya sistemindeki bir görüntünün 0 - 255 arasında yalnızca 3 kanallı bir tamsayı dizisi olduğu gibi, bir görüntüyü örneğin JPG gibi kayıp bir formatta sıkıştırmanın amacı nedir?

Mesele şu ki, dosyayı çok daha küçük yapıyor. JPEG sıkıştırması sıklıkla bir dosyanın boyutunu 10 veya daha fazla bir faktörle azaltır. Bu, belirli bir depolama cihazına daha fazla görüntü sığdırabileceğiniz, daha hızlı kopyalayabileceğiniz, daha hızlı açabileceğiniz ve daha hızlı yükleyip indirebileceğiniz anlamına gelir. Aynı görüntüyü (ya da neredeyse neredeyse) çok daha küçük bir alanda saklamak kaynakları daha verimli kullanır ve dolayısıyla maliyeti azaltır. Bunu büyük ölçüde düşünün: İnternette mevcut olan bilgilerin çok büyük bir kısmının görüntüler ve filmlerden oluşması muhtemeldir ve sıkıştırma olmadan daha fazla veya daha büyük veri merkezlerine ihtiyaç duyar ve daha fazla enerji tüketiriz.

Sıkıştırma algosunun bazı piksel değerlerini 254'ten 255'e ya da her neyse değiştirdiğini söyleyin. Yani? Bu, dosya boyutunda herhangi bir tasarruf sağlar veya görsel kaliteyi nasıl etkiler?

Yukarıdaki RLE örneğimi düşünün. Büyük bir boş duvar içeren bir fotoğrafınız olduğunu varsayalım, bu nedenle fotoğrafınızın geniş alanları aynı renktedir, ancak görüntüde neredeyse farkedilmeyen biraz daha koyu piksellerin saçılması vardır. Bu pikseller sıkıştırma etkinliğini azaltır. Sadece "sonraki 500.000 pikselin tümü {243, 251, 227}" diyebilmek yerine, uzunluğunu kodlamanız gerekir, çünkü her biri çoğu zaman biraz farklı piksellerden birine rastlarsınız. Sıkıştırma algoritmasının küçük değişiklikler yapmasına izin verirseniz, belki de yalnızca herhangi bir pikseli% 1 veya% 2'den fazla değiştirmeden değiştirebilirseniz, görüntüyü algılayarak değiştirmeden çok daha yüksek bir sıkıştırma oranı elde edebilirsiniz. Bu bir takas: siz dosya boyutunda büyük bir küçülme karşılığında, orijinal görüntüdeki az miktarda bilgiden vazgeçmek. Tam olarak bu çizgiyi çizmek istediğiniz yer değişebilir, bu nedenle JPEG gibi kayıplı formatlar kullanıcının istediği sıkıştırma düzeyini seçmesine izin verir.

@ Remco'nun fantastik cevabına ek olarak , aynı amaç için neden farklı kodlayıcılar bulunduğunu da eklemek istiyorum.

Codec'ler şunlar için tasarlanmıştır:

• Kayıpsız olun vs kayıplı
• Hızlı kodlayın VS. dosya boyutu azaltmak
• Asimetrik ve Simetrik kod çözme
• Yazılımla uyumlu olun
• Farklı sıkıştırma seviyelerinde / durumlarda algısal olarak neredeyse kayıpsız olun
• Aşağıdakiler dahil diğer kodeklerin sunmadığı özelliklere sahip olun:
  • telifsiz olmak
  • katmanlar için destek
  • alfa kanalı (örneğin RGBA) / transparrency desteği
  • hızlı web görünümü sun
  • yüksek (er) bit derinliğini destekler
  • çoklu renk alanlarını destekler (RGB / CMYK)
  • meta veri / sürüm oluşturma / ... için destek

Bunlardan bazıları karşılıklı olarak özeldir. Ve bu nedenle, çok sayıda kodek kaldı.

Birkaç örnek

Not: Kodeklerin listesi ne tamamlanmış ne de tüm özellikleri (ya da eksikliği) belirtilmemiştir. Bu cevap birisinin yararlı olduğunu kanıtlarsa, daha fazla bilgi ekleyebilirim (ve biraz daha kesin olabilirim).

Belki de en yaygın bilinen format JPEG'dir . Çok geniş, ama eski bir formattır. DCT'yi (Ayrık Cosine Transformation) kullanır, bu nedenle en yüksek kalite ayarlarında oldukça iyi kalite sunarken, daha düşük olanlarla blokaj görünecektir.

Sonra JPEG 2000 JPEG yerine geldi: Wavelet-Transformation'a dayanıyor, bu yüzden daha yüksek kalite ayarlarında JPEG ile aynı kaliteyi sunarken, daha düşük kalite ayarlarında çok daha iyi kalite sunuyor (bloklar biraz bulanık ). Ayrıca, JPEG 2000, ilgilenilen bölgeleri (resmin bir bölgesinde yüksek kalite, başka bir yerde daha düşük kalite) ve 16 bit destek sunar. (Ayrıca, diğer bazı şeyler.) Ne yazık ki (?), JPEG'den daha hesaplamalı bir pahalı olduğundan ve bazı lisanslama endişelerinden dolayı, JPEG 2000, JPEG kadar geniş bir şekilde desteklenmemektedir.

PNG , bilinen başka bir formattır - kayıpsızdır ve alfa kanallarını destekler, ancak RGB olmayan renk uzayları için destek sunmaz (CMYK gibi). Bu nedenle, "yalnızca çevrimiçi" bir biçimdir.

Sonra OpenEXR gibi VFX biçimleri var . Hepsi kalite ve hız etrafında döner: OpenEXR kayıpsızdır, 64bit'e kadar destekler ve hızlı kodlar / kod çözer. Genel olarak VFX endüstrisinde orta format olarak kullanılır.

TIFF , fotoğrafçılar arasında oldukça popüler olan bir başka kayıpsız formattır. Sıkıştırma için hiçbiri / ZIP / RLE / LZW / JPEG sunar. 32bit'e kadar destekler. Seçilebilir sıkıştırma özelliği ile oldukça uyumludur, ancak kayıpsızlığından dolayı daha çok çevrimdışı bir biçimdedir.

HEIF , en yeni görüntü kodeklerinden biridir. HEVC / h.265 ile aynı sıkıştırmayı kullanır ve bu nedenle JPEG'den daha iyi bir sıkıştırma oranı vermesi beklenir. Bununla birlikte, bu oldukça yenidir ve patent tabi olduğu için, bu kadar geniş şekilde desteklenmemektedir bir yukarıdakilerin.

RAW görüntüler ^{Ayrıca bkz.} Gerçek resimler değil, gerçekten: Bunlar daha çok ham (dolayısıyla isim) sensör okuma verileri için bir konteyner niteliğindedir. Sadece verileri nasıl yorumlayacağını bilen bir yazılımla resim çekmek mümkündür. Bu nedenle, Lightroom / Capture One / DarkTable / ... gibi RAW dönüştürücülerinin, Canon için * .CR2 gibi önceden belirlenmiş kapları kullanan yeni kameraları desteklemek için güncellemelere ihtiyacı var. 14bit RAW'ın, aynı RAW'tan dışa aktardığınız 32bit TIFF'den daha fazla düzenleme seçeneği sunmasının nedeni de budur.

Intermisision: Kayıpsız vs kayıp

Gerçekte ne sorduğunuzu hala bilmiyorum, bu yüzden kayıpsız ve kayıpsız hakkında küçük bir açıklama eklemenin zarar vermeyeceğini düşündüm.

Kayıpsız sıkıştırma yaparak çalışır işletilen uzunlukta kodlama (RLE) / Huffman kodlaması / ... verileri sıkıştırmak için. Verilerin kendisi değişmez, ancak daha küçük bir pakette saklanır. Örneğin, RLE'yi alın: Diyelim ki, R-kanal bir bit akışımız var (pikselden 0,0piksele 0,11) 255,255,255,255,255,215,215,235,100,000,000,000- RLE bunu şu şekilde kodlar 52552215123511003000- bu çok daha küçüktür, ve bunun 4 basamaklı gruplar halinde kaydedildiğini ve ilk hane sayaç, son üç hane değerdir, sonra tamı yeniden yapılandırabiliriz 255,255,255,255,255,215,215,235,100,000,000,000.

Öte yandan, kayıplı sıkıştırma , kayıpsız olandan daha fazla sıkıştırmaya çalışır. Bunu yapmak için, kayıplı kodekler genellikle algımızın almadığı şeyleri kaldırmaya çalışırlar. Örneğin, al YUV( YCbCrgerçekten) modeli JPEG (ve hemen hemen her video codec) kullanır: Y = Luminance, Cb = Chrominance Blue, Cr = Chrominance Red. Bir insan 4:2:0(her pikselin bir parlaklık değeri vardır, ancak renkler alternatif olarak 2x2'lik bloklar halinde kaydedilir) ve bir 4:4:4(her pikselin parlaklık ve her iki renk kanalına sahip) kodlu resim arasındaki farkı çözemez. Bu gözümüzün fizyolojisine bağlıdır : Renkteki farklılıkları göremeyiz, aynı zamanda parlaklıktaki farklılıkları görebiliriz.

Bu, çoğu zaman iyi çalışır, ancak bir MP3 dosyasıyla karşılaştırın: Neredeyse hiç kimse 192kbps ve 320kbps arasında fark yaratamaz, ancak 64kbps'nin altına iner ve işler çok çabuk çirkinleşir. Aynı zamanda, yeniden kodlama, istenmeyen eserler ortaya çıkabileceği için kaliteyi daha da düşürecektir (örneğin JPEG'de, yüksek kalitede kodlamalardan küçük bloklar, daha sonraki kodlamalarda resmin detayları olarak kabul edilecektir).

Alt çizgi

Görüntü formatlarını veya özelliklerini önemsemiyorsanız, ikisi de iyi olacak. Yeterince yüksek kaliteli ayarlarla, bunlar arasında bile bir fark görmeyeceğiniz mümkündür ve beklenir.

Bununla birlikte, belirli bir özelliğe ihtiyacınız varsa, bunu kapsayan bir kodek olabilir (ve neredeyse kesinlikle: olacaktır).

Çekirdekte ise, fotoğraflar yalnızca 3 kanal piksel değerindedir [0, 255] X RBG

Bu ciddi bir şekilde kırılmış bir varsayımdır ve sorunuzun geri kalanı, ondan ayrılmadan yanıtlanamaz.

Yani, RAW'ı TIFF'den farklı kılan şey, bunların tümü 0-255 arasındaki değerlerle sınırlı değil midir?

"Ham" terimi iki farklı şeye, bir "kamera raw" görüntüsüne veya başlık içermeyen raw görüntü verilerini içeren bir dosyaya atıfta bulunabilir.

Bir "camera raw" görüntüsü, ham verileri sensörden çıktığı gibi saklar. Modern kamera sensörlerinin çoğu, 8 bitten daha fazla ADC'ye sahiptir, ancak aynı zamanda her bir konumdaki yalnızca bir renk bileşeni için yoğunluk verileri toplarlar. Geometri mercek tarafından bozulabilir, ADC'den gelen yoğunluk değerleri, bir insanın yoğunluk algısını yansıtmakta iyi bir iş çıkarmayabilir, renk bileşenleri tam olarak monitörünüz tarafından kullanılanlara eşlenmeyebilir.

Ham sensör verilerini kaliteli bir RGB görüntüye dönüştürmek için enterpolasyon içeren karmaşık bir haritalama işlemi gereklidir ve bunu yapmanın tek bir doğru yolu yoktur. Ayrıca, renk bileşenlerinin enterpolasyon yapması gereği nedeniyle, RGB görüntüsü ham verilerden daha büyük olabilir.

Dönüştürme kamerada yapılabilir (ve çoğu zaman yapılır), ancak çoğu fotoğrafçı ham verileri kaydetmeyi tercih eder, böylece işlemden sonra işlemlerin ince ayar yapması sağlanır.

Tiff, görüntüleri çok çeşitli meta verilerle çok çeşitli formatlarda saklayabilen karmaşık bir dosya formatıdır. Uygulamada genellikle sıkıştırılmamış veya kayıpsız sıkıştırılmış RGB veya CMYK görüntüleri depolamak için kullanılır.

Başlıkları olmayan ham görüntü verileri içeren dosyalar nadiren kullanılır, çünkü okumadan önce biçimlerini ve boyutlarını bilmeniz gerekir. Bazı görüntü işleme araçları olsa da onları destekliyor.

Ayrıca, sayısal bir bakış açısından, 32 bit görüntülerden farklı bir 16 bit görüntü gibi bir şey yapan şey nedir?

Ne yazık ki "n bit" iki farklı anlama gelebilir. Bu, tüm renk bileşenlerinin bir bit sayısına (örneğin kırmızı için 5 bit, mavi için 5 bit ve 16 bit veya 6 bit kırmızı, 8 bit yeşil, 8 bit mavi ve 8 bit için 6 bit) sıkıştırılması anlamına gelebilir. 32 bit için alfa) veya at; her bir renk bileşeninin, her piksel konumundaki n bilgi bitine sahip olduğu anlamına gelebilir.

Bu perspektife devam ederek, bir bilgisayarın dosya sistemindeki bir görüntünün 0 - 255 arasındaki sadece 3 kanallı bir tamsayı dizisi olduğu söylenebilir.

Yine bu bakış açısı sadece düz yanlıştır.

Bir dosya bir bayt dizisidir, ancak bu baytlar neredeyse hiçbir zaman "yalnızca 0 - 255 arasındaki 3 kanallı bir tam sayı dizisi" değildir.

Böyle bir görüntü saklayabilirsiniz. Bazı araçlar bile bu tür dosyaların okunmasını ve yazılmasını destekler ancak sorun, okumadan önce dosyayı bilmeniz gerektiği anlamına gelir. 3000 bayt boyutunda bir dosya olduğunu varsayalım, 1000 24 bit RGB pikseliniz var mı? 3000 8 bit gri tonlamalı pikseller? Bir paletten 3000 8 bit piksel? Renk bileşenleri hangi sıradadır? görüntü ne şeklidir? Renk bileşenleri RGB veya BGR sırasına göre mi? Bu soruların cevaplarını bilmiyorsanız, böyle bir dosyayı anlamlı bir şekilde okuyamazsınız.

Bu nedenle pratik görüntü formatları tipik olarak, dosyanın türünü, görüntünün boyutlarını ve gerçek görüntü verilerinin nasıl depolandığını tanımlayan bir veya daha fazla başlık ile başlar. İsteğe bağlı meta veri de içerebilirler.

Bir görüntüyü örneğin JPG gibi kayıp bir formatta sıkıştırmanın amacı nedir? Sıkıştırma algosunun bazı piksel değerlerini 254'ten 255'e ya da her neyse değiştirdiğini söyleyin. Yani? Bu, dosya boyutunda herhangi bir tasarruf sağlar veya görsel kaliteyi nasıl etkiler?

Sıkıştırma algoritmaları yalnızca "değerleri değiştirmez", bilgileri tamamen farklı bir şekilde kodlarlar, örneğin JPEG kabaca

• Verileri RGB'den YUV'ye dönüştürün
• (isteğe bağlı olarak) bir veya her iki boyutta da kroma kanallarının kararlılığını 2 katına kadar azaltır.
• Her kanalın verilerini 8x8 bloğa bölün.
• Kesikli bir kosinüs dönüşümü kullanarak blokları frekans alanına dönüştürün
• Yüksek frekans bilgisinin kesinliğini azaltırken düşük frekans bilgisini koruyarak sonuçları ölçün.
• Elde edilen sayıları değişken uzunluklu bir kodlama şeması (bayram kodlaması veya aritmetik kodlama) kullanarak bir bayt dizisi olarak kodlayın
• Bu baytları uygun başlıklar ile birlikte dosyaya kaydedin.

Diğer taraftan kayıpsız şekilde sıkıştırılmış formatlar genellikle genel amaçlı veri sıkıştırma algoritması üzerine kurulur, ancak bazen PNG'ye benzeyen görüntüye özgü ön işleme ile takviye eder.

• Verileri desteklenen formatlardan birine dönüştürün (örneğin, sırasıyla Kırmızı, yeşil ve mavi için bir bit)
• Görüntünün her satırı için bir "filtreleme" işlemi gerçekleştirin, genel filtreleme seçenekleri vardır (hiç filtreleme dahil değil), ancak genel amaç, bir pikselin komşuları ile benzer olması muhtemel olduğu görüntüye özgü bilgileri almaktır. “deflate” ile başa çıkabilecek şekilde.
• "Söndür" genel amaçlı sıkıştırma algoritmasını kullanarak filtrelenmiş verileri sıkıştırın.
• Bu baytları uygun başlıklar ile birlikte dosyaya kaydedin.

Bu varsayımın yanlış olmasının birkaç nedeni var ve hepsi bir şeye iniyor:

Hangi ölçeği kullanıyorsunuz?

Ve bu biraz daha bozulabilir:

255 nedir?

"Renk" fiziksel evrenin bir özelliği değildir. Akılda ortaya çıkan bir sansasyondur. Ve buna "mavi", "yeşil" ve "kırmızı" gibi şeyler de dahildir. "Hiç mavi yok" anlamına gelen 0'dan "mavi" anlamına gelen 255 Aslında 255'in mavinin platonik idealini temsil etmesi mümkün değil , çünkü ... gerçek dünyada böyle mükemmel bir şey yok. Yani, bu demek oluyor ki:

• önünüzdeki cihazda yapabileceğiniz en mavi şey nedir?
• İnsan ekran sistemi ve yazıcı / mürekkep / kağıt kombinasyonlarının çoğu onu temsil edemiyor olsa bile, insan görüş sistemi açısından saf maviye en yakın ideal eşleşmeye ne kadar yakın?
• çok çeşitli cihazlarda makul olarak temsil edilebilecek oldukça iyi bir mavi?
• İnsan vizyonunun dışında kalan ancak RGB üçlü'nün menzildeki çoğu rengi kaplamasına izin veren mavi?

Sesi kesildi mi? Hayır! Bunlar aslında gerçek örneklerdir. Her seçimin bu gösterimlerini inceleyin. Kavisli alan, insan görme renk uzayının 2B dilimidir ve üçgen, kırmızı, yeşil veya mavi için belirli bir seçenek verildiğinde temsil edilebilecek alanı gösterir.

İlk olarak, işte mevcut orta sınıf cihazların oldukça temsilcisi olan dizüstü bilgisayar ekranımın profili:

Şimdi, işte Adobe RGB alanı. Bunun ekranımın gösterebileceğinden daha büyük olduğuna dikkat edin!

Yani, işte burada sRGB - standart olmayan ve varsayılan alan genellikle hiçbir şey belirtilmediğinde varsayılan alandır. Çoğu durumda "yeterince iyi" olması gerekiyordu.

Ve son olarak, üçgeni insan görüşünün neredeyse tümüne uyacak kadar büyük yapmak için hayali renkleri temel olarak kullanan ProPhoto RGB .

Şimdi ışığın rengini ve kromatik adaptasyonu - insan vizyon sisteminin çevreyi algılamayı ayarlama yeteneği ile atın . Aslında, sadece yetenek değil: ister istesen de istemesen olur . "Saf mavi", bu şeyin akkor ışığında olabileceği kadar mavi göründüğü anlamına mı geliyor ? Güneş ışığında fotoğraf çekersek, değer ne olmalı?

Yani "255" çok farklı anlamlara gelebilir.

0 nedir?

Bu oldukça basittir - 0 olması için ne kadar siyah gerekir? Öyle mi vantablack siyah? Öyleyse, sahnenizdeki tüm gerçek gölgeler çok daha az uçsa , sahnenizde olmayan ve hangi renk gibi, dinamik bir aralık için bir grup potansiyel değeri "israf etmek" istiyorsunuz? erişiminiz olan herhangi bir cihaz veya yazıcı tarafından temsil edilmiyor mu?

Eğriniz nedir?

Öyleyse, son noktalarına ulaştığında, birinden diğerine nasıl geçersin? İnsanın parlaklık algısı kesinlikle doğrusal değildir . 0-255 ölçeğinizde 100, 50'den iki kat daha parlak mı yoksa daha büyük bir faktör mü olmalı? Mesela 3 ile 4 arasındaki algısal fark, 203 ile 204 arasındakiyle aynı mı olmalı?

Bir günlük depolama sistemi kullanmaya karar verirseniz, bu eğri insan vizyonuyla eşleşecek şekilde mi, veri optimizasyonu için mi yoksa başka bir şey için mi optimize edilmelidir?

Birçok farklı ihtiyaç için birçok olasılık var.

Sıkıştırma üzerinde

Sen sor.

Sıkıştırma algosunun bazı piksel değerlerini 254'ten 255'e ya da her neyse değiştirdiğini söyleyin. Yani? Bu, dosya boyutunda herhangi bir tasarruf sağlar veya görsel kaliteyi nasıl etkiler?

Modern sıkıştırma algoritmaları bundan daha karmaşık, ancak bu iyi bir örnek teşkil ediyor. FF255'i temsil etmek ve 254'ü temsil etmek için onaltılık kullanacağım FEve çalışma uzunluğu kodlamasını bir sıkıştırma biçimi olarak kullandığımızı hayal ediyorum . Basitlik için, renk yerine siyah ve beyazı varsayalım. Bununla, şuna benzeyen bir veri satırımız varsa:

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 

bunu çok basit bir şekilde sıkıştırabiliriz

16×FF 

... ki bu oldukça açık bir tasarruf. Temel olarak 16 baytı ikiye kaydedebiliriz (biri sayı için, diğeri veri için). Ama şunu söyleyelim:

FF FF FE FF FE FF FF FF FF FF FE FE FE FF FE FE

Şimdi, çalışma uzunluğu kodlaması bize verir:

2×FF 1×FE 1×FF 1×FE 5×FF 3×FE 1×FF 2×FE

... ki bu hiç tasarruf etmiyor ve aslında dosya boyutunu da arttırabilirdi . Ancak, tüm FEdeğerleri FFyuvarlarsak, küçük boyutta ancak dosya kalitesi üzerinde bir etkisi olduğunu fark etmek zor, büyük boyut küçültme ile ilk vakaya geri dönüyoruz.

Tabii ki önemsiz, tartışmalı bir örnek, ancak tüm kayıplı sıkıştırma algoritmaları bu temel özelliği paylaşıyor: veri kaybı, umarım çok fazla algılanan bir değişiklik olmadan daha kompakt bir depolama formatı kullanmayı kolaylaştırır .

Biraz derinlikte

Ayrıca, sayısal bir açıdan, 32 bit görüntülerden farklı bir 16 bit görüntü gibi bir şey yapan şey nedir? Yine, bir görüntü sadece 0-255 arasında tamsayı değerleri olan bir dizidir.

Yani ..... 0-255 arasındaki bir tamsayı değerleri dizisi sekiz bitlik bir dizidir. (2⁸ = 256.) Üç kanallı, bu 24 bitlik bir görüntüdür; bazı biçimlerde 32 bit için saydamlık ("alfa") kanalı da vardır. Kanal başına daha yüksek bir değer de kullanılabilir, bu genellikle "16 bit derinlik" derken kastettiğimiz şeydir. Bu, dizinin 0-255 yerine 0-65535'ten (2¹⁶ = 65536) geçtiği anlamına gelir. Genelde böyle bir düzende, bu temelde sadece en yüksek değerin her ölçekte aynı şeyi temsil ettiği bir çarpandır, fakat daha yüksek bit derinliği daha fazla nüans verir. ( Bununla ilgili daha fazla bilgi için bu cevaba bakınız .) Değerler için tamsayılar yerine 64-bit float (!) Veya kullanım durumuna bağlı olarak diğer veri türleri kullanan bazı özel dosya formatları da var, fakat temel kavram aynı .

Hayır, görüntü yalnızca 0-255 aralığındaki RGB değerleri değildir. Depolama formatlarını görmezden gelseniz bile, rengi tanımlamanın birçok yolu vardır. İşte bazı örnekler:

• Kırmızı, yeşil ve mavi bileşenler (RGB)
• Mavi, kırmızı, sarı ve siyah bileşenler (CMYK)
• Ton, doygunluk ve açıklık / değer (HSL / HSV)
• Bir kameradaki bir grup sensöre çarpan ışık miktarı
• Sensörlere çarptığında ışık miktarı ve yönü (bir ışık alanı kamerasında )

İlk ikisi sırasıyla monitörlerde görüntülemek ve yazdırmak için en sık kullanılanlardır.

Ek olarak, bir görüntü yalnızca pikseller değil, aynı zamanda meta verilerdir. Piksel sayısındaki genişlik, yazdırmanız durumunda fiziksel genişlik, küçük resim veya hatta fotoğraf çekildiğinde kameranın coğrafi konumu gibi şeyler olabilir .

Öncülünüz yanlış değil: herhangi bir görüntü, N boyutlu bir sonlu değer dizisi kullanılarak gösterilebilir. Şahsen ben bir matris yerine ayrık geometri kullanmanın genelliğini açıklarım, ancak özü aynıdır. Ama içerik bu, dosya değil.

Ancak, dosya formatları farklıdır. Temel olarak, söz konusu kişiler gibi aynı görüntüyü temsil etmenin birkaç farklı yolu vardır: bmp, png, jpg, vs. Tabii ki, onları çözdükten sonra, aynı görüntünün iki kayıpsız kodlanmış sürümü aynı matrislere yol açacaktır.
Zip ile sıkıştırdığınız bir .txt dosyası olarak düşünün. Kayıpsız bir kodlamanın, metnin aynısı olmayan, ancak gerçekten yakın, metnin salakça bir sürümü gibi olan bir metni döndürmesi garipliği ile.

Metin benzetmesi ile kalıyorum, diyelim ki, aynı metin .txt, .docx, .pdf, vb. Olarak kaydedilmiş. Diyelim ki içerik aynıysa neden tüm dosyalar tamamen aynı değil? (Tamam, txt’in formatlaması yok, ancak diğerleri var).

Nasıl Bu arada, kontrol Netpbm kodlama gerçekten farklıdır JPEG .

RAW ve TIFF formatları için söyleyebileceğim kadarıyla, cevap (diğerleri dediği gibi) aslında her zaman aynı renk alanlarını kullanmamalarıdır (örneğin, RAW dosyaları piksel başına daha fazla bit kullanabilir, böylece daha ince renk bilgileri depolayabilir) .

Ancak, sorunuzun temeline ulaşmak için - bazen farklı biçimlerde depolanan görüntüler vardır, ancak sonuçta her biri tam olarak aynı sayı dizisini temsil eder.

Bunun bir nedeni, PNG dosyası ile TIFF dosyası arasındaki sıkıştırma farklarıdır.

PNG dosyaları belirli bir sıkıştırma algoritması kullanır. Bu, bir görüntünün sadece her piksel için büyük bir sayı listesi olarak kaydedilmeyeceği anlamına gelir. Basitleştirilmiş örnek: "bu 10x10 piksel bloğunda, tüm pikseller renkli XYZ" yazan bir şey depolayabilir. Daha sonra, bu bilgileri 100 kez üst üste depolamak yerine, bir kez depolar, artı bilgilerin uygulandığı bölge hakkında bir miktar bilgi saklar.

Sorun, orijinal sayı dizisini (renkleri temsil eden) geri almaktır, böylece onu gösterebilir veya düzenleyebilir ya da her neyse, bu sıkıştırılmış bilgiyi nasıl yorumlayacağını bilen bir yazılıma ihtiyacınız var.

PNG dosyaları her zaman aynı sıkıştırma algoritmasını kullanır, bu nedenle yazılımın tüm geçerli PNG dosyalarını desteklemesi kolaydır. Öte yandan, bazı görüntüler PNG'nin sıkıştırma algoritmasına kendini ödünç vermeyen bir yapıya sahiptir, bu nedenle PNG dosyalarınızın bazıları oldukça büyük olabilir.

Diğer yandan, TIFF dosyaları birçok farklı sıkıştırma algoritmasını destekler. Aslında, görüntünün farklı kısımlarını farklı sıkıştırılmış olarak bile depolayabilir. VE 'uzantıları' destekler, böylece görüntüleri özel yöntemler kullanarak sıkıştırabilirsiniz. Bu yüzden belki de resminizin üst yarısı PNG'ye benzer bir yöntem kullanılarak sıkıştırılır, ancak bu alt yarıyı çok iyi sıkıştırmaz, bu nedenle alt yarı farklı bir yöntemle sıkıştırılır.

Bu nedenle TIFF dosyaları daha esnektir - daha az bayt kullanarak tam olarak aynı sayı dizisini saklayabilirsiniz. Ancak görüntünün kodunu çözmek için gereken yazılım daha karmaşık olacaktır ve attığınız her TIFF dosyasıyla tutarlı bir şekilde çalışmayabilir, örneğin bir TIFF dosyasını tek bir yazılıma kaydedebilir ve farklı bir yazılım kullanarak açamıyor olabilirsiniz. hala orijinalinde çalışıyor.

Sen sor

Ancak 3 kanallı temel bir RBC görüntüsünden başka bir şey sormuyorum. Tek bildiğim, eğer biri bana bunlardan birini verirse, şimdi bir dizi numaram var. Bir sayı dizisinin neden 0 - 255 arasındaki bazı diğer sayı dizilerinden farklı olabileceğini bilmek için hiçbir nedenim yok.

Bunu size verebilmek için birisinin görüntünün nasıl kaydedildiğini ve sayının bir diziye nasıl çevrileceğini bilmesi gerekiyordu. (Ya da muhtemelen bazı yazılımlar sizin için habersizce bu çeviriyi yapıyordur).

Bir görüntüyü PNG olarak ve tekrar TIFF veya GIF olarak kaydetmeyi deneyebilir ve her birinin aynı sayı dizisini farklı şekilde nasıl temsil ettiğini görmek için onaltılık bir görüntüleyicide bakabilirsiniz . Veya, PNG dosyalarının ve TIFF dosyalarının dahili olarak nasıl temsil edildiğinin ayrıntılarını okuyun, aynı sayıdaki farklı dizileri okumak için neyin yerleşik olması gerektiği hakkında bir fikir vermek için.

Bitmapler

Bir bitmap (BMP) temel olarak tanımladığınız şeydir, piksel renklerini temsil eden bir sayı dizisidir. Örneğin bir şey

1, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1

Kayıpsız sıkıştırma

Şimdi bir sıkıştırma şeması tanımlayalım. Sıkıştırma düzenimizde, bir çift sayımız olacaktır. Örneğin

3, 1, 1, 0, 7, 1

Şimdi, belirtmek istediğim ilk şey, bu sıkıştırma düzeninin ilk diziyle aynı pikselleri temsil etmesidir. İlk dizide üç 1, ardından tek bir 0 ve ardından yedi 1. Ve burada temsil ettiğimiz şey bu. İki formatlı çoklu pikselleri temsil ettiği için bu format daha kısadır. Bitmap formatı, her piksel için bir sayı kullanmak zorundadır.

Açıkçası bu, bir görüntünün (örneğin sadece bir satır) ve bir sıkıştırma şemasının basitleştirilmiş bir görüntüsüdür. Ancak umarım bu, sıkıştırma düzeninin görüntünün biçimini nasıl değiştirdiğini görmenize olanak sağlar. Bir GIF'in BMP ile olan ilişkisi budur. GIF , bu basit yerine Lempel-Ziv-Welch adlı bir sıkıştırma şeması kullanıyor .

Burada tarif ettiğimiz kayıpsız bir sıkıştırma şemasıdır. Kayıpsız sıkıştırma şemalarındaki bir problem, bazı girdiler için kodlanmış formun orijinalden daha uzun olabileceğidir. Örneğin

1, 0, 1, 0, 1

Kodlama

1, 1, 1, 0, 1, 1, 1, 0, 1, 1

Eh, bu işe yaramazdı. Girişi iki kat daha uzun yaptık.

Başka bir kayıpsız sıkıştırma

Şimdi, farklı bir sıkıştırma şeması düşünelim. Bu resimde, görüntüyü bindirme daireler olarak göstereceğiz. Her daire için bir merkez, bir yarıçap ve bir renk tanımlayacağız.

İlk bitmapimiz olur

5, 5, 1, 3, 0, 0

Bu bizim ilk sıkıştırma yöntemimizle aynı uzunluktadır.

Ve bizim ikinci olabilir

2, 2, 1, 2, 1, 0, 2, 0, 1

Bu, orta öğede ortalanmış üç dairedir (bilgisayar sayısında 2, bilgisayarlarda 0 saymaya başlar). Bir dairenin yarıçapı 2 ve renk 1'i vardır. Sonra, renk 0 ve yarıçapı 1 olan bir daireyi ekleriz. Sonunda, renk 1 ve yarıçapı 0 olan bir daireye sahibiz.

1, 1, 1, 1, 1
1, 0, 0, 0, 0, 1
1, 0, 1, 0, 1

Veya

2, 2, 1, 1, 0, 0, 3, 0, 0

Bu aynı başlangıç ​​çemberidir ancak iki nokta çemberi ile kaplıdır. Adımlar, olur

1, 1, 1, 1, 1
1, 0, 1, 1, 1
1, 0, 1, 0, 1

Her ikisi de ilk kodlanmış versiyondan daha kısa fakat orijinal versiyondan daha uzun.

Neden çevrelerden bahsettiğimi ve aralıklardan bahsetmediğimi merak edebilirsiniz. Asıl sebep, çemberlerin gerçek iki boyutlu görüntülerin kullandıklarına daha yakın olmalarıdır.

Kayıplı sıkıştırma

Ayrıca kayıplı sıkıştırma şemaları konseptine sahibiz. Bu kayıpsız sıkıştırma şemaları orijinal bitmap dizisine geri döndürülebilir. Kayıplı sıkıştırma düzenleri geri dönüşümlü olmayabilir.

Çevreler yöntemimizin kayıplı bir versiyonunu düşünelim. Bu konuda basit bir kural kullanacağız. Yarıçapı 1'den küçük olan daireleri saklamayız. Yani son iki kodlamada bunun yerine

2, 2, 1, 2, 1, 0

ve

2, 2, 1

yine piksellere dönüştürülen

1, 0, 0, 0, 1

ve

1, 1, 1, 1, 1

İlk versiyon orijinalden daha uzun sadece bir element. İkinci versiyon daha kısa. Her ikisi de geçerlidir, bu yüzden algoritma her ikisini de geliştirmekte ve daha kısa olanı seçmekte özgürdür.

Daha kısıtlayıcı kuralları olan görüntüleri daha düşük kalitede olarak tanımlarız.

Görüntülerin üst üste bindirilmiş dairesel şekil koleksiyonları olarak gösterilmesi, Ortak Fotoğraf Uzmanları Grubu veya JPEG formatının çalışma biçimine benzer . Şekilleri dairelerden ziyade elipslerdir, ancak fikir benzerdir. Basit yöntemimizden çok, görüntüleri kodlamak için ayrık kosinüs dönüşümünü kullanıyor .

GIF’in aksine JPEG aslında görüntüyü temsil etmenin farklı bir yoludur. GIF hala pikseldir. Sadece farklı bir şekilde depolanırlar. JPEG şekiller. Bir JPEG görüntülemek için, şekilleri piksellere dönüştürürüz, çünkü ekranlar bu şekilde çalışır. Teoride, bu şekilde çalışmayan bir ekran geliştirebiliriz. Piksel yerine, JPEG formatına daha iyi uyması için şekiller oluşturabilir. Tabii ki, bu ekran bitmap'leri gösteremezdi. Bir BMP veya GIF görüntülemek için JPEG’e dönüştürmemiz gerekir.

Standart bir GIF dönüştürürseniz, 300x300 piksel söylerseniz, JPEG formatına dönüştürürseniz ve kaliteyi düşürürseniz, kullandığı temel şekiller görünür olmalıdır. Çoğu JPEG, daha yüksek çözünürlüklü bir görüntüyle başlayarak bu yapıtları önler.

JPEG'ler iyi ölçeklenir, çünkü piksel yerine şekillerdir. Bu nedenle, 8000x8000 görüntüyle başlarsanız, JPEG'e dönüştürün ve 300x300 görüntü olarak görüntüleyin, kaybedilen ayrıntıların çoğu yine de kaybedilir. 8000x8000 bitmap'i önce 300x300 bitmap'e, ardından JPEG'e dönüştürdüyseniz, sonuçlar genellikle daha düşük kalitede olur.

MPEG

Hareketsiz görüntülerden bahsediyoruz. Moving Picture Experts Group veya MPEG formatında JPEG olarak sıkıştırma aynı tür kullanır, ama aynı zamanda başka bir şey yapar. Video yapmanın basit bir yolu, bir dizi durağan görüntü göndermek olsa da, MPEG aslında bir kare gönderir, ardından bazı kareler, değişiklikleri listeleyen ve bir son kare ile sonlandırır. Çoğu kare önceki kareye benzer olduğundan, değişikliklerin listesi genellikle ikinci bir görüntününkinden daha küçüktür.

Sıra normalde o kadar uzun değil, beş kare diyelim. Ancak, akışın olması gerekenden daha küçük olmasına yardımcı olur.

basitleştirmeler

Çok fazla görmezden geldim. Resimlerim yalnızca iki renge (1 bit) sahip, 8 bitlik görüntünün 256'sı değil ve kesinlikle 32 bitlik bir görüntünün 4,294,967,296'sı değil. 8 bit görüntülerde bile, görüntü için genellikle farklı paletler seçebileceğinizi unutmayın. Dolayısıyla, aynı sekanslara sahip iki adet 8 bit bitmap, farklı görünen (aynı şekil ancak farklı renkler) görünen görüntüleri temsil edebilir.

Resimlerim tek boyutlu, iki boyutlu değil. Çoğu görüntü, dizileri iki boyutlu hale getiren belirli bir satır boyutuna sahip olacaktır.

Gerçek kodlamaları hiç temsil etmeyi denemedim. Kullandığım basit olanlardan çok daha karmaşıklar. Bunu yaptım çünkü bu yazıdaki kodlamaları tanımlamak istedim. Tek bir cevapla Lempel-Ziv'i daha karmaşık Lempel-Ziv-Welch iyileştirmesini daha az açıklayabileceğime ikna olmadım. Ve Fourier'in onları herhangi bir uzunlukta açıklamak için yeterince iyi dönüşümler yaptığını da anlamıyorum.

Bu, gerçek görüntü işlemenin basitleştirilmiş bir sürümüdür. Ancak, didaktik amaçlar için, hala önemli noktalara vararak daha karmaşık gerçeklikten daha kolay anlaşıldığını hissediyorum.

Diyelim ki her pikselin 0-255 aralığında her biri sadece üç sayı (kırmızı, yeşil ve mavi) idi. Diğer cevaplayıcılar bu varsayımla (doğru) zorlayarak başlamıştır, ancak basitlik için bunun doğru olduğunu söyleyelim.

Dilbilim ders kitabındaki bir karikatürü hatırlıyorum (ne yazık ki çevrimiçi bulamıyorum): iki eski Mısır taş oymacısı, çok sayıda yürüyen figürün oyduğu devasa bir duvarın dibinde çok yorgun duruyor. Biri diğerine şöyle diyor: "Elbette," Firavunun 100.000 askeri var mıydı? "Yazmanın daha kolay bir yolu olmalı." Bu fikri aklında tut.

Şimdi, resminizin ilk satırında 1800 siyah piksel bulunduğunu varsayalım. Bu nasıl temsil edilir?

0 0 0    0 0 0     0 0 0   ....

Peki bu ne kadar depolama alanı gerektirir? Her değer bir bayttır. Piksel başına üç bayt, satırda 1800 piksel, yani zaten satır başına 5400 bayt. Bu nedenle, 1800 x 1200 boyutunda bir görüntünün 1200 kat daha fazla çekim yapması gerekir ki bu 6 megabayttan fazladır. Öyleyse şimdi gidip bir Google resim araması yapalım ve 1800x1200 resimden oluşan birkaç resim indirebiliriz. Bir .pngresim ve bir .jpgresim diyelim . Dosya boyutuna bakın: 6 MB mı? Olmaz, genellikle bundan daha küçüktür. Ve elbette, arzu edilen bir şey, elbette, bu alandan tasarruf ve daha kısa indirme süresi ...

Yani, ne oluyor? Önemli olan, saklayacak çok sayıda numaraya sahip olsanız bile, temsil etmenin farklı yolları vardır.dosyadaki bu numaralar. İki paragraf önce, cevabımda burada daha etkili bir temsil örneği var. "1800 siyah piksel" kelimesini yazdım. Bu 17 karakterdir ve bu yüzden 17 bayttan daha fazla sürmesi gerekmez, yine de 5400 bayta ihtiyacımız olduğunu düşündüğümüz bilgilerin aynısını mükemmel bir şekilde açıklar. Ve eğer bu bilgiyi kodlamak için İngilizce dilini kullanmadıysanız, ama daha özel bir dil kullandıysanız, kesinlikle 17 bayttan daha iyisini yapabilir (ve kodlama / kod çözme uygulamasında çok fazla çaba harcayabilirsiniz). Şimdi, şimdiden, birden fazla resim sıkıştırma formatı gönderdik: İngilizce kelimeler kullanan ve biri bundan daha etkili. Bunun nereye gittiğini gördün mü?

Tamam, yani, bir sürü komşu piksel aynı renge sahipse işe yarar. Ama ya yapmazlarsa? Tabii ki, görüntünün içeriğine bağlı: ne kadar fazlalık varsa, bilgiyi sıkıştırmak o kadar kolay olur . Artıklık, başka bölümleri zaten biliyorsanız, görüntünün bölümlerinin oldukça iyi tahmin edilebileceği anlamına gelir. Sıkıştırma, yalnızca bilgiyi yeniden oluşturmak için gerekli olan minimum notu yazmak anlamına gelir. Mümkün olan her görüntünün fazlalığı yoktur, ancak benim saf siyah örneğimden daha karmaşık olmasına rağmen insan gözü ve beyni için anlamı olan herhangi bir gerçek görüntünün hala çok fazla fazlalığa sahip olma eğilimi vardır. Ve birçok farklı sıkıştırma yöntemi vardır. Bazı sıkıştırma yöntemleri kayıpsızyani, siyah renkli satır örneğimde olduğu gibi bilgilerin orijinalle matematiksel olarak aynı olması için yeniden yapılandırılabileceği anlamına gelir. Çoğu .pngdosya kayıpsız bir sıkıştırma yöntemi kullanır. Bazı yöntemler kaybedilir : rekonstrüksiyon mükemmel değildir, ancak hatalar insan gözü ve beynin onları çok az göreceği şekilde gizlenir. Çoğu .jpgdosya kayıp.

Karmaşık artıklık kalıplarını nasıl tanıdığınız ve bunların verimli sıkıştırılmış açıklamalarını nasıl yazdığınızın detayları oldukça matematikseldir ve önemsizdir, bu yüzden farklı sıkıştırma stratejilerine karşılık gelen çok farklı biçimlerde yer vardır. Ama umarım prensibi alırsın.

Yukarıdaki birkaç yorumcu, yanlış anlamanızın ortaya çıkabileceği yerler hakkında makul tahminlerde bulunmuştur. Sorunuzda, sıkıştırmanın sadece piksel değerlerini biraz değiştirdiğini düşünüyoruz (ve kesinlikle, kayıplı sıkıştırma yöntemleri bunu yerlerde yapıyor, ancak bilgi düzenini değiştirmeden yalnızca istenmeyen bir yan etki olarak). Dosyayı açtığınızda ve görüntü içeriğine baktığınızda (örneğin, Matlab'da bir sayı dizisi olarak veya Photoshop'ta ekranda görüntü olarak) sıkıştırılmış dosya içeriğine bakmıyorsunuz, bunun yerine yeniden yapılanmaya bakıyorsunuz.orijinaliyle aynı mizanpaja sahip olan (mizanpajı doğru bir şekilde yeniden oluşturmadıysanız yeniden yapılanma pek olmazdı). Dosya açma prosedürü, dosyadaki bilgiyi bellekteki tam bir sıkıştırılmamış gösterime indirgemiştir. Sıkıştırılmamış iki rekonstrüksiyonu karşılaştırırsanız , gerçekten de geldikleri iki farklı resim formatını ayırt edecek bir şey yoktur (varsa rekonstrüksiyon hataları hariç).

Evet, ama bu 1'lere ve 0'lara nasıl ulaştığınız çok farklı.

Bir örnek vereceğim, ancak bu sahte ve doğru olmaktan fazlasını göstermesi gerekiyor. Tüm dijital görüntülerin bir seviyede ikili olarak temsil edildiğini unutmayın.

Meseleleri karmaşıklaştırmak için farklı kanallar var. CMYK, RGB, B&W, sadece bir kaç isim. Buna girmeyeceğiz. Çekim, depolama ve görüntüleme gibi farklı aşamalar da vardır. Yine, örneğin doğru olmadığını göstermesi gerekiyorsa da buna gireceğiz. Doğru örnekler istiyorsanız, bir ton teknik belgeye bakmanız gerekecektir.

Bu yüzden örneklemimizde siyah beyaz bir resme bakacağız.

00067000
00067000
00567800
04056090
40056009

Sayılar "Siyah" ın ne kadar güçlü olduğunu gösterir. Kameranın görüntüyü bu şekilde yakalaması. İyi bir kamera, bu yüzden görüntüyü de saklıyor.

Şimdi görüntüyü bir bilgisayarda saklıyor, ancak çok fazla yer kaplıyor, bu yüzden sıkıştıracağız. Bunu karıştırmanın yanı sıra, çoğu insanın 1 siyah seviyesi farkını tespit edemediğini de biliyoruz, bu yüzden bazılarını düzelteceğiz.

302730
302730
204820
*04056090
1420262019

Şimdi görüntüyü diskte saklıyoruz. Daha az yer kaplar ve orijinal görüntünün çoğunu oluşturmamızı sağlar.

Şimdi bir yazıcıya yazdırmak istediğimizi varsayalım. Yazıcı yalnızca bir düzeyde siyah yazdırıyor, böylece bir bilgisayar depolanmış, sıkıştırılmış görüntüyü yazıcı konuşmasına çevirir.

00011000
00011000
00111100
01011010
10011001

Bu, makul görünen bir görüntü çıktısını alır, ancak örnekte çok fazla bir kalite eksikliği olduğunu bile görebilirsiniz. Ama hey bu yazıcının hatası.

Son olarak, görüntüyü 10 siyah düzeydeki iyi bir yazıcıya yazdırın. Kameran ile aynı. Böylece depolanmış ve sıkıştırılmış görüntü kullanılır.

00077000
00077000
00888800
04056090
40066009

Gördüğünüz gibi görüntünün "daha iyi" olduğu, ancak orjinalinden biraz değişti.

Herhangi bir zamanda, sizin sadece bir kanalın gücünün doğru olduğu gerçeği doğru. Öte yandan, sıkıştırılmış imge, ki yine de dekomprese edilmeli, buna oldukça sadık kalır.

Ancak, sıkıştırılmış format çok fazla "bilgi" kaybeder. Bu bilgi önemli mi? Bu, sanatçıya ve izleyiciye kalmış. Yerden kazanma, işlem süresi, son / kaydedilen görüntünün kalitesi ve ihtiyaç arasında birkaç takas vardır. Belgelerimin çoğunu tek renkli siyah olarak tarıyorum, çünkü tek ihtiyacım olan bu. Ancak, düğün fotoğraflarım BÜYÜK HAM formatındadır çünkü ne zaman harika bir şekilde tekrar baskı yapmak isteyeceğimi bilemiyorum. Bununla birlikte, onları (fotoğraflar) dijital bir resim çerçevesine aktardığımda, yer kazanmak için onları JPEG'e dönüştürüyorum. Farklı kanallar, farklı filtreler ve farklı sıkıştırma yöntemlerinin tümü bir takım takaslardır. Yazıcı üçgeninin dijital versiyonu gibi.

Çoğunlukla hareketli görüntüler de olsa, görüntü algılama ve kodlama / sıkıştırma ile çalıştığım için biraz ek bilgi vereceğim.

Temel biçiminde, belirli bir ekranda görüntülenen bir resim (HERHANGİ bir resim) aslında sadece aynı bir sayı dizisidir. Bu sayıların hepsi 0-255 veya 0-65535 veya 0-her neyse-32-bit-ben-unuttum-go-go olabilir.

AMA MAĞAZA ve ULAŞMAK için bu kadar çok yol var, bu bilgilerin birçoğu sadece zaman sisi için kaybedilen teknolojilerin ürünleri.

Ayrıca, burada bahsettiğim diğer bölümlerden hiçbirini görmediğim bir ayrıntı, dijital kameradan gelen RAW görüntü sensörü verilerinin bir bayer düzeninde RGrGbB veya en azından biraz işlenmesi gereken somesuch olabilir. Mk.1 insan göz küresi için herhangi bir anlamda. Şüphesiz, DSLR'nizin kaydettiği RAW biçiminde bile olsa bunu asla elde edemezsiniz, çünkü 8, 16, 32 veya onbirinci milyar bit derinliğinde, güzel bir RGB veya YUV piksel ızgarasına dönüştürene kadar işe yaramaz.

Üzerinde çalıştığım şeyler, hangi nedenle olursa olsun YUV'yi kullanıyorlar. Bence codec'ler tarafından daha kolay işlendiğini, insanlar parlaklığı renkten çok daha fazla hassasiyetle algıladıklarını düşünüyorum.

Biraz yatmadan önce okumak için "çerçeve görüntüsü formatı" bölümüne bakın: http://focus.ti.com/lit/ug/sprufg8b/sprufg8b.pdf

Neyse ... TIFF / RAW / IFF / PNG gibi sıkıştırılmamış görüntü dosyaları arasındaki fark hakkındaki orijinal sorunuza geri dönün.

Genel olarak bunların var olmasının nedeni, aylar önce, her bilgisayar / işletim sistemi / yazıcı üreticisinin, görüntülerin saklanması / gönderilmesi için bir miktar farklı gereksinim kümesi getirmesiydi.

Bu yüzden, bu konudaki diğer kişiler tarafından tartışıldığı gibi RAW, kamera üreticisinin önemli olduğunu düşündüğü her türlü veri yükünü kullanarak, kameralarının gelecekte sahip olabileceği veya sahip olabileceği özelliklere bağlı olarak, farklı dijital kameralar tarafından kaydedilen farklı şeyler için genel bir terimdir. Bu nedenle, ana resim veri biti çok benzer olsa da, etrafındaki görüntü ve tüm kamera ayarlarını vb. Tanımlayan "ambalaj" bir dosya farklı bir üretici tarafından anlaşılmayacaktı.

Geleneksel olarak bu, sizin (veya daha büyük olasılıkla profesyonel fotoğrafçıların) bu yüksek kaliteli görüntüleri işlemek için kendi özel (ve bazen pahalı) yazılımlarını kullanabilmelerini sağlar, aksi takdirde diğer insanların pahalı yazılımlarını kullanmaya başlayabilirsiniz. Ayrıca, belki de Adobe Photoshop formatlarını desteklemek ister, bu yüzden belki daha fazla profesyonel fotoğrafçının PS'yi satın alabilmesi ve belki de bu kamerayı satın alabilmesi için Adobe $$$'i şarj edebilir. Rahat!

RAW, aynı zamanda belirli bir veri grubunu insan tarafından görülebilir bir resme nasıl dönüştürecağınızla ilgili bilgileri saklar, verilere yapmanız gereken tüm tweaks öğelerini "doğru" görüntüye getirmek için görüntüler.

TIFF, diğer şeylerin yanı sıra, yazıcılara grafik veri göndermek için kullanılan eski bir görüntü formatıydı (grafik özellikli yazıcılar uygun fiyatlı olmaya başladığında). Yazıcının içindeki küçük ucuz mikroişlemcide işlem yapmak oldukça kolaydı.

IFF (evet, bu bir şey) Amiga bilgisayarlarında kullanılana benzer bir formattı, onlar tarafından ya da popüler boya paketlerinden birinin icat edildiğine inanıyorum. Ancak, burada örnek olarak kullanıyorum, çünkü diğerleri gibi bit eşlem resim verilerini depolasa da, sıkıştırılmamış veya RLE verilerini, 1 bit mono'dan 8 bit 256-renge kadar değişen bit derinliklerini destekledi (ancak renklerin her biri için seçilebilecek 3x8 bit RGB paletinin yanı sıra, dönemin diğer makinelerinin yönetebileceğinden çok daha fazla renk sağlayan Yarım Ton ve Beklet ve Değiştir gibi özel modlar. Oh, ve aynı zamanda animasyonu da destekledi (GIF gibi), böylece bir IFF dosyası, kareler arasında değişken gecikmelerle herhangi bir sayıda kareyi depolayabilir ve her karenin kendi paleti olabilir. Bu yüzden, IFF, bir TIFF dosyasına kıyasla, tüm bunları ele almak için ek veriler içerecektir.

PNG, yine bitmap verilerini depolayan, ancak bir görüntüdeki değişken saydamlık için 8 bit alfa kanalı gibi bazı korkak özellikleri destekleyen (web sayfalarında yararlı olan), bu nedenle yine "veri yükü" resim verileri çok benzer görünebilir ancak etrafındaki sarmalayıcı farklıdır ve taşıma kapasitesi yalnızca piksel başına RGB verisi yerine RGBA içerebilir.

Yani, tanımlanmış 4 farklı resim dosyası formatı - bir kedinin örnek renkli tam HD görüntüsünü 4 tanenin herhangi birinde saklayabilirsiniz ve LOOK özdeş olur, ekranınızdaki her piksel SİPARİŞ AYNI değere sahip olur ve NO 4 ... arasındaki kalite farkı ... ancak 4 dosyanın boyutu, düzeni bakımından büyük olasılıkla farklı olması ve yazılımın yüklenmesi ve işlenmesi için daha kolay veya daha zor olacaktır.

Umarım yardımcı olur!

Sadece bu sorunun ilk cevabında olması gereken bilgiyi burada bulacağımı düşündüm.

Görüntüdeki pikseller baytta depolanmaz - görüntü siyah beyaz olmadığı sürece yalnızca siyah beyazdır.

Gerçek renkli bir görüntünüz varsa, her piksel bir değer olarak 16 bit veya 2 bayt ile gösterilir. 32 bitlik bir görüntünüz varsa, her piksel tek bir değer olarak 32 bit veya 4 bayt gerektirir.

İlginç bir şekilde, görüntü ve ses dosyaları ile bir bilgisayardaki diğer her veri türü 1 ve 0 bitlerine kadar düşüyor. Sadece onları doğru boyutta parçalara çevirerek anlamın onlardan çıkarıldığı anlamına gelir.

Örneğin, bir resim ve bir kelime belgesi ile bir mp3 dosyasının tümü aynı temel veri içeriğine (bir demet bayt) sahiptir ve bunlardan herhangi biri diğer türlerden biri olarak yorumlanabilir - bir kelimeyi doc olarak ses olarak yorumlayabilirsiniz. dosya ve bir şey duyarsınız, ama müzik olmazdı. Bir ses dosyasını kesinlikle bir görüntü olarak yorumlayabilirsiniz ve bir şey gösterecektir, ancak tutarlı bir görüntü olmazdı.

Sonuç olarak, özetlemek gerekirse, bir bilgisayar yalnızca bitleri bilir - biraz 1 veya 0 olur. Tüm görüntüler, sesler, belgeler, filmler, videolar, kayıtlar, oyunlar, telefon görüşmeleri, metin mesajları ve dijital olarak etiketlenmiş herhangi bir şey aynı içerik - 1'li ve 0'lı bir demet. 1'ler ve 0'lar görüntüler, sesler, belgeler ve diğer her şeydir, çünkü bunları okuyan kod bu bitleri okumayı bilir ve bunları uygun şekilde işler.

Bu yüzden 16 bit ve 32 bit görüntüler ve 16 bit ve 24 bit ses dosyaları gibi şeylere sahibiz. Bir piksel veya ses örneği için ne kadar çok bit kullanırsanız, o kadar etkileyici olabilirsiniz - 16 bit yalnızca 64k benzersiz renk tanımlayabilir, ancak 32 bit 4 milyondan fazla benzersiz renk tanımlayabilir. Tek renkli bir görüntü, piksel başına 1 bit kullanır - açık veya kapalı.

Ses dosyalarında, örnek başına ne kadar çok bit kullanırsanız, kayıt o kadar ayrıntılı ve farklı olabilir.

Tüm konuyu okumadım ama birçok kişi vectorized görüntü formatlarını unutuyor gibi görünüyor. Bunlar piksel dizisi değildir, çünkü piksel kavramı bile böyle bir biçimde mevcut değildir. Görüntünün bir ekranda veya başka bir ortamda nasıl üretileceğini bulmak, işleyiciye kalmıştır.

Renk alanlarından, sıkıştırma, bit boyutlarından ve kanal formatından bahsetmeden bile, piksel haritalarından tamamen farklı bir dosya formatları kümesi vardır. Yine de, vektör biçimleri, tipik olarak bir kamera tarafından değil, bir bilgisayar tarafından üretilen belirli görüntü türlerini temsil etmede çok daha "iyidir".

Bu soruya daha önce oldukça ayrıntılı cevap verildi. Bununla birlikte, cevaplarda sunulan birçok teori olmasına rağmen, genellikle daha fazla açıklama gerektiren bilgisayar programlamayla ilgili bazı temel konular olduğunu düşünüyorum. Yazılım mühendisi olduğumu söylemeliyim. Anladığım soruyu okuduktan sonra, bu soruyu oluşturan temel programlama veri türlerinin tamamen yanlış anlaşıldığını gördüm.

Buradaki ilk soru şudur:

Ayrıca, sayısal bir bakış açısından, 32 bit görüntülerden farklı bir 16 bit görüntü gibi bir şey yapan şey nedir? Yine, bir görüntü sadece 0 -255 arasında tamsayı değerleri olan bir dizidir.

Daha önce de belirtildiği gibi: Hayır değil. Görüntü yalnızca 0-255 arasında bir tam sayı değerleri dizisi değil. Aslında 0 ila 65535 değerlik tek veya çok boyutlu bir dizi, 0 ila 4294967295 dizisi veya bir bit dizisi (bir bit 0 veya 1 değeri tutabilir, hepsi budur) olabilir; görüntü dosyalarını çeşitli kodlama kurallarına göre tam sayılar halinde okur.

Bunu daha önce anlamak için, daha önce de belirtildiği gibi, temel programlama veri tipleri üzerine bir tartışma yapılması gerektiğini düşünüyorum. Onları olabildiğince basit bir şekilde açıklamaya çalışacağım, böylece herhangi biri tamsayı değerlerini bilgisayar dosyalarına kaydetmeyle ilgili sorunları anlayacak.

Bilgisayar programlamada, değerleri dosyalara yazmak, bunları dosyalardan bilgisayar belleğine okumak, çeşitli özel programlama dilleri veri türlerini kullanarak bu değerleri işlemek ve sonunda bunları dosyalara kaydetmek için bazı temel ilkel veri türlerini kullanırız. Bilgisayar programında tamsayılar sadece tamsayı değildir. Her çeşit tam sayı vardır, kullandığımız programlama diline ve her biri için ne kadar belleğe ihtiyacımız olduğuna bağlı. Tipik olarak, çoğu programlama dilinde aşağıdaki veri türlerine sahibiz (ve bunları düzenlemenin yolları):

• BIT - 0 veya 1 tutma
• UINT8 - 8bit işaretsiz tamsayı - [0 - 255] aralığı arasındaki değerleri tutabilirler.
• INT8 - 8 bit işaretli tam sayı - [-126 - 127] aralığı arasındaki değerleri tutabilirler.
• UINT16 - 16bit işaretsiz tamsayı - [0 - 65535] aralığı arasındaki değerleri tutabilirler.
• INT16 - 16bit işaretsiz tamsayı - [−32768 - 32767] aralığı arasındaki değerleri tutabilirler.
• UINT32 - 32bit işaretsiz tamsayı - [0 - 4294967295] aralığı arasındaki değerleri tutabilirler.
• INT32 - 32bit işaretsiz tamsayı - [−2147483648 - 2147483647] aralığı arasındaki değerleri tutabilirler.
• VEYA tüm bu veri tiplerinin daha karmaşık bir formatta bir kombinasyonu. Örneğin, 3 farklı değer tutan bir UINT16 (16 BIT), ilk 0 BIT tutma değerleri 0 ila 127 arasında, sonraki BIT 0 veya 1 tutma vb.

Ayrıca DAHA FAZLASI, programcıların dosyalardan tamsayı veri türünü okurken veya yazarken uğraşması gereken bir şey vardır. Endianess.Endianness, bellekte veya dosyalarda saklandığında baytların (tablomuzdan UINT8) daha büyük sayısal değerler olarak düzenlendiği sıralı sırayı ifade eder. Endianness bilgisayar biliminde ilgi çekicidir, çünkü iki çelişkili ve uyumsuz format ortak kullanımdadır: bitlerin veya baytların veya diğer bileşenlerin büyük uçtan sipariş edilip edilmediğine bağlı olarak değerler büyük-endian veya küçük-endian biçiminde gösterilebilir (en önemli bit) veya küçük uç (en az anlamlı bit). Basit bir şekilde, bu 0000000011011111 veya ... bunun gibi 1101111100000000 gibi bir değeri veya seçtiğiniz endian sırasını saklayabilirsiniz. Ve amacınıza uygun herhangi bir sipariş seçmekte özgürsünüz. Bir görüntü dosyası formatı tasarlarken yaptığınız kuralların diğerleri yoktur.

Lütfen bilgisayar programında tamsayıların değere bağlı olarak az veya çok alan kullandığına dikkat edin. 255255255 yazmak için daha fazla kağıda ihtiyacın olduğu gibi, daha büyük bir değer yazmak için daha fazla BIT'e ihtiyacın var. Daha sonra değeri okumak istediğinizde, bunu yazarken oluşturduğunuz kuralları tam olarak bilmeniz gerekir. Aksi halde, sadece 0 -255 arasındaki tamsayı değerlerine sahip bir diziyi nasıl okuyacağımızı anlamamız imkansızdır, çünkü bu sayıların nerede depolandığını ve bu sayıların sahip olduğunuz çok sayıda seçenekle nasıl depolandığını bilmezsiniz (BIT, UINT8). , UINT16, UINT32 veya tüm bu bilgisayar veri türlerinin bir kombinasyonu). Sakın unutma, Endianness. Verilerin büyük veya küçük endian düzeni kullanılarak yazıldığını bilmiyorsanız, doğru değeri okuyamazsınız.

Bu görüntüler ASLA ASLA sadece 0 - 255 arasında tamsayı değerleri olan bir dizidir. Bazıları UINT16 dizileridir (16bit resimler), diğerleri UINT32 dizileridir (32bit resimler) veya diğerleri UINT8 dizileridir (8bit resimler). Bazı çok yaratıcı bilgisayar programcıları, sizi INT8 dizileriyle yaşayan, -126 ile 127 arasındaki değer dizisi anlamına gelen işaretli türleri bile kullanabilir.

Aslında bir görüntü dosyasını okuduğunuzda, karşılaştığınız ilk verilerden biri genellikle görüntü genişliğini ve yüksekliğini temsil eden bazı BIT'lerdir. Ve bunlar sadece bazı 0-255 değerleri değildir. Bunlar ayrıca programcı tarafından seçilen bazı veri türleridir. Bazı programcılar 16 BIT'in maksimum 65535 piksel görüntü genişliği saklamak için yeterli olduğunu düşüneceklerdir, çünkü bir takım küçük düğmelerin görüntülerini tutmak için bir oyunda kullanılan bir görüntü formatı tasarlıyorlar. Bazı başka programcılar burada 4294967295 genişliğe ve yüksekliğe kadar görüntü saklamanıza izin veren 32bit bir değer kullanabilir.Kuralları bilmiyorsanız, bu "değerleri" kendi deyiminizle okuyamazsınız. Çünkü görüntü dosyasında nereden başladıklarını ve nerede bitdiklerini bilmiyorsunuz. Böylece hiçbir şey anlamadığınız bir grup BIT ile karşılaşırsınız.

Bu yüzden evren pek çok farklı resim formatıyla doludur. Çünkü bir tamsayı değerlerini bir dosyaya yazmak için standart bir çözüm yoktur . Tamamen, üzerinde çalışmakta olduğunuz makinenin Endianess'i, orijinal dosya formatı uygulamasını tasarlamak için kullandığınız programlama dili ve görüntü formatının amacı gibi başka pek çok şey (örneğin daha önce açıkça belirtildiği gibi) temel alarak programcı seçimidir. diğer cevaplar).

4x2 piksel görüntüyü temsil etmek için yalnızca bir tek değeri 166 tutan siyah beyaz görüntünün pratik basit dosya biçimi:

Resim (1 - siyah piksel, 0 - beyaz piksel):

1010 
0110

Bu dosya formatı SINGLE 8bit tamsayı değeri 166 (10100110) olarak depolanan PIXEL başına 1 BIT kullanır. Bu kadar. 0-255 değer dizisi kullanılmaz, ancak değer 166 olarak kaydedilen 8 farklı 0 veya 1 değer kullanılır.

RGB için her piksel için * 3 kez 0-255 değer dizisi kullandıysanız, 24 kat daha büyük bir görüntü elde edersiniz. Bu dosya formatı sadece 24 kat daha az disk alanı kaydetti, bu görüntüyü kaydetmeniz gereken 24 kat daha az veya bu görüntüyü kullanmak için gerekli olan bilgisayar belleğinin 24 kat daha az olması, örneğin bu görüntüyü yüksek performanslı 3D oyun motorunuzda kullanırken Ekranda bir şey çizin (etrafında uçan binlerce toz partikülünü tekstüre etmek iyi bir aday olabilir :)).