- libjxl 0.10 reduziert den Flaschenhals der JPEG-XL-Kodierung, die große Bilder bisher auf einmal verarbeitete, mit einer Streaming-Encoding-API und verbessert damit Speicherverbrauch und Geschwindigkeit bei verlustfreier Kompression deutlich
- Die verlustfreie Kodierung eines 13500×6750 großen NASA-Nachtbilds der Erde sank von rund 8 GB RAM und über 2 Minuten in libjxl 0.9 auf 0,7 GB RAM, 30 Sekunden mit einem einzelnen Thread und 5 Sekunden mit 8 Threads in libjxl 0.10
- Für den Vergleich von Kompressionsverfahren reicht die Dateigröße allein nicht aus; die Pareto-Front, die Kodiergeschwindigkeit und Kompressionsdichte gemeinsam betrachtet, wird zum Maßstab für die beste Einstellung je nach Zeitbudget
- Bei verlustbehafteter Kompression müssen Kompressionsrate, Geschwindigkeit und Bildqualität gemeinsam betrachtet werden; im Bereich SSIMULACRA2 60–90 zeigt JPEG XL besonders starke Ergebnisse bei hoher Qualität bis visuell verlustfrei
- Neue JPEG-Encoder wie jpegli bleiben in Bereichen mit extrem schneller Kodierung weiterhin konkurrenzfähig, doch JPEG XL etabliert sich über einen breiten Geschwindigkeitsbereich hinweg als zentrale Wahl für verlustfreie wie verlustbehaftete Kompression
Die wichtigsten Änderungen in libjxl 0.10
- libjxl 0.10 ist die neue Version der JPEG-XL-Referenzimplementierung; die größte Änderung ist die vollständige Umsetzung der Streaming-Encoding-API
- Diese API kodiert große Bilder nicht mehr auf einmal, sondern in Chunks
- Dadurch sinkt die RAM-Belastung, die entsteht, wenn das gesamte Bild in den Speicher geladen wird
- Auch die Kodiergeschwindigkeit verbessert sich
- Besonders deutlich ist der Effekt bei verlustfreier Kompression großer Bilder
Weniger Speicher und Zeit bei verlustfreier Kompression
- Vor libjxl 0.10 konnten verlustfreie JPEG-XL-Kodierungen durch hohen Speicherbedarf und lange Laufzeiten problematisch sein
- Das Beispielbild ist NASAs 13500×6750 großes Nachtbild der Erde
- Die TIFF-Datei ist 64 MB groß
- Die unkomprimierte Größe beträgt 273 MB
- Ergebnis der Kompression desselben Bilds mit der Standard-effort-Einstellung e7:
- libjxl 0.9 nutzte rund 8 GB RAM und brauchte mehr als 2 Minuten; die Ergebnisdatei war 33,7 MB groß
- Mit einem einzelnen Thread dauerte es 2 Minuten 40 Sekunden, mit 8 Threads 2 Minuten 6 Sekunden; der Effekt zusätzlicher Threads war also gering
- Gemessen wurde auf einem MacBook Pro vom November 2023 mit 12-Core Apple M3 Pro CPU und 36 GB RAM
- In libjxl 0.10 benötigt die Kompression desselben Bilds nur noch 0,7 GB RAM
- 30 Sekunden mit einem einzelnen Thread
- 5 Sekunden mit 8 Threads
- Die Ergebnisdatei ist 33,2 MB groß
- Ein höherer effort-Wert verbessert die Kompressionsrate, aber der Zugewinn pro investierter CPU-Zeit nimmt zunehmend ab
- Von e1 auf e2 konnten mit 1 Sekunde statt 0,1 Sekunden 22 MB eingespart werden
- Von e2 auf e7 wurden mit 5 Sekunden statt 1 Sekunde zusätzlich 11 MB eingespart
- Von e7 auf e9 musste man fast 2 Minuten warten, um nur noch 1 MB zusätzlich zu sparen
Praktische Kompromisse bei effort-Einstellungen
- Kompressionseinstellungen sind ein Kompromiss zwischen Zeit und Dateigröße
- In Authoring-Workflows, bei denen während der Bildbearbeitung lokal gespeichert wird, ist starke Kompression nicht zwingend nötig; eine niedrige effort-Einstellung kann daher sinnvoll sein
- In One-to-many-Verteilungsszenarien oder bei Langzeitarchivierung kann es sich lohnen, mehr CPU-Zeit einzusetzen, um einige MB einzusparen
Kompressionsverfahren mit der Pareto-Front vergleichen
- Wer Kompressionstechniken nur anhand der Dateigröße vergleicht, übersieht leicht Informationen, die für die tatsächliche Auswahl wichtig sind
-
Vergleichsachsen und Interpretation der Diagramme
- Die zentralen Achsen sind Kompressionsdichte und Kodiergeschwindigkeit
- Dass ein Verfahren Pareto-optimal ist, bedeutet, dass es kein anderes Verfahren gibt, das bei gleicher oder besserer Kompressionsdichte in kürzerer Zeit dasselbe erreicht
- Die Menge dieser Pareto-optimalen Verfahren ist die Pareto-Front
- In den Diagrammen zeigt die y-Achse die Kodiergeschwindigkeit, die x-Achse die durchschnittlichen Bits pro Pixel des komprimierten Bilds
- Die y-Achse verwendet die Einheit Megapixel pro Sekunde und aufgrund des großen Geschwindigkeitsbereichs eine logarithmische Skala
- Unkomprimiertes 8-Bit-RGB entspricht 24 bpp
- Weiter oben bedeutet schneller, weiter links bedeutet bessere Kompression
Ergebnisse beim Vergleich verlustfreier Kompression
- Schon frühere libjxl-Versionen lieferten über alle Geschwindigkeitsbereiche hinweg Pareto-optimale Ergebnisse und erzeugten kleinere Dateien als PNG, verlustfreies AVIF und verlustfreies WebP
- libjxl 0.10 zeigt gegenüber früheren Versionen deutlich bessere Ergebnisse
- QOI ist im Diagramm nicht dargestellt, erreichte aber 17 bpp bei 154 Mpx/s
- Die niedrigste effort-Einstellung von libjxl komprimiert bis auf 11,5 bpp bei 427 Mpx/s
- libjxl war damit 2,7-mal schneller und die Ergebnisdatei 32,5 % kleiner
Verlustfreie Kompression bei nicht-fotografischen Bildern
- Fotos enthalten viel natürliches Rauschen und sind deshalb schwer verlustfrei zu komprimieren; bei nicht-fotografischen Bildern sieht das anders aus
- In einem Test mit 41 Comic-Bildern verschiedener Stilrichtungen lag die durchschnittliche Größe bei 7,3 Megapixeln
- Solche Bilder ließen sich auf etwa 4 bpp komprimieren und damit deutlich besser als Fotobilder mit etwa 10 bpp
- Verlustfreies AVIF war für diesen Bildtyp nicht nützlich
- Die Kompressionsrate war schlechter als bei PNG
- Es erreichte eine ähnliche Dichte wie QOI, war aber deutlich langsamer
- Verlustfreies WebP zeigte bei solchen Bildern eine sehr gute Kompressionsrate
- QOI ist unter dem Gesichtspunkt von Geschwindigkeit und Einfachheit akzeptabel, aber weit von Pareto-Optimalität entfernt
- JPEG XL mit niedriger effort-Einstellung war doppelt so schnell wie QOI und erzeugte 31 % kleinere Dateien
- libjxl 0.10 verbessert sich auch bei nicht-fotografischen Bildern stark gegenüber 0.9
- WebP mit Standard-effort: 4,30 bpp, 2,3 Mpx/s
- libjxl 0.9 effort 5: 4,27 bpp, 2,6 Mpx/s
- libjxl 0.10 effort 5: 4,25 bpp, 12,2 Mpx/s
- libjxl 0.10 effort 7: 4,04 bpp, 5,9 Mpx/s
Bei verlustbehafteter Kompression kommt die Qualitätsachse hinzu
- Bei verlustfreier Kompression reichen Größe und Geschwindigkeit, bei verlustbehafteter Kompression kommt Bildqualität hinzu
- Die Leistung verlustbehafteter Bild-Codecs und Encoder kann je nach Qualitätsstufe stark variieren
- Ein Encoder, der bei hoher Qualität gut ist, muss nicht auch bei niedriger Qualität gut sein
- Umgekehrt gilt das ebenso
- Bitrate-Distortion-Plots, die nur Kompressionsrate und Qualität betrachten, erschweren die Bewertung des Kompromisses zwischen Kodier-effort und Kompressionsleistung
- Um die Pareto-Front verlustbehafteter Kompression zu sehen, muss der dreidimensionale Raum aus Kompression, Geschwindigkeit und Qualität an mehreren Qualitätsstufen betrachtet werden
Qualitätsmessung und Aggregation
- Bildqualität ist subjektiv und kann von Person zu Person unterschiedlich wahrgenommen werden
- Die beste Messmethode sind Experimente, in denen Dutzende Personen oder mehr Bilder nach einem strengen Testprotokoll vergleichen oder bewerten
- Solche Experimente sind zeit- und kostenintensiv; deshalb werden objektive Metriken verwendet, da sich nicht alle Encoder-Einstellungen testen lassen
- Zu den guten öffentlichen Metriken gehören SSIMULACRA2, Butteraugli und DSSIM
- Sie versuchen, das menschliche visuelle System zu modellieren, und korrelieren gut mit subjektiven Bewertungen
- Ältere, einfachere Metriken wie PSNR oder SSIM passen deutlich schlechter zu menschlichen Qualitätsurteilen
- Bewertet man mit einer Metrik, die ein Encoder intern selbst optimiert, kann das die Ergebnisse zugunsten dieses Encoders verzerren
- libjxl mit hohem effort optimiert Butteraugli
- libavif kann PSNR oder SSIM optimieren
- SSIMULACRA2 wird von den getesteten Encodern intern nicht zur Optimierung verwendet und gilt deshalb als sichere Metrik
- Im Test wurden Encoder-Einstellungen so gewählt, dass bei Anwendung auf den gesamten Bildsatz der durchschnittliche SSIMULACRA2-Wert jeweils nahe an einem Zielwert lag
- Die Sortierung nach Durchschnittswerten begünstigt WebP und AVIF
- Frühere Studien zeigten, dass AVIF und WebP weniger konsistent sind als JPEG und HEIC, während JPEG XL der konsistenteste Encoder war
- In der Praxis möchte man möglicherweise eher den schlechtesten Wert oder die tatsächlich schlechteste visuelle Qualität angleichen
Qualitätsbereich nahe an der Praxis
- Verlustbehaftete Kompression kann zwar hohe Kompressionsraten wie 50:1 oder 200:1 erreichen, erzeugt dann aber Artefakte
- Der in der Praxis besonders relevante Bereich liegt bei SSIMULACRA2 60–90
- Eigenschaften je Qualitätsstufe:
- SSIMULACRA2 90: visuell verlustfreie Qualität; moderne Codecs wie AVIF und JPEG XL erreichen das bei etwa 8:1 Kompression, also 3 bpp
- SSIMULACRA2 80: hohe Qualität; erreichbar mit etwa 16:1 Kompression, also 1,5 bpp
- SSIMULACRA2 70: mittelhohe Qualität; erreichbar mit etwa 30:1 Kompression, also 0,8 bpp
- SSIMULACRA2 60: mittlere Qualität; erreichbar mit etwa 40:1 Kompression, also 0,6 bpp
- Qualität unter SSIMULACRA2 60 spart zwar noch mehr Bandbreite, birgt aber das Risiko, Bilder sichtbar zu beschädigen
- Im Web des Jahres 2024 ist vor allem der Bereich mittlerer bis hoher Qualität relevant
- Laut HTTP Archive liegt der Medianwert für AVIF im Web bei 1 bpp, also im Bereich mittelhoher Qualität
- Der Medianwert für JPEG liegt bei 2,1 bpp, also im Bereich hoher Qualität
- In nicht webbasierten Einsatzszenarien wie Kameras ist der Bereich hohe Qualität bis visuell verlustfrei noch relevanter
Ergebnisse der Pareto-Front bei verlustbehafteter Kompression
- Die Tests zur verlustbehafteten Kompression wurden mit den jeweils aktuellen Versionen der Encoder Ende Februar 2024 durchgeführt
- Die Kodiergeschwindigkeit wurde mit 8 Threads auf einem MacBook Pro vom November 2023 mit Apple M3 Pro gemessen
- Für AVIF wurden sowohl Tile- als auch Non-Tile-Einstellungen getestet
- Tile-Einstellungen nutzen Multithreading besser und sind daher schneller
- Dafür geht Kompressionsdichte verloren
Mittlere Qualität: SSIMULACRA2 60
- Selbst innerhalb desselben Formats waren die Ergebnisse je nach Encoder und effort-Einstellung sehr unterschiedlich
- Die historisch weit verbreitete Standardkonfiguration von libjpeg-turbo war im Diagramm am schnellsten, lag aber auf der Seite mit geringerer Kompressionsdichte
- WebP bot eine bessere Kompressionsdichte als libjpeg-turbo
- mozjpeg war langsamer als libjpeg-turbo, lieferte aber bessere Kompression und war bei diesem Bildsatz und dieser Qualitätsstufe Pareto-effizienter als WebP
- jpegli, entwickelt vom JPEG-XL-Team bei Google, war schneller als mozjpeg und komprimierte besser
- Es baut auf Erkenntnissen aus guetzli und libjxl auf
- Es komprimiert besser als WebP und schnelles AVIF und erzeugt dabei weiterhin klassische JPEG-Dateien
- AVIF und HEIC können eine bessere Kompressionsdichte als JPEG und WebP erreichen, sind beim Kodieren aber langsamer
- JPEG XL erreicht eine ähnliche Kompressionsdichte und kodiert dabei deutlich schneller
- Die Pareto-Front dieser Qualitätsstufe besteht bei vernünftigen Geschwindigkeiten aus JPEG XL und mehreren JPEG-Encodern; in langsameren Bereichen kommt AVIF hinzu
Ergebnisse bei mittelhoher und hoher Qualität
- Bei SSIMULACRA2 70, also mittelhoher Qualität, ähnelten die Gesamtergebnisse denen bei mittlerer Qualität
- Als höchste für das Web relevante Qualitätsstufe wurde ein durchschnittlicher SSIMULACRA2-Wert von 85 verwendet, mit Einstellungen, die dafür sorgten, dass die meisten Bilder 80 oder mehr erreichten
- Bei dieser hohen Qualitätsstufe wurden die Unterschiede klarer
- mozjpeg schlug WebP nicht mehr
- jpegli schlug WebP weiterhin
- Die Pareto-Front wurde größtenteils von JPEG XL besetzt
- Bei extrem schneller Kodierung blieb klassisches JPEG weiterhin gut
- AVIF lag bei dieser Qualitätsstufe nicht auf der Pareto-Front
- In seiner langsamsten Einstellung erreichte es bei weniger als 0,5 Mpx/s dieselbe Kompressionsdichte wie die zweitschnellste libjxl-Einstellung
- Diese libjxl-Einstellung arbeitete mit 52 Mpx/s und war damit mehr als 100-mal schneller
Dekodiergeschwindigkeit
- Die bisherigen Vergleiche konzentrierten sich auf Kompressionsdichte und Kodiergeschwindigkeit
- Auf modernen Rechnern ist die Dekodiergeschwindigkeit kein großes Problem, wurde aber ebenfalls gemessen
- Sequenzielles JPEG ist bei der Dekodiergeschwindigkeit am stärksten
- Progressives JPEG, wie es mozjpeg und jpegli in der Standardeinstellung erzeugen, ist langsamer, lädt Bilder in vernünftiger Größe aber immer noch sehr schnell
- JPEG XL liegt zwischen sequenziellem und progressivem JPEG
- Die Dekodiergeschwindigkeit von AVIF hängt von der Kodierweise ab
- Schnellere, aber etwas schlechtere Multi-Tile-Kodierung dekodiert ebenfalls schneller
- Die Standardkodierung mit Single Tile ist langsamer
- Selbst die langsamste gemessene Dekodiergeschwindigkeit ist im Vergleich zur Kodiergeschwindigkeit noch ausreichend hoch
Visuell verlustfrei und große Bilder
- Im Diagramm zur visuell verlustfreien Qualität war WebP nicht enthalten
- Im verlustbehafteten Modus konnte es diese Qualitätsstufe nicht erreichen
- Der Grund ist, dass bei WebP 4:2:0-Chroma-Subsampling verpflichtend ist
- Auch mozjpeg ist nicht auf diese Qualitätsstufe ausgelegt und schnitt sowohl bei Kompression als auch Geschwindigkeit schlechter ab als libjpeg-turbo
- Mit der Standardgeschwindigkeit war libavif 20 % kleiner als libjpeg-turbo, brauchte zum Kodieren aber eine um eine Größenordnung längere Zeit
- Bei derselben Qualitätsstufe war libjxl 20 % kleiner als libavif und 2,5-mal schneller
- Die Pareto-Front bei visuell verlustfreier Qualität wurde größtenteils von JPEG XL besetzt; im schnellsten Bereich war auch JPEG vertreten
- Anders als in Tests mit etwa 1-Megapixel-Bildern in Web-Größe änderten sich die Ergebnisse bei größeren Bildern deutlich
- Bei hoher Qualität waren WebP, mozjpeg und AVIF schlechter als libjpeg-turbo
- HEIC bot gegenüber libjpeg-turbo deutliche Einsparungen
- jpegli bot ebenfalls deutliche Einsparungen bei besserer Geschwindigkeit
- JPEG XL komprimierte Bilder auf unter 1,3 bpp, während AVIF, libjpeg-turbo und WebP mehr als 2 bpp benötigten
Die endgültige Einordnung von libjxl 0.10
- libjxl 0.10 reduziert den Speicherverbrauch bei verlustfreier wie verlustbehafteter Kompression um fast eine Größenordnung
- Auch die Geschwindigkeit wurde verbessert; insbesondere die standardmäßige verlustfreie Multithread-Kodierung mit mittlerem effort wurde um fast eine Größenordnung beschleunigt
- JPEG XL erweist sich sowohl für verlustfreie als auch für verlustbehaftete Kompression als starker Bild-Codec, besonders im Bereich hoher Qualität bis visuell verlustfrei
- Über einen breiten Bereich von Geschwindigkeitseinstellungen hinweg bleibt JPEG XL eine nahezu Pareto-optimale Wahl
- Auch klassisches JPEG bleibt dank neuer Encoder attraktiv
- jpegli verbessert sowohl Geschwindigkeit als auch Kompression gegenüber mozjpeg deutlich
- Wenn extrem schnelle Kodierung nötig ist, kann klassisches JPEG weiterhin die beste Wahl sein
2 Kommentare
Der
jpegli-Encoder verlängert nachmozjpegnun erneut das Leben von JPG ...Er wurde zwar vom JXL-Lager entwickelt, könnte aber ironischerweise die Verbreitung von JXL behindern ...
Meinungen auf Hacker News
Man sollte auch beachten, wie gut verlustfreies WebP ist.
Das geht oft unter, weil gesagt wird, WebP habe gegenüber MozJPEG-Encoding keinen klaren Vorteil oder sei sogar schlechter, aber verlustfreies WebP ist bei Leistung und Geschwindigkeit wirklich hervorragend.
Es ist deutlich besser als PNG oder OptiPNG, die Online-Unterstützung ist inzwischen ausreichend, und das miserable verlustfreie AVIF übertrifft es natürlich ebenfalls deutlich.
Für SDR-Bilder ist das in Ordnung, für HDR wird es jedoch zu einer grundlegenden Einschränkung, ähnlich wie GIF auf 256 Farben beschränkt ist.
Wenn man ganze Comics komprimiert, ist PNG weiterhin die richtige Wahl; in diesem Fall sollte man eher oxipng verwenden als das praktisch aufgegebene optipng.
Außerdem fehlt hier der Hinweis, dass verlustfreies JPEG2000 bei Fotoinhalten überraschend gut und schnell sein kann.
Für die meisten Einsatzzwecke ist er echtem Lossless vorzuziehen und reduziert die Größe oft zusätzlich um die Hälfte, ohne sichtbare Verluste.
Bei sehr niedrigen Qualitätseinstellungen ist es erstaunlich, dass JPEG trotz sichtbarer Artefakte, die aus der Nähe wie ein kubistisches Durcheinander wirken, eine scharfe Annäherung an Details beibehält, die die Gesamtqualität des Bildes besser bewahrt.
Im Grunde verwandelt es das Bild in irgendeinen abstrakten Kunststil, während JXL und AVIF einfach unscharf werden.
Diese Bilder zielen nicht auf dieselbe Kompressionsrate, sondern auf ein ähnliches Verzerrungsniveau; die Bits pro Pixel stehen neben dem Bild.
Im echten Internet ist Qualität 65 selten und wird höchstens auf Websites mit niedrigster Qualität genutzt; Qualität 75 ist verbreitete niedrige Qualität, Qualität 85 liegt eher im Durchschnitt.
Wenn Kompression nötig ist, verwende ich Qualität 94 yuv444 oder höher.
Die Bitrate steht in der linken Spalte, und das Low-Quality-JPG hat dieselbe Größe wie die mittlere bis niedrige Qualität von JXL/AVIF mit 0,4 bpp; deshalb sollte man das Bild unten links mit dem oberen mittleren und dem rechten Bild vergleichen.
Man sollte sich nicht von einem falschen Vergleich mitreißen lassen; wenn man JXL und AVIF ebenfalls die doppelte Dateigröße gibt, sehen sie deutlich besser aus.
SSIMULACRA2 bestraft Blockartefakte stark, scheint sich aber wenig um Unschärfe zu kümmern; ich stimme zu, dass bei gleichem SSIMULACRA2-Score die JPEG-Version besser aussieht.
Ich verstehe nicht, warum sich der Artikel so stark auf die Encoding-Geschwindigkeit konzentriert, das Decoding, das in Web-Verbindungsumgebungen meiner Ansicht nach 99 % der Nutzung ausmacht, aber nur oberflächlich behandelt.
Es wird ungefähr mit „Decoding-Geschwindigkeit ist auf modernen Computern kein großes Problem, aber ein kurzer Blick auf die Zahlen ist interessant“ abgetan.
Ab diesem Punkt ist der Flaschenhals nicht mehr das Decoding.
Die meisten modernen Kompressionsalgorithmen sind asymmetrisch: Man kann deutlich mehr Zeit in die Kompression investieren, ohne die Dekompressionsleistung stark zu beeinflussen. Sobald die Grundleistung erreicht ist, wird das weniger wichtig.
Falls ja, wäre das ein starkes Argument, sie JPEG XL vorzuziehen, das auf aktueller Hardware komplett in Software decodiert werden muss.
H264-Decoding ist überall vorhanden, und AV1-Decoding entwickelt sich ebenfalls kontinuierlich zu einer Standardfunktion.
Es reicht, wenn der Client die wenigen Bilder einer Seite so schnell decodieren kann, dass Menschen es nicht bemerken; umgekehrt kann schon eine Verbesserung um ein paar Prozent beim Encoding reale Kosten sparen.
Sie geben tatsächlich Millionen von Dollar für Bild-Encoding aus.
Ich musste lachen, als ich QOI im Lossless-Benchmark sah.
Es wird in allgemeiner Endnutzer-Software nicht standardmäßig unterstützt und ist ein im Grunde irrelevantes Format, das eher „ganz okay“ als „gut“ sein will; trotzdem hat es sich einen Platz im Chart für Nicht-Foto-Encoding gesichert, was interessant ist.
Deshalb verwenden GameMaker Studio und Spiele, die ungefähr in den letzten zwei Jahren erstellt wurden, intern tatsächlich QOI.
Verbraucher nutzen es nicht bewusst, aber ganz irrelevant ist es schwerlich.
Rückblickend ist das naheliegend, denn QOI-Decoding ist im Kern sequenziell und lässt sich nicht leicht parallelisieren.
Ich frage mich, ob die Qualität von JXL am Format selbst liegt oder am Encoder.
Die Fähigkeit, allein mit
-d 1.0hochwertige, kleine Bilder zu erzeugen, ist fast unheimlich; bei anderen Codecs musste man je nach Bildtyp unterschiedliche Qualitätseinstellungen wählen, um ähnliche Ergebnisse zu erzielen.Bei diesem Entwicklungstempo würde es mich nicht wundern, wenn libjxl zum x264 unter den Bild-Encodern wird.
Umgekehrt war libvpx immer ein eher durchschnittlicher Encoder, und ich denke, das könnte der Grund für die enttäuschende Leistung des vp8/vp9-Formats sein – nicht nur bei der Geschwindigkeit, sondern bei der Gesamtleistung.
Das hat zwangsläufig auch die Performance von verlustbehaftetem WebP beeinflusst, und Dark Shikari hat auch einmal die Standbild-Performance von x264 und vp8 verglichen [0].
[0] https://web.archive.org/web/20150419071902/http://x264dev.mu...
Der Fokus lag stark auf visueller Verlustfreiheit, und man wollte keine Formatfunktionen aufnehmen, die bei hohen Qualitätseinstellungen nicht helfen, sondern nur die Komplexität erhöhen.
Neben den Modellierungsfunktionen sind Kontextmodellierung und effiziente Entropiekodierung bei hoher Qualität sehr wichtig.
Ich denke, die Entropiekodierung von AVIF passt nicht gut zu hochwertigen oder verlustfreien Fotos.
-d 1.0-Schnittstelle, entwickelt.Erwähnenswert ist auch, dass aus der Arbeit an JPEG XL eine hervorragende neue Parallelisierungsbibliothek namens Highway hervorgegangen ist.
Diese Bibliothek wird nicht nur in JPEG XL verwendet, sondern auch in Googles aktuellen Gemma-AI-Modellen.
In [1] wird es ebenfalls behandelt; der Einstieg lautet: „Heute teilen wir Open-Source-Code, der Zahlen-Arrays etwa 10-mal schneller sortiert als C++
std::sort, dabei auf allen modernen CPU-Architekturen portabel bleibt und dennoch schneller ist als aktuelle architekturspezifische Algorithmen. Im Folgenden besprechen wir, wie wir das erreicht haben.“[0] https://github.com/google/highway
[1] https://opensource.googleblog.com/2022/06/Vectorized%20and%2..., das zugehörige Paper ist https://arxiv.org/pdf/2205.05982.pdf
Es scheint der beste Weg zu sein, portables SIMD in C++ zu bekommen.
Unabhängig davon, wie sehr JPEG XL für sich genommen glänzt, ist allein schon die folgende Fähigkeit wirklich beeindruckend:
a.jpgist 615504 Byte groß und hat den SHA-1716744d950ecf9e5757c565041143775a810e10f.Führt man
cjxl a.jpg a.jxlaus, liest es das 615504-Byte-JPEG und komprimiert es inklusive Container auf 537339 Byte.Führt man dann aber
djxl a.jxl b.jpgaus, liest es die 537339 Byte komprimierter Daten und rekonstruiert daraus ein JPEG; auchb.jpgist 615504 Byte groß und hat exakt denselben SHA-1.Wenn man bedenkt, dass es weltweit Milliarden von JPEG-Dateien gibt, die man erhalten möchte: Wenn man bestehende JPEGs erneut in ein verlustbehaftetes Format komprimiert, sinkt die Qualität.
JPEG XL kann jedoch 15–30 % einsparen und bei Bedarf das ursprüngliche JPG bitgenau zu 100 % wiederherstellen.
Wirklich großartig.
Leider nutze ich Debian stable 12 Bookworm mit ImageMagick 6.9, und meines Wissens verwendet Emacs vermutlich ImageMagick zur Bildanzeige.
JPEG-XL-Unterstützung wurde erst in ImageMagick 7 hinzugefügt, und ich bin dem noch nicht weiter nachgegangen.
Ich denke, es wird helfen, digitales Kulturerbe vollständig zu bewahren, ohne verlustbehaftetes Re-Encoding.
Sehr beeindruckend ist, dass die neue Version von libjxl den Speicherverbrauch sowohl bei verlustbehafteter als auch bei verlustfreier Kompression um Größenordnungen reduziert und zugleich die Geschwindigkeit verbessert hat.
Besonders gefällt mir, dass die Standard-Effort-Einstellung für multithreaded verlustfreies Encoding jetzt um Größenordnungen schneller ist; der Artikel ist außerdem gut geschrieben.
Ich frage mich, ob es eine Website gibt, die die einzelnen Schritte des JPEG-XL-Formats im Detail erklärt.
Anders als beim klassischen JPEG war es schwer, Dokumentation zu finden, die die relevanten Schritte klar erläutert, was schade ist, weil in diesem Format offensichtlich viele interessante Innovationen gebündelt sind.
Auch die einzelnen Komponenten dürften für sich genommen nützlich sein.
Kernpunkte sind DCT mit variabler Größe bis zu 128x128, ANS-Entropievorhersage und luma-basierte Chroma-Vorhersage.
https://github.com/libjxl/libjxl/blob/main/doc/encode_effort... zeigt auch gut, welche Funktionen zu welchen Effort-Stufen gehören.
Im Artikel fehlt rav1e, das AV1 und damit AVIF encodiert.
rav1e ist deutlich schneller als die Referenzimplementierung aom; es gab Fälle, in denen aom selbst nach einer Minute die Bildumwandlung nicht abgeschlossen hatte, während rav1e weniger als 10 Sekunden brauchte.
Außerdem frage ich mich, ob das schnelle rav1e bei hohen Encoding-Geschwindigkeiten besser aussieht als jpegli.
Bei ähnlicher Geschwindigkeit habe ich zwischen beiden keine großen Unterschiede in der Kompressionsleistung gesehen.