Phát hành đặc tả PNG mới

• Định dạng tệp PNG được sửa đổi lớn lần đầu sau 20 năm, lấy lại vị thế trước đây
• Đặc tả lần này phản ánh nhiều công nghệ hiện đại như hỗ trợ HDR, APNG (ảnh động), dữ liệu Exif dưới dạng hỗ trợ chính thức
• Các công ty IT lớn như Adobe, Apple, Google cùng các đơn vị phát sóng đã cùng tham gia phát triển
• Đặc tả mới nhất đã được Chrome, Safari, Photoshop và nhiều chương trình khác hỗ trợ
• Trong tương lai còn có kế hoạch cập nhật thêm như công nghệ nén tốt hơn và mã hóa/giải mã song song

---

Mở đầu: Sự trở lại và tầm quan trọng của PNG

• Gần đây, định dạng tệp PNG đã vượt qua gần 20 năm đình trệ để được cập nhật bằng một đặc tả mới
• PNG đang được các tổ chức lớn như Thư viện Quốc hội Mỹ, Thư viện và Lưu trữ Canada, Cơ quan Lưu trữ Quốc gia Úc lựa chọn làm định dạng khuyến nghị chính thức
• Thông qua đặc tả mới, PNG giành lại sức cạnh tranh trên thị trường và cho thấy tính đổi mới

Tính năng và đặc điểm mới

Hỗ trợ HDR phù hợp và khả năng tương thích trong tương lai

• PNG mới cung cấp hỗ trợ HDR (High Dynamic Range)
• Trong hình ảnh so sánh không gian màu Rec. 2020 và Rec. 709, vùng rộng hơn (tam giác bên ngoài) cho thấy dải màu mà ảnh HDR có thể biểu diễn
• Thông tin HDR này chỉ cần thêm 4 byte (cùng phần overhead chunk PNG hiện có)
• Các tác giả ban đầu và chuyên gia kỹ thuật chủ chốt như Chris Lilley đã tham gia để giải thích rõ ràng công nghệ mới

APNG (Animated PNG) được công nhận chính thức

• Animated PNG (APNG), ban đầu do Mozilla đề xuất và được Firefox hỗ trợ, nay cũng đã được đưa vào đặc tả chính thức
• Trước đây chỉ một phần mềm số ít hỗ trợ, nhưng hiện đã được chấp nhận rộng rãi trong nhiều chương trình khác nhau

Hỗ trợ chính thức cho dữ liệu Exif

• Thông qua Exif, có thể lưu metadata như bản quyền, thông tin máy ảnh, thông tin GPS
• Điều này mang lại hiệu quả cao trong tạo ảnh, lưu trữ và quản lý bản quyền

Cải tiến tổng thể và sửa lỗi

• Việc sửa lỗi (Errata) và làm rõ đặc tả cũ cũng được thực hiện cùng lúc

Bối cảnh và quá trình phát triển

• Đặc tả PNG trước đó được công bố cách đây khoảng 20 năm (trước khi iPhone ra mắt 3 năm rưỡi)
• Việc phát triển được khởi động lại khi W3C Timed Text Working Group (nhóm tiêu chuẩn hóa công nghệ phụ đề) nêu ra nhu cầu hỗ trợ HDR cho PNG
• Sau khi đề xuất được đưa ra, các công ty công nghệ lớn như Adobe, Apple, BBC, Google, MovieLabs, W3C đã cùng tham gia
• Một liên minh mạnh đã được hình thành để đưa PNG trở thành định dạng hình ảnh thế hệ tiếp theo
• Hiện tại, hai bản cập nhật tiếp theo cũng đã được chuẩn bị sẵn

Tình hình đã được áp dụng rộng rãi

• Đặc tả PNG mới nhất đã được hỗ trợ trong nhiều chương trình như Chrome, Safari, Firefox, iOS/macOS, Photoshop, DaVinci Resolve, Avid Media Composer
• Hỗ trợ cũng đang mở rộng trong các đơn vị phát sóng và phần cứng, công cụ liên quan
• Các hình ảnh phát sóng như thanh cuộn tin tức, banner tỷ số thể thao là ví dụ sử dụng PNG HDR mới

Kế hoạch sắp tới

