JPEG XL: Awal dan kondisi saat ini

 (cloudinary.com)
1 poin oleh GN⁺ 2023-07-22 | 1 komentar | Bagikan ke WhatsApp
  • Apple mengumumkan dukungan untuk Safari 17 serta iOS, iPadOS, macOS, watchOS, dan visionOS, sehingga peluang adopsi web untuk standar kompresi gambar yang relatif baru ini kembali membesar
  • Format ini dirancang dengan menggabungkan Google PIK dan Cloudinary FUIF yang muncul dari permintaan proposal komite JPEG pada 2018, dan bitstream-nya dibekukan pada akhir 2020
  • Chrome menambahkan dukungan eksperimental pada 2021 lalu mengumumkan penghapusannya pada Oktober 2022, memicu kontroversi, sementara adopsi di sisi alat produksi terus berlanjut
  • Dalam perbandingan Cloudinary, JPEG XL menunjukkan penghematan tambahan 5~10% dibanding AVIF, terutama dengan keseimbangan penghematan dan kecepatan yang lebih baik di rentang kualitas tinggi
  • Pengguna Cloudinary dapat menerapkan konversi dengan f_jxl atau .jxl, tetapi untuk deployment nyata tetap perlu menyiapkan fallback AVIF, WebP, dan JPEG

Titik awal dan standardisasi JPEG XL

  • Pengembangan JPEG XL dimulai pada 2018 ketika komite JPEG mengajukan permintaan proposal untuk kompresi gambar generasi berikutnya
  • Dari total 7 proposal, PIK dari Google dan FUIF dari Cloudinary paling menonjol, lalu elemen dari kedua proposal itu digabung dan disempurnakan hingga menjadi desain codec baru
  • Pada akhir 2020, pekerjaan teknis utama selesai, dan bitstream dibekukan agar tidak ada perubahan yang mengubah format dari sudut pandang decoder
  • Cloudinary menambahkan dukungan JXL pada November 2020
  • Chrome menambahkan dukungan eksperimental di balik flag pada awal April 2021, sebelum standar JPEG XL diterbitkan secara resmi
    • Draf finalnya saat itu sudah diajukan ke ISO
    • Persetujuan dan publikasi standar internasional ISO/IEC 18181 baru selesai pada Maret 2022
  • Firefox juga segera menambahkan dukungan eksperimental

Keputusan penghapusan oleh Chrome dan melambatnya adopsi browser

  • Pengembang Chrome mengumumkan penghapusan dukungan JPEG XL pada Halloween 2022
  • Keputusan ini tidak terduga dan memicu kontroversi
  • Cloudinary merangkum alasan mengapa keputusan Chrome perlu dibatalkan dalam The Case for JPEG XL
  • Pada Desember, pengembang Chrome mempublikasikan hasil pengujian yang dipakai untuk membenarkan keputusan tersebut dan meminta masukan
  • Cloudinary menunjukkan cacat metodologis dan kekurangan dalam hasil tersebut di Contemplating Codec Comparisons, tetapi masukan itu belum tercermin hingga sekarang
  • Di luar browser, adopsi JPEG XL terus berlanjut
    • Serif Affinity
    • Adobe Camera Raw
    • GIMP
    • Krita
  • Keputusan Chrome memperlambat adopsi JPEG XL yang lebih luas di browser web

Titik balik yang dipicu pengumuman Apple

  • Apple memasukkan JPEG XL ke dalam daftar fitur baru Safari di WWDC23 pada 5 Juni 2023
  • Bukan hanya Safari 17, versi baru iOS, iPadOS, macOS, watchOS, dan visionOS juga mendukung JPEG XL
  • Para pengembang JPEG XL tidak menduga bahwa browser pertama yang mendukung format yang ikut diciptakan Google ini justru Safari
  • Setelah pengumuman ini, kemungkinan bangkitnya momentum adopsi JPEG XL kembali membesar

