วิเคราะห์ข้อดีและข้อเสียของเทคโนโลยี WebP (2021)

 (eng.aurelienpierre.com)
2 คะแนน โดย GN⁺ 2023-12-17 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้การรองรับ WebP ของ WordPress และเบราว์เซอร์หลัก ๆ จะทำให้การย้ายไลบรารีภาพถ่ายทำได้ง่ายขึ้น แต่ในภาพถ่ายจริง ความเสียหายอย่าง posterization และ ringing กลับเห็นเด่นชัดกว่า การลดขนาดไฟล์
  • Google และปลั๊กอิน WordPress หลายตัวแนะนำว่า WebP มีขนาดเล็กกว่า JPEG และ lossy 80 ก็เพียงพอแล้ว แต่หากแปลง JPEG เดิมกลับเป็น WebP อาจเกิด การบีบอัดแบบสูญเสียที่สะสมซ้อนกัน
  • สำหรับภาพที่ ไล่โทนอย่างนุ่มนวล มีความสำคัญ เช่น ภาพพอร์ตเทรตสตูดิโอและฟิล์มสแกน แม้ WebP 95~96 ก็ให้ผลลัพธ์ใกล้เคียงกับ JPEG 85+noise หรือหนักกว่า
  • การเปรียบเทียบค่า SSIM เฉลี่ยและขนาดไฟล์เฉลี่ยไม่สามารถรับประกัน การรับมือกรณีแย่ที่สุด ที่ช่างภาพต้องการได้ และสำหรับเว็บไซต์ที่ปรับจูนคุณภาพแยกตามภาพได้ยาก ความเสถียรสำคัญกว่า
  • หากเป็นไซต์ที่คุณภาพภาพสำคัญ แนวทางที่เป็นจริงกว่าคือคง JPEG 85~90 ไว้, เพิ่ม dithering หรือ noise ละเอียด ๆ, หลีกเลี่ยงการ re-encode JPEG เดิมเป็น WebP และใช้ CDN·ภาพแบบ responsive·lazy loading

ความคาดหวังจากการนำ WebP มาใช้และปัญหาจริง

  • เมื่อ WordPress ยอมรับการอัปโหลด MIME type image/webp และหลังเดือนกันยายน 2020 เบราว์เซอร์หลัก ๆ สามารถแสดง WebP ได้ การย้ายไลบรารีภาพถ่ายไปเป็น WebP จึงทำได้ง่ายขึ้น
  • WebP ดูเป็นตัวเลือกที่น่าสนใจจากการเปรียบเทียบว่ามีขนาดเล็กกว่า JPEG 15% ที่คุณภาพเท่ากัน และตัวเลขของ Google ที่ระบุว่าเล็กกว่า 25~34%
  • ใน WordPress มีปลั๊กอินจำนวนมากที่แปลงไลบรารีสื่อเดิมเป็น WebP และหลายตัวทำงานในรูปแบบ SaaS โดยแปลงบนเซิร์ฟเวอร์ภายนอก
  • ปลั๊กอินและเอกสารทางเทคนิคบางส่วนระบุว่าคุณภาพ WebP ที่สูงกว่า lossy 80 ไม่จำเป็นสำหรับภาพถ่ายส่วนใหญ่ แต่ตัวอย่างโลโก้ไม่สามารถเป็นตัวแทนปัญหาของงานภาพถ่ายจริงได้เพียงพอ

ความเสียหายเมื่อบีบอัด JPEG เดิมเป็น WebP อีกครั้ง

  • หลังจากแปลงสื่อ WordPress ทั้งหมดด้วยคุณภาพ lossy 80 พบว่ามี วงแหวนแบบ posterized ปรากฏบนพื้นหลัง
  • ภาพที่เกิดปัญหาเป็นภาพสแกนฟอร์แมตกลาง 6×7cm ที่ถ่ายด้วยฟิล์ม Ilford Delta 400 บนกล้อง Mamiya RB 67 และต้นฉบับเริ่มจากสแกน 16 บิต
  • เกรนเงินฮาไลด์ของ Delta 400 ทำหน้าที่คล้าย dithering ตามธรรมชาติ ช่วยป้องกัน posterization ในพื้นที่นุ่ม ๆ ได้ดี แต่หลังแปลงเป็น WebP การไล่โทนกลับแตกเป็นขั้น ๆ
  • JPEG ต้นฉบับคุณภาพ 85 ก็ไม่ได้สะอาดสมบูรณ์ แต่ยังดีกว่าไฟล์ WebP ที่แปลงแล้ว และผลกระทบหลักมาจากการซ้อนการบีบอัดแบบสูญเสียของ WebP เพิ่มอีกชั้นบน JPEG ที่ถูกบีบอัดแบบสูญเสียอยู่แล้ว
  • Google Page Speed Insights และปลั๊กอินหลายตัวแนะนำหรือทำให้ flow การ re-encode แบบนี้ทำได้ง่าย แต่ความเสียหายของคุณภาพจริงไม่ใช่สิ่งที่ปลอดภัย

