Codec karşılaştırmalarını dikkatle değerlendirmek

 (cloudinary.com)
10 puan yazan lifthrasiir 2022-12-15 | 2 yorum | WhatsApp'ta paylaş

Chrome'un JPEG XL deneyini durduracağı haberi (https://tr.news.hada.io/topic?id=7709) çıkınca, konu takipçisi "neden siliyorsunuz" sorularıyla dolup taşmıştı. Bunun üzerine AVIF tarafı, kendilerinin karşılaştırdığı benchmark verilerini yayımlayarak itirazını savunmuştu (https://storage.googleapis.com/avif-comparison/index.html). Bu yazı ise söz konusu verilerin analizi ve JPEG XL tarafının buna verdiği yanıttır.

Yalnızca JPEG XL'i savunma/karşı çıkma meselesinin ötesinde, görüntü formatı karşılaştırmalarında önemli noktaları ele aldığı için okumaya değer. Ana noktaları birkaç maddeyle özetlersek:

  • AVIF tarafının decode hızı, Chrome ve libjxl'in eski sürümlerine dayanıyordu; bu yüzden abartılı görünüyor. Güncel sürümler baz alındığında JPEG XL (varsayılan ayarlar) ~= 12 bit AVIF < JPEG XL (hızlı decode ayarı) ~= 8 bit AVIF < JPEG'den yeniden sıkıştırılmış JPEG XL sıralaması ortaya çıkıyor ve her bir eşitsizlik yalnızca yaklaşık %10 fark anlamına geliyor.

  • Toplam decode hızından daha önemlisi, kullanılabilir görüntünün hangi anda ortaya çıktığıdır; JPEG XL progressive decode'u desteklediği için burada büyük bir avantaj sağlar. (Bu, web'de Largest Contentful Paint gibi konuların tartışılmasıyla aynı bağlamdır.)

  • Encoding performansı ile encode edilmiş görüntünün kalitesi ayrı ayrı karşılaştırılıyor; ancak libjxl, encoding performansı ile encoding kalitesini tamamen bağımsız biçimde ayarlayabilirken AVIF dahil diğer encoder'ların çoğunda bu mümkün değildir. Bu yüzden bu şekilde bir karşılaştırma yapılamaz.

  • Encoding sırasında hedeflenen kalite aralığı fazla geniş tutulmuş ve olasılık dağılımı hesaba katılmamış. "On the fly" diye adlandırılan en düşük kalite, kimsenin hiçbir amaçla kullanamayacağı kadar düşüktür. Ayrıca AVIF ortalamada düşük kaliteli görüntülerde güçlü görünse de dosya boyutu biraz arttığında JPEG XL'in açık ara öne geçtiği birçok durum vardır; buna rağmen uygun olmayan bir ortalama alma yöntemi kullanılarak JPEG XL'in güçlü yanları seyreltilmiş.

  • Testte kullanılan veri kümesi uygun değil. Kayıpsız sıkıştırmada dergi görüntülerinin tarandığı Kodak kümesi kullanılmış, kayıplı sıkıştırmada ise normalde vektör grafik ya da kayıpsız sıkıştırma kullanılan Noto Emoji kümesi yer alıyor; her ikisi de genel olarak kayıpsız ve kayıplı sıkıştırmanın tipik kullanım örnekleri değil.

  • Görüntü sıkıştırma performansı bugünü ilgilendiriyorsa, görüntü formatının desteklediği özellikler geleceği ilgilendirir. Bir kez tarayıcıya giren bir görüntü formatı artık kaldırılamıyorsa, değerlendirmede özelliklere o kadar daha fazla ağırlık vermek gerekir.

İlgili okumalar

2 yorum

 
lifthrasiir 2022-12-15

İşe gitmeden önce alelacele yazdığım için ufak tefek hatalar var(...), on the fly tam olarak en düşük kalite değil, en yüksek hız anlamına geliyor (ancak JPEG XL hariç çoğu encoder'da kaliteyle ters bir ilişki gösterir). Ayrıca Kodak veri kümesi için ben ne düşünüyordum da dergi diye yazmışım bilmiyorum ama aslında filmden taranmıştır.