JPEG XL và câu hỏi khó: Liệu Web có thực sự cần thêm một định dạng ảnh mới?

JPEG XL từ lâu được xem là "ứng viên sáng giá" cho tương lai ảnh trên Web, với khả năng nén vượt trội và tính linh hoạt cao. Tuy nhiên, một phân tích kỹ thuật gần đây đặt ra câu hỏi ngược lại: liệu định dạng này có thực sự cần thiết cho trình duyệt, khi AVIF đang bứt phá ở mọi dải chất lượng?

So sánh chất lượng nén HDR giữa các định dạng ảnh hiện đại

Bối cảnh: Vì sao JPEG XL lại gây tranh cãi?

JPEG XL là định dạng ảnh do Ủy ban JPEG phát triển, không mất phí bản quyền, có khả năng nén hiệu quả và linh hoạt hơn WebP. Định dạng này từng nhận được sự quan tâm của nhiều công ty lớn, nhưng đến năm 2023 thì bị Chrome từ chối tích hợp – một quyết định gây nhiều tranh cãi trong cộng đồng mã nguồn mở.

Gần đây, một bộ giải mã JPEG XL viết bằng Rust đã xuất hiện trong Firefox và Chrome ở một mức độ nào đó. Nhiều người cho rằng các ông lớn của Web có thể đang "quay xe", nhất là khi bộ giải mã mới hứa hẹn giúp Web tránh lặp lại lỗ hổng bảo mật của WebP năm 2023.

Tuy nhiên, tác giả bài phân tích – một kỹ sư nén ảnh xuất thân từ lĩnh vực nén video – lại đưa ra góc nhìn trái chiều. Anh từng ủng hộ JPEG XL cho Interop 2024 và có nhiều trao đổi cá nhân với hai tác giả chính của định dạng là Jon Sneyers và Jyrki Alakuijala. Bài viết không nhằm phủ nhận công sức của họ, mà muốn đưa ra cái nhìn thực nghiệm về hiện trạng nén ảnh và nền tảng Web trong năm 2026.

Điểm yếu cốt lõi: Không cạnh tranh được ở nén lossy

Lập luận trung tâm của bài viết rất rõ ràng: phần lớn nhu cầu ảnh trên Web chỉ cần nén lossy linh hoạt, đủ tốt để tránh các lỗi nén khó coi (như JPEG trên ảnh phi nhiếp ảnh). Người dùng Web bình thường không cần lossless.

Điều này vô hiệu hóa lợi thế lossless của JPEG XL, vốn chỉ nhỏ hơn WebP lossless khoảng 11,9% – và đó là trên một tập dữ liệu thử nghiệm không thực tế với Web (ảnh 157 MP, minh họa 10 MP, sách 27 MP). Việc đưa thêm một codec ảnh mới vào trình duyệt để tiết kiệm 12% dung lượng ảnh là điều khó biện minh.

Nhưng vấn đề nghiêm trọng hơn nằm ở chính nén lossy – nơi JPEG XL từng được kỳ vọng sẽ tỏa sáng.

Biểu đồ so sánh chỉ số CVVDP giữa các encoder

Các chỉ số đánh giá không hề ủng hộ JPEG XL

Theo các thang đo như CVVDP, MS-SSIM và SSIMULACRA2, encoder tham chiếu libjxl đang tụt lại khá xa so với các đối thủ hiện đại. Biểu đồ trong bài còn đưa vào "aperture-alpha" – encoder sắp ra mắt của Halide Compression – để cho thấy khoảng cách cần thu hẹp là bao xa.

Một số ý kiến cho rằng JPEG XL mạnh về mặt cảm nhận thị giác dù chỉ số không cao, nhưng tác giả không thấy đủ bằng chứng để tin rằng bức tranh có thể đảo ngược hoàn toàn. Với AVIF, chế độ tối ưu cảm nhận của libaom chỉ thấp hơn chế độ tối ưu theo chỉ số vài điểm – trong khi khoảng cách của JPEG XL lớn hơn nhiều.

Những hạn chế kỹ thuật khó khắc phục

Tác giả – với tư cách kỹ sư nén ảnh – liệt kê một loạt điểm yếu mang tính cấu trúc của JPEG XL:

