Chromium ผสานรวม JpegXL แล้ว

 (chromium-review.googlesource.com)
2 คะแนน โดย GN⁺ 2026-01-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการผสานรวมตัวถอดรหัส JpegXL เข้ากับโค้ดเบสของ Chromium ทำให้เบราว์เซอร์สามารถประมวลผลภาพฟอร์แมต JXL ได้
  • สามารถดูการเปลี่ยนแปลงได้ในหน้ารีวิวโค้ด Gerrit ภายใต้ชื่อ “Wire up JXL decoder”
  • การรวมครั้งนี้เป็น ขั้นตอนสำคัญสำหรับการรองรับฟอร์แมต JpegXL โดยรวมงานเชื่อมต่อตัวถอดรหัสไว้ด้วย
  • รีวิวโค้ดนี้ถูกลงทะเบียนเป็น การเปลี่ยนแปลงในรีโพซิทอรี src ของ Chromium (7184969)
  • มีความหมายในแง่ของการ ขยายการรองรับฟอร์แมตภาพยุคถัดไป ของเว็บเบราว์เซอร์

การผสานรวมตัวถอดรหัส JpegXL ของ Chromium

  • รายการรีวิวโค้ด Gerrit “Wire up JXL decoder (7184969)” คือการเปลี่ยนแปลงที่เชื่อมต่อตัวถอดรหัส JpegXL เข้ากับโปรเจกต์ Chromium
    • การเปลี่ยนแปลงนี้ดำเนินการภายใน รีโพซิทอรี src ของ Chromium
    • แพลตฟอร์มรีวิวโค้ดใช้ chromium-review.googlesource.com
  • ตามชื่อของมัน งานนี้หมายถึงการ เชื่อมต่อตัวถอดรหัส JXL เข้าภายในเบราว์เซอร์ (wire up)
  • ในหน้านี้ ไม่มีคำอธิบายเพิ่มเติมหรือรายละเอียดโค้ดแสดงอยู่ โดยตรวจสอบได้เพียงชื่อของการเปลี่ยนแปลงเท่านั้น

บริบททางเทคนิค

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

