Chromium menggabungkan JpegXL

 (chromium-review.googlesource.com)
2 poin oleh GN⁺ 2026-01-14 | 1 komentar | Bagikan ke WhatsApp
  • Decoder JpegXL diintegrasikan ke codebase Chromium, sehingga browser dapat memproses gambar berformat JXL
  • Perubahan ini dapat dilihat di halaman code review Gerrit dengan judul “Wire up JXL decoder”
  • Penggabungan ini merupakan langkah kunci untuk dukungan format JpegXL, termasuk pekerjaan pengkabelan decoder
  • Code review tersebut terdaftar sebagai perubahan dalam repositori src Chromium (7184969)
  • Hal ini penting dalam konteks perluasan dukungan format gambar generasi berikutnya di browser web

Integrasi decoder JpegXL di Chromium

  • Item code review Gerrit “Wire up JXL decoder (7184969)” adalah perubahan yang menghubungkan decoder JpegXL ke proyek Chromium
    • Perubahan ini dilakukan di repositori src milik Chromium
    • Platform code review yang digunakan adalah chromium-review.googlesource.com
  • Sesuai judulnya, ini berarti pekerjaan untuk menghubungkan (wire up) decoder JXL (JpegXL) ke dalam browser
  • Halaman tersebut tidak menampilkan penjelasan tambahan maupun detail kode, hanya judul perubahan yang dapat dikonfirmasi

Konteks teknis

  • JpegXL adalah format kompresi gambar generasi berikutnya, yang bertujuan meningkatkan efisiensi dibanding JPEG yang ada (tidak disebutkan langsung dalam teks asli, hanya nama teknologinya yang muncul)
  • Dengan decoder yang digabungkan ke Chromium, fondasi untuk mengaktifkan kemampuan pemrosesan gambar JXL di tingkat kode kini tersedia
  • Perubahan ini merupakan kemajuan teknis yang terkait dengan perluasan sistem decoding media di mesin browser

Status dokumen

  • Halaman ini ditampilkan sebagai snapshot cache dari code review Gerrit
  • Ada peringatan bahwa “shadow DOM is hidden”, tetapi isi kode sebenarnya tidak ditampilkan
  • Karena itu, informasi yang dapat dipastikan dari dokumen ini hanya judul perubahan dan identifier review (7184969)

Bacaan terkait