• Ở bản tiếp theo, có kế hoạch cải thiện hơn nữa khả năng tương thích giữa HDR & SDR
• Ngoài ra, phương thức nén tốt hơn và mã hóa/giải mã song song cũng đang được thúc đẩy
• Phiên bản thứ tư dự kiến sẽ là một bản cập nhật tương đối ngắn, sau đó phiên bản thứ năm sẽ được phát triển dựa trên nghiên cứu về công nghệ nén

[carnoxen]

Ban đầu cộng đồng đã từ chối APNG vì cho rằng nó không phải là tiêu chuẩn cho hình ảnh, giờ thì cuối cùng cũng đã công nhận rồi nhỉ.

[GN⁺]

Ý kiến Hacker News

• Tự nhận là tác giả và cho biết luôn sẵn sàng trả lời mọi câu hỏi

  • Nhấn mạnh rằng lần này PNG không phải là một định dạng hoàn toàn mới mà là phiên bản cập nhật của định dạng hiện có

  • Khẳng định khả năng tương thích ngược rất cao

  • Giải thích rằng ngay cả các chương trình cũ cũng có thể đọc các tệp PNG mới tốt nhất có thể, ví dụ vẫn nhận ra đó là ảnh một quả táo đỏ

  • Cho rằng có thể có sự nhầm lẫn về cách PNG hoạt động bên trong nên tóm tắt các ý chính

    • Tệp PNG được cấu thành từ nhiều chunk dữ liệu khác nhau
    • Mỗi chunk có tên riêng nên chương trình có thể bỏ qua những chunk mà nó không biết hoặc không cần
    • Nêu rõ chỉ tồn tại đúng một luồng hình ảnh

  • Bày tỏ mong muốn có các tệp mẫu sử dụng tính năng của đặc tả PNG mới, đặc biệt là một trang demo cho phép tải trực tiếp ảnh động hoặc ảnh HDR để thử khả năng tương thích của chương trình

  • Tôi ủng hộ meta-format và bộ công cụ dùng chung

    • Lấy ví dụ như Office Open XML hay ePub, chỉ cần có thư viện zip và XML là có thể parse được
    • Cho biết PNG cũng có cấu trúc gần giống Interchange File Format (sau đây gọi là IFF), nhưng trước đây tiêu chuẩn hơi khác biệt nên theo kinh nghiệm của bản thân, không thể dùng một parser IFF hoàn toàn phổ dụng để đồng thời parse PNG và các tệp họ IFF
    • IFF dễ triển khai và có ưu điểm về nén dữ liệu, nhưng từ trước tới nay chủ yếu chỉ được dùng cho dữ liệu game cũ, audio AIFF·RIFF và các mục đích hạn chế khác; đồng thời chỉ ra việc PNG và IFF không tương thích là một trong những lý do khiến không xuất hiện tooling phổ dụng
    • Bày tỏ hy vọng rằng nếu PNGv3 khiến tệp PNG chính thức trở thành tệp IFF, thì dựa trên độ phổ biến của PNG, hệ sinh thái IFF phổ dụng (ví dụ như libiff) có thể mở rộng và còn dùng để định nghĩa các định dạng mới
    • Đề cập đã tự viết parser PNG/IFF và nói rằng không dễ chỉ sửa PNG để có tương thích IFF, đồng thời vẫn phải giữ tương thích ngược, nhất là với parser phần cứng
    • Tôi đề xuất tài liệu hóa riêng cấu trúc IFF biến thể mà PNG đang dùng như một tiêu chuẩn meta-format mới, tức IFF 2.0
    • Mong muốn IFF 2.0 sẽ chính thức hóa một profile tương thích với PNGv2, cùng các profile bao phủ cả IFFv1 như AIFF/RIFF để thúc đẩy tooling IFF phổ dụng
    • Xa hơn nữa, trong một profile greenfield mới dành cho môi trường hiện đại, có thể đưa vào ví dụ như kiểm tra toàn vẹn bằng hash hiện đại thay cho CRC, mở rộng bộ ký tự tên chunk, và cấu trúc lưu metadata thuộc tính của từng chunk một cách hiệu quả
    • Cho rằng các cấu trúc này nên cho phép transcode cả IFFv1 lẫn PNGv2, và cách tuyên bố profile mang tính chiến lược như HTML5 kết hợp và tương thích với HTML4 cùng XHTML là điều đáng mong muốn
    • Kết luận rằng trọng tâm là mục tiêu thiết kế, tức giảm tối đa sự dị biệt giữa định dạng cũ và mới cũng như mở rộng hệ sinh thái công cụ, hơn là các chi tiết nhỏ

