Apakah Google menghidupkan kembali dukungan JPEG XL?

 (tonisagrista.com)
5 poin oleh GN⁺ 2025-12-03 | 2 komentar | Bagikan ke WhatsApp
  • Mesin Chromium memulihkan dukungan JPEG XL, sehingga format gambar yang sempat dibuang kini kembali mendapat perhatian
  • Pada 2022 Google menghapus JPEG XL dengan alasan “kurangnya minat ekosistem”, tetapi tekanan berkelanjutan dari komunitas dan perusahaan-perusahaan besar terus berlanjut
  • Meta, Intel, Adobe, Cloudinary, Krita dan berbagai organisasi lain secara terbuka mendukung perlunya mempertahankan format ini
  • Baru-baru ini PDF Association menyatakan niat untuk mengadopsi JPEG XL sebagai format dasar untuk konten HDR, yang semakin memperkuat momentum ini
  • Keputusan untuk memperkenalkannya kembali di Chrome dinilai sebagai titik balik yang meningkatkan kemungkinan standarisasi JPEG XL secara luas

Latar belakang kebangkitan JPEG XL

  • Pada 2022 tim Chromium menghapus kode dan flag JPEG XL dengan alasan “kurangnya minat ekosistem yang memadai” dan “kurangnya keunggulan dibanding format yang sudah ada”
    • Saat itu komunitas menyatakan dukungan dari organisasi-organisasi besar seperti Meta, Intel, Cloudinary, Adobe, ffmpeg, libvips, Krita
    • Setelah itu, melalui blog, video, dan media sosial, terus bermunculan tanggapan yang menyoroti ketidakadilan keputusan penghapusan tersebut
  • Pada akhir 2025, tim Chromium mengubah isu JPEG XL yang berstatus Obsolete menjadi Assigned, dan secara resmi memulai proses pemulihan
    • Di kelompok pengembang Blink, Rick Byers menyebut bahwa ia “menyambut decoder JPEG XL yang berkinerja baik dan aman terhadap memori”
    • Keputusan ini didasarkan pada sinyal-sinyal positif seperti dukungan Safari, perubahan sikap Firefox, dan langkah adopsi dari PDF Association

Firefox dan pengembangan decoder berbasis Rust

  • Tim Firefox mengkhawatirkan risiko keamanan decoder libjxl berbasis C++ milik JPEG XL, dan mengajukan kebutuhan akan versi Rust yang “aman terhadap memori”
    • Menyusul hal itu, Google Research mulai mengembangkan implementasi Rust jxl-rs
    • Proyek ini menjadi pemicu yang meningkatkan kemungkinan integrasi JPEG XL yang aman di dalam browser

Langkah adopsi dari PDF Association

  • CTO PDF Association, Peter Wyatt, mengumumkan niat untuk memasukkan JPEG XL sebagai format gambar HDR dasar dalam spesifikasi PDF
    • Ini menjadi faktor yang memperkuat kemungkinan standardisasi JPEG XL di ranah dokumen dan penerbitan

Karakteristik teknis utama JPEG XL

  • Mendukung rek kompresi ulang lossless untuk JPEG yang sudah ada, sehingga ukuran dapat dikurangi sekitar 30% tanpa kehilangan kualitas
  • Mendukung wide color gamut dan HDR, serta mampu menangani hingga 32-bit channel dan 4.099 channel
  • Mendukung ukuran gambar maksimum 1.073.741.823×1.073.741.824, sehingga memungkinkan pemrosesan gambar berukuran sangat besar
  • Mendukung progressive decoding, meningkatkan efisiensi transmisi di web
  • Mencakup fitur animasi, transparansi alfa, dan depth map
  • Memiliki struktur yang tahan terhadap generation loss, sehingga penurunan kualitas saat encoding berulang dapat diminimalkan

Kesimpulan

  • JPEG XL memenuhi syarat sebagai format gambar generasi berikutnya, dan kembalinya format ini ke mesin Chrome menjadi momentum penting bagi adopsi massal
  • Pemulihan ini terjadi setelah tekanan jangka panjang dari komunitas, menjadikannya kandidat standar baru dalam ekosistem gambar web
  • Penulis menyambut evaluasi ulang Chromium, namun juga menyoroti bahwa keputusan ini datang terlalu terlambat

Bacaan terkait

