JPEG XL: จุดเริ่มต้นและสถานการณ์ปัจจุบัน

 (cloudinary.com)
1 คะแนน โดย GN⁺ 2023-07-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • JPEG XL คือ ฟอร์แมตบีบอัดภาพยุคถัดไปที่เริ่มพัฒนาในปี 2018 โดยรวม Google PIK และ Cloudinary FUIF เข้าด้วยกัน และงานมาตรฐานก็เสร็จสิ้นเมื่อบิตสตรีมถูกตรึงสมบูรณ์ในปี 2020
  • ก่อนที่ Chrome จะ ตัดสินใจถอดการรองรับในปี 2022 กระแสการใช้งานเคยขยายตัวอย่างราบรื่น โดยเบราว์เซอร์หลักอย่าง Firefox และ Chrome ได้เพิ่มการรองรับแบบทดลอง
  • เมื่อมีการประกาศว่า Safari 17 และ ผลิตภัณฑ์ทั้งหมดของ Apple รวมถึง iOS และ macOS รองรับ JPEG XL โมเมนตัมของการขยายอีโคซิสเต็มก็กลับมาแข็งแรงอีกครั้ง
  • Cloudinary ใช้ การทดลองบนชุดข้อมูล CID22 และเกณฑ์ SSIMULACRA 2 เพื่อเปรียบเทียบ JPEG XL, AVIF, WebP, mozjpeg ฯลฯ และวิเคราะห์ความแตกต่างในมุมของคุณภาพสูง การบีบอัดสูง และความเร็ว
  • มีการประเมินว่า JPEG XL ให้ประโยชน์ด้านการบีบอัดเพิ่มขึ้นอีก 5~10% เมื่อเทียบกับ AVIF และยังคงรักษาความเร็วในระดับที่เหมาะสม จึงถูกมองว่า เป็นโคเดกที่ดีที่สุดโดยเฉลี่ย ณ เวลานี้

จุดเริ่มต้นของ JPEG XL

  • คณะกรรมการ JPEG ได้จัด การเปิดรับข้อเสนอสำหรับมาตรฐานบีบอัดภาพยุคถัดไป และมีการส่งข้อเสนอเข้ามา 7 รายการ ก่อนจะเริ่มออกแบบ JPEG XL โดยผสานเทคโนโลยีของ Google PIK และ Cloudinary FUIF
    • ด้วยการรวมจุดเด่นของทั้งสองฟอร์แมต จึงเกิดเป็น โครงสร้างโคเดกใหม่ที่ให้การบีบอัดคุณภาพสูงและประสิทธิภาพสูงกว่า JPEG เดิม
  • บิตสตรีมถูกตรึงในช่วงปลายปี 2020 และได้รับการอนุมัติอย่างเป็นทางการเป็นมาตรฐาน ISO (ISO/IEC 18181) ในเดือนมีนาคม 2022
  • ในปี 2021 Chrome และ Firefox ได้เพิ่ม การรองรับแบบทดลองผ่านแฟลก ทำให้ดูเหมือนทุกอย่างกำลังไปได้สวย
  • แต่ราวช่วง Halloween ปี 2022 Chrome ได้ ประกาศถอดการรองรับแบบไม่ทันตั้งตัว จนเกิดข้อถกเถียง
    • ฝั่ง Cloudinary ได้ชี้ให้เห็น ปัญหาเชิงระเบียบวิธีหลายประการ ในวิธีทดสอบของ Chrome แต่ไม่ได้รับการสะท้อน
  • นอกเหนือจากเบราว์เซอร์ การรองรับ JPEG XL ก็ยังเพิ่มขึ้นต่อเนื่องในกลุ่ม เครื่องมือสร้างสรรค์งาน เช่น Serif Affinity, Adobe Camera Raw, GIMP และ Krita

การประกาศของ Apple ที่ WWDC

  • ใน WWDC23 ชื่อของ JPEG XL ถูกบรรจุอย่างเป็นทางการ ในรายการฟีเจอร์ใหม่ของ Safari 17
    • ทั้ง iOS, iPadOS, macOS, watchOS และ visionOS ในอีโคซิสเต็มของ Apple ต่างเพิ่มการรองรับ JXL
  • แม้แต่นักพัฒนา JPEG XL เองก็ ไม่คาดว่า Safari จะกลายเป็นเบราว์เซอร์ตัวแรกที่รองรับอย่างเป็นทางการ และการประกาศนี้ก็ช่วยเสริมโมเมนตัมของอีโคซิสเต็ม