1 komentar

 
GN⁺ 2026-01-14
Komentar Hacker News

  • Saya melihat artikel blog Cloudinary, dan itu adalah tulisan lama yang klasik yang membandingkan webp, jpegxl, avif, jpeg, dan lainnya
    Grafiknya tersusun rapi, dan AVIF sangat lambat

    • Saat JPEG disetel ke kualitas paling rendah, hasilnya justru terlihat jauh lebih baik di sini
      Tautan ke bagian terkait
    • Saya tidak yakin sebenarnya situs ini ingin melakukan apa
      Lihat tangkapan layar
    • Seperti kalimat yang dikutip, jika JPEG XL kini telah mengukuhkan posisinya sebagai codec terbaik untuk lossy/lossless, itu adalah kemajuan besar karena bisa menggantikan JPEG dan PNG sekaligus
    • Namun, pengujian ini tidak menggunakan encoder/decoder dengan akselerasi perangkat keras

  • Library jxl-rs adalah implementasi Rust untuk JPEG XL
    Ini proyek yang relatif baru, tetapi berkat Rust rasanya lebih menenangkan dari sisi keamanan dan stabilitas
    Saat diskusi Chromium sebelumnya, library ini belum ada

    • Saya ingat alasan Google menolak JPEG XL adalah karena “kurangnya minat”. Sepertinya bukan karena masalah keamanan
    • Saya tidak setuju dengan pernyataan “Rust mengurangi kekhawatiran keamanan”. Keamanan memori bukanlah keamanan itu sendiri
      Rust bisa menimbulkan rasa terlalu percaya diri, dan ada kasus ketika threat modeling jadi dilewati
      Bahkan programmer C yang sangat teliti bisa saja lebih aman
    • Saya sempat memeriksa seberapa banyak kode unsafe yang ada
      Tautan hasil pencarian

  • Baru-baru ini saya membandingkan WebP dan AVIF, dan WebP encoding-nya nyaris seketika, sedangkan AVIF butuh lebih dari 20 detik untuk gambar 1MP
    JXL masih belum banyak didukung jadi secara praktik belum bisa dipakai, tetapi saya berharap kecepatannya setara WebP dengan kualitas yang lebih baik

    • rav1e disebut sudah bertahun-tahun tidak diperbarui, jadi lebih baik memakai encoder seperti aom atau svt-av1
    • AVIF perlu penyesuaian parameter penggunaan CPU. Konfigurasi bawaan memakai level CPU yang terlalu tinggi sehingga lambat
      Di lingkungan saya, AVIF 2MP bisa dibuat dalam sekitar 100ms

  • Sangat disayangkan bahwa spesifikasi publik (spec) JPEG XL tidak bisa diakses secara bebas

    • Menurut saya mempertahankan standar tertutup adalah hal yang memalukan
    • Masalahnya adalah kenyataan bahwa banyak dokumen dari lembaga seperti ISO dan IEC berada di balik paywall

  • Kita mendapat satu format gambar baru lagi, dan saya khawatir situasi akan terulang di mana pada akhirnya tidak bisa dipakai tanpa konversi

    • Meski begitu, bahkan Microsoft pun merilis add-on JPEG XL, dan sekarang setelah Google mundur, saya rasa ini adalah peluang yang nyata
      Tautan Microsoft Store
    • Dalam praktiknya, sudah banyak aplikasi yang mendukungnya — Affinity, Photoshop, Microsoft Photos, Gimp, serta dukungan sistem secara menyeluruh di iOS 17+/macOS 12+
      Chromium justru termasuk yang terlambat
    • Tentu saja, format baru selalu memerlukan sekitar 10 tahun masa adopsi

  • Saat membaca daftar fitur JPEG XL di wiki, saya melihat ada fitur menarik seperti gambar multikanal atau dokumen multipage
    Ada sisi bagusnya, tetapi rasanya makin lama makin kompleks seperti TIFF

  • Masih ada banyak kesamaan antara JPEG dan JPEG-XL
    Saya penasaran apakah implementasi baru bisa sekaligus mengintegrasikan dukungan JPEG lama sehingga ukuran kode dapat dikurangi

    • Faktanya, issue untuk fungsi itu sudah dibuka di repositori Rust JPEG-XL
      Tautan issue #513

  • Secara pribadi, saya cenderung tetap memakai JPEG yang sudah ada daripada format baru seperti WEBP
    Sebagian besar program mendukungnya, dan bagi pengguna umum JPEG + PNG sudah cukup
    Animasi sederhana bisa memakai GIF, yang kompleks bisa ditangani sebagai video

    • “JPEG XL” meski namanya begitu, bukan sekadar versi perluasan JPEG
      Ia memungkinkan encoding lossless dengan ukuran lebih kecil daripada PNG, dan juga mendukung transcoding yang dapat dipulihkan sambil memampatkan JPEG lama 20% lebih jauh
      Ada berbagai fitur seperti HDR, wide gamut, progressive loading, sehingga ideal juga untuk pengiriman di web
      Lihat jpegxl.info
    • WebP sekarang pada dasarnya bisa dianggap sebagai format standar de facto
      Semua browser utama mendukungnya sejak Safari 14, dan ia juga sudah dibundel secara default sejak Windows 10 dan macOS Big Sur
      Lihat status dukungan dan daftar perangkat lunak
    • GIF sekarang sudah tidak efisien. Menggantinya dengan video 5~10 kali lebih efisien
      Artikel terkait

  • Saya sudah lama mendengar perdebatan JPEG XL, WebP, dan AVIF, tetapi tidak terlalu memahaminya
    Dari benchmark, JpegXL tampak lebih unggul daripada WebP baik dalam kecepatan kompresi maupun ukuran, jadi saya penasaran kenapa Chromium ragu mengadopsinya

    • WebP dan AVIF berbagi kode dengan VP8/AV1 sehingga integrasi ke browser lebih mudah, sedangkan JPEG-XL punya codebase terpisah sehingga beban implementasinya lebih besar
      Selain itu, libjxl adalah basis kode C++ dengan lebih dari 100 ribu baris, jadi ada risiko kerentanan keamanan
      Tampaknya Chrome meninjaunya kembali seiring implementasi Rust yang makin matang
    • JPEG XL mendukung decoding progresif
      Video demo
    • Google pernah berargumen bahwa “jika ada beberapa format serupa, yang bertambah hanya risiko keamanan”, dan bahwa AVIF saja sudah cukup
    • AVIF bagus pada bpp rendah (kualitas rendah) tetapi lemah untuk lossless, sementara JXL kuat pada kualitas tinggi dan lossless
    • Dulu library C++ JPEGXL berada dalam kondisi pemeliharaan terhenti, tetapi setelah versi Rust muncul, adopsi browser jadi memungkinkan

  • Saya penasaran apakah JPEG XL mendukung animasi

    • Didukung, tetapi tidak memiliki kompresi antar-frame sehingga tidak efisien, jadi ukurannya lebih besar daripada video biasa
    • Menurut halaman status platform Chrome, animasi, HDR, dan decoding progresif semuanya didukung
      Tautan detail
    • Saat diuji langsung di browser Canary, animasinya memang berjalan dengan baik
    • Seseorang bercanda bahwa WebP pada dasarnya adalah “format video yang menjadi gambar”, sedangkan JPEG XL adalah “format gambar yang menjadi video”, sehingga muncul struktur simetri yang paradoksal 😄