Google กลับมาสนับสนุน JPEG XL แล้วหรือยัง?

• การฟื้นฟูการรองรับ JPEG XL โดยเอนจิน Chromium ทำให้รูปแบบไฟล์ภาพที่เคยถูกยกเลิกกลับมาได้รับความสนใจอีกครั้ง
• ในปี 2022 Google ลบ JPEG XL ออกด้วยเหตุผลว่ามี การขาดความสนใจจากระบบนิเวศ แต่ แรงกดดันต่อเนื่องจากชุมชนและองค์กรหลัก ก็ยังคงดำเนินอยู่
• Meta, Intel, Adobe, Cloudinary, Krita และองค์กรอื่น ๆ ได้ประกาศสนับสนุนความจำเป็นในการคงรูปแบบนี้อย่างเปิดเผย
• ล่าสุด PDF Association แสดงเจตนาจะรับรอง JPEG XL เป็น รูปแบบหลักสำหรับเนื้อหา HDR ทำให้กระแสนี้เข้มข้นขึ้น
• การตัดสินใจนำ Chrome กลับมาใช้ได้ถูกประเมินว่าเป็นจุดเปลี่ยนที่ยกระดับความเป็นไปได้ในการทำให้ JPEG XL กลายเป็นมาตรฐานสากลได้จริง

---

ฉากหลังการกลับมาอีกครั้งของ JPEG XL

• ทีม Chromium ในปี 2022 ยกเลิกโค้ดและแฟล็กของ JPEG XL โดยอ้างว่า ระบบนิเวศมีความสนใจไม่เพียงพอ และ ข้อได้เปรียบไม่ชัดเจนเมื่อเทียบกับรูปแบบเดิม
  • ขณะนั้นชุมชนได้แสดงการสนับสนุนจากองค์กรสำคัญ เช่น Meta, Intel, Cloudinary, Adobe, ffmpeg, libvips, Krita
  • หลังจากนั้นมีปฏิกิริยาในบล็อก วิดีโอ และโซเชียลมีเดียที่ชี้ว่า การตัดสินใจลบออกนั้นไม่ยุติธรรม
• ปลายปี 2025 ทีม Chromium เปลี่ยนประเด็น JPEG XL ที่เคยอยู่สถานะ Obsolete เป็น Assigned และเริ่มดำเนินการฟื้นฟูอย่างเป็นทางการ
  • ในกลุ่มนักพัฒนา Blink, Rick Byers กล่าวว่า "ยินดีต้อนรับตัวถอดรหัส JPEG XL ที่มีประสิทธิภาพดีและปลอดภัยต่อหน่วยความจำ"
  • การตัดสินใจนี้ตั้งอยู่บนสัญญาณบวกหลายด้าน เช่น การสนับสนุนของ Safari การเปลี่ยนแนวทางของ Firefox และความเคลื่อนไหวในการยอมรับของ PDF Association

Firefox และการพัฒนาตัวถอดรหัสพื้นฐานด้วย Rust

• ทีม Firefox กังวลเรื่อง ความเสี่ยงด้านความปลอดภัยของตัวถอดรหัส JPEG XL ที่ใช้ C++ โดย libjxl และชี้ให้เห็นความจำเป็นของเวอร์ชันภาษา Rust ที่ "ปลอดภัยต่อหน่วยความจำ"
  • ตามนั้น Google Research เริ่มพัฒนา ตัวแก้ไขด้วย Rust ชื่อ jxl-rs
  • โครงการนี้เป็นตัวผลักดันที่ช่วยเพิ่มความเป็นไปได้ในการผสาน JPEG XL เข้ากับเบราว์เซอร์อย่างปลอดภัย

ความเคลื่อนไหวในการรับรองของ PDF Association

• CTO ของ PDF Association, Peter Wyatt แสดงความตั้งใจว่าจะใส่ JPEG XL เป็น รูปแบบพื้นฐานของภาพ HDR ในข้อกำหนด PDF
  • สิ่งนี้เป็นปัจจัยที่เสริมความเป็นไปได้ในการทำให้ JPEG XL กลายเป็นมาตรฐานในโลกเอกสารและการพิมพ์