• Trong công cụ vẽ web của tôi, tôi dùng một mẹo là lưu biểu diễn JSON của tài liệu vào trường chú thích của PNG

  • Làm vậy thì tệp đã lưu có thể dùng ngay như một hình ảnh, đồng thời cũng có thể nạp lại vào editor

  • Ưu điểm là thư mục tải xuống không bị chất đầy những tệp JSON khó nhận biết

  • Khá thú vị, nhưng lại hơi khó giải thích cho người dùng vì sao tệp được lưu thành .png, hoặc vì sao khi mở rồi lưu lại bằng Paint chẳng hạn thì dữ liệu bị mất

  • Krita cũng lưu thiết lập cọ theo cách này, nhưng khi dữ liệu quá lớn thì có thể gây ra những vấn đề ngoài dự kiến

    • Vấn đề liên quan: Krita-Brushes issue #4, Memileo Impasto Brushes discussion

  • Macromedia Fireworks đã dùng PNG làm định dạng lưu mặc định từ 20 năm trước

    • Tất nhiên khi đó không phải để nhét JSON vào

  • Nhiều frontend tạo ảnh AI cũng dùng cách tương tự

    • Chúng lưu prompt hoặc thiết lập trong comment của ảnh, để chỉ cần mở ảnh là có thể lấy lại cấu hình hoặc nạp cả workflow như ComfyUI
    • Thực ra tôi nghĩ các công cụ xử lý ảnh dùng kiểu này khá phổ biến

  • Macromedia Fireworks lưu tệp Fireworks trong PNG,

    • còn tệp Illustrator(AI) của Adobe thực chất là PDF,
    • và tệp PSD của Photoshop cũng có thể được lưu bên trong TIFF
    • Vì vậy trong Photoshop có thể thấy nhiều layer, nhưng ở phần mềm khác thì chỉ hiện một layer duy nhất

• Đặc tả này gần như là việc chính thức hóa những gì đã được triển khai rộng rãi

  • Dù gọi là PNG thế hệ tiếp theo, nếu cần decoder mới thì có lẽ gọi là PNG2 cũng được

  • JPEG-XL đã đáp ứng phần lớn những điều mọi người muốn ở một codec lossless

    • Vấn đề là tốc độ và tài nguyên cho encode/decode

  • Hiện tại codec ảnh lossless tốt nhất là HALIC

    • Thảo luận chi tiết: HN HALIC discussion

  • Nhưng xem chuỗi thảo luận HALIC thì thực tế LEA 0.5 còn tốt hơn

    • Trong benchmark nén ảnh lossless, HALIC không nằm ở nhóm dẫn đầu

  • Thành thật mà nói, trước đây tôi từng nghĩ JPEG XL chỉ dành cho “ảnh siêu lớn” nên đã bỏ qua nó một thời gian

  • Tôi dùng png trong công cụ annotation ảnh thị giác máy tính (XLabel)

    • Có thể lưu trực tiếp nhãn lớp vào metadata của ảnh nên không cần để riêng các tệp văn bản
    • Sau này tôi muốn tạo một định dạng mở rộng phù hợp với mục đích như vậy

  • Nén lossless của WebP thuộc hàng đầu ngành nhưng vẫn không được dùng rộng rãi

    • Điều đó cho thấy điều quan trọng không hẳn là đạt hiệu năng lossless tốt nhất, mà bài toán lớn hơn là được hệ sinh thái chấp nhận

  • Vấn đề tốc độ encode/decode có thể được cải thiện theo thời gian

    • Đây là điều từng thực sự xảy ra trong hệ sinh thái jpg trước đây

