WebP teknolojisinin artı ve eksi yönlerinin analizi (2021)

 (eng.aurelienpierre.com)
2 puan yazan GN⁺ 2023-12-17 | 1 yorum | WhatsApp'ta paylaş
  • WordPress ve başlıca tarayıcıların WebP desteği sayesinde fotoğraf kütüphanelerini taşımak kolaylaştı, ancak gerçek fotoğraflarda dosya boyutu tasarrufundan çok posterizasyon ve ringing gibi bozulmalar daha belirgin ortaya çıkıyor
  • Google ve çeşitli WordPress eklentileri WebP'nin JPEG'den daha küçük olduğunu ve lossy 80 değerinin yeterli olduğunu söylese de, mevcut JPEG'leri yeniden WebP'ye dönüştürmek kayıplı sıkıştırmanın birikmesine yol açabilir
  • Stüdyo portreleri ve film taramaları gibi yumuşak gradyanların önemli olduğu görüntülerde WebP 95~96 bile JPEG 85+gürültüye benzer ya da ondan daha ağır sonuçlar veriyor
  • Ortalama SSIM ve ortalama dosya boyutu karşılaştırmaları, fotoğrafçıların ihtiyaç duyduğu en kötü senaryo dayanıklılığını garanti etmez; görüntü başına kalite ayarının zor olduğu web sitelerinde kararlılık daha önemlidir
  • Görüntü kalitesinin önemli olduğu sitelerde JPEG 85~90'ı korumak, dithering veya çok ince gürültü eklemek, mevcut JPEG'leri WebP olarak yeniden kodlamaktan kaçınmak ve CDN, duyarlı görseller, lazy loading kullanmak daha gerçekçidir

WebP'den beklenenler ve pratikteki sorunlar

  • WordPress'in image/webp MIME türü yüklemelerini kabul etmesi ve Eylül 2020'den sonra başlıca tarayıcıların WebP gösterebilir hale gelmesiyle, fotoğraf kütüphanelerini WebP'ye taşımak kolaylaştı
  • WebP, aynı kalitede JPEG'den %15 daha küçük olduğu yönündeki karşılaştırmalar ve Google'ın %25~34 daha küçük olduğu verileri nedeniyle cazip bir seçenek gibi görünüyor
  • WordPress'te mevcut medya kütüphanesini WebP'ye dönüştüren çok sayıda eklenti var ve bunların önemli bir kısmı dönüşümü harici sunucularda yapan SaaS modeli ile çalışıyor
  • Bazı eklentiler ve teknik dokümanlar, WebP kalite değeri lossy 80 üzerinin çoğu fotoğraf için gereksiz olduğunu söylese de, logo örnekleri gerçek fotoğraf iş akışındaki sorunları yeterince temsil etmiyor

Mevcut JPEG'leri yeniden WebP olarak sıkıştırırken oluşan bozulma

  • WordPress medyasını lossy 80 kalitesinde toplu dönüştürdükten sonra arka planda posterize halkalar oluştu
  • Sorun görülen görüntü, Mamiya RB 67 ile çekilmiş Ilford Delta 400 filminden 6×7 cm orta format bir taramaydı ve kaynak 16 bit bir taramadan geliyordu
  • Delta 400'ün gümüş tanecikleri doğal bir dithering gibi davranarak yumuşak bölgelerde posterizasyonu engellemeye yardımcı oluyor, ancak WebP dönüşümünden sonra gradyanlar basamaklı şekilde kırılıyor
  • Orijinal JPEG kalite 85 de tamamen temiz değildi, ancak WebP sürümünden daha iyiydi; bunda zaten kayıplı sıkıştırılmış JPEG üzerine bir kez daha WebP kayıplı sıkıştırma uygulanmasının etkisi büyük
  • Google Page Speed Insights ve çeşitli eklentiler bu tür yeniden kodlama akışını öneriyor ya da kolaylaştırıyor, ancak pratikteki kalite kaybı güvenli değil

