JPEG

JPEG ⓘ

Ein Foto einer europäischen Wildkatze mit abnehmender Komprimierungsrate und damit zunehmender Qualität, von links nach rechts
Erweiterung des Dateinamens	.jpg, .jpeg, .jpe .jif, .jfif, .jfi
Internet-Medientyp	bild/jpeg
Typ-Code	JPEG
Einheitlicher Typbezeichner (UTI)	öffentlich.jpeg
Magische Zahl	ff d8 ff
Entwickelt von	Joint Photographic Experts Group, IBM, Mitsubishi Electric, AT&T, Canon Inc.
Erste Veröffentlichung	18. September 1992; vor 30 Jahren
Art des Formats	Verlustbehaftetes Bildkompressionsformat
Norm	ISO/IEC 10918, ITU-T T.81, ITU-T T.83, ITU-T T.84, ITU-T T.86
Website	www.jpeg.org/jpeg/

Kontinuierlich variierende JPEG-Kompression (zwischen Q=100 und Q=1) für eine abdominale CT-Aufnahme ⓘ

JPEG (/ˈdʒeɪpɛɡ/ JAY-peg) ist ein häufig verwendetes Verfahren zur verlustbehafteten Komprimierung digitaler Bilder, insbesondere von Bildern, die mit Hilfe der Digitalfotografie erzeugt wurden. Der Grad der Komprimierung kann eingestellt werden, so dass ein wählbarer Kompromiss zwischen Speichergröße und Bildqualität möglich ist. JPEG erreicht in der Regel eine Komprimierung von 10:1 bei nur geringfügigen Einbußen in der Bildqualität. Seit seiner Einführung im Jahr 1992 ist JPEG der weltweit am weitesten verbreitete Bildkompressionsstandard und das am häufigsten verwendete digitale Bildformat. 2015 wurden täglich mehrere Milliarden JPEG-Bilder produziert. ⓘ

Der Begriff "JPEG" ist ein Akronym für die Joint Photographic Experts Group, die den Standard im Jahr 1992 entwickelt hat. Die verlustbehaftete Bildkompression von JPEG basiert auf der diskreten Kosinustransformation (DCT), einer Technik, die erstmals 1972 von Nasir Ahmed vorgeschlagen wurde. JPEG war maßgeblich für die Verbreitung von Digitalbildern und Digitalfotos im Internet und später in den sozialen Medien verantwortlich. ⓘ

Die JPEG-Komprimierung wird in einer Reihe von Bilddateiformaten verwendet. JPEG/Exif ist das gebräuchlichste Bildformat, das von Digitalkameras und anderen Geräten zur Bilderfassung verwendet wird; zusammen mit JPEG/JFIF ist es das gebräuchlichste Format zur Speicherung und Übertragung von Fotos im World Wide Web. Diese Formatvarianten werden oft nicht unterschieden und einfach als JPEG bezeichnet. ⓘ

Der MIME-Medientyp für JPEG ist image/jpeg, außer in älteren Internet Explorer-Versionen, die beim Hochladen von JPEG-Bildern den MIME-Typ image/pjpeg anbieten. JPEG-Dateien haben normalerweise die Dateinamenerweiterung .jpg oder .jpeg. JPEG/JFIF unterstützt eine maximale Bildgröße von 65.535×65.535 Pixeln, also bis zu 4 Gigapixeln bei einem Seitenverhältnis von 1:1. Im Jahr 2000 führte die JPEG-Gruppe mit JPEG 2000 ein Nachfolgeformat ein, das jedoch nicht in der Lage war, das ursprüngliche JPEG als vorherrschenden Bildstandard zu ersetzen. ⓘ

Logo ⓘ

Ein Bild mit von links nach rechts abnehmenden Qualitätsstufen ⓘ

JPEG schlägt verschiedene Komprimierungs- und Kodierungsmethoden vor, darunter verlustbehaftete und verlustfreie Kompression, verschiedene Farbtiefen sowie sequenzielle oder progressive Modi (normaler Bildaufbau bzw. allmähliche Verfeinerung). Weithin verbreitet ist nur die verlustbehaftete Komprimierung bei sequenziellem oder progressivem Modus und 8-Bit-Farbkanälen. ⓘ

Die JPEG-Norm beschreibt lediglich Bildkompressionsverfahren, legt aber nicht fest, wie die so entstandenen Daten gespeichert werden sollen. Gemeinhin werden mit „JPEG-Dateien“ oder „JPG-Dateien“ Dateien im Grafikformat JPEG File Interchange Format (JFIF) bezeichnet. JFIF ist jedoch nur eine Art, JPEG-Daten abzulegen; SPIFF und JNG sind weitere, wenn auch wenig gebräuchliche, Möglichkeiten. ⓘ

Geschichte

Hintergrund

Die ursprüngliche JPEG-Spezifikation, die 1992 veröffentlicht wurde, setzt Verfahren aus verschiedenen früheren Forschungspapieren und Patenten um, die von der CCITT (jetzt ITU-T) und der Joint Photographic Experts Group zitiert wurden. Die wichtigste Grundlage für den verlustbehafteten JPEG-Komprimierungsalgorithmus ist die diskrete Kosinustransformation (DCT), die erstmals 1972 von Nasir Ahmed als Bildkomprimierungstechnik vorgeschlagen wurde. Ahmed entwickelte 1973 zusammen mit T. Natarajan von der Kansas State University und K. R. Rao von der University of Texas in Arlington einen praktischen DCT-Algorithmus. Ihre Arbeit von 1974 wird in der JPEG-Spezifikation zitiert, ebenso wie mehrere spätere Forschungsarbeiten, die sich mit DCT befassten, darunter eine Arbeit von Wen-Hsiung Chen, C.H. Smith und S.C. Fralick aus dem Jahr 1977, die einen schnellen DCT-Algorithmus beschrieb, sowie eine Arbeit von N.J. Narasinha und S.C. Fralick aus dem Jahr 1978 und eine Arbeit von B.G. Lee aus dem Jahr 1984. Die Spezifikation zitiert auch ein Papier von Wen-Hsiung Chen und W.K. Pratt aus dem Jahr 1984 als Einfluss auf den Quantisierungsalgorithmus und David A. Huffmans Papier aus dem Jahr 1952 für den Huffman-Kodierungsalgorithmus. ⓘ

In der JPEG-Spezifikation werden Patente mehrerer Unternehmen zitiert. Die folgenden Patente bildeten die Grundlage für den arithmetischen Kodierungsalgorithmus.

• IBM
  • U.S. Patent 4,652,856 - 4. Februar 1986 - Kottappuram M. A. Mohiuddin und Jorma J. Rissanen - Multiplikationsfreier arithmetischer Code mit mehreren Alphabeten
  • U.S. Patent 4,905,297 - 27. Februar 1990 - G. Langdon, J.L. Mitchell, W.B. Pennebaker und Jorma J. Rissanen - Arithmetisches Kodier- und Dekodiersystem
  • U.S. Patent 4,935,882 - 19. Juni 1990 - W.B. Pennebaker und J.L. Mitchell - Wahrscheinlichkeitsanpassung für arithmetische Kodierer
• Mitsubishi Electric
  • JP H02202267 (1021672) - 21. Januar 1989 - Toshihiro Kimura, Shigenori Kino, Fumitaka Ono, Masayuki Yoshida - Kodiersystem
  • JP H03247123 (2-46275) - 26. Februar 1990 - Fumitaka Ono, Tomohiro Kimura, Masayuki Yoshida und Shigenori Kino - Kodiergerät und Kodierverfahren ⓘ

In der JPEG-Spezifikation werden auch drei weitere Patente von IBM genannt. Andere Unternehmen, die als Patentinhaber genannt werden, sind AT&T (zwei Patente) und Canon Inc. Nicht in der Liste enthalten ist das US-Patent 4,698,672, das von Wen-Hsiung Chen und Daniel J. Klenke von Compression Labs im Oktober 1986 angemeldet wurde. Das Patent beschreibt einen DCT-basierten Bildkompressionsalgorithmus und war später im Jahr 2002 Anlass für eine Kontroverse (siehe Patentkontroverse unten). In der JPEG-Spezifikation wurden jedoch zwei frühere Forschungsarbeiten von Wen-Hsiung Chen zitiert, die 1977 und 1984 veröffentlicht wurden. ⓘ

JPEG-Norm

"JPEG" steht für Joint Photographic Experts Group, den Namen des Komitees, das den JPEG-Standard und auch andere Standards für die Kodierung von Standbildern entwickelt hat. Das "Joint" stand für ISO TC97 WG8 und CCITT SGVIII. Die 1986 gegründete Gruppe entwickelte den JPEG-Standard in den späten 1980er Jahren. Unter mehreren untersuchten Transformationskodierungstechniken wählte sie die diskrete Kosinustransformation (DCT) aus, da sie die bei weitem effizienteste praktische Kompressionstechnik war. Die Gruppe veröffentlichte den JPEG-Standard im Jahr 1992. ⓘ

1987 wurde aus dem ISO TC 97 das ISO/IEC JTC1 und 1992 wurde aus dem CCITT das ITU-T. Gegenwärtig ist JPEG auf Seiten des JTC1 eine von zwei Untergruppen des ISO/IEC Joint Technical Committee 1, Subcommittee 29, Working Group 1 (ISO/IEC JTC 1/SC 29/WG 1) - mit dem Titel Coding of still pictures. Auf Seiten der ITU-T ist die ITU-T SG16 das zuständige Gremium. Die ursprüngliche JPEG-Gruppe wurde 1986 gegründet und gab 1992 den ersten JPEG-Standard heraus, der im September 1992 als ITU-T-Empfehlung T.81 und 1994 als ISO/IEC 10918-1 angenommen wurde. ⓘ

Der JPEG-Standard spezifiziert den Codec, der festlegt, wie ein Bild in einen Strom von Bytes komprimiert und wieder in ein Bild dekomprimiert wird, aber nicht das Dateiformat, das diesen Strom enthält. Die Standards Exif und JFIF definieren die allgemein verwendeten Dateiformate für den Austausch von JPEG-komprimierten Bildern. ⓘ

Die JPEG-Normen tragen die offizielle Bezeichnung Informationstechnologie - Digitale Komprimierung und Kodierung von Standbildern mit kontinuierlichen Tönen. ISO/IEC 10918 besteht aus den folgenden Teilen:

Digitale Kompression und Kodierung von Halbton-Standbildern - Teile ⓘ

Teil	ISO/IEC-Norm	ITU-T Rec.	Datum der Erstveröffentlichung	Letzte Änderung	Titel	Beschreibung
Teil 1	ISO/IEC 10918-1:1994	T.81 (09/92)	18. September 1992		Anforderungen und Richtlinien
Teil 2	ISO/IEC 10918-2:1995	T.83 (11/94)	Nov 11, 1994		Prüfung der Konformität	Regeln und Prüfungen für die Konformität von Software (zu Teil 1).
Teil 3	ISO/IEC 10918-3:1997	T.84 (07/96)	3. Juli 1996	Apr 1, 1999	Erweiterungen	Eine Reihe von Erweiterungen zur Verbesserung des Teils 1, einschließlich des Still Picture Interchange File Format (SPIFF).
Teil 4	ISO/IEC 10918-4:1999	T.86 (06/98)	Jun 18, 1998	Jun 29, 2012	Registrierung von JPEG-Profilen, SPIFF-Profilen, SPIFF-Tags, SPIFF-Farbräumen, APPn-Markern, SPIFF-Kompressionsarten und Registrierungsstellen (REGAUT)	Methoden zur Registrierung einiger der Parameter, die zur Erweiterung von JPEG verwendet werden
Teil 5	ISO/IEC 10918-5:2013	T.871 (05/11)	14. Mai 2011		JPEG File Interchange Format (JFIF)	Ein weitverbreitetes Format, das sich de facto als Dateiformat für mit dem JPEG-Standard kodierte Bilder durchgesetzt hat. Im Jahr 2009 richtete der JPEG-Ausschuss eine Ad-hoc-Gruppe ein, um JFIF als JPEG Teil 5 zu standardisieren.
Teil 6	ISO/IEC 10918-6:2013	T.872 (06/12)	Juni 2012		Anwendung auf Drucksysteme	Spezifiziert eine Teilmenge von Merkmalen und Anwendungswerkzeugen für den Austausch von nach ISO/IEC 10918-1 kodierten Bildern für den Druck.
Teil 7	ISO/IEC 10918-7:2021	T.873 (06/21)	Mai 2019	Juni 2021	Referenz-Software	Bietet Referenzimplementierungen des JPEG-Kernkodierungssystems

