เปิดตัวสเปก PNG ใหม่

• ฟอร์แมตไฟล์ PNG ได้รับการปรับปรุงครั้งใหม่ในรอบ 20 ปี และกลับมาทวงสถานะเดิมอีกครั้ง
• สเปกครั้งนี้เพิ่มเทคโนโลยีสมัยใหม่หลายอย่างอย่างเป็นทางการ เช่น รองรับ HDR, APNG (แอนิเมชัน), และข้อมูล Exif
• บริษัท IT รายใหญ่และผู้ประกอบการด้านบรอดแคสต์ เช่น Adobe, Apple, Google ร่วมกันพัฒนา
• สเปกล่าสุดมีการรองรับแล้วในหลายโปรแกรม เช่น Chrome, Safari, Photoshop
• ในอนาคตมีแผนอัปเดตเพิ่มเติม เช่น เทคโนโลยีการบีบอัดที่ดีกว่าเดิม และการเข้ารหัส/ถอดรหัสแบบขนาน

---

บทนำ: การคืนชีพของ PNG และความสำคัญของมัน

• ล่าสุด ฟอร์แมตไฟล์ PNG ได้รับการอัปเดตด้วยสเปกใหม่ หลังหยุดนิ่งมาราว 20 ปี
• องค์กรสำคัญอย่างหอสมุดรัฐสภาสหรัฐฯ, Library and Archives Canada และหอจดหมายเหตุแห่งชาติออสเตรเลีย ต่างเลือกใช้ PNG เป็น ฟอร์แมตที่แนะนำอย่างเป็นทางการ
• สเปกใหม่นี้ช่วยให้ PNG กลับมามี ความสามารถในการแข่งขัน ในตลาดและแสดงให้เห็นถึงนวัตกรรมอีกครั้ง

ฟีเจอร์และคุณสมบัติใหม่

การรองรับ HDR อย่างเหมาะสมและความเข้ากันได้ในอนาคต

• PNG รุ่นใหม่รองรับ HDR (High Dynamic Range)
• ในภาพเปรียบเทียบขอบเขตสี Rec. 2020 กับ Rec. 709 พื้นที่ที่กว้างกว่า (สามเหลี่ยมด้านนอก) แสดงถึงสีที่ภาพ HDR สามารถถ่ายทอดได้
• ข้อมูล HDR นี้ต้องใช้พื้นที่เพิ่มเพียง 4 ไบต์ (รวมถึงโอเวอร์เฮดของ chunk แบบเดิมของ PNG)
• Chris Lilley และผู้เขียนยุคแรก รวมถึงผู้เชี่ยวชาญทางเทคนิคหลัก ได้ร่วมอธิบายเทคโนโลยีใหม่นี้อย่างชัดเจน

การรับรอง APNG (Animated PNG) อย่างเป็นทางการ

• Animated PNG (APNG) ซึ่ง Mozilla เป็นผู้เสนอครั้งแรกและ Firefox รองรับ ก็ถูกรวมเข้าในสเปกอย่างเป็นทางการแล้ว
• ก่อนหน้านี้มีเพียงซอฟต์แวร์บางส่วนที่รองรับ แต่ปัจจุบันมีการนำไปใช้กันอย่างแพร่หลายในหลายโปรแกรม

การรองรับข้อมูล Exif อย่างเป็นทางการ

• Exif ช่วยให้เก็บเมตาดาต้า เช่น ลิขสิทธิ์, ข้อมูลกล้อง, ข้อมูล GPS ได้
• จึงมีประโยชน์สูงสำหรับการสร้างและจัดเก็บภาพ ตลอดจนการจัดการลิขสิทธิ์

การปรับปรุงโดยรวมและการแก้ไขข้อผิดพลาด

• มีการ แก้ไข Errata และทำให้ข้อกำหนดเดิมชัดเจนขึ้น ไปพร้อมกัน

เบื้องหลังและกระบวนการพัฒนา