คุณสมบัติทางเทคนิคหลักของ JPEG XL

• รองรับ การบีบอัดซ้ำแบบไม่สูญเสียข้อมูลของ JPEG เดิม ซึ่งช่วยลดขนาดได้ประมาณ 30% โดยไม่ลดคุณภาพ
• รองรับ gamut สีกว้างและ HDR โดยรองรับสูงสุด 32 บิตต่อช่องสัญญาณ และ 4,099 ช่องสัญญาณ
• รองรับขนาดภาพสูงสุด 1,073,741,823×1,073,741,824 จึงจัดการภาพขนาดยักษ์ได้
• รองรับ การถอดรหัสแบบค่อยเป็นค่อยไป (progressive decoding) เพื่อเพิ่มประสิทธิภาพการส่งผ่านในเว็บ
• รวมฟีเจอร์ แอนิเมชัน, ความโปร่งใสแบบอัลฟา, และแผนที่ความลึก (depth map)
• โครงสร้างที่ทนต่อการสูญเสียตามรุ่น ทำให้การเข้ารหัสซ้ำหลายครั้งมีการสูญเสียคุณภาพน้อยที่สุด

บทสรุป

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

[xguru]

2022-09-04 Show GN: J40: ตัวถอดรหัส JPEG XL
2022-11-02 Google Chrome เตรียมหยุดรองรับ JPEG-XL ตั้งแต่เวอร์ชัน 110 เป็นต้นไป
2023-07-22 JPEG XL: จุดเริ่มต้นและสถานการณ์ปัจจุบัน
2024-04-05 Jpegli - ไลบรารีเข้ารหัส JPEG ใหม่ที่ Google สร้างขึ้น
2024-09-21 เหตุผลที่ Apple ใช้ JPEG XL ใน iPhone 16 และผลกระทบต่อภาพถ่าย

[GN⁺]

ความคิดเห็นใน Hacker News

• หนึ่งในความสามารถเจ๋ง ๆ ของ JPEG XL ที่คนยังไม่ค่อยรู้จักคือโหมดที่สามารถ แปลงจาก JPEG แบบไม่สูญเสียข้อมูล พร้อมลดพื้นที่จัดเก็บได้ราว 20%
  เพราะคงบิตสตรีมเอนโทรปีต้นฉบับไว้เหมือนเดิม จึง ย้อนกลับได้ทั้งหมด
  GCP กำลังนำสิ่งนี้ไปใช้กับ DICOM Store API ทำให้ได้ประโยชน์จากการประหยัดพื้นที่ของ JXL พร้อมทั้งแปลงกลับเป็น JPEG แบบเรียลไทม์เพื่อให้บริการได้
  บริษัทของเราจัดเก็บข้อมูลระดับหลายสิบ PB ไว้ใน GCP DICOM Store จึงคาดว่าฟีเจอร์นี้จะช่วยลดค่าใช้จ่ายรายปีได้มาก
  หวังว่าจะมี การรองรับแบบเนทีฟ ในเบราว์เซอร์ด้วย และได้ยินมาว่าทีม Chrome น่าจะรองรับในที่สุด

  • สงสัยว่ามันต่างจากตัวเข้ารหัส JPEG ทั่วไปหรือ mozjpeg อย่างไรเมื่อเทียบกัน
  • ก่อนหน้านี้ไม่เคยมีเวลาทดสอบ GCP DICOM Store จึงอยากรู้ว่าพอใช้งานจริงแล้วเป็นอย่างไร
    อยากรู้ว่าเป็น PACS แบบสมบูรณ์, เป็นการทำ WADO, หรือเป็นแค่ custom API ธรรมดา
  • ถ้าย้อนกลับได้ แบบนั้นก็เก็บเป็น JPEG XL แล้วค่อยแปลงกลับตอนให้บริการก็พอไม่ใช่หรือ
    เลยถามว่ามันกินเวลาในการประมวลผลมากหรือเปล่า
  • ถ้ายังไงก็ต้องเก็บ DICOM ต้นฉบับอยู่แล้ว ก็สงสัยว่าการแปลงจะมีความหมายแค่ไหน
    เพราะต้นทุนการเก็บข้อมูลส่วนใหญ่น่าจะมาจากตัว DICOM เอง
  • ท้ายที่สุดลูกค้ารายใหญ่ของ GCP ก็จะได้ประโยชน์มากจากฟีเจอร์นี้ เลยทำให้นึกว่า เหตุผลที่ดัน JXL ใน Chrome อาจเป็นเพราะลูกค้าภายใน

