JPEG XL dan Pareto Front

 (cloudinary.com)
2 poin oleh GN⁺ 2024-03-02 | 2 komentar | Bagikan ke WhatsApp
  • Bottleneck pada encoding JPEG XL yang sebelumnya memproses gambar besar sekaligus dikurangi oleh libjxl 0.10 melalui API encoding streaming, sehingga penggunaan memori dan kecepatan kompresi lossless meningkat besar
  • Encoding lossless gambar Bumi malam hari NASA berukuran 13500×6750 turun dari sekitar 8GB RAM dan lebih dari 2 menit di libjxl 0.9 menjadi 0,7GB RAM, 30 detik single-thread, dan 5 detik dengan 8 thread di libjxl 0.10
  • Membandingkan metode kompresi hanya dari ukuran file tidak cukup; Pareto front yang melihat kecepatan encoding dan kepadatan kompresi bersama-sama menjadi tolok ukur untuk menentukan pengaturan optimal berdasarkan anggaran waktu
  • Kompresi lossy perlu melihat rasio kompresi, kecepatan, dan kualitas gambar sekaligus; pada rentang SSIMULACRA2 60–90, JPEG XL menunjukkan hasil yang kuat terutama di area kualitas tinggi hingga visually lossless
  • Encoder JPEG baru seperti jpegli masih kompetitif pada rentang encoding yang sangat cepat, tetapi JPEG XL telah menjadi pilihan utama untuk kompresi lossless maupun lossy pada rentang kecepatan yang luas

Perubahan utama di libjxl 0.10

  • libjxl 0.10 adalah versi baru dari implementasi referensi JPEG XL, dan perubahan terbesarnya adalah implementasi penuh API encoding streaming
  • API ini tidak memproses gambar besar sekaligus, melainkan melakukan encoding dalam unit chunk
    • Beban RAM yang muncul saat seluruh gambar dimuat ke memori berkurang
    • Kecepatan encoding juga ikut meningkat
    • Efeknya sangat menonjol terutama pada kompresi lossless untuk gambar besar

Memori dan waktu yang berkurang pada kompresi lossless

  • Sebelum libjxl 0.10, encoding JPEG XL lossless bisa bermasalah karena membutuhkan memori besar dan waktu pemrosesan lama
  • Contoh gambarnya adalah gambar Bumi malam hari NASA berukuran 13500×6750
    • File TIFF berukuran 64MB
    • Ukuran sebelum kompresi adalah 273MB
  • Hasil kompresi gambar yang sama dengan pengaturan effort default e7:
    • libjxl 0.9 menggunakan sekitar 8GB RAM dan memakan waktu lebih dari 2 menit, dengan file hasil 33,7MB
    • Single-thread memakan waktu 2 menit 40 detik, sedangkan 8 thread 2 menit 6 detik, sehingga efek penambahan thread tidak besar
    • Lingkungan pengujian adalah MacBook Pro November 2023 dengan CPU Apple M3 Pro 12-core dan RAM 36GB
  • Di libjxl 0.10, kompresi gambar yang sama hanya membutuhkan 0,7GB RAM
    • 30 detik single-thread
    • 5 detik dengan 8 thread
    • File hasil 33,2MB
  • Jika nilai effort dinaikkan, rasio kompresi membaik, tetapi peningkatan dibanding waktu CPU yang dipakai makin mengecil
    • Dari e1 ke e2, menggunakan 1 detik alih-alih 0,1 detik dapat mengurangi 22MB
    • Dari e2 ke e7, menggunakan 5 detik alih-alih 1 detik mengurangi tambahan 11MB
    • Dari e7 ke e9, untuk mengurangi 1MB lagi harus menunggu hampir 2 menit

Kompromi praktis pada pengaturan effort

  • Pengaturan kompresi adalah masalah kompromi antara waktu dan ukuran file
  • Dalam workflow pembuatan konten yang menyimpan secara lokal saat mengedit gambar, kompresi kuat tidak selalu diperlukan sehingga encoding dengan effort rendah bisa masuk akal
  • Dalam skenario distribusi satu-ke-banyak atau penyimpanan jangka panjang, memakai lebih banyak waktu CPU untuk mengurangi beberapa MB bisa bernilai