• สเปก PNG ฉบับก่อนหน้าถูกเผยแพร่เมื่อราว 20 ปีก่อน (ก่อน iPhone เปิดตัว 3 ปีครึ่ง)
• การพัฒนากลับมาเริ่มอีกครั้งเมื่อ W3C Timed Text Working Group (มาตรฐานเทคโนโลยีคำบรรยาย) ชี้ให้เห็นถึงความจำเป็นที่ PNG ต้องรองรับ HDR
• เมื่อมีข้อเสนอขึ้นมา บริษัทเทคโนโลยีสำคัญอย่าง Adobe, Apple, BBC, Google, MovieLabs และ W3C ก็เข้าร่วมกันพัฒนา
• เกิดเป็นคอนซอร์เทียมที่แข็งแกร่งเพื่อยกระดับ PNG ให้เป็นฟอร์แมตรูปภาพยุคถัดไป
• ขณะนี้ อัปเดตต่อเนื่องอีกสองรายการ ก็อยู่ระหว่างการเตรียมการแล้ว

สถานะการใช้งานที่แพร่หลายในปัจจุบัน

• Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer และโปรแกรมอื่น ๆ อีกมาก รองรับสเปก PNG ล่าสุดแล้ว
• การรองรับกำลังขยายไปยังผู้ประกอบการบรอดแคสต์ รวมถึงฮาร์ดแวร์และเครื่องมือที่เกี่ยวข้อง
• ภาพสำหรับงานกระจายเสียง เช่น นิวส์สกอลล์และแบนเนอร์คะแนนกีฬา คือหนึ่งในตัวอย่างการใช้งาน HDR PNG แบบใหม่

แผนในอนาคต

• ในฉบับถัดไปมีแผนจะปรับปรุง ความเข้ากันได้ระหว่าง HDR & SDR ให้ดียิ่งขึ้น
• นอกจากนี้ยังมีการผลักดัน วิธีการบีบอัดที่ดีขึ้น และการเข้ารหัส/ถอดรหัสแบบขนาน
• ฉบับที่ 4 จะเป็นการอัปเดตที่ค่อนข้างสั้น และหลังจากนั้นมีแผนพัฒนาฉบับที่ 5 โดยอาศัยงานวิจัยด้านเทคโนโลยีการบีบอัด

[carnoxen]

ตอนแรกพวกเขาปฏิเสธว่า APNG ไม่ใช่มาตรฐานสำหรับรูปภาพขององค์กร แต่ในที่สุดตอนนี้ก็ยอมรับแล้วสินะ

[GN⁺]

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