การทดลองเปรียบเทียบกับภาพถ่ายจริง

  • แม้ในเงื่อนไขที่ encode ภาพ RAW โดยตรงจาก darktable และบีบอัดเพียงครั้งเดียว ก็ยังพบจุดอ่อนของ WebP
  • ภาพทดสอบเป็น headshot ในสตูดิโอจริง ซึ่งแสงที่ไล่ลงอย่างนุ่มนวลและ gradient ของพื้นหลังมีความสำคัญ
  • เมื่อบันทึกทั้ง JPEG และ WebP ที่คุณภาพ 90 และใช้ Floyd-Steinberg dithering แบบ 8 บิต ผลคือ:
    • JPEG 85 และ WebP 90 ถูกประเมินว่าล้มเหลวทั้งคู่
    • WebP ดูแย่กว่าเพราะวง posterized มี contrast สูงกว่า
    • WebP 90 ยังมีปัญหาเหลืออยู่ แม้จะเป็นคุณภาพที่สูงกว่าค่าที่แนะนำ lossy 80 ถึง 10 จุด
    • JPEG 90 ดูใช้ได้ แต่ขนาดไฟล์ใหญ่กว่า
  • เมื่อบันทึก WebP แบบ lossless คุณภาพสะอาดขึ้น แต่ขนาดไฟล์ไม่น่าพอใจ ขณะที่ JPEG 90 แยกความแตกต่างได้ยากด้วยขนาดราวหนึ่งในสามของ WebP และ JPEG 95 ก็ดูคล้ายกันในขนาดที่มากกว่าครึ่งเล็กน้อย
  • ในการทดสอบที่เพิ่ม random noise ระดับ -48 dB PSNR แทน Floyd-Steinberg dithering นั้น WebP ก็ยังไวต่อ posterization มากกว่า
    • คุณภาพ WebP ที่นุ่มนวลใกล้เคียงกับ JPEG 85+noise อยู่ระหว่าง 95~96
    • ภายใต้เงื่อนไขนี้ WebP หนักกว่า JPEG 85+noise 39% และหนักกว่า JPEG 90+Floyd-Steinberg dithering 30%
    • ผลลัพธ์ของ WebP ยังมี ringing อ่อน ๆ เหลืออยู่

ช่องว่างระหว่างตัวชี้วัดเฉลี่ยกับคุณภาพภาพถ่าย

  • การประเมินความเหนือกว่าของ WebP พึ่งพาค่า SSIM เฉลี่ยและขนาดบิตเฉลี่ยของชุดข้อมูลภาพอย่างมาก
  • ค่าเฉลี่ยไม่สามารถรับประกัน ความเสถียรของผลลัพธ์ ที่ช่างภาพต้องการในเว็บพอร์ตโฟลิโอได้
    • พอร์ตโฟลิโอภาพถ่ายไม่ใช่พื้นที่ที่ backend บีบอัดจะล้มเหลวแบบสุ่มได้
    • การปรับคุณภาพ WebP อย่างละเอียดเป็นรายภาพใช้เวลามาก และใน WordPress ก็ถือว่าทำแบบนั้นได้ยาก
  • SSIM เป็นตัวชี้วัดความคล้ายของภาพที่อิงค่าเฉลี่ย ความแปรปรวน และความแปรปรวนร่วม จึงสะท้อนเมตริกการรับรู้จริงได้ไม่เพียงพอและยังเป็นที่ถกเถียง
  • สำหรับความเสียหายจากการบีบอัด ไม่เพียงขนาดของความคลาดเคลื่อนเชิงตัวเลขเท่านั้นที่สำคัญ แต่ ลักษณะของ artifact ก็สำคัญด้วย
    • noise แบบสุ่มอาจยอมรับได้ในระดับหนึ่ง
    • คราบที่มี pattern หรือ gradient แบบเป็นขั้น ๆ ทำลายภาพถ่ายรุนแรงกว่า

ฉากที่ WebP อ่อนแอเป็นพิเศษ

  • ในงานภาพถ่าย ฉากที่ยากที่สุดมักไม่ใช่รายละเอียดคมชัด แต่เป็น การไล่โทนอย่างนุ่มนวล
  • ในสถานการณ์ที่แสงใกล้เคียง point light ตกลงบนผนังเพื่อสร้างพื้นหลังที่ดูเป็นธรรมชาติ พื้นหลังต้องมี texture เพียงพอแต่ไม่ดึงสายตาไปจากตัวแบบ
  • ตัวอย่างการบีบอัด WebP มักแสดงฉากที่คมชัด มี depth of field ลึก และมีรายละเอียดความถี่สูงมาก แต่ฉากแบบนี้มีโอกาสเกิด posterization ต่ำ จึงไม่เผยจุดอ่อนของอัลกอริทึมได้ดี
  • ความคมชัดไม่พอไม่ได้ทำลายภาพถ่ายเสมอไป แต่การที่ vignetting นุ่ม ๆ แตกเป็นขั้น ๆ เป็นความเสียหายที่ยอมรับได้ยาก