• คู่แข่งของ JPEG XL ไม่ใช่ AVIF
  AVIF กลายเป็น มาตรฐานโดยพฤตินัย ไปแล้ว เบราว์เซอร์แทบทั้งหมดรองรับ และยังถูกใช้เป็นฟอร์แมตรูปภาพเริ่มต้นของ Apple ด้วย
  ส่วน JXL ยังมีการรองรับในเบราว์เซอร์ไม่มาก แต่กำลังเริ่มมีที่ยืนในตลาดเฉพาะอย่าง งานเก็บถาวร, ภาพถ่ายระดับมืออาชีพ และงานการแพทย์
  อีกสัก 10 ปี คนอาจเรียกมันสั้น ๆ ว่า “JPEG” ไปเลยเพราะแพร่หลายมากพอ
  AVIF เป็นมาตรฐานเปิดและปลอดค่าลิขสิทธิ์ มีประสิทธิภาพการบีบอัดสูงกว่า JPEG/WebP มาก และอยู่ในระดับใกล้เคียงกับ JXL
  JXL มีขนาดภาพสูงสุดที่ใหญ่กว่าก็จริง แต่ในด้านการยอมรับใช้งาน AVIF นำไปไกลกว่ามาก
  ถ้า AV2 ออกมา ช่องว่างด้านคุณภาพก็น่าจะแทบหายไป และทั้งสองฟอร์แมตก็น่าจะพัฒนาไปพร้อมกันโดยรักษา ระดับคุณภาพที่ใกล้เคียงกัน ไว้

  • AVIF เหนือกว่า JPEG หรือ WebP ในด้านประสิทธิภาพการบีบอัดก็จริง แต่กับ JXL นั้น สู้ไม่ได้เลย
    ที่การตั้งค่าคุณภาพแบบใช้งานจริง JXL ให้การบีบอัดที่ดีกว่าและเข้ารหัส/ถอดรหัสได้เร็วกว่า
    แถมยังรองรับ progressive decoding ด้วย
    ถ้า AV2 ออกมาอาจไล่ทัน แต่ตอนนี้ผมคิดว่า JXL นำอยู่มาก
  • หนึ่งในเหตุผลที่ทีม Chrome ยกเลิกการรองรับ JXL ไปก่อนหน้านี้คือ AVIF ดีพออยู่แล้ว
    การทบทวนใหม่ครั้งนี้ก็ดูเหมือนจะเชื่อมโยงกับการตัดสินใจในตอนนั้น
  • คำพูดที่ว่า “ฟอร์แมตรูปภาพเริ่มต้นของ Apple คือ AVIF” น่าจะไม่ถูกต้อง
    iPhone ใช้ HEIF
  • เคยลองใช้ libjxl โดยตรงแล้วพบว่า ใช้หน่วยความจำมากและไม่เสถียร
    การเข้ารหัสภาพความละเอียดสูงถึงขั้นต้องใช้ RAM ระดับเทราไบต์
    โค้ดเบสดูยุ่งเหยิงจนน่าตกใจ และตัวเลือกหลายอย่างก็ทำงานได้ไม่ถูกต้อง
    การลองใหม่ด้วย jxl-rs เป็นเรื่องน่ายินดี แต่เพราะยังเป็นนักพัฒนากลุ่มเดิมมีส่วนร่วมอยู่ จึงยังมองอย่างระมัดระวัง

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

  • Mozilla มีจุดยืนคล้ายกัน แต่ Google เคยมี ท่าทีเป็นปฏิปักษ์ อยู่พักหนึ่ง
    ปิด issue ไปทั้งที่ผู้ใช้คัดค้าน และเพิ่งกลับมาเปิดใหม่ไม่นานนี้
    อาจเป็นเพราะ ปัญหา PR หรือความไม่พอใจภายในก็ได้
  • jxl-rs เคยมีช่วงที่ไม่มีคอมมิตนานกว่าปีครึ่ง
    ที่ตอนนี้กลับมาดำเนินไปได้ดีอาจเป็น ผลจากโชคช่วย ก็ได้

