Google, WebP'yi ilk olarak JPEG'in yerini alacak kayıplı bir resim biçimi olarak geliştirmiştir. WebP, JPEG olarak kodlanmış karşılaştırılabilir kalitede bir resim dosyasından daha küçük dosyalar üretebilir. Biçimde sonradan yapılan güncellemeler, kayıpsız sıkıştırma, PNG benzeri alfa kanalı şeffaflığı ve GIF benzeri animasyon seçeneklerini kullanıma sundu. Bunların tümü JPEG stili kayıplı sıkıştırmayla birlikte kullanılabiliyor. WebP, inanılmaz çok yönlü bir biçimdir.
WebP'nin kayıplı sıkıştırma algoritması, VP8 video codec'inin videolardaki animasyon karelerini sıkıştırmak için kullandığı yönteme dayanır. Yüksek düzeyde, JPEG kodlamasına benzer: WebP, tek tek pikseller yerine "bloklar" olarak çalışır ve parlaklık ile renk tonu arasında benzer bir bölme bulunur. WebP'nin luma blokları 16x16, renk blokları ise 8x8 şeklindedir ve bu "makro bloklar" da 4x4 alt bloklara ayrılmıştır.
WebP'nin JPEG'den önemli ölçüde farklı olduğu iki özellik vardır: "engelleme tahmini" ve "uyarlanabilir blok niceleme".
Tahmini Engelle
Blok tahmini, her bir renk ve parlaklık bloğunun içeriklerinin, çevresindeki blokların (özellikle de mevcut blokun üstündeki ve solundaki blokların) değerlerine bağlı olarak tahmin edildiği işlemdir. Tahmin edebileceğiniz gibi, bu işi yapan algoritmalar oldukça karmaşıktır, ancak bunu yalın bir dille ifade etmek gerekirse: "Geçerli blokun üzerinde mavi ve geçerli bloğun solunda mavi varsa, bu bloğun mavi olduğunu varsayın."
Aslına bakılırsa, hem PNG hem de JPEG bu tür tahminleri bir derece kadar yapar. Bununla birlikte WebP, etraftaki blokların verilerini örnekleyip ardından birkaç farklı "tahmin modu" kullanarak mevcut bloğu doldurmaya çalışması ve resmin eksik kısmını etkili bir şekilde "çizmeye" çalışması açısından benzersizdir. Daha sonra her tahmin modunun sağladığı sonuçlar, gerçek görüntü verileriyle karşılaştırılır ve en yakın tahmine dayalı eşleşme seçilir.
En yakın tahmine dayalı eşleşme bile elbette tamamen doğru olmayacaktır. Bu nedenle, söz konusu bloğun tahmin edilen ve gerçek değerleri arasındaki farklar dosyaya kodlanır. Resmin kodunu çözerken oluşturma motoru, aynı tahmine dayalı mantığı uygulamak için aynı verileri kullanır. Böylece her blok için aynı öngörülen değerlere ulaşılır. Tahmin ile dosyada kodlanan beklenen görüntü arasındaki fark, daha sonra tahminlere uygulanır. Bu durum, Git kaydetmesinin dosyanın yeni bir kopyası yerine yerel dosyaya uygulanan diferansiyel yamayı temsil etmesine benzer.
Örnek olarak: Gerçek tahmine dayalı algoritmanın karmaşık matematiğinin ayrıntısına inmek yerine, tek tahmin modu ile WebP benzeri bir kodlama icat edecek ve bu kodlamayı, eski biçimlerde yaptığımız gibi bir sayı tablosunu verimli bir şekilde aktarmak için kullanacağız. Algoritmamızda tek bir tahmin modu vardır. Buna "tahmin modu birinci " denir: Her bloğun değeri, 1'den başlayarak üstünde ve solundaki blokların değerlerinin toplamıdır.
Şimdi aşağıdaki gerçek resim verileriyle başladığımızı düşünelim:
111151111
122456389
2x9'luk bir ızgaranın içeriğini belirlemek için tahmine dayalı modelimizi kullanarak aşağıdaki sonucu elde ederiz:
111111111
123456789
Verilerimiz, icat ettiğimiz tahmine dayalı algoritmaya oldukça uygundur. Tahmin edilen veriler, gerçek verilerimizle yakın bir eşleşmedir. Elbette mükemmel bir uyum değildir. Gerçek verilerde, tahmin edilen verilerden farklı birkaç blok bulunmaktadır. Dolayısıyla, gönderdiğimiz kodlama yalnızca kullanılacak tahmin yöntemini değil, tahmin edilen değerlerinden farklı olması gereken blokların farkını da içerir:
_ _ _ _ +4 _ _ _ _
_ _ -1 _ _ _ -4 _ _
Üzerinde konuştuğumuz bazı eski biçim kodlamalarıyla aynı sade bir dil kullanın:
Tahmin modu birinci kullanılarak 2x9 ızgara. +4 ila 1x5, -1-2x3, -4 ila 2x7.
Sonuç, inanılmaz derecede verimli bir kodlanmış dosya oluyor.
Uyarlanabilir blok niceleme
JPEG sıkıştırması, resimdeki her bloka aynı nicelendirme düzeyini uygulayan genel bir işlemdir. Tek tip bir kompozisyona sahip bir resimde bu elbette anlamlı olur, ancak gerçek dünya fotoğrafları çevremizdeki dünya kadar tek tip değildir. Pratikte bu, JPEG sıkıştırması ayarlarımızın, JPEG sıkıştırmasının üstün olduğu yüksek frekans ayrıntılarına göre değil, resmimizin sıkıştırma yapılarının görünme olasılığının en yüksek olduğu bölümlerine göre belirlendiği anlamına gelir.
Bu abartılı örnekte görebileceğiniz gibi, kralın kanatları ön planda nispeten keskin. Yüksek çözünürlüklü orijinaliyle karşılaştırıldığında biraz grenli görünen ama orijinaliyle karşılaştırılmadan fark edilemeyeceği kesindir. Benzer şekilde, süt otunun ayrıntılı çiçek oluşumu ve ön plandaki yapraklar. Eğitimli gözlerimizle birlikte kompresyon kalıntılarının izlerini görebilirsiniz, ancak kompresyonun makul seviyelerden çok daha fazla yükselmesine rağmen, ön plandakiler hâlâ berrak bir hal alıyor. Resmin sol üst tarafındaki düşük frekans bilgisi (yaprakların bulanık yeşil arka planı) berbat görünüyor. Eğitimsiz bir izleyici bile kalite sorununu anında fark eder; arka plandaki hafif gradyanlar, pürüzlü, düz renkli bloklara yuvarlanır.
WebP, bunu önlemek için sayısallaştırmaya yönelik uyarlanabilir bir yaklaşım uygular: Bir görüntü, görsel olarak benzer dört segmente bölünür ve bu segmentlerin sıkıştırma parametreleri bağımsız olarak ayarlanır. WebP ile aynı büyük boyutlu sıkıştırmayı kullanma:
İki resim dosyasının boyutu yaklaşık olarak aynıdır. Hükümdarın kanatlarına baktığımızda kalite hemen hemen aynıdır. Çok, çok yakından bakarsanız, sonuçta birkaç küçük farklılık görebilirsiniz, ancak genel kalitede gerçek bir fark olmaz. WebP'ye göre, süt otunun çiçekleri biraz daha keskindir. Yine de, bu ikisini yan yana karşılaştırıp, bizim haliyle kalitedeki farklılıklarını aramadığınız sürece muhtemelen fark edilirsiniz. Arka plan bambaşka bir hikaye: JPEG'in açıkça görülebilen yapılarının neredeyse hiçbir iz yok. WebP bize aynı dosya boyutunu ama çok daha yüksek kaliteli bir resim verir. İkisini bu kadar yakından karşılaştırmazsak, psiko-görsel sistemlerimizin algılayamayacağı birkaç küçük ayrıntı verin veya alın.
WebP'yi kullanma
WebP'nin dahili bileşenleri JPEG kodlamasından çok daha karmaşık olabilir, ancak günlük çalışmalarımız açısından bu kadar basit olabilir: WebP kodlamasının tüm karmaşıklığı, JPEG’de olduğu gibi 0-100 arasında ifade edilen tek bir "kalite" değeri etrafında standartlaştırılır. Tekrar belirtelim, bu tek bir kapsayıcı "kalite" ayarıyla sınırlı olduğunuz anlamına gelmez. Normalde görünmez olan bu ayarların dosya boyutunu ve kalitesini nasıl etkileyebileceğini daha iyi anlamak istiyorsanız WebP kodlamasının tüm ince ayrıntılarını düzenleyebilirsiniz (ve yapmanız gerekir).
Google, tek tek dosyaları veya tüm resim dizinlerini dönüştürmenize veya sıkıştırmanıza olanak tanıyan bir cwebp komut satırı kodlayıcısı sunar:
$ 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 |
Komut satırını tercih etmiyorsanız Squoosh, WebP'yi kodlama konusunda bize de yardımcı olacaktır. Farklı kodlamalar, ayarlar, kalite seviyeleri ve JPEG kodlamasından dosya boyutu farklılıkları arasında yan yana karşılaştırma seçeneği sunar.