Chromium hợp nhất JpegXL

 (chromium-review.googlesource.com)
2 điểm bởi GN⁺ 2026-01-14 | 1 bình luận | Chia sẻ qua WhatsApp
  • Bộ giải mã JpegXL đã được tích hợp vào codebase của Chromium, cho phép trình duyệt xử lý hình ảnh định dạng JXL
  • Có thể xem thay đổi này trên trang review mã Gerrit với tiêu đề “Wire up JXL decoder”
  • Việc hợp nhất này là bước cốt lõi để hỗ trợ định dạng JpegXL, bao gồm công việc kết nối bộ giải mã
  • Review mã được đăng ký là thay đổi trong kho src của Chromium (7184969)
  • Điều này có ý nghĩa ở chỗ mở rộng hỗ trợ các định dạng ảnh thế hệ mới trong trình duyệt web

Tích hợp bộ giải mã JpegXL của Chromium

  • Mục review mã Gerrit “Wire up JXL decoder (7184969)” là thay đổi nhằm kết nối bộ giải mã JpegXL vào dự án Chromium
    • Thay đổi này được thực hiện trong kho src của Chromium
    • Nền tảng review mã sử dụng chromium-review.googlesource.com
  • Đúng như tiêu đề, đây là công việc kết nối (wire up) bộ giải mã JXL (JpegXL) vào bên trong trình duyệt
  • Trang này không hiển thị mô tả bổ sung hay chi tiết mã nguồn, chỉ có thể xác nhận tiêu đề thay đổi

Bối cảnh kỹ thuật

  • JpegXL là định dạng nén ảnh thế hệ mới, hướng tới cải thiện hiệu quả so với JPEG hiện tại (không được nhắc trực tiếp trong nguyên văn, chỉ xuất hiện tên công nghệ)
  • Việc bộ giải mã được hợp nhất vào Chromium tạo nền tảng để kích hoạt khả năng xử lý ảnh JXL ở cấp độ mã nguồn
  • Thay đổi này là một bước tiến kỹ thuật liên quan đến việc mở rộng hệ thống giải mã media của engine trình duyệt

