Analisis Kelebihan dan Kekurangan Teknologi WebP (2021)

 (eng.aurelienpierre.com)
2 poin oleh GN⁺ 2023-12-17 | 1 komentar | Bagikan ke WhatsApp
  • Dukungan WebP di WordPress dan browser utama membuat migrasi pustaka foto menjadi lebih mudah, tetapi pada foto nyata, kerusakan seperti posterization dan ringing tampak lebih menonjol daripada pengurangan ukuran file
  • Google dan berbagai plugin WordPress menyatakan bahwa WebP lebih kecil daripada JPEG dan lossy 80 sudah cukup, tetapi mengubah JPEG yang sudah ada kembali menjadi WebP dapat menyebabkan kompresi lossy bertumpuk
  • Pada gambar yang mengutamakan gradasi halus, seperti potret studio dan scan film, WebP 95–96 pun menunjukkan hasil yang mirip atau lebih berat dibanding JPEG 85+noise
  • Perbandingan rata-rata SSIM dan rata-rata ukuran file tidak dapat menjamin penanganan kasus terburuk yang dibutuhkan fotografer, dan pada situs web yang sulit melakukan tuning kualitas per gambar, stabilitas lebih penting
  • Untuk situs yang mengutamakan kualitas gambar, pendekatan yang lebih realistis adalah mempertahankan JPEG 85–90, menambahkan dithering atau noise halus, menghindari re-encoding JPEG lama ke WebP, serta memanfaatkan CDN, gambar responsif, dan lazy loading

Ekspektasi Adopsi WebP dan Masalah Nyatanya

  • Setelah WordPress menerima unggahan dengan tipe MIME image/webp, dan browser utama sejak September 2020 dapat menampilkan WebP, memindahkan pustaka foto ke WebP menjadi lebih mudah
  • WebP terlihat sebagai pilihan menarik karena perbandingan yang menyebutkan ukurannya 15% lebih kecil daripada JPEG pada kualitas yang sama, serta angka dari Google yang menyebut 25–34% lebih kecil
  • Di WordPress ada banyak plugin yang mengonversi pustaka media lama ke WebP, dan banyak di antaranya berjalan dengan model SaaS yang melakukan konversi di server eksternal
  • Sebagian plugin dan dokumen teknis menyatakan bahwa kualitas WebP di atas lossy 80 tidak diperlukan untuk sebagian besar foto, tetapi contoh logo tidak cukup mewakili masalah dalam pekerjaan fotografi nyata

Kerusakan Saat JPEG Lama Dikompresi Ulang ke WebP

  • Setelah media WordPress dikonversi massal dengan kualitas lossy 80, muncul cincin posterized pada latar belakang
  • Gambar yang bermasalah adalah scan format medium 6×7 cm dari film Ilford Delta 400 yang dipotret dengan Mamiya RB 67, dan sumbernya berasal dari scan 16-bit
  • Butiran perak halida pada Delta 400 bekerja seperti dithering alami, sehingga menguntungkan untuk mencegah posterization di area halus, tetapi setelah konversi WebP gradasinya pecah seperti tangga
  • JPEG asli kualitas 85 juga tidak sepenuhnya bersih, tetapi lebih baik daripada versi hasil konversi WebP, dan pengaruh besarnya berasal dari penumpukan satu lagi kompresi lossy WebP di atas JPEG yang sudah mengalami kompresi lossy
  • Google Page Speed Insights dan berbagai plugin menganjurkan atau memudahkan alur re-encoding seperti ini, tetapi kerusakan kualitas nyata membuatnya tidak aman

