Microsoft veröffentlicht die JPEG-XL-Bilderweiterung für Windows
von caschy | 17 Kommentare
Windows-Anwender können jetzt die JPEG-XL-Bilderweiterung im Microsoft Store herunterladen. Vorausgesetzt wird derzeit Windows 11 24H2. Die JPEG XL-Bilderweiterung ermöglicht Windows das Anzeigen und Speichern von Dateien, die die Dateierweiterung „.jxl“ verwenden. Ein Vorteil des Formats liegt in der Abwärtskompatibilität. Interessierte Anwender können bestehende JPEG-Dateien verlustfrei in das XL-Format umwandeln und dabei die Dateigröße deutlich reduzieren. Diese Dateien lassen sich bei Bedarf wieder exakt in das ursprüngliche JPEG-Format zurückwandeln.
- Automatische Staubaufnahme: Genießen Sie eine Reinigung ohne manuellen Aufwand mit unserem...
Transparenz: In diesem Artikel sind Partnerlinks enthalten. Durch einen Klick darauf gelangt ihr direkt zum Anbieter. Solltet ihr euch dort für einen Kauf entscheiden, erhalten wir eine kleine Provision. Für euch ändert sich am Preis nichts. Partnerlinks haben keinerlei Einfluss auf unsere Berichterstattung.
Wird geladen ...
Das bedeutet dann, dass meine Bilddateien bei gleicher Auflösung im .jxl Format dann weniger Speicherplatz benötigen, als wenn ich sie als .jpg speichere?
Und wenn ich das Format installiere, kann ich es dann bespielsweise auch in Paint nutzen?
Im Prinzip genau das
https://jpeg.org/jpegxl/#:~:text=Overview%20of%20JPEG%20XL&text=Existing%20JPEG%20files%20can%20be,with%20existing%20JPEG%2Dbased%20applications.
So verrückt das auch klingen mag. Daher eignet sich JPEG XL auch zur Archivierung von alten .jpg Dateien.
Man kann sie (das richtige Programm vorausgesetzt!) 1:1 verlustfrei als .jxl speichern und Jahre später die ehemalige .jpg Datei wieder daraus extrahieren.
Hat aber in der Zwischenzeit 20% also 1/5 an Speicherplatz gespart.
Wichtig ist aber, dass das erstmal nur die Theorie ist und man auch gewisse Hinweise beachten muss, damit das auch wirklich gegeben ist:
https://www.datahoards.com/lossless-conversion-from-jpg-to-jxl/
und man kann .jxl Dateien nicht einfach wie .jpg öffnen, also man sollte sie derzeit noch nicht per Mail versenden. Speziell da Google mit seiner Marktmacht ein anderes Bildformat möchte: AVIF. (basierend auf dem Videocodec AV1)
Ich kann mir vorstellen, dass die Implementierung in Windows nämlich nicht verlustfrei konvertiert (was aber auch etwas zusätzlichen Platz einspart, da ist man dann eher bei bis zu 60% Ersparnis bei der gleichen visuellen Qualität (geprüft auf Sicht), abhängig vom Bild)
https://beebom.com/what-is-jpeg-xl/
Allgemein hat .jxl einige Funktionen, die dem allgegenwärtigen .jpg fehlen.
Animationen, 10bit Support (HDR).
und das Dateiformat braucht in der Theorie keine Vorschau mehr. Es reicht die ersten X Byte der Datei zu laden für eine geringere Auflösung.
Also selbst wenn da ein 16K x 16K Bild liegt, kann ein Dateimanager als Vorschau davon 128×128 Pixel laden, ohne davon eine Abziehkopie machen zu müssen, die dann zusätzlichen Platz belegt. (Dasselbe Prinzip gilt theoretisch auf für hochauflösende Bilder auf Webseiten, wenn Browser die für eine kleine Ansicht laden, aber hier steht Google massiv im Weg)
Allgemein wirbt .jxl fast schon utopisch damit so gut wie alles besser zu können wie die Konkurrenz aber in nur einem Dateiformat. (während die Konkurrenz nur manche der Vorteile abdeckt aber nie alle)
Allgemein ist .jxl etwas besser als .webm, heif und avif, da es wirklich als Bildformat konstruiert wurde.
der größte Vorteil ist aber (z. B. gegenüber Heif), dass es jeder Hersteller frei nutzen und einbauen kann ohne Royalties (Lizenzen) zahlen zu müssen. Damit könnte das Format irgendwann wieder so allgegenwärtig wie jpg werden. (wird es natürlich nie)
Aber wer will, kann es auch jetzt schon für sich selber und die eigene Fotosammlung einsetzen.
Ich bin gespannt, wie der Codeckrieg diesmal ausgeht.
Apple hat sich ja vor Jahren mal für HEIF entschieden. Google will auf Dauer von jpg zu AVIF. Und nutzt für Videos bereits HEVC (der Unterbau von HEIF).
Apple hat aber mit dem iPhone 16 angefangen, dass man RAW-Fotos auch als .jxl speichern kann
Wann Adobe Breite Unterstützung erhält muss sich noch zeigen. Der DNG Converter beherrscht es offenbar jetzt aber mehr schlecht als recht.
https://www.reddit.com/r/jpegxl/comments/1gqd03r/adobe_dng_converter_has_lossless_jxl_support/
es tut sich auf jedenfall was
Quality conent! Danke für diese Erklärung – besser als jeder Blogpost
danke dir, fürs erklären, sehr schön zu lesen
Wieso bekommt man bei Windows 11 Pro 23H2 keine Option auf 24H2 angeboten? PC-Integritätsprüfung zeigt alles in grün…
Vielleicht hast du noch irgendwas installiert was ein Upgrade Blocker ist.
Die aktuellen Sachen stehen hier (z. B. AutoCAD 2022)
https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-24h2#known-issues
Es gibt diverse Ausschlusskriterien für Win11 24H2.
Vielleicht ringt Dich dieser Artikel weiter:
https://windowsarea.de/2024/10/windows-11-24h2-update-probleme-diese-nutzer-bekommen-das-update-nicht/
Danke euch, ich habe den Windows11InstallationAssistant geladen. Mit dem ging es beim 2. Mal.
Nach der Installation werden mir weder Explorer Thumbnails angezeigt, noch lassen sich jxl in Paint oder Snipping Tool laden (auch nicht nach Neustart).
Nutzen also unbekannt…
Zurück zu https://github.com/saschanaz/jxl-winthumb
@Caschy Du schreibst, dass sich interessierte Anwender bestehende Bilder wandeln können mit der MS Software oder Drittsoftware?
Dritt.
Das wird hier ausführlich erklärt:
https://www.datahoards.com/lossless-conversion-from-jpg-to-jxl/
Ich verstehe die Aussage mit der Abwertskompatibilität nur mäßig. Insbesondere die verlinkte Quelle lässt mich da ein Bischen ratlos zurück.
Ich kann ein bestehendes JPEG-File in JPEG-XL transcodieren. Ja Ok, verstehe ich. Mit dem gleichen Argument ist DVD zu VHS kompatibel, weil ich alles was auf der VHS steht, auch auf eine DVD bringe. Und umgekehrt, ich kann dann diesen Inhalt wieder zurück zu JPEG bringen. Auch da verstehe ich: Sofern ich dann nicht im Nachhinein den Inhalt der DVD nicht besser mache, indem ich z.B. 5.1 Audio dazu baue, das die VHS gar nicht hatte, kann ich nachher den DVD-Inhalt wieder zurück auf eine VHS spielen.
Hieraus entnehme ich erst mal, dass sämtliche „Abnahmekriterien“, was Inhalt und Qualität von JPEG bieten musste, ein Subset von JPEG-XL sind, sodass ich verlustfrei hin und her konvertieren kann. Insbesondere sollen sich bei mehrfachen Transcodierungsschritten zwischen den Formaten nicht neue Verluste aufbauen und das Ergebnis immer schlechter werden (wenn ich 90 % Qualität einstelle, dann soll ich auch nach 100 Transcodierungen in beide Richtungen noch ein 90%-Ergebnis haben, und nicht 60 % weil bei jedem Schritt 10 % verloren gehen).
Das alleine ist für mich aber immer noch nicht die Definition zu „abwärtskompatibel“. Dazu müsste vielmehr „überall wo das neu reinpasst, auch da alte reinpassen“. Also: Jedes Tool, das JPEG-XL kann, kann automatisch auch JPEG.
Damit das gilt, muss aber wiederum JPEG-XL nicht direkt kompatibel sein. Das geht vermutlich nämlich auch „einfach so“. Sofern Adobe die Lib zur JPEG-Behandlung nicht aus Photoshop entfernt, sondern einfach JPEG-XL dazu baut, bleibt Photoshop ja kompatibel zu beiden. Ganz ohne, dass JPEG und JPEG-XL zueinander kompatibel sind.
Damit die Aussage nicht mehr oder weniger Quark ist, muss es ein bestimmtes standardkonformes JPEG-XL-File geben, das gleichzeitig ein standardkonformes JPEG-File ist. Mindestens, wenn man es von der richtigen Seite aus anschaut.
Und tatsächlich steht das, wenn ich das richtig interpretiere, so in der verlinkten Quelle:
„Migrating to JPEG XL reduces storage costs because servers can store a single JPEG XL file to serve both JPEG and JPEG XL clients“
Also sowas wie: Die ersten 250kB der Datei sind JPEG, danach kommen weiter 150kB JPEG-XL, und der Apache-Webserver soll beim Ausliefern je nach Client-Anfrage entweder die ersten 250kB ausliefern oder die hinteren 150.
Das ist aber seit 100 Jahren ein gelöstes Problem:
* Webserver speichert foo.jpeg
* Client fragt nach „foo.jpeg, aber ich kann auch webp“
* Webserver prüft, ob foo.jpeg.webp im Dateisystem liegt
* und liefert dann webp aus wenn verfügbar, ansonsten jpeg.
* Irgend wann in der Zukunft kommt ein Konvertierungsprozess, der auf der Festplatte des Websevers alle jpeg-Datei nimmt, in webp konvertiert und neben der Quelldatei speichert.
Die Idee ist aber auf kein Dateiformat beschränkt, sondern lässt sich auf alle Dateiformate anwenden, die Bilder sind, und auf alle Dateiformate, die Videos sind ebenfalls. Das kann es also, fürchte ich, nicht sein.
Damit eine „Kompatibilität innerhalb des Dateiformats“ gerechtfertigt ist und gleichzeitig die Aussage „Migrating to JPEG XL reduces storage costs“, müsste man sowas gelten wie:
* In den ersten 50kB stehen Daten, die JPEG und JPEG-XL gemeinsam haben
* dann kommen 200kB Daten die nur JPEG hat, wenn man sie den ersten 50kB hinzufügt,
* dann kommen 100kB Daten die nur JPEG-XL hat, wenn man sie den ersten 50kB hinzufügt.
Dann wäre „JPEG-XL das auch gleichzeitig JPEG ist“ zwar größer als JPEG und größer als JPEG-XL, aber immerhin wäre das JPEG-kompatible JPEG-XL kleiner als zwei Einzeldateien. Das wäre ja auch schon ein Vorteil.
Viel komplizierter, würde ich sagen, darf das aber nicht sein. Sonst würde man billigen Speicher gegen teure CPU tauschen, und das ist ja eher ein Nachteil.
Natürlich heißt das nicht, dass JPEG-XL Quatsch ist. Wenn es für sich alleine in ein paar Aspekten besser als JPEG ist, ist das ja auch schon ausreichend. Nur kann ich mir nicht zusammenreimen, wo da die Kompatibilität sein könnte (die über die grundlegende Kompatibilität von Bildern zueinander hinaus geht) und deshalb nicht ganz verstehe, warum das das Verkaufsargument ist.
Beschäftige dich mal damit wie JPEG arbeitet. Mit diskreter Kosinus-Transformation (DCT, darauf basiert JPEG und ist erstmal eine verlustfreie Umwandlung) werden die Farbwerte der einzelnen Farbkanäle eines Pixelblocks in „Wellen“ gewandelt (bzw. Koeffizienten für entsprechend viele Einzelwellen). Der Verlust erfolgt erst durch die anschließende Quantisierung, sprich: Gewichtung der Koeffizienten (weniger für das Bild ausschlaggebende Koeffizienten werden eingespart – und „0“-Folgen sind gut komprimierbar). Die quantisierten Koeffizienten werden dann mit einem „ganz normalen“ Komprimierungsalgorithmus komprimiert.
–> Nutze ich also die immer selbe Quantisierungsmatrix (Qualitätsstufe) beim erneuten Speichern, dürfte es keine neuen Verluste geben. Und dann kann man auch zwischen den Formaten wandeln, da (vermutlich) nur die Komprimierung, nicht aber die Quantisierung geändert wird.
Laut https://gnulinux.ch/jxl-wird-jpg-abloesen soll aber auch ein JPEG-Anteil in eine JXL-Datei eingebettet werden können – dann ist die Datei (auf dem Server) größer, aber nur der passende Teil würde ausgeliefert.
In der verlinkten Quelle: https://jpeg.org/jpegxl/index.html steht dann noch „Existing JPEG files can be losslessly transcoded to JPEG XL, significantly reducing their size. These can be restored into the exact same JPEG file, ensuring backward compatibility with existing JPEG-based applications.“
Vielleicht hier noch etwas Background zu Bildformaten: https://u-labs.de/portal/die-3-bildformate-der-zukunft/
Tatsächlich geht es nicht um Kompatibilität anders als beim Audiocodec AAC, von dem es Varianten gibt, die mit dem korrekten Decoder auch bei geringeren Bitraten besser klingen aber rückwärtskompatibel bleiben (dann nur schlechter klingen).
Es geht um Archivierung und Storage.
Du kannst als Serverbetreiber (Oder Privatpersonen) alle bisherigen jpg Dateien verlustfrei in jxl als Dateiformat umziehen, 20% Speicherplatz sparen und sie beim Abruf von legacy-Clients On-the-fly zurück konvertieren nach jpg und erhältst wirklich (inkl. Metadaten) original dieselbe jpg Datei zurück (gleiche Checksum)
Solange jxl sich aber nicht weit verbreitet ist das nur semi nützlich, weil man dann meistens konvertieren muss. (wobei das vermutlich nicht so viel cpu braucht, wie du annimmst)
Auf Dauer kann jxl dann aber Speicherplatz sowie Bandbreite sparen (weil Browser die Bilder auch nicht vollständig herunterladen müssen und man sich Vorschaudateien sparen kann. Wer die Datei am Ende kürzt/nur teilweise herunterlädt erhält eine niedriger aufgelöste Vorschau)
hier habe ich auch noch Infos dazu gefunden, die mir bis gerade neu waren
https://forum.xnview.com/viewtopic.php?t=44150
Also ja ich weiß auch nicht alles dazu, momentan ist die Verbreitung des neuen Codecs noch begrenzt. Größtenteils, weil sich Mozilla und Google sträuben.
Das hat teils nachvollziehbare Gründe, teilweise ist es Firmenpolitik, weil man das eigene Format AVIF pushen möchte, damit es nicht in der Versenkung verschwindet.
Ist denn der Support für JPEG-XL in Chrome und Firefox wieder vorhanden? Mein letzter Stand war, dass die Beiden den Support dafür rausgeworfen haben und bisher nichts mehr in diese Richtung unternommen wurde.
Zumindest dieser Website nach sieht es immer noch danach aus, dass nur Safari das Ganze unterstützt: https://caniuse.com/jpegxl
Absolut richtig.
Nach aktuellem Stand kein jxl in beiden Browsern und deren Derivaten. Nur in der Nightly von Firefox und wenn man es dort aktiviert. (das wird so nie in Beta/Release landen)
Es gab aber letzten Herbst eine Aussage, dass man bereit ist das zu reevaluieren, wenn jemand einen Decoder entwickelt, der speichersicher (memorysafe) ist (Wunschprogrammiersprache Rust) und Google Entwickler (unerwartet) haben offenbar Interesse geäußert das doch umzusetzen. Man darf gespannt sein und abwarten.
https://www.soeren-hentzschel.at/firefox/neue-hoffnung-fur-bildformat-jpeg-xl/
Im Internet wird jxl wohl in den nächsten 3-5 Jahren keinerlei Verbreitung finden außer auf Webseiten für Fotografen vielleicht für 10bit-Fotografie. Aber dann auch eher zum Herunterladen, weil Browser nicht dafür bekannt sind mehr als 8bit korrekt darzustellen, weil Farbtheorie deutlich komplizierter ist.