Membandingkan metode kompresi dengan Pareto front

  • Saat membandingkan teknik kompresi, melihat ukuran file saja mudah membuat informasi yang diperlukan untuk pilihan nyata terlewat

  • Sumbu perbandingan dan cara membaca chart

    • Sumbu utama adalah kepadatan kompresi dan kecepatan encoding
    • Suatu metode disebut Pareto optimal jika tidak ada metode lain yang mencapai kepadatan kompresi yang sama atau lebih baik dalam waktu yang lebih singkat
    • Kumpulan metode Pareto optimal disebut Pareto front
    • Pada chart, sumbu vertikal adalah kecepatan encoding, dan sumbu horizontal adalah rata-rata bits per pixel dari gambar terkompresi
    • Sumbu vertikal memakai satuan megapixels per second, dan menggunakan skala log untuk menangani rentang kecepatan yang luas
    • RGB 8-bit sebelum kompresi adalah 24bpp
    • Makin ke atas makin cepat, dan makin ke kiri rasio kompresinya makin baik

Hasil perbandingan kompresi lossless

  • libjxl sebelumnya juga menghasilkan hasil Pareto optimal di semua rentang kecepatan, dan membuat file lebih kecil daripada PNG, AVIF lossless, dan WebP lossless
  • libjxl 0.10 menunjukkan hasil yang lebih baik dengan selisih signifikan dibanding versi sebelumnya
  • QOI tidak ditampilkan di chart, tetapi mencatat 17bpp pada 154Mpx/s
    • Pengaturan effort terendah libjxl mengompresi hingga 11,5bpp pada 427Mpx/s
    • libjxl 2,7 kali lebih cepat dan file hasilnya 32,5% lebih kecil

Kompresi lossless pada gambar non-foto

  • Foto cenderung sulit dikompresi lossless karena memiliki banyak noise alami, dan hasilnya berbeda pada gambar non-foto
  • Dalam pengujian yang memakai 41 gambar komik dengan beragam gaya gambar, ukuran rata-ratanya 7,3 megapiksel
  • Gambar seperti ini terkompresi hingga sekitar 4bpp, jauh lebih baik daripada sekitar 10bpp pada gambar foto
  • AVIF lossless tidak berguna untuk jenis gambar ini
    • Rasio kompresinya lebih rendah daripada PNG
    • Mencapai kepadatan yang mirip dengan QOI, tetapi jauh lebih lambat
  • WebP lossless menunjukkan rasio kompresi yang sangat baik pada gambar seperti ini
  • QOI cukup baik jika mempertimbangkan kecepatan dan kesederhanaannya, tetapi jauh dari Pareto optimal
    • Encoding JPEG XL dengan effort rendah 2 kali lebih cepat daripada QOI dan 31% lebih kecil
  • libjxl 0.10 juga jauh membaik dibanding 0.9 pada gambar non-foto
    • WebP effort default: 4,30bpp, 2,3Mpx/s
    • libjxl 0.9 effort 5: 4,27bpp, 2,6Mpx/s
    • libjxl 0.10 effort 5: 4,25bpp, 12,2Mpx/s
    • libjxl 0.10 effort 7: 4,04bpp, 5,9Mpx/s

Kompresi lossy menambahkan sumbu kualitas gambar

  • Untuk kompresi lossless, cukup melihat ukuran terkompresi dan kecepatan, tetapi pada kompresi lossy ada tambahan kualitas gambar
  • Codec dan encoder gambar lossy dapat memiliki kinerja berbeda tergantung titik kualitas
    • Encoder yang baik pada encoding berkualitas tinggi tidak bisa dianggap pasti baik pada kualitas rendah
    • Sebaliknya juga sama
  • Plot bitrate-distortion yang hanya melihat rasio kompresi dan kualitas membuat kompromi antara effort encoding dan performa kompresi sulit dievaluasi
  • Untuk melihat Pareto front kompresi lossy, ruang 3 dimensi kompresi, kecepatan, dan kualitas perlu dipotong pada beberapa titik kualitas

