Biçim tartışmaları genellikle kodekten başlayıp dışarı doğru gider. Bu ters bir sıra. Doğru biçime önce fotoğrafın içindekiler karar verir, ancak ondan sonra karşı tarafın neyi kabul ettiği.
Fotoğraflar: JPEG ya da WebP
Sürekli tonlu görseller — yüzler, manzaralar, geçişleri ve gren içeren her şey — kayıplı kodeklerle iyi sıkışır, çünkü göz kalabalık alanlardaki küçük hataları affeder. JPEG güvenli varsayılandır; sebebi de her yerin onu kabul etmesidir. Kayıplı WebP aynı algılanan kaliteye gözle görülür biçimde daha az baytla ulaşır, dolayısıyla hedefin izin verdiği her yerde kazanır.
Bunun için ToolZool kullanacaksan bir uyarı: sıkıştırıcımız WebP’yi yalnızca kayıpsız kipte yazar ve bu, bir fotoğrafta JPEG’in birkaç katı büyüklükte bir dosya üretir. Boyut sınırı olan bir fotoğraf için burada JPEG’i seç. Bu farkın nedeni sıkıştırıcının kendi sayfasında anlatılıyor — ne uyumsuz bir lisans ne de bir C araç zinciri gerektirmeden gönderebileceğimiz bir kayıplı WebP kodlayıcısı yok.
Düz grafikler ve metin: PNG
Logolar, simgeler, şemalar ve arayüz ekran görüntüleri keskin kenarlardan ve geniş, tek renkli alanlardan oluşur. Kayıplı kodekler keskin kenarları kötü işler: metnin çevresinde gözle görülür halkalanma çıkar ve kattıkları gürültünün kodlanması da pahalı olduğundan, dosya çoğu zaman aynı görselin kayıpsız PNG’sinden daha büyük olur.
Saydamlık seçimi belirler
JPEG’in alfa kanalı yoktur. Saydam bir PNG’yi JPEG’e dönüştürürsen saydam alanlar doluya döner — genellikle siyah, bazen beyaz, nadiren istediğin renk. PNG ve WebP alfayı destekler; görselde saydamlık varsa kısa liste bu ikisidir.
AVIF nereye oturuyor
AVIF, eşit kalitede dosya boyutunda WebP’yi geçer, özellikle düşük bit hızlarında, ve güncel tarayıcıların hepsi onu gösterebiliyor. Sorun kodlamada: JPEG ya da WebP’ye kıyasla çok daha yavaş ve çok daha ağırdır — kodlama bir derleme sunucusunda değil telefonda olduğunda bunun önemi büyür.
ToolZool bugün AVIF’i ne okuyor ne yazıyor. İki yön de bir AV1 kodeki gerektiriyor ve bakımı sürdürülen her seçenek, WebAssembly’ye derlenmeyen bir C kütüphanesi — yani bir AVIF dosyasının önce başka bir yerde dönüştürülmesi gerekiyor. Aynı şey, çoğu iPhone’un varsayılan olarak ürettiği HEIC için de geçerli.
Hepsinin üstünde duran soru
Form neyi kabul ediyor? Geri çevrilen daha iyi bir biçim, daha iyi değildir. Önce kabul edilen listeyi oku, sonra onun içinde iyileştir — ve uygun görünen bir dosya yine de reddediliyorsa, bir yükleme formu dosyanı neden geri çeviriyor yazısı formun gerçekte yaptığı dört denetimi tek tek ele alıyor. Biçimler arasında geçiş yapman gerekiyorsa, görsel sıkıştırıcı JPG, PNG ve WebP okur; JPEG, PNG ya da kayıpsız WebP yazar, yani bu küme içinde dönüştürücü olarak da iş görür.