• Không có chế độ dự đoán hướng (directional prediction): Trong khi các codec khối như WebP cho phép dự đoán pixel từ dữ liệu xung quanh, JPEG XL dùng khối VarDCT và biến đổi tần số trực tiếp. Điều này khiến việc giữ cạnh (edge preservation) kém hơn.
• Không có bộ lọc khử khối (DLF): JPEG XL chỉ có gaborish và EPF – tương tự loop restoration và CDEF của AV1 – nhưng không thể thay thế hoàn toàn DLF. Hệ quả là hiện tượng nhiễu "muỗi" (mosquito noise) vẫn tồn tại.
• Không gian màu XYB gây tranh cãi: Nền tảng của XYB mang tính trực giác cao, nhưng lợi ích không chuyển hóa được sang các định dạng khác. Việc libjxl lượng tử hóa mạnh kênh B khiến khả năng giữ màu kém, buộc các nhà phát triển encoder mới phải "sửa lại".
• Xử lý ảnh phi nhiếp ảnh kém: Giải pháp đề xuất là dùng patches, nhưng phức tạp hơn nhiều so với Intra Block Copy của AV1. Chi phí để mã hóa một khối IntraBC chỉ gồm vector chuyển động và hệ số dư, trong khi JXL cần đến khung tham chiếu, header, thông tin crop, blend, từ điển patch và khung dư – quá nhiều overhead.

So sánh chỉ số SSIMULACRA2 giữa các encoder

Tốc độ giải mã: Vấn đề bị xem nhẹ

JPEG XL có đặc tả cực kỳ linh hoạt: hỗ trợ tới 4096 kênh, độ sâu màu tùy ý, giải mã lũy tiến (progressive decode), nén lại JPEG... Nhưng phần lớn tính năng này không hữu ích cho Web, nơi chỉ cần 4 kênh (RGB/YUV + alpha), độ sâu màu đủ cho HDR (10-bit) và khả năng tải nhanh.

Về giải mã lũy tiến – thứ mà AVIF từng thiếu và bị chê – giờ đây AVIF đã làm rất tốt. Trang thông tin của JPEG-XL thậm chí cho thấy AVIF hiển thị ảnh dùng được khi mới tải khoảng 2-3% dung lượng, sớm hơn hẳn JXL, trong khi tổng dung lượng AVIF lại nhỏ hơn.

Còn về nén lại JPEG (tiết kiệm khoảng 20% dung lượng), người dùng phải trả giá bằng thời gian giải mã tăng khoảng 33%. Với các thiết bị phổ thông, lập luận "tiết kiệm miễn phí" là sai lệch.

Đáng lo ngại hơn, do tính biểu đạt cao, JPEG XL có thể bị lợi dụng để tạo "bom giải mã". Một ảnh chỉ nặng 1.918 byte có thể khiến thiết bị mất tới 17,43 giây để giải mã. Với việc bộ giải mã Rust đang được đưa vào Chrome và Firefox, nguy cơ tấn công thiết bị yếu trở nên dễ dàng hơn.

Kết luận: JPEG XL có ích, nhưng không phải cho trình duyệt

Tác giả cho rằng codec cho Web nên được thiết kế chuyên biệt, hiệu quả và phạm vi hẹp đúng với nhu cầu của Web. WebP có phần quá hẹp, AVIF có thể cải thiện container và đặc tả AV1, nhưng AVIF vẫn là lựa chọn tất yếu nhờ hệ sinh thái AV1 trưởng thành.

JPEG XL thì ngược lại – nó được thiết kế để "là tất cả cho mọi người". Điều này có ích cho nhiều lĩnh vực khác, nhưng Web cần tiết kiệm băng thông, giải mã nhanh và hạn chế rủi ro bảo mật. Tác giả thậm chí đánh giá JPEG XL không phù hợp với Web bằng WebP.

Ba năm rưỡi trước, chính tác giả từng nói: "Tôi muốn một Web nơi cả AVIF và JPEG XL cùng tồn tại, để nhà phát triển tự quyết định dựa trên điểm mạnh của từng định dạng." Nhưng khi đó, JPEG XL còn là ứng viên mạnh cho nén lossy chất lượng trung bình đến cao. Giờ đây, AVIF đã thống trị toàn bộ dải chất lượng, và lợi thế duy nhất của JPEG XL đã biến mất.

"JPEG XL không phải là vô dụng; nó thực sự là công nghệ hấp dẫn cho các trường hợp sử dụng ngoài Web. Tôi chỉ không tin rằng chúng ta cần nó trong trình duyệt trong tương lai gần."

JPEG XL vẫn có thể phát triển mạnh mẽ bên ngoài Web – trong các công cụ chuyên nghiệp như Adobe, cho các nhà sản xuất máy ảnh và OEM smartphone. Nhưng với Web, có lẽ đã đến lúc chấp nhận rằng AVIF là đủ.