Pengukuran kualitas gambar dan metode agregasi

  • Kualitas gambar bersifat subjektif dan bisa berbeda antarmanusia
  • Metode pengukuran terbaik adalah eksperimen yang meminta puluhan orang atau lebih membandingkan atau memberi skor gambar berdasarkan protokol pengujian yang ketat
  • Karena eksperimen seperti ini memakan banyak waktu dan biaya sehingga sulit menguji semua pengaturan encoder, metrik objektif digunakan
  • Di antara metrik publik, SSIMULACRA2, Butteraugli, dan DSSIM dianggap sebagai metrik yang baik
    • Mereka berusaha memodelkan sistem visual manusia dan memiliki korelasi yang baik dengan penilaian subjektif
    • Metrik sederhana lama seperti PSNR atau SSIM tidak cocok dengan penilaian kualitas gambar oleh manusia
  • Jika evaluasi memakai metrik yang dioptimalkan secara internal oleh encoder, hasil dapat terdistorsi menguntungkan encoder tersebut
    • libjxl dengan effort tinggi mengoptimalkan Butteraugli
    • libavif dapat mengoptimalkan PSNR atau SSIM
    • SSIMULACRA2 dianggap sebagai metrik aman karena encoder yang diuji tidak menggunakannya untuk optimasi internal
  • Dalam pengujian, pengaturan encoder dipilih agar saat tiap pengaturan diterapkan ke seluruh kumpulan gambar, skor rata-rata SSIMULACRA2 mendekati nilai tertentu
  • Penyelarasan skor rata-rata adalah metode yang menguntungkan WebP dan AVIF
    • Dalam penelitian sebelumnya, AVIF dan WebP kurang konsisten daripada JPEG dan HEIC, sedangkan JPEG XL adalah encoder paling konsisten
    • Dalam penggunaan nyata, orang mungkin ingin menyamakan skor terburuk atau kualitas visual terburuk yang sebenarnya

Rentang kualitas yang dekat dengan penggunaan nyata

  • Kompresi lossy dapat mencapai rasio kompresi tinggi seperti 50:1 atau 200:1, tetapi artefak kompresi akan muncul
  • Rentang yang paling relevan dalam penggunaan nyata adalah SSIMULACRA2 60–90
  • Karakteristik tiap titik kualitas:
    • SSIMULACRA2 90: kualitas visually lossless, dan codec modern seperti AVIF dan JPEG XL dapat mencapainya pada rasio kompresi sekitar 8:1, yaitu 3bpp
    • SSIMULACRA2 80: kualitas tinggi, dapat dicapai pada rasio kompresi sekitar 16:1, yaitu 1,5bpp
    • SSIMULACRA2 70: kualitas menengah-atas, dapat dicapai pada rasio kompresi sekitar 30:1, yaitu 0,8bpp
    • SSIMULACRA2 60: kualitas menengah, dapat dicapai pada rasio kompresi sekitar 40:1, yaitu 0,6bpp
  • Kualitas di bawah SSIMULACRA2 60 dapat lebih mengurangi bandwidth, tetapi berisiko merusak gambar
  • Di web pada 2024, rentang kualitas menengah hingga tinggi sangat relevan
    • Berdasarkan HTTP Archive, median AVIF di web adalah 1bpp, yang setara dengan kualitas menengah-atas
    • Median JPEG adalah 2,1bpp, yang setara dengan kualitas tinggi
  • Untuk kasus penggunaan non-web seperti kamera, rentang kualitas tinggi hingga visually lossless lebih relevan

