Google đã khôi phục hỗ trợ JPEG XL?

 (tonisagrista.com)
5 điểm bởi GN⁺ 2025-12-03 | 2 bình luận | Chia sẻ qua WhatsApp
  • Nhân Chromium đã khôi phục hỗ trợ JPEG XL, khiến định dạng ảnh từng bị khai tử lại được chú ý trở lại
  • Năm 2022, Google đã loại bỏ JPEG XL với lý do “thiếu sự quan tâm từ hệ sinh thái”, nhưng áp lực liên tục từ cộng đồng và các công ty lớn vẫn tiếp diễn
  • Nhiều tổ chức như Meta, Intel, Adobe, Cloudinary, Krita đã công khai ủng hộ việc duy trì định dạng này
  • Gần đây, PDF Association bày tỏ ý định chọn JPEG XL làm định dạng mặc định cho nội dung HDR, càng củng cố xu hướng này
  • Quyết định tái đưa vào Chrome được xem là bước ngoặt làm tăng khả năng JPEG XL trở thành tiêu chuẩn phổ biến

Bối cảnh sự trở lại của JPEG XL

  • Năm 2022, nhóm Chromium đã gỡ mã và cờ của JPEG XL với lý do “không có đủ sự quan tâm từ hệ sinh thái” và “thiếu lợi thế so với các định dạng hiện có”
    • Khi đó, cộng đồng đã nêu rõ sự ủng hộ từ các tổ chức lớn như Meta, Intel, Cloudinary, Adobe, ffmpeg, libvips, Krita
    • Sau đó, trên blog, video và mạng xã hội, các phản ứng chỉ ra tính phi lý của quyết định loại bỏ vẫn tiếp tục xuất hiện
  • Cuối năm 2025, nhóm Chromium đã chuyển issue JPEG XL từ trạng thái Obsolete sang Assigned, chính thức bắt đầu quy trình khôi phục
    • Trong nhóm phát triển Blink, Rick Byers cho biết “hoan nghênh một bộ giải mã JPEG XL có hiệu năng tốt và an toàn bộ nhớ”
    • Quyết định này dựa trên các tín hiệu tích cực như Safari hỗ trợ, Firefox thay đổi lập trường và động thái chấp nhận từ PDF Association

Firefox và việc phát triển bộ giải mã dựa trên Rust

  • Nhóm Firefox lo ngại về rủi ro bảo mật của bộ giải mã libjxl viết bằng C++ của JPEG XL và cho rằng cần một phiên bản Rust “an toàn bộ nhớ”
    • Theo đó, Google Research đã bắt đầu phát triển bản triển khai Rust jxl-rs
    • Dự án này trở thành một bước đệm giúp tăng khả năng tích hợp JPEG XL an toàn trong trình duyệt

Động thái chấp nhận từ PDF Association

  • CTO của PDF Association, Peter Wyatt, đã công bố ý định đưa JPEG XL vào đặc tả PDF như định dạng ảnh mặc định cho HDR
    • Đây là yếu tố góp phần củng cố khả năng tiêu chuẩn hóa của JPEG XL trong lĩnh vực tài liệu và xuất bản

Những đặc điểm kỹ thuật chính của JPEG XL

  • Hỗ trợ nén lại JPEG hiện có theo kiểu không mất dữ liệu, giúp giảm khoảng 30% dung lượng mà không suy giảm chất lượng
  • Hỗ trợ dải màu rộng và HDR, có thể xử lý tối đa kênh 32 bit và 4.099 kênh
  • Hỗ trợ kích thước ảnh tối đa 1,073,741,823×1,073,741,824, cho phép xử lý ảnh siêu lớn
  • Hỗ trợ giải mã tiến dần (progressive decoding), cải thiện hiệu quả truyền tải trên web
  • Bao gồm các tính năng animation, alpha transparency, depth map
  • Có cấu trúc chống suy hao qua nhiều thế hệ, giúp giảm thiểu mất chất lượng khi mã hóa lặp lại

Kết luận

  • JPEG XL đáp ứng các yêu cầu của một định dạng ảnh thế hệ mới, và việc quay trở lại trong nhân Chrome là động lực mang tính quyết định cho sự phổ biến đại chúng
  • Sau áp lực dài hạn từ cộng đồng, định dạng này đang nổi lên như một ứng viên tiêu chuẩn mới cho hệ sinh thái ảnh trên web
  • Tác giả hoan nghênh việc Chromium đánh giá lại, nhưng cũng chỉ ra rằng quyết định này đã được đưa ra quá muộn

Bài viết liên quan