Eksperimen Perbandingan pada Foto Nyata

  • Kelemahan WebP juga terlihat dalam kondisi ketika foto RAW dienkode langsung dari darktable sehingga hanya dikompresi sekali
  • Gambar uji adalah headshot studio nyata, dengan pencahayaan yang jatuh halus dan gradasi latar belakang yang penting
  • Setelah JPEG dan WebP sama-sama disimpan pada kualitas 90 dan diterapkan Floyd-Steinberg dithering 8-bit, hasilnya:
    • JPEG 85 dan WebP 90 sama-sama dinilai gagal
    • WebP terlihat lebih buruk karena kontras cincin posterization lebih tinggi
    • WebP 90 masih bermasalah meski kualitasnya 10 poin lebih tinggi daripada nilai yang direkomendasikan lossy 80
    • JPEG 90 terlihat cukup baik, tetapi ukuran filenya lebih besar
  • Jika WebP disimpan secara lossless, kualitasnya menjadi bersih tetapi ukuran filenya tidak memuaskan; JPEG 90 sulit dibedakan pada ukuran sekitar sepertiganya, dan JPEG 95 tampak serupa pada ukuran sedikit di atas separuhnya
  • Pada pengujian dengan menambahkan noise acak -48 dB PSNR alih-alih Floyd-Steinberg dithering, WebP tetap lebih rentan terhadap posterization
    • Kualitas WebP yang menjadi sehalus JPEG 85+noise berada di antara 95–96
    • Dalam kondisi ini, WebP 39% lebih berat daripada JPEG 85+noise, dan juga 30% lebih berat daripada JPEG 90+Floyd-Steinberg dithering
    • Hasil WebP masih menyisakan ringing lemah

Kesenjangan antara Metrik Rata-rata dan Kualitas Foto

  • Penilaian keunggulan WebP sangat bergantung pada rata-rata SSIM dan rata-rata ukuran bit dari dataset gambar
  • Nilai rata-rata tidak dapat menjamin stabilitas output yang dituntut fotografer dari portofolio web
    • Portofolio fotografi bukanlah area yang boleh dibiarkan gagal secara acak oleh backend kompresi
    • Menyesuaikan kualitas WebP secara rinci untuk setiap gambar memakan banyak waktu, dan di WordPress cara seperti itu juga dianggap sulit
  • SSIM adalah metrik kesamaan gambar berbasis rata-rata, varians, dan kovarians, sehingga tidak cukup mencerminkan metrik persepsi nyata dan masih diperdebatkan
  • Dalam kerusakan kompresi, yang penting bukan hanya besar deviasi numeriknya, tetapi juga sifat artefaknya
    • Noise acak masih dapat ditoleransi sampai tingkat tertentu
    • Noda berpola atau gradasi bertangga merusak foto jauh lebih parah

Adegan yang Sangat Lemah bagi WebP

  • Dalam pekerjaan fotografi, adegan paling sulit sering kali bukan detail tajam, melainkan gradasi halus
  • Dalam situasi ketika cahaya yang mendekati sumber titik jatuh ke dinding untuk membentuk latar alami, latar belakang harus memiliki tekstur yang cukup tanpa mengalihkan perhatian dari subjek
  • Contoh kompresi WebP sering menampilkan adegan yang tajam, memiliki depth of field dalam, dan banyak detail frekuensi tinggi, tetapi adegan seperti ini memiliki kemungkinan posterization yang rendah sehingga tidak memperlihatkan kelemahan algoritme dengan baik
  • Kurangnya ketajaman tidak selalu merusak foto, tetapi fenomena vignetting halus yang pecah seperti tangga adalah kerusakan yang sulit diterima

Desain Format dan Masalah Warna

  • WebP menggunakan format RGB atau RGBalpha, sehingga gambar hitam-putih tidak dapat disimpan sebagai gambar abu-abu kanal tunggal
  • Posterization yang terlihat dalam pengujian menjadi lebih buruk sebagai cincin magenta dan hijau, dan ditafsirkan sebagai pergeseran warna akibat chroma subsampling
  • Jika format hitam-putih murni dapat disimpan sebagai kanal tunggal, pergeseran chroma tambahan tidak perlu terjadi
  • AVIF telah menyelesaikan bagian ini, tetapi diperkirakan butuh setidaknya 10 tahun sampai teknologinya terealisasi secara luas dalam praktik