Hasil Pareto front kompresi lossy

  • Pengujian kompresi lossy dilakukan dengan versi terbaru masing-masing encoder per akhir Februari 2024
  • Kecepatan encoding diukur dengan 8 thread pada MacBook Pro November 2023 berbasis Apple M3 Pro
  • AVIF diuji baik dengan pengaturan tile maupun tanpa tile
    • Pengaturan tile memanfaatkan multithreading dengan baik sehingga lebih cepat
    • Namun ada kehilangan kepadatan kompresi

Kualitas menengah: SSIMULACRA2 60

  • Di dalam format yang sama pun, hasil berbeda besar tergantung encoder dan pengaturan effort
  • Pengaturan default libjpeg-turbo, encoder JPEG yang secara historis banyak digunakan, berada di posisi paling cepat pada chart tetapi dengan kepadatan kompresi rendah
  • WebP memiliki kepadatan kompresi lebih baik daripada libjpeg-turbo
  • mozjpeg lebih lambat daripada libjpeg-turbo tetapi memberi hasil kompresi yang lebih baik, dan pada kumpulan gambar serta titik kualitas ini lebih Pareto-efficient daripada WebP
  • jpegli, yang dibuat oleh tim JPEG XL Google, lebih cepat daripada mozjpeg dan rasio kompresinya juga lebih baik
    • Berdasarkan pelajaran dari guetzli dan libjxl
    • Mengompresi lebih baik daripada WebP dan AVIF cepat, sekaligus menghasilkan file JPEG lama
  • AVIF dan HEIC dapat memperoleh kepadatan kompresi yang lebih baik daripada JPEG dan WebP, tetapi encoding-nya lebih lambat
  • JPEG XL mencapai kepadatan kompresi yang mirip sambil melakukan encoding jauh lebih cepat
  • Pareto front pada titik kualitas ini terdiri dari JPEG XL dan beberapa encoder JPEG di rentang kecepatan yang wajar, serta AVIF di rentang yang lebih lambat

Hasil kualitas menengah-atas dan tinggi

  • Pada kualitas menengah-atas SSIMULACRA2 70, hasil keseluruhan mirip dengan kualitas menengah
  • Sebagai titik kualitas tertinggi yang relevan dengan web, digunakan rata-rata SSIMULACRA2 85, dengan pengaturan agar sebagian besar gambar mencapai 80 atau lebih
  • Pada titik kualitas tinggi ini, perbedaannya makin jelas
    • mozjpeg tidak lagi mengalahkan WebP
    • jpegli masih mengalahkan WebP
    • Pareto front sebagian besar ditempati JPEG XL
    • Pada encoding yang sangat cepat, JPEG lama masih bagus
  • Pada titik kualitas ini, AVIF tidak berada di Pareto front
    • Pada pengaturan paling lambat, dengan kecepatan di bawah 0,5Mpx/s, AVIF menyamai kepadatan kompresi pengaturan libjxl kedua tercepat
    • Pengaturan libjxl tersebut berjalan 52Mpx/s, lebih dari 100 kali lebih cepat

Kecepatan decoding

  • Perbandingan sejauh ini berfokus pada kepadatan kompresi dan kecepatan encoding
  • Pada komputer modern, kecepatan decoding bukan masalah besar, tetapi nilai pengukurannya juga dibandingkan
  • JPEG sequential paling kuat dalam kecepatan decoding
  • JPEG progressive yang dihasilkan mozjpeg dan jpegli default lebih lambat, tetapi cukup cepat untuk memuat gambar berukuran wajar dengan sangat cepat
  • JPEG XL berada di antara JPEG sequential dan JPEG progressive
  • Kecepatan decoding AVIF bergantung pada metode encoding
    • Jika memakai encoding multi-tile yang lebih cepat tetapi sedikit lebih buruk, decoding juga lebih cepat
    • Encoding single-tile default lebih lambat
  • Bahkan kecepatan decoding paling lambat yang diukur masih tergolong cukup cepat dibandingkan kecepatan encoding