การทดลองเปรียบเทียบโคเดกภาพ (CID22)

  • Cloudinary ได้สร้าง ชุดข้อมูลภาพ CID22 ขนาดใหญ่ (ข้อมูลเชิงอัตวิสัยที่มนุษย์ประเมินคุณภาพด้วยตนเอง)
    • แม้ว่าการประเมินเชิงอัตวิสัยจะเป็นเกณฑ์ที่แม่นยำที่สุด แต่การทดลองขนาดใหญ่ทำได้ยาก จึงนำข้อมูลนี้มาใช้ ตรวจสอบความน่าเชื่อถือของตัวชี้วัดอย่าง SSIMULACRA 2.1 และต่อยอดสู่การทดลองในวงกว้าง
  • การบีบอัดภาพต้องให้ความสำคัญกับสมดุลของ อัตราการบีบอัด คุณภาพการมองเห็น และความเร็วในการเข้ารหัส
    • ภายใต้เงื่อนไขคุณภาพเท่ากัน ได้มีการเปรียบเทียบ JPEG XL, AVIF, WebP และ mozjpeg โดยอิงตาม SSIMULACRA 2
  • ผลลัพธ์หลัก
    • WebP: ในช่วงคุณภาพต่ำลดขนาดได้ 25~35% เมื่อเทียบกับ JPEG แต่ในช่วงคุณภาพสูง ประโยชน์จะลดลงเพราะข้อจำกัดของ yuv420
    • เมื่อเทียบกับ mozjpeg แล้ว WebP ให้ประโยชน์เพิ่มขึ้นเพียงราว 3~5%
    • AVIF: ลดขนาดได้เพิ่มอีก 10~15% เมื่อเทียบกับ WebP และรองรับ yuv444 ทำให้ยังคงอัตราการลดขนาดที่สูงในช่วงคุณภาพสูง
      • อย่างไรก็ตาม ความเร็วในการเข้ารหัสช้ามาก (ช้ากว่าหลายเท่าระดับเลขหลักเดียวเมื่อใช้ค่าตั้งต้นพื้นฐานของตัวเอง)
    • JPEG XL: ลดขนาดได้เพิ่มอีก 5~10% เมื่อเทียบกับ AVIF โดยเฉพาะในช่วงคุณภาพสูงที่ความต่างชัดเจน
      • ความเร็วในการเข้ารหัสก็เร็วกว่าของ AVIF และมีประสิทธิภาพที่ใช้งานจริงได้

การใช้งาน JPEG XL และการรองรับของ Cloudinary

  • เนื่องจาก Cloudinary มีส่วนร่วมในการพัฒนา JPEG XL จึง ให้การรองรับ JXL ได้เป็นรายแรก ๆ
    • สามารถแปลงได้โดยเพิ่ม f_jxl ใน URL หรือเปลี่ยนนามสกุลไฟล์เป็น .jxl
  • หากเป็นบริการที่มีสัดส่วนผู้ใช้ Safari สูง กลยุทธ์ ให้ JPEG XL เป็นตัวเลือกหลัก แล้วใช้ AVIF/WebP/JPEG เป็นฟอลแบ็กสำหรับเบราว์เซอร์อื่น ก็มีประสิทธิภาพ
  • เนื่องจากภาพแต่ละภาพมีโคเดกที่เหมาะสมต่างกัน Cloudinary จึงกำลังพัฒนา เวอร์ชันใหม่ของ f_auto,q_auto ที่ขับเคลื่อนด้วย AI
    • มีแผนจะเพิ่มความสามารถในการเลือกฟอร์แมตที่เหมาะสมที่สุดสำหรับแต่ละภาพโดยอัตโนมัติ

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

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

 
GN⁺ 2023-07-22
ความคิดเห็นจาก Hacker News
  • MKV ซึ่งเป็น "รูปแบบคอนเทนเนอร์" สำหรับวิดีโอและเสียงที่เสถียรยังคงอยู่ต่อไป ในขณะที่การเข้ารหัสภาพแบบใหม่กลับต้องการรูปแบบคอนเทนเนอร์และนามสกุลไฟล์ใหม่
  • ตัวถอดรหัส AV อย่าง libffmpeg รองรับฟอร์แมตและโคเดก AV ที่น่าสนใจแทบทั้งหมด ทำให้เกิดการรองรับโคเดกใหม่อย่างแพร่หลายได้
  • ไม่มี "ไลบรารีแบบอูเบอร์" สำหรับฟอร์แมตภาพ+โคเดกแบบเดียวกับ libffmpeg
  • ตอนนี้ Chrome และ Edge รองรับและแสดงผล JXL ได้แล้วบน iOS 17
  • JPEG 2000 ไม่เคยถูกนำไปใช้จริงอย่างแพร่หลาย และ JPEG XL ก็เป็นเพียงการปรับปรุงแบบค่อยเป็นค่อยไป
  • บางคนยังไม่มั่นใจเมื่อจะใช้ webp, avif หรือ jxl เพราะการรองรับยังจำกัดและการทำงานกับไฟล์ประเภทเหล่านี้ทำได้ยาก
  • การยอมรับรูปแบบภาพใหม่อาจชวนให้นึกถึงช่วงแรก ๆ ของ JPEG
  • ผู้ใช้บางรายมีประสบการณ์ที่แตกต่างกันกับฟอร์แมตบีบอัดภาพอย่าง WEBP, AVIF และ JPEG XL
  • ความสนใจต่อ AVIF และ JPEG XL กำลังเพิ่มขึ้นจากความต้องการเผยแพร่ภาพที่มีช่วงสีกว้าง
  • ระบบนิเวศของ Apple รับ HEIF มาใช้ แต่ไม่ได้รับวิดีโอ AV1 มาใช้
  • ผู้ใช้บางรายหวังให้มีการรวมฟอร์แมต BPG เพิ่มเติมนอกเหนือจาก JPEG XL
  • JPEG XL แตกต่างจาก JPEG 2000 และ JPEG XR
  • ชื่อ "JPEG XL" อาจส่งผลต่อความสำเร็จได้
  • มีข้อเสนอให้ใช้ JPEG XL เป็นโคเดกภาพนิ่งในฟอร์แมตวิดีโอใหม่ที่อิงกับ AV1