พิจารณาการเปรียบเทียบโค้ดेकอย่างรอบคอบ

 (cloudinary.com)
10 คะแนน โดย lifthrasiir 2022-12-15 | 2 ความคิดเห็น | แชร์ทาง WhatsApp

มีข่าวว่า Chrome ยุติการทดลอง JPEG XL (https://th.news.hada.io/topic?id=7709) และใน issue tracker ก็เต็มไปด้วยคำถามว่าเหตุใดจึงลบมันออก จากนั้นฝั่ง AVIF เคยนำข้อมูล benchmark ที่พวกเขาเปรียบเทียบเองมาเผยแพร่เพื่อโต้แย้งจุดนี้ (https://storage.googleapis.com/avif-comparison/index.html) บทความนี้เป็นการวิเคราะห์ข้อมูลดังกล่าวและเป็นคำโต้แย้งจากฝั่ง JPEG XL

นอกเหนือจากการสนับสนุน/คัดค้าน JPEG XL แบบตรงไปตรงมาแล้ว บทความนี้ยังชี้ประเด็นสำคัญเกี่ยวกับการเปรียบเทียบฟอร์แมตภาพ จึงเป็นสิ่งที่น่าอ่าน หากสรุปเฉพาะประเด็นสำคัญมีดังนี้:

  • ความเร็วในการถอดรหัสของฝั่ง AVIF อ้างอิงจาก Chrome และ libjxl เวอร์ชันเก่า จึงทำให้ผลดูเกินจริง เมื่ออิงจากเวอร์ชันล่าสุด JPEG XL (การตั้งค่าพื้นฐาน) ~= AVIF 12 บิต < JPEG XL (ตั้งค่าถอดรหัสเร็ว) ~= AVIF 8 บิต < JPEG XL ที่บีบอัดซ้ำจาก JPEG และเครื่องหมายอสมการแต่ละตัวต่างกันเพียงราว 10% เท่านั้น

  • สิ่งที่สำคัญกว่าความเร็วถอดรหัสทั้งหมดคือภาพที่ใช้งานได้เริ่มแสดงออกมาตอนไหน และ JPEG XL รองรับการถอดรหัสแบบ progressive จึงมีข้อได้เปรียบอย่างมากในจุดนี้ (เป็นบริบทเดียวกับการพูดถึง Largest Contentful Paint บนเว็บ)

  • มีการเปรียบเทียบประสิทธิภาพการเข้ารหัสและคุณภาพของภาพที่เข้ารหัสแยกจากกัน แต่ libjxl สามารถปรับประสิทธิภาพการเข้ารหัสกับคุณภาพการเข้ารหัสได้อย่างอิสระโดยสมบูรณ์ ขณะที่ encoder อื่นส่วนใหญ่รวมถึง AVIF ทำเช่นนั้นไม่ได้ จึงไม่สามารถเปรียบเทียบแบบนั้นได้

  • ช่วงคุณภาพเป้าหมายที่ใช้ตอนเข้ารหัสกว้างเกินไปและไม่ได้คำนึงถึงการกระจายความน่าจะเป็น คุณภาพต่ำสุดที่ระบุว่า "On the fly" ต่ำมากจนไม่มีใครสามารถนำไปใช้ได้ไม่ว่าจุดประสงค์ใดก็ตาม นอกจากนี้ AVIF โดยเฉลี่ยมักเด่นในภาพคุณภาพต่ำ แต่เมื่อขนาดไฟล์เพิ่มขึ้นเพียงเล็กน้อยก็มักเป็น JPEG XL ที่นำหน้าอย่างชัดเจน อย่างไรก็ดี มีการนำค่าเฉลี่ยด้วยวิธีที่ไม่เหมาะสมจนทำให้จุดแข็งของ JPEG XL ถูกลดทอนลง

  • ชุดข้อมูลที่ใช้ทดสอบไม่เหมาะสม ในการบีบอัดแบบไม่สูญเสียข้อมูลมีการใช้ชุด Kodak ที่เป็นภาพสแกนนิตยสาร ส่วนการบีบอัดแบบสูญเสียข้อมูลกลับมีชุด Noto Emoji ซึ่งปกติแล้วมักเป็นกราฟิกเวกเตอร์หรือใช้การบีบอัดแบบไม่สูญเสียข้อมูล ทั้งสองอย่างไม่ใช่กรณีใช้งานทั่วไปของการบีบอัดแบบไม่สูญเสียหรือแบบสูญเสียข้อมูล

  • หากการถกเถียงเรื่องประสิทธิภาพการบีบอัดภาพเป็นเรื่องของปัจจุบัน ฟีเจอร์ที่ฟอร์แมตภาพรองรับก็คือเรื่องของอนาคต หากลบฟอร์แมตภาพที่ใส่เข้าไปในเบราว์เซอร์แล้วออกไม่ได้ ก็ยิ่งควรประเมินโดยให้น้ำหนักกับฟีเจอร์มากขึ้น

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

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

 
lifthrasiir 2022-12-15

ผมเขียนอย่างเร่งรีบก่อนออกไปทำงาน เลยมีจุดเล็กๆ น้อยๆ ที่ผิดอยู่บ้าง (...), ถ้าพูดอย่างเคร่งครัดแล้ว "on the fly" ไม่ใช่คุณภาพต่ำสุดแต่เป็นความเร็วสูงสุด (อย่างไรก็ตาม ในตัวเข้ารหัสส่วนใหญ่ยกเว้น JPEG XL มักมีความสัมพันธ์แบบผกผันกับคุณภาพ) นอกจากนี้ ชุดข้อมูล Kodak ผมก็ไม่รู้ว่าตอนนั้นคิดอะไรอยู่ถึงเขียนว่าเป็นนิตยสาร แต่จริงๆ แล้วเป็นสิ่งที่สแกนมาจากฟิล์ม