Visually lossless dan gambar besar

  • Chart kualitas visually lossless tidak menyertakan WebP
    • WebP tidak dapat mencapai titik kualitas ini dalam mode lossy
    • Karena WebP mewajibkan chroma subsampling 4:2:0
  • mozjpeg juga tidak dirancang untuk titik kualitas ini, sehingga lebih buruk daripada libjpeg-turbo baik dalam kompresi maupun kecepatan
  • Pada pengaturan kecepatan default, libavif 20% lebih kecil daripada libjpeg-turbo, tetapi encoding memakan waktu satu orde magnitudo lebih lama
  • Pada titik kualitas yang sama, libjxl 20% lebih kecil daripada libavif dan 2,5 kali lebih cepat
  • Pareto front untuk kualitas visually lossless sebagian besar ditempati JPEG XL, dengan JPEG juga termasuk pada rentang kecepatan paling cepat
  • Berbeda dari pengujian gambar berukuran web sekitar 1 megapiksel, hasilnya sangat berbeda pada pengujian gambar yang lebih besar
    • Pada titik kualitas tinggi, WebP, mozjpeg, dan AVIF lebih buruk daripada libjpeg-turbo
    • HEIC memberi penghematan signifikan dibanding libjpeg-turbo
    • jpegli juga memberi penghematan signifikan dengan kecepatan yang lebih baik
    • JPEG XL mengompresi gambar hingga di bawah 1,3bpp, sedangkan AVIF, libjpeg-turbo, dan WebP membutuhkan 2bpp atau lebih

Posisi akhir libjxl 0.10

  • libjxl 0.10 mengurangi penggunaan memori pada kompresi lossless dan lossy hingga skala satu digit
  • Kecepatan juga meningkat, terutama pengaturan effort default untuk encoding lossless multithread menjadi lebih cepat dalam skala satu digit
  • JPEG XL dapat dirangkum sebagai codec gambar yang kuat baik untuk kompresi lossless maupun lossy, terutama pada rentang kualitas tinggi hingga visually lossless
  • Pada rentang pengaturan kecepatan yang luas, JPEG XL tetap menjadi pilihan yang mendekati Pareto optimal
  • JPEG lama juga tetap menarik berkat encoder baru
    • jpegli meningkat jauh dibanding mozjpeg baik dalam kecepatan maupun kompresi
    • Saat encoding yang sangat cepat diperlukan, JPEG lama masih bisa menjadi pilihan terbaik

Bacaan terkait

2 komentar

 
dofuuz 2024-03-08

Encoder jpegli sekali lagi memperpanjang umur JPG setelah mozjpeg...
Dibuat oleh kubu JXL, tetapi ironisnya justru bisa menghambat penyebaran JXL...
 