• Tin tốt nhất là hỗ trợ dữ liệu Exif cuối cùng đã được phản ánh chính thức

  • Trước đây cũng có thể ghi dữ liệu tùy chỉnh vào header, nhưng hỗ trợ Exif là rất đáng hoan nghênh

  • Nhân tiện cũng thắc mắc liệu Exif có trường nào liên quan đến con quay hồi chuyển (xoay) hoặc gia tốc kế (trọng lực) hay không

    • Ảnh chụp bằng ứng dụng Google Camera thiếu kiểu thông tin này, nên về sau khá tiếc khi cần tự động hiệu chỉnh hoặc ghép panorama

  • Có trường gia tốc kế (Exif.Photo.Acceleration) và trường dành cho độ cao góc máy ảnh (Exif.Photo.CameraElevationAngle),

    • nhưng không hỗ trợ đủ cả 3 trục
    • Có cả cảm biến môi trường, nhưng chỉ phản ánh các mục cụ thể mà người viết đặc tả chỉ định
    • Exif.Photo.MakerNote là vùng tự do để nhà sản xuất lưu thông tin họ muốn, và giới hạn dung lượng đủ lớn để ghi cả dữ liệu 9 trục

  • Exif có thể gây ra nhầm lẫn trong cách xử lý xoay khi render ảnh

    • Decoder cũ và mới có thể hiển thị ảnh khác nhau tùy có xử lý xoay Exif hay không
    • Vì không có khuyến nghị cụ thể cho decoder về xoay Exif nên các lỗi xoay hai lần, ví dụ desktop environment và thư viện cùng tự xử lý, xảy ra khá thường xuyên
    • Chỉ có một câu khuyến nghị mơ hồ kiểu như “nếu decoder không thể biết riêng liệu dữ liệu Exif có đáng tin hay không, thì Exif chỉ nên được xem là thông tin mang giá trị ghi chép”
    • Để tương thích ngược hoàn toàn, tôi nghĩ cần một chỉ dẫn rõ ràng như “tuyệt đối không xoay”

  • Không có trường tiêu chuẩn nào để ghi dữ liệu từ gia tốc kế hay hệ thống dẫn đường quán tính của camera

    • Danh sách trường Exif: mô tả tag chính thức của exiv2

  • Thực tế nhiều website xóa phần lớn dữ liệu Exif khi tải ảnh lên

    • Vì một số trường có thể bị lạm dụng cho quyền riêng tư hoặc theo dõi vị trí

  • Cá nhân tôi mong mọi người dùng XMP thay vì Exif

    • Exif có cấu trúc kỳ quặc và về bản chất giống như nhét một ảnh TIFF vào bên trong PNG

• Đặc tả PNG lần này chính thức hóa những cách làm vốn đã được dùng rộng rãi

  • Codec tốt nhất phải hoạt động ở mọi nơi, trong bất kỳ ứng dụng nào, từ OS shell, API cho đến Linux

  • Các định dạng như HEIC hay AV1 nếu không có hỗ trợ ở cấp hệ điều hành thì thậm chí rất khó preview tệp

  • Một định dạng không lưu hành đúng nghĩa thì không nên trở thành mặc định của nền tảng

  • Tôi làm công việc phải xử lý nhiều định dạng ảnh, kể cả những định dạng hiếm chỉ dùng trong các lĩnh vực cụ thể

    • Việc thật sự hỗ trợ đa dạng định dạng là một thách thức rất lớn
    • Nhiều thư viện bề ngoài ghi là hỗ trợ jpg/tif/heic, nhưng nếu hỏi có xử lý ổn cả jpeg 30GB hay hỗ trợ đầy đủ mọi metadata hay không thì lại không hẳn

  • Đặc tả mới này thậm chí có thể còn gây rối hơn HEIC hay AV1

    • Không mở tệp ra thì hoàn toàn không biết bên trong PNG đang dùng codec nào

• Đây là lần đầu tôi thấy HDR được dùng theo nghĩa “không gian màu rộng hơn” chứ không phải theo nghĩa mở rộng độ sáng/tỷ lệ tương phản một cách rõ ràng