Ecma International TR/98 spezifiziert das JPEG File Interchange Format (JFIF); die erste Ausgabe wurde im Juni 2009 veröffentlicht. ⓘ

Kontroverse um Patente

Im Jahr 2002 machte Forgent Networks geltend, dass es die Patentrechte an der JPEG-Technologie besitze und durchsetzen werde, die sich aus einem Patent ergeben, das am 27. Oktober 1986 eingereicht und am 6. Oktober 1987 erteilt worden war: U.S. Patent 4,698,672 von Wen-Hsiung Chen und Daniel J. Klenke von Compression Labs. Während Forgent zu diesem Zeitpunkt nicht Eigentümer von Compression Labs war, verkaufte Chen später Compression Labs an Forgent, bevor Chen zu Cisco wechselte. Dies führte dazu, dass Forgent die Eigentumsrechte an dem Patent erwarb. Die Ankündigung von Forgent im Jahr 2002 sorgte für einen Aufruhr, der an die Versuche von Unisys erinnerte, seine Rechte am GIF-Bildkompressionsstandard durchzusetzen. ⓘ

Der JPEG-Ausschuss untersuchte die Patentansprüche im Jahr 2002 und vertrat die Ansicht, dass sie durch den Stand der Technik ungültig seien, eine Ansicht, die von verschiedenen Experten geteilt wurde. Das Patent beschreibt einen Bildkomprimierungsalgorithmus, der auf der diskreten Kosinustransformation (DCT) basiert, einer verlustbehafteten Bildkomprimierungstechnik, die auf eine Arbeit von Nasir Ahmed, T. Natarajan und K. R. Rao aus dem Jahr 1974 zurückgeht. Wen-Hsiung Chen entwickelte ihr DCT-Verfahren weiter und beschrieb 1977 in einer Arbeit mit C.H. Smith und S.C. Fralick einen schnellen DCT-Algorithmus. Die JPEG-Spezifikation von 1992 zitiert sowohl das Ahmed-Papier von 1974 als auch das Chen-Papier von 1977 für seinen DCT-Algorithmus sowie ein Papier von Chen und W.K. Pratt von 1984 für seinen Quantisierungsalgorithmus. Als Chen 1986 zusammen mit Klenke sein Patent für einen DCT-basierten Bildkompressionsalgorithmus anmeldete, war das meiste von dem, was später zum JPEG-Standard werden sollte, bereits in früherer Literatur formuliert worden. Der JPEG-Vertreter Richard Clark behauptete auch, dass Chen selbst in einem der JPEG-Ausschüsse saß, doch Forgent bestritt diese Behauptung. ⓘ

Zwischen 2002 und 2004 konnte Forgent durch die Lizenzierung seines Patents an etwa 30 Unternehmen rund 105 Millionen US-Dollar einnehmen. Im April 2004 verklagte Forgent 31 weitere Unternehmen, um weitere Lizenzzahlungen zu erzwingen. Im Juli desselben Jahres reichte ein Konsortium von 21 großen Computerfirmen eine Gegenklage ein, mit dem Ziel, das Patent für ungültig zu erklären. Darüber hinaus reichte Microsoft im April 2005 eine separate Klage gegen Forgent ein. Im Februar 2006 stimmte das United States Patent and Trademark Office auf Antrag der Public Patent Foundation einer erneuten Prüfung des JPEG-Patents von Forgent zu. Am 26. Mai 2006 erklärte das USPTO das Patent aufgrund des Standes der Technik für ungültig. Das USPTO stellte außerdem fest, dass Forgent den Stand der Technik kannte, es aber absichtlich vermied, das Patentamt darüber zu informieren. Dies macht es sehr unwahrscheinlich, dass ein Einspruch zur Wiedereinsetzung des Patents Erfolg haben wird. ⓘ

Forgent verfügt auch über ein ähnliches Patent, das 1994 vom Europäischen Patentamt erteilt wurde, wobei unklar ist, wie durchsetzbar es ist. ⓘ

Mit Stand vom 27. Oktober 2006 scheint die 20-jährige Laufzeit des US-Patents abgelaufen zu sein, und im November 2006 erklärte sich Forgent bereit, auf die Durchsetzung von Patentansprüchen gegen die Verwendung des JPEG-Standards zu verzichten. ⓘ

Eines der ausdrücklichen Ziele des JPEG-Komitees ist es, dass seine Standards (insbesondere die Basismethoden) ohne die Zahlung von Lizenzgebühren implementiert werden können, und es hat sich entsprechende Lizenzrechte für seinen JPEG-2000-Standard von über 20 großen Organisationen gesichert. ⓘ

Seit August 2007 behauptet ein anderes Unternehmen, Global Patent Holdings, LLC, dass sein 1993 erteiltes Patent (U.S. Patent 5,253,341) durch das Herunterladen von JPEG-Bildern auf einer Website oder per E-Mail verletzt wird. Falls das Patent nicht für ungültig erklärt wird, könnte es für jede Website gelten, die JPEG-Bilder anzeigt. Das Patent wurde von 2000 bis 2007 vom US-Patent- und Markenamt erneut geprüft; im Juli 2007 widerrief das Patentamt alle ursprünglichen Ansprüche des Patents, befand aber einen von Global Patent Holdings vorgeschlagenen zusätzlichen Anspruch (Anspruch 17) für gültig. Global Patent Holdings reichte daraufhin eine Reihe von Klagen ein, die sich auf Anspruch 17 des Patents stützten. ⓘ

In den ersten beiden Klagen nach der erneuten Prüfung, die beide in Chicago, Illinois, eingereicht wurden, verklagte Global Patent Holdings die Green Bay Packers, CDW, Motorola, Apple, Orbitz, Officemax, Caterpillar, Kraft und Peapod als Beklagte. Eine dritte Klage wurde am 5. Dezember 2007 in Südflorida gegen ADT Security Services, AutoNation, Florida Crystals Corp., HearUSA, MovieTickets.com, Ocwen Financial Corp. und Tire Kingdom eingereicht, eine vierte Klage am 8. Januar 2008 in Südflorida gegen das Boca Raton Resort & Club. Eine fünfte Klage wurde gegen Global Patent Holdings in Nevada eingereicht. Diese Klage wurde von Zappos.com, Inc. eingereicht, das sich angeblich von Global Patent Holdings bedroht fühlte, und beantragte die gerichtliche Feststellung, dass das Patent '341 ungültig ist und nicht verletzt wird. ⓘ

Global Patent Holdings hatte das '341-Patent auch benutzt, um Kritiker breiter Softwarepatente zu verklagen oder zu bedrohen, darunter Gregory Aharonian und den anonymen Betreiber eines als "Patent Troll Tracker" bekannten Blogs. Am 21. Dezember 2007 beantragte der Patentanwalt Vernon Francissen aus Chicago beim US-Patent- und Markenamt eine erneute Prüfung des einzigen verbleibenden Anspruchs des Patents '341 auf der Grundlage eines neuen Stands der Technik. ⓘ

Am 5. März 2008 stimmte das US-Patent- und Markenamt einer erneuten Prüfung des Patents '341 zu und stellte fest, dass der neue Stand der Technik wesentliche neue Fragen hinsichtlich der Gültigkeit des Patents aufwirft. In Anbetracht der erneuten Prüfung haben die beschuldigten Verletzer in vier der fünf anhängigen Verfahren Anträge auf Aussetzung ihrer Verfahren bis zum Abschluss der Prüfung des Patents '341 durch das US-Patent- und Markenamt gestellt. Am 23. April 2008 hat ein Richter in Chicago, Illinois, der den Vorsitz über die beiden Klagen innehat, den Anträgen in diesen Fällen stattgegeben. Am 22. Juli 2008 erließ das Patentamt die erste "Office Action" der zweiten Überprüfung und erklärte den Anspruch aus neunzehn verschiedenen Gründen für ungültig. Am 24. November 2009 wurde eine Wiederholungsprüfungsbescheinigung ausgestellt, mit der alle Ansprüche aufgehoben wurden. ⓘ

Seit 2011 und seit Anfang 2013 verklagt ein Unternehmen namens Princeton Digital Image Corporation mit Sitz in Osttexas zahlreiche Unternehmen wegen angeblicher Verletzung des US-Patents 4.813.056. Princeton behauptet, dass der JPEG-Bildkomprimierungsstandard gegen das Patent '056 verstößt, und hat eine große Anzahl von Websites, Einzelhändlern, Kamera- und Geräteherstellern sowie Wiederverkäufern verklagt. Das Patent war ursprünglich im Besitz von General Electric und wurde an dieses Unternehmen übertragen. Das Patent ist im Dezember 2007 ausgelaufen, aber Princeton hat eine große Anzahl von Unternehmen wegen "früherer Verletzungen" dieses Patents verklagt. (Nach den US-Patentgesetzen kann ein Patentinhaber bis zu sechs Jahre vor Einreichung einer Klage auf "frühere Verletzung" klagen, so dass Princeton theoretisch bis Dezember 2013 weitere Unternehmen hätte verklagen können.) Im März 2013 waren bei Princeton in New York und Delaware Klagen gegen mehr als 55 Unternehmen anhängig. Die Beteiligung von General Electric an der Klage ist nicht bekannt, obwohl Gerichtsakten darauf hinweisen, dass das Unternehmen das Patent 2009 an Princeton abgetreten hat und bestimmte Rechte an dem Patent behält. ⓘ

Typische Anwendung

Der JPEG-Komprimierungsalgorithmus funktioniert am besten bei Fotos und Gemälden von realistischen Szenen mit sanften Tonwert- und Farbabstufungen. Für die Verwendung im Internet, wo die Verringerung der für ein Bild verwendeten Datenmenge für eine ansprechende Darstellung wichtig ist, ist JPEG aufgrund seiner Komprimierungsvorteile sehr beliebt. JPEG/Exif ist auch das gängigste Format, das von Digitalkameras gespeichert wird. ⓘ

JPEG eignet sich jedoch nicht gut für Strichzeichnungen und andere Text- oder Symbolgrafiken, bei denen die scharfen Kontraste zwischen benachbarten Pixeln merkliche Artefakte verursachen können. Solche Bilder werden besser in einem verlustfreien Grafikformat wie TIFF, GIF, PNG oder einem Rohbildformat gespeichert. Der JPEG-Standard enthält einen verlustfreien Kodierungsmodus, der jedoch von den meisten Produkten nicht unterstützt wird. ⓘ

Da JPEG in der Regel eine verlustbehaftete Komprimierungsmethode ist, die die Bildtreue verringert, ist es für die exakte Reproduktion von Bilddaten ungeeignet (z. B. für einige wissenschaftliche und medizinische Bildgebungsanwendungen und bestimmte technische Bildverarbeitungsarbeiten). ⓘ

JPEG eignet sich auch nicht für Dateien, die mehrfach bearbeitet werden, da bei jeder erneuten Komprimierung ein Teil der Bildqualität verloren geht, insbesondere wenn das Bild beschnitten oder verschoben wird oder wenn die Kodierungsparameter geändert werden - siehe Verlust bei der digitalen Erzeugung. Um den Verlust von Bildinformationen bei aufeinanderfolgenden und wiederholten Bearbeitungen zu vermeiden, kann die erste Bearbeitung in einem verlustfreien Format gespeichert, anschließend in diesem Format bearbeitet und schließlich als JPEG zur Verteilung veröffentlicht werden. ⓘ

JPEG-Komprimierung

JPEG verwendet eine verlustbehaftete Form der Kompression, die auf der diskreten Kosinustransformation (DCT) basiert. Diese mathematische Operation wandelt jedes Bild/Feld der Videoquelle aus dem räumlichen (2D) Bereich in den Frequenzbereich (auch bekannt als Transformationsbereich) um. Ein Wahrnehmungsmodell, das lose auf dem menschlichen psychovisuellen System basiert, verwirft hochfrequente Informationen, d. h. scharfe Übergänge in Intensität und Farbton. In der Transformationsdomäne wird der Prozess der Informationsreduzierung als Quantisierung bezeichnet. Vereinfacht ausgedrückt ist die Quantisierung eine Methode zur optimalen Reduzierung einer großen Zahlenskala (mit verschiedenen Vorkommen jeder Zahl) auf eine kleinere, und der Transformationsbereich ist eine geeignete Darstellung des Bildes, da die Hochfrequenzkoeffizienten, die weniger zum Gesamtbild beitragen als andere Koeffizienten, charakteristischerweise kleine Werte mit hoher Kompressibilität sind. Die quantisierten Koeffizienten werden dann in eine Reihenfolge gebracht und verlustfrei in den Ausgabe-Bitstrom gepackt. Fast alle Software-Implementierungen von JPEG erlauben die Steuerung des Kompressionsverhältnisses (sowie anderer optionaler Parameter) durch den Benutzer, so dass dieser die Bildqualität gegen eine geringere Dateigröße eintauschen kann. Bei eingebetteten Anwendungen (wie z. B. miniDV, das ein ähnliches DCT-Kompressionsschema verwendet) sind die Parameter für die Anwendung vorausgewählt und festgelegt. ⓘ