GN⁺ 2024-03-02
Opini Hacker News

  • Perlu juga diperhatikan seberapa bagus WebP lossless
    Ini sering tenggelam oleh pembahasan bahwa WebP tidak punya keunggulan jelas dibanding encoding MozJPEG, atau bahkan lebih buruk, tetapi WebP lossless benar-benar hebat dalam hal performa dan kecepatan
    Jauh lebih baik daripada PNG atau OptiPNG, dukungan online-nya juga sudah memadai, dan tentu saja jauh mengungguli AVIF lossless yang buruk

    • WebP lossless memang sangat bagus, tetapi karena hanya mendukung 8-bit, kesiapan masa depannya lemah
      Untuk gambar SDR tidak masalah, tetapi untuk HDR ini menjadi batasan mendasar seperti GIF yang terbatas pada 256 warna
    • WebP lossless punya masalah karena hanya mendukung (A)RGB, dan grayscale dienkode lewat cara memutar yang lebih buruk daripada dukungan monokrom
      Jika mengompresi seluruh komik, PNG masih menjadi pilihan yang tepat, dan dalam kasus ini lebih baik memakai oxipng daripada optipng yang pada dasarnya sudah ditinggalkan
      Hal lain yang terlewat di sini: JPEG2000 lossless bisa saja secara mengejutkan bagus dan cepat untuk konten foto
    • WebP juga punya mode encoding hampir lossless berbasis spesifikasi WebP lossless, tetapi hampir tidak pernah dipromosikan
      Untuk kebanyakan penggunaan, mode ini lebih layak dipilih daripada lossless murni, dan sering kali mengurangi ukuran hingga separuh tanpa kehilangan yang terlihat
    • Cukup mengejutkan bahwa versi lossless AVIF dan HEIC, format gambar baru, performanya seburuk ini dibanding PNG yang sudah tua
    • Pada AVIF lossless pun tampaknya masih ada ruang penghematan tambahan: https://www.reddit.com/r/AV1/comments/1b3lh08/comment/kstmbr...

  • Pada pengaturan kualitas yang sangat rendah, JPEG secara mengejutkan tetap mempertahankan aproksimasi detail tajam yang lebih baik menjaga kualitas keseluruhan gambar, meskipun dari dekat tampak berantakan seperti lukisan kubisme karena artefak yang mencolok
    Pada dasarnya gambar diubah menjadi semacam gaya seni abstrak, sedangkan JXL dan AVIF hanya menjadi buram

    • Itu karena JPEG diberi 0,5 bit per piksel, sementara JPEG XL dan AVIF hanya diberi sekitar 0,22 dan 0,2 bit
      Gambar-gambar ini bukan disamakan pada rasio kompresi yang sama, melainkan pada tingkat distorsi yang sama, dan jumlah bit per piksel ditampilkan di sebelah gambar
      Di internet nyata, penggunaan kualitas 65 jarang dan hanya dipakai situs berkualitas terendah; kualitas 75 adalah kualitas rendah yang umum, dan kualitas 85 mendekati rata-rata
      Saat kompresi diperlukan, digunakan kualitas 94 yuv444 atau lebih tinggi
    • Kalau yang dimaksud gambar ini: https://res.cloudinary.com/jon/qp-low.png
      Bitrate ada di kolom kiri, dan JPG kualitas rendah berukuran sama dengan kualitas menengah-bawah JXL/AVIF pada 0,4 bpp, jadi gambar kiri bawah harus dibandingkan dengan gambar tengah atas dan kanan
    • JPEG masih memakai kira-kira dua kali lebih banyak bit per piksel, sehingga ukuran file akhirnya jauh lebih besar
      Jangan terbawa perbandingan yang keliru; jika JXL dan AVIF juga diberi ukuran file dua kali lipat, tampilannya akan jauh lebih baik
    • Karena bitrate JPEG lebih tinggi, dalam pengujian ini maknanya lebih dekat bahwa SSIMULACRA2 adalah metrik yang keliru
      SSIMULACRA2 tampaknya menghukum artefak blok dengan kuat tetapi tidak terlalu peduli pada keburaman, dan saya setuju bahwa pada skor SSIMULACRA2 yang sama, versi JPEG terlihat lebih baik
    • Kesimpulan yang saya dapat dari tulisan ini juga bahwa JPEG benar-benar bagus mempertahankan ketajaman tepi seperti bulu mata, sedangkan JXL dan AVIF menghaluskan semua detail gambar hingga melebur

  • Saya tidak paham mengapa tulisan ini begitu fokus pada kecepatan encoding, tetapi membahas decoding—yang menurut saya mencakup 99% penggunaan dalam konteks koneksi web—secara seadanya
    Pembahasannya hanya lewat kalimat semacam, “Kecepatan decoding bukan masalah besar di komputer modern, tetapi menarik untuk melihat angkanya secara cepat”

    • Jika sudah melewati 100 MB per detik, itu saya anggap cukup untuk internet
      Mulai titik itu, bottleneck-nya bukan lagi decoding
      Sebagian besar algoritme kompresi modern bersifat asimetris, sehingga meski menghabiskan jauh lebih banyak waktu untuk kompresi, performa dekompresi tidak banyak terpengaruh; setelah performa dasar tercapai, hal itu menjadi kurang penting
    • Saya penasaran apakah praktis mendecode format gambar yang diturunkan dari format video, seperti AVIF/AV1 atau HEIC/H264, dengan decoder video hardware
      Jika memungkinkan, itu bisa menjadi alasan kuat untuk lebih memilih format-format ini dibanding JPEG XL yang saat ini harus didecode sepenuhnya lewat software pada semua hardware
      Decoding H264 ada di mana-mana, dan decoding AV1 juga terus menjadi fitur standar
    • Dalam beberapa penggunaan, perusahaan membayar biaya encoding, sementara klien melakukan decoding
      Selama klien dapat mendecode beberapa gambar di halaman dengan cukup cepat sehingga tidak terasa oleh manusia, itu sudah cukup; sebaliknya, peningkatan beberapa persen saja pada encoding bisa menghemat biaya nyata
    • Encoding real-time cukup umum, jadi kecepatan encoding penting
    • Karena itulah use case Cloudinary
      Mereka benar-benar menghabiskan jutaan dolar untuk encoding gambar

  • Saya tertawa melihat QOI masuk ke benchmark lossless
    Format ini tidak didukung secara default di software konsumen umum, dan pada dasarnya tidak relevan karena targetnya sekadar cukup baik, bukan bagus; menarik juga bahwa ia mengambil satu tempat di chart encoding non-foto

    • GameMaker Studio cukup cepat mengikuti arus QOI, dan dua tahun lalu mereka mengganti tekstur PNG menjadi QOI lalu menambahkan kompresi BZ2 di atasnya, menghasilkan pengurangan ukuran rata-rata 20%
      Jadi GameMaker Studio dan game-game yang dibuat kira-kira dalam dua tahun terakhir memang memakai QOI secara internal
      Konsumen memang tidak memakainya secara sadar, tetapi sulit juga menyebutnya sepenuhnya tidak relevan
    • Meski begitu, QOI tidak mencapai Pareto frontier
      Jika dipikir kembali, itu wajar, karena decoding QOI pada dasarnya bersifat sekuensial sehingga tidak mudah diparalelkan

  • Penasaran apakah kehebatan JXL berasal dari formatnya sendiri atau dari encoder-nya
    Kemampuannya membuat gambar kecil berkualitas tinggi hanya dengan -d 1.0 terasa nyaris aneh; pada codec lain, untuk mendapatkan hasil serupa harus memberi pengaturan kualitas berbeda tergantung jenis gambar

    • Poin yang sangat bagus
      Dengan laju pengembangan seperti ini, tidak mengherankan jika libjxl menjadi x264-nya dunia encoder gambar
      Sebaliknya, libvpx selalu merupakan encoder yang biasa-biasa saja, dan menurut saya itu mungkin penyebab performa format vp8/vp9 yang mengecewakan, bukan hanya dari sisi kecepatan tetapi performa secara keseluruhan
      Ini tak terhindarkan juga memengaruhi performa lossy WebP, dan Dark Shikari pernah membandingkan performa gambar diam x264 dan vp8 [0]
      [0] https://web.archive.org/web/20150419071902/http://x264dev.mu...
    • Awalnya Pik dirancang untuk mencapai yang terbaik di distance 1.0 tanpa opsi kualitas
      Fokus besarnya tetap pada visual lossless, dan mereka tidak ingin memasukkan fitur format yang tidak membantu pada pengaturan kualitas tinggi tetapi hanya menambah kompleksitas
      Selain fitur pemodelan, pemodelan konteks dan efisiensi entropy coding sangat penting pada kualitas tinggi
      Menurut saya entropy coding AVIF kurang cocok untuk foto berkualitas tinggi atau lossless
    • Mereka juga membuat encoder JPEG cjpegli dengan antarmuka -d 1.0 yang sama

  • Layak disebut bahwa dari pekerjaan JPEG XL juga lahir library paralelisasi baru yang hebat bernama Highway
    Library ini digunakan bukan hanya oleh JPEG XL, tetapi juga oleh model AI Gemma terbaru dari Google

    • Jika tertarik pada Highway, lihat [0]
      [1] juga membahasnya, dan pembukanya seperti ini: “Hari ini kami membagikan kode open source yang mengurutkan array angka sekitar 10 kali lebih cepat daripada C++ std::sort, tetap portabel di semua arsitektur CPU modern, dan bahkan lebih cepat daripada algoritme terbaru yang khusus untuk arsitektur tertentu. Di bawah ini kami membahas bagaimana kami mencapainya.”
      [0] https://github.com/google/highway
      [1] https://opensource.googleblog.com/2022/06/Vectorized%20and%2..., makalah terkait ada di https://arxiv.org/pdf/2205.05982.pdf
    • Dan ada juga VIPS
      Sepertinya ini cara terbaik untuk mendapatkan SIMD portabel di C++

  • Terlepas dari seberapa bersinarnya JPEG XL itu sendiri, fakta bahwa ia bisa melakukan hal berikut saja sudah jelas luar biasa
    a.jpg berukuran 615504 byte dan SHA-1-nya adalah 716744d950ecf9e5757c565041143775a810e10f
    Jika menjalankan cjxl a.jpg a.jxl, ia membaca JPEG 615504 byte dan mengompresnya menjadi 537339 byte termasuk kontainer
    Namun jika menjalankan djxl a.jxl b.jpg, ia membaca data terkompresi 537339 byte dan merekonstruksinya menjadi JPEG, dan b.jpg juga berukuran 615504 byte dengan SHA-1 yang sepenuhnya sama
    Mengingat ada miliaran file JPEG di dunia yang ingin disimpan, jika JPEG yang sudah ada dikompresi ulang ke format lossy, kualitasnya akan menurun
    Namun JPEG XL bisa menghemat 15–30% sambil tetap dapat mengembalikan JPG asli 100% identik bit demi bit jika diinginkan
    Benar-benar keren
    Sayangnya saya memakai Debian stable 12 Bookworm dengan ImageMagick 6.9, dan setahu saya Emacs mungkin memakai ImageMagick saat menampilkan gambar
    Dukungan JPEG XL baru ditambahkan di ImageMagick 7, dan saya belum menggali lebih jauh

    • Saya ikut berkontribusi memasukkan persyaratan itu ke JPEG XL
      Menurut saya itu akan membantu melestarikan warisan digital secara utuh tanpa re-encoding lossy
    • Ini pasti akan menjadi fitur yang sangat dihargai oleh pengguna yang mengambil screenshot JPEG lalu mengirimkannya lagi lewat WhatsApp :P

  • Sangat mengesankan bahwa versi baru libjxl menurunkan penggunaan memori hingga orde satu digit baik untuk kompresi lossy maupun lossless, dan juga meningkatkan kecepatan
    Terutama bagian bahwa pengaturan effort default untuk encoding lossless multi-thread kini lebih cepat hingga orde satu digit; tulisannya juga bagus

  • Penasaran apakah ada situs web yang menjelaskan setiap tahap format JPEG XL secara rinci
    Berbeda dengan JPEG tradisional, sulit menemukan dokumen yang memandu langkah-langkah terkait dengan jelas, dan sayang sekali karena jelas format ini mengumpulkan banyak inovasi menarik
    Komponen-komponen individualnya juga tampaknya berguna dengan sendirinya

  • Artikel tersebut tidak menyertakan rav1e, yang meng-encode AV1 dan dengan demikian AVIF
    rav1e jauh lebih cepat daripada aom sebagai implementasi referensi, dan ada kasus ketika aom tidak selesai mengonversi gambar meski sudah ditunggu 1 menit, sedangkan rav1e membutuhkan kurang dari 10 detik

    • Penasaran apakah kurva Pareto rav1e berada di depan kurva Pareto libaom
      Juga penasaran apakah rav1e yang cepat terlihat lebih baik daripada jpegli pada kecepatan encoding tinggi
    • Baik rav1e maupun libaom memiliki pengaturan kecepatan
      Pada kecepatan yang mirip, saya belum melihat perbedaan besar dalam performa kompresi di antara keduanya