Cara membandingkan codec gambar

  • Cloudinary menangani kompresi gambar sebagai pekerjaan inti, sehingga perlu memahami secara mendalam codec, encoder, dan pengaturan mana yang dipakai dan kapan
  • Mereka membuat Cloudinary Image Dataset(CID22), yaitu dataset besar gambar terkompresi dengan anotasi manusia, dan memakainya untuk memahami dampak kompresi pada kualitas perseptual
  • Perbandingan encoder gambar tidaklah sederhana
    • Distorsi yang dihasilkan tiap encoder berbeda-beda
    • Sulit memprediksi kualitas gambar yang dirasakan pengguna
    • Uji subjektif masih menjadi standar dalam evaluasi kualitas gambar
  • Cloudinary juga berpartisipasi dalam penelitian metodologi pengujian seperti proyek AIC-3 milik komite JPEG
  • Dataset gambar beranotasi manusia dipakai untuk memvalidasi metrik objektif seperti SSIMULACRA 2
    • Metrik tidak sempurna
    • Namun memungkinkan pengujian dalam skala besar terhadap lebih banyak gambar dan pengaturan encoder yang sulit ditangani lewat eksperimen subjektif

Trade-off antara kompresi, kualitas, dan kecepatan

  • Dalam kompresi gambar, dibutuhkan trade-off di antara tiga elemen
    • Kompresi: seberapa besar ukuran file bisa dikurangi
    • Kualitas: seberapa besar kualitas visual menurun
    • Kecepatan: berapa lama waktu yang dibutuhkan untuk meng-encode gambar
  • Pentingnya tiap elemen berbeda menurut use case
  • Perbandingan dilakukan dengan melihat performa kompresi dan kecepatan beberapa encoder pada kualitas visual yang sama
  • SSIMULACRA v2.1 digunakan di sumbu horizontal sebagai metrik kualitas visual
  • Di sumbu vertikal, tingkat penghematan dibanding JPEG 4:4:4 yang tidak dioptimalkan ditampilkan sebagai performa kompresi
  • Grafik terpisah menampilkan kecepatan encoding dalam megapiksel per detik berdasarkan satu inti CPU
  • Objek perbandingan adalah JPEG XL, AVIF/libaom, WebP, dan mozjpeg, masing-masing menggunakan pengaturan kecepatan default
    • Garis putus-putus adalah chroma subsampling 4:2:0 (yuv420)
    • Garis penuh adalah 4:4:4 (yuv444)
    • Rentang kualitasnya dari kualitas sangat rendah mendekati q30 menurut libjpeg hingga kualitas sangat tinggi mendekati q95
  • Data agregatnya setara dengan sekitar 300 gambar asli

Hasil per codec

  • WebP memberikan keuntungan yang berarti dibanding JPEG yang tidak dioptimalkan
    • Di rentang kualitas rendah, terlihat penghematan 25~35%
    • Di rentang kualitas tinggi, besar penghematannya menurun
    • Batasan wajib yuv420 pada WebP menjadi kendala di atas q90, dan bahkan menyulitkan untuk mencapai kualitas JPEG yang memungkinkan yuv444 full-range
  • Dibanding encoder mozjpeg yang dioptimalkan, keuntungan tambahan WebP tidak besar
    • mozjpeg juga memberi keuntungan besar dibanding JPEG yang tidak dioptimalkan
    • Penghematan tambahan WebP hanya sekitar 3~5%
  • AVIF memberi penghematan tambahan sekitar 10~15% dibanding WebP
    • AVIF tidak memiliki paksaan yuv420 sehingga tetap bisa memberi penghematan berarti dibanding JPEG yang tidak dioptimalkan bahkan di rentang kualitas tinggi
    • Namun pada kecepatan default, encoding AVIF kira-kira satu orde lebih lambat daripada WebP atau mozjpeg
  • JPEG XL memberi penghematan tambahan sekitar 5~10% dibanding AVIF
    • Penghematan tambahannya lebih besar di rentang kualitas tinggi daripada di rentang kualitas rendah
    • Hasil ini dicapai pada kecepatan yang lebih masuk akal

Menggunakan JPEG XL di Cloudinary

  • Cloudinary termasuk yang paling awal menyediakan dukungan karena ikut berpartisipasi dalam pengembangan JPEG XL
  • Untuk mengonversi gambar ke JXL di Cloudinary, cukup tambahkan f_jxl ke URL atau ubah ekstensinya menjadi .jxl
  • Jika trafik pengunjung dari iOS atau Safari cukup berarti, setelah iOS dan Safari baru dirilis akan layak menyajikan gambar JPEG XL
  • Untuk pengunjung lain, tetap diperlukan fallback AVIF, WebP, dan JPEG
  • Berdasarkan performa kompresi rata-rata, JPEG XL saat ini adalah codec terbaik yang tersedia, tetapi variasinya per gambar cukup besar
    • Ada gambar yang hasil JPEG XL-nya jauh lebih baik daripada codec lain
    • Ada juga gambar yang AVIF-nya lebih baik daripada JPEG XL
  • Cloudinary sedang mengerjakan fitur baru berbasis AI f_auto,q_auto yang secara otomatis memilih format terbaik per gambar