Die Komprimierungsmethode ist in der Regel verlustbehaftet, was bedeutet, dass einige ursprüngliche Bildinformationen verloren gehen und nicht wiederhergestellt werden können, was sich möglicherweise auf die Bildqualität auswirkt. Es gibt einen optionalen verlustfreien Modus, der im JPEG-Standard definiert ist. Dieser Modus wird jedoch von den meisten Produkten nicht unterstützt. ⓘ

Es gibt auch ein progressives JPEG-Format mit Zeilensprungverfahren, bei dem die Daten in mehreren Durchgängen mit zunehmend höherer Detailgenauigkeit komprimiert werden. Dies ist ideal für große Bilder, die während des Herunterladens über eine langsame Verbindung angezeigt werden, und ermöglicht eine angemessene Vorschau, nachdem nur ein Teil der Daten empfangen wurde. Die Unterstützung für progressive JPEGs ist jedoch nicht universell. Wenn progressive JPEGs von Programmen empfangen werden, die sie nicht unterstützen (z. B. Versionen des Internet Explorer vor Windows 7), zeigt die Software das Bild erst an, nachdem es vollständig heruntergeladen wurde. ⓘ

Es gibt auch viele medizinische Bildgebungs-, Verkehrs- und Kameraanwendungen, die 12-Bit-JPEG-Bilder sowohl in Graustufen als auch in Farbe erstellen und verarbeiten. Das 12-Bit-JPEG-Format ist in einem erweiterten Teil der JPEG-Spezifikation enthalten. Der libjpeg-Codec unterstützt 12-Bit-JPEG und es gibt sogar eine Hochleistungsversion. ⓘ

Verlustfreie Bearbeitung

Verschiedene Änderungen an einem JPEG-Bild können verlustfrei durchgeführt werden (d. h. ohne erneute Komprimierung und den damit verbundenen Qualitätsverlust), solange die Bildgröße ein Vielfaches von 1 MCU-Block (Minimum Coded Unit) ist (normalerweise 16 Pixel in beiden Richtungen, für 4:2:0 Chroma Subsampling). Zu den Dienstprogrammen, die dies implementieren, gehören:

• jpegtran und sein GUI, Jpegcrop.
• IrfanView mit "JPG Lossless Crop (PlugIn)" und "JPG Lossless Rotation (PlugIn)", die die Installation des Plugins JPG_TRANSFORM erfordern.
• FastStone Image Viewer mit "Verlustfreies Zuschneiden in Datei" und "Verlustfreies Drehen von JPEG".
• XnViewMP verwendet "JPEG verlustfreie Transformationen".
• ACDSee unterstützt das verlustfreie Drehen (aber nicht das verlustfreie Zuschneiden) mit der Option "Verlustfreie JPEG-Operationen erzwingen". ⓘ

Blöcke können in 90-Grad-Schritten gedreht, in den horizontalen, vertikalen und diagonalen Achsen gespiegelt und im Bild verschoben werden. Es müssen nicht alle Blöcke des Originalbildes im geänderten Bild verwendet werden. ⓘ

Der obere und der linke Rand eines JPEG-Bildes müssen auf einer 8 × 8 Pixel großen Blockgrenze liegen, der untere und der rechte Rand müssen dies nicht tun. Dies schränkt die möglichen verlustfreien Beschneidungsoperationen ein und verhindert auch das Spiegeln und Drehen eines Bildes, dessen unterer oder rechter Rand nicht auf einer Blockgrenze für alle Kanäle liegt (weil der Rand oben oder links landen würde, wo - wie oben erwähnt - eine Blockgrenze obligatorisch ist). ⓘ

Drehungen, bei denen das Bild nicht ein Vielfaches von 8 oder 16 ist, wobei dieser Wert von der Chroma-Unterabtastung abhängt, sind nicht verlustfrei. Beim Drehen eines solchen Bildes müssen die Blöcke neu berechnet werden, was zu Qualitätsverlusten führt. ⓘ

Wenn beim verlustfreien Zuschneiden die untere oder rechte Seite des Zuschneidebereichs nicht auf einer Blockgrenze liegt, sind die restlichen Daten der teilweise verwendeten Blöcke noch in der zugeschnittenen Datei vorhanden und können wiederhergestellt werden. Es ist auch möglich, ohne Qualitätsverlust zwischen Baseline- und Progressive-Formaten zu wechseln, da der einzige Unterschied in der Reihenfolge besteht, in der die Koeffizienten in der Datei platziert werden. ⓘ

Außerdem können mehrere JPEG-Bilder verlustfrei zusammengefügt werden, sofern sie mit der gleichen Qualität gespeichert wurden und die Kanten mit den Blockgrenzen übereinstimmen. ⓘ

Verluste beim wiederholten Rotieren und Speichern eines JPEG-Bildes mit „krummer“ Auflösung 1021 × 767 (nicht durch 16 teilbar).
Das wiederholte Rotieren von JPEG-Bildern mit durch 16 teilbarer Auflösung (z. B. 1024 × 768) bei Verwendung immer der gleichen Quantisierungsmatrix ist dagegen (bei ordnungsgemäßer Implementierung) verlustfrei. ⓘ

Obwohl eine Dekodierung und Rekodierung meist verlustbehaftet ist, lassen sich einige Bildmanipulationen (prinzipiell) ohne unerwünschte Datenverluste durchführen:

• Bilddrehungen um 90°, 180° und 270°
• horizontale und vertikale Bildspiegelungen
• Beschneiden von Rändern um Vielfache von 16 Pixeln (bzw. 8 Pixel bei Schwarzweißbildern oder Farbbildern ohne Unterabtastung) ⓘ

Dazu ist die Entropiekodierung und die Zickzack-Umsortierung rückgängig zu machen. Die Operationen erfolgen dann auf Grundlage der DCT-Koeffizienten (Umsortieren, Weglassen nicht benötigter Blöcke). Danach erfolgen wieder die Zickzack-Umsortierung und die Entropiekodierung. Es erfolgen keine verlustbehafteten Arbeitsschritte mehr. Nicht jedes Programm führt diese Operationen verlustfrei durch, es benötigt dazu spezielle dateiformatspezifische Verarbeitungsmodule. Bei den verbreiteten Bildbearbeitungsprogrammen ist das meist nicht der Fall, da diese in der Regel die Datei zunächst in ein Bitmuster dekodieren und dann mit diesen Daten arbeiten. ⓘ

Beispielsweise das für Windows und Linux verfügbare Konsolenprogramm jpegtran vermag es, alle diese Operationen verlustfrei auszuführen, ebenso das GUI-gestützte IrfanView für Windows. ⓘ

Bilder, deren Auflösung nicht ein Vielfaches von 16 Pixeln (bzw. 8 Pixel bei Schwarzweißbildern oder Farbbildern ohne Unterabtastung) beträgt, sind problematisch. Sie weisen unvollständige Blöcke auf, das heißt, Blöcke, die nicht alle synthetisierten Pixel verwenden. JPEG erlaubt solche Blöcke aber nur am rechten und am unteren Bildrand. Einige dieser Operationen verlangen daher einmalig, dass diese Randstreifen verworfen werden. ⓘ

JPEG-Dateien

Das als "JPEG Interchange Format" (JIF) bekannte Dateiformat ist in Anhang B der Norm festgelegt. Dieses "reine" Dateiformat wird jedoch nur selten verwendet, vor allem wegen der Schwierigkeit, Encoder und Decoder zu programmieren, die alle Aspekte der Norm vollständig umsetzen, und wegen bestimmter Mängel der Norm:

• Definition des Farbraums
• Registrierung der Komponentenunterabtastung
• Definition des Pixel-Seitenverhältnisses. ⓘ

Es wurden mehrere zusätzliche Normen entwickelt, um diese Probleme zu lösen. Der erste dieser Standards, der 1992 veröffentlicht wurde, war das JPEG File Interchange Format (oder JFIF), dem in den letzten Jahren das Exchangeable Image File Format (Exif) und ICC-Farbprofile folgten. Beide Formate verwenden das eigentliche JIF-Byte-Layout, das aus verschiedenen Markern besteht, aber zusätzlich einen der Erweiterungspunkte des JIF-Standards verwenden, nämlich die Anwendungsmarker: JFIF verwendet APP0, während Exif APP1 verwendet. Innerhalb dieser Dateisegmente, die im JIF-Standard für eine spätere Verwendung vorgesehen sind und nicht von ihm gelesen werden, fügen diese Standards spezifische Metadaten hinzu. ⓘ

So ist JFIF in gewisser Hinsicht eine abgespeckte Version des JIF-Standards, da es bestimmte Einschränkungen festlegt (z. B. dass nicht alle verschiedenen Kodierungsmodi zulässig sind), während es in anderer Hinsicht aufgrund der hinzugefügten Metadaten eine Erweiterung von JIF ist. In der Dokumentation für den ursprünglichen JFIF-Standard heißt es:

JPEG File Interchange Format ist ein minimales Dateiformat, das den Austausch von JPEG-Bitstreams zwischen einer Vielzahl von Plattformen und Anwendungen ermöglicht. Dieses Minimalformat enthält keine der fortgeschrittenen Funktionen, die in der TIFF-JPEG-Spezifikation oder einem anwendungsspezifischen Dateiformat enthalten sind. Das sollte es auch nicht, denn der einzige Zweck dieses vereinfachten Formats ist es, den Austausch von JPEG-komprimierten Bildern zu ermöglichen. ⓘ

Bilddateien, die JPEG-Kompression verwenden, werden allgemein als "JPEG-Dateien" bezeichnet und in Varianten des JIF-Bildformats gespeichert. Die meisten Bilderfassungsgeräte (z. B. Digitalkameras), die JPEG-Dateien ausgeben, erstellen Dateien im Exif-Format, dem Format, das die Kamerabranche für den Austausch von Metadaten standardisiert hat. Da der Exif-Standard jedoch keine Farbprofile zulässt, speichert die meiste Bildbearbeitungssoftware JPEG im JFIF-Format und fügt das APP1-Segment aus der Exif-Datei hinzu, um die Metadaten auf eine fast konforme Weise einzuschließen; der JFIF-Standard wird etwas flexibel interpretiert. ⓘ

Der JFIF-Standard wird etwas flexibel interpretiert. Streng genommen sind die Standards JFIF und Exif inkompatibel, da jeder Standard vorschreibt, dass sein Markersegment (APP0 bzw. APP1) zuerst erscheint. In der Praxis enthalten die meisten JPEG-Dateien ein JFIF-Markierungssegment, das dem Exif-Header vorausgeht. Dies ermöglicht es älteren Lesegeräten, das JFIF-Segment des älteren Formats korrekt zu verarbeiten, während neuere Lesegeräte auch das folgende Exif-Segment dekodieren, wobei sie weniger streng darauf achten, dass es als erstes erscheint. ⓘ

JPEG-Dateinamenerweiterungen

Die gängigsten Dateinamenerweiterungen für Dateien mit JPEG-Kompression sind .jpg und .jpeg, aber auch .jpe, .jfif und .jif werden verwendet. JPEG-Daten können auch in andere Dateitypen eingebettet werden: TIFF-kodierte Dateien enthalten oft ein JPEG-Bild als Miniaturansicht des Hauptbildes, und MP3-Dateien können ein JPEG-Cover im ID3v2-Tag enthalten. ⓘ

Farbprofil

In viele JPEG-Dateien ist ein ICC-Farbprofil (Farbraum) eingebettet. Zu den häufig verwendeten Farbprofilen gehören sRGB und Adobe RGB. Da diese Farbräume eine nichtlineare Transformation verwenden, beträgt der Dynamikbereich einer 8-Bit-JPEG-Datei etwa 11 Blendenstufen; siehe Gammakurve. ⓘ

Wenn das Bild keine Farbprofilinformationen enthält (untagged), wird der Farbraum für die Anzeige auf Webseiten als sRGB angenommen. ⓘ

Syntax und Struktur