• ผู้แสดงความคิดเห็นระบุว่าตนเป็นผู้เขียน และยินดีตอบคำถามเสมอ

  • เน้นว่านี่ไม่ใช่ฟอร์แมตใหม่ทั้งหมด แต่เป็นเวอร์ชันอัปเดตของฟอร์แมตเดิม

  • ระบุว่ามีความเข้ากันได้ย้อนหลังสูงมาก

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

  • สรุปประเด็นสำคัญไว้ เพราะอาจมีความสับสนเกี่ยวกับการทำงานภายในของ PNG

    • ไฟล์ PNG ประกอบด้วย data chunk หลายชนิด
    • แต่ละ chunk มีชื่อ ทำให้โปรแกรมสามารถข้าม chunk ที่ไม่รู้จักหรือไม่จำเป็นได้
    • ระบุชัดว่ามี image stream อยู่เพียงหนึ่งเดียว

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

  • ระบุว่าตนสนับสนุน meta-format และ tooling แบบอเนกประสงค์

    • ยกตัวอย่างโครงสร้างอย่าง Office Open XML หรือ ePub ที่แค่มีไลบรารี zip กับ XML ก็ parse ได้
    • อธิบายจากประสบการณ์ว่า PNG ก็มีโครงสร้างเกือบเหมือน Interchange File Format (ต่อไปนี้เรียก IFF) แต่ที่ผ่านมามีรายละเอียดสเปกต่างกันเล็กน้อยจนไม่สามารถใช้ IFF parser แบบทั่วไป parse ทั้งไฟล์ PNG และไฟล์ตระกูล IFF พร้อมกันได้
    • IFF นำไป implement ได้ง่ายและมีจุดเด่นด้าน data compression แต่จนถึงตอนนี้ถูกใช้แค่ในงานจำกัด เช่น ข้อมูลเกมเก่า หรือเสียง AIFF·RIFF และชี้ว่าความไม่เข้ากันระหว่าง PNG กับ IFF เป็นหนึ่งในเหตุผลที่ tooling แบบอเนกประสงค์ไม่เกิดขึ้น
    • หวังว่า PNGv3 ถ้าทำให้ไฟล์ PNG กลายเป็นไฟล์ IFF อย่างเป็นทางการได้ ก็อาจใช้ความแพร่หลายของ PNG เป็นแรงผลักให้ ecosystem IFF แบบทั่วไป (เช่น libiff) เติบโต และนำไปใช้กำหนดฟอร์แมตใหม่ ๆ ได้
    • กล่าวว่าตนเคยทำ PNG/IFF parser ด้วยตัวเอง และบอกว่าการปรับ PNG ให้เข้ากันกับ IFF แบบตรง ๆ นั้นทำได้ยาก อีกทั้งยังต้องรักษาความเข้ากันได้ย้อนหลังไว้ด้วย โดยเฉพาะกับ parser ฝั่งฮาร์ดแวร์
    • จึงเสนอให้โครงสร้าง IFF ดัดแปลงที่ PNG ใช้อยู่ ถูกจัดทำเอกสารแยกเป็นมาตรฐาน meta-format ใหม่ (IFF 2.0)
    • ต้องการให้ IFF 2.0 กำหนดโปรไฟล์ที่เข้ากันกับ PNGv2 และโปรไฟล์ที่ครอบคลุม IFFv1 อย่าง AIFF/RIFF อย่างเป็นทางการ เพื่อผลักดัน tooling IFF แบบทั่วไป
    • ต่อไปสำหรับโปรไฟล์ greenfield ใหม่ ๆ (ฟอร์แมตใหม่ที่ออกแบบให้เหมาะกับสภาพแวดล้อมปัจจุบัน) ก็อาจนำโครงสร้างอย่างการตรวจสอบความถูกต้องด้วยแฮชสมัยใหม่แทน CRC, การขยายชุดอักขระของชื่อ chunk, หรือโครงสร้างที่เก็บข้อมูลคุณสมบัติของแต่ละ chunk ได้อย่างมีประสิทธิภาพมาใช้
    • มองว่าโครงสร้างเหล่านี้ควรทำให้ทั้ง IFFv1 และ PNGv2 สามารถแปลงข้ามกัน (transcode) ได้ และแนวทางประกาศโปรไฟล์เชิงกลยุทธ์แบบที่ HTML5 ผสมและเข้ากันกับ HTML4 และ XHTML นั้นเหมาะสม
    • สรุปว่าตนให้ความสำคัญกับเป้าหมายด้านการออกแบบมากกว่ารายละเอียดปลีกย่อย โดยเน้นการลดความแตกต่างระหว่างฟอร์แมตเดิมกับฟอร์แมตใหม่ และการขยาย ecosystem ของเครื่องมือ

