
WebP mi AVIF mi: hangisi ne zaman kazanır
Ölçülmüş sıkıştırma oranları, WebP'nin 8 bit ve 4:2:0 sınırları, AVIF'in kodlama maliyeti ve ilerlemeli yükleme eksiği ile hangi içerikte hangisi doğru.

Kalite ayarındaki 80 bir yüzde değil, nicemleme tablosunu ölçekleyen bir sayı. Görünmeyen kaybın sınırını bulmak için ayarı taşımak değil, ölçmek gerekiyor.
Hiçbir şeyin. JPEG kodlayıcılarında kalite değeri bir yüzde değil, nicemleme (quantization) tablosunu ölçekleyen bir sayıdır. Kodlayıcı görüntüyü 8 × 8 bloklara ayırıp her bloğu frekans katsayılarına çevirir, sonra bu katsayıları tablodaki bölenlere bölüp yuvarlar. Kalite değeri o bölenleri büyütür ya da küçültür. İki farklı kodlayıcının 80'i aynı tabloyu vermez, aynı kodlayıcının 80'i farklı alt örnekleme ayarıyla aynı görsel sonucu vermez.
Bunun pratik karşılığı şu: bir projede işe yarayan sayıyı başka projeye taşımak güvenli değil. Taşınabilir olan şey ayar değil, yöntemdir. Aşağıdaki sıra da bu yüzden önemli.
4000 × 3000 piksel bir fotoğraf 12 megapiksel taşır. Aynı görseli sitede 800 × 600 kutuda gösteriyorsanız ihtiyacınız 0,48 megapiksel; yani 25 kat fazla veri sıkıştırıyorsunuz. Yüksek yoğunluklu ekranlar için iki katı çözünürlük verseniz bile 1600 × 1200 = 1,92 megapiksel, hâlâ altıda bir. Hiçbir kalite ayarı bu oranı yakalayamaz ve ölçü düşürmek görüntüyü bozmaz, sadece küçültür.
Bu yüzden akışın ilk adımı daima yeniden boyutlandırma olmalı, gerekiyorsa kırpma ile birlikte. Sıkıştırma ayarıyla uğraşmak, görsel zaten doğru ölçüye indikten sonra anlamlı hale gelir.
Fotoğraf makinesinden çıkan bir JPEG'in içinde piksel dışında epey şey vardır: EXIF blokları, GPS kaydı, üretici notları, bazen XMP ve neredeyse her zaman gömülü bir önizleme görüntüsü. O önizleme kendi başına tam bir JPEG'dir ve makineye göre birkaç kilobayttan birkaç yüz kilobayta kadar çıkabilir. Web için hazırlarken bunların hiçbiri gerekmez ve EXIF temizleyici ile hepsi tek adımda gider.
Tek istisna ICC renk profilidir. Görsel sRGB ise profili atmak güvenlidir. Display P3 gibi geniş gamlı bir profille kaydedilmişse profili silmeyin: tarayıcı profilsiz görseli sRGB varsayar ve renkler, özellikle doygun kırmızı ve yeşiller, gözle görülür biçimde kayar. Doğru yol profili silmek değil, görseli sRGB'ye dönüştürüp öyle kaydetmektir.
İnsan gözü parlaklık değişimine renk değişiminden çok daha duyarlıdır, kayıplı kodlayıcılar da bunu kullanır. 4:4:4'te her piksel için üç örnek (Y, Cb, Cr) saklanır. 4:2:0'da 2 × 2'lik bir blokta dört parlaklık örneğine karşılık yalnızca bir Cb ve bir Cr örneği vardır: 12 yerine 6 örnek, yani sıkıştırma başlamadan önce veri yarıya iner.
Fotoğrafta bu bedel neredeyse görünmez. Görünür olduğu yerler bellidir: beyaz zemin üzerinde kırmızı ya da mavi yazı, ince renkli çizgiler, keskin kenarlı logolar ve arayüz ekran görüntüleri. Bu içerik tiplerinde 4:4:4'e geçmek, kaliteyi düşürüp alt örneklemeyi açık bırakmaktan daha iyi bir takastır. Kayıplı WebP'nin bu seçeneği hiç olmadığını da hesaba katın; formatların sınırlarını WebP mi AVIF mi yazısında karşılaştırdık.
"Bana iyi göründü" ölçeklenmeyen bir yöntemdir: ekranınıza, yakınlaştırma oranınıza ve o gün ne kadar dikkatli olduğunuza bağlıdır. Ölçülebilir alternatifi perceptual metriklerdir. Butteraugli ve onun üzerine kurulu SSIMULACRA 2, iki görüntü arasındaki farkı insan görüşünün duyarlılığına göre ağırlıklandırır.
SSIMULACRA 2'nin ölçeği kullanışlı, çünkü skorları somut kodlayıcı ayarlarına bağlıyor:
Web için pratik hedef bandı 70 ile 85 arası. Sayfanın en üstündeki tanıtım görseli ve ürün fotoğrafı için 85, listelerdeki küçük resimler için 70 civarı makul. Arşiv ve baskı öncesi kopyada ise 90'ın altına inmeyin.
Temsili beş görselinizi seçin, her birini 95, 90, 85, 80, 75 ve 70'te üretip boyutları bir tabloya yazın. Göreceğiniz şey neredeyse her zaman aynıdır: eğri üst uçta çok diktir. 95'ten 90'a inmek dosyayı belirgin şekilde küçültür ve görsel fark bırakmaz; 75'ten 70'e inmek az bayt kazandırır ama artefaktı belirgin biçimde artırır. Diz noktası genelde 80 ile 85 arasındadır, ama kataloğunuzun içeriğine göre kayar. Toplu üretim için görsel sıkıştırma aracı bu merdiveni kurmanın en hızlı yolu.
Bir çıktıyı denetlerken rastgele bakmayın. Bozulma hep aynı dört yerde başlar, doğrudan oralara gidin ve %100 yakınlaştırmada, hedef cihazda inceleyin.
8 bit bir kanalda bir gradyan zaten yalnızca 256 kademeye sahiptir. Nicemleme bu kademelerin bir kısmını birleştirince geçiş şeritlere ayrılır. Sezgiye aykırı ama işe yarayan çözüm, kodlamadan önce çok hafif bir gürültü ya da dither eklemektir: rastgelelik kademe sınırını dağıtır ve şerit algısı kaybolur. Bedeli birkaç kilobayttır ve kaliteyi bir basamak yükseltmekten daha ucuza aynı sorunu çözer.
Kayıplı bir dosyayı açıp yeniden kaydetmek jenerasyon kaybı üretir. Burada ince bir ayrım var. Aynı kodlayıcı, aynı ayar ve aynı piksel boyutuyla yeniden kaydederseniz sonuç şaşırtıcı biçimde kararlıdır, çünkü sinyal zaten o nicemleme ızgarasına oturmuştur. Boyutu tek piksel değiştirin ya da döndürün: 8 × 8 blok ızgarası kayar, her blok yeni komşularla yeniden nicemlenir ve bozulma hızla birikir.
Bu yüzden tek kural şu: çıktıyı her zaman orijinal masterdan türetin, daha önce teslim ettiğiniz dosyadan değil. Kaliteyi yükseltmek kaybı geri getirmez; yalnızca mevcut artefaktları daha sadık saklar ve dosyayı büyütür. Aynı mantık format değişiminde de geçerli: JPEG'i AVIF'e çevirirken kaynak JPEG'in artefaktları da kodlanır, bu yüzden kazanç orijinalden dönüştürmeye kıyasla daha azdır.
PNG kayıpsızdır, yani "PNG sıkıştırma" dendiğinde iki farklı şeyden biri kastedilir. Birincisi filtre seçimi ve deflate optimizasyonudur: pikseller bit bit aynı kalır, kazanç mütevazıdır ama risksizdir. İkincisi palet nicemlemesidir; görüntü 256 renge indirgenir, bu işlem kayıplıdır ama ikon, arayüz grafiği ve düz renkli çizimlerde çoğu zaman gözle ayırt edilmez ve kazanç büyüktür.
Fotoğraf için PNG en baştan yanlış tercihtir. Saydamlık gerekmiyorsa kayıplı bir formata, gerekiyorsa alfa destekleyen modern bir formata geçin; PNG'den WebP'ye aracı hem kayıplı hem kayıpsız modu denemenize izin verir.
Kodlayıcıdan bağımsız tek bir sayı yok, ama SSIMULACRA 2 ölçeği iyi bir referans veriyor: 70 puan (yaklaşık libjpeg-turbo 4:2:0 kalite 70) orijinali görmeyen birinin fark etmediği seviye, 90 puan (yaklaşık 4:4:4 kalite 95) görsel olarak kayıpsız kabul ediliyor. Web için 70-85 bandı, arşiv için 90 ve üstü makul.
Aynı kodlayıcı, aynı ayar ve aynı piksel boyutuyla kaydederseniz sonuç nispeten kararlıdır. Boyutu değiştirir ya da döndürürseniz 8 x 8 blok ızgarası kayar ve her kaydetmede yeni artefakt birikir. Çıktıyı her zaman orijinalden üretin.
Piksellere dokunmaz, sadece metadata ve gömülü önizlemeyi kaldırır. Dikkat edilecek tek şey ICC profilidir: görsel Display P3 gibi geniş gamlı bir profille kaydedilmişse profili silmek renkleri kaydırır. Önce sRGB'ye dönüştürün, sonra temizleyin.
Bantlanma 8 bit gradyanın 256 kademesinin nicemlemeyle birleşmesinden çıkar. Kaliteyi yükseltmek pahalı bir çözümdür; kodlamadan önce çok hafif gürültü veya dither eklemek kademe sınırlarını dağıtır ve birkaç kilobayta aynı sonucu verir.
Hangi yöntemi kullandığınıza bağlı. Filtre ve deflate optimizasyonu tamamen kayıpsızdır, pikseller bit bit aynı kalır. Palet nicemlemesi ise görüntüyü 256 renge indirir; kayıplıdır ama arayüz grafiği ve düz renkli çizimde genelde görünmez.

Ölçülmüş sıkıştırma oranları, WebP'nin 8 bit ve 4:2:0 sınırları, AVIF'in kodlama maliyeti ve ilerlemeli yükleme eksiği ile hangi içerikte hangisi doğru.

Görselden AI filigranı silmenin teknik karşılığı, hangi durumda temiz sonuç verdiği ve görünür rozeti silmenin gömülü köken bilgisini neden kaldırmadığı.