Ein JPEG-Bild besteht aus einer Abfolge von Segmenten, die jeweils mit einer Markierung beginnen, wobei jedes Segment mit einem 0xFF-Byte beginnt, gefolgt von einem Byte, das angibt, um welche Art von Markierung es sich handelt. Einige Marker bestehen nur aus diesen beiden Bytes, andere werden von zwei Bytes gefolgt (erst hoch, dann niedrig), die die Länge der markerspezifischen Nutzdaten angeben, die folgen. (Die Länge umfasst die zwei Bytes für die Länge, aber nicht die zwei Bytes für die Markierung.) Auf einige Markierungen folgen entropiekodierte Daten; die Länge einer solchen Markierung schließt die entropiekodierten Daten nicht ein. Beachten Sie, dass aufeinanderfolgende 0xFF-Bytes als Füllbytes zum Auffüllen verwendet werden, obwohl dieses Auffüllen von Füllbytes nur für Marker erfolgen sollte, die unmittelbar auf entropiekodierte Scandaten folgen (siehe JPEG-Spezifikation Abschnitt B.1.1.2 und E.1.2 für Details; insbesondere "In allen Fällen, in denen Marker nach den komprimierten Daten angehängt werden, können optionale 0xFF-Füllbytes dem Marker vorausgehen"). ⓘ

Innerhalb der entropiekodierten Daten wird nach jedem 0xFF-Byte ein 0x00-Byte vom Encoder vor dem nächsten Byte eingefügt, damit es nicht den Anschein hat, dass eine Markierung vorhanden ist, wo keine vorgesehen ist, um Framing-Fehler zu vermeiden. Decoder müssen dieses 0x00-Byte auslassen. Diese Technik, Byte Stuffing genannt (siehe JPEG-Spezifikation, Abschnitt F.1.2.3), wird nur auf die entropiekodierten Daten angewandt, nicht auf die Marker-Nutzdaten. Beachten Sie jedoch, dass entropiekodierte Daten einige eigene Marker haben; insbesondere die Reset-Marker (0xD0 bis 0xD7), die dazu dienen, unabhängige Teile entropiekodierter Daten zu isolieren, um eine parallele Dekodierung zu ermöglichen, und es steht den Kodierern frei, diese Reset-Marker in regelmäßigen Abständen einzufügen (obwohl nicht alle Kodierer dies tun). ⓘ

Gemeinsame JPEG-Markierungen

Kurzer Name	Bytes	Nutzdaten	Bezeichnung	Kommentare ⓘ
SOI	0xFF, 0xD8	keine	Start des Bildes
SOF0	0xFF, 0xC0	variable Größe	Bildanfang (Grundlinien-DCT)	Zeigt an, dass es sich um ein Baseline-DCT-basiertes JPEG handelt, und gibt die Breite, Höhe, Anzahl der Komponenten und die Unterabtastung der Komponenten (z. B. 4:2:0) an.
SOF2	0xFF, 0xC2	variable Größe	Bildanfang (progressive DCT)	Zeigt an, dass es sich um ein progressives DCT-basiertes JPEG handelt, und gibt die Breite, Höhe, Anzahl der Komponenten und die Komponentenunterabtastung (z. B. 4:2:0) an.
DHT	0xFF, 0xC4	variable Größe	Huffman-Tabelle(n) definieren	Legt eine oder mehrere Huffman-Tabellen fest.
DQT	0xFF, 0xDB	variable Größe	Quantisierungstabelle(n) definieren	Legt eine oder mehrere Quantisierungstabellen fest.
DRI	0xFF, 0xDD	4 Bytes	Wiederanlaufintervall definieren	Legt das Intervall zwischen den RSTn-Markern in Minimum Coded Units (MCUs) fest. Auf diese Markierung folgen zwei Bytes, die die feste Größe angeben, so dass sie wie jedes andere Segment mit variabler Größe behandelt werden kann.
SOS	0xFF, 0xDA	variable Größe	Beginn der Abtastung	Beginnt eine Abtastung des Bildes von oben nach unten. Bei DCT-JPEG-Basisbildern gibt es in der Regel einen einzigen Scan. Progressive DCT-JPEG-Bilder enthalten in der Regel mehrere Abtastungen. Diese Markierung gibt an, welche Datenscheibe sie enthalten wird, und wird unmittelbar von entropiekodierten Daten gefolgt.
RSTn	0xFF, 0xDn (n=0..7)	keine	Neustart	Wird alle r Makroblöcke eingefügt, wobei r das durch einen DRI-Marker festgelegte Neustart-Intervall ist. Nicht verwendet, wenn kein DRI-Marker vorhanden war. Die unteren drei Bits des Markierungscodes durchlaufen einen Wertzyklus von 0 bis 7.
APPn	0xFF, 0xEn	variable Größe	Anwendungsspezifisch	Eine Exif-JPEG-Datei verwendet beispielsweise eine APP1-Markierung, um Metadaten zu speichern, die in einer Struktur angelegt sind, die sich eng an TIFF anlehnt.
COM	0xFF, 0xFE	variable Größe	Kommentar	Enthält einen Textkommentar.
EOI	0xFF, 0xD9	keine	Ende des Bildes

Es gibt weitere "Start Of Frame"-Marker, die andere Arten von JPEG-Kodierungen einleiten. ⓘ

Da mehrere Hersteller denselben APPn-Marker-Typ verwenden können, beginnen anwendungsspezifische Marker oft mit einem Standard- oder Herstellernamen (z. B. "Exif" oder "Adobe") oder einer anderen identifizierenden Zeichenfolge. ⓘ

Bei einer Neustartmarke werden die Block-zu-Block-Prädiktorvariablen zurückgesetzt und der Bitstrom wird auf eine Bytegrenze synchronisiert. Neustart-Marken ermöglichen die Wiederherstellung nach Bitstream-Fehlern, z. B. bei der Übertragung über ein unzuverlässiges Netzwerk oder bei Dateibeschädigungen. Da die Makroblöcke zwischen den Neustartmarkierungen unabhängig voneinander dekodiert werden können, ist eine parallele Dekodierung dieser Blöcke möglich. ⓘ

Beispiel für einen JPEG-Codec

Obwohl eine JPEG-Datei auf verschiedene Weise kodiert werden kann, wird sie in den meisten Fällen mit JFIF kodiert. Der Kodierungsprozess besteht aus mehreren Schritten:

1. Die Darstellung der Farben im Bild wird von RGB in Y′CBC_R umgewandelt, bestehend aus einer Luma-Komponente (Y'), die die Helligkeit darstellt, und zwei Chroma-Komponenten (CB und C_R), die die Farbe darstellen. Dieser Schritt wird manchmal übersprungen.
2. Die Auflösung der Chroma-Daten wird verringert, in der Regel um den Faktor 2 oder 3. Damit wird der Tatsache Rechnung getragen, dass das Auge für feine Farbdetails weniger empfindlich ist als für feine Helligkeitsdetails.
3. Das Bild wird in Blöcke von 8×8 Pixeln aufgeteilt, und für jeden Block werden die Y-, CB- und C_R-Daten einer diskreten Kosinustransformation (DCT) unterzogen. Eine DCT ähnelt einer Fourier-Transformation in dem Sinne, dass sie eine Art räumliches Frequenzspektrum erzeugt.
4. Die Amplituden der Frequenzkomponenten werden quantisiert. Das menschliche Sehvermögen reagiert viel empfindlicher auf kleine Farb- oder Helligkeitsschwankungen über große Flächen als auf die Stärke hochfrequenter Helligkeitsschwankungen. Daher werden die Amplituden der hochfrequenten Komponenten mit einer geringeren Genauigkeit gespeichert als die der niederfrequenten Komponenten. Die Qualitätseinstellung des Encoders (z. B. 50 oder 95 auf einer Skala von 0-100 in der Bibliothek der Independent JPEG Group) wirkt sich darauf aus, inwieweit die Auflösung der einzelnen Frequenzkomponenten reduziert wird. Wird eine zu niedrige Qualitätseinstellung verwendet, werden die hochfrequenten Komponenten gänzlich verworfen.
5. Die resultierenden Daten für alle 8×8 Blöcke werden mit einem verlustfreien Algorithmus, einer Variante der Huffman-Kodierung, weiter komprimiert.

Bei der Dekodierung werden diese Schritte rückgängig gemacht, mit Ausnahme der Quantisierung, da diese nicht umkehrbar ist. Im weiteren Verlauf dieses Abschnitts werden die Kodierungs- und Dekodierungsverfahren genauer beschrieben. ⓘ

Kodierung

Viele der Optionen im JPEG-Standard werden nicht häufig verwendet, und wie bereits erwähnt, verwendet die meiste Bildsoftware bei der Erstellung einer JPEG-Datei das einfachere JFIF-Format, in dem u. a. die Kodierungsmethode angegeben ist. Es folgt eine kurze Beschreibung einer der gebräuchlicheren Kodierungsmethoden, wenn sie auf eine Eingabe mit 24 Bits pro Pixel (jeweils acht Bits für Rot, Grün und Blau) angewendet wird. Bei dieser speziellen Option handelt es sich um eine verlustbehaftete Datenkomprimierungsmethode. ⓘ

Farbraumtransformation

Zunächst sollte das Bild von RGB (standardmäßig sRGB, aber auch andere Farbräume sind möglich) in einen anderen Farbraum namens Y′CBCR (oder informell YCbCr) umgewandelt werden. Er besteht aus den drei Komponenten Y', CB und CR: Die Y'-Komponente steht für die Helligkeit eines Pixels, die CB- und CR-Komponenten für die Chrominanz (aufgeteilt in Blau- und Rotanteile). Dies ist im Grunde derselbe Farbraum, der auch beim digitalen Farbfernsehen und bei digitalen Videos, einschließlich Video-DVDs, verwendet wird. Die Konvertierung in den Y′CBCR-Farbraum ermöglicht eine stärkere Komprimierung ohne nennenswerte Auswirkungen auf die wahrnehmbare Bildqualität (oder eine höhere wahrnehmbare Bildqualität bei gleicher Komprimierung). Die Komprimierung ist effizienter, weil die Helligkeitsinformationen, die für die letztendliche Wahrnehmungsqualität des Bildes wichtiger sind, auf einen einzigen Kanal beschränkt sind. Dies entspricht eher der Farbwahrnehmung im menschlichen Sehsystem. Die Farbtransformation verbessert auch die Kompression durch statistische Dekorrelation. ⓘ

Im JFIF-Standard ist eine bestimmte Umwandlung in Y′CBCR vorgeschrieben, die durchgeführt werden sollte, damit die resultierende JPEG-Datei möglichst kompatibel ist. Einige JPEG-Implementierungen im Modus "höchste Qualität" verzichten jedoch auf diesen Schritt und behalten stattdessen die Farbinformationen im RGB-Farbmodell bei, bei dem das Bild in separaten Kanälen für die roten, grünen und blauen Helligkeitskomponenten gespeichert wird. Dies führt zu einer weniger effizienten Komprimierung und wird wahrscheinlich nicht verwendet, wenn die Dateigröße besonders wichtig ist. ⓘ

Downsampling

Aufgrund der Dichte der farb- und helligkeitsempfindlichen Rezeptoren im menschlichen Auge kann der Mensch in der Helligkeit eines Bildes (der Y'-Komponente) wesentlich mehr feine Details erkennen als in Farbton und Farbsättigung eines Bildes (den Cb- und Cr-Komponenten). Mit diesem Wissen können Encoder entwickelt werden, um Bilder effizienter zu komprimieren. ⓘ

Die Umwandlung in das Y′CBCR-Farbmodell ermöglicht den nächsten üblichen Schritt, nämlich die Verringerung der räumlichen Auflösung der Cb- und Cr-Komponenten (als "Downsampling" oder "Chroma Subsampling" bezeichnet). Die Verhältnisse, in denen das Downsampling bei JPEG-Bildern üblicherweise durchgeführt wird, sind 4:4:4 (kein Downsampling), 4:2:2 (Reduzierung um den Faktor 2 in horizontaler Richtung) oder (am häufigsten) 4:2:0 (Reduzierung um den Faktor 2 sowohl in horizontaler als auch in vertikaler Richtung). Für den Rest des Komprimierungsprozesses werden Y', Cb und Cr getrennt und auf sehr ähnliche Weise verarbeitet. ⓘ

Die Farbabweichungssignale Cb und Cr werden meist in reduzierter Auflösung gespeichert. Dazu werden sie tiefpassgefiltert und unterabgetastet (im einfachsten Fall durch eine Mittelwertbildung). ⓘ

Meist wird eine vertikale und horizontale Unterabtastung jeweils um den Faktor 2 verwendet (YCbCr 4:2:0), die die Datenmenge um den Faktor 4 reduziert. Bei dieser Umwandlung wird die Tatsache ausgenutzt, dass die Ortsauflösung des menschlichen Auges für Farben deutlich geringer ist als für Helligkeitsübergänge. ⓘ

Blocksplitting

Nach der Unterabtastung muss jeder Kanal in 8×8 Blöcke aufgeteilt werden. Je nach Chroma-Subsampling ergibt dies Minimum Coded Unit (MCU)-Blöcke der Größe 8×8 (4:4:4 - kein Subsampling), 16×8 (4:2:2) oder, am häufigsten, 16×16 (4:2:0). Bei der Videokompression werden MCUs als Makroblöcke bezeichnet. ⓘ

Wenn die Daten für einen Kanal keine ganzzahlige Anzahl von Blöcken darstellen, muss der Encoder den verbleibenden Bereich der unvollständigen Blöcke mit einer Art von Dummy-Daten füllen. Das Füllen der Ränder mit einer festen Farbe (z. B. Schwarz) kann zu Ringing-Artefakten entlang des sichtbaren Teils des Randes führen; Die Wiederholung der Randpixel ist eine gängige Technik, die solche Artefakte reduziert (aber nicht unbedingt beseitigt), und es können auch anspruchsvollere Randfülltechniken angewendet werden. ⓘ

Diskrete Kosinustransformation

Das 8×8-Teilbild, dargestellt in 8-Bit-Graustufen ⓘ

Als nächstes wird jeder 8×8-Block jeder Komponente (Y, Cb, Cr) in eine Darstellung im Frequenzbereich umgewandelt, wobei eine normalisierte, zweidimensionale diskrete Kosinustransformation (DCT) vom Typ II verwendet wird (siehe Zitat 1 in Diskrete Kosinustransformation). Die DCT wird manchmal als "Typ-II-DCT" im Zusammenhang mit einer Familie von Transformationen wie der diskreten Kosinustransformation bezeichnet, und die entsprechende Umkehrung (IDCT) wird als "Typ-III-DCT" bezeichnet. ⓘ

Ein Beispiel für ein solches 8×8 8-Bit-Teilbild könnte sein:

$\left[{\begin{array}{rrrrrrrr}52&55&61&66&70&61&64&73\\63&59&55&90&109&85&69&72\\62&59&68&113&144&104&66&73\\63&58&71&122&154&106&70&69\\67&61&68&104&126&88&68&70\\79&65&60&70&77&68&58&75\\85&71&64&59&55&61&65&83\\87&79&69&68&65&76&78&94\end{array}}\right].$ ⓘ

Vor der Berechnung der DCT des 8×8-Blocks werden seine Werte von einem positiven Bereich zu einem auf Null zentrierten Wert verschoben. Bei einem 8-Bit-Bild fällt jeder Eintrag im Originalblock in den Bereich $[0,255]$. Der Mittelpunkt des Bereichs (in diesem Fall der Wert 128) wird von jedem Eintrag subtrahiert, um einen Datenbereich zu erzeugen, der auf Null zentriert ist, so dass der modifizierte Bereich $[-128,127]$. Dieser Schritt verringert die Anforderungen an den dynamischen Bereich in der nachfolgenden DCT-Verarbeitungsstufe. ⓘ

Dieser Schritt führt zu den folgenden Werten:

$g={\begin{array}{c}x\\\longrightarrow \\\left[{\begin{array}{rrrrrrrr}-76&-73&-67&-62&-58&-67&-64&-55\\-65&-69&-73&-38&-19&-43&-59&-56\\-66&-69&-60&-15&16&-24&-62&-55\\-65&-70&-57&-6&26&-22&-58&-59\\-61&-67&-60&-24&-2&-40&-60&-58\\-49&-63&-68&-58&-51&-60&-70&-53\\-43&-57&-64&-69&-73&-67&-63&-45\\-41&-49&-59&-60&-63&-52&-50&-34\end{array}}\right]\end{array}}{\Bigg \downarrow }y.$ ⓘ

Die DCT transformiert einen 8×8-Block von Eingangswerten in eine lineare Kombination dieser 64 Muster. Die Muster werden als zweidimensionale DCT-Basisfunktionen bezeichnet, und die Ausgangswerte werden als Transformationskoeffizienten bezeichnet. Der horizontale Index ist $u$ und der vertikale Index ist $v$. ⓘ

Der nächste Schritt besteht darin, die zweidimensionale DCT zu berechnen, die wie folgt lautet

$\ G_{u,v}={\frac {1}{4}}\alpha (u)\alpha (v)\sum _{x=0}^{7}\sum _{y=0}^{7}g_{x,y}\cos \left[{\frac {(2x+1)u\pi }{16}}\right]\cos \left[{\frac {(2y+1)v\pi }{16}}\right]$ ⓘ

wobei

• $\ u$ die horizontale Ortsfrequenz ist, für die ganzen Zahlen $\ 0\leq u<8$.
• $\ v$ die vertikale Ortsfrequenz, für die ganzen Zahlen $\ 0\leq v<8$.
• $\alpha (u)={\begin{cases}{\frac {1}{\sqrt {2}}},&{\mbox{if }}u=0\\1,&{\mbox{otherwise}}\end{cases}}$ ein normalisierender Skalierungsfaktor ist, um die Transformation orthonormal zu machen
• $\ g_{x,y}$ der Pixelwert an den Koordinaten ist $\ (x,y)$
• $\ G_{u,v}$ der DCT-Koeffizient an den Koordinaten ist $\ (u,v).$ ⓘ

Wenn wir diese Transformation auf unsere obige Matrix anwenden, erhalten wir das folgende Ergebnis (gerundet auf die nächsten zwei Stellen hinter dem Komma):

$G={\begin{array}{c}u\\\longrightarrow \\\left[{\begin{array}{rrrrrrrr}-415.38&-30.19&-61.20&27.24&56.12&-20.10&-2.39&0.46\\4.47&-21.86&-60.76&10.25&13.15&-7.09&-8.54&4.88\\-46.83&7.37&77.13&-24.56&-28.91&9.93&5.42&-5.65\\-48.53&12.07&34.10&-14.76&-10.24&6.30&1.83&1.95\\12.12&-6.55&-13.20&-3.95&-1.87&1.75&-2.79&3.14\\-7.73&2.91&2.38&-5.94&-2.38&0.94&4.30&1.85\\-1.03&0.18&0.42&-2.42&-0.88&-3.02&4.12&-0.66\\-0.17&0.14&-1.07&-4.19&-1.17&-0.10&0.50&1.68\end{array}}\right]\end{array}}{\Bigg \downarrow }v.$ ⓘ

Man beachte den Eintrag in der linken oberen Ecke mit dem ziemlich großen Betrag. Dies ist der Gleichstromkoeffizient (auch konstante Komponente genannt), der den Grundfarbton für den gesamten Block definiert. Die restlichen 63 Koeffizienten sind die AC-Koeffizienten (auch alternierende Komponenten genannt). Der Vorteil der DCT ist ihre Tendenz, den größten Teil des Signals in einer Ecke des Ergebnisses zusammenzufassen, wie oben zu sehen ist. Der nachfolgende Quantisierungsschritt verstärkt diesen Effekt und verringert gleichzeitig die Gesamtgröße der DCT-Koeffizienten, was zu einem Signal führt, das sich in der Entropiestufe leicht effizient komprimieren lässt. ⓘ

Die DCT erhöht vorübergehend die Bittiefe der Daten, da die DCT-Koeffizienten eines 8-Bit/Komponenten-Bildes bis zu 11 oder mehr Bits (je nach Genauigkeit der DCT-Berechnung) zum Speichern benötigen. Dies kann den Codec zwingen, vorübergehend 16-Bit-Zahlen zu verwenden, um diese Koeffizienten zu speichern, wodurch sich die Größe der Bilddarstellung an dieser Stelle verdoppelt; diese Werte werden normalerweise durch den Quantisierungsschritt wieder auf 8-Bit-Werte reduziert. Die vorübergehende Vergrößerung in dieser Phase stellt für die meisten JPEG-Implementierungen kein Leistungsproblem dar, da in der Regel nur ein sehr kleiner Teil des Bildes zu einem bestimmten Zeitpunkt während der Bildkodierung oder -dekodierung in vollständiger DCT-Form gespeichert wird. ⓘ

Zur DCT existiert die inverse Transformation, die IDCT:

$f_{xy}={1 \over 4}\sum _{m=0}^{7}\sum _{n=0}^{7}C_{m}C_{n}F_{mn}\cos \left[{\frac {(2x+1)m\pi }{16}}\right]\cos \left[{\frac {(2y+1)n\pi }{16}}\right]$ ⓘ

mit den gleichen Korrekturfaktoren $C_{k}$ wie bei der DCT. ⓘ

Quantisierung

Das menschliche Auge ist gut darin, kleine Helligkeitsunterschiede über einen relativ großen Bereich zu erkennen, aber nicht so gut darin, die genaue Stärke einer hochfrequenten Helligkeitsänderung zu unterscheiden. So kann man die Informationsmenge in den Hochfrequenzkomponenten stark reduzieren. Dazu wird einfach jede Komponente im Frequenzbereich durch eine Konstante für diese Komponente geteilt und dann auf die nächste ganze Zahl gerundet. Dieser Rundungsvorgang ist der einzige verlustbehaftete Vorgang im gesamten Prozess (abgesehen von der Chroma-Unterabtastung), wenn die DCT-Berechnung mit ausreichend hoher Präzision durchgeführt wird. Infolgedessen werden in der Regel viele der höheren Frequenzkomponenten auf Null gerundet, und viele der übrigen werden zu kleinen positiven oder negativen Zahlen, für deren Darstellung viel weniger Bits benötigt werden. ⓘ

Die Elemente in der Quantisierungsmatrix steuern das Kompressionsverhältnis, wobei größere Werte eine stärkere Kompression bewirken. Eine typische Quantisierungsmatrix (für eine Qualität von 50 %, wie im ursprünglichen JPEG-Standard festgelegt) sieht wie folgt aus:

$Q={\begin{bmatrix}16&11&10&16&24&40&51&61\\12&12&14&19&26&58&60&55\\14&13&16&24&40&57&69&56\\14&17&22&29&51&87&80&62\\18&22&37&56&68&109&103&77\\24&35&55&64&81&104&113&92\\49&64&78&87&103&121&120&101\\72&92&95&98&112&100&103&99\end{bmatrix}}.$ ⓘ

Die quantisierten DCT-Koeffizienten werden berechnet mit ⓘ

$B_{j,k}=\mathrm {round} \left({\frac {G_{j,k}}{Q_{j,k}}}\right){\mbox{ for }}j=0,1,2,\ldots ,7;k=0,1,2,\ldots ,7$ ⓘ

wobei $G$ sind die nicht quantisierten DCT-Koeffizienten; $Q$ ist die obige Quantisierungsmatrix; und $B$ sind die quantisierten DCT-Koeffizienten. ⓘ

Die Verwendung dieser Quantisierungsmatrix mit der DCT-Koeffizientenmatrix von oben ergibt:

Links: ein endgültiges Bild wird aus einer Reihe von Basisfunktionen aufgebaut. Rechts: jede der DCT-Basisfunktionen, aus denen das Bild besteht, und der entsprechende Gewichtungskoeffizient. Mitte: die Basisfunktion nach der Multiplikation mit dem Koeffizienten: diese Komponente wird dem endgültigen Bild hinzugefügt. Zur Verdeutlichung wird der 8×8-Makroblock in diesem Beispiel durch bilineare Interpolation um das 10-fache vergrößert. ⓘ

$B=\left[{\begin{array}{rrrrrrrr}-26&-3&-6&2&2&-1&0&0\\0&-2&-4&1&1&0&0&0\\-3&1&5&-1&-1&0&0&0\\-3&1&2&-1&0&0&0&0\\1&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\end{array}}\right].$ ⓘ

Beispiel: Verwendung von -415 (dem DC-Koeffizienten) und Aufrundung auf die nächste ganze Zahl ⓘ

$\mathrm {round} \left({\frac {-415.37}{16}}\right)=\mathrm {round} \left(-25.96\right)=-26.$ ⓘ

Beachten Sie, dass die meisten Elemente mit höheren Frequenzen des Teilblocks (d. h. diejenigen mit einer x- oder y-Raumfrequenz von mehr als 4) zu Nullwerten quantisiert werden. ⓘ

Entropie-Kodierung

Zickzack-Anordnung der JPEG-Bildkomponenten ⓘ

Die Entropiekodierung ist eine besondere Form der verlustfreien Datenkompression. Dabei werden die Bildkomponenten in einer "Zickzack"-Reihenfolge angeordnet, wobei ein Lauflängenkodierungsalgorithmus (RLE) verwendet wird, der ähnliche Frequenzen zusammenfasst, Nullen für die Längenkodierung einfügt und dann eine Huffman-Kodierung für den verbleibenden Teil verwendet. ⓘ

Der JPEG-Standard erlaubt auch die Verwendung der arithmetischen Kodierung, die der Huffman-Kodierung mathematisch überlegen ist, verlangt aber nicht, dass die Decoder diese unterstützen. Diese Funktion wurde jedoch nur selten genutzt, da sie in der Vergangenheit durch Patente geschützt war, die lizenzpflichtig waren, und weil sie im Vergleich zur Huffman-Kodierung langsamer zu kodieren und zu dekodieren ist. Durch die arithmetische Kodierung werden die Dateien in der Regel um etwa 5-7 % kleiner. ⓘ

Der vorherige quantisierte DC-Koeffizient wird verwendet, um den aktuellen quantisierten DC-Koeffizienten vorherzusagen. Die Differenz zwischen den beiden wird kodiert und nicht der tatsächliche Wert. Bei der Kodierung der 63 quantisierten AC-Koeffizienten wird eine solche Vorhersagedifferenzierung nicht verwendet. ⓘ

Die Zickzack-Sequenz für die oben genannten quantisierten Koeffizienten ist unten dargestellt. (Das dargestellte Format dient nur dem besseren Verständnis/der besseren Übersicht). ⓘ

-26
-3	0
-3	-2	-6
2	-4	1	-3
1	1	5	1	2
-1	1	-1	2	0	0
0	0	0	-1	-1	0	0
0	0	0	0	0	0	0	0
0	0	0	0	0	0	0
0	0	0	0	0	0
0	0	0	0	0
0	0	0	0
0	0	0
0	0
0

ⓘ

Wenn der i-te Block dargestellt wird durch $B_{i}$ und die Positionen innerhalb jedes Blocks werden durch $(p,q)$ wobei $p=0,1,...,7$ und $q=0,1,...,7$dargestellt, dann kann jeder Koeffizient im DCT-Bild wie folgt dargestellt werden $B_{i}(p,q)$. Im obigen Schema ist die Reihenfolge der kodierten Pixel (für den i-ten Block) also $B_{i}(0,0)$, $B_{i}(0,1)$, $B_{i}(1,0)$, $B_{i}(2,0)$, $B_{i}(1,1)$, $B_{i}(0,2)$, $B_{i}(0,3)$, $B_{i}(1,2)$ und so weiter. ⓘ

Sequenzielle JPEG-Kodierung und -Dekodierung auf der Basislinie ⓘ

Dieser Kodierungsmodus wird als Baseline-Sequential-Kodierung bezeichnet. Baseline JPEG unterstützt auch die progressive Kodierung. Während bei der sequentiellen Kodierung die Koeffizienten eines einzelnen Blocks auf einmal (im Zickzack) kodiert werden, werden bei der progressiven Kodierung ähnlich positionierte Stapel von Koeffizienten aller Blöcke in einem Durchgang (Scan genannt) kodiert, gefolgt vom nächsten Stapel von Koeffizienten aller Blöcke und so weiter. Wenn das Bild zum Beispiel in N 8×8 Blöcke unterteilt ist $B_{0},B_{1},B_{2},...,B_{n-1}$unterteilt ist, dann kodiert eine progressive 3-Scan-Kodierung die DC-Komponente, $B_{i}(0,0)$ für alle Blöcke, d. h. für alle $i=0,1,2,...,N-1$in der ersten Abtastung. Darauf folgt der zweite Scan, der einige weitere Komponenten kodiert (bei vier weiteren Komponenten sind dies $B_{i}(0,1)$ zu $B_{i}(1,1)$, immer noch im Zickzack) Koeffizienten aller Blöcke kodiert (die Reihenfolge ist also: $B_{0}(0,1),B_{0}(1,0),B_{0}(2,0),B_{0}(1,1),B_{1}(0,1),B_{1}(1,0),...,B_{N}(2,0),B_{N}(1,1)$), gefolgt von allen restlichen Koeffizienten aller Blöcke im letzten Scan. ⓘ

Sobald alle Koeffizienten an ähnlichen Positionen kodiert wurden, ist die nächste zu kodierende Position diejenige, die in der Zickzack-Traversale als nächste auftritt, wie in der obigen Abbildung dargestellt. Es hat sich gezeigt, dass die progressive JPEG-Basiskodierung in der Regel zu einer besseren Komprimierung führt als die sequentielle JPEG-Basiskodierung, da bei jedem "Scan" oder "Durchlauf" (der ähnlich positionierte Koeffizienten enthält) unterschiedliche Huffman-Tabellen (siehe unten) verwendet werden können, die auf unterschiedliche Frequenzen zugeschnitten sind, obwohl der Unterschied nicht allzu groß ist. ⓘ

Im weiteren Verlauf des Artikels wird davon ausgegangen, dass das erzeugte Koeffizientenmuster auf den sequentiellen Modus zurückzuführen ist. ⓘ

Zur Kodierung des oben beschriebenen Koeffizientenmusters verwendet JPEG die Huffman-Kodierung. Der JPEG-Standard stellt allgemeine Huffman-Tabellen zur Verfügung; Kodierer können auch Huffman-Tabellen erzeugen, die für die tatsächlichen Häufigkeitsverteilungen in den zu kodierenden Bildern optimiert sind. ⓘ

Der Prozess der Kodierung der zick-zack-quantisierten Daten beginnt mit einer Lauflängenkodierung, die im Folgenden erläutert wird, wobei:

• x ist der quantisierte AC-Koeffizient, der nicht Null ist.
• RUNLENGTH ist die Anzahl der Nullen, die vor diesem AC-Koeffizienten, der nicht Null ist, stehen.
• SIZE ist die Anzahl der Bits, die zur Darstellung von x erforderlich sind.
• AMPLITUDE ist die Bit-Repräsentation von x. ⓘ

Bei der Lauflängencodierung wird jeder AC-Koeffizient x, der nicht Null ist, untersucht und festgestellt, wie viele Nullen vor dem vorherigen AC-Koeffizienten standen. Mit dieser Information werden zwei Symbole erstellt:

Symbol 1	Symbol 2
(LAUFLÄNGE, GRÖSSE)	(AMPLITUDE)

ⓘ

Sowohl RUNLENGTH als auch SIZE liegen auf demselben Byte, was bedeutet, dass beide nur vier Bits an Informationen enthalten. Die höheren Bits geben die Anzahl der Nullen an, während die niedrigeren Bits die Anzahl der Bits bezeichnen, die zur Codierung des Wertes von x erforderlich sind. ⓘ

Dies hat zur Folge, dass Symbol 1 nur Informationen über die ersten 15 Nullen vor dem AC-Koeffizienten, der nicht Null ist, speichern kann. JPEG definiert jedoch zwei spezielle Huffman-Codewörter. Eines ist für die vorzeitige Beendigung der Sequenz, wenn die verbleibenden Koeffizienten Null sind (genannt "End-of-Block" oder "EOB"), und ein anderes, wenn die Reihe der Nullen über 15 hinausgeht, bevor ein AC-Koeffizient ungleich Null erreicht wird. In einem solchen Fall, in dem 16 Nullen vor einem gegebenen AC-Koeffizienten ungleich Null auftreten, wird Symbol 1 "speziell" kodiert als: (15, 0)(0). ⓘ

Der gesamte Prozess wird fortgesetzt, bis "EOB" - bezeichnet durch (0, 0) - erreicht ist. ⓘ

In diesem Sinne wird die Sequenz von vorhin zu:

(0, 2)(-3);(1, 2)(-3);(0, 1)(-2);(0, 2)(-6);(0, 1)(2);(0, 1)(-4);(0, 1)(1);(0, 2)(-3);(0, 1)(1);(0, 1)(1);

(0, 2)(5);(0, 1)(1);(0, 1)(2);(0, 1)(-1);(0, 1)(1);(0, 1)(-1);(0, 1)(2);(5, 1)(-1);(0, 1)(-1);(0, 0); ⓘ

(Der erste Wert in der Matrix, -26, ist der Gleichstromkoeffizient; er wird nicht auf die gleiche Weise kodiert. Siehe oben.) ⓘ

Von hier aus werden Frequenzberechnungen auf der Grundlage des Vorkommens der Koeffizienten durchgeführt. In unserem Beispielblock handelt es sich bei den meisten der quantisierten Koeffizienten um kleine Zahlen, denen nicht unmittelbar ein Nullkoeffizient vorausgeht. Diese häufigeren Fälle werden durch kürzere Codewörter dargestellt. ⓘ

Komprimierungsverhältnis und Artefakte

Dieses Bild zeigt die Pixel, die sich zwischen einem nicht komprimierten Bild und dem gleichen Bild, das mit JPEG und einer Qualitätseinstellung von 50 komprimiert wurde, unterscheiden. Dunkler bedeutet einen größeren Unterschied. Beachten Sie insbesondere die Veränderungen, die in der Nähe von scharfen Kanten auftreten und eine blockartige Form haben. ⓘ

Das Originalbild ⓘ

Die komprimierten 8×8 Quadrate sind im skalierten Bild sichtbar, zusammen mit anderen visuellen Artefakten der verlustbehafteten Kompression. ⓘ

Das resultierende Kompressionsverhältnis kann je nach Bedarf variiert werden, indem die in der Quantisierungsphase verwendeten Divisoren mehr oder weniger aggressiv gewählt werden. Eine 10:1-Komprimierung führt normalerweise zu einem Bild, das mit dem Auge nicht mehr vom Original zu unterscheiden ist. Ein Kompressionsverhältnis von 100:1 ist in der Regel möglich, sieht aber im Vergleich zum Original deutlich artefaktbehaftet aus. Der geeignete Komprimierungsgrad hängt von der Verwendung des Bildes ab. ⓘ

Externes Bild ⓘ
Veranschaulichung der Randbeschäftigung

Wer das World Wide Web nutzt, kennt vielleicht die als Kompressionsartefakte bekannten Unregelmäßigkeiten in JPEG-Bildern, die sich in Form von Rauschen an kontrastreichen Kanten (insbesondere Kurven und Ecken) oder "blockigen" Bildern äußern können. Diese Artefakte sind auf den Quantisierungsschritt des JPEG-Algorithmus zurückzuführen. Besonders auffällig sind sie an scharfen Ecken zwischen kontrastreichen Farben (Text ist ein gutes Beispiel, da er viele solcher Ecken enthält). Die analogen Artefakte in MPEG-Videos werden als Moskito-Rauschen bezeichnet, da die daraus resultierende "Kantenhäufigkeit" und die falschen Punkte, die sich im Laufe der Zeit verändern, an Moskitos erinnern, die das Objekt umschwirren. ⓘ

Diese Artefakte können durch die Wahl eines niedrigeren Komprimierungsgrads verringert werden; sie können vollständig vermieden werden, indem ein Bild in einem verlustfreien Dateiformat gespeichert wird, was allerdings zu einer größeren Dateigröße führt. Die mit Raytracing-Programmen erstellten Bilder weisen auffällige blockartige Formen im Gelände auf. Bestimmte Kompressionsartefakte mit geringer Intensität können bei der einfachen Betrachtung der Bilder akzeptabel sein, werden aber bei der anschließenden Bearbeitung des Bildes hervorgehoben, was in der Regel zu einer inakzeptablen Qualität führt. Das folgende Beispiel zeigt die Auswirkung einer verlustbehafteten Komprimierung auf einen Verarbeitungsschritt der Kantenerkennung. ⓘ

Bild	Verlustfreie Komprimierung	Verlustbehaftete Kompression ⓘ
Original
Verarbeitet durch Canny-Kantendetektor

Bei einigen Programmen kann der Benutzer den Grad der Komprimierung einzelner Blöcke variieren. Eine stärkere Komprimierung wird auf Bereiche des Bildes angewendet, die weniger Artefakte aufweisen. Auf diese Weise ist es möglich, die Größe der JPEG-Datei manuell zu verringern, ohne dass die Qualität darunter leidet. ⓘ

Da die Quantisierungsphase immer zu einem Informationsverlust führt, ist der JPEG-Standard immer ein verlustbehafteter Kompressionscodec. (Informationen gehen sowohl bei der Quantisierung als auch bei der Rundung der Fließkommazahlen verloren). Selbst wenn die Quantisierungsmatrix eine Matrix aus Einsen ist, gehen beim Runden Informationen verloren. ⓘ

Dekodierung

Die Dekodierung zur Anzeige des Bildes besteht aus der Umkehrung der oben genannten Schritte. ⓘ

Man nimmt die DCT-Koeffizientenmatrix (nachdem man die Differenz der DC-Koeffizienten wieder hinzugefügt hat) ⓘ

$\left[{\begin{array}{rrrrrrrr}-26&-3&-6&2&2&-1&0&0\\0&-2&-4&1&1&0&0&0\\-3&1&5&-1&-1&0&0&0\\-3&1&2&-1&0&0&0&0\\1&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\end{array}}\right]$ ⓘ

und das Produkt aus Eintrag für Eintrag mit der obigen Quantisierungsmatrix ergibt ⓘ

$\left[{\begin{array}{rrrrrrrr}-416&-33&-60&32&48&-40&0&0\\0&-24&-56&19&26&0&0&0\\-42&13&80&-24&-40&0&0&0\\-42&17&44&-29&0&0&0&0\\18&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\\0&0&0&0&0&0&0&0\end{array}}\right]$ ⓘ

was der ursprünglichen DCT-Koeffizientenmatrix für den linken oberen Teil sehr ähnlich ist. ⓘ

Der nächste Schritt ist die zweidimensionale inverse DCT (eine 2D-DCT des Typs III), die sich wie folgt ergibt $f_{x,y}={\frac {1}{4}}\sum _{u=0}^{7}\sum _{v=0}^{7}\alpha (u)\alpha (v)F_{u,v}\cos \left[{\frac {(2x+1)u\pi }{16}}\right]\cos \left[{\frac {(2y+1)v\pi }{16}}\right]$ ⓘ

wobei

• $\ x$ ist die Pixelzeile, für die ganzen Zahlen $\ 0\leq x<8$.
• $\ y$ ist die Pixelspalte, für die ganzen Zahlen $\ 0\leq y<8$.
• $\ \alpha (u)$ ist wie oben definiert, für die ganzen Zahlen $\ 0\leq u<8$.
• $\ F_{u,v}$ ist der rekonstruierte ungefähre Koeffizient an den Koordinaten $\ (u,v).$
• $\ f_{x,y}$ ist der rekonstruierte Pixelwert an den Koordinaten $\ (x,y)$ ⓘ

Die Rundung der Ausgabe auf ganzzahlige Werte (da das Original ganzzahlige Werte hatte) ergibt ein Bild mit (immer noch um 128 nach unten verschobenen) Werten ⓘ

Zwischen dem Original (oben) und dem dekomprimierten Bild (unten) sind leichte Unterschiede zu erkennen, die vor allem in der linken unteren Ecke zu sehen sind. ⓘ

$\left[{\begin{array}{rrrrrrrr}-66&-63&-71&-68&-56&-65&-68&-46\\-71&-73&-72&-46&-20&-41&-66&-57\\-70&-78&-68&-17&20&-14&-61&-63\\-63&-73&-62&-8&27&-14&-60&-58\\-58&-65&-61&-27&-6&-40&-68&-50\\-57&-57&-64&-58&-48&-66&-72&-47\\-53&-46&-61&-74&-65&-63&-62&-45\\-47&-34&-53&-74&-60&-47&-47&-41\end{array}}\right]$ ⓘ

und addiert 128 zu jedem Eintrag ⓘ

$\left[{\begin{array}{rrrrrrrr}62&65&57&60&72&63&60&82\\57&55&56&82&108&87&62&71\\58&50&60&111&148&114&67&65\\65&55&66&120&155&114&68&70\\70&63&67&101&122&88&60&78\\71&71&64&70&80&62&56&81\\75&82&67&54&63&65&66&83\\81&94&75&54&68&81&81&87\end{array}}\right].$ ⓘ

Dies ist das dekomprimierte Teilbild. Im Allgemeinen kann der Dekomprimierungsprozess Werte erzeugen, die außerhalb des ursprünglichen Eingabebereichs von $[0,255]$. In diesem Fall muss der Decoder die Ausgangswerte so beschneiden, dass sie innerhalb dieses Bereichs bleiben, um einen Überlauf zu verhindern, wenn das dekomprimierte Bild mit der ursprünglichen Bittiefe gespeichert wird. ⓘ

Vergleicht man das dekomprimierte Teilbild mit dem ursprünglichen Teilbild (siehe auch die Bilder rechts), indem man die Differenz (Original - unkomprimiert) bildet, so ergeben sich folgende Fehlerwerte:

$\left[{\begin{array}{rrrrrrrr}-10&-10&4&6&-2&-2&4&-9\\6&4&-1&8&1&-2&7&1\\4&9&8&2&-4&-10&-1&8\\-2&3&5&2&-1&-8&2&-1\\-3&-2&1&3&4&0&8&-8\\8&-6&-4&-0&-3&6&2&-6\\10&-11&-3&5&-8&-4&-1&-0\\6&-15&-6&14&-3&-5&-3&7\end{array}}\right]$ ⓘ

mit einem durchschnittlichen absoluten Fehler von etwa 5 Werten pro Pixel (d.h., ${\frac {1}{64}}\sum _{x=0}^{7}\sum _{y=0}^{7}|e(x,y)|=4.8750$). ⓘ

Der Fehler ist am deutlichsten in der linken unteren Ecke zu erkennen, wo das untere linke Pixel dunkler wird als das Pixel unmittelbar rechts davon. ⓘ

Erforderliche Genauigkeit

Die erforderliche Implementierungsgenauigkeit eines JPEG-Codecs wird implizit durch die Anforderungen an die Einhaltung des JPEG-Standards definiert. Diese Anforderungen sind in der ITU.T-Empfehlung T.83 | ISO/IEC 10918-2 festgelegt. Im Gegensatz zu den MPEG-Normen und vielen späteren JPEG-Normen werden in dem oben genannten Dokument sowohl die erforderlichen Implementierungsgenauigkeiten für den Kodierungs- als auch für den Dekodierungsprozess eines JPEG-Codecs anhand eines maximal tolerierbaren Fehlers der Vorwärts- und Invers-DCT in der DCT-Domäne definiert, der durch Referenz-Testströme ermittelt wird. Zum Beispiel darf die Ausgabe einer Decoder-Implementierung einen Fehler von einer Quantisierungseinheit im DCT-Bereich nicht überschreiten, wenn sie auf die Referenz-Test-Codeströme angewendet wird, die als Teil der oben genannten Norm bereitgestellt werden. Obwohl ungewöhnlich und im Gegensatz zu vielen anderen und moderneren Normen formuliert ITU.T T.83 | ISO/IEC 10918-2 keine Fehlergrenzen im Bildbereich. ⓘ

Auswirkungen der JPEG-Kompression

JPEG-Komprimierungsartefakte passen gut zu Fotos mit detaillierten, ungleichmäßigen Texturen, die höhere Komprimierungsraten erlauben. Beachten Sie, wie sich eine höhere Komprimierungsrate zuerst auf die hochfrequenten Texturen in der oberen linken Ecke des Bildes auswirkt und wie die kontrastreichen Linien unschärfer werden. Die sehr hohe Komprimierungsrate beeinträchtigt die Qualität des Bildes stark, obwohl die Gesamtfarben und die Bildform noch erkennbar sind. Allerdings leidet die Präzision der Farben (für das menschliche Auge) weniger als die Präzision der Konturen (basierend auf der Leuchtdichte). Dies rechtfertigt die Tatsache, dass Bilder zunächst in ein Farbmodell umgewandelt werden sollten, das die Luminanz- von der Farbinformation trennt, bevor die chromatischen Ebenen unterabgetastet werden (wobei auch eine Quantisierung geringerer Qualität verwendet werden kann), um die Präzision der Luminanzebene mit mehr Informationsbits zu erhalten. ⓘ

Beispielfotos

Visuelle Auswirkungen einer jpeg-Komprimierung in Photoshop auf ein Bild mit 4480x4480 Pixeln ⓘ

Zur Information: Das nachstehende unkomprimierte 24-Bit-RGB-Bitmap-Bild (73.242 Pixel) würde 219.726 Bytes benötigen (ohne alle anderen Informationsheader). Die unten angegebenen Dateigrößen beinhalten die internen JPEG-Informationsheader und einige Metadaten. Für Bilder höchster Qualität (Q=100) werden etwa 8,25 Bit pro Farbpixel benötigt. Bei Graustufenbildern sind mindestens 6,5 Bits pro Pixel ausreichend (eine vergleichbare Q=100-Qualität von Farbinformationen erfordert etwa 25 % mehr kodierte Bits). Das Bild mit der höchsten Qualität (Q=100) wird mit neun Bits pro Farbpixel kodiert, das Bild mittlerer Qualität (Q=25) verwendet ein Bit pro Farbpixel. Für die meisten Anwendungen sollte der Qualitätsfaktor nicht unter 0,75 Bit pro Pixel (Q=12,5) sinken, wie das Bild niedriger Qualität zeigt. Das Bild mit der niedrigsten Qualität verwendet nur 0,13 Bit pro Pixel und zeigt sehr schlechte Farben. Dies ist nützlich, wenn das Bild in einer deutlich verkleinerten Größe angezeigt werden soll. Eine Methode zur Erstellung besserer Quantisierungsmatrizen für eine bestimmte Bildqualität unter Verwendung des PSNR anstelle des Q-Faktors wird in Minguillón & Pujol (2001) beschrieben. ⓘ

Hinweis: Bei den obigen Bildern handelt es sich nicht um IEEE / CCIR / EBU-Testbilder, und die Encodereinstellungen sind nicht angegeben oder verfügbar.

Bild	Qualität	Größe (Bytes)	Komprimierungsverhältnis	Kommentar
	Höchste Qualität (Q = 100)	81,447	2.7:1	Äußerst geringe Artefakte
	Hohe Qualität (Q = 50)	14,679	15:1	Erste Anzeichen von Unterbildartefakten
	Mittlere Qualität (Q = 25)	9,407	23:1	Stärkere Artefakte; Verlust von Hochfrequenzinformationen
	Niedrige Qualität (Q = 10)	4,787	46:1	Starker Hochfrequenzverlust führt zu offensichtlichen Artefakten an Teilbildgrenzen ("Macroblocking")
	Geringste Qualität (Q = 1)	1,523	144:1	Extremer Farb- und Detailverlust; die Blätter sind fast unkenntlich.

ⓘ

Das Foto mittlerer Qualität benötigt nur 4,3 % des Speicherplatzes, der für das unkomprimierte Bild erforderlich ist, weist aber kaum Detailverluste oder sichtbare Artefakte auf. Ab einem bestimmten Komprimierungsgrad weisen die komprimierten Bilder jedoch zunehmend sichtbare Mängel auf. Eine mathematische Erklärung dieses Schwelleneffekts finden Sie in dem Artikel über die Theorie der Ratenverzerrung. Eine besondere Einschränkung von JPEG in dieser Hinsicht ist seine nicht überlappende 8×8-Blocktransformationsstruktur. Modernere Verfahren wie JPEG 2000 und JPEG XR weisen eine gleichmäßigere Qualitätsverschlechterung bei abnehmendem Bitverbrauch auf, indem sie Transformationen mit einer größeren räumlichen Ausdehnung für die niedrigeren Frequenzkoeffizienten und überlappende Transformationsbasisfunktionen verwenden. ⓘ

Verlustfreie weitere Kompression

Von 2004 bis 2008 wurden neue Forschungsarbeiten durchgeführt, um die in JPEG-Bildern enthaltenen Daten weiter zu komprimieren, ohne das dargestellte Bild zu verändern. Dies findet Anwendung in Szenarien, in denen das Originalbild nur im JPEG-Format vorliegt und für die Archivierung oder Übertragung verkleinert werden muss. Standard-Komprimierungstools für allgemeine Zwecke können JPEG-Dateien nicht wesentlich komprimieren. ⓘ

In der Regel nutzen solche Verfahren Verbesserungen des naiven Verfahrens zur Kodierung von DCT-Koeffizienten, das keine Berücksichtigung findet:

• Korrelationen zwischen den Größen benachbarter Koeffizienten im selben Block;
• Korrelationen zwischen den Größen desselben Koeffizienten in benachbarten Blöcken;
• Korrelationen zwischen den Beträgen desselben Koeffizienten/Blocks in verschiedenen Kanälen;
• Die DC-Koeffizienten ähneln in ihrer Gesamtheit einer verkleinerten Version des Originalbildes, multipliziert mit einem Skalierungsfaktor. Bekannte Verfahren zur verlustfreien Kodierung von Bildern mit kontinuierlichen Tönen können angewandt werden, wobei eine etwas bessere Komprimierung als bei der in JPEG verwendeten Huffman-kodierten DPCM erreicht wird. ⓘ

In JPEG gibt es bereits einige standardmäßige, aber selten genutzte Optionen, um die Effizienz der Kodierung von DCT-Koeffizienten zu verbessern: die Option der arithmetischen Kodierung und die Option der progressiven Kodierung (die zu niedrigeren Bitraten führt, da die Werte für jeden Koeffizienten unabhängig voneinander kodiert werden und jeder Koeffizient eine deutlich andere Verteilung hat). Moderne Methoden haben diese Techniken verbessert, indem sie Koeffizienten neu anordnen, um Koeffizienten größerer Größenordnung zusammenzufassen, benachbarte Koeffizienten und Blöcke zur Vorhersage neuer Koeffizientenwerte verwenden, Blöcke oder Koeffizienten auf der Grundlage ihrer Statistik und benachbarter Werte auf eine kleine Anzahl unabhängig kodierter Modelle aufteilen und in jüngster Zeit Blöcke dekodieren, nachfolgende Blöcke im räumlichen Bereich vorhersagen und diese dann kodieren, um Vorhersagen für DCT-Koeffizienten zu erzeugen. ⓘ

In der Regel können solche Methoden bestehende JPEG-Dateien um 15 bis 25 % komprimieren, und bei JPEGs, die mit niedrigen Qualitätseinstellungen komprimiert wurden, können Verbesserungen von bis zu 65 % erzielt werden. ⓘ

Ein frei verfügbares Tool namens packJPG basiert auf dem 2007 veröffentlichten Dokument "Improved Redundancy Reduction for JPEG Files". ⓘ

Als Entropiekodierung wird meist eine Huffman-Kodierung verwendet. Der JPEG-Standard erlaubt auch eine arithmetische Kodierung. Obwohl diese zwischen 5 und 15 Prozent kleinere Dateien generiert, wird sie aus patentrechtlichen Gründen kaum verwendet, zudem ist diese Kodierung deutlich langsamer. ⓘ

Abgeleitete Formate für stereoskopisches 3D

JPEG Stereoskopisch

Ein Beispiel für eine stereoskopische .JPS-Datei ⓘ

JPS ist ein stereoskopisches JPEG-Bild, das für die Erstellung von 3D-Effekten aus 2D-Bildern verwendet wird. Es enthält zwei statische Bilder, eines für das linke und eines für das rechte Auge, kodiert als zwei nebeneinander liegende Bilder in einer einzigen JPG-Datei. JPEG Stereoscopic (JPS, Erweiterung .jps) ist ein JPEG-basiertes Format für stereoskopische Bilder. Es verfügt über eine Reihe von Konfigurationen, die im JPEG APP3-Markerfeld gespeichert sind, enthält aber in der Regel ein Bild mit doppelter Breite, das zwei Bilder gleicher Größe in schräger Anordnung (d. h. linkes Bild auf der rechten Bildhälfte und umgekehrt) nebeneinander darstellt. Dieses Dateiformat kann ohne spezielle Software als JPEG betrachtet oder für die Wiedergabe in anderen Modi verarbeitet werden. ⓘ

JPEG-Mehrbildformat

Das JPEG-Multi-Picture-Format (MPO, Erweiterung .mpo) ist ein JPEG-basiertes Format zur Speicherung mehrerer Bilder in einer einzigen Datei. Es enthält zwei oder mehr JPEG-Dateien, die miteinander verkettet sind. Es definiert auch ein JPEG APP2-Markersegment zur Bildbeschreibung. Verschiedene Geräte verwenden es zum Speichern von 3D-Bildern, z. B. Fujifilm FinePix Real 3D W1, HTC Evo 3D, JVC GY-HMZ1U AVCHD/MVC-Erweiterungscamcorder, Nintendo 3DS, Panasonic Lumix DMC-TZ20, DMC-TZ30, DMC-TZ60, DMC-TS4 (FT4) und Sony DSC-HX7V. Andere Geräte nutzen ihn, um "Vorschaubilder" zu speichern, die auf einem Fernsehgerät angezeigt werden können. ⓘ

In den letzten Jahren hat die wissenschaftliche Gemeinschaft aufgrund der zunehmenden Verwendung stereoskopischer Bilder große Anstrengungen unternommen, um Algorithmen für die Kompression stereoskopischer Bilder zu entwickeln. ⓘ

Implementierungen

Eine sehr wichtige Implementierung eines JPEG-Codecs ist die freie Programmierbibliothek libjpeg der Independent JPEG Group. Sie wurde erstmals 1991 veröffentlicht und war entscheidend für den Erfolg des Standards. Diese Bibliothek oder ein direktes Derivat davon wird in unzähligen Anwendungen verwendet. In neueren Versionen wurden proprietäre Erweiterungen eingeführt, die die ABI-Kompatibilität mit früheren Versionen brachen und die nicht durch den ITU|ISO/IEC-Standard abgedeckt sind. ⓘ

Im März 2017 veröffentlichte Google das Open-Source-Projekt Guetzli, das eine viel längere Kodierungszeit gegen eine geringere Dateigröße eintauscht (ähnlich wie Zopfli für PNG und andere verlustfreie Datenformate). ⓘ

ITU|ISO/IEC formalisierte JPEG-Referenzimplementierungen in der ITU-T-Empfehlung T.873 | ISO/IEC 10918-7 im Jahr 2021. ⓘ

Die ISO/IEC Joint Photography Experts Group unterhält eine der beiden Referenzsoftware-Implementierungen, die sowohl Basis-JPEG (ISO/IEC 10918-1 und 18477-1) und JPEG-XT-Erweiterungen (ISO/IEC 18477 Teile 2 und 6-9) als auch JPEG-LS (ISO/IEC 14495) kodieren kann. ⓘ

Eine zweite Referenzimplementierung ist libJPEG-turbo, ein Derivat der JPEG-Implementierung der Indedependent JPEG Group, das auf hohe Leistung und Konformität mit dem JPEG-Standard abgestimmt ist. ⓘ

JPEG XT

JPEG XT (ISO/IEC 18477) wurde im Juni 2015 veröffentlicht; es erweitert das Basis-JPEG-Format um Unterstützung für höhere ganzzahlige Bittiefen (bis zu 16 Bit), Bilder mit hohem Dynamikbereich und Fließkommakodierung, verlustfreie Kodierung und Alphakanal-Kodierung. Die Erweiterungen sind abwärtskompatibel mit dem Basis-JPEG/JFIF-Dateiformat und verlustbehafteten 8-Bit-Kompressionsbildern. JPEG XT verwendet ein erweiterbares Dateiformat, das auf JFIF basiert. Die Erweiterungsebenen werden verwendet, um die JPEG 8-Bit-Basisebene zu ändern und das hochauflösende Bild wiederherzustellen. Vorhandene Software ist vorwärtskompatibel und kann den JPEG-XT-Binärstrom lesen, obwohl sie nur die 8-Bit-Basisschicht dekodieren würde. ⓘ

JPEG XL

Seit August 2017 hat JTC1/SC29/WG1 eine Reihe von Aufforderungen zur Einreichung von Vorschlägen für JPEG XL veröffentlicht - den Bildkompressionsstandard der nächsten Generation mit einer wesentlich besseren Kompressionseffizienz (60 % Verbesserung) im Vergleich zu JPEG. Es wird erwartet, dass der Standard die von HEVC HM, Daala und WebP gezeigte Komprimierungsleistung für Standbilder übertrifft und im Gegensatz zu früheren Versuchen, JPEG zu ersetzen, eine verlustfreie und effizientere Option für den Transport und die Speicherung von herkömmlichen JPEG-Bildern durch Neukomprimierung bietet. Zu den Kernanforderungen gehören die Unterstützung von Bildern mit sehr hoher Auflösung (mindestens 40 MP), 8-10 Bits pro Komponente, RGB/YCbCr/ICtCp-Farbkodierung, animierte Bilder, Alphakanal-Kodierung, Rec. 709-Farbraum (sRGB) und Gamma-Funktion (2,4-Power), Rec. 2100 Wide Color Gamut-Farbraum (Rec. 2020) und High Dynamic Range Transfer-Funktionen (PQ und HLG) sowie eine qualitativ hochwertige Komprimierung von synthetischen Bildern wie Bitmap-Schriften und Verläufen. Der Standard sollte auch höhere Bittiefen (12-16 Bit Integer und Fließkomma), zusätzliche Farbräume und Übertragungsfunktionen (wie Log C von Arri), eingebettete Vorschaubilder, verlustfreie Alphakanalcodierung, Kodierung von Bildbereichen und Codierung mit geringer Komplexität bieten. Alle patentierten Technologien würden lizenzgebührenfrei vergeben werden. Die Vorschläge wurden bis September 2018 eingereicht und führten im Juli 2019 zu einem Entwurf des Ausschusses. Das Dateiformat und das Kerncodierungssystem wurden am 13. Oktober 2021 bzw. am 30. März 2022 formell standardisiert. ⓘ

Daneben ist mit JPEG XL ein weiteres Nachfolgeformat in Entwicklung. Es integriert eine Reihe von Funktionen, für die bisher andere Bildformate verwendet wurden und bietet eine verbesserte Komprimierung, die auf den experimentellen Formaten PIK und FUIF basiert. Im Januar 2021 wurde ein Format Freeze bekanntgegeben. Im Mai 2021 wurde gemeldet, dass das Format in Vorabversionen von Chrome, Edge und Firefox (noch mit zusätzlichen Schaltern gesichert) ausprobiert werden kann. ⓘ

Die JPEG-Dekodierung

Die Dekompression (meist Dekodierung genannt) erfolgt invers zur Kompression:

• Entropie-Dekodierung
• Umsortierung
• Requantisierung
• Inverse Diskrete Kosinustransformation.
• Überabtastung und Tiefpassfilterung der Farbdifferenzsignal U und V (verlustbehaftet)
• Farbmodellumrechnung vom YCbCr-Farbmodell in den Zielfarbraum (meist RGB) ⓘ

Die Dekompression ist zwar (weitgehend) verlustfrei, allerdings tritt das Inverse-Dekoder-Problem auf. Aus dekodierten Daten ist es nur schwierig möglich, die ursprüngliche Datei zu rekonstruieren. Ein Dekodier-Kodier-Vorgang verändert die Datei und ist damit nicht verlustfrei, es treten wie beim analogen Überspielen Generationsverluste auf. ⓘ

Die Generationsverluste von JPEG sind allerdings vergleichsweise klein, wenn wieder die gleiche Quantisierungstabelle zum Einsatz kommt und die Blockgrenzen die gleichen sind. Bei geeigneten Randbedingungen kann man sie bei JPEG sogar vermeiden. Bei JPEG-2000 ist das nicht mehr der Fall (überlappende Transformationen, wie sie bei JPEG-2000 wie auch in der Audiodatenkompression zum Einsatz kommen, erfordern dafür utopische Rechenleistungen). ⓘ

Farbmodellumrechnung

Die Rückrechnung vom YCbCr-Farbmodell in den RGB-Farbraum erfolgt über die inverse Matrix der Hinrechnung, sie lautet:

${\begin{bmatrix}R'\\G'\\B'\end{bmatrix}}={\begin{bmatrix}1&0&1{,}402\\1&-0{,}344136&-0{,}714136\\1&1{,}772&0\end{bmatrix}}\cdot {\begin{bmatrix}Y'\\Pb\\Pr\end{bmatrix}}$

mit:

${\begin{bmatrix}Y'\\Pb\\Pr\end{bmatrix}}={\begin{bmatrix}Y'\\Cb\\Cr\end{bmatrix}}-{\begin{bmatrix}0\\128\\128\end{bmatrix}}$ ⓘ

Progressives JPEG

Ein JPEG-Bild besteht aus Koeffizienten. Diese speichern keine Pixel, sondern Annäherungen des gesamten Bildinhalts eines 8×8-Bildblocks. Beim Progressive JPEG werden erst die ersten Koeffizienten jedes Bildblocks, dann die zweiten usw. der Reihe nach abgespeichert, so dass die Annäherung an das Originalbild immer besser wird. ⓘ

Wie beim Interlacing, das bei GIF angewendet wird, liegt der Zweck darin, dem Benutzer, noch bevor die gesamte Datei geladen ist, schnell ein grobes Vorschaubild zu geben. Dies ist besonders dann sinnvoll, wenn das Laden eines Bildes länger als eine halbe bis ganze Sekunde dauert bzw. man nur ein Vorschaubild benötigt. Jedoch werden große Bilder trotzdem meistens im normalen JPEG-Modus zum Download angeboten. ⓘ

Verlustfreie Nachbearbeitung von JPEG

Verlustfreie erweiterte Kompression der Daten

Die Firma Dropbox hat ein Programm entwickelt, welches mittels arithmetischen Kodierens den Platzbedarf von bereits vorhandenen JPEG-Dateien nochmals um durchschnittlich ungefähr 20 Prozent verkleinert. Das Programm heißt Lepton und steht unter der Apache-2.0-Lizenz, einer Open-Source-Lizenz. ⓘ