• ในเครื่องมือวาดรูปบนเว็บของฉัน ใช้วิธีเก็บ JSON representation ของเอกสารไว้ในช่องคอมเมนต์ของ PNG

  • ทำแบบนี้แล้วไฟล์ที่บันทึกไว้ใช้เป็นรูปภาพได้ทันที และยังโหลดกลับเข้า editor ได้ด้วย

  • ข้อดีคือไม่ต้องมีไฟล์ JSON ชื่ออ่านยากกองเต็มโฟลเดอร์ดาวน์โหลด

  • ฟังดูสนุกดี แต่ก็อธิบายกับผู้ใช้ยากว่าทำไมไฟล์ถึงถูกบันทึกเป็น .png หรือทำไมพอเปิดด้วย Paint แล้วเซฟใหม่ข้อมูลถึงหาย

  • Krita ก็เก็บการตั้งค่าแปรงแบบนี้เช่นกัน แต่ถ้าข้อมูลมีมากเกินไปอาจทำให้เกิดปัญหาที่ไม่คาดคิด

    • ประเด็นที่เกี่ยวข้อง: Krita-Brushes issue #4, บทสนทนา Memileo Impasto Brushes

  • Macromedia Fireworks ใช้ PNG เป็นฟอร์แมตบันทึกเริ่มต้นมาตั้งแต่ 20 ปีก่อนแล้ว

    • แน่นอนว่าตอนนั้นไม่ได้ใส่ JSON ลงไป

  • ฟรอนต์เอนด์สำหรับสร้างภาพ AI หลายตัวก็ใช้งานคล้ายกัน

    • โดยเก็บ prompt หรือ setting ไว้ใน comment ของภาพ ทำให้แค่เปิดภาพก็เรียกการตั้งค่ากลับมาได้ หรือโหลด workflow ทั้งชุดแบบ ComfyUI ได้
    • อันที่จริงคิดว่าเครื่องมือจัดการภาพจำนวนมากใช้วิธีนี้กันค่อนข้างแพร่หลาย

  • Macromedia Fireworks บันทึกไฟล์ Fireworks ไว้ใน PNG,

    • ส่วนไฟล์ Illustrator (AI) ของ Adobe แท้จริงแล้วคือ PDF,
    • และไฟล์ PSD ของ Photoshop ก็สามารถเก็บไว้ภายใน TIFF ได้
    • ด้วยเหตุนี้ ใน Photoshop จึงเห็นหลายเลเยอร์ แต่ซอฟต์แวร์อื่นอาจเห็นเพียงเลเยอร์เดียว

• สเปกนี้ใกล้เคียงกับการทำให้สิ่งที่ถูก implement กันอย่างกว้างขวางอยู่แล้ว กลายเป็นข้อกำหนดที่ชัดเจน

  • ถ้าจะเรียกว่า PNG รุ่นถัดไป แล้วต้องมี decoder ใหม่ ก็รู้สึกว่าเรียก PNG2 ไปเลยก็ได้

  • JPEG-XL ตอบโจทย์ codec แบบ lossless ที่คนส่วนใหญ่ต้องการอยู่แล้วแทบทั้งหมด

    • ปัญหาคือความเร็วและทรัพยากรที่ใช้ในการ encode/decode

  • ตอนนี้ codec ภาพแบบ lossless ที่ดีที่สุดคือ HALIC

    • ดูการถกเถียงเพิ่มเติม: HN HALIC discussion

  • แต่ดูจาก เธรดพูดคุย HALIC แล้ว ในทางปฏิบัติ LEA 0.5 ดูจะดีกว่า

    • ใน benchmark การบีบอัดภาพแบบ lossless HALIC ก็ไม่ได้อยู่ระดับบนสุด

  • พูดตรง ๆ คือก่อนหน้านี้เข้าใจผิดและมองข้าม JPEG XL ไปพักหนึ่ง เพราะคิดว่าใช้สำหรับ "ภาพขนาดยักษ์" เท่านั้น

  • ฉันใช้ png ในเครื่องมือ annotation ภาพสำหรับคอมพิวเตอร์วิทัศน์ (XLabel)

    • เก็บ class label ไว้ใน metadata ของภาพโดยตรง ทำให้ไม่ต้องมีไฟล์ข้อความแยกต่างหาก
    • ต่อไปอยากทำฟอร์แมตส่วนขยายที่เหมาะกับการใช้งานแบบนี้

  • lossless compression ของ WebP อยู่ในระดับดีที่สุดของอุตสาหกรรม แต่กลับไม่ได้ถูกใช้อย่างแพร่หลาย

    • สะท้อนว่าไม่ใช่แค่การมีประสิทธิภาพสูงสุดในด้าน lossless compression เท่านั้นที่สำคัญ แต่การยอมรับใน ecosystem ต่างหากที่เป็นโจทย์ใหญ่กว่า

  • ปัญหาความเร็ว encode/decode อาจดีขึ้นได้เมื่อเวลาผ่านไป

    • เรื่องนี้เคยเกิดขึ้นจริงใน ecosystem ของ jpg มาก่อน