• เคยดู อิมพลีเมนเทชันอ้างอิง (C++) ของ JPEG XL แล้ว เมื่อ 2 ปีก่อนคุณภาพโค้ดยังไม่ดีนัก
  ให้ความรู้สึกเหมือนอาจมีปัญหาด้านความปลอดภัยเกิดขึ้นได้

  • เพราะแบบนั้นทั้ง Mozilla และ Google จึงกำลังพิจารณาการรองรับ JXL โดยมีเงื่อนไขว่า ต้องมีอิมพลีเมนเทชันที่ปลอดภัยด้านหน่วยความจำ
    เวอร์ชัน Rust กำลังพัฒนาอยู่ และ Google ก็มีแผนจะค่อย ๆ เปลี่ยนตัวถอดรหัสทั้งหมดใน Chromium ไปเป็น Rust
  • จริง ๆ แล้ว ณ เวลานี้ (2025) โค้ดประมวลผลภาพขนาดใหญ่ที่เขียนด้วย C++ เองก็เป็น ความเสี่ยงด้านความปลอดภัย อยู่แล้ว
    ไม่ใช่ปัญหาเฉพาะของ JPEG XL

• ความละเอียดสูงสุดของ JPEG XL คือ 1,073,741,823 × 1,073,741,824 ซึ่งสามารถแทนภาพความละเอียดมหาศาลระดับ หลายร้อยเพตะไบต์ ได้
  ในทางปฏิบัติแม้บีบอัดแล้วก็ยังอยู่ระดับหลายสิบถึงหลายร้อย PB

  • ถ้าคิดที่ 600DPI ด้านหนึ่งจะยาวระดับ ระยะทางมาราธอน
    ถ้ากำหนดภาพขนาดยักษ์แบบนี้ได้ด้วยข้อมูลเพียงไม่กี่ไบต์ มันก็ดูเหมือนอาจเป็น ช่องทางสำหรับการโจมตีแบบ DOS ได้
    ตอนพยายามแปลงเป็นจำนวนกระดาษ A4 เครื่องคิดเลขของ Gemini ดันสับสนเรื่องหน่วยแล้วให้คำตอบเพี้ยน ๆ ออกมา
  • ภาพมหึมาแบบนี้ วิธีเดียวที่ใช้งานได้จริงคือจัดการด้วย การแบ่งเป็นไทล์และโครงสร้างแบบพีระมิด
  • น่าจะมีขนาดประมาณภาพถ่ายทั้งโลกที่ความละเอียดราว 4 ซม.
  • ถ้าถ่ายเซลฟีที่ความละเอียดนั้น ก็คงระดับ กล้องจุลทรรศน์ซูเปอร์เรโซลูชัน เลยทีเดียว
  • JPEG XL ต่างจาก AVIF ตรงที่รองรับ progressive decoding ที่มีประสิทธิภาพ จึงสามารถเห็นภาพพรีวิวคุณภาพต่ำได้อย่างรวดเร็วระหว่างดาวน์โหลด

• รวมการพูดคุย HN ในอดีต
  Chromium Team Re-Opens JPEG XL Feature Ticket
  FSF Slams Google over Dropping JPEG-XL in Chrome
  Google set to deprecate JPEG XL support in Chrome 110
  Chromium jpegxl issue closed as won't fix

  • เธรดที่เกี่ยวข้องเพิ่มเติมถูกรวบรวมไว้ที่นี่
  • ประเด็นถกเถียงสำคัญล่าสุดดูได้ที่ Google Revisits JPEG XL in Chromium After Earlier Removal