2 bình luận

 
GN⁺ 2025-12-03
Ý kiến trên Hacker News

  • Một trong những tính năng hay nhưng ít được biết đến của JPEG XL là chế độ transcode không mất dữ liệu từ JPEG, giúp tiết kiệm khoảng 20% dung lượng lưu trữ
    Vì giữ nguyên bitstream entropy gốc nên nó hoàn toàn có thể đảo ngược
    GCP đang áp dụng điều này vào DICOM Store API, nên có thể tận dụng mức tiết kiệm dung lượng của JXL mà vẫn cung cấp bằng cách chuyển đổi sang JPEG theo thời gian thực
    Công ty chúng tôi lưu trữ dữ liệu ở quy mô hàng chục PB trên GCP DICOM Store, nên kỳ vọng tính năng này sẽ giúp giảm đáng kể chi phí hằng năm
    Cũng hy vọng có hỗ trợ native trên trình duyệt, và tôi đã nghe nói đội Chrome cuối cùng cũng sẽ hỗ trợ

    • Tôi tò mò không biết nó khác gì so với encoder JPEG thông thường hay mozjpeg
    • Trước đây tôi chưa có thời gian thử GCP DICOM Store, nên muốn biết trải nghiệm thực tế ra sao
      Không rõ nó là PACS hoàn chỉnh, triển khai WADO, hay chỉ là một API tùy biến đơn giản
    • Nếu có thể đảo ngược thì chẳng phải cứ lưu bằng JPEG XL rồi chuyển đổi ngược khi phục vụ là được sao?
      Tôi muốn hỏi liệu thời gian xử lý có tốn nhiều không
    • Nếu dù sao cũng phải lưu DICOM gốc thì tôi nghi ngờ việc transcode có còn nhiều ý nghĩa không
      Có vẻ phần lớn chi phí lưu trữ vẫn là ở chính DICOM
    • Cuối cùng thì các khách hàng lớn của GCP sẽ hưởng lợi lớn từ tính năng này, nên tôi có cảm giác lý do thúc đẩy JXL trong Chrome là vì khách hàng nội bộ

  • Đối thủ của JPEG XL không phải AVIF
    AVIF đã trở thành chuẩn de facto, gần như mọi trình duyệt đều hỗ trợ, và còn được dùng làm định dạng ảnh mặc định của Apple
    JXL tuy vẫn yếu về hỗ trợ trên trình duyệt, nhưng đang dần có chỗ đứng ở các thị trường ngách như lưu trữ bảo tồn, ảnh chuyên nghiệp, y tế
    Khoảng 10 năm nữa, có thể nó sẽ phổ biến đến mức mọi người đơn giản gọi nó là “JPEG”
    AVIF là tiêu chuẩn mở, miễn phí bản quyền, có hiệu quả nén cao hơn nhiều so với JPEG/WebP, và cũng ở mức tương đương với JXL
    JXL có kích thước ảnh tối đa lớn hơn, nhưng mức độ chấp nhận thực tế thì AVIF đi trước rất xa
    Khi AV2 ra mắt, khoảng cách chất lượng gần như sẽ biến mất, và tôi nghĩ cả hai định dạng sẽ cùng phát triển trong khi giữ mức chất lượng tương tự nhau

    • AVIF đương nhiên có hiệu quả nén tốt hơn JPEG hay WebP, nhưng so với JXL thì không đủ sức cạnh tranh
      Ở các thiết lập chất lượng thực tế, JXL cho tỷ lệ nén cao hơn cùng tốc độ mã hóa/giải mã nhanh hơn
      Ngoài ra còn hỗ trợ progressive decoding
      Có thể AV2 sẽ bắt kịp, nhưng hiện tại tôi nghĩ JXL đang vượt lên khá xa
    • Một trong những lý do đội Chrome dừng hỗ trợ JXL trước đây là vì AVIF khi đó đã đủ tốt rồi
      Có vẻ lần xem xét lại này cũng liên quan đến quyết định khi đó
    • Câu “định dạng ảnh mặc định của Apple là AVIF” có vẻ không đúng
      iPhone dùng HEIF
    • Tôi đã thử dùng trực tiếp libjxl và thấy nó ngốn bộ nhớ, lại thiếu ổn định
      Để mã hóa ảnh độ phân giải cao, có lúc cần RAM ở mức terabyte
      Tôi đã rất ngạc nhiên vì codebase khá lộn xộn, và nhiều tùy chọn không hoạt động đúng
      Việc thử lại bằng jxl-rs là tín hiệu tích cực, nhưng vì vẫn là những nhà phát triển đó tham gia nên tôi vẫn theo dõi một cách thận trọng

  • Có khả năng Chromium sẽ dùng crate jxl-rs cho tính năng JPEG XL
    Có vẻ họ định chờ đến khi nó đủ ổn định rồi mới tích hợp
    Có thể xem issue liên quan ở đây

    • Mozilla cũng từng có lập trường tương tự, nhưng Google trong một thời gian đã thể hiện thái độ thù địch
      Họ đóng issue bất chấp sự phản đối của người dùng, và chỉ gần đây mới mở lại
      Có lẽ là vì vấn đề PR hoặc bất mãn nội bộ
    • jxl-rs đã từng có giai đoạn hơn một năm rưỡi không có commit nào
      Việc giờ nó tiến triển tốt có thể chỉ là kết quả của may mắn

  • Tôi đã xem qua triển khai tham chiếu (C++) của JPEG XL, và ngay cả 2 năm trước chất lượng mã cũng không tốt
    Nó tạo cảm giác rất dễ phát sinh vấn đề bảo mật

    • Vì vậy cả Mozilla lẫn Google đều đang cân nhắc hỗ trợ JXL với điều kiện có triển khai an toàn bộ nhớ
      Bản Rust đang được phát triển, và Google cũng có kế hoạch dần thay tất cả decoder trong Chromium bằng Rust
    • Thực ra ở thời điểm hiện tại (2025), bản thân một khối lượng mã xử lý ảnh lớn viết bằng C++ đã là rủi ro bảo mật
      Đây không chỉ là vấn đề riêng của JPEG XL

  • Độ phân giải tối đa của JPEG XL là 1,073,741,823 × 1,073,741,824, có thể biểu diễn ảnh siêu độ phân giải lên tới hàng trăm petabyte
    Trên thực tế, ngay cả sau nén thì cũng vẫn ở mức hàng chục đến hàng trăm PB

    • Với 600DPI thì một cạnh tương đương quãng đường marathon
      Nếu có thể định nghĩa một ảnh khổng lồ như vậy chỉ bằng một lượng byte nhỏ, nó có vẻ cũng có thể trở thành vector tấn công DOS
      Tôi định quy đổi sang số tờ A4 thì máy tính Gemini lại nhầm đơn vị và cho ra kết quả kỳ quặc
    • Với những ảnh siêu lớn như vậy, cách thực tế duy nhất là xử lý bằng tiling và cấu trúc pyramid
    • Có vẻ nó cỡ một bức ảnh chụp toàn bộ Trái Đất ở độ phân giải khoảng 4cm
    • Nếu chụp selfie ở độ phân giải đó thì chắc sẽ ở mức kính hiển vi siêu phân giải
    • Khác với AVIF, JPEG XL hỗ trợ progressive decoding hiệu quả, nên có thể nhanh chóng xem trước bản chất lượng thấp ngay cả khi đang tải xuống

  • Tổng hợp các thảo luận HN trước đây
    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

  • Tôi đã dùng .avif được vài năm rồi
    Nó không hoàn hảo, nhưng tôi thấy vẫn tốt hơn nhiều so với .jpg hay .png
    Tôi cũng từng cân nhắc .webp và jpeg-xl, nhưng cuối cùng vẫn hài lòng với .avif
    Tuy vậy tôi không thích việc Google trên thực tế chi phối các tiêu chuẩn web
    Việc một công ty thương mại kiểm soát hệ sinh thái số là điều không mong muốn

    • Câu “.avif tốt hơn .jpg” lại lặp .avif hai lần nên hơi khó hiểu
    • Nếu muốn làm JPEG chất lượng cao mà dung lượng nhỏ, tôi khuyên nên thử jpegli
      jpegli GitHub
      Nếu chọn tốt thiết lập gần-lossless theo thị giác của AVIF thì có thể nhỏ hơn jpegli, nhưng trung bình thì jpegli hiệu quả hơn
    • Nhân tiện, trong tiếng Anh “for several years” tự nhiên hơn “since some years”
    • JPEG XL ít suy giảm chất lượng hơn khi lưu lại nhiều lần nên có lợi trong môi trường web
      Video liên quan: liên kết YouTube

  • Người loại bỏ JXL không phải là “toàn bộ Google” mà là đội Chrome
    JXL do Jyrki Alakuijala ở Google Zurich thiết kế, và ông thuộc Google Research chứ không phải đội Chrome
    Đội Chrome có văn hóa khép kín tập trung quanh Mountain View

    • Jyrki là một kỹ sư xuất sắc, cũng là người tạo ra Brotli, WebP lossless, WOFF2, jpegli
      Việc ông tạo jpegli sau khi JpegXL bị loại bỏ cũng là một dạng phản ứng
    • Có lẽ có thể giải thích tình huống này bằng Định luật Conway

  • Có vẻ JXL bị chậm lại vì phụ thuộc C++ đa luồng khiến bề mặt tấn công bảo mật lớn hơn
    Cả Mozilla lẫn Google đều muốn tránh điều đó nên ưu tiên triển khai bằng Rust
    Bản thân tiêu chuẩn này rõ ràng là định dạng tốt hơn các định dạng cũ

    • Con số 100 triệu dòng có vẻ bị phóng đại quá mức
    • Thực tế chỉ khoảng 30 nghìn dòng, còn bản single-thread thì vào khoảng 10 nghìn dòng
      Kích thước binary cũng nhỏ hơn AVIF rất nhiều, và đặc tả cũng ngắn gọn hơn nhiều
    • Google đã tham gia phát triển JXL, nên việc không sớm tạo decoder an toàn bộ nhớ là trách nhiệm của chính họ
    • Có phải ý bạn là khoảng 100 nghìn dòng không? Có lẽ phần lớn trong đó là mã kiểm thử
    • libjxl thực tế khoảng 112 nghìn dòng, tức vẫn chênh 3 bậc độ lớn so với khẳng định 100 triệu dòng

  • Nghe nói tệp RAW trên iPhone 17 Pro sẽ được nén bằng JPEG XL