สถานะของเอกสาร

  • หน้านี้แสดงเป็น สแนปช็อตแคชของ Gerrit code review
  • มีข้อความเตือนว่า “shadow DOM ถูกซ่อนไว้” แต่ ไม่มีการแสดงเนื้อหาโค้ดจริง
  • ดังนั้นข้อมูลที่ตรวจสอบได้จากเอกสารนี้จึงมีเพียง ชื่อการเปลี่ยนแปลงและตัวระบุรีวิว (7184969) เท่านั้น

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

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

 
GN⁺ 2026-01-14
ความคิดเห็นจาก Hacker News

  • เคยอ่าน บทความในบล็อกของ Cloudinary ซึ่งเป็นบทความคลาสสิกเก่าแก่ที่เปรียบเทียบ webp, jpegxl, avif, jpeg ฯลฯ
    กราฟจัดทำมาอย่างดี และ AVIF ช้ามาก

    • เมื่อตั้ง JPEG ไว้ที่คุณภาพต่ำสุด กลับดูดีกว่ามากในที่นี้
      ลิงก์ไปยังส่วนที่เกี่ยวข้อง
    • ไม่แน่ใจว่าเว็บไซต์นี้พยายามจะทำอะไรกันแน่
      ดูภาพหน้าจอ
    • หากเป็นจริงตามข้อความที่อ้างว่า JPEG XL ได้ตอกย้ำตำแหน่งของตัวเองในฐานะ codec ที่ดีที่สุดทั้งแบบสูญเสียข้อมูล/ไม่สูญเสียข้อมูล ในตอนนี้ นี่ก็เป็นความก้าวหน้าครั้งใหญ่ที่อาจแทนที่ JPEG และ PNG ได้พร้อมกัน
    • แต่การทดสอบนี้ ไม่ได้ใช้ตัวเข้ารหัส/ถอดรหัสที่เร่งด้วยฮาร์ดแวร์

  • ไลบรารี jxl-rs เป็น implementation ของ JPEG XL ใน Rust
    แม้จะเป็นโปรเจ็กต์ที่ค่อนข้างใหม่ แต่ด้วย Rust ก็ทำให้รู้สึกสบายใจขึ้นในแง่ ความมั่นคงปลอดภัย
    ตอนที่ Chromium เคยถกเถียงกันก่อนหน้านี้ ยังไม่มีไลบรารีนี้

    • จำได้ว่าเหตุผลที่ Google ปฏิเสธ JPEG XL คือเพราะ “ความสนใจไม่มากพอ” ไม่น่าใช่เพราะปัญหาด้านความปลอดภัย
    • ไม่เห็นด้วยกับคำพูดที่ว่า “Rust ช่วยลดความกังวลด้านความปลอดภัย” เพราะ ความปลอดภัยของหน่วยความจำไม่ใช่ความปลอดภัยทั้งหมด
      Rust อาจทำให้คนประมาทเกินไป และเกิดการละเลย threat modeling
      ในทางกลับกัน โปรแกรมเมอร์ C ที่ระมัดระวังอาจปลอดภัยกว่าเสียอีก
    • ลองไปเช็กดูแล้วว่ามี unsafe code อยู่มากแค่ไหน
      ลิงก์ผลการค้นหา

  • เมื่อไม่นานมานี้ได้ลองเทียบ WebP กับ AVIF แล้วพบว่า WebP เข้ารหัสได้แทบจะทันที ขณะที่ AVIF ใช้เวลามากกว่า 20 วินาทีสำหรับภาพ 1MP
    JXL ยังมีการรองรับน้อยเลยยังใช้จริงไม่ได้ แต่ก็คาดหวังว่ามันจะมีความเร็วระดับ WebP พร้อมคุณภาพที่ดีกว่า

    • มีคนบอกว่า rav1e แทบไม่ได้อัปเดตมาหลายปีแล้ว ดังนั้นใช้ตัวเข้ารหัสอย่าง aom หรือ svt-av1 จะดีกว่า
    • AVIF ต้องปรับพารามิเตอร์การใช้ CPU เพราะค่าปริยายตั้งระดับ CPU ไว้สูงเกินไปจนช้า
      ในสภาพแวดล้อมของฉัน สร้าง AVIF ขนาด 2MP ได้ในราว 100ms

  • น่าเสียดายที่ สเปกแบบเปิดเผยต่อสาธารณะ ของ JPEG XL ไม่ได้เข้าถึงได้อย่างเสรี

    • คิดว่าการคงมาตรฐานที่ไม่เปิดเผยไว้นั้นน่าอับอาย
    • ปัญหาคือเอกสารจำนวนมากขององค์กรอย่าง ISO, IEC ยังอยู่หลัง กำแพงจ่ายเงิน (paywall)

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

    • ถึงอย่างนั้น แม้แต่ Microsoft ก็ยังออกส่วนเสริม JPEG XL มาแล้ว และตอนนี้ที่ Google ถอยออกไปแล้ว ก็ดูเหมือนจะเป็น โอกาสจริงๆ
      ลิงก์ Microsoft Store
    • ในความเป็นจริงก็มีแอปจำนวนมากรองรับอยู่แล้ว — Affinity, Photoshop, Microsoft Photos, Gimp รวมถึง การรองรับทั้งระบบ บน iOS 17+/macOS 12+
      กลับเป็น Chromium ที่ช้ากว่าเพื่อน
    • แน่นอนว่าฟอร์แมตใหม่ๆ มักต้องใช้ เวลานำมาใช้ราว 10 ปี เสมอ

  • ลองอ่านรายการฟีเจอร์ของ JPEG XL จากวิกิแล้ว พบว่ามีความสามารถน่าสนใจอย่าง ภาพหลายแชนเนล หรือ เอกสารหลายหน้า
    มีข้อดีอยู่ แต่ก็เริ่มให้ความรู้สึกว่ามันซับซ้อนขึ้นเรื่อยๆ จนคล้าย TIFF

  • ระหว่าง JPEG กับ JPEG-XL ก็ยังมีจุดร่วมกันอยู่มาก
    ถ้า implementation ใหม่รวมการรองรับ JPEG เดิมเข้าไปด้วย จะช่วย ลดขนาดโค้ด ได้หรือไม่ก็น่าสงสัย

    • จริงๆ แล้วมี issue สำหรับฟีเจอร์นั้นเปิดอยู่ใน repository Rust ของ JPEG-XL
      ลิงก์ issue #513

  • ส่วนตัวแล้วตั้งใจจะใช้ JPEG เดิม ต่อไปมากกว่าฟอร์แมตใหม่อย่าง WEBP
    โปรแกรมส่วนใหญ่รองรับอยู่แล้ว และสำหรับผู้ใช้ทั่วไป JPEG + PNG ก็เพียงพอ
    แอนิเมชันง่ายๆ ใช้ GIF ส่วนที่ซับซ้อนก็จัดการเป็นวิดีโอได้

    • “JPEG XL” แม้ชื่อจะเป็นแบบนั้น แต่จริงๆ ไม่ใช่แค่ JPEG รุ่นขยาย
      มันทำ การเข้ารหัสแบบไม่สูญเสียข้อมูล ได้ด้วยขนาดเล็กกว่า PNG และยังรองรับ transcoding แบบกู้คืนได้ โดยบีบอัด JPEG เดิมได้เพิ่มอีกราว 20%
      มีฟีเจอร์หลากหลายอย่าง HDR, wide gamut, การโหลดแบบ progressive ฯลฯ จึงเหมาะกับการส่งผ่านเว็บอย่างยิ่ง
      ดูเพิ่มเติมที่ jpegxl.info
    • ปัจจุบัน WebP ถือได้ว่าเป็น ฟอร์แมตมาตรฐานโดยพฤตินัย แล้ว
      เบราว์เซอร์หลักทั้งหมดรองรับตั้งแต่ Safari 14 เป็นต้นไป และมีมาให้โดยปริยายใน Windows 10·macOS Big Sur ขึ้นไป
      ดู สถานะการรองรับ, รายชื่อซอฟต์แวร์
    • ตอนนี้ GIF ไม่มีประสิทธิภาพแล้ว การ แทนที่ด้วยวิดีโอ จะมีประสิทธิภาพกว่าถึง 5~10 เท่า
      บทความที่เกี่ยวข้อง

  • ได้ยินข้อถกเถียงเรื่อง JPEG XL, WebP, AVIF มานานแต่ก็ไม่ค่อยเข้าใจนัก
    พอดู benchmark แล้ว JpegXL เหนือกว่า WebP ทั้งในด้านความเร็วในการบีบอัดและขนาดไฟล์ จึงสงสัยว่าทำไม Chromium ถึงลังเลที่จะรองรับ

    • WebP กับ AVIF แชร์โค้ดกับ VP8/AV1 จึง ผสานเข้ากับเบราว์เซอร์ได้ง่าย ขณะที่ JPEG-XL เป็นโค้ดเบสแยกต่างหาก ทำให้ภาระในการ implement สูงกว่า
      นอกจากนี้ libjxl ยังเป็นโค้ด C++ กว่า 100,000 บรรทัด จึงมี ความเสี่ยงด้านช่องโหว่ความปลอดภัย
      พอ implementation ใน Rust เริ่มสุกงอมขึ้น ดูเหมือน Chrome ก็กลับมาพิจารณาอีกครั้ง
    • JPEG XL รองรับ การถอดรหัสแบบ progressive
      วิดีโอเดโม
    • Google เคยอ้างว่า “ถ้ามีฟอร์แมตคล้ายกันหลายตัว ก็มีแต่จะเพิ่มความเสี่ยงด้านความปลอดภัย” และ AVIF เพียงตัวเดียวก็เพียงพอแล้ว
    • AVIF ทำได้ดีที่ bpp ต่ำ (คุณภาพต่ำ) แต่ไม่เก่งเรื่อง lossless ขณะที่ JXL เด่นในงานคุณภาพสูงและ lossless
    • ในอดีตไลบรารี C++ ของ JPEGXL เคยอยู่ในสภาพ หยุดการบำรุงรักษา แต่พอเวอร์ชัน Rust ปรากฏขึ้น การรองรับในเบราว์เซอร์ก็เริ่มเป็นไปได้

  • เคยสงสัยว่า JPEG XL รองรับแอนิเมชันหรือไม่

    • รองรับ แต่ ไม่มีการบีบอัดระหว่างเฟรมจึงไม่มีประสิทธิภาพ ทำให้ไฟล์ใหญ่กว่าวิดีโอทั่วไป
    • ตามหน้า Chrome platform status ระบุว่ารองรับทั้งแอนิเมชัน, HDR และ การถอดรหัสแบบ progressive
      ลิงก์รายละเอียด
    • พอลองทดสอบในเบราว์เซอร์ Canary จริงๆ ก็พบว่าแอนิเมชันทำงานได้ดี
    • มีคนพูดติดตลกว่า WebP นั้นแทบจะเป็น “ฟอร์แมตวิดีโอที่อยู่ในภาพ” ส่วน JPEG XL เป็น “ฟอร์แมตภาพที่อยู่ในวิดีโอ” เลยเกิดเป็น โครงสร้างสมมาตรแบบย้อนแย้ง ขึ้นมา 😄