Cara Menjaga Kualitas Gambar

  • Untuk situs web yang mengutamakan gambar, terutama portofolio seniman visual, dinilai lebih baik mempertahankan kualitas JPEG 90 atau setidaknya 85
  • Untuk melindungi gradasi halus, disarankan selalu menambahkan dithering atau noise yang sangat lemah pada gambar
  • Sebaiknya jangan mengonversi JPEG lama ke WebP, kecuali jika kerusakan setingkat contoh sebelumnya dapat diterima
  • Untuk meningkatkan kecepatan loading dan responsivitas yang dirasakan, lebih aman memanfaatkan CDN, ukuran gambar responsif, dan lazy loading gambar daripada konversi format
  • Model SaaS yang melakukan konversi di server eksternal memerlukan biaya, tidak mengungkap faktor kualitas sebenarnya, dan dapat menimbulkan error koneksi HTTP di lingkungan WordPress yang diperkuat dengan plugin keamanan
  • Menjalankan ImageMagick atau GraphicsMagick langsung di server lebih baik, dan pendekatan yang disarankan adalah menggunakan program server secara langsung, bukan antarmuka PHP
  • Jika developer teknologi dan perancang algoritme gambar memaksakan pilihan format hanya berdasarkan metrik rata-rata, hal itu dapat menimbulkan kerugian waktu dan biaya bagi seniman nyata

Bacaan terkait