• Không biết có phải đã quá muộn hay chưa

  • Và JPEG XL vốn đã có đủ mọi tính năng như nén lossy/lossless, animation, HDR, Exif, cùng các kỹ thuật nén tiên tiến như finite state entropy, ZStandard

  • Tôi nghĩ không cần cập nhật PNG riêng nữa, cứ dùng JPEG XL là được

  • Nhưng thực tế “chỉ cần được chấp nhận” lại không đơn giản

    • Tình trạng hỗ trợ JPEG XL trên trình duyệt: đã 5 năm trôi qua nhưng mới chỉ có một trình duyệt hỗ trợ
    • Nếu nhà cung cấp trình duyệt không triển khai thì lập trình viên hay người dùng cũng không thể dùng định dạng mới, đó là thực tế

  • Về nhắc đến “kỹ thuật nén tiên tiến (ZStandard v.v.)”

    • ZStandard có thể lại không phù hợp để nén các con số có biên độ thay đổi đều đặn, ví dụ gradient
    • Bzip2 tốt hơn ở khía cạnh này, và phù hợp hơn khi hai biến số, tức lặp bên trong và bên ngoài như ví dụ, tương ứng với các kênh màu
    • Dữ liệu thực tế không đơn giản như vậy vì có nhiễu, nhưng những so sánh thuật toán kiểu này vẫn khác thực tế
      • Tham khảo: thảo luận Mastodon liên quan

  • “Không cần cập nhật PNG, cứ chấp nhận JPEG XL là được”

    • Vậy thì nên nói chuyện đó với Google
    • Thực tế Google đã từ bỏ hỗ trợ JPEG XL trong Chrome (vấn đề liên quan), và điều này làm chặn đà mở rộng của hệ sinh thái

  • Tôi không hiểu vì sao lại tạo thêm một tiêu chuẩn khác, hay một biến thể phái sinh nữa

    • Mọi thứ vốn đã đủ rối rồi, vậy mà vẫn chỉ liên tục thêm những tiêu chuẩn mới không có điểm bán hàng độc đáo

• Giờ thì có thể thay GIF bằng APNG (alpha blending + nền trong suốt + nén lossless), nên cảm giác web của thập niên 2000 có thể sống lại

  • Không biết Animated SVG có tiêu chuẩn hay không

    • Trước đây tôi từng thấy SVG animation dựa trên JavaScript, kiểu avatar chatbot, nhưng không rõ có framework tiêu chuẩn nào không

  • Animated SVG là có tồn tại

    • Các phần tử animation chính của SVG: set, animate, animateTransform, animateMotion
    • Giải thích chi tiết: tài liệu về SVG animation

  • Tôi hiểu là ngày nay thay vì GIF, video không tiếng như mp4 được dùng nhiều hơn vì nén tốt hơn

    • Không rõ Animated PNG có còn sức cạnh tranh so với các định dạng video như AV1 hay không

  • Phần lớn dịch vụ hỗ trợ tải lên GIF gần như không hỗ trợ APNG hay animated WEBP

    • Hỗ trợ backend gần như bằng 0 nên rất bức bối

  • Khi chuyển video ngắn thành đồ họa động, WEBP vốn đã tốt hơn APNG

    • Nếu dùng GIF làm định dạng trung gian thì APNG còn có chút khả năng cạnh tranh
    • Còn hiện nay AVIF là lựa chọn tốt nhất

  • Vài năm trước tôi từng dùng thư viện Lottie (Bodymovin)

    • Tạo animation trong Adobe After Effects, xuất ra svg và json rồi dùng lottie JS để áp dụng animation dễ dàng trên web
    • Tôi cảm thấy công cụ và DX cho web animation dạng vector vẫn còn thiếu
    • Cũng tò mò về công cụ và DX phía animated PNG

• Trong PR có khẳng định rằng “nhiều chương trình đã hỗ trợ đặc tả PNG mới”

  • Nhưng việc nói Photoshop hỗ trợ APNG là sai

    • Dù nhận diện APNG là mục thứ hai trong phần What's new, nhưng thực tế Photoshop không hỗ trợ nên khá thất vọng

  • Photoshop có hỗ trợ phần HDR, nhưng không hỗ trợ phần APNG

• Có người nhắc đến việc con người cần quản lý sự không chắc chắn về ngày giờ theo cách nhất quán bằng phần mềm

  • Sự cần thiết phải quản lý thông tin thời gian mơ hồ như “ảnh được scan năm 2025, nội dung vào khoảng lễ Phục sinh, trong giai đoạn 1920~1940”

  • EXIF có trường DateTimeDigitized

    • Với biểu diễn ngày tháng mơ hồ thì có đặc tả EDTF
      • Tham khảo: giải thích trường EXIF, tài liệu chính thức đặc tả EDTF

  • Google Photos và Apple Photos cho phép đặt ngày trực tiếp, nhưng thực tế lại không lưu vào EXIF

    • Khi chuyển nền tảng, các ảnh không có EXIF sẽ gặp vấn đề là thông tin ngày tháng cũng biến mất theo