Gerçek fotoğraflarda karşılaştırma deneyi

  • RAW fotoğrafı darktable içinde doğrudan kodlayıp yalnızca bir kez sıkıştırma yapılan koşulda bile WebP'nin zayıf yönleri görüldü
  • Test görüntüsü, yumuşak düşen ışığın ve arka plan gradyanının önemli olduğu gerçek bir stüdyo headshot'ıydı
  • Hem JPEG hem WebP kalite 90 olarak kaydedilip 8 bit Floyd-Steinberg dithering uygulandığında:
    • JPEG 85 ve WebP 90 başarısız olarak değerlendirildi
    • WebP'de posterize halkaların kontrastı daha yüksekti ve daha kötü görünüyordu
    • WebP 90, önerilen lossy 80 değerinden 10 puan yüksek olmasına rağmen sorun sürüyordu
    • JPEG 90 kabul edilebilir görünüyordu, ancak dosya boyutu daha büyüktü
  • WebP kayıpsız olarak kaydedildiğinde kalite temizleşti, ancak dosya boyutu tatmin edici değildi; JPEG 90 bunun yaklaşık üçte biri boyutta ayırt etmesi zor bir sonuç verdi ve JPEG 95 biraz yarısından büyük boyutta benzer görünüyordu
  • Floyd-Steinberg dithering yerine -48 dB PSNR düzeyinde rastgele gürültü eklenen testte de WebP hâlâ posterizasyona daha yatkındı
    • JPEG 85+gürültü kadar yumuşayan WebP kalite değeri 95~96 arasındaydı
    • Bu koşulda WebP, JPEG 85+gürültüden %39 daha ağırdı ve JPEG 90+Floyd-Steinberg dithering'den de %30 daha ağırdı
    • WebP sonucunda hâlâ hafif ringing kalıyordu

Ortalama metriklerle fotoğraf kalitesi arasındaki fark

  • WebP'nin üstünlüğüne dair değerlendirmeler büyük ölçüde görüntü veri kümelerindeki ortalama SSIM ve ortalama bit boyutuna dayanıyor
  • Ortalama değerler, fotoğrafçıların web portföylerinde ihtiyaç duyduğu çıktı kararlılığını garanti etmiyor
    • Fotoğraf portföyü, sıkıştırma arka ucunun rastgele başarısız olmasının kabul edilebileceği bir alan değil
    • Her görüntü için WebP kalitesini ince ayarlamak zaman alıcı ve WordPress'te böyle bir yaklaşımın uygulanması da zor görülüyor
  • SSIM, ortalama, varyans ve kovaryansa dayalı bir görüntü benzerliği metriği olduğundan gerçek algısal metrikleri yeterince yansıtmayabilir ve tartışmalıdır
  • Sıkıştırma bozulmalarında önemli olan yalnızca sayısal sapmanın büyüklüğü değil, artefaktın niteliğidir
    • Rastgele gürültü belli ölçüde tolere edilebilir
    • Desenli lekeler veya basamaklı gradyanlar fotoğrafı çok daha ağır biçimde bozar

WebP'nin özellikle zayıf kaldığı sahneler

  • Fotoğraf işlerinde en zorlu sahneler, keskin ayrıntılardan çok yumuşak gradyanlar içerenlerdir
  • Noktasal ışık kaynağına yakın bir ışığın duvara düşerek doğal bir arka plan oluşturduğu durumlarda, arka planın yeterli dokuya sahip olması ama konudan dikkati çalmaması gerekir
  • WebP sıkıştırma örnekleri sık sık keskin, alan derinliği yüksek ve yüksek frekanslı detayların bol olduğu sahneleri gösterir; ancak bu tür sahnelerde posterizasyon olasılığı düşüktür ve algoritmanın zayıflıkları iyi ortaya çıkmaz
  • Yetersiz keskinlik bir fotoğrafı her zaman mahvetmez, ancak yumuşak vinyetin basamak basamak kırılması kabul edilmesi zor bir bozulmadır

Format tasarımı ve renk sorunları

  • WebP, RGB veya RGBalpha biçiminde olduğundan siyah-beyaz görüntüleri tek kanallı gri tonlamalı görüntü olarak saklayamaz
  • Testte görülen posterizasyon, macenta ve yeşil halkalarla daha da kötüleşti; bu da kroma alt örnekleme kaynaklı renk kayması olarak yorumlandı
  • Saf siyah-beyaz format tek kanal olarak saklanabilseydi, ek kroma kaymaları üretilmeyebilirdi
  • AVIF bu noktayı çözmüş durumda, ancak bunun teknik olarak geniş ölçekte pratik hale gelmesinin en az 10 yıl süreceği düşünülüyor