• ข่าวดีที่สุดคือมีการรองรับข้อมูล Exif อย่างเป็นทางการแล้ว

  • ก่อนหน้านี้ก็เขียนข้อมูลแบบกำหนดเองไว้ใน header ได้อยู่แล้ว แต่การรองรับ Exif นั้นน่ายินดีมาก

  • อีกเรื่องคือสงสัยว่าใน Exif มีฟิลด์เกี่ยวกับ gyroscope (การหมุน) หรือ acceleration (แรงโน้มถ่วง) หรือไม่

    • เพราะรูปที่ถ่ายจากแอป Google Camera ไม่มีข้อมูลพวกนี้ ทำให้บางครั้งเสียดายเมื่อต้องใช้กับการปรับแก้อัตโนมัติภายหลังหรือการต่อภาพพาโนรามา

  • มีฟิลด์สำหรับ acceleration (Exif.Photo.Acceleration) และฟิลด์สำหรับความสูง (Exif.Photo.CameraElevationAngle) แต่ไม่ได้รองรับครบทั้ง 3 แกน

    • มีข้อมูลจาก environmental sensor (สภาพแวดล้อมโดยรอบ) อยู่บ้าง แต่สะท้อนเฉพาะรายการที่ผู้เขียนสเปกระบุไว้
    • Exif.Photo.MakerNote เป็นพื้นที่อิสระที่ผู้ผลิตสามารถเก็บข้อมูลอะไรก็ได้ตามต้องการ และมีขนาดกว้างพอจะบันทึกข้อมูล 9 แกนได้สบาย

  • Exif อาจทำให้การจัดการการหมุนระหว่างการเรนเดอร์ภาพเกิดความสับสน

    • decoder รุ่นเก่าและรุ่นใหม่อาจแสดงภาพต่างกัน ขึ้นอยู่กับว่าจะใช้ค่า rotation จาก Exif หรือไม่
    • เนื่องจากไม่มีคำแนะนำเฉพาะสำหรับ decoder เรื่อง Exif rotation จึงเกิดบั๊กอย่างการหมุนซ้ำซ้อนบ่อยครั้ง (เช่น เดสก์ท็อปกับไลบรารีจัดการกันคนละชั้น)
    • มีเพียงข้อความแนะนำกำกวมทำนองว่า "ถ้า decoder ไม่อาจรู้แยกได้ว่า Exif data เชื่อถือได้หรือไม่ ก็ควรถือว่ามีค่าเพียงเชิงบันทึกข้อมูล"
    • จึงคิดว่าถ้าจะให้เข้ากันได้ย้อนหลังอย่างสมบูรณ์ ควรมีคำสั่งที่ชัดเจนแบบ "ห้ามหมุนโดยเด็ดขาด"

  • ไม่มีฟิลด์มาตรฐานสำหรับบันทึกข้อมูลจาก accelerometer หรือ inertial navigation unit ของกล้อง

    • รายการฟิลด์ Exif: คำอธิบายแท็กอย่างเป็นทางการของ exiv2

  • ในความเป็นจริง เว็บไซต์จำนวนมากลบข้อมูล Exif ส่วนใหญ่ออกตอนอัปโหลด

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

  • โดยส่วนตัวอยากให้คนหันไปใช้ XMP แทน Exif

    • Exif มีโครงสร้างประหลาด และโดยแก่นแล้วเหมือนฝังภาพ TIFF ไว้ภายใน PNG