Bacaan terkait

1 komentar

 
GN⁺ 2023-07-22
Komentar Hacker News

  • Penasaran kenapa untuk video·audio, format kontainer seperti MKV bisa bertahan lama meski encoding berubah, sementara untuk gambar setiap encoding baru butuh kontainer dan ekstensi baru, lalu muncul perang format kecil soal dukungan
    Mungkin juga karena hampir semua decoder AV memakai libffmpeg atau fork-nya, dan libffmpeg adalah library terpadu raksasa yang pada praktiknya mendukung hampir semua format dan codec AV utama, jadi kalau codec baru masuk ke libffmpeg, hampir semua program otomatis ikut mendukungnya
    Kalau begitu, kenapa di sisi format·codec gambar tidak ada library terpadu seperti libffmpeg juga jadi pertanyaan

    • Pendahulu dalam persaingan ini adalah TIFF, dan seperti Matroska atau QuickTime menambahkan pengindeksan ke aliran codec mentah seperti MP3/MPEG-TS, TIFF juga menyediakan fitur seperti striping, tiling, dan versi resolusi lebih rendah untuk aliran codec mentah seperti JPEG
      Bedanya, video tanpa indeks pada dasarnya nyaris tak bisa dipakai, tetapi gambar tanpa tile umumnya masih baik-baik saja kecuali di beberapa bidang yang menangani data piksel dalam jumlah sangat besar
      Karena itu, di citra geospasial, medis, dan hasil pemindaian resolusi tinggi, Anda akan melihat kontainer TIFF yang berisi tile JPEG atau JPEG2000, tetapi ekosistem alat publiknya kurang bagus sehingga hampir tidak ada kompatibilitas antar berbagai subset spesifikasi TIFF, dan antar vendor malah lebih parah. Di luar libtiff, hampir tidak ada perangkat lunak bebas, bahkan viewer untuk melihat gambar yang lebih besar dari memori pun minim
      Ada juga contoh berbasis TIFF seperti gambar mentah Canon CR2, tetapi nyaris tidak mendapat manfaat kompatibilitas sehingga tidak terlalu berarti. LogLuv TIFF cukup layak sebagai format HDR, tetapi posisinya serba tanggung di antara Radiance HDR yang ramah bagi perender hobi, OpenEXR yang didorong Pixar, dan berbagai format foto konsumen yang didorong vendor besar dari waktu ke waktu, serta lebih dekat ke beberapa makalah dan kode libtiff daripada spesifikasi tingkat bit yang jelas
      Salah satu alasannya tampaknya karena gambar berukuran besar adalah kebutuhan yang nis, tetapi juga karena Adobe memperoleh TIFF lewat akuisisi Aldus lalu cukup cepat menelantarkan spesifikasinya. Meski begitu, selama sekitar 10 tahun pertama tim legal Adobe tampaknya cukup aktif mencegah ekstensi tak kompatibel yang memakai nama merek dagang seperti TIFF64. Ironisnya, saat ini jika Anda membutuhkan TIFF, biasanya karena Anda perlu data yang melebihi 2GB
      Memang benar TIFF adalah kekacauan yang terlalu fleksibel, tetapi Matroska juga cukup rumit sampai perlu profil WebM, dan QuickTime/BMFF juga punya banyak subset serupa seperti 3GPP, MOV, dan MP4
      Pada akhirnya TIFF sampai batas tertentu adalah jawaban yang diinginkan, tetapi sekarang sudah tidak banyak dipakai. Tidak adanya dukungan browser mungkin juga berpengaruh besar. Kontainer HEIF mungkin secara teknis lebih baik, tetapi membeli semua spesifikasi ISO terkait kemungkinan memakan biaya lebih dari 10 ribu dolar, jadi secara keseluruhan cukup disayangkan
    • Kontainer video membungkus beberapa aliran sekaligus, menyinkronkan audio·video·subtitle, dan menangani bagian penting dari streaming agar codec bisa fokus pada perannya sebagai codec
      Keuntungan lainnya, codec video baru bisa dipakai bersama codec audio yang sudah ada
      Sebaliknya, kontainer gambar diam hampir tidak punya banyak hal untuk dilakukan. Jika isinya hanya satu gambar, pembungkus terpisah tidak terlalu dibutuhkan
    • Kontainer video biasanya perlu memuat beberapa aliran yang tersinkron seperti video·audio·subtitle, aliran audio alternatif, informasi chapter, dan metadata seperti artis
      Saat mendistribusikan gambar statis di web, fungsi seperti aliran alternatif nyaris tidak dibutuhkan, dan cukup mengunduh satu aliran yang diinginkan. Cara paling sederhana adalah menyediakan tiap aliran sebagai file terpisah dan sejak awal tidak memultipleks banyak aliran ke dalam satu kontainer
      Saya juga memahami bahwa bahkan pada video streaming web, fitur ala MKV belum tentu wajib. Biasanya video·audio·teks disediakan sebagai aliran independen dalam file terpisah dan player atau browser yang menyinkronkannya. Jika dilakukan sebaliknya, server bisa jadi harus melakukan demultipleks yang tidak perlu atau klien mengunduh aliran yang tidak dibutuhkan
      Potensi keunggulan dari format kontainer tunggal tampaknya terutama ada pada metadata
    • Kontainer tetap hanya kontainer, dan decoder untuk codec yang ada di dalamnya tetap diperlukan. Dalam hal ini video dan gambar sama saja
      Alasan kontainer lebih penting pada video adalah karena biasanya beberapa codec berbeda dipakai bersama, seperti video dan audio, dan bitstream-nya harus disusun secara berselang-seling
      Format ISOBMFF dipakai sebagai kontainer untuk MP4, JPEG 2000, JPEG XL, HEIF, AVIF, dan lain-lain
      Untuk gambar juga ada library terpadu seperti ffmpeg. Contohnya ImageMagick, GraphicsMagic, libvips, imlib2, dan gdk-pixbuf, dan karena semuanya mendukung hampir semua format gambar, aplikasi yang dibangun di atasnya akan otomatis mendapatkan dukungan JPEG XL juga
      Apple juga punya library terpadu serupa bernama CoreMedia, sehingga aplikasi yang memakai library ini otomatis mendapat dukungan JPEG XL
    • Tampaknya ada pengaruh besar dari tradisi dan inersia sesuai cara format itu pertama kali dibuat dan dipelihara
      Video hampir selalu punya setidaknya dua trek yang harus disinkronkan secara bersamaan, biasanya satu trek video dan satu trek audio. Karena itu wajar jika keduanya dibungkus dalam kontainer dan format video serta audio bisa berbeda
      Pada gambar, setidaknya pada masa awal, isinya hanya satu gambar, jadi tidak ada kebutuhan besar untuk menaruh satu kontainer. Kasus seperti GIF yang berisi banyak frame adalah pengecualian

  • Tulisan terkait ini juga layak dibaca: https://dennisforbes.ca/articles/jpegxl_just_won_the_image_w...
    Muat JXL jika klien mendukung
    Build Chrome dan Edge terbaru mendukung dan menampilkan JXL di iOS 17. Secara internal mereka memang harus memakai mesin Safari, tetapi sebelumnya tampaknya JXL ditekan atau diblokir di sisi mesin bersama itu

    • Karena WebKit menambahkan dukungan di iOS 17, ini bisa dianggap sebagai kemenangan yang didapat secara transitif
    • Di iOS hanya ada Safari. Semua browser di iOS hanyalah kulit yang diletakkan di atas WebKit milik Safari
      Lihat butir 2.5.6 di sini - https://developer.apple.com/app-store/review/guidelines/

  • Masalah saat mencoba menggantikan JPEG adalah bagi kebanyakan orang, JPEG sudah “cukup bagus”
    Ada juga JPEG 2000 yang merupakan peningkatan dari sisi performa, tetapi nyaris tidak benar-benar diadopsi. Dari sudut pandang pengguna, jika JPEG XL paling banter hanya merupakan peningkatan bertahap dibanding JPEG 2000, wajar muncul pertanyaan kenapa orang harus peduli kali ini, padahal mereka juga tidak tertarik pada format sebelumnya

    • Alasan besarnya adalah JPEG XL bisa bermigrasi dengan mulus dari JPEG dan memungkinkan konversi lossless
      Bisa mendapatkan rasio kompresi yang lebih baik, dan layanan dapat menyediakan berbagai resolusi dan kualitas dari gambar tersimpan yang sama sehingga mengurangi ruang penyimpanan atau biaya komputasi. Proses ini transparan bagi pengguna
      Pengguna rata-rata mungkin tidak peduli, tetapi perusahaan cloud dan layanan web kemungkinan ingin mengadopsi teknologi ini jika dukungannya meluas demi menurunkan biaya operasional
    • JPEG 2000 bukan hanya tidak memiliki kompatibilitas ke belakang, tetapi decoding-nya juga jauh lebih lambat dan membutuhkan RAM lebih banyak, yang saat dirilis merupakan masalah jauh lebih besar daripada sekarang
      Memang ada peningkatan teknis di area tertentu seperti transparansi, gambar besar tanpa tiling, dan berbagai ruang warna, tetapi saat mengompresi batas kontras tinggi dan area tekstur frekuensi tinggi pada bitrate rendah, hasilnya tidak jauh lebih baik. Ia hanya mengganti artefak blok milik JPEG dengan smoothing kuat dan artefak ringing versinya sendiri
    • Implementasi JPEG 2000 sudah sangat buruk selama waktu yang lama
      Second Life memakai JPEG2000 untuk tekstur, dan ketika kliennya dirilis sebagai open source, mereka harus beralih ke library open source, yang ternyata sangat lambat. Saat masuk ke area baru, klien bisa nyaris macet selama beberapa menit sampai decoding tekstur selesai
    • JPEG2000 terkena jebakan lisensi paten. JPEG XL secara eksplisit bebas royalti
    • Kalau dipikir-pikir, cukup langka JPEG bisa sesukses ini dan bertahan selama ini. Kompresinya relatif sederhana dan elegan, namun masih cukup layak dipakai
      Meski begitu, tetap berharap JPEG XL benar-benar menjadi penerusnya

  • Tulisannya bagus, tetapi untuk orang yang tidak mengikuti perkembangannya dari dekat, akan lebih baik jika dimulai dengan pengantar “sebenarnya JPEG XL itu apa”
    Bagian akhir memang menjelaskannya sampai taraf tertentu, tetapi saya masih belum yakin kapan sebaiknya memakai WebP, AVIF, atau JXL. Pengunggah gambar di kebanyakan situs web juga tidak mendukung file-file ini, jadi sulit menanganinya, dan akhirnya saya membuka file, mengambil tangkapan layar, lalu mengubahnya menjadi JPEG untuk diunggah
    Saya juga penasaran apakah ada kemungkinan Chrome membatalkan keputusan penghentian dukungannya

    • Logika dari pihak Chrome adalah tidak adanya dukungan industri. Dukungan industri di sini tampaknya berarti sesuatu yang lebih dari sekadar ucapan di issue tracker, jadi kita harus melihat bagaimana adopsinya setelah Safari mendukungnya
      Kenaikan penggunaan JXL bisa menjadi alasan yang cukup untuk memasukkan kembali dukungan JXL, dan kali ini seharusnya bukan di balik flag eksperimen, melainkan dukungan bawaan. Firefox juga mungkin akan memasukkannya ke build pengguna umum tanpa flag
    • Sepertinya Chrome tidak akan berbalik arah
      Kalau Microsoft, mungkin mereka bisa menekan Google lewat pengaruh seperti default Edge/Windows atau aplikasi untuk lingkungan kerja
    • Satu-satunya cara menghilangkan kekuatan monopoli Chrome adalah membuat keputusan mereka menjadi tidak penting
      Ubah semua gambar di situs web menjadi JXL dan biarkan Chrome memberikan pengalaman yang buruk; apakah mereka akan memperbaikinya atau tidak, itu urusan mereka

  • Saat JPEG masih baru, ini membangkitkan nostalgia tentang masa ketika untuk melihat file jpg, kita memerlukan aplikasi eksternal sampai browser mengadopsi standar tersebut
    Setelah itu, kita harus melihat apakah situs favorit kita punya cukup banyak gambar jpg untuk menentukan apakah perlu ganti browser

  • Masalah JPEG XL tampaknya adalah branding. Dari namanya saja terasa seperti JPEG tetapi dengan ukuran file lebih besar, dan itu jelas bukan yang diinginkan

    • Saya tidak melihat itu sebagai masalah utamanya, tetapi saya setuju bahwa namanya langsung memberi kesan seperti itu
      Seharusnya tidak terlalu sulit memberi nama yang memberi kesan “file yang lebih baik”, bukan “file extra large”
    • Seharusnya namanya JPEG SX

  • Tidak yakin apakah hasil model seperti SSIMULACRA bisa dipercaya.
    Mungkin saya tidak melakukan encoding dengan benar, tetapi saat bereksperimen mengompresi beberapa foto yang diambil dengan Sony α7ii pada kualitas tinggi, kesimpulannya adalah WEBP secara konsisten lebih baik daripada JPEG, dan AVIF tidak lebih baik daripada WEBP. Pada kualitas rendah seperti gambar hero blog, saya merasa AVIF unggul.
    Belakangan ini saya tertarik mengunggah gambar gamut lebar ke web. Ini berawal dari penemuan bahwa monitor Adobe RGB kira-kira menambahkan lebih banyak merah saat diminta menampilkan hijau sRGB, karena hijau sRGB lebih kekuningan daripada hijau Adobe RGB, dan ini fatal saat membuat gambar stereoskopik anaglif merah-biru.
    Setelah fenomena ini bisa dikendalikan, saya jadi tertarik mempublikasikan foto datar dalam gamut lebar. Biasanya saya memproses dalam ProPhotoRGB, jadi langkah pertamanya sederhana. Banyak perangkat mobile mendekati Display P3, dan banyak TV serta monitor baru mendekati Rec 2020, meski selain monitor Dolby yang harganya tidak masuk akal saya tidak tahu banyak produk yang benar-benar mencakupnya dengan baik.
    Diagram ruang warna ada di sini: [https://en.wikipedia.org/wiki/Rec._2020#/media/File:CIE1931x...](https://en.wikipedia.org/wiki/Rec._2020#/media/File:CIE1931xy_gamut_comparison_of_sRGB_P3_Rec2020.svg)
    Adobe RGB dan Display P3 tidak jauh lebih besar daripada ruang sRGB, jadi 8-bit per kanal warna masih cukup, tetapi untuk bekerja di ProPhotoRGB atau Rec 2020 benar-benar dibutuhkan lebih banyak bit. Saya melakukan mastering dalam 16-bit, tetapi untuk distribusi biasanya memakai format 10-bit atau 12-bit, jadi saya kembali tertarik pada AVIF dan JPEG XL.
    Namun saya belum yakin apakah itu sepadan, karena ruang warna yang muncul dalam pemandangan alami hanya sedikit lebih besar daripada sRGB.
    https://tftcentral.co.uk/articles/pointers_gamut
    Secara teori itu juga jauh lebih kecil daripada ruang warna yang dapat dipersepsi, misalnya dibandingkan hijau dari laser pointer hijau. Jelas Adobe RGB cukup baik mencakup warna yang bisa dicetak dengan proses CMYK, tetapi orang-orang tidak terlalu menuntut warna yang ekstrem. Karena tampaknya ke depan kita makin bisa menyediakan warna-warna seperti itu, saya jadi memikirkan cara memakainya secara bermakna sambil mempertimbangkan risiko merusak gambar akibat perangkat lunak yang cacat.

    • Display P3 yang didukung monitor bagus tetapi murah jelas jauh lebih besar daripada sRGB. Merah pada Display P3 terlihat cukup murni, tetapi merah pada sRGB terlalu kusam dan kekuningan hingga sulit diterima.
      Adobe RGB dirancang untuk gambar cetak yang lebih baik, dan karena tidak memperbaiki kelemahan utama sRGB yaitu merah, ia tidak berguna untuk monitor.
      Jika monitor Dell Display P3 (U2720Q) saya diubah dari warna 30-bit ke 24-bit, hasilnya jelas lebih buruk.
      Setidaknya dalam pengalaman saya, untuk mendapatkan peningkatan dari Display P3 selalu dibutuhkan 10-bit per komponen warna, dan pada monitor perbedaan antara Display P3 atau DCI P3 dengan sRGB sangat mudah terlihat.
      Banyak benda merah yang bisa dilihat setiap hari punya merah yang lebih jenuh daripada yang bisa direproduksi monitor sRGB. Pakaian, bunga, bahkan darah adalah contohnya.
      Untuk distribusi gambar atau film, saya setuju bahwa ruang warna Rec. 2020 adalah pilihan yang benar. Meski hampir tidak ada orang yang punya proyektor laser yang bisa mereproduksi seluruh ruang warna Rec. 2020.
      Segelintir orang yang punya perangkat yang sesuai bisa mereproduksi gambar sebagaimana didistribusikan, dan bagi yang lain konversi ruang warna sangat sederhana. Sebaliknya, jika didistribusikan dalam ruang warna lawas seperti sRGB atau Adobe RGB, bahkan orang dengan display yang lebih baik tetap harus melihat gambar berkualitas lebih rendah.
    • Sekarang saya kira idealnya mendistribusikan dalam Rec2020 dan membiarkan perangkat mengonversinya ke ruang warna bawaannya sendiri.
      AdobeRGB sekarang saya anggap hampir tidak relevan, murni warisan lama. Display-P3 masuk akal kalau hanya hidup di dalam ekosistem Apple dan memang hanya menargetkan itu, tetapi selain itu tidak terlalu menarik.
      ProPhoto sendiri bagus, tetapi karena Rec2020 sudah cukup lebar, saya tidak yakin perlu punya ruang warna RGB terpisah khusus untuk pemrosesan. Tentu saja, kalau alur kerja ProPhoto yang ada sudah berjalan baik, rasanya juga tidak ada alasan untuk menggantinya.
    • Menyamakan warna pada pemandangan alami dengan ruang warna yang berasal dari pantulan difus menurut saya tidak adil.
      Kembang api, pertunjukan cahaya, langit, setup LED RGB 1337, seni fluoresen, dan hal-hal lain yang ingin dipotret orang melibatkan fenomena seperti emisi, hamburan, dan pantulan spekular.
      Kenyataannya, ruang warna teoritis yang lebih besar yang dapat dipersepsi penuh dengan fenomena sehari-hari, dan warna yang sangat mencolok serta adegan HDR, misalnya kembang api di langit gelap, adalah hal yang sangat suka dilihat dan dipotret orang.
    • Kalau bicara kualitas gambar, pernyataan bahwa WEBP secara konsisten lebih baik daripada JPEG cukup mengejutkan.
      Saya selalu merasa kualitas WebP secara konsisten lebih buruk daripada JPEG.
      Saya hanya memakai WebP untuk gambar lossless, karena setidaknya saat itu ukurannya lebih kecil daripada PNG.

  • Ekosistem Apple relatif terisolasi.
    Mereka mengadopsi HEIF, tetapi tidak mengadopsi video AV1.

    • Apple juga mengadopsi HEIC, yang merupakan standar yang sangat terjerat paten sehingga cukup berisiko bagi browser untuk mendukungnya di web terbuka.
    • Memang benar ekosistem Apple relatif terisolasi.
      Meski begitu, Apple merilis komputer konsumen pertama yang mendukung Display P3 pada 2015 [1].
      Sejumlah vendor lain termasuk Google juga merilis perangkat dengan dukungan Display P3, tetapi 2 miliar perangkat Apple jelas bukan angka kecil.
      [1]: https://en.m.wikipedia.org/wiki/DCI-P3#History

  • Akan bagus jika format BPG milik Bellard juga dimasukkan. Saya tidak tahu apakah format itu punya masalah praktis atau tidak https://bellard.org/bpg/
    Perlu juga dicatat bahwa jpg xl berbeda dari jpg 2000 dan jpg xr.

    • BPG berbasis HEVC, jadi ada beban paten dan lisensi.
    • Dalam pengujian Cloudinary dulu, BPG ternyata sangat baik, secara mengejutkan melampaui AV1 dan JPEG XL dalam beberapa atau banyak kategori.
      Karena itu saya jadi percaya bahwa kalau BPG memakai VVC hasilnya akan lebih baik lagi.

  • Saya sungguh merasa jpeg xl akan lebih berhasil jika punya nama yang lebih baik

    • Ekstensi yang panjang memang didukung dengan baik, tetapi tetap saja .jxl adalah ekstensi file yang cukup keren dan ringkas. Meski begitu, menurut saya *.jpegxl juga seharusnya dikenali
      Jika formatnya sendiri mulai mendapat momentum, rasanya pada akhirnya itu akan diakui secara de facto
    • JXL lebih baik daripada Jpeg XL. Kalau nanti jadi populer, orang mungkin akan menyebutnya “jexel” alih-alih “jaypeg”
    • Menurut saya, merujuk ke JPEG justru cerdas. Itu langsung membuat pengguna umum mengenalinya sebagai “gambar”, dan menempatkan format ini sebagai penerusnya