1 komentar

 
GN⁺ 2023-12-17
Komentar Hacker News

  • Saya melihat masalah yang sama di WebP, jadi sebagian besar kembali ke JPG/PNG; untuk foto memakai jpg, dan untuk gambar jenis UI memakai png.
    Masalah sebenarnya tampaknya ada pada banyak orang yang tidak bisa merasakan perbedaannya, dan saya rasa itu karena selama 10 tahun terakhir monitor desktop tetap berada di titik buta tanpa inovasi. Separuh orang di sini mungkin melihat gambar contoh dengan LCD 1920x1080 yang keluar sekitar 2012, dan itu juga bagian dari masalahnya.
    Anehnya, layar kecil seperti ponsel dan layar besar seperti TV 4K sudah memiliki kerapatan piksel yang sangat baik relatif terhadap jarak menonton, tetapi panel 20–40 inci masih terjebak di level pertengahan 2000-an.
    Selain itu, rasanya akan lebih baik jika penulis memakai foto contoh dengan latar terang atau mengubah latar tulisan menjadi hitam. Gambar hitam di atas latar putih membuat mata sulit beradaptasi sehingga masalahnya sulit terlihat; jika diletakkan di latar gelap, perbedaannya jauh lebih mudah terlihat.

    • Bahkan pada dua display era 2012, artefak kompresi terlihat jelas. Yang satu monitor IPS 30 inci 2560x1600 yang cukup bagus untuk standar saat itu, dan yang lain TV TN 27 inci 1080p kelas pemula.
      Jadi sulit mengatakan bahwa kualitas display adalah masalah utamanya. Bisa saja masalah driver atau filter pascapemrosesan, atau mungkin memang tidak semua orang punya mata untuk melihat hal semacam ini.
      Kalau tertarik pada pemrosesan gambar, dari pengalaman detail seperti ini akan terlihat. Penulisnya jelas lebih berpengalaman daripada saya, dan melihat detail semacam ini mungkin bagian dari pekerjaannya. Besar kemungkinan ia bisa mengenali masalah bahkan di monitor yang buruk, sekaligus menjelaskan dengan cara apa monitor itu buruk.
    • Bahkan di monitor 27 inci 4K, sangat sulit merasakan perbedaannya, dan saya bahkan tidak yakin apakah benar-benar terlihat.
      Contohnya kurang bagus. Jika ingin menunjukkan sesuatu, harus memperbesar screenshot untuk memperlihatkan artefaknya.
    • Di sisi Apple, monitor laptop dan desktop sudah berkembang dengan baik, dengan PPI tinggi, kecerahan, dan akurasi warna yang hampir menjadi standar sejak sekitar 10 tahun lalu. Hanya saja harganya mahal, dan di PC kebanyakan orang tidak memedulikannya, jadi itu menjadi salah satu bagian pertama yang dipangkas.
    • Untuk JPG saya setuju, tetapi jika memakai WebP lossless alih-alih PNG, bukankah pikselnya tetap sama dan hanya ukuran filenya yang menjadi sekitar 30% lebih kecil daripada PNG tersebut? Bahkan dibandingkan PNG yang sudah dioptimalkan kuat dengan zopfli/optipng dan sejenisnya, ukurannya masih sekitar 15% lebih kecil.
      Saat mengubah PNG ke WebP, apakah “lossless” pada “lossless WebP” sebenarnya bukan benar-benar lossless?
      Sebagai catatan, setelah mengonversi PNG ke WebP lossless lalu mengekstraknya kembali ke PNG, kemudian mengonversi PNG itu lagi ke WebP, hasilnya adalah file WebP lossless yang benar-benar sama. Baik dienkode secara lossless langsung dari PNG, maupun dari PNG yang sama yang sudah di-“crush” dengan pengoptimal PNG, WebP yang dihasilkan sama.
    • Di sini saya memakai layar IPS 27 inci 4K, dan untuk melihat perbedaan yang disebut penulis, saya harus menyipitkan mata atau memperbesar.
      Bagus kalau ada orang yang benar-benar peduli pada hasil terbaik, tetapi saya rasa sebagian besar orang tidak akan menyadarinya maupun memedulikannya.

  • Saya membuka dua foto pertama masing-masing di tab terpisah lalu beralih cepat, tetapi sama sekali tidak ada perbedaan. Saya mencobanya di dua monitor berbeda, di Chrome dan Firefox, dan foto pria terakhir juga sama
    Edit: perbandingan terakhir ternyata memasukkan WebP dua kali dan tautannya salah. jpg ada di sini, tetapi tetap tidak terlihat perbedaannya
    https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...

    • Saya cek di Macbook 16 M2 Max dengan preset standar P3-1600 nits, Chrome 120.0.6099.109, dan semua gambar WebP memiliki posterization yang cukup parah, sementara contoh JPEG tidak demikian
      Edit: untuk melihat kebenarannya, Anda harus benar-benar mengeklik dan melihat gambar ukuran penuh. Gambar yang disisipkan di artikel memiliki artefak kompresi yang cukup parah, bahkan yang disebut lossless sekalipun
      Jadi https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... WebP lossless ukuran penuh terlihat baik-baik saja, tetapi versi sisipan dari gambar yang sama, yaitu https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... terlihat buruk sekali
      Edit 2: perbedaan di antara tiga di bawah ini cukup jelas
      https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... lossy-noise.jpg (JPEG 216 kB)
      https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (WebP 150 kB)
      https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (WebP 301 kB)
      Kedua contoh WebP tersebut, bahkan versi 301 kB, jelas memperlihatkan posterization
      Saya bertanya-tanya apakah ada masalah dengan encoder WebP atau pengaturan yang digunakan
      Edit 3: gamma monitor dan profil warna dapat memengaruhi seberapa terlihat posterization pada gradasi
    • Salah satu perbedaan yang mudah dilihat adalah pada pasangan ini: latar belakang mengalami posterization di webp, tetapi tidak di jpg: https://en.wikipedia.org/wiki/Posterization
      https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
      https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
    • Ada perbedaan yang jelas. Terlihat di semua monitor saya, dari desktop, laptop, hingga mobile, dan terutama mudah terlihat di seperempat kanan atas
      Namun jika Anda tidak tertarik pada fotografi, mungkin Anda tidak cukup peduli untuk melihatnya
    • Setelah berusia 50 tahun, penglihatan saya mulai memburuk, tetapi perbedaan fotonya sangat jelas sampai terasa tidak masuk akal. Hampir mustahil untuk tidak melihat seberapa besar perbedaannya
      Perbedaan seperti ini tidak kecil. Orang-orang yang tidak bisa melihat perbedaannya, atau baru bisa melihatnya kalau memperhatikan dengan saksama, perlu tahu bahwa bagi banyak orang perbedaan itu langsung terlihat
    • Foto pertama secara pribadi sangat sulit saya temukan perbedaannya, dan awalnya saya harus sedikit memperbesar agar terlihat. Di sisi kiri gambar, sekitar setinggi kepala, versi WebP memiliki sedikit lebih banyak kesan blok
      Untuk gambar kedua, saya membuka versi jpeg 90 [1] dan webp 90 [2], dan jika dibandingkan, ada masalah banding yang jelas di sisi kanan leher. Pita yang lebih gelap yang mengelilingi seluruh gambar juga sedikit kurang terlihat, tetapi masih terlihat jika tahu harus melihat ke mana
      Jika membandingkan jpeg 90 dengan salah satu dari webp lossless, jpeg 100, atau jpeg 95, banding yang sangat samar pada jpeg 90 di sisi kanan leher juga terlihat. Namun tanpa diperbesar, sangat sulit dikenali
      [1] https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
      [2] https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...

  • Menurut saya, kelemahan WebP yang paling buruk dan paling mudah dikenali adalah chroma subsampling 4:2:0 yang dipaksakan. Pada banyak gambar dengan warna terang, hilangnya warna dan kecerahan terlihat jelas bahkan tanpa mata profesional
    Pada perbandingan [1], balon di kanan atas jelas kehilangan warna merah yang hidup, dan pada perbandingan [2], karya seni neon biru terang di tengah kehilangan kecerahannya
    [1] https://storage.googleapis.com/demos.webmproject.org/webp/cm...
    [2] https://storage.googleapis.com/demos.webmproject.org/webp/cm...

    • Bukan bermaksud memicu perdebatan lagi, tetapi pada kedua contoh yang ditautkan itu saya sama sekali tidak merasakan perbedaannya. Akan membantu kalau situs itu setidaknya memungkinkan kita menyeret bilah perbandingan vertikal. Saya melihatnya di layar iPhone 14
    • Terima kasih untuk tautannya, dan di mata saya memang terdeteksi, tetapi untuk penggunaan situs web tampaknya bisa diabaikan. Bagaimana dengan saturasi?
      Saya penasaran mengapa perintah ini menghasilkan warna biru muda yang pucat saat konversi jpg > webp, sementara warna lain keluar cukup lumayan
      cwebp -pass 10 -m 6 -nostrong -sharp_yuv -quiet -q 60 -sharpness 2 $1 -o

  • Tulisan ini tidak membahas masalah yang paling saya rasakan dari WebP. Ketidaknyamanan yang diberikan format ini di luar browser lebih besar daripada penghematan ukuran yang kecil
    Ada format-format yang lebih baik. Ada format yang terinspirasi dari codec video seperti HEIF, AVIF, yang bisa muncul dari H.266, atau JPEG XL, dan WebP terasa seperti kompromi tanpa keunggulan yang memadai

    • Klik kanan, simpan sebagai, lalu... aduh WebP lagi, itulah penderitaannya
    • WebP sebenarnya juga berbasis codec video. Hanya saja VP8 tampaknya hampir tidak mendapat tempat di sisi encoder/decoder hardware
    • Kenyataan yang lebih buruk daripada artikel aslinya adalah kita bisa saja berurusan dengan gambar JPEG yang dikonversi ke WEBP lalu dikembalikan lagi ke JPEG. Setelah itu mungkin ada orang yang mengedit JPEG tersebut, lalu dikonversi lagi ke WEBP
      Banyak orang berdebat apakah banding terlihat atau tidak pada gambar WEBP yang kondisinya mendekati ideal, tetapi gambar WEBP di dunia nyata pada umumnya terlihat mengerikan. Saya baru belakangan ini mulai benar-benar menyadarinya
      Tentu saja sekarang kita bisa “membersihkan” gambar lewat proses upscaling generatif, tetapi cukup ironis bahwa listrik sebanyak itu dipakai karena seseorang ingin menghemat 45KB
      Ini juga mengingatkan pada masa ketika GIF dikonversi menjadi JPEG. Sekitar 25 tahun lalu ada banyak screenshot GIF yang bersih dan 256 warna sudah cukup, tetapi JPEG merusaknya
      Google menyuruh developer memakai WEBP, tetapi tidak punya masalah menyajikan iklan video yang tidak ingin dilihat siapa pun dalam skala petabyte
    • Sekarang mari kita bicarakan HEIF juga. Di desktop, ini format yang merepotkan baik di dalam maupun di luar browser

  • Kalau argumennya “mungkin terlihat baik-baik saja di mata non-ahli, tetapi tidak bagi fotografer”, rasanya perlu ada contoh yang lebih baik untuk menunjukkan kepada “non-ahli” mengapa WebP buruk dan untuk membenarkan tulisan serta nadanya
    Mungkin karena saya melihatnya di Android, semua foto tampak memiliki kualitas yang sama
    Dan kalau membuat foto untuk “mata ahli”, bukankah tinggal tidak memakai teknologi yang tidak cocok untuk mata ahli? Atau jangan serahkan keputusan seperti itu kepada orang lain?

    • Poin penulis adalah bahwa orang yang membuat teknologi seperti ini seharusnya memiliki mata ahli
      Melihat komentar-komentar di thread ini yang dengan percaya diri mengatakan penulis omong kosong dan tidak ada perbedaan, rasa frustrasi itu tampak wajar. Tidak apa-apa kalau tidak melihat perbedaan pada gambar-gambar pertama, tetapi jangan lalu dengan percaya diri mengatakan lebih tahu daripada penulis atau merancang codec gambar
    • Saya juga melihatnya di Android
      Bahkan tanpa melihatnya secara layar penuh, saya bisa melihatnya. Lihat pria yang mengernyit itu, lalu lihat tepi kemeja di dekat bahunya
      Pada foto dengan kualitas gambar buruk, muncul pendar cahaya di sekitar bahu, seolah-olah ada cahaya latar
      Pada foto berkualitas baik, gradasinya halus. Tidak ada pendar cahaya seperti backlight di sekitar bahu, hanya tampak seperti latar gradasi yang lembut
      Agar jelas, saya bukan fotografer, melainkan engineer DevOps. Terakhir kali saya memakai JavaScript secara profesional pun setidaknya 11 tahun lalu
      Cukup mudah terlihat
    • Lihat diskusi di sini [1]. Untuk membedakannya, harus dilihat dalam ukuran penuh
      [1] https://news.ycombinator.com/item?id=38653224
    • Siapa pun yang pernah menangani codec tahu bahwa perbandingan codec tidak dilakukan dengan satu gambar
      Seluruh gagasan dasar tulisan blog ini tampaknya bukan untuk lolos verifikasi dasar sebagai perbandingan antarformat, melainkan untuk menghasilkan lebih banyak keluhan dan klik

  • Sebagai sedikit latar belakang, Aurelien Pierre dikenal sebagai kontributor utama Darktable. Darktable adalah alat pengembangan/katalog RAW open source, semacam Adobe Lightroom versi open source
    Ia dikenal punya pandangan kuat tentang cara yang benar, kadang sampai terkesan keras, sehingga ia juga mem-fork Darktable menjadi proyeknya sendiri bernama Ansel. Dulu pernah ada diskusi HN juga https://news.ycombinator.com/item?id=38390914

    • Saya harus mencoba Ansel. Ada yang tahu apakah masih kompatibel dengan format Darktable?

  • Jika Anda peduli pada kualitas gambar arsip, Anda tidak akan mengompresi ulang gambar lama ke format baru, kecuali bisa dilakukan dari sumber asli yang tidak terkompresi. Jika di-encode ulang dari sumber yang sudah dikompresi secara lossy, kualitasnya akan menurun. Storage murah dan terus makin murah
    Yang bermakna adalah memilih pengaturan yang aman saat mengompresi foto baru ke format baru

    • JPEG XL disebut bisa meng-encode ulang file JPEG yang ada menjadi file 20% lebih kecil tanpa kehilangan kualitas
      Dalam konteks ini, Google telah menghambat JPEG XL dengan menghapus dukungan JPEG XL dari Chrome dan menolak memulihkannya, sambil berargumen bahwa dibanding format yang sudah ada seperti WebP, “manfaat inkremental”-nya tidak cukup
    • Benar, tapi itu bukan poin utamanya. Bahkan jika memulai dari gradien sempurna yang disimpan sebagai PNG, WebP pada -q100 menghasilkan banding yang terlihat, sedangkan JPEG pada -q90 pun tampak transparan secara visual

  • Sepertinya penulis berfokus pada hal yang salah. Ia berfokus pada perbedaan format, padahal seharusnya berfokus pada metode kompresi. Di tiap program pemrosesan gambar, meski disetel ke angka yang sama, misalnya “80”, hasil kompresinya berbeda
    Untuk perbandingan yang benar-benar bermakna, perlu menguji beragam gambar, bukan hanya foto potret studio hitam-putih dengan latar gradien halus, tetapi juga gambar full-color dengan latar kompleks. Perlu juga melihat berbagai program seperti imagemagik, graphicsMagick, sharp, photoshop, dan berbagai layanan cloud
    Masalah lain adalah use case. Jika seorang fotografer profesional ingin mengunggah foto ukuran penuh dengan kualitas tertinggi, mungkin lebih baik tidak mengompresinya sama sekali agar hasil kreasi/editing tetap tersimpan sepenuhnya. Namun use case itu bukan use case rata-rata situs web yang menampilkan gambar dengan ukuran dan kualitas yang wajar
    Dalam banyak situasi, gambar yang jauh lebih kecil layak menerima kompresi yang lebih kuat, dan pada banyak gambar kompresinya tidak akan seterlihat pada foto studio profesional resolusi penuh dengan latar gradien besar

  • Secara pribadi saya tidak melihat perbedaan yang berarti, jadi mata saya jelas “mata non-ahli”

    • Ini sangat bergantung pada perangkat. Di mesin Windows kantor, banding sedikit terlihat; di ponsel lebih buruk; di MacBook mengerikan
    • Besar kemungkinan, seperti kebanyakan orang, Anda hanya melihat foreground. Bahkan di perangkat Android 12 kecil, jika dilihat tanpa layar penuh, warna latar di sekitar tepi kemeja dan di tepi foto berubah cukup mencolok antar-gambar
      Yang dikeluhkan penulis adalah artefak pada latar gambar
    • Penglihatan saya juga buruk dan tidak terlatih, tetapi setelah diberi tahu letak cacatnya lalu melihat lagi, cukup jelas
    • Itu bagus. Begitu menyadari masalah banding, Anda akan terkena kutukan melihatnya di mana-mana
    • Menariknya, saya sudah bisa melihat perbedaannya dengan jelas bahkan sebelum membaca. Perangkat yang saya pakai adalah MacBook Air 11 inci berusia 9 tahun, jadi tidak buruk, tetapi juga bukan perangkat kelas atas
      Menarik bagaimana persepsi bisa sebegitu berbeda antar-orang

  • Gradien WebP sering terlihat seperti still frame video. Chroma subsampling mengurangi kepadatan nilai pendekatan luminance yang bisa digunakan, dan makin kuat diterapkan, makin buruk gradiennya
    Kontras tinggi dan detail frekuensi tinggi tidak banyak terdampak, tetapi gradien bisa rusak parah

    • Pernyataan “chroma subsampling mengurangi kepadatan nilai pendekatan luminance” hampir kebalikannya
      Chroma berarti warna, dan subsampling warna digunakan agar tidak mengambil informasi dari kanal luminance yang lebih penting
    • Di WebM/VP9 pun tidak jarang terlihat banding yang cukup parah pada gradien gelap, jadi penjelasan ini sampai batas tertentu masuk akal
    • WebP memakai YCbCr rentang terbatas seperti video, sedangkan JPEG memakai YCbCr rentang penuh. Karena itu, pada monitor yang memakai nilai RGB penuh, JPEG grayscale terlihat sempurna, sementara WebP bisa menimbulkan sedikit banding saat menampilkan konten grayscale