• สเปก PNG ครั้งนี้เป็นการทำสิ่งที่ใช้กันอย่างแพร่หลายอยู่แล้วให้เป็นข้อกำหนดทางการ

  • codec ที่ดีที่สุดต้องใช้งานได้ทุกที่ ไม่ว่าในแอปใด, OS shell, API หรือ Linux

  • ฟอร์แมตอย่าง HEIC หรือ AV1 ถ้าไม่มีการรองรับในระดับ OS ก็แทบจะดูตัวอย่างไฟล์ยังลำบาก

  • ฟอร์แมตที่ยังไม่แพร่หลายจริง ไม่ควรกลายเป็นค่าปริยายของแพลตฟอร์ม

  • ฉันทำงานที่ต้องรองรับฟอร์แมตภาพหลายชนิด รวมถึงฟอร์แมตหายากที่ใช้กันเฉพาะทางด้วย

    • การรองรับฟอร์แมตจำนวนมากอย่างแท้จริงเป็นความท้าทายใหญ่มาก
    • แม้ไลบรารีจะเขียนไว้ผิวเผินว่ารองรับ jpg/tif/heic แต่เอาเข้าจริง ถ้าเป็น jpeg ขนาด 30GB หรือ metadata ครบทุกแบบจะรองรับได้หมดโดยไม่มีปัญหาหรือไม่ ก็ไม่ใช่

  • สเปกใหม่นี้อาจสร้างความสับสนมากกว่า HEIC หรือ AV1 เสียอีก

    • เพราะไม่สามารถรู้ได้เลยว่าข้างใน PNG ใช้ codec อะไร จนกว่าจะเปิดไฟล์ดู

• นี่เป็นครั้งแรกที่เห็นคำว่า HDR ถูกใช้ในความหมายว่า "gamut สีที่กว้างขึ้น" ไม่ใช่การขยายช่วงความสว่าง/คอนทราสต์อย่างชัดเจน

• สงสัยว่ามันสายเกินไปหรือเปล่า

  • และ JPEG XL ก็มีทุกฟีเจอร์อยู่แล้ว (compression แบบ lossy/lossless, animation, HDR, Exif ฯลฯ) รวมถึงเทคนิคการบีบอัดขั้นสูง (finite-state symbol entropy, ZStandard เป็นต้น)

  • เลยคิดว่าไม่จำเป็นต้องอัปเดต PNG แยกต่างหาก แค่ใช้ JPEG XL ไปเลยก็พอ

  • แต่ความจริงคือแนวคิดแบบ "แค่ยอมรับใช้งานก็จบ" นั้นใช้ไม่ได้

    • สถานะการรองรับ JPEG XL บนเบราว์เซอร์: ผ่านมา 5 ปีแล้ว แต่ยังมีเบราว์เซอร์ที่รองรับอยู่เพียงเจ้าเดียว
    • หากผู้ผลิตเบราว์เซอร์ไม่ implement นักพัฒนาและผู้ใช้ก็ไม่มีทางใช้ฟอร์แมตใหม่ได้จริง

  • เกี่ยวกับคำว่า "เทคนิคการบีบอัดขั้นสูง (ZStandard เป็นต้น)"

    • ZStandard อาจไม่เหมาะนักกับการบีบอัดตัวเลขที่มีการเปลี่ยนแปลงอย่างสม่ำเสมอ (เช่น gradient)
    • Bzip2 อาจทำได้ดีกว่าในด้านนี้ และจะเหมาะยิ่งขึ้นเมื่อมีตัวแปรสองชั้น (ลูปชั้นในและชั้นนอก) ที่สอดคล้องกับ color channel อย่างในตัวอย่าง
    • แน่นอนว่าข้อมูลจริงซับซ้อนกว่านั้นเพราะมี noise แต่การเปรียบเทียบอัลกอริทึมแบบนี้ก็ยังไม่ตรงกับสภาพจริงทั้งหมด
      • ดูเพิ่มเติม: บทสนทนาที่เกี่ยวข้องบน Mastodon

  • สำหรับความเห็นว่า "ไม่ต้องอัปเดต PNG แค่ยอมรับ JPEG XL ก็พอ"

    • ถ้าอย่างนั้นคงต้องไปบอก Google
    • เพราะ Google เลิกสนับสนุน JPEG XL ใน Chrome ไปแล้วจริง ๆ (ประเด็นที่เกี่ยวข้อง) ซึ่งทำให้การขยาย ecosystem ติดขัด

  • ไม่เข้าใจว่าทำไมต้องสร้างมาตรฐาน (หรืออนุพันธ์) ใหม่เพิ่มอีก

    • ทั้งที่ทุกอย่างก็สับสนพออยู่แล้ว แต่ก็ยังมีมาตรฐานใหม่ที่ไม่มีจุดขายเฉพาะตัวเพิ่มมาเรื่อย ๆ