การออกแบบฟอร์แมตและปัญหาสี

  • WebP เป็นรูปแบบ RGB หรือ RGBalpha จึงไม่สามารถบันทึกภาพขาวดำเป็นภาพ grayscale แบบช่องสัญญาณเดียวได้
  • posterization ที่พบในการทดสอบแย่ลงด้วยวงสี magenta และเขียว และตีความได้ว่าเป็นการเลื่อนของสีจาก chroma subsampling
  • หากสามารถบันทึกรูปแบบขาวดำล้วนเป็นช่องสัญญาณเดียวได้ ก็อาจไม่สร้างการเลื่อนของ chroma เพิ่มเติม
  • AVIF แก้ปัญหาส่วนนี้แล้ว แต่คาดว่าจะต้องใช้เวลาอย่างน้อย 10 ปี กว่าเทคโนโลยีนี้จะเกิดขึ้นจริงอย่างแพร่หลายในทางปฏิบัติ

แนวทางรับมือเพื่อรักษาคุณภาพภาพ

  • หากเป็นเว็บไซต์ที่ภาพมีความสำคัญ โดยเฉพาะพอร์ตโฟลิโอของศิลปินทัศนศิลป์ เห็นว่าควรรักษาคุณภาพ JPEG 90 หรืออย่างน้อย 85 ไว้จะดีกว่า
  • เพื่อปกป้องการไล่โทนที่นุ่มนวล แนะนำให้เพิ่ม dithering หรือ noise ที่อ่อนมาก ๆ ลงในภาพเสมอ
  • ไม่ควรแปลง JPEG เดิมเป็น WebP และควรยกเว้นเฉพาะเมื่อยอมรับความเสียหายในระดับตัวอย่างข้างต้นได้เท่านั้น
  • หากต้องการเพิ่มความเร็วในการโหลดและการตอบสนองที่ผู้ใช้รับรู้ได้ การใช้ CDN, ขนาดภาพแบบ responsive, และ lazy loading ภาพ ปลอดภัยกว่าการแปลงฟอร์แมต
  • รูปแบบ SaaS ที่แปลงบนเซิร์ฟเวอร์ภายนอกมีค่าใช้จ่าย ไม่เปิดเผย factor คุณภาพจริง และอาจเกิดข้อผิดพลาดการเชื่อมต่อ HTTP ในสภาพแวดล้อม WordPress ที่เสริมความแข็งแกร่งด้วยปลั๊กอินความปลอดภัย เป็นต้น
  • วิธีรัน ImageMagick หรือ GraphicsMagick โดยตรงบนเซิร์ฟเวอร์ดีกว่า และแนะนำแนวทางที่ใช้โปรแกรมเซิร์ฟเวอร์โดยตรง ไม่ใช่อินเทอร์เฟซ PHP
  • หากนักพัฒนาเทคโนโลยีและผู้ออกแบบอัลกอริทึมภาพผลักดันการเลือกฟอร์แมตด้วยตัวชี้วัดเฉลี่ยเพียงอย่างเดียว อาจทำให้ศิลปินตัวจริงสูญเสียเวลาและค่าใช้จ่ายได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-17
