Το JPEG XL δημιουργήθηκε ως διάδοχος του JPEG, όμως η υιοθέτησή του έμεινε πίσω σε σχέση με τα WebP και AVIF.
Αυτό άλλαξε μέχρι τα τέλη της περασμένης χρονιάς, όταν η PDF Association ανακοίνωσε ότι θα υποστηρίξει το JPEG XL σε αρχεία PDF και η Google εξέφρασε τη βούληση της να ενσωματώσει υποστήριξη για το συγκεκριμένο format στο Chrome—κάτι που έκανε και την περασμένη εβδομάδα.
Ο Jon Sneyers, ένας από τους θεμελιωτές του JPEG XL, εξηγεί:
«Αυτό μπορεί να γίνει το standard codec για εικόνες.»
Πως ξεκίνησε το JPEG XL και γιατί “κόλλησε” η υιοθέτηση
Η δουλειά για το format JPEG XL ξεκίνησε τον Ιανουάριο του 2019, αφού η επιτροπή JPEG κάλεσε το 2018 τους developers να υποβάλουν προτάσεις για έναν διάδοχο του JPEG.
Τελικά, η επιτροπή αποφάσισε να συνδυάσει δύο προτάσεις:
- το Pik της Google
- το Free Universal Image Format (FUIF) του Sneyers
Τον Μάρτιο του 2022, το format τυποποιήθηκε επίσημα από τον διεθνή οργανισμό προτυποποίησης ISO.
Παρόλα αυτά, η υιοθέτηση στους browsers ήταν «ανώμαλη»: η Google ξεκίνησε υποστήριξη JPEG XL τον Φεβρουάριο του 2022 και τη σταμάτησε τον Νοέμβριο του 2022.
Παράλληλα, και η Mozilla σταμάτησε την ανάπτυξη μιας υλοποίησης JPEG XL, η οποία υπήρχε ήδη στην πειραματική Nightly έκδοση του Firefox.
Με αυτά τα δύο «χτυπήματα», το JPEG XL (ως web standard) έμοιαζε σχεδόν καταδικασμένο.
Μετά, όμως, η υιοθέτηση πήρε την ανηφόρα:
- 2023: Η Apple, απρόσμενα, ανακοίνωσε υποστήριξη JPEG XL στο Safari.
- 2024: Η Mozilla αναθεώρησε και δήλωσε ενδιαφέρον για υλοποίηση JPEG XL σε Rust.
- Έπειτα: Ακολούθησαν οι ανακοινώσεις από PDF Association και Google.
Η Google πλέον υποστηρίζει τον decoder jxl-rs (βασισμένο σε Rust) στο πειραματικό Chrome Canary, αν και προς το παρόν το αντίστοιχο “flag” παραμένει απενεργοποιημένο από προεπιλογή.
Το JPEG XL ήδη υποστηρίζεται από δημοφιλή software επεξεργασίας εικόνων όπως GIMP, Krita και Adobe Camera Raw, και δείχνει ότι κατευθύνεται προς ευρύτερη υιοθέτηση και στο web.
Πίνακας: JPEG XL vs WebP vs AVIF (τι κερδίζει το web)
| Χαρακτηριστικό | JPEG | WebP | AVIF | JPEG XL |
|---|---|---|---|---|
| Κύρια στόχευση | Φωτογραφίες | Web images | Υψηλή συμπίεση (από AV1) | “Next-gen” εικόνες (ειδικά για images) |
| Lossless δυνατότητες | Περιορισμένες | Ναι | Ναι | Ναι (και lossless “recompress” JPEG) |
| Lossless επανασυμπίεση JPEG (μικρότερο αρχείο χωρίς απώλεια) | Όχι | Όχι | Όχι | Ναι (~20% μικρότερο, σύμφωνα με το κείμενο) |
| Προοδευτική φόρτωση (preview → βελτίωση) | Ναι | Όχι (τυπικά) | Όχι (τυπικά) | Ναι |
| Σχεδιασμένο ως “image codec” (όχι video-derivative) | Ναι | Όχι (από VP8) | Όχι (από AV1) | Ναι |
| Παράλληλη κωδικοποίηση/αποκωδικοποίηση | Περιορισμένη | Περιορισμένη | Εξαρτάται από υλοποίηση | Ναι (καλύτερη αξιοποίηση multi-core) |
Σημείωση: Η πραγματική υποστήριξη σε browsers/OS αλλάζει συχνά και εξαρτάται από εκδόσεις, flags και συγκεκριμένες υλοποιήσεις.
«Έκπληξη» από τη Google
Τα νέα για την πρόθεση της Go
ogle να ενσωματώσει JPEG XL στο Chrome στα τέλη Νοεμβρίου ήρθαν απρόσμενα για τον Sneyers:
«Περίμενα ότι το Chrome αργά ή γρήγορα θα άλλαζε γνώμη, αλλά τόσο ξαφνικά δεν το περίμενα.
Ήταν έκπληξη—όπως έκπληξη (αρνητική) ήταν και το σταμάτημα της υποστήριξης στα τέλη του 2022.»
Παρόλα αυτά, ο Sneyers έβλεπε ήδη τα σημάδια: η Apple το υποστήριζε στο Safari και στα λειτουργικά της, η Microsoft το υποστηρίζει στα Windows, η Adobe στο Photoshop και η Mozilla είχε αλλάξει θέση.
Το Chrome ήταν σχεδόν ο μόνος μεγάλος παίκτης που δεν είχε δηλώσει ανοιχτά υποστήριξη.
«Δεν υπάρχει ενδιαφέρον από developers»; Η αντίρρηση του Sneyers
Η Google, όταν σταμάτησε την υποστήριξη JPEG XL στο Chrome, ανέφερε ως βασικό λόγο την «έλλειψη ενδιαφέροντος από developers».
Ο Sneyers αμφισβητεί αυτό το συμπέρασμα:
- Δεν έγινε σοβαρή προσπάθεια να μετρηθεί το ενδιαφέρον των web developers.
- Υπάρχουν πρακτικές όπως τα origin trials, όπου μια νέα λειτουργία ενεργοποιείται δοκιμαστικά σε συγκεκριμένα sites/apps.
- Η Cloudinary (όπου εργάζεται ο Sneyers) ζήτησε origin trial ώστε να σερβίρει JPEG XL που θα λειτουργούσαν στο Chrome χωρίς παγκόσμια υποστήριξη—όμως τέτοια πειράματα, όπως λέει, ουσιαστικά δεν έγιναν.
Επιπλέον, όταν κάτι είναι πίσω από flag που είναι off by default, ελάχιστοι χρήστες το ενεργοποιούν.
Στο Chrome για Android, μάλιστα, τέτοιες σημαίες δεν μπορούν καν να ενεργοποιηθούν, άρα είναι δύσκολο να εκτιμηθεί ζήτηση.
«Όλοι γνωριζόμαστε»: WebP, AVIF και το φαινόμενο “not invented here”
Η Google έχει δικό της codec (WebP) και συμμετέχει στην Alliance for Open Media, που ανέπτυξε το AVIF.
Ο Sneyers θεωρεί πιθανό ότι αυτό έπαιξε ρόλο στο να καθυστερήσει η ενσωμάτωση του JPEG XL στο Chrome:
«Έχω την αίσθηση ότι κάποιοι decision makers στο Chrome είναι οι ίδιοι άνθρωποι που έφτιαξαν το WebP και τώρα δουλεύουν και στο AVIF, οπότε υπάρχει μια κουλτούρα τύπου “not invented here”.
Είναι ειρωνικό, γιατί το JPEG XL το ανέπτυξα μαζί με ανθρώπους της Google και την επιτροπή JPEG—αλλά αυτό είναι άλλη “γραμμή” μέσα στη Google, εκτός Chrome team.»
Η κριτική στα tests της Google (AVIF vs JPEG XL)
Λίγο μετά τη διακοπή υποστήριξης, η Google δημοσίευσε test report που παρουσίαζε το AVIF ως ανώτερο από το JPEG XL.
Ο Sneyers διαφωνεί έντονα (και το έχει γράψει και σε blog), κυρίως γιατί:
- Δεν υπήρξε ανθρώπινη αξιολόγηση ποιότητας (να κοιτάξουν οι άνθρωποι τις εικόνες). Χρησιμοποιήθηκαν μόνο αλγόριθμοι.
- Χρησιμοποιήθηκε, μεταξύ άλλων, το MS-SSIM, που συχνά εφαρμόζεται στο YCbCr. Το AVIF δουλεύει σε αυτή τη χρωματική περιοχή και μπορεί να “tune-αριστεί” για να γράφει καλά.
Το JPEG XL χρησιμοποιεί XYB, που προσεγγίζει καλύτερα την ανθρώπινη αντίληψη χρώματος. - Οι εικόνες στα tests ήταν σε υπερβολικά χαμηλή ποιότητα (0,1 έως 3 bits ανά pixel).
«Εκεί μπορεί να κερδίζει το AVIF, αλλά είναι άσχετο πρακτικά, γιατί κανείς δεν θέλει τόσο επιθετική συμπίεση στο web», λέει ο Sneyers.
Και προσθέτει: το μεγάλο κέρδος είναι συχνά στη υψηλότερη ποιότητα. Π.χ. από 30KB σε 20KB έχεις 33% σχετικό κέρδος, αλλά από 300KB σε 200KB έχεις πολύ μεγαλύτερο απόλυτο όφελος.
Γιατί JPEG XL; (και γιατί δεν είναι “video codec σε μεταμφίεση”)
Το ότι το JPEG XL μπορεί με λιγότερο επιθετική συμπίεση να δίνει καλύτερα αποτελέσματα, οφείλεται (μεταξύ άλλων) στο ότι είναι πραγματικός image codec.
Αντίθετα, τα WebP και AVIF είναι ουσιαστικά image codecs που προέρχονται από video codecs (VP8 και AV1 αντίστοιχα).
Αυτό έχει μειονεκτήματα για εικόνες:
Video προτεραιότητες ≠ image προτεραιότητες
Στα βίντεο έχεις πολλά καρέ ανά δευτερόλεπτο, άρα τα artifacts «χάνονται» πιο εύκολα. Αυτό οδηγεί σε άλλες επιλογές σχεδίασης.
Επιθετικά φίλτρα και “πλαστική” εικόνα
Οι video codecs συχνά χρησιμοποιούν φίλτρα που μειώνουν τα blocks “εξομαλύνοντας” πολύ την εικόνα.
Αυτό βοηθά σε χαμηλή ποιότητα, αλλά σε υψηλότερη ποιότητα μπορεί να “τρώει” λεπτομέρεια και να δίνει ένα πλαστικό look.
Directional prediction (κατευθυντική πρόβλεψη)
Η πρόβλεψη «αν υπάρχει μια γραμμή, συνεχίζει προς την ίδια κατεύθυνση» βοηθά σε χαμηλή ποιότητα ώστε να βγαίνει κάτι αξιοπρεπές, αλλά:
- περιορίζεται σε λίγες κατευθύνσεις
- μπορεί να προκαλέσει παραμορφώσεις/smudging
- σε υψηλή ποιότητα είναι συχνά περιττή
«Μορς» και entropycoding: το μεγάλο πλεονέκτημα σε υψηλή ποιότητα
Για εικόνες υψηλότερης ποιότητας, ο Sneyers θεωρεί ότι πιο σημαντικό είναι το ισχυρό entropy coding: μια μορφή lossless συμπίεσης που δίνει σύντομους κώδικες σε συχνά στοιχεία και μακρύτερους σε σπάνια—όπως ο κώδικας Μορς δίνει μικρότερους κώδικες στα συχνά γράμματα σε σχέση με γράμματα όπως Q ή X.
Αν και μπορεί να γίνει σε hardware και software, είναι δύσκολο να υλοποιηθεί πολύ ισχυρό entropycoding σε hardware.
Οι video codecs πρέπει να παίζουν σε κάθε είδους συσκευή (και κινητά με μπαταρία), ενώ τα βίντεο μπορεί να διαρκούν ώρες—αν «λιώσει» η CPU, είναι πρόβλημα.
Γι’ αυτό οι κατασκευαστές χρησιμοποιούν ειδικά chips (ASIC) για video decode: πολύ αποδοτικά ενεργειακά, αλλά περιορίζουν την πολυπλοκότητα του codec (για να μην γίνουν τεράστια/ακριβά). Στις εικόνες, δεν χρειάζεται ειδικό hardware: η συμπίεση μιας εικόνας μπορεί να γίνει άνετα στην CPU.
Lossless “JPEG recompression” έως ~20% μικρότερο
Ένα εντυπωσιακό αποτέλεσμα του entropycoding στο JPEG XL είναι ότι μπορεί να πάρει υπάρχον JPEG και να το κάνει lossless περίπου 20% μικρότερο, χωρίς να χάσει λεπτομέρεια.
Η διαφορά δεν είναι στα δεδομένα της εικόνας, αλλά στον τρόπο αποθήκευσής τους.
Asymmetric Numeral Systems (ANS): τι αλλάζει σε σχέση με Huffman
Για να πετύχει αυτά τα κέρδη, το JPEG XL φέρνει πολλές βελτιώσεις σε σχέση με το JPEG.
Το JPEG βασίζεται κυρίως σε Huffman coding, μια μορφή prefix coding που φτιάχνει ένα “δέντρο” συχνοτήτων και δίνει πιο κοντινούς/σύντομους κώδικες στα συχνά σύμβολα.
Είναι απλό και γρήγορο, αλλά λιγότερο αποδοτικό, γιατί δουλεύει με ολόκληρα bits: αν κάτι έχει θεωρητικά πληροφορία < 1 bit, πάλι “πληρώνει” 1 bit.
Το JPEG XL χρησιμοποιεί Asymmetric Numeral Systems (ANS), που συνδυάζει την ταχύτητα του prefix coding με την αποδοτικότητα της αριθμητικής κωδικοποίησης.
Η μέθοδος αναπτύχθηκε από τον Jarek Duda και χρησιμοποιείται, μεταξύ άλλων, στους αλγορίθμους συμπίεσης Zstandard (Facebook) και LZFSE (Apple).
Πως λειτουργεί (απλουστευμένα)
- Κατά το encoding, τα δεδομένα αποθηκεύονται σε έναν “state” αριθμό.
- Όσο πιο πιθανό ένα σύμβολο, τόσο λιγότερο μεγαλώνει ο state.
- Όταν ο state περάσει ένα όριο, bits “ξεχειλίζουν” προς το bitstream (το τελικό αρχείο).
Έτσι, πληροφορία μπορεί να αποθηκευτεί και σε λιγότερο από 1 bit. Ένα σύμβολο με πιθανότητα 90% καταλαμβάνει περίπου 0,15 bits.
Range-ANS, ακρίβεια πιθανοτήτων και context modeling
Το JPEG XL υλοποιεί range-ans:
- state 32 bits
- κατανομές πιθανοτήτων με ακρίβεια 12 bits (4096 σημεία)
Σε απλό Huffman, ακριβείς πιθανότητες είναι μόνο της μορφής 1/2ⁿ (50%, 25%, 12,5% κ.λπ.). Στο ANS του JPEG XL, μπορούν να εκφραστούν πιθανότητες της μορφής x/4095 (π.χ. 4094/4095 = 99,97% ή 1/4095 = 0,024%).
Το JPEG XL χρησιμοποιεί επίσης context modeling: «ομαδοποιεί» τμήματα εικόνας με παρόμοια histogram, ώστε να χρειάζονται λιγότεροι πίνακες—μειώνοντας το overhead.
Το μέγιστο πλήθος πινάκων μετά το clustering είναι 255, ώστε οι αναφορές να χωράνε σε 1 byte.
Υψηλό color depth και υβριδική integer κωδικοποίηση
Το JPEG XL υποστηρίζει βάθη χρώματος έως 32 bits. Για να κρατάει τους πίνακες συμπαγείς όταν υπάρχει πολύ μεγάλο πλήθος πιθανών συμβόλων, χρησιμοποιεί hybrid integer coding:
- μικροί αριθμοί (συχνότεροι) κωδικοποιούνται πλήρως με ANS
- σπάνια σύμβολα γράφονται εν μέρει “raw” (ασυμπίεστα) στο bitstream, χωρισμένα σε token + raw bits
«Περιμένοντας τις εικόνες»: προοδευτική φόρτωση, checksum και multi-core
Πέρα από το ισχυρό entropycoding, το JPEG XL έχει κι άλλα πρακτικά πλεονεκτήματα:
Προοδευτική φόρτωση (progressive loading)
Σε αντίθεση με WebP και AVIF, το JPEG XL υποστηρίζει progressive loading: σε μια web σελίδα εμφανίζεται γρήγορα μια χαμηλής ποιότητας προεπισκόπηση, η οποία βελτιώνεται όσο φορτώνουν δεδομένα.
Το WebP και το AVIF συχνά χρειάζονται να κατέβει όλο το αρχείο πριν εμφανιστεί εικόνα, άρα ο χρήστης μπορεί να βλέπει άδειο πλαίσιο.
Ενσωματωμένο checksum
Το encoding ξεκινά από την τιμή 0x00130000 και μετά το decoding πρέπει να επιστρέψει στην ίδια τελική κατάσταση. Αν όχι, μπορεί να υπάρχει αλλοίωση δεδομένων (π.χ. από σφάλματα μεταφοράς).
Παράλληλο encoding/decoding
Το JPEG XL μπορεί να κωδικοποιηθεί και να αποκωδικοποιηθεί παράλληλα, μοιράζοντας δουλειά σε πολλούς πυρήνες CPU.
Ο Sneyers αναφέρει ότι δεν είναι απολύτως γραμμικό, αλλά είναι κοντά: με 8 cores μπορεί να πάει περίπου 7 φορές πιο γρήγορα.
Σε JPEG και WebP αυτό το όφελος δεν υπάρχει στον ίδιο βαθμό: π.χ. στο Photoshop, είτε έχετε 2 είτε 20 cores, το φόρτωμα δεν επιταχύνεται αναλόγως.
Πρακτικό tip για webmasters (εμπλουτισμός)
Πώς να το σερβίρετε χωρίς να “σπάει” η εικόνα
Μέχρι να γίνει πλήρως καθολική η υποστήριξη, η ασφαλής προσέγγιση είναι να σερβίρετε JPEG XL με fallback (π.χ. AVIF/WebP/JPEG) μέσω <picture>:
- Βάζετε πρώτα τα νεότερα formats (π.χ. jxl/avif/webp)
- Και στο τέλος ένα κλασικό JPEG/PNG για συμβατότητα
Έτσι εκμεταλλεύεστε τα οφέλη όπου γίνεται, χωρίς να εμφανίζεται «σπασμένη εικόνα» σε browsers που δεν το υποστηρίζουν.