• ตอนนี้อาจแทนที่ GIF ด้วย APNG (alpha blending + transparent background + lossless compression) ได้แล้ว ทำให้บรรยากาศเว็บยุค 2000s กลับมาอีกครั้ง

  • เลยสงสัยว่ามี Animated SVG ที่เป็นมาตรฐานหรือไม่

    • เคยเห็น SVG animation แบบใช้ JavaScript มาก่อน (เช่น อวตารแชตบอต) แต่ไม่แน่ใจว่ามีเฟรมเวิร์กมาตรฐานหรือเปล่า

  • Animated SVG มีอยู่

    • องค์ประกอบหลักของ SVG animation คือ set, animate, animateTransform, animateMotion
    • อธิบายเพิ่มเติม: ข้อมูลเกี่ยวกับ SVG animation

  • เข้าใจว่าปัจจุบันวิดีโอแบบไม่มีเสียง (เช่น mp4) ถูกใช้แทน GIF มากขึ้นเพราะบีบอัดได้ดีกว่า

    • เลยสงสัยว่า Animated PNG ยังแข่งขันกับฟอร์แมตวิดีโออย่าง AV1 ได้หรือไม่

  • บริการส่วนใหญ่ที่รองรับการอัปโหลด GIF แทบไม่รองรับ APNG หรือ animated WEBP เลย

    • การรองรับฝั่งแบ็กเอนด์ใกล้เคียงกับศูนย์จนรู้สึกหงุดหงิดมาก

  • ถ้าแปลงคลิปสั้นเป็นกราฟิกแอนิเมชัน เดิมที WEBP ดีกว่า APNG อยู่แล้ว

    • แต่ถ้าใช้ GIF เป็นฟอร์แมตกลาง APNG ก็ยังพอแข่งขันได้
    • ทุกวันนี้ AVIF เป็นตัวเลือกที่ดีที่สุด

  • เมื่อหลายปีก่อนเคยใช้ไลบรารี Lottie (Bodymovin)

    • ทำแอนิเมชันใน Adobe After Effects แล้ว export เป็น svg และ json จากนั้นใช้ lottie JS เพื่อใส่แอนิเมชันบนเว็บได้ง่าย
    • รู้สึกว่ายังขาดเครื่องมือหรือ DX (ประสบการณ์นักพัฒนา) ที่ดีสำหรับเว็บแอนิเมชันแบบเวกเตอร์
    • เลยอยากรู้ด้วยว่าฝั่ง animated PNG มีเครื่องมือและ DX เป็นอย่างไรบ้าง

• ใน PR มีการอ้างว่า "โปรแกรมจำนวนมากรองรับสเปก PNG ใหม่อยู่แล้ว" แต่

  • ข้อความที่บอกว่า Photoshop รองรับ APNG นั้นไม่ถูกต้อง

    • ทั้งที่การรู้จัก APNG อยู่เป็นหัวข้อที่สองใน What's new แต่พอลองจริงกลับไม่รองรับใน Photoshop ทำให้ผิดหวังมาก

  • Photoshop รองรับส่วน HDR แต่ไม่รองรับส่วน APNG

• มีคนพูดถึงว่ามนุษย์ควรมีวิธีจัดการความไม่แน่นอนของข้อมูลเวลา/วันที่ในซอฟต์แวร์ให้สอดคล้องกัน

  • เช่นข้อมูลเวลาแบบคลุมเครืออย่าง "ภาพสแกนในปี 2025, เนื้อหาอยู่ราวช่วงอีสเตอร์, ระหว่างปี 1920~1940"

  • ใน EXIF มีฟิลด์ DateTimeDigitized อยู่

    • และสำหรับการระบุวันที่แบบคลุมเครือนั้นก็มีสเปก EDTF
      • อ้างอิง: คำอธิบายฟิลด์ EXIF, เอกสารทางการของสเปก EDTF

  • ใน Google Photos และ Apple Photos สามารถกำหนดวันที่เองได้ แต่ไม่ได้บันทึกกลับไปใน EXIF จริง

    • เวลาย้ายแพลตฟอร์ม รูปที่ไม่มี EXIF จึงมักสูญเสียข้อมูลวันที่ไปด้วย