• ผมใช้ .avif มาหลายปีแล้ว
  มันไม่สมบูรณ์แบบ แต่รู้สึกว่าดีกว่า .jpg หรือ .png มาก
  เคยพิจารณา .webp และ jpeg-xl ด้วย แต่สุดท้ายก็พอใจกับ .avif
  เพียงแต่ไม่ชอบที่ Google แทบจะ กำหนดมาตรฐานเว็บได้ตามใจ
  การที่บริษัทเชิงพาณิชย์ควบคุมระบบนิเวศดิจิทัลไม่ใช่เรื่องพึงประสงค์

  • ประโยคที่ว่า “.jpg ดีกว่า .avif” ทำให้สับสนเพราะ พูดถึง .avif ซ้ำสองครั้ง
  • ถ้าอยากทำ JPEG คุณภาพสูงให้เล็กลง แนะนำให้ลอง jpegli
    jpegli GitHub
    ถ้าปรับค่า visual lossless ของ AVIF ได้ดี มันอาจเล็กกว่า jpegli แต่โดยเฉลี่ยแล้ว jpegli มีประสิทธิภาพดีกว่า
  • อนึ่ง ในภาษาอังกฤษ “since some years” ฟังไม่เป็นธรรมชาติเท่า “for several years”
  • JPEG XL เสียคุณภาพน้อยแม้จะบันทึกซ้ำหลายครั้ง จึงเหมาะกับการใช้งานบนเว็บ
    วิดีโอที่เกี่ยวข้อง: ลิงก์ YouTube

• คนที่ถอด JXL ออกไม่ใช่ “Google ทั้งบริษัท” แต่เป็น ทีม Chrome
  JXL ถูกออกแบบโดย Jyrki Alakuijala จาก Google Zurich Research ซึ่งไม่ได้อยู่ทีม Chrome
  ทีม Chrome มีวัฒนธรรมแบบ ปิดตัวและรวมศูนย์ที่ Mountain View

  • Jyrki เป็นวิศวกรที่ยอดเยี่ยม ผู้สร้าง Brotli, WebP lossless, WOFF2, jpegli และอีกหลายอย่าง
    การที่เขาสร้าง jpegli หลังจาก JpegXL ถูกทิ้งไปก็เหมือนเป็นปฏิกิริยาตอบสนองรูปแบบหนึ่ง
  • สถานการณ์นี้อาจอธิบายได้ด้วย Conway’s Law

• ดูเหมือน JXL จะล่าช้าเพราะมีการพึ่งพา C++ แบบมัลติเธรดมาก ทำให้ พื้นผิวการโจมตีด้านความปลอดภัย กว้างขึ้น
  ทั้ง Mozilla และ Google ต่างอยากหลีกเลี่ยงสิ่งนี้ จึงชอบ อิมพลีเมนเทชัน Rust มากกว่า
  ตัวมาตรฐานเองถือว่าเป็นฟอร์แมตที่ดีกว่าของเดิมอย่างชัดเจน

  • บอกว่ามี 100 ล้านบรรทัดก็ดูเกินจริงมาก
  • จริง ๆ แล้วมีประมาณ 30,000 บรรทัด และเวอร์ชันเธรดเดียวน่าจะอยู่ราว 10,000 บรรทัด
    ไบนารีก็เล็กกว่า AVIF มาก และสเปกก็สั้นกระชับกว่ามาก
  • Google มีส่วนร่วมในการพัฒนา JXL เอง ดังนั้นการที่ ไม่ได้สร้างตัวถอดรหัสแบบปลอดภัยด้านหน่วยความจำให้เร็วกว่าเดิม ก็เป็นความรับผิดชอบของตัวเอง
  • หรือจริง ๆ หมายถึง 100,000 บรรทัด? ในจำนวนนั้นก็น่าจะมีโค้ดทดสอบอยู่มากพอสมควร
  • libjxl จริง ๆ มีประมาณ 112,000 บรรทัด ซึ่งต่างจากคำกล่าวอ้าง 100 ล้านบรรทัดอยู่ 3 หลัก

• ว่ากันว่าไฟล์ RAW ของ iPhone 17 Pro จะถูกบีบอัดด้วย JPEG XL