Bereite dich auf einen riesigen Beitrag vor - ja, das ist außer Kontrolle geraten ...
Obligatorische xkcd:
Leider gibt es kein einfaches "bestes" Format. Einige werden sehr gut unterstützt, andere bieten extreme Vielseitigkeit, andere verlustfreie Komprimierung, ...
Der erste Teil dieser Antwort ("Funktionen" und "Kurzer Überblick über die Formate") befasst sich mit technischen Aspekten, während der zweite Teil ("(Andere) zu berücksichtigende Punkte") sich eher mit den praktischen Aspekten der Formatwahl befasst .
Eigenschaften:
Bitte beachten Sie, dass es fast unmöglich ist, jeden Hack in jedes Format aufzunehmen - z. B. können GIFs ohne Komprimierung gespeichert werden, indem die LZW-Tabelle ignoriert wird. Warum erwähne ich das unten nicht? Weil 99% aller GIFs, denen ich jemals begegnet bin, LZW verwendet haben, weil LZW heute ein Kinderspiel in Bezug auf Rechenleistung ist und weil dieser Beitrag versucht, die Situation für beliebte Situationen zu klären, nicht für die Forschungs- und Entwicklungsabteilung von ILM. Fotografen verwenden ihre Dateien zum Archivieren, Veröffentlichen und Drucken. Dies sind also die Dinge, die ich hier betrachte.
Informationen, die zwischen den jeweiligen Wikipedia-Artikeln, Spezifikationen, dem Wiki-Vergleich und der Metadaten-Support-Liste von exiftool abgeglichen wurden .
| 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 | |
Legende : o
... Optional; n
... Nicht verfügbar; y
... verfügbar; D
... Tiefe; *
... Schauen Sie sich unten den entsprechenden Text an.
Kurzer Überblick über die Formate:
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
Legende : b/c/p
... Bits pro Kanal (z. B. R, G, B) pro Pixel. Dinge in [ ]
sind optional; ?
... fundierte Vermutung / keine Ahnung.
'Bitmap'-Dateien werden in Zeilen codiert und normalerweise nicht komprimiert, sodass ein einzelner Bit-Flip nur eine Zeile des Bildes zerstört, solange der Header nicht gespiegelt wird, was das Decodieren erschwert - probieren Sie es selbst mit einem HEX aus Editor! . Da es keine (gute) Komprimierung bietet, sind die Dateigrößen sehr groß, da die vollständigen Informationen für jedes Pixel gespeichert werden müssen. Aufgrund seiner Steifheit kann es für die Langzeitarchivierung gut sein.
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)
Legende : b/c/p
... Bits pro Kanal (z. B. R, G, B) pro Pixel. Dinge in [ ]
sind optional; ?
... fundierte Vermutung / keine Ahnung.
'Better Portable Graphics' (BPG) verwendet HEVC, das Sie möglicherweise aus dem Video-Codec h.265 kennen . Es sollte der Nachfolger von JPEG sein, wurde aber nie populär genug. Mit dem Aufstieg von HEIF, der in gewisser Hinsicht ziemlich ähnlich, aber populärer ist, ist es plausibel, dass HEIF bevorzugt wird. HEVC ist in Bezug auf die Komprimierung im Vergleich zu JPEGs DCT weit überlegen - es lässt sich jedoch nur bei den niedrigeren Bitraten gut vergleichen, da es tendenziell verschwommen ist.
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)
Legende : b/c/p
... Bits pro Kanal (z. B. R, G, B) pro Pixel. Dinge in [ ]
sind optional; ?
... fundierte Vermutung / keine Ahnung.
OpenEXR wurde von Industrial Lights and Magic (ILM) als Zwischenformat für VFX-Workflows entwickelt. Es kann mehrere Kanäle mit sehr hoher Bittiefe, mehrere Bilder und Metadaten in einer Datei enthalten. Es bietet verschiedene Komprimierungsalgorithmen - oder überhaupt keine Komprimierung. EXR kann mit TIFF verglichen werden - EXR bietet mehr Optionen, während TIFF weitaus beliebter ist.
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)
Legende : b/c/p
... Bits pro Kanal (z. B. R, G, B) pro Pixel. Dinge in [ ]
sind optional; ?
... fundierte Vermutung / keine Ahnung.
'Free Lossless Image Format' (FLIF) verwendet ein Derivat der verlustfreien HEVC-Komprimierung. FLIF behauptet, im Vergleich zu allen anderen Formaten der Zeit extreme Komprimierungsverhältnisse zu haben - während meine eigenen Tests mich zu der Annahme veranlassten, dass es wirklich Rechenleistung benötigt, um nutzbar zu sein (mehrere Minuten Codierungszeit für ein einzelnes 24-MP-Bild mit einem Hyperthread 4,3 GHz Hexacore ist nicht so gut: D) . Da es sich jedoch um einen jungen Codec handelt, können Verbesserungen auftreten. Es bietet Unterstützung für Animationen, Alphakanäle, progressive Dekodierung und sogar verlustbehaftete Codierung (ohne Generationsverlust nach der ersten Codierung). Nur die Zeit wird zeigen, ob es gelingen wird, und um ehrlich zu sein, hoffe ich es sehr, da es eine einzige Lösung für mehrere Probleme zu bieten scheint.
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
Legende : b/c/p
... Bits pro Kanal (z. B. R, G, B) pro Pixel. Dinge in [ ]
sind optional; ?
... fundierte Vermutung / keine Ahnung.
Während 'Graphics Interchange Format' (GIF) 8 Bit pro Kanal und Pixel bietet, werden diese auf eine Farbpalette von 256 Farben reduziert (die eine "Hintergrundfarbe" enthalten kann). Es wird hauptsächlich für Animationen verwendet - das einzige, was PNG nicht besser machen kann, da PNG an sich keine Animationsunterstützung bietet.
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
Legende : b/c/p
... Bits pro Kanal (z. B. R, G, B) pro Pixel. Dinge in [ ]
sind optional; ?
... fundierte Vermutung / keine Ahnung.
'High Efficiency Image Format' (HEIF) verwendet HEVC auch zur Komprimierung. Zusätzlich zu den Farbkanälen kann es entweder einen Alphakanal oder eine Tiefenkarte enthalten (wird für spätere Tiefenschärfeeffekte der Software verwendet ). Auch die rudimentäre Bearbeitung kann verlustfrei erfolgen. Gemäß den Spezifikationen verfügt es auch über einen verlustfreien Komprimierungsmodus. Da dies von allen großen Betriebssystemen unterstützt wird, scheint es der wahrscheinlichste Kandidat für eine Folge von JPEG zu sein (falls es jemals eines gibt).
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
Legende : b/c/p
... Bits pro Kanal (z. B. R, G, B) pro Pixel. Dinge in [ ]
sind optional; ?
... fundierte Vermutung / keine Ahnung.
'Joint Photographic Experts Group' (JPEG) ist heute wohl das am häufigsten verwendete Bildformat. Es verwendet die diskrete Cosinustransformation (DCT), die verlustbehaftet ist. Es gibt eine verlustfreie Spezifikation, die jedoch nicht zu oft verwendet wird. Bestimmte Programme können bestimmte rudimentäre Aktionen (z. B. Drehung) verlustfrei ausführen. Dies erfordert jedoch auch, dass Bildbreite und -höhe durch 8 teilbar sind (die Blockgröße von JPEG) - z. B. 800 x 640 funktionieren, 804 x 643 nicht. JPEG hat keine Möglichkeit, Bilder in RGB zu speichern - es wandelt das Bild in den YCbCr-Farbraum um und reduziert häufig die Pixelinformationen von 4: 4: 4 (jedes Pixel hat alle Kanäle) auf 4: 2: 0 (jeder Kanal hat Luminanz, aber nur alle 4 th Pixel bekommt eine Cb / Cr-Wert). Wie bei den meisten Farbraumkonvertierungen kann dies zu wahrnehmbaren Unterschieden führen, insbesondere bei extremen Farben. JPEG ist schnell zu codieren und in Einstellungen mit hoher Qualität nicht schlecht, aber für mich würden die oben genannten Dinge mich nicht zum Weinen bringen, wenn es jemals verschwinden würde - es hat uns gute Dienste geleistet, aber die verwendeten Bildformate könnten etwas mehr sein ... kürzlich. Immerhin haben sich Computer seit 1991 gut entwickelt.
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)
Legende : b/c/p
... Bits pro Kanal (z. B. R, G, B) pro Pixel. Dinge in [ ]
sind optional; ?
... fundierte Vermutung / keine Ahnung.
'JPEG 2000' (JP2k oder JP2) ist der offizielle Nachfolger von JPEG. Es verwendet Wavelets anstelle der DCT, die weniger blockartige Artefakte bieten und insgesamt vielseitiger als JPEG sind. Trotz alledem hat es JPEG nie wirklich eingeholt.
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)
Legende : b/c/p
... Bits pro Kanal (z. B. R, G, B) pro Pixel. Dinge in [ ]
sind optional; ?
... fundierte Vermutung / keine Ahnung.
'JPEG Extended Range' (JPEG XR, JXR) ist ein weiterer Versuch, JPEG erfolgreich zu machen. Sein YCgCo-Farbraum ist YCbCr überlegen, da er vollständig reversibel ist. Während einige Software dies unterstützt, kam es auch nie an den Ruhm anderer Formate heran.
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
Legende : b/c/p
... Bits pro Kanal (z. B. R, G, B) pro Pixel. Dinge in [ ]
sind optional; ?
... fundierte Vermutung / keine Ahnung.
'Portable Network Graphics' (PNG) wurde als Nachfolger von GIF eingeführt. PNG-Dateien sind zwar vom Design her verlustfrei, können jedoch mit verschiedenen Tools optimiert werden, von denen einige die Datei verlustbehaftet komprimieren. PNG verwendet die DEFLATE-Komprimierung, sodass sie für Grafiken (wie CAD-Zeichnungen, Screenshots usw.) recht effizient ist, für Fotos jedoch weniger effizient. Einige Programme bieten zwar Unterstützung für Metadaten, haben jedoch Probleme beim Lesen. Danke für das Heads-up, @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
Legende : b/c/p
... Bits pro Kanal (z. B. R, G, B) pro Pixel. Dinge in [ ]
sind optional; ?
... fundierte Vermutung / keine Ahnung.
'Truevision TGA' / 'TARGA' (TGA) ist ein Fie-Format, das ich nur aufgenommen habe, weil es jeder zu kennen scheint. Es wurde 1984 eingeführt. Es unterstützt die verlustfreie Komprimierung (RLE), die für Grafiken in Ordnung ist, für Fotos jedoch nicht so gut.
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
Legende : b/c/p
... Bits pro Kanal (z. B. R, G, B) pro Pixel. Dinge in [ ]
sind optional; ?
... fundierte Vermutung / keine Ahnung.
Auch das 'Tagged Image File Format' (TIF oder TIF) gibt es schon lange. Es bietet Layer-Unterstützung (dh mehrere gestapelte RGBA-Bilder). TIFFs werden häufig als Zwischendateien verwendet, da sie weitgehend unterstützt werden und hinsichtlich ihrer Funktionen recht flexibel sind.
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)
Legende : b/c/p
... Bits pro Kanal (z. B. R, G, B) pro Pixel. Dinge in [ ]
sind optional; ?
... fundierte Vermutung / keine Ahnung.
'WebP' verwendet VP8 (ein Open-Source-Konkurrenzformat zu AVC). Wie bei BPG hat es nie den Sprung in Consumer-Geräte geschafft, obwohl es anscheinend von vielen Internetdiensten verwendet wird.
(Andere) Dinge zu beachten:
Neucodierung (Generationsverlust)
Das Neukodieren einer verlustfreien Datei ändert nichts - das Neukodieren einer verlustbehafteten Datei führt mit ziemlicher Sicherheit zu Artefakten. JPEG kann damit ziemlich gut umgehen, wenn Sie die Datei in derselben Qualitätseinstellung speichern, in der sie zuvor gespeichert wurde.
Dieses Video zeigt den Generationsverlust ziemlich gut - das erste Bild zeigt die Originaldatei, während alle anderen eine erneute Komprimierung bei unterschiedlichen Qualitätseinstellungen zeigen. (Beachten Sie, dass sich FLIF im verlustbehafteten Modus befindet, sodass das erste Bild anders aussieht.)
Artefakte sind nicht unbedingt ein Todesurteil - z. B. für schnelles Web-Publishing oder Vorschau auf Mobilgeräten ist es möglicherweise nicht schlecht.
Langlebigkeit des Codecs
Als ich diese Antwort schrieb, dachte ich mir: "Wer würde heutzutage überhaupt TARGA verwenden?" und es brachte mich zum Nachdenken: Ich würde nie zögern, ein Auto zu fahren, das in den 80ern hergestellt wurde. Ich würde jederzeit Bilder anschauen, die in den 80ern aufgenommen wurden. Ich würde alle Kameras verwenden, die in dieser Zeit hergestellt wurden. Aber ich würde keinen so alten Codec verwenden. Warum?
Am Ende gibt es keine sichere Möglichkeit zu sagen, ob der eine oder der andere Codec eine bestimmte Zeitspanne überlebt. Wenn HEIF morgen JPEG auf allen Consumer-Geräten ersetzen würde, wie lange würde es dauern, bis Programme die JPEG-Unterstützung einstellen? Wie viele Computergenerationen - und was noch wichtiger ist: Betriebssysteme - wird es geben, bevor Sie sie nicht mehr öffnen können?
Andererseits erfordern relativ einfache Codecs wie TARGA nur relativ einfache Programme, um sie zu lesen, während moderne Codecs und ihre Decoder mehrere Abhängigkeiten aufweisen. Während Einfachheit für die Komprimierung schlecht ist, kann sie in einem apokalyptischen Szenario für die Archivierung gut sein. Vielen Dank an @lijat für den Hinweis!
Meiner Meinung nach müssen dazu mehrere Aspekte berücksichtigt werden: Welcher Codec ist populär genug, damit die Unterstützung nicht sofort abfällt? Welcher Codec wird von der Open Source-Community unterstützt (weil niemand proprietäre Formate eines bankrotten Unternehmens verwaltet)? Es scheint auch, dass man mindestens alle zehn Jahre sehen sollte, ob es notwendig ist, zu einem neuen, besser unterstützten Codec zu springen (siehe "Neucodierung (Generationsverlust)") - das möchten Sie zum Beispiel nicht Ihre TARGA-Sammlung soll morgen unlesbar sein, oder?
Das ist übrigens besonders besorgniserregend, wenn man an RAW-Dateien denkt .
Programmunterstützung (Langlebigkeit # 2)
Der beliebteste und beste Codec ist nicht gut genug, wenn Sie ihn nicht verwenden können. Und obwohl ich keine minderwertigen Codecs verwenden würde, nur weil ein bestimmtes Programm dies nicht unterstützt, kann es schlecht sein, einen Codec zu verwenden, den nur ein Programm ordnungsgemäß unterstützt.
Welche Funktionen brauche ich?
Persönlich codiere ich die meisten meiner Dateien immer noch in JPEG - ich kann sie auf jedem Gerät lesen und die Artefakte kaum (wenn überhaupt) sehen. 8bit ist für die meisten Geräte gut genug und Alphakanäle werden nicht wirklich benötigt, wenn nur Bilder angezeigt werden.
Für alle Dateien, die nicht "einmal bearbeiten" sind, behalte ich entweder meine RAWs oder mindestens 16-Bit-TIFFs, damit sie auch in Zukunft verwendet werden können.
PSD? DNG?
"Photoshop Document" (PSD) ist das TIFF-Format von Photoshop. Technisch ist es TIF ziemlich ähnlich. Es gibt auch PSB, was nur für Dateigrößen über 4 GiB gilt. Es ist nichts Falsches daran, aber ich persönlich bevorzuge TIFF so weit wie möglich.
"Digital Negative" (DNG) ist ein Versuch, einen offenen RAW-Standard zu erstellen. Obwohl ich die Idee liebe und sie recht gut funktioniert, beachten Sie, dass einige RAW-Editoren Probleme mit ihnen haben - z. B. vergisst Capture One normalerweise den Weißabgleich der Kamera und stellt den Schieberegler auf 5000 KB ein, unabhängig vom tatsächlichen Wert. Andere Programme in der Vergangenheit haben sie als feste weiße oder rosa Bilder gezeigt oder ihnen einen magentafarbenen Farbton gegeben. Wenn Ihnen die Dateigröße keine Rolle spielt, können Sie das Original-RAW in Ihre DNG aufnehmen. Wenn Sie es jemals wieder benötigen, können Sie es einfach erneut extrahieren. Meine 2 Cent? Probieren Sie es mit Ihrer Lieblingssoftware aus - und wenn es gut funktioniert, verwenden Sie es.
Andere Formate?
Da dies bereits außer Kontrolle geraten war, wollte ich nicht noch mehr Bildformate ansprechen. Dies bedeutet jedoch nicht, dass die nicht aufgeführten nicht erwägenswert sind.