Muazzam bir gönderi için hazırlanın - evet, bu kontrolden çıktı ...
Zorunlu xkcd:
Ne yazık ki, basit bir 'en iyi' format yoktur. Bazıları çok iyi desteklenir, bazıları aşırı çok yönlülük sunar, bazıları kayıpsız sıkıştırma sunar, ...
Bu cevabın ilk kısmı ("Özellikler" ve "Formatlara kısa bir bakış") tekniklerden bahsederken, ikinci kısmı ("(Diğer) Dikkate alınması gerekenler") daha çok format seçiminin pratik yönlerine yöneliktir .
Özellikleri:
Her hack'i her formata dahil etmenin neredeyse imkansız olduğunu unutmayın - örneğin, GIF'ler LZW tablosunu göz ardı ederek sıkıştırılmadan kaydedilebilir. Bunu neden aşağıda belirtmiyorum? Çünkü şimdiye kadar karşılaştığım tüm GIF'lerin% 99'u LZW kullandı, çünkü LZW bugün hesaplama gücünde beyinsiz ve bu yazı ILM'nin Ar-Ge departmanı için değil, popüler durumlar için durumu açıklığa kavuşturmaya çalıştığı için. Fotoğrafçılar dosyalarını arşivleme, yayınlama ve basım için kullanacaklardır, işte burada düşündüğüm şeyler bunlar.
İlgili Wikipedia makaleleri, spesifikasyonları, Wiki karşılaştırması ve exiftool'un meta veri destek listesi arasında çapraz kontrol .
| Bits per | | Supported by
Codec | Lossy | Channel | Metadata | Channels | Programs | Good for (IMHO)
-------------------------------------------------------------------------------------------------
BMP | n | <= 8 | - | RGBA | Most propr. & free | Archival
BPG | y | <= 14 | EXIF+XMP | RGBA | |
EXR | o | <= 32 | y(?) | RGBAD | | VFX workflow
FLIF | o* | <= 16 | EXIF+XMP | RGBA | | To be seen
GIF | n | <= 8* | XMP | RGB | Most propr. & free | GIFs ;-)
HEIF | o* | <= 16 | EXIF+XMP | RGB(A/D) | | To be seen
JPEG | y* | <= 8 | EXIF+IPTC+XMP | RGB | ~ all propr. & free | Online; Easy access
JP2K | o | <= 32 | EXIF+IPTC+XMP | RGBA | |
JXR | o | <= 32 | EXIF+IPTC+XMP | RGBA | |
PNG | n | <= 16 | EXIF+IPTC+XMP*| RGBA | Most propr. & free | CAD-drawings; Online
TGA | n | <= 8 | y(?) | RGBA | |
TIFF | o | <= 32 | EXIF+XMP | RGBA | Most propr. & free | Archival; Editing
WebP | o | <= 8 | EXIF+XMP | RGBA | |
Açıklama : o... İsteğe bağlı; n... müsait değil; y... mevcut; D... Derinlik; *... Aşağıdaki metne göre bakın.
Biçimlere kısa genel bakış:
BMP
Feature |
-----------------------------------------------------------------
Introduced | 1990
Open + Free | Both per Microsoft's Open Specification Promise
Colorspace | R:G:B[:A] (4:4:4[:4])
b/c/p | 1:0:0[:0], 5:6:5, 8:8:8[:8]
Compression | None [RLE in 5:6:4] (so: lossless)
Maximum Size | 4 GiB
Metadata | [ICC]
OS support | Virtually all OSs with a graphical interface
Açıklama : b/c/p... piksel başına kanal başına bit (örn. R, G, B). içindeki şeyler [ ]isteğe bağlıdır; ?... eğitimli tahmin / ipucu yok.
'Bitmap' dosyaları satırlar halinde kodlanır ve genellikle sıkıştırılmaz, bu nedenle tek bir bit çevirme görüntünün yalnızca bir satırını yok eder Süreci çevirmediği sürece, kod çözmeyi zorlaştıracaktır - bir HEX ile kendiniz deneyin editör! . (İyi) sıkıştırma sunmadığından, her piksel için tüm bilgileri kaydetmek zorunda olduğu için dosya boyutları çok büyüktür. Sertliği nedeniyle uzun süreli arşivleme için iyi olabilir.
BPG
Feature |
---------------------------------------------------------------------
Introduced | 2014
Open + Free | Yes (but HEVC patents might be problematic)
Colorspace | R:G:B[:A] (4:4:4[:4]); Y:Cb:CR[:A] (4:2:0[:4] - 4:4:4[:4]);
| Y:Cg:Co[:A] (4:2:0[:4] - 4:4:4[:4]); C:M:Y:K (4:4:4:4)
b/c/p | 8 - 14
Compression | HEVC (lossy / lossless)
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [XMP]
OS support | Linux, Mac, Windows (at least through browser decoding)
Açıklama : b/c/p... piksel başına kanal başına bit (örn. R, G, B). içindeki şeyler [ ]isteğe bağlıdır; ?... eğitimli tahmin / ipucu yok.
'Better Portable Graphics' (BPG) , h.265 video codec bileşeninden bildiğiniz HEVC kullanır . JPEG'in halefi olması gerekiyordu, ancak hiçbir zaman yeterince popüler olmadı. Bazı yönlerden oldukça benzer ancak daha popüler olan HEIF'in yükselişi ile HEIF'in tercih edileceği akla yatkındır. HEVC, JPEG'in DCT'sine kıyasla sıkıştırma açısından çok daha üstündür - ancak, bulanık olma eğilimi gösterdiğinden, düşük bit hızları hariç tümünde iyi karşılaştırmaz.
EXR
Feature |
---------------------------------------------------------------------
Introduced | 1999
Open + Free | Yes
Colorspace | R:G:B[:A][:D] (4:4:4[:4][:4])
b/c/p | <= 32
Compression | [RLE]; [ZIP]; [PIZ]; ... [lossless (usual) / lossy]
Maximum Size | > 4 GiB
Metadata | [Yes (XMP-style)]
OS support | Linux, Mac, Windows (through library)
Açıklama : b/c/p... piksel başına kanal başına bit (örn. R, G, B). içindeki şeyler [ ]isteğe bağlıdır; ?... eğitimli tahmin / ipucu yok.
OpenEXR , Industrial Lights and Magic (ILM) tarafından VFX iş akışları için bir ara format olarak tasarlanmıştır. Çok yüksek bit derinliklerinde, birden çok görüntüyü ve meta verileri tek bir dosyada tutabilir. Farklı sıkıştırma algoritmaları sunar veya hiç sıkıştırma yapmaz. EXR, TIFF ile karşılaştırılabilir - EXR daha fazla seçenek sunarken, TIFF çok popülerdir.
FLIF
Feature |
---------------------------------------------------------------------
Introduced | 2015
Open + Free | Yes
Colorspace | R:G:B[:A] (4:4:4[:4]) (CMYK and YCbCr in ToDo-List)
b/c/p | <= 16
Compression | MANIAC (variant of CABAC, used in AVC/HEVC) (lossless / lossy (1st generation))
Maximum Size | > 4 GiB
Metadata | [EXIF]; [ICC]; [XMP]
OS support | Linux, Mac, Windows (through provided viewer)
Açıklama : b/c/p... piksel başına kanal başına bit (örn. R, G, B). içindeki şeyler [ ]isteğe bağlıdır; ?... eğitimli tahmin / ipucu yok.
'Serbest Kayıpsız Görüntü Biçimi' (FLIF) , kayıpsız bir HEVC sıkıştırması türevi kullanır. FLIF, zamanın diğer tüm formatlarına kıyasla aşırı sıkıştırma oranlarına sahip olduğunu iddia ediyor - kendi testlerim buna inanmamı sağlarken, gerçekten kullanılabilmesi için hesaplama gücüne ihtiyacı var (Hiper iş parçacıklı tek bir 24 MP resim için birkaç dakika kodlama süresi 4,3 GHz hexacore o kadar iyi değil: D) . Ancak, genç bir codec bileşeni olduğu için iyileştirmeler ortaya çıkabilir. Animasyonlar, alfa kanalları, aşamalı kod çözme ve hatta kayıplı kodlama (ilk kodlamadan sonra artık üretim kaybı olmadan) desteği sunar. Sadece zamanın başarılı olup olmadığını gösterecek ve dürüst olmak gerekirse, umarım çok sayıda sorun için tek bir çözüm sunuyor gibi görünüyor.
GIF
Feature |
---------------------------------------------------------------------
Introduced | 1987
Open + Free | Yes
Colorspace | R:G:B[:A] (4:4:4[:4])
b/c/p | 2 (palette of 256 colors in total)
Compression | LZW (lossless)
Maximum Size | < 4 GiB
Metadata | [XMP]
OS support | Virtually all OSs with a graphical interface
Açıklama : b/c/p... piksel başına kanal başına bit (örn. R, G, B). içindeki şeyler [ ]isteğe bağlıdır; ?... eğitimli tahmin / ipucu yok.
İken 'Grafik Değişim Biçimi' (GIF) teklifler piksel başına kanal başına 8 bit, (bir "arka plan rengi" içerebilir) 256 renk renk paletine onları azaltacaktır. Çoğunlukla animasyonlar için kullanılır - PNG'nin kendi başına animasyon desteği sunmadığı için PNG'nin daha iyi yapamayacağı tek şey.
HEIF
Feature |
----------------------------------------------------------------------
Introduced | 2015
Open + Free | No (patents)
Colorspace | ? Y:Cb:Cr[:A/:D] (4:2:0[:4]) ?
b/c/p | <= 16
Compression | HEVC (lossy)
Maximum Size | < 4 GiB
Metadata | [EXIF]; [XMP]
OS support | Linux, Mac, Windows
Açıklama : b/c/p... piksel başına kanal başına bit (örn. R, G, B). içindeki şeyler [ ]isteğe bağlıdır; ?... eğitimli tahmin / ipucu yok.
'Yüksek Verimli Görüntü Biçimi' (HEIF) sıkıştırma için HEVC kullanır. Renkli kanallara ek olarak, bir alfa kanalı veya bir derinlik haritası da tutabilir (daha sonraki yazılım alan derinliği efektleri için kullanılır ). Ayrıca, ilkel düzenleme kayıpsız olarak gerçekleşebilir. Spesifikasyonlara göre kayıpsız bir sıkıştırma moduna da sahiptir. Tüm büyük işletim sistemleri bunu desteklediğinden, bir ardışık JPEG (muhtemelen varsa) için en olası yarışmacı gibi görünüyor.
JPEG
Feature |
----------------------------------------------------------------------
Introduced | 1991
Open + Free | Sort of (free library, but patent might apply)
Colorspace | Y:Cb:Cr (4:2:0 (typical) - 4:4:4)
b/c/p | 8
Compression | DCT (lossy)
Maximum Size | < 2 GiB
Metadata | [EXIF]; [ICC]; [IPTC]; [XMP]
OS support | Virtually all OSs with a graphical interface
Açıklama : b/c/p... piksel başına kanal başına bit (örn. R, G, B). içindeki şeyler [ ]isteğe bağlıdır; ?... eğitimli tahmin / ipucu yok.
'Joint Photographic Experts Group' (JPEG) günümüzde tartışmasız en çok kullanılan görüntü formatıdır. Kayıplı türden ayrı kosinüs dönüşümünü (DCT) kullanır. Kayıpsız bir şartname vardır, ancak çok sık kullanılmaz. Bazı programlar belirli temel eylemleri (örneğin döndürme) kayıpsız gerçekleştirebilir, ancak bu aynı zamanda görüntü genişliği ve yüksekliğinin 8 ile bölünebilir olmasını gerektirir (JPEG'in blok boyutu) - örneğin 800x640 çalışmayacaktır, 804x643 çalışmaz. JPEG'de görüntüleri RGB'ye kaydetme seçeneği yoktur - resmi YCbCr renk alanına dönüştürür ve genellikle piksel bilgilerini 4: 4: 4'ten (her pikselin tüm kanalları vardır) 4: 2: 0'a (her kanalın parlaklığına sahiptir, ancak her kanalın parlaklığı vardır, ancak yalnızca her 4 inci piksel) bir Cb / Cr-değerini alır. Çoğu renk aralığı dönüşümünde olduğu gibi, bu özellikle aşırı renklerde algılanabilir farklılıklara yol açabilir. JPEG kodlamak hızlıdır ve yüksek kalite ayarlarında çok kötü değildir, ancak bana göre, yukarıda belirtilen şeyler yok olsaydı beni ağlatmazdı - bize iyi hizmet etti, ancak kullanılan görüntü formatları biraz daha fazla olabilir ... son. Sonuçta, bilgisayarlar 1991'den beri iyi bir evrim geçirdi.
JP2K
Feature |
----------------------------------------------------------------------
Introduced | 2000 (duh...)
Open + Free | No (patents)
Colorspace | ? Y:Cb:Cr[:A] (4:4:4[:4]) ?
b/c/p | 8 - 32
Compression | Wavelet (lossy / lossless)
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [IPTC]; [XMP]
OS support | Linux, Mac, Windows (at least through viewer programs)
Açıklama : b/c/p... piksel başına kanal başına bit (örn. R, G, B). içindeki şeyler [ ]isteğe bağlıdır; ?... eğitimli tahmin / ipucu yok.
'JPEG 2000' (JP2k veya JP2) , JPEG'in resmi halefidir. Daha az bloklu eserler sunan ve genel olarak JPEG'den daha çok yönlü olan DCT yerine dalgacıklar kullanır. Tüm bunlara rağmen, JPEG ile hiç yakalanmadı.
JXR
Feature |
----------------------------------------------------------------------
Introduced | 2009
Open + Free | Yes (Microsoft Open Specification Promise)
Colorspace | Y:Cb:Cr[:A] (4:2:0[:4] - 4:4:4[:4]); Y:Cg:Co[:A] (? 4:2:0[:4] - 4:4:4[:4] ?);
| C:M:Y:K [4:4:4:4]
b/c/p | 8 - 32 (16 for CMYK)
Compression | DCT (lossy / lossless)
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [IPTC]; [XMP]
OS support | Linux, Mac, Windows (at least through viewer programs)
Açıklama : b/c/p... piksel başına kanal başına bit (örn. R, G, B). içindeki şeyler [ ]isteğe bağlıdır; ?... eğitimli tahmin / ipucu yok.
'JPEG genişletilmiş aralık' (JPEG XR, JXR), JPEG'i başarmak için başka bir denemedir. YCgCo renk aralığı YCbCr'den üstündür çünkü tamamen geri dönüşümlüdür. Bazı yazılımlar onu desteklese de, diğer formatların şöhretine asla yaklaşamamıştır.
PNG
Feature |
----------------------------------------------------------------------
Introduced | 1996
Open + Free | Yes
Colorspace | R:G:B[:A] (4:4:4[:4])
b/c/p | 8 - 16
Compression | DEFLATE (lossless)
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [IPTC]; [XMP]
OS support | Virtually all OSs with a graphical interface
Açıklama : b/c/p... piksel başına kanal başına bit (örn. R, G, B). içindeki şeyler [ ]isteğe bağlıdır; ?... eğitimli tahmin / ipucu yok.
'Taşınabilir Ağ Grafikleri' (PNG) GIF'in halefi olarak tanıtıldı. Tasarımla kayıpsız olsa da, PNG dosyaları birkaç araçla optimize edilebilir, bazıları da dosyayı kayıplı bir şekilde sıkıştıracaktır. PNG, DEFLATE sıkıştırmayı kullanır, bu nedenle grafikler için (CAD çizimleri, ekran görüntüleri, ... gibi) oldukça etkilidir, ancak fotoğraflar için daha az verimlidir. Meta veriler için destek sunarken, bazı programlar bunları okumakta zorlanır. Uyarı için teşekkürler, @mattdm !
TGA
Feature |
----------------------------------------------------------------------
Introduced | 1984
Open + Free | ? Yes
Colorspace | R:G:B[:A] (4:4:4[:4])
b/c/p | <= 8
Compression | RLE (lossless)
Maximum Size | ? < 2 GiB
Metadata | Rudimentary
OS support | ? Virtually all OSs with a graphical interface
Açıklama : b/c/p... piksel başına kanal başına bit (örn. R, G, B). içindeki şeyler [ ]isteğe bağlıdır; ?... eğitimli tahmin / ipucu yok.
'Truevision TGA' / 'TARGA' (TGA) , dahil ettiğim bir dosya biçimidir, çünkü herkes biliyor gibi görünüyor. 1984 yılında tanıtıldı. Grafikler için iyi çalışacak, ancak fotoğraflar için iyi olmayan kayıpsız sıkıştırmayı (RLE) destekler.
TIFF
Feature |
----------------------------------------------------------------------
Introduced | 1986
Open + Free | ? Yes
Colorspace | R:G:B[:A] (4:4:4[:4]); Y:Cb:Cr[:A] (? 4:2:0[:4] - 4:4:4[:4] ?);
| C:M:Y:K (? 4:4:4:4 ?); L:a:b[:A] (? 4:4:4:[A] ?)
b/c/p | 8 - 32
Compression | [LZW (lossless)]; [ZIP (lossless)]; [JPEG (lossy)]
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [XMP]
OS support | Virtually all OSs with a GUI support >= 1 of the compression types
Açıklama : b/c/p... piksel başına kanal başına bit (örn. R, G, B). içindeki şeyler [ ]isteğe bağlıdır; ?... eğitimli tahmin / ipucu yok.
'Etiketli Resim Dosyası Biçimi' (TIF veya TIF) de uzun zamandır var. Katman desteği sunar (örn. Yığın halinde birden fazla RGBA görüntüsü). TIFF'ler genellikle ara dosyalar olarak kullanılır, çünkü yetenekleri açısından geniş ölçüde desteklenir ve oldukça esnektir.
WebP
Feature |
----------------------------------------------------------------------
Introduced | 2010
Open + Free | Yes
Colorspace | R:G:B:A (4:4:4[:4]) lossless; Y:Cb:Cr[:A] (4:2:0[:4]) lossy
b/c/p | 8
Compression | VP8 (lossless / lossy)
Maximum Size | ?
Metadata | [EXIF]; [ICC]; [XMP]
OS support | Linux, Mac, Windows (at least through browser decoding)
Açıklama : b/c/p... piksel başına kanal başına bit (örn. R, G, B). içindeki şeyler [ ]isteğe bağlıdır; ?... eğitimli tahmin / ipucu yok.
'WebP' , VP8'i (AVC'ye açık kaynaklı bir rakip format) kullanır. BPG'de olduğu gibi, pek çok internet hizmeti tarafından kullanıldığı görülmesine rağmen, tüketici cihazlarına hiçbir zaman sıçrama yapmadı.
(Diğer) Dikkat edilmesi gerekenler:
Yeniden kodlama (üretim kaybı)
Kayıpsız bir dosyayı yeniden kodlamak hiçbir şeyi değiştirmez - kayıplı bir dosyayı yeniden kodlamak neredeyse kesinlikle artefaktlara yol açar. JPEG oldukça iyi bu işleyebilir eğer bunu önce en kaydedildiği aynı kalitede ortamda dosyayı kaydedin.
Bu video, üretim kaybını oldukça iyi gösteriyor - ilk kare orijinal dosyayı gösterirken, diğerleri farklı kalite ayarlarında yeniden sıkıştırma gösteriyor. (FLIF'in kayıp modunda olduğunu unutmayın, bu nedenle ilk kare farklı görünecektir.)
Artefaktlar mutlaka bir ölüm cezası olmayacaktır - örneğin, hızlı web yayıncılığı veya mobil cihazlarda önizleme için çok kötü olmayabilir.
Codec bileşeninin uzun ömürlülüğü
Bu yanıtı yazarken kendi kendime "bugünlerde TARGA'yı kim kullanacak?" Diye düşünüyordum. ve beni düşündürdü: 80'lerde yapılmış bir araba kullanmaktan hiç çekinmezdim. 80'lerde çekilen resimlere bakmaktan çekinmem. O zaman yapılan kameraları kullanırdım. Ama o kadar eski bir codec bileşeni kullanmam. Neden?
Sonunda, bir kodek veya diğerinin belirli bir zaman diliminde hayatta kalacağını söylemenin kesin bir yolu yoktur. HEIF yarın tüm tüketici cihazlarında JPEG'in yerini alacak olsaydı, programların JPEG desteğini durdurması ne kadar sürer? Kaç nesil bilgisayar - ve daha da önemlisi: işletim sistemleri - artık açamadan önce olacak mı?
Öte yandan, TARGA gibi nispeten basit kodeklerin yalnızca göreceli olarak basit programların okunması gerekirken, modern kodeklerin ve kod çözücülerinin çoklu bağımlılıkları vardır. Bu nedenle sadelik sıkıştırma için kötü olsa da, kıyamet senaryosunda arşivlemek için iyi olabilir. @Lijat bunu işaret ettiğiniz için teşekkürler !
Bence bunun göz önünde bulundurulması gereken birkaç açı var: Hangi kodek, desteğin hemen düşmemesi için yeterince popüler? Açık kod topluluğu tarafından hangi codec bileşeni destekleniyor (çünkü kimse iflas eden bir şirketin tescilli formatlarını koruyamayacak)? Ayrıca, en azından her on yılda bir, yeni, daha iyi desteklenen bir codec bileşenine atlamaya gerek olup olmadığını görmelidir (Bkz. "Yeniden kodlama (üretim kaybı)") - örneğin, koleksiyonunuzun yarın okunamayacak olması değil mi?
Bu arada, RAW dosyaları hakkında düşünürken özellikle endişe vericidir .
Program desteği (Ömür # 2)
En popüler, en iyi codec bileşeni kullanamazsanız yeterince iyi olmayacaktır. Ve sadece belirli bir program onu desteklemediğinden daha düşük kodekleri kullanmayacak olsam da, sadece bir programın düzgün bir şekilde desteklediği bir kodek kullanmak kötü olabilir.
Hangi özelliklere ihtiyacım var?
Şahsen, hala dosyalarımın çoğunu JPEG olarak kodluyorum - bunları herhangi bir cihazda okuyabilirim ve eserleri neredeyse hiç göremiyorum. 8bit çoğu cihaz için yeterince iyidir ve sadece resimleri görüntülerken alfa kanallarına gerçekten ihtiyaç yoktur.
"Bir kez düzenleme" tarzı olmayan tüm dosyalar için, RAW'larımı veya en az 16bit TIFF'leri saklıyorum, böylece gelecekte de kullanılabilirler.
PSD? DNG?
"Photoshop Belgesi" (PSD), Photoshop'un TIFF tarzı biçimidir. Teknik olarak, TIF'e oldukça benzer. PSB de var, bu sadece 4 GiB üzerindeki dosya boyutları için aynı şey. Kullanırken yanlış bir şey yok, ama kişisel olarak, TIFF'i olabildiğince tercih ediyorum.
"Dijital Negatif" (DNG), açık bir RAW standardı yaratma girişimidir. Fikri çok seviyorum ve oldukça iyi çalışıyor olsa da, bazı RAW editörlerinin onlarla ilgili sorun yaşadığına dikkat edin - örneğin Capture One genellikle kameranın beyaz dengesini unutur, böylece gerçek değer ne olursa olsun kaydırıcıyı 5000K'ya ayarlar. Geçmişteki diğer programlar bunları düz beyaz veya pembe görüntüler olarak göstermiş veya macenta tonu vermiştir. Dosya boyutu sizi ilgilendirmiyorsa, orijinal RAW'ı DNG'nize dahil edebilirsiniz - tekrar ihtiyacınız varsa, tekrar çıkarabilirsiniz. 2 sentim mi? En sevdiğiniz yazılımla deneyin - ve iyi çalışırsa kullanın.
Diğer formatlar?
Bu zaten kontrolden çıktığı için daha fazla görüntü formatını ele almak istemedim. Ancak bu, listelenmeyenlerin dikkate almaya değer olmadığı anlamına gelmez.