Trạng thái tài liệu

  • Trang được hiển thị dưới dạng snapshot đã được cache của review mã Gerrit
  • Có kèm cảnh báo rằng shadow DOM đang bị ẩn, nhưng nội dung mã thực tế không được hiển thị
  • Vì vậy, thông tin có thể xác nhận từ tài liệu này chỉ gồm tiêu đề thay đổi và mã định danh review (7184969)

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-01-14
Ý kiến trên Hacker News

  • Tôi đã xem bài viết trên blog của Cloudinary, đây là một bài kinh điển cũ so sánh webp, jpegxl, avif, jpeg, v.v.
    Biểu đồ được trình bày rất rõ ràng, và AVIF cực kỳ chậm

    • Khi đặt JPEG ở mức chất lượng thấp nhất thì trong trường hợp này lại trông đẹp hơn nhiều
      Liên kết đến phần liên quan
    • Tôi không rõ chính xác trang này đang cố làm gì
      Xem ảnh chụp màn hình
    • Nếu như câu được trích dẫn nói rằng JPEG XL hiện đã củng cố vị thế là codec tốt nhất cho cả nén mất dữ liệu/lossless, thì đây là một bước tiến lớn có thể thay thế cả JPEG lẫn PNG bằng một định dạng duy nhất
    • Tuy nhiên, bài test này không sử dụng bộ mã hóa/giải mã có tăng tốc phần cứng

  • Thư viện jxl-rs là một bản triển khai JPEG XL bằng Rust
    Đây là dự án khá mới, nhưng nhờ Rust nên khiến người ta yên tâm hơn về độ an toàn bảo mật
    Thời điểm Chromium thảo luận trước đây thì chưa có thư viện này

    • Tôi nhớ lý do Google từ chối JPEG XL là vì “thiếu quan tâm”. Có vẻ không phải vì vấn đề bảo mật
    • Tôi không đồng ý với ý “Rust làm giảm bớt lo ngại bảo mật”. An toàn bộ nhớ không đồng nghĩa với bảo mật
      Rust có thể khiến người ta quá tự tin, dẫn đến bỏ qua việc mô hình hóa mối đe dọa
      Thậm chí một lập trình viên C cẩn thận còn có thể an toàn hơn
    • Tôi đã thử kiểm tra xem thực tế có bao nhiêu mã unsafe
      Liên kết kết quả tìm kiếm

  • Gần đây tôi đã so sánh WebP và AVIF, thì WebP mã hóa gần như tức thì, trong khi AVIF mất hơn 20 giây cho ảnh 1MP
    JXL hiện vẫn được hỗ trợ ít nên trên thực tế chưa dùng được, nhưng tôi kỳ vọng tốc độ ở mức WebP với chất lượng tốt hơn

    • rav1e đã ở trạng thái ngừng cập nhật suốt nhiều năm, nên tốt hơn là dùng các encoder như aom hoặc svt-av1
    • AVIF cần chỉnh tham số sử dụng CPU. Thiết lập mặc định dùng mức CPU quá cao nên mới chậm
      Trong môi trường của tôi, ảnh AVIF 2MP được tạo trong khoảng 100ms

  • Thật đáng tiếc khi đặc tả công khai (spec) của JPEG XL không thể truy cập tự do

    • Tôi nghĩ việc duy trì một tiêu chuẩn không công khai là điều đáng xấu hổ
    • Vấn đề nằm ở thực tế là rất nhiều tài liệu của các tổ chức như ISO, IEC lại nằm sau tường phí (paywall)

  • Chúng ta lại có thêm một định dạng ảnh mới nữa, và tôi lo rằng rồi sẽ lại lặp lại tình huống không dùng được nếu không chuyển đổi

    • Nhưng ngay cả Microsoft cũng đã phát hành add-on JPEG XL, và giờ khi Google đã lùi bước thì tôi nghĩ đây là một cơ hội thực sự
      Liên kết Microsoft Store
    • Trên thực tế đã có nhiều ứng dụng hỗ trợ rồi — Affinity, Photoshop, Microsoft Photos, Gimp, và thậm chí cả hỗ trợ toàn hệ thống trên iOS 17+/macOS 12+
      Chromium mới là bên chậm chân hơn
    • Tất nhiên, một định dạng mới lúc nào cũng cần khoảng 10 năm để được chấp nhận rộng rãi

  • Đọc danh sách tính năng của JPEG XL trên wiki thì thấy có những khả năng thú vị như ảnh đa kênh hay tài liệu nhiều trang
    Có điểm tốt, nhưng cũng tạo cảm giác ngày càng phức tạp giống TIFF

  • Giữa JPEG và JPEG-XL vẫn còn rất nhiều điểm chung
    Tôi tự hỏi liệu nếu một bản triển khai mới tích hợp luôn cả hỗ trợ JPEG hiện có thì có thể giảm kích thước mã nguồn hay không

    • Thực tế đã có issue mở cho tính năng đó trong kho lưu trữ Rust của JPEG-XL
      Liên kết issue #513

  • Cá nhân tôi vẫn muốn tiếp tục dùng JPEG hiện có hơn là các định dạng mới như WEBP
    Hầu hết chương trình đều hỗ trợ, và với người dùng phổ thông thì JPEG + PNG là đủ
    Ảnh động đơn giản thì dùng GIF, còn phức tạp hơn thì xử lý bằng video là được

    • “JPEG XL” trái với tên gọi không chỉ đơn thuần là phiên bản mở rộng của JPEG
      Nó có thể mã hóa lossless với dung lượng nhỏ hơn PNG, đồng thời hỗ trợ chuyển mã có thể phục hồi giúp nén JPEG hiện có thêm 20%
      Nó còn có nhiều tính năng như HDR, dải màu rộng, tải tiến dần, nên cũng rất lý tưởng cho truyền tải trên web
      Tham khảo jpegxl.info
    • WebP giờ có thể xem là định dạng tiêu chuẩn trên thực tế
      Mọi trình duyệt lớn đều hỗ trợ kể từ Safari 14, và nó cũng được tích hợp sẵn từ Windows 10 và macOS Big Sur trở đi
      Tham khảo tình trạng hỗ trợ, danh sách phần mềm
    • GIF giờ đã kém hiệu quả. Thay bằng video sẽ hiệu quả hơn từ 5 đến 10 lần
      Bài viết liên quan

  • Tôi đã nghe tranh luận về JPEG XL, WebP, AVIF từ lâu nhưng không hiểu lắm
    Nhìn benchmark thì JpegXL vượt WebP cả về tốc độ nén lẫn kích thước, nên tôi thắc mắc vì sao Chromium lại ngần ngại áp dụng

    • WebP và AVIF dùng chung mã với VP8/AV1 nên dễ tích hợp vào trình duyệt, trong khi JPEG-XL là codebase riêng nên gánh nặng triển khai lớn hơn
      Ngoài ra, libjxl là hơn 100.000 dòng C++, nên có nguy cơ lỗ hổng bảo mật
      Khi bản triển khai Rust dần trưởng thành hơn, có vẻ Chrome đang xem xét lại
    • JPEG XL hỗ trợ giải mã tiến dần
      Video demo
    • Google từng cho rằng “nếu có nhiều định dạng tương tự nhau thì chỉ làm tăng rủi ro bảo mật”, và AVIF một mình là đủ
    • AVIF tốt ở bpp thấp (chất lượng thấp) nhưng yếu ở lossless, trong khi JXL mạnh ở chất lượng cao và lossless
    • Trước đây thư viện C++ JPEGXL từng ở trạng thái ngừng bảo trì, nhưng khi bản Rust xuất hiện thì việc trình duyệt áp dụng mới trở nên khả thi

  • Tôi từng thắc mắc liệu JPEG XL có hỗ trợ ảnh động hay không

    • Có hỗ trợ, nhưng vì không có nén liên khung nên kém hiệu quả và dung lượng lớn hơn video thông thường
    • Theo trang trạng thái nền tảng của Chrome, nó hỗ trợ ảnh động, HDR và giải mã tiến dần
      Liên kết chi tiết
    • Tôi đã thử test trên trình duyệt Canary và ảnh động hoạt động tốt
    • Có người đùa rằng WebP thực chất là “định dạng ảnh là video”, còn JPEG XL thì là “định dạng video là ảnh”, tạo nên một cấu trúc đối xứng đầy nghịch lý 😄