Google awalnya mengembangkan WebP sebagai format gambar lossy untuk menggantikan JPEG, yang mampu menghasilkan file berukuran lebih kecil dari file gambar dengan kualitas setara yang dikodekan sebagai JPEG. Kemudian pembaruan pada format tersebut memperkenalkan opsi kompresi lossless, Transparansi saluran alfa mirip PNG, dan animasi seperti GIF—semuanya dapat digunakan bersama kompresi lossy bergaya JPEG. WebP adalah format yang luar biasa.
Algoritma kompresi lossy WebP didasarkan pada metode yang codec video VP8 untuk mengompresi keyframe dalam video. Secara umum, cara ini mirip dengan encoding JPEG: WebP beroperasi dari segi "blok" bukan piksel individual, serta memiliki pembagian yang serupa antara luminans dan krominans. Blok luma WebP berukuran 16x16, sedangkan blok kroma berukuran 8x8, dan "macroblock" adalah kemudian dibagi lagi menjadi 4 x 4 sub-blok.
Perbedaan WebP secara drastis dengan JPEG terletak dalam dua fitur: "prediksi blok" dan "kuantisasi blok adaptif".
Blokir Prediksi
Prediksi blok adalah proses prediksi isi setiap blok krominan dan luminans berdasarkan nilai balok-balok di sekitarnya—khususnya balok di atas dan di sebelah kiri balok yang aktif. Seperti yang Anda bayangkan, algoritma yang melakukan pekerjaan ini cukup rumit, tetapi dalam bahasa sederhana: "jika ada warna biru di atas blok saat ini, dan biru di sebelah kiri dari blok yang aktif, anggaplah blok ini berwarna biru."
Sebenarnya, baik PNG dan JPEG juga melakukan prediksi semacam ini hingga beberapa derajat. Namun, WebP memiliki keunikan karena sampel ini mengambil sampel block data lalu mencoba mengisi blok saat ini dengan beberapa "mode prediksi" yang berbeda, mencoba "menggambar" secara efektif bagian yang hilang dari gambar. Hasil yang diberikan oleh masing-masing mode prediksi kemudian dibandingkan dengan data gambar asli, dan pencocokan prediktif dipilih.
Bahkan kecocokan prediktif terdekat pun tidak akan sepenuhnya benar, jadi perbedaan antara prediksi nilai aktual dari blok itu dienkodekan dalam file. Saat mendekode gambar, mesin rendering menggunakan data yang sama untuk menerapkan logika prediktif yang sama, yang mengarah ke nilai prediksi yang sama untuk setiap blok. Perbedaan antara prediksi dan gambar yang diharapkan yang dienkode dalam file tersebut lalu diterapkan di atas prediksi—serupa dengan bagaimana commit Git merepresentasikan perbedaan {i>patch<i} yang diterapkan pada file lokal, bukan salinan baru dari file tersebut.
Sebagai ilustrasi: kita tidak akan mendalami matematika kompleks dalam algoritma prediktif yang sebenarnya, melainkan akan membuat encoding seperti WebP dengan satu mode prediksi, dan menggunakannya untuk menyampaikan petak angka secara efisien seperti yang kita lakukan pada format lama. Algoritma kami memiliki satu mode prediksi, yang akan kita sebut "mode prediksi satu:" nilai setiap blok adalah jumlah nilai blok di atas itu dan di sebelah kirinya, dimulai dengan 1.
Sekarang, misalkan kita memulai dengan data gambar asli berikut:
111151111
122456389
Dengan menggunakan model prediktif untuk menentukan konten grid 2x9, kita akan mendapatkan hasil berikut:
111111111
123456789
Data kita cocok dengan algoritma prediktif yang telah kita ciptakan—data prediksinya sangat cocok dengan data sebenarnya. Data aktual memiliki beberapa blok yang berbeda dari data prediksi. Jadi, encoding yang kami kirim tidak hanya menyertakan metode prediksi yang akan digunakan, melainkan juga hasil operasi diff dari blok apa pun yang seharusnya berbeda dari nilai prediksinya:
_ _ _ _ +4 _ _ _ _
_ _ -1 _ _ _ -4 _ _
Masukkan bahasa sederhana yang sama seperti beberapa encoding format lama yang telah kita bahas:
Kisi 2x9 menggunakan mode prediksi satu. +4 hingga 1x5, -1 hingga 2x3, -4 hingga 2x7.
Hasil akhirnya adalah file berenkode yang sangat efisien.
Kuantisasi blok adaptif
Kompresi JPEG adalah operasi menyeluruh, yang menerapkan tingkat kuantisasi yang sama ke setiap blok dalam gambar. Dalam gambar dengan komposisi yang seragam, tentu saja masih masuk akal—tetapi foto dunia nyata tidak lebih seragam dari dunia di sekitar kita. Dalam praktiknya, ini berarti bahwa setelan kompresi JPEG kami ditentukan bukan oleh detail frekuensi tinggi—dengan JPEG unggul dalam kompresi data—tetapi ada di bagian gambar yang paling mungkin muncul artefak kompresi.
Seperti yang dapat Anda lihat dalam contoh yang berlebihan ini, sayap raja di latar depan terlihat relatif tajam—sedikit berbintik jika dibandingkan dengan foto asli yang beresolusi tinggi, namun tentu saja tidak terlihat tanpa versi aslinya untuk dibandingkan. Demikian juga, perbungaan mendetail dari milkweed, dan daun di latar depan—Anda dan saya mungkin melihat jejak kompresi artefak dengan mata terlatih, tapi bahkan dengan kompresi yang meningkat jauh melampaui tingkat yang wajar, hal-hal di latar depan masih terlihat jelas. Informasi frekuensi rendah di kiri atas gambar—latar belakang daun hijau buram—terlihat sangat buruk. Bahkan pemirsa yang tidak terlatih pun akan langsung menyadari masalah kualitas—gradien halus di latar belakang dibulatkan ke bawah menjadi blok berwarna solid yang bergerigi.
Untuk menghindari hal ini, WebP menggunakan pendekatan adaptif untuk kuantisasi: sebuah gambar dibagi menjadi empat bagian yang secara visual serupa segmen, dan parameter kompresi untuk segmen tersebut di-tuning secara independen. Menggunakan kompresi berukuran besar yang sama dengan WebP:
Ukuran kedua file gambar ini hampir sama. Kualitasnya hampir sama saat kita melihat sayap raja—Anda dapat menemukan beberapa perbedaan kecil di hasil akhir jika Anda melihat dengan sangat dekat, tetapi tidak ada perbedaan nyata dalam kualitas keseluruhan. Di WebP, bunga milkweed hanya sedikit lebih tajam—sekali lagi, kemungkinan tidak cukup terlihat kecuali jika Anda membandingkan keduanya secara berdampingan dan benar-benar mencari perbedaan dalam kualitas, seperti itu. Latar belakang cerita berbeda keseluruhan: hampir tidak ada jejak JPEG dari artefak JPEG yang terlihat jelas. WebP memberi kita ukuran file yang sama, tetapi jauh lebih tinggi yang berkualitas—berikan atau ambil beberapa detail kecil yang tidak dapat dideteksi oleh sistem psikovisual kita jika tidak dibandingkan keduanya dengan sangat dekat.
Menggunakan WebP
Internal WebP mungkin jauh lebih kompleks daripada encoding JPEG, namun, sama sederhananya untuk pekerjaan: semua kompleksitas encoding WebP distandarisasi pada satu "kualitas" —dinyatakan dari 0–100, seperti JPEG. Sekali lagi, hal ini bukan berarti Anda terbatas pada satu "kualitas" yang menyeluruh deskripsi tempat. Anda bisa—dan harus—mengotak-atik semua detail encoding WebP, jika hanya untuk mendapatkan pemahaman yang lebih baik tentang bagaimana setelan yang biasanya tidak terlihat ini dapat memengaruhi ukuran dan kualitas file.
Google menawarkan encoder command line cwebp yang memungkinkan Anda mengonversi atau mengompresi file individual atau seluruh direktori gambar:
$ cwebp -q 80 butterfly.jpg -o butterfly.webp
Saving file 'butterfly.webp'
File: butterfly.jpg
Dimension: 1676 x 1418
Output: 208418 bytes Y-U-V-All-PSNR 41.00 43.99 44.95 41.87 dB
(0.70 bpp)
block count: intra4: 7644 (81.80%)
Intra16: 1701 (18.20%)
Skipped: 63 (0.67%)
bytes used: header: 249 (0.1%)
mode-partition: 36885 (17.7%)
Residuals bytes |segment 1|segment 2|segment 3|segment 4| total
macroblocks: | 8%| 22%| 26%| 44%| 9345
quantizer: | 27 | 25 | 21 | 13 |
filter level: | 8 | 6 | 19 | 16 |
Dan jika Anda tidak cenderung menggunakan command line, Squoosh juga akan membantu kita melakukan encoding WebP. Ini memberi kita opsi perbandingan berdampingan antara berbagai encoding, setelan, tingkat kualitas, dan perbedaan ukuran file dari encoding JPEG.