2 komentar

 
GN⁺ 2025-12-03
Opini Hacker News

  • Salah satu fitur keren JPEG XL yang kurang dikenal adalah mode untuk mentranskode JPEG secara lossless sambil menghemat ruang penyimpanan sekitar 20%
    Karena bitstream entropi asli dipertahankan apa adanya, format ini sepenuhnya reversibel
    GCP sedang menerapkannya pada DICOM Store API, sehingga bisa menikmati penghematan ruang dari JXL sambil tetap menyajikannya lewat konversi real-time ke JPEG
    Perusahaan kami menyimpan data skala puluhan PB di GCP DICOM Store, jadi kami berharap fitur ini bisa sangat mengurangi biaya tahunan
    Kami juga berharap ada dukungan native di browser, dan saya dengar tim Chrome pada akhirnya akan mendukungnya

    • Saya penasaran apa bedanya dibanding encoder JPEG biasa atau mozjpeg
    • Dulu saya tidak sempat menguji GCP DICOM Store, jadi saya penasaran seperti apa rasanya saat benar-benar dipakai
      Saya ingin tahu apakah ini PACS lengkap, implementasi WADO, atau hanya API kustom sederhana
    • Kalau reversibel, bukankah cukup simpan saja sebagai JPEG XL lalu konversikan lagi saat disajikan?
      Saya penasaran apakah waktu pemrosesannya memang besar
    • Jika pada akhirnya DICOM asli tetap harus disimpan, saya ragu transkoding ini ada artinya
      Sepertinya sebagian besar biaya penyimpanan justru berasal dari DICOM itu sendiri
    • Pada akhirnya pelanggan besar GCP akan sangat diuntungkan oleh fitur ini, jadi saya merasa alasan Chrome mendorong JXL adalah karena pelanggan internal

  • Pesaing JPEG XL bukan AVIF
    AVIF sudah menjadi standar de facto, didukung hampir semua browser, dan bahkan dipakai sebagai format gambar default Apple
    JXL masih lemah dalam dukungan browser, tetapi mulai mendapat tempat di ceruk seperti arsip, fotografi profesional, dan medis
    Dalam sekitar 10 tahun, bisa jadi orang akan menyebutnya begitu saja sebagai “JPEG”
    AVIF adalah standar terbuka dan bebas royalti, jauh lebih efisien daripada JPEG/WebP, dan juga berada di tingkat yang mirip dengan JXL
    Ukuran gambar maksimum JXL memang lebih besar, tetapi dari sisi adopsi AVIF jauh lebih unggul
    Jika AV2 keluar, kesenjangan kualitasnya hampir akan hilang, dan saya kira kedua format akan terus berkembang sambil mempertahankan tingkat kualitas yang mirip

    • Bahwa AVIF lebih efisien daripada JPEG atau WebP memang jelas, tetapi melawan JXL itu bukan tandingan
      Pada pengaturan kualitas yang realistis, JXL menunjukkan rasio kompresi yang lebih tinggi serta kecepatan encoding dan decoding yang lebih baik
      Selain itu juga mendukung progressive decoding
      Mungkin AV2 akan bisa mengejar, tetapi untuk saat ini saya rasa JXL jauh di depan
    • Salah satu alasan tim Chrome menghentikan dukungan JXL dulu adalah karena AVIF sudah cukup bagus
      Tinjauan ulang kali ini tampaknya terkait dengan keputusan saat itu
    • Pernyataan bahwa “format gambar default Apple adalah AVIF” sepertinya salah
      iPhone memakai HEIF
    • Saya pernah langsung memakai libjxl dan penggunaan memorinya tinggi serta tidak stabil
      Untuk meng-encode gambar beresolusi tinggi, sampai terasa perlu RAM kelas terabyte
      Saya kaget karena codebase-nya berantakan, dan banyak opsi tidak benar-benar berfungsi
      Mencoba lagi dengan jxl-rs itu kabar baik, tetapi karena pengembang yang sama juga terlibat, saya tetap berhati-hati

  • Kemungkinan besar Chromium akan memakai crate jxl-rs untuk fitur JPEG XL
    Sepertinya mereka menunggu sampai cukup stabil sebelum mengintegrasikannya
    Isu terkait bisa dilihat di sini

    • Mozilla punya posisi yang mirip, tetapi Google selama ini menunjukkan sikap yang cenderung bermusuhan
      Mereka menutup isu itu meski ada penolakan dari pengguna, dan baru belakangan membukanya kembali
      Mungkin karena masalah PR atau keluhan internal
    • Ada masa lebih dari satu setengah tahun tanpa commit di jxl-rs
      Fakta bahwa sekarang berjalan baik mungkin juga hasil keberuntungan

  • Saya pernah melihat implementasi referensi (C++) JPEG XL, dan bahkan dua tahun lalu kualitas kodenya tidak bagus
    Rasanya seperti tinggal menunggu muncul masalah keamanan

    • Karena itu Mozilla dan Google sama-sama mempertimbangkan dukungan JXL dengan syarat ada implementasi yang memory-safe
      Versi Rust sedang dikembangkan, dan Google punya rencana untuk secara bertahap mengganti semua decoder di Chromium ke Rust
    • Sebenarnya pada titik ini (2025), codebase pemrosesan gambar besar yang ditulis dalam C++ itu sendiri sudah merupakan risiko keamanan
      Ini bukan masalah yang hanya dimiliki JPEG XL

  • Resolusi maksimum JPEG XL adalah 1,073,741,823 × 1,073,741,824, sehingga bisa merepresentasikan gambar ultraresolusi setara ratusan petabyte
    Secara realistis pun, setelah dikompresi ukurannya tetap berada di kisaran puluhan hingga ratusan PB

    • Pada 600DPI, panjang salah satu sisinya setara jarak maraton
      Jika gambar sebesar ini bisa didefinisikan dalam ruang byte yang kecil, rasanya itu juga bisa menjadi vektor serangan DOS
      Saya sempat mencoba mengonversinya ke jumlah lembar A4, tetapi kalkulator Gemini malah bingung soal satuan dan memberi hasil aneh
    • Untuk gambar raksasa seperti ini, satu-satunya cara praktis adalah menanganinya dengan tiling dan struktur piramida
    • Ukurannya mungkin kira-kira setara gambar seluruh Bumi pada resolusi sekitar 4 cm
    • Kalau selfie diambil pada resolusi itu, hasilnya akan seperti mikroskop super-resolusi
    • Tidak seperti AVIF, JPEG XL mendukung progressive decoding yang efisien, jadi pratinjau berkualitas rendah bisa cepat terlihat saat unduhan masih berlangsung

  • Kumpulan diskusi HN terdahulu
    Chromium Team Re-Opens JPEG XL Feature Ticket
    FSF Slams Google over Dropping JPEG-XL in Chrome
    Google set to deprecate JPEG XL support in Chrome 110
    Chromium jpegxl issue closed as won't fix

  • Saya sudah memakai .avif selama beberapa tahun
    Tidak sempurna, tetapi rasanya jauh lebih baik daripada .jpg atau .png
    Saya juga sempat mempertimbangkan .webp dan jpeg-xl, tetapi pada akhirnya puas dengan .avif
    Hanya saja saya tidak suka Google secara de facto mengendalikan standar web
    Tidak sehat jika perusahaan komersial mengontrol ekosistem digital

    • Kalimat “.avif lebih baik daripada .jpg” terasa membingungkan karena .avif disebut dua kali
    • Jika ingin membuat JPEG berkualitas tinggi menjadi kecil, saya sarankan mencoba jpegli
      jpegli GitHub
      Jika pengaturan visual lossless AVIF dipilih dengan baik, hasilnya mungkin bisa lebih kecil daripada jpegli, tetapi rata-rata jpegli lebih efisien
    • Sebagai catatan, dalam bahasa Inggris, “for several years” terdengar lebih alami daripada “since some years”
    • JPEG XL lebih tahan terhadap penurunan kualitas meski disimpan ulang berkali-kali, sehingga menguntungkan untuk lingkungan web
      Video terkait: tautan YouTube

  • Yang menghapus JXL bukan “Google secara keseluruhan”, melainkan tim Chrome
    JXL dirancang oleh Jyrki Alakuijala dari Google Zurich Research, dan dia bukan bagian dari tim Chrome melainkan Google Research
    Tim Chrome punya budaya yang tertutup dan berpusat di Mountain View

    • Jyrki adalah engineer hebat yang juga membuat Brotli, WebP lossless, WOFF2, jpegli dan lainnya
      Fakta bahwa dia membuat jpegli setelah JpegXL dibatalkan juga semacam bentuk reaksi
    • Situasi ini tampaknya bisa dijelaskan dengan Conway’s Law

  • Tampaknya JXL tertunda karena banyak dependensi multithread berbasis C++ yang bisa memperbesar permukaan serangan keamanan
    Mozilla dan Google sama-sama lebih memilih implementasi Rust untuk menghindari hal itu
    Standarnya sendiri jelas format yang lebih baik dibanding yang sudah ada

    • Angka 100 juta baris itu terasa terlalu dibesar-besarkan
    • Kenyataannya hanya sekitar 30 ribu baris, dan versi single-thread sekitar 10 ribu baris
      Ukuran binernya juga jauh lebih kecil daripada AVIF, dan spesifikasinya jauh lebih ringkas
    • Karena Google ikut terlibat dalam pengembangan JXL, gagal cepat membuat decoder yang memory-safe itu juga tanggung jawab mereka sendiri
    • Mungkin yang dimaksud 100 ribu baris? Sebagian besar kemungkinan adalah kode pengujian
    • libjxl yang sebenarnya sekitar 112 ribu baris, jadi klaim 100 juta baris meleset tiga orde besaran

  • File RAW di iPhone 17 Pro kabarnya dikompresi dengan JPEG XL