Google awalnya mengembangkan WebP sebagai format gambar lossy untuk menggantikan JPEG, yang mampu menghasilkan file yang lebih kecil daripada file gambar berkualitas sebanding yang dienkode sebagai JPEG. Update berikutnya pada format tersebut memperkenalkan opsi kompresi lossless, transparansi saluran alfa seperti PNG, dan animasi seperti GIF—yang semuanya dapat digunakan bersama kompresi lossy bergaya JPEG. WebP adalah format yang luar biasa.
Algoritma kompresi lossy WebP didasarkan pada metode yang digunakan codec video VP8 untuk mengompresi keyframe dalam video. Pada tingkat yang tinggi, ini mirip dengan encoding JPEG: WebP beroperasi dalam istilah "blok", bukan piksel individual, dan memiliki pembagian yang serupa antara luminance dan chrominance. Blok luma WebP berukuran 16x16, sedangkan blok kroma 8x8, dan "blok makro" tersebut dibagi lagi menjadi sub-blok 4x4.
Di mana WebP sangat berbeda dari JPEG terdapat dalam dua fitur: "prediksi blok" dan "kuantisasi blok adaptif".
Prediksi Blokir
Prediksi blok adalah proses saat konten setiap blok chrominance dan luminance diprediksi berdasarkan nilai blok di sekitarnya—khususnya blok di atas dan di sebelah kiri blok saat ini. Seperti yang dapat Anda bayangkan, algoritma yang melakukan pekerjaan ini cukup kompleks, tetapi dalam bahasa sederhana: "jika ada biru di atas blok saat ini, dan biru di sebelah kiri blok saat ini, anggap blok ini berwarna biru".
Sebenarnya, PNG dan JPEG juga melakukan prediksi semacam ini pada tingkat beberapa. Namun, WebP bersifat unik karena mengambil sampel data blok di sekitarnya, lalu mencoba mengisi blok saat ini dengan beberapa "mode prediksi" yang berbeda, yang secara efektif mencoba "menggambar" bagian gambar yang hilang. Hasil yang diberikan oleh setiap mode prediksi kemudian dibandingkan dengan data gambar sebenarnya, dan kecocokan prediktif terdekat akan dipilih.
Tentunya, pencocokan prediktif terdekat sekali pun tidak sepenuhnya benar, sehingga perbedaan antara nilai prediksi dan nilai sebenarnya dari blok tersebut akan dienkode dalam file tersebut. Saat mendekode gambar, mesin rendering menggunakan data yang sama untuk menerapkan logika prediktif yang sama, sehingga mengarah ke nilai prediksi yang sama untuk setiap blok. Perbedaan antara prediksi dan gambar yang diharapkan yang dienkode dalam file kemudian diterapkan pada prediksi. Mirip dengan bagaimana Git commit mewakili patch diferensial yang diterapkan pada file lokal, bukan salinan baru dari file tersebut.
Sebagai ilustrasi: daripada menggali matematika kompleks yang terlibat dalam algoritma prediktif yang sebenarnya, kami akan membuat encoding seperti WebP dengan satu mode prediksi, dan menggunakannya untuk secara efisien menyampaikan petak angka seperti yang kita lakukan pada format lama. Algoritma kita memiliki mode prediksi tunggal, yang disebut "mode prediksi satu": nilai setiap blok adalah jumlah nilai blok di atasnya dan di sebelah kirinya, dimulai dengan 1.
Sekarang, misalkan kita memulai dengan data gambar sebenarnya berikut:
111151111
122456389
Dengan menggunakan model prediktif kita untuk menentukan isi kisi 2x9, kita akan mendapatkan hasil berikut:
111111111
123456789
Data kita cocok untuk algoritma prediktif yang kita temukan—data yang diprediksi sangat mendekati data kita yang sebenarnya. Tentu saja tidak cocok—data aktual memiliki beberapa blok yang berbeda dari data yang diprediksi. Jadi, encoding yang kami kirim tidak hanya menyertakan metode prediksi yang akan digunakan, tetapi juga perbedaan dari blok apa pun yang harus berbeda dari nilai yang diprediksi:
_ _ _ _ +4 _ _ _ _
_ _ -1 _ _ _ -4 _ _
Masukkan jenis bahasa sederhana yang sama dengan beberapa encoding format lama yang telah kita bahas:
Petak 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. Hal ini jelas masuk akal dalam sebuah gambar dengan komposisi yang seragam, tetapi foto dunia nyata tidak lebih seragam dibandingkan dunia di sekitar kita. Dalam praktiknya, hal ini berarti bahwa setelan kompresi JPEG kami tidak ditentukan oleh detail frekuensi tinggi—dengan keunggulan kompresi JPEG—tetapi oleh bagian gambar tempat artefak kompresi paling mungkin muncul.
Seperti yang Anda lihat dalam contoh yang berlebihan ini, sayap raja di latar depan terlihat relatif tajam—sedikit kasar jika dibandingkan dengan gambar asli resolusi tinggi, tetapi tentu tidak terlihat tanpa versi aslinya untuk dibandingkan dengannya. Demikian juga, detail bunga milkweed dan daun di latar depan—Anda dan saya mungkin melihat jejak artefak kompresi dengan mata terlatih kami, tetapi bahkan dengan kompresi yang ditingkatkan jauh melebihi tingkat wajar, warna di latar depan masih terlihat jelas. Informasi frekuensi rendah di kiri atas gambar—latar belakang daun berwarna hijau buram—terlihat mengerikan. Bahkan penonton yang tidak terlatih pun akan langsung melihat masalah kualitas—gradien halus di latar belakang dibulatkan ke bawah menjadi blok warna solid yang bergerigi.
Untuk menghindari hal ini, WebP mengambil pendekatan adaptif untuk kuantisasi: gambar dibagi menjadi hingga empat segmen yang mirip secara visual, dan parameter kompresi untuk segmen tersebut disesuaikan secara independen. Menggunakan kompresi besar yang sama dengan WebP:
Ukuran kedua file gambar ini kurang lebih sama. Kualitasnya hampir sama jika kita melihat sayap raja—Anda dapat melihat beberapa perbedaan kecil pada hasil akhirnya jika dilihat sangat, sangat dekat, tetapi tidak ada perbedaan nyata dalam kualitas secara keseluruhan. Di WebP, bunga milkweed hanya sedikit lebih tajam—sekali lagi, mungkin tidak cukup terlihat kecuali Anda membandingkan keduanya secara berdampingan dan benar-benar mencari perbedaan kualitas, seperti yang kami lihat. Latar belakangnya sama sekali berbeda: hampir tidak ada artefak JPEG yang terlihat jelas. WebP memberi kita ukuran file yang sama, tetapi gambar dengan kualitas yang jauh lebih tinggi—memberikan atau mengambil beberapa detail kecil yang tidak dapat dideteksi oleh sistem psikovisual kami jika kami tidak membandingkan keduanya dengan begitu dekat.
Menggunakan WebP
Bagian internal WebP mungkin jauh lebih kompleks daripada encoding JPEG, tetapi sama sederhananya untuk tujuan pekerjaan sehari-hari kita: semua kompleksitas encoding WebP distandarkan pada satu nilai "kualitas"—yang dinyatakan dari 0–100, sama seperti JPEG. Sekali lagi, hal itu bukan berarti bahwa Anda dibatasi pada satu setelan "kualitas" yang menyeluruh. Anda dapat—dan sebaiknya—mengutak-atik semua detail encoding WebP, jika hanya untuk mendapatkan pemahaman yang lebih baik tentang pengaruh setelan yang biasanya tidak terlihat ini terhadap ukuran dan kualitas file.
Google menawarkan encoder command line cwebp yang memungkinkan Anda mengonversi atau mengompresi setiap file 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 menampilkan kode WebP. Fitur ini memberi kami opsi perbandingan berdampingan antara encoding, setelan, tingkat kualitas, dan perbedaan ukuran file yang berbeda dari encoding JPEG.