ความคิดเห็นจาก Hacker News

  • เจอปัญหาเดียวกันใน WebP เลยกลับไปใช้ JPG/PNG เป็นส่วนใหญ่ โดยใช้ jpg สำหรับภาพถ่าย และ png สำหรับภาพแนว UI
    ดูเหมือนปัญหาจริงคือคนจำนวนมากแยกความแตกต่างไม่ออก ซึ่งน่าจะเป็นเพราะจอเดสก์ท็อปแทบไม่มีนวัตกรรมมาราว 10 ปีแล้ว ครึ่งหนึ่งของคนที่นี่คงกำลังดูภาพตัวอย่างบนจอ LCD 1920x1080 ราวปี 2012 และนั่นก็เป็นส่วนหนึ่งของปัญหา
    แปลกตรงที่หน้าจอเล็กอย่างมือถือและจอใหญ่อย่างทีวี 4K มีความหนาแน่นพิกเซลที่ดีมากเมื่อเทียบกับระยะการรับชม แต่ พาเนลขนาด 20~40 นิ้ว กลับติดอยู่ที่ระดับกลางยุค 2000
    อีกอย่าง ถ้าผู้เขียนใช้ภาพตัวอย่างที่พื้นหลังสว่าง หรือเปลี่ยนพื้นหลังบทความเป็นสีดำก็น่าจะดีกว่านี้ ภาพสีดำบนพื้นขาวทำให้ตาปรับตัวยากและมองปัญหาได้ยาก แต่ถ้าวางบนพื้นหลังมืดจะเห็นความต่างได้ง่ายกว่ามาก

    • แม้บนจอจากยุค 2012 สองเครื่องก็ยังเห็น compression artifacts ได้ชัด เครื่องหนึ่งเป็นจอ IPS 30 นิ้ว 2560x1600 ที่ถือว่าดีพอสมควรในยุคนั้น อีกเครื่องเป็นทีวี TN 1080p ขนาด 27 นิ้วระดับเริ่มต้น
      เพราะงั้นคงยากจะบอกว่าคุณภาพจอคือปัญหาหลัก อาจเป็นปัญหาจากไดรเวอร์หรือฟิลเตอร์ post-processing หรืออาจเป็นแค่ไม่ใช่ทุกคนจะมีสายตาแบบที่มองเห็นสิ่งนี้ได้
      ถ้าสนใจงานประมวลผลภาพ จากประสบการณ์แล้วจะเริ่มสังเกตรายละเอียดแบบนี้ได้ ผู้เขียนน่าจะมีประสบการณ์มากกว่าฉันชัดเจน และการมองเห็นรายละเอียดพวกนี้อาจเป็นส่วนหนึ่งของงานด้วย เขาน่าจะดูออกแม้บนจอแย่ ๆ และยังบอกได้ด้วยว่าจอนั้นแย่อย่างไร
    • แม้บนจอ 27 นิ้ว 4K ก็ยังรู้สึกถึงความต่างได้ยากมาก และไม่แน่ใจด้วยซ้ำว่ามองเห็นจริงไหม
      ตัวอย่างไม่ค่อยดีนัก ถ้าจะสาธิตอะไรควร ขยายภาพหน้าจอ เพื่อให้เห็น artifacts
    • ฝั่ง Apple นั้น ทั้งโน้ตบุ๊กและจอเดสก์ท็อปพัฒนามาได้ดีมากเกือบ 10 ปีแล้ว โดยมี PPI สูง ความสว่างดี และความแม่นยำของสีในระดับเหมือนเป็นมาตรฐาน เพียงแต่ราคาแพง และฝั่ง PC คนส่วนใหญ่ก็ไม่ค่อยใส่ใจ จึงมักเป็นหนึ่งในส่วนแรก ๆ ที่ถูกตัดทิ้ง
    • เห็นด้วยเรื่อง JPG แต่ถ้าใช้ lossless WebP แทน PNG ก็เท่ากับพิกเซลเหมือนเดิมและไฟล์เล็กกว่า PNG เดิมราว 30% ไม่ใช่หรือ? แม้เทียบกับ PNG ที่ปรับแต่งมาแรงมากแล้วด้วย zopfli/optipng ก็ยังเล็กกว่าราว 15%
      เวลาคุณแปลง PNG เป็น WebP คำว่า “lossless WebP” นี่ไม่ได้หมายถึงไม่สูญเสียจริง ๆ หรือ?
      อีกอย่าง ถ้าแปลง PNG เป็น lossless WebP แล้วแตกกลับเป็น PNG จากนั้นแปลง PNG นั้นกลับเป็น WebP อีกครั้ง ก็จะได้ไฟล์ lossless WebP ที่เหมือนเดิมทุกประการ ไม่ว่าจะเข้ารหัสแบบ lossless จาก PNG ตรง ๆ หรือจาก PNG เดียวกันที่ถูก “crush” ด้วยเครื่องมือปรับแต่ง PNG ก็จะได้ WebP ตัวเดียวกัน
    • ที่นี่ใช้จอ 27 นิ้ว 4K IPS แต่ถ้าจะเห็นความต่างแบบที่ผู้เขียนพูดถึง ต้องหรี่ตาหรือซูมเข้าไป
      ก็ดีที่มีคนใส่ใจผลลัพธ์ที่ดีที่สุดจริง ๆ แต่คนส่วนใหญ่น่าจะทั้งไม่สังเกตและไม่สนใจ

  • ผมลองเปิดภาพสองภาพแรกในแท็บแยกกันแล้วสลับไปมาอย่างรวดเร็ว แต่ไม่เห็นความต่างเลย ทดสอบบนจอ 2 ตัวที่ต่างกัน ทั้งใน Chrome และ Firefox และภาพผู้ชายชุดสุดท้ายก็ดูเหมือนกันด้วย
    แก้ไข: การเปรียบเทียบอันสุดท้ายใส่ WebP ซ้ำสองครั้ง และลิงก์ผิด นี่คือ jpg แต่ถึงอย่างนั้นก็ยังไม่เห็นความต่าง
    https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...

    • ผมตรวจดูบน Macbook 16 M2 Max พรีเซ็ตมาตรฐาน P3-1600 nits ใน Chrome 120.0.6099.109 แล้วพบว่า WebP ทุกภาพมี posterization ค่อนข้างรุนแรง แต่ตัวอย่าง JPEG ไม่มี
      แก้ไข: ถ้าอยากเห็นความจริง ต้องคลิกดูภาพขนาดเต็มจริง ๆ ภาพที่ฝังอยู่ในบทความ แม้แต่ภาพที่ระบุว่า lossless ก็ยังมี compression artifacts ค่อนข้างหนัก
      ดังนั้น https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... WebP แบบ lossless ขนาดเต็มก็ดูโอเค แต่เวอร์ชันที่ฝังของภาพเดียวกันคือ https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... ดูแย่มาก
      แก้ไข 2: ความต่างของสามอันด้านล่างนี้ค่อนข้างชัดเจน
      https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... lossy-noise.jpg (216 kB JPEG)
      https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (150 kB WebP)
      https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (301 kB WebP)
      ตัวอย่าง WebP ทั้งสองอัน แม้แต่เวอร์ชัน 301 kB ก็ยังเห็น posterization ชัดเจน
      ผมเลยสงสัยว่ามีปัญหากับตัวเข้ารหัส WebP หรือการตั้งค่าที่ใช้หรือเปล่า
      แก้ไข 3: gamma ของจอและ color profile อาจมีผลต่อความชัดเจนของ gradient posterization
    • ความต่างที่เห็นได้ง่ายอย่างหนึ่งคือ ในคู่นี้พื้นหลังใน webp มีอาการ posterized แต่ 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...
    • มีความต่างชัดเจน เห็นได้บนทุกจอทั้งเดสก์ท็อป โน้ตบุ๊ก และมือถือ โดยเฉพาะใน พื้นที่ 1/4 ด้านขวาบน
      แต่ถ้าคุณไม่ได้สนใจเรื่องภาพถ่าย ก็อาจไม่ได้ใส่ใจมากพอจะเห็นมัน
    • พออายุ 50 สายตาผมก็เริ่มแย่ลง แต่ความต่างของภาพถ่ายนี่ชัดแบบเหลือเชื่อ ชัดจนแทบเป็นไปไม่ได้ที่จะมองไม่เห็นว่าต่างกันแค่ไหน
      ความต่างแบบนี้ไม่ใช่เรื่องเล็ก คนที่ไม่เห็นความต่าง หรือเห็นก็ต่อเมื่อเพ่งดู ควรรู้ไว้ว่า สำหรับหลายคนมันเห็นได้ทันที
    • ภาพแรกสำหรับผมดูออกได้ยากมาก ตอนแรกต้องซูมเข้าไปนิดหน่อยถึงจะเห็น บริเวณด้านซ้ายของภาพแถวระดับศีรษะ เวอร์ชัน WebP มี ความเป็นบล็อก มากกว่าเล็กน้อย
      ภาพที่สอง ผมเปิดเวอร์ชัน jpeg 90 [1] และ webp 90 [2] แล้วพอเทียบกันก็เห็นปัญหา banding ชัดเจนทางขวาของลำคอ แถบมืดกว่าที่วนอยู่รอบทั้งภาพก็ดูจางลงเล็กน้อย แต่ถ้ารู้ว่าต้องมองตรงไหนก็ยังเห็นอยู่
      ถ้าเอา jpeg 90 ไปเทียบกับ webp lossless, jpeg 100 หรือ jpeg 95 ก็จะเห็น banding ที่อ่อนมากของ jpeg 90 ทางขวาของลำคอเช่นกัน เพียงแต่ถ้าไม่ซูมก็สังเกตได้ยากมาก
      [1] https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
      [2] https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...

  • สำหรับผม ข้อเสียของ WebP ที่แย่ที่สุดและสังเกตแยกได้ง่ายที่สุดคือการบังคับใช้ 4:2:0 chroma subsampling ในภาพจำนวนมากที่มีสีสว่างสด การสูญเสียสีและความสว่างเห็นได้ชัดแม้ไม่ต้องมีสายตาแบบมืออาชีพ
    ในการเปรียบเทียบ [1] เห็นชัดว่าบอลลูนมุมขวาบนเสียสีแดงสดไป และในการเปรียบเทียบ [2] งานนีออนอาร์ตสีน้ำเงินสว่างตรงกลางสูญเสียความสว่างไป
    [1] https://storage.googleapis.com/demos.webmproject.org/webp/cm...
    [2] https://storage.googleapis.com/demos.webmproject.org/webp/cm...

    • ไม่ได้อยากยั่วยุให้ถกเถียงเพิ่มนะ แต่จากตัวอย่างที่ลิงก์มาทั้งสองอัน ผมไม่รู้สึกถึงความต่างเลยแม้แต่น้อย ถ้าเว็บนั้นอย่างน้อยให้ลากแถบเปรียบเทียบแนวตั้งได้ก็น่าจะช่วยได้ ดูบนหน้าจอ iPhone 14
    • ขอบคุณสำหรับลิงก์นั้น สำหรับตาผมพอมองออก แต่สำหรับการใช้งานบนเว็บก็ดูเล็กน้อยจนมองข้ามได้ ความอิ่มตัวสีล่ะ?
      สงสัยว่าทำไมคำสั่งนี้ถึงทำให้เกิดสีฟ้าจาง ๆ ตอนแปลง jpg > webp ในขณะที่สีอื่น ๆ ยังออกมาโอเคพอใช้
      cwebp -pass 10 -m 6 -nostrong -sharp_yuv -quiet -q 60 -sharpness 2 $1 -o

  • บทความนี้ไม่ได้พูดถึงปัญหาใหญ่ที่สุดที่ผมรู้สึกกับ WebP เลย สำหรับไฟล์ฟอร์แมตนี้ ความไม่สะดวก นอกเบราว์เซอร์มีมากกว่าการประหยัดขนาดเล็กน้อย
    มีฟอร์แมตที่ดีกว่าอยู่ ทั้งฟอร์แมตที่ได้แรงบันดาลใจจากวิดีโอโค้ดेकอย่างที่เห็นใน HEIF, AVIF, H.266 หรืออย่าง JPEG XL และ WebP ก็ดูเหมือนเป็นการประนีประนอมที่ไม่มีข้อดีมากพอ

    • คลิกขวา บันทึกเป็น แล้วก็... อ้าว เป็น WebP อีกแล้ว ความทรมานแบบนั้นน่ะ
    • ที่จริง WebP ก็มีพื้นฐานจากวิดีโอโค้ดेकเหมือนกัน เพียงแต่ดูเหมือน VP8 แทบจะไม่เคยตั้งหลักได้เลยในฝั่งฮาร์ดแวร์ encoder/decoder
    • ความจริงที่แย่ยิ่งกว่าบทความต้นฉบับคือ คุณอาจต้องรับมือกับไฟล์ JPEG ที่ถูกแปลงเป็น WEBP แล้วแปลงกลับมาเป็น JPEG อีกที จากนั้นก็อาจมีใครสักคนแก้ไข JPEG นั้น แล้วมันก็ถูกแปลงกลับเป็น WEBP อีกครั้ง
      หลายคนเถียงกันว่าในภาพ WEBP ที่อยู่ในสภาวะเกือบดีที่สุดนั้นจะเห็น banding หรือไม่ แต่ภาพ WEBP ในโลกความจริงส่วนใหญ่มักดูแย่มาก ผมเพิ่งเริ่มสังเกตเรื่องนี้อย่างจริงจังไม่นานนี้เอง
      แน่นอนว่าตอนนี้เราสามารถ “เก็บกวาด” ภาพได้ด้วยกระบวนการอัปสเกลแบบสร้างภาพใหม่ แต่ก็ค่อนข้างน่าขันที่ต้องใช้ไฟฟ้ามากขนาดนี้เพียงเพราะมีคนอยากประหยัด 45KB
      มันทำให้นึกถึงยุคที่ GIF ถูกแปลงเป็น JPEG ด้วย เมื่อราว 25 ปีก่อนมีสกรีนช็อต GIF สะอาด ๆ จำนวนมากที่ 256 สีก็เพียงพอแล้ว แต่ JPEG ทำมันพัง
      Google บอกให้นักพัฒนาใช้ WEBP แต่กลับไม่มีปัญหาอะไรเลยกับการเสิร์ฟโฆษณาวิดีโอที่ไม่มีใครอยากดูในระดับเพตะไบต์
    • เอาล่ะ ทีนี้มาคุยเรื่อง HEIF กันบ้าง มันก็เป็นฟอร์แมตที่ใช้งานไม่สะดวกทั้งในและนอกเบราว์เซอร์บนเดสก์ท็อป

  • ถ้าประเด็นคือ “สำหรับสายตาคนทั่วไปมันอาจดูโอเค แต่สำหรับช่างภาพมันไม่โอเค” งั้นก็น่าจะต้องมีตัวอย่างที่ดีกว่านี้เพื่อแสดงให้ “คนทั่วไป” เห็นว่า WebP แย่อย่างไร และเพื่อรองรับทั้งเนื้อหาและน้ำเสียงของบทความ
    หรือเพราะผมดูบน Android ก็ไม่รู้ แต่คุณภาพของภาพทั้งหมดดูเหมือนกันหมด
    แล้วถ้าคุณกำลังทำภาพสำหรับ “สายตาแบบมืออาชีพ” ก็แค่ไม่ใช้เทคโนโลยีที่ไม่ตอบโจทย์สายตาแบบมืออาชีพไม่ใช่หรือ? หรือไม่ก็อย่าให้คนอื่นมาตัดสินใจเรื่องนั้นแทน?

    • ประเด็นของผู้เขียนคือ ถ้าคุณเป็นคนสร้างเทคโนโลยีแบบนี้ คุณก็ควรมี สายตาแบบมืออาชีพ
      พอเห็นคอมเมนต์ในเธรดนี้ที่พูดอย่างมั่นใจว่าไม่มีความต่าง ทั้งที่จริง ๆ พูดเพ้อเจ้อ ความหงุดหงิดของผู้เขียนก็ดูสมเหตุสมผลนะ มองไม่ออกจากภาพชุดแรกก็ไม่เป็นไร แต่คุณก็ไม่ควรมั่นใจว่าตัวเองรู้ดีกว่าผู้เขียน หรือไปออกแบบ image codec
    • ผมก็ดูบน Android
      มองออกได้แม้ไม่ต้องดูเต็มจอ แค่ดูผู้ชายที่ทำหน้าบึ้ง แล้วมองที่ขอบเสื้อบริเวณใกล้ไหล่
      ในภาพคุณภาพแย่ จะมี แสงฟุ้ง รอบไหล่ คล้ายแสงย้อน
      ในภาพคุณภาพดี การไล่เฉดจะเนียนกว่า รอบไหล่ไม่มีแสงฟุ้งคล้ายแสงย้อน แต่ดูเหมือนฉากหลังไล่เฉดนุ่ม ๆ ตามปกติ
      ขอย้ำว่าผมไม่ใช่ช่างภาพ ผมเป็นวิศวกร DevOps และครั้งสุดท้ายที่ใช้ JavaScript ในงานอาชีพก็อย่างน้อย 11 ปีที่แล้ว
      มันเห็นได้ง่ายพอสมควร
    • ดูการอภิปรายตรงนี้ได้ [1] ถ้าจะให้แยกออก ต้องดูที่ ขนาดเต็ม
      [1] https://news.ycombinator.com/item?id=38653224
    • ใครก็ตามที่เคยทำงานกับ codec จะรู้ว่าไม่มีใครเปรียบเทียบ codec กันด้วย ภาพเดียว
      แนวคิดพื้นฐานทั้งหมดของบล็อกโพสต์นี้ดูเหมือนไม่ได้พยายามผ่านการตรวจสอบพื้นฐานในฐานะการเปรียบเทียบฟอร์แมต แต่เหมือนแค่อยากบ่นและเรียกคลิกมากกว่า

  • ข้อมูลพื้นหลังนิดหน่อย Aurelien Pierre เป็นที่รู้จักว่าเป็นผู้มีส่วนร่วมหลักของ Darktable โดย Darktable เป็นเครื่องมือโอเพนซอร์สสำหรับล้างไฟล์ RAW/จัดทำแค็ตตาล็อก ซึ่งก็คือประมาณ Adobe Lightroom แบบโอเพนซอร์ส
    เขาเป็นที่รู้กันว่ามีความเห็นหนักแน่นเรื่องวิธีที่ถูกต้อง และบางครั้งก็ถึงขั้นค่อนข้างแข็งกร้าว จนถึงกับ fork Darktable ออกไปเป็นโปรเจกต์ของตัวเองชื่อ Ansel ด้วย เคยมีการพูดคุยใน HN มาก่อน https://news.ycombinator.com/item?id=38390914

    • น่าจะต้องลองดู Ansel แล้ว มีใครรู้ไหมว่ายังเข้ากันได้กับฟอร์แมตของ Darktable อยู่หรือเปล่า?

  • หากใส่ใจคุณภาพของภาพเก็บถาวร ก็ไม่ควรนำภาพเก่ามาบีบอัดใหม่เป็นฟอร์แมตใหม่ เว้นแต่จะทำได้จากต้นฉบับแบบไม่บีบอัด การ re-encode จากซอร์สที่บีบอัดแบบสูญเสียข้อมูลจะทำให้คุณภาพแย่ลง พื้นที่เก็บข้อมูลก็ราคาถูกและจะยิ่งถูกลงเรื่อยๆ
    สิ่งที่มีความหมายจริงๆ คือการเลือก การตั้งค่าที่ปลอดภัย เมื่อต้องบีบอัดภาพใหม่ด้วยฟอร์แมตใหม่

    • มีการระบุว่า JPEG XL สามารถ re-encode ไฟล์ JPEG เดิมให้มีขนาดเล็กลง 20% โดยไม่สูญเสียคุณภาพ
      ในบริบทนี้ Google ได้ขัดขวาง JPEG XL โดยอ้างว่าเมื่อเทียบกับฟอร์แมตเดิมอย่าง WebP แล้ว “ประโยชน์เชิงเพิ่มพูน” ยังไม่มากพอ พร้อมทั้งถอดการรองรับ JPEG XL ออกจาก Chrome และปฏิเสธที่จะนำกลับมา
    • ก็จริง แต่ไม่ใช่ประเด็นสำคัญ ต่อให้เริ่มจากภาพที่บันทึกไล่เฉดสีได้สมบูรณ์แบบใน PNG, WebP ก็ยังเกิดอาการ banding ที่มองเห็นได้ที่ -q100 ขณะที่ JPEG ดูโปร่งใสทางสายตาแม้ที่ -q90

  • ดูเหมือนผู้เขียนจะโฟกัสผิดจุด ไปสนใจความต่างของฟอร์แมต ทั้งที่จริงควรโฟกัสที่ วิธีการบีบอัด มากกว่า โปรแกรมประมวลผลภาพแต่ละตัวให้ผลการบีบอัดต่างกัน แม้จะตั้งค่าเลขเดียวกัน เช่น “80”
    ถ้าจะเทียบกันอย่างมีความหมายจริง ต้องทดสอบภาพหลายแบบ ไม่ใช่แค่ภาพพอร์ตเทรตสตูดิโอขาวดำที่มีฉากหลังไล่เฉดนุ่มๆ แต่รวมถึงภาพสีเต็มรูปแบบที่มีฉากหลังซับซ้อนด้วย และควรดูหลายโปรแกรม เช่น imagemagik, graphicsMagick, sharp, photoshop รวมถึงบริการคลาวด์ต่างๆ
    อีกประเด็นคือกรณีการใช้งาน ถ้าเป็นช่างภาพมืออาชีพที่ต้องการอัปโหลดภาพขนาดเต็มคุณภาพสูงสุด อาจดีกว่าถ้าไม่บีบอัดเลย เพื่อให้ผลงานสร้างสรรค์/การแต่งภาพถูกเก็บไว้ครบถ้วน แต่กรณีนั้นไม่ใช่กรณีใช้งานทั่วไปของเว็บไซต์ที่ต้องแสดงภาพขนาดพอเหมาะและคุณภาพพอเหมาะ
    ในหลายสถานการณ์ ภาพที่เล็กกว่ามากอาจคุ้มค่ากับการยอมรับการบีบอัดที่แรงขึ้น และในภาพจำนวนมาก การบีบอัดจะสังเกตเห็นได้น้อยกว่าภาพถ่ายสตูดิโอระดับมืออาชีพความละเอียดเต็มที่มีฉากหลังไล่เฉดขนาดใหญ่

  • ส่วนตัวผมมองไม่เห็นความต่างที่มีนัยสำคัญ เลยคิดว่าตัวเองคงเป็น “สายตาแบบคนทั่วไป” แน่ๆ

    • มันต่างกันมากตามอุปกรณ์ บนเครื่อง Windows ที่บริษัทจะเห็น banding นิดหน่อย บนมือถือแย่กว่า และบน MacBook แย่มาก
    • เป็นไปได้ว่าคุณคงมองแต่ส่วน foreground เหมือนคนส่วนใหญ่ แม้บนอุปกรณ์ Android 12 จอเล็ก ถ้าไม่ได้ดูแบบเต็มจอ ก็ยังเห็นสีบริเวณฉากหลังรอบขอบเสื้อและขอบรูปเปลี่ยนไปอย่างชัดเจนในแต่ละภาพ
      สิ่งที่ผู้เขียนบ่นคือ artifact ที่เกิดขึ้นในฉากหลังของภาพ
    • สายตาก็ไม่ดีและไม่ได้ผ่านการฝึก แต่พอมีคนชี้ตำหนิให้แล้วกลับไปดูใหม่ ก็เห็นค่อนข้างชัด
    • นั่นแหละปัญหา พอสังเกตเห็น ปัญหา banding ครั้งหนึ่งแล้ว ก็เหมือนโดนคำสาปให้เห็นมันไปทุกที่
    • น่าสนใจตรงที่ผมเห็นความต่างชัดเจนได้ตั้งแต่ก่อนอ่านเสียอีก อุปกรณ์ที่ใช้คือ MacBook Air 11 นิ้วอายุ 9 ปี ไม่ได้แย่แต่ก็ไม่ใช่อุปกรณ์ระดับไฮเอนด์
      น่าทึ่งที่การรับรู้ของแต่ละคนต่างกันได้มากขนาดนี้

  • ไล่เฉดสีใน WebP มักดูคล้าย ภาพนิ่งจากวิดีโอ การทำ chroma subsampling ลดความหนาแน่นของค่าประมาณความสว่างที่ใช้ได้ และยิ่งใช้แรงเท่าไร ไล่เฉดสีก็ยิ่งแย่ลง
    รายละเอียดความถี่สูงและความต่างคอนทราสต์มากจะไม่ได้รับผลกระทบมากนัก แต่ไล่เฉดสีอาจเสียหายหนักได้

    • ข้อความที่ว่า “chroma subsampling ลดความหนาแน่นของค่าประมาณความสว่าง” นั้นเกือบจะตรงข้ามกับความจริง
      chroma หมายถึงสี และการ subsampling สีเป็นวิธีที่ใช้เพื่อหลีกเลี่ยงการตัดข้อมูลออกจากช่องสัญญาณความสว่างที่สำคัญกว่า
    • ใน WebM/VP9 ก็ไม่ใช่เรื่องแปลกที่จะเห็น banding ค่อนข้างรุนแรงในไล่เฉดสีโทนมืด ดังนั้นคำอธิบายนี้ก็พอฟังขึ้นในระดับหนึ่ง
    • WebP ใช้ YCbCr แบบ limited range เหมือนวิดีโอ ส่วน JPEG ใช้ YCbCr แบบ full range ดังนั้นบนจอภาพที่ใช้ค่า RGB เต็มช่วง ภาพ JPEG โทนเทาจึงอาจดูสมบูรณ์แบบ ขณะที่ WebP อาจเกิด banding เล็กน้อยเมื่อแสดงเนื้อหาแบบโทนเทา