Görüntü kalitesini korumak için alınabilecek önlemler

  • Görüntünün önemli olduğu web siteleri, özellikle de görsel sanatçı portföyleri için JPEG kalite 90 veya en az 85'i korumanın daha iyi olduğu düşünülüyor
  • Yumuşak gradyanları korumak için görüntülere her zaman dithering ya da çok hafif gürültü eklenmesi öneriliyor
  • Mevcut JPEG'leri WebP'ye dönüştürmemek daha iyi; ancak önceki örneklerdeki düzeydeki bozulma kabul edilebiliyorsa istisna yapılabilir
  • Yükleme hızı ve algılanan tepki süresini artırmak için format dönüştürmektense CDN, duyarlı görsel boyutları, görsel lazy loading kullanmak daha güvenlidir
  • Harici sunucuda dönüşüm yapan SaaS modeli maliyetlidir, gerçek kalite katsayısını açıklamaz ve güvenlik eklentileriyle güçlendirilmiş WordPress ortamlarında HTTP bağlantı hatalarına yol açabilir
  • Sunucuda doğrudan ImageMagick veya GraphicsMagick çalıştırmak daha iyidir; PHP arayüzü yerine sunucu programlarını doğrudan kullanmak önerilir
  • Teknoloji geliştiricileri ve görüntü algoritması tasarımcıları ortalama metriklere bakarak format seçimini dayatırsa, gerçek sanatçılar için zaman ve maliyet kaybına yol açabilir

İlgili okumalar

1 yorum

 
GN⁺ 2023-12-17
Hacker News yorumları

  • WebP’de de aynı sorunu gördüğüm için çoğunlukla JPG/PNG’ye geri döndüm; fotoğraflar için jpg, UI türü görseller için png kullanıyorum.
    Asıl sorun, birçok kişinin farkı hissedememesi gibi görünüyor; bunun da son 10 yılda masaüstü monitörlerin yenilikten uzak bir kör noktada kalmasından kaynaklandığını düşünüyorum. Buradakilerin yarısı örnek görselleri muhtemelen 2012 civarında çıkmış 1920x1080 LCD’lerde görüyor; bu da sorunun bir parçası.
    Tuhaf şekilde telefonlar gibi küçük ekranlar ve 4K TV’ler gibi büyük ekranlar, izleme mesafesine göre harika piksel yoğunluğuna ulaştı; ama 20~40 inç paneller 2000’lerin ortası seviyesinde takılı kaldı.
    Ayrıca yazarın açık arka planlı örnek fotoğraflar kullanması ya da yazının arka planını siyaha çevirmesi daha iyi olurdu bence. Beyaz arka plan üzerindeki siyah görsellerde gözün uyum sağlaması zor olduğu için sorunu görmek güçleşiyor; koyu bir arka plana konduğunda fark çok daha kolay görülüyor.

    • 2012 dönemi iki ekranda bile sıkıştırma artefaktları gayet iyi görünüyor. Biri o dönem ölçütlerine göre oldukça iyi sayılan 30 inç 2560x1600 IPS monitör, diğeri ise giriş seviyesi 27 inç TN 1080p TV.
      Bu yüzden ekran kalitesinin temel sorun olduğunu söylemek zor. Sürücü veya son işleme filtresi sorunu da olabilir; ya da herkesin bu tür şeyleri görecek göze sahip olmaması da mümkün.
      Görüntü işlemeye ilginiz varsa deneyimle bu tür ayrıntıları görmeye başlıyorsunuz. Yazarın benden kesinlikle daha fazla deneyimi var ve bu ayrıntıları görmek işinin bir parçası bile olabilir. Berbat bir monitörde bile sorunu fark edip o monitörün hangi yönden berbat olduğunu da söyleyebilmesi muhtemel.
    • 27 inç 4K monitörde bile farkı hissetmek çok zor; gerçekten görüp görmediğimden bile emin değilim.
      Örnekler pek iyi değil. Bir şeyi göstermek istiyorsanız ekran görüntüsünü büyütüp artefaktları göstermelisiniz.
    • Apple tarafında dizüstüler ve masaüstü monitörler, neredeyse 10 yıldır yüksek PPI, parlaklık ve renk doğruluğunu standart gibi sunarak iyi gelişti. Ancak pahalılar ve PC tarafında çoğu kişi bunu önemsemediği için ilk kesilen kalemlerden biri oluyor.
    • JPG konusunda katılıyorum, ama PNG yerine kayıpsız WebP kullanınca pikseller aynı kalıp dosya ilgili PNG’den yaklaşık %30 daha küçük olmuyor mu? zopfli/optipng gibi araçlarla zaten sıkı optimize edilmiş PNG’lerle karşılaştırıldığında bile yaklaşık %15 daha küçük.
      PNG’yi WebP’ye çevirirken “lossless WebP”deki lossless aslında gerçekten kayıpsız değil mi?
      Bu arada, PNG’yi kayıpsız WebP’ye dönüştürüp sonra tekrar PNG’ye açtıktan sonra, o PNG’yi yeniden WebP’ye çevirince tamamen aynı kayıpsız WebP dosyası elde ediliyor. PNG’den doğrudan kayıpsız kodlasanız da, PNG optimize ediciyle “crush” edilmiş aynı PNG’den kodlasanız da aynı WebP çıkıyor.
    • Burada 27 inç 4K IPS ekran kullanıyorum; yazarın bahsettiği farkı görmek için gözlerimi kısmam ya da yakınlaştırmam gerekiyor.
      En iyi sonucu gerçekten önemseyen insanların olması güzel, ama çoğu kişi bunu ne fark eder ne de umursar gibi geliyor.

  • İlk iki fotoğrafı ayrı sekmelerde açıp hızlıca geçiş yaptım; hiçbir fark yok. İki farklı monitörde, Chrome ve Firefox’ta denedim; sondaki erkek fotoğrafları da aynıydı.
    Düzeltme: Son karşılaştırmada WebP iki kez konmuştu ve bağlantı yanlıştı. JPG burada, ama yine de fark göremiyorum.
    https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...

  • Bence WebP’nin en kötü ve ayırt etmesi en kolay dezavantajı zorunlu 4:2:0 kroma alt örnekleme. Parlak renklere sahip birçok görüntüde renk ve parlaklık kaybı, uzman gözü olmadan bile açıkça görülüyor
    Karşılaştırma [1]’de sağ üstteki balonun canlı kırmızısını kaybettiği belirgin; karşılaştırma [2]’de ise ortadaki parlak mavi neon sanatının parlaklığını kaybettiği görülüyor
    [1] https://storage.googleapis.com/demos.webmproject.org/webp/cm...
    [2] https://storage.googleapis.com/demos.webmproject.org/webp/cm...

    • Yine tartışmayı alevlendirmeye çalışmıyorum ama bağlantısını verdiğin iki örnekte de hiçbir fark hissedemedim. O sitenin en azından dikey karşılaştırma çubuğunu sürüklemeye izin vermesi yardımcı olurdu. iPhone 14 ekranında baktım
    • Bağlantı için teşekkürler; benim gözüm algılayabiliyor ama web sitesi kullanımı için ihmal edilebilir görünüyor. Peki ya doygunluk?
      Şu komutun jpg > webp dönüşümünde neden soluk bir mavi ürettiğini, diğer renklerin ise fena görünmediğini merak ediyorum
      cwebp -pass 10 -m 6 -nostrong -sharp_yuv -quiet -q 60 -sharpness 2 $1 -o

  • Bu yazı, WebP’de benim en büyük sorun olarak gördüğüm şeye değinmemiş. Tarayıcı dışında bu biçimin yarattığı rahatsızlık, küçük dosya boyutu tasarrufundan daha ağır basıyor
    Daha iyi biçimler var. HEIF, AVIF, H.266’dan çıkabilecek türden video kodeklerinden esinlenen biçimler ya da JPEG XL var; WebP ise yeterli avantajı olmayan bir uzlaşma gibi görünüyor

    • Sağ tık, farklı kaydet ve... ah yine WebP acısı var
    • WebP de aslında video kodeği tabanlı. Sadece VP8’in donanım encoder/decoder tarafında pek yer edinememiş gibi görünüyor
    • Orijinal yazıdan daha kötü gerçek şu: JPEG görüntülerin WEBP’ye dönüştürülüp sonra yeniden JPEG’e çevrilmiş hâlleriyle uğraşmak zorunda kalabilirsiniz. Üstelik ardından biri o JPEG’i düzenlemiş ve tekrar WEBP’ye dönüştürmüş olabilir
      Birçok kişi, ideale yakın koşullardaki WEBP görüntülerde banding görülüp görülmediğini tartışıyor ama gerçek dünyadaki WEBP görüntüler genelde berbat görünüyor. Bunu ancak son zamanlarda ciddi biçimde fark etmeye başladım
      Elbette artık üretken upscaling süreciyle görüntüyü “temizlemek” mümkün; birinin 45KB tasarruf etmek istemesi yüzünden bu kadar elektrik harcanması epey ironik
      Bu bana GIF’lerin JPEG’e dönüştürüldüğü zamanları da hatırlatıyor. Yaklaşık 25 yıl önce 256 rengin yeterli olduğu çok sayıda temiz GIF ekran görüntüsü vardı; JPEG bunları mahvetti
      Google geliştiricilere WEBP kullanmalarını söylüyor ama kimsenin görmek istemediği video reklamları petabaytlarca sunmakta hiçbir sorun görmüyor
    • Şimdi bir de HEIF’ten bahsedelim. Masaüstünde, hem tarayıcı içinde hem de dışında rahatsızlık veren bir biçim

  • “Uzman olmayan göze iyi görünebilir ama bir fotoğrafçı için öyle değil” deniyorsa, WebP’nin neden kötü olduğunu “uzman olmayanlara” gösterecek ve yazıyla üslubu haklı çıkaracak daha iyi bir örnek olmalı gibi geliyor
    Android’de baktığımdan mı bilmiyorum, tüm fotoğrafların kalitesi aynı görünüyor
    Ayrıca “uzman gözü” için fotoğraf üretiyorsan, uzman gözüne uygun olmayan bir teknolojiyi kullanmazsın, değil mi? Ya da böyle kararları başkalarına bırakmazsın?

    • Yazarın asıl noktası, bu tür teknolojileri yapan kişilerin uzman gözüne sahip olması gerektiği
      Bu başlıkta yazarın saçmaladığını ve fark olmadığını kendinden emin biçimde söyleyen yorumlara bakınca, bu hayal kırıklığı haklı görünüyor. İlk görüntülerde farkı görememek sorun değil; ama o zaman yazardan daha iyi bildiğini iddia etmemeli ya da görüntü kodeği tasarlamamalısın
    • Ben de Android’de baktım
      Tam ekran bakmadan da görebildim. Yüzünü buruşturan adama bakıp omzuna yakın gömlek kenarına bakmak yeterli
      Görüntü kalitesi kötü olan fotoğrafta, omuz çevresinde sanki arkadan ışık varmış gibi ışık taşması oluşuyor
      Kaliteli fotoğrafta gradyan pürüzsüz. Omuz çevresinde arkadan ışık gibi bir taşma yok; sadece yumuşak gradyan bir arka plan gibi görünüyor
      Açık söyleyeyim, fotoğrafçı değilim; DevOps mühendisiyim. JavaScript’i profesyonel olarak en son kullanmamın üzerinden de en az 11 yıl geçti
      Yeterince kolay görülüyor
    • Buradaki tartışmaya bakabilirsiniz [1]. Ayırt edebilmek için tam boyutta bakmak gerekiyor
      [1] https://news.ycombinator.com/item?id=38653224
    • Kodeklerle uğraşmış herkes, kodek karşılaştırmasının tek bir görüntüyle yapılmayacağını bilir
      Bu blog yazısının temel fikrinin tamamı, biçimler arası karşılaştırma olarak temel doğrulamayı geçmeye çalışmaktan çok, şikâyet ve tık üretmeye yönelik gibi görünüyor

  • Biraz arka plan vermek gerekirse, Aurelien Pierre Darktable’ın başlıca katkıcılarından biri olarak biliniyor. Darktable açık kaynaklı bir RAW işleme/kataloglama aracı; yani açık kaynaklı Adobe Lightroom gibi
    Doğru yöntem konusunda güçlü görüşleri olduğu biliniyor ve bazen sert denebilecek kadar; hatta Darktable’ı Ansel adlı kendi projesine fork’ladı. Daha önce HN’de de bir tartışma vardı https://news.ycombinator.com/item?id=38390914

    • Ansel’e bakmam gerekecek. Hâlâ Darktable biçimiyle uyumlu olup olmadığını bilen var mı?

  • Arşiv görüntü kalitesini önemsiyorsanız, sıkıştırılmamış orijinalden yapabildiğiniz durumlar dışında eski görüntüleri yeni bir formata yeniden sıkıştırmazsınız. Kayıplı sıkıştırılmış bir kaynaktan yeniden kodlama yapmak kaliteyi düşürür. Depolama ucuz ve ucuzlamaya devam ediyor
    Anlamlı olan, yeni fotoğrafları yeni bir formata sıkıştırırken güvenli ayarlar seçmektir

    • JPEG XL'in mevcut JPEG dosyalarını kalite kaybı olmadan %20 daha küçük dosyalara yeniden kodlayabildiği söyleniyor
      Bu bağlamda Google, Chrome'da JPEG XL desteğini kaldırıp geri getirmeyi de reddederek, WebP gibi mevcut formatlarla karşılaştırıldığında yeterli “kademeli fayda” sağlamadığını öne sürüp JPEG XL'in önünü tıkadı
    • Doğru, ama asıl mesele bu değil. Mükemmel bir gradyanı PNG olarak kaydedilmiş hâlinden başlasanız bile, WebP -q100 ayarında gözle görülür bantlanma üretirken JPEG -q90 ayarında bile görsel olarak şeffaftır

  • Yazar yanlış yere odaklanmış gibi görünüyor. Format farklarına yoğunlaşmış, ama aslında sıkıştırma yöntemine odaklanmalıydı. Farklı görüntü işleme programlarında aynı sayı, örneğin “80”, ayarlansa bile sıkıştırma sonuçları farklı olur
    Gerçekten anlamlı bir karşılaştırma için yalnızca yumuşak gradyan arka planlı siyah-beyaz stüdyo portreleri değil, karmaşık arka planlı tam renkli görüntüler gibi çeşitli görüntüler de test edilmeli. imagemagik, graphicsMagick, sharp, photoshop ve çeşitli bulut servisleri gibi farklı programlar da birlikte ele alınmalı
    Bir diğer mesele de kullanım senaryosu. Profesyonel bir fotoğrafçı tam boyutta, en yüksek kalitede fotoğraf yüklemek istiyorsa, üretim/düzenleme sonucunun tamamen korunması için hiç sıkıştırmamak daha iyi olabilir. Ama bu kullanım senaryosu, bir web sitesinin makul boyutta ve makul kalitede görüntüler göstermesine ilişkin ortalama kullanım senaryosu değil
    Birçok durumda çok daha küçük görüntüler daha güçlü sıkıştırmayı göze almaya değer; birçok görüntüde de sıkıştırma, büyük gradyan arka plana sahip tam çözünürlüklü profesyonel stüdyo fotoğraflarındaki kadar fark edilmeyecektir

  • Kişisel olarak anlamlı bir fark göremediğim için, benim gözlerim kesinlikle “uzman olmayan gözler” gibi görünüyor

    • Cihaza göre büyük ölçüde değişiyor. Şirketteki Windows makinede bantlanma biraz görünüyor, telefonda daha kötü, MacBook'ta ise korkunç
    • Büyük olasılıkla çoğu kişi gibi yalnızca ön plana bakıyordunuz. Küçük bir Android 12 cihazda bile tam ekran olmadan bakınca, gömleğin kenarları çevresindeki arka planın ve fotoğraf kenarlarındaki renklerin görüntüden görüntüye belirgin biçimde değiştiği görülüyor
      Yazarın şikâyet ettiği şey, görüntü arka planında oluşan artefaktlar
    • Görme keskinliğim de kötü, eğitimim de yok; ama kusur söylendikten sonra tekrar bakınca oldukça belirgin
    • İyi olmuş. Bir kez bantlanma sorununu fark edince her yerde görme lanetine yakalanıyorsunuz
    • İlginç şekilde, okumadan önce de farkı açıkça görebiliyordum. Kullandığım cihaz 9 yıllık 11 inç MacBook Air; kötü değil ama üst seviye ekipman da değil
      Algının insandan insana bu kadar değişmesi ilginç

  • WebP'deki gradyanlar çoğu zaman video kareleri gibi görünür. Chroma subsampling, kullanılabilir parlaklık yaklaşım değerlerinin yoğunluğunu azaltır; ne kadar güçlü uygulanırsa gradyan o kadar kötüleşir
    Kontrastı yüksek ve yüksek frekanslı detaylar bundan fazla etkilenmez, ancak gradyanlar ciddi şekilde bozulabilir

    • “Chroma subsampling'in parlaklık yaklaşım değerlerinin yoğunluğunu azalttığı” ifadesi neredeyse tersidir
      Chroma renk anlamına gelir; renk alt örnekleme, daha önemli olan parlaklık kanalından bilgi eksiltmemek için kullanılan bir yöntemdir
    • WebM/VP9'da da koyu gradyanlarda epey ciddi bantlanma görmek nadir değil; bu yüzden bu açıklama bir ölçüde mantıklı
    • WebP, video gibi sınırlı aralıklı YCbCr kullanır; JPEG ise tam aralıklı YCbCr kullanır. Bu nedenle tüm RGB değerlerini kullanan monitörlerde gri tonlamalı JPEG kusursuz görünürken, WebP gri tonlamalı içerik gösterirken hafif bantlanma oluşturabilir