JPEG XL và biên Pareto

 (cloudinary.com)
2 điểm bởi GN⁺ 2024-03-02 | 2 bình luận | Chia sẻ qua WhatsApp
  • libjxl 0.10 giảm nút thắt của việc mã hóa JPEG XL vốn phải xử lý ảnh lớn trong một lần bằng API mã hóa streaming, đồng thời cải thiện đáng kể mức dùng bộ nhớ và tốc độ của nén không mất dữ liệu
  • Mã hóa không mất dữ liệu cho ảnh Trái Đất ban đêm 13500×6750 của NASA giảm từ khoảng 8GB RAM và hơn 2 phút trên libjxl 0.9 xuống còn 0,7GB RAM, 30 giây với luồng đơn và 5 giây với 8 luồng trên libjxl 0.10
  • So sánh các phương thức nén chỉ bằng kích thước tệp là chưa đủ; biên Pareto xem đồng thời tốc độ mã hóa và mật độ nén trở thành tiêu chí phân định thiết lập tối ưu theo từng ngân sách thời gian
  • Với nén mất dữ liệu, cần xem đồng thời tỷ lệ nén, tốc độ và chất lượng hình ảnh; trong dải SSIMULACRA2 60~90, JPEG XL cho kết quả đặc biệt mạnh ở vùng chất lượng cao đến gần như không mất mát về mặt thị giác
  • Các bộ mã hóa JPEG mới như jpegli vẫn còn sức cạnh tranh ở dải mã hóa cực nhanh, nhưng JPEG XL đang trở thành lựa chọn chủ chốt cho cả nén không mất dữ liệu lẫn mất dữ liệu trên một dải tốc độ rộng

Thay đổi cốt lõi của libjxl 0.10

  • libjxl 0.10 là phiên bản mới của triển khai tham chiếu JPEG XL, và thay đổi lớn nhất là việc hoàn thiện API mã hóa streaming
  • API này mã hóa ảnh lớn theo từng khối thay vì xử lý toàn bộ trong một lần
    • Giảm gánh nặng RAM khi phải nạp toàn bộ ảnh vào bộ nhớ
    • Đồng thời cải thiện tốc độ mã hóa
    • Hiệu quả đặc biệt rõ trong nén không mất dữ liệu cho ảnh lớn

Bộ nhớ và thời gian giảm trong nén không mất dữ liệu

  • Trước libjxl 0.10, mã hóa JPEG XL không mất dữ liệu có thể gặp vấn đề về mức dùng bộ nhớ lớn và thời gian xử lý dài
  • Ảnh ví dụ là ảnh Trái Đất ban đêm 13500×6750 của NASA
    • Tệp TIFF là 64MB
    • Kích thước trước nén là 273MB
  • Kết quả nén cùng ảnh đó ở thiết lập effort mặc định e7:
    • libjxl 0.9 dùng khoảng 8GB RAM và mất hơn 2 phút, tệp kết quả là 33,7MB
    • Luồng đơn mất 2 phút 40 giây, 8 luồng mất 2 phút 6 giây nên hiệu quả tăng thêm luồng không lớn
    • Môi trường đo là MacBook Pro tháng 11/2023 trang bị CPU Apple M3 Pro 12 nhân và RAM 36GB
  • Trên libjxl 0.10, nén cùng ảnh đó chỉ cần 0,7GB RAM
    • 30 giây với luồng đơn
    • 5 giây với 8 luồng
    • Tệp kết quả là 33,2MB
  • Khi tăng giá trị effort, tỷ lệ nén tốt hơn nhưng mức cải thiện so với thời gian CPU bỏ ra giảm dần
    • Từ e1 lên e2, dùng 1 giây thay vì 0,1 giây có thể giảm 22MB
    • Từ e2 lên e7, dùng 5 giây thay vì 1 giây giúp giảm thêm 11MB
    • Từ e7 lên e9, muốn giảm thêm 1MB thì phải chờ gần 2 phút

Điểm cân bằng thực tế của thiết lập effort

  • Thiết lập nén là bài toán đánh đổi giữa thời gian và kích thước tệp
  • Trong quy trình sáng tác lưu cục bộ khi chỉnh sửa ảnh, nén mạnh có thể không thực sự cần thiết nên mã hóa effort thấp có thể là lựa chọn hợp lý
  • Trong các kịch bản phân phối một đến nhiều hoặc lưu trữ dài hạn, việc dùng thêm thời gian CPU để giảm vài MB có thể đáng giá

So sánh phương thức nén bằng biên Pareto

  • Khi so sánh các kỹ thuật nén, chỉ nhìn kích thước tệp dễ bỏ sót thông tin cần thiết cho lựa chọn thực tế

  • Trục so sánh và cách đọc biểu đồ

    • Hai trục cốt lõi là mật độ nén và tốc độ mã hóa
    • Một phương thức là tối ưu Pareto nếu không có phương thức nào khác đạt cùng hoặc tốt hơn về mật độ nén trong thời gian ngắn hơn
    • Tập hợp các phương thức tối ưu Pareto là biên Pareto
    • Trong biểu đồ, trục dọc là tốc độ mã hóa, trục ngang là số bit trung bình trên mỗi pixel của ảnh đã nén
    • Trục dọc dùng đơn vị megapixels per second và dùng thang log để bao phủ dải tốc độ rộng
    • Ảnh RGB 8-bit trước nén là 24bpp
    • Càng lên trên thì càng nhanh, càng sang trái thì tỷ lệ nén càng tốt

Kết quả so sánh nén không mất dữ liệu

  • libjxl trước đây cũng đã cho kết quả tối ưu Pareto trên mọi dải tốc độ, tạo ra tệp nhỏ hơn PNG, AVIF không mất dữ liệu và WebP không mất dữ liệu
  • libjxl 0.10 cho kết quả tốt hơn phiên bản trước với khoảng cách đáng kể
  • QOI không được vẽ trên biểu đồ nhưng đạt 17bpp ở 154Mpx/s
    • Thiết lập effort thấp nhất của libjxl nén xuống 11,5bpp ở 427Mpx/s
    • Phía libjxl nhanh hơn 2,7 lần và tệp kết quả nhỏ hơn 32,5%

Nén không mất dữ liệu cho ảnh phi chụp ảnh

  • Ảnh chụp có nhiều nhiễu tự nhiên nên khó nén không mất dữ liệu, còn với ảnh phi chụp thì kết quả khác
  • Trong bài test dùng 41 ảnh truyện tranh với nhiều phong cách vẽ khác nhau, kích thước trung bình là 7,3 megapixel
  • Loại ảnh này nén được xuống khoảng 4bpp, tốt hơn nhiều so với khoảng 10bpp của ảnh chụp
  • AVIF không mất dữ liệu không hữu ích với loại ảnh này
    • Tỷ lệ nén còn kém PNG
    • Đạt mật độ tương tự QOI nhưng chậm hơn nhiều
  • WebP không mất dữ liệu cho tỷ lệ nén rất tốt trên loại ảnh này
  • QOI ổn nếu xét tốc độ và độ đơn giản, nhưng còn khá xa mức tối ưu Pareto
    • Mã hóa JPEG XL effort thấp nhanh hơn QOI 2 lần và nhỏ hơn 31%
  • libjxl 0.10 cũng cải thiện lớn so với 0.9 trên ảnh phi chụp
    • WebP effort mặc định: 4,30bpp, 2,3Mpx/s
    • libjxl 0.9 effort 5: 4,27bpp, 2,6Mpx/s
    • libjxl 0.10 effort 5: 4,25bpp, 12,2Mpx/s
    • libjxl 0.10 effort 7: 4,04bpp, 5,9Mpx/s

Nén mất dữ liệu có thêm trục chất lượng

  • Nén không mất dữ liệu chỉ cần nhìn kích thước nén và tốc độ, nhưng nén mất dữ liệu còn có thêm chất lượng hình ảnh
  • Hiệu năng của codec và encoder ảnh mất dữ liệu có thể khác nhau tùy điểm chất lượng
    • Encoder tốt ở mã hóa chất lượng cao chưa chắc tốt ở chất lượng thấp
    • Chiều ngược lại cũng vậy
  • Biểu đồ bitrate-distortion chỉ nhìn tỷ lệ nén và chất lượng khiến việc đánh giá đánh đổi giữa effort mã hóa và hiệu năng nén trở nên khó khăn
  • Muốn xem biên Pareto của nén mất dữ liệu, cần cắt không gian 3 chiều gồm nén, tốc độ và chất lượng ở nhiều điểm chất lượng khác nhau

Cách đo và tổng hợp chất lượng hình ảnh

  • Chất lượng hình ảnh mang tính chủ quan và có thể khác nhau giữa từng người
  • Cách đo tốt nhất là thí nghiệm để hàng chục người trở lên so sánh hoặc chấm điểm ảnh theo giao thức kiểm thử nghiêm ngặt
  • Vì các thí nghiệm như vậy tốn thời gian và chi phí nên khó kiểm thử mọi thiết lập encoder, do đó người ta dùng các chỉ số khách quan
  • Trong các chỉ số công khai, những chỉ số tốt gồm SSIMULACRA2, Butteraugli, DSSIM
    • Chúng cố mô hình hóa hệ thị giác con người và có tương quan tốt với đánh giá chủ quan
    • Các chỉ số cũ và đơn giản như PSNR hay SSIM không khớp tốt với đánh giá chất lượng của con người
  • Nếu đánh giá bằng chính chỉ số mà encoder tối ưu nội bộ, kết quả có thể bị lệch theo hướng có lợi cho encoder đó
    • libjxl effort cao tối ưu Butteraugli
    • libavif có thể tối ưu PSNR hoặc SSIM
    • SSIMULACRA2 được xem là chỉ số an toàn vì các encoder được thử không dùng nó cho tối ưu nội bộ
  • Trong bài test, thiết lập encoder được chọn sao cho khi áp dụng cho toàn bộ tập ảnh, điểm SSIMULACRA2 trung bình gần với một giá trị mục tiêu nhất định
  • Cách sắp theo điểm trung bình có lợi cho WebP và AVIF
    • Các nghiên cứu trước cho thấy AVIF và WebP kém ổn định hơn JPEG và HEIC, còn JPEG XL là encoder ổn định nhất
    • Trong sử dụng thực tế, có thể người dùng muốn khớp theo điểm tệ nhất hoặc chất lượng thị giác tệ nhất thực sự

Dải chất lượng gần với sử dụng thực tế

  • Nén mất dữ liệu có thể đạt các tỷ lệ nén cao như 50:1 hay 200:1, nhưng sẽ sinh artefact nén
  • Dải có ý nghĩa nhất trong thực tế là SSIMULACRA2 60~90
  • Đặc tính theo từng điểm chất lượng:
    • SSIMULACRA2 90: chất lượng gần như không mất mát về mặt thị giác; các codec hiện đại như AVIF và JPEG XL có thể đạt ở tỷ lệ nén khoảng 8:1, tức 3bpp
    • SSIMULACRA2 80: chất lượng cao, đạt ở tỷ lệ nén khoảng 16:1, tức 1,5bpp
    • SSIMULACRA2 70: chất lượng trung bình cao, đạt ở tỷ lệ nén khoảng 30:1, tức 0,8bpp
    • SSIMULACRA2 60: chất lượng trung bình, đạt ở tỷ lệ nén khoảng 40:1, tức 0,6bpp
  • Chất lượng dưới SSIMULACRA2 60 có thể giảm băng thông thêm nhưng cũng có nguy cơ làm hỏng hình ảnh
  • Trên web năm 2024, dải chất lượng trung bình đến cao là đáng quan tâm nhất
    • Theo HTTP Archive, giá trị trung vị của AVIF trên web là 1bpp, tương ứng chất lượng trung bình cao
    • Giá trị trung vị của JPEG là 2,1bpp, tương ứng chất lượng cao
  • Với các trường hợp ngoài web như máy ảnh, dải chất lượng cao đến gần như không mất mát về mặt thị giác còn quan trọng hơn

Kết quả biên Pareto của nén mất dữ liệu

  • Bài test nén mất dữ liệu được thực hiện với phiên bản mới nhất của từng encoder tính đến cuối tháng 2/2024
  • Tốc độ mã hóa được đo với 8 luồng trên MacBook Pro tháng 11/2023 dùng Apple M3 Pro
  • AVIF được thử cả thiết lập có tile và không tile
    • Thiết lập có tile tận dụng multithreading tốt hơn nên nhanh hơn
    • Đổi lại sẽ mất mật độ nén

Chất lượng trung bình: SSIMULACRA2 60

  • Ngay trong cùng một định dạng, kết quả cũng khác biệt lớn tùy encoder và thiết lập effort
  • Thiết lập mặc định của libjpeg-turbo, encoder JPEG từng được dùng rất rộng rãi, nhanh nhất trên biểu đồ nhưng nằm ở phía mật độ nén kém
  • WebP có mật độ nén tốt hơn libjpeg-turbo
  • mozjpeg chậm hơn libjpeg-turbo nhưng cho kết quả nén tốt hơn, và trên tập ảnh cũng như điểm chất lượng này thì hiệu quả Pareto hơn WebP
  • jpegli do nhóm JPEG XL của Google phát triển nhanh hơn mozjpeg và tỷ lệ nén cũng tốt hơn
    • Dựa trên các bài học rút ra từ guetzli và libjxl
    • Nén tốt hơn WebP và AVIF tốc độ cao trong khi vẫn tạo ra tệp JPEG truyền thống
  • AVIF và HEIC đạt mật độ nén tốt hơn JPEG và WebP nhưng mã hóa chậm hơn
  • JPEG XL mã hóa nhanh hơn nhiều trong khi đạt mật độ nén tương tự
  • Biên Pareto ở điểm chất lượng này gồm JPEG XL và nhiều encoder JPEG ở dải tốc độ hợp lý, còn AVIF nằm ở dải chậm hơn

Kết quả chất lượng trung bình cao và chất lượng cao

  • Ở chất lượng trung bình cao SSIMULACRA2 70, kết quả tổng thể tương tự chất lượng trung bình
  • Bài viết dùng SSIMULACRA2 trung bình 85 làm điểm chất lượng cao nhất liên quan đến web, với thiết lập để đa số ảnh đạt từ 80 trở lên
  • Ở điểm chất lượng cao này, khác biệt trở nên rõ hơn
    • mozjpeg không còn vượt WebP nữa
    • jpegli vẫn vượt WebP
    • Biên Pareto chủ yếu do JPEG XL chiếm giữ
    • Với mã hóa cực nhanh, JPEG truyền thống vẫn rất tốt
  • Ở điểm chất lượng này, AVIF không nằm trên biên Pareto
    • Thiết lập chậm nhất của nó đạt cùng mật độ nén với thiết lập libjxl nhanh thứ hai ở tốc độ dưới 0,5Mpx/s
    • Thiết lập libjxl tương ứng đạt 52Mpx/s, nhanh hơn hơn 100 lần

Tốc độ giải mã

  • Các so sánh đến đây chủ yếu tập trung vào mật độ nén và tốc độ mã hóa
  • Trên máy tính hiện đại, tốc độ giải mã không phải vấn đề lớn nhưng các số đo vẫn được so sánh
  • JPEG tuần tự mạnh nhất về tốc độ giải mã
  • JPEG progressive do mozjpeg và jpegli mặc định tạo ra chậm hơn, nhưng vẫn đủ nhanh để tải ảnh kích thước hợp lý rất nhanh
  • JPEG XL nằm giữa JPEG tuần tự và JPEG progressive
  • Tốc độ giải mã của AVIF thay đổi theo cách mã hóa
    • Dùng mã hóa multi-tile nhanh hơn nhưng hơi kém hơn thì giải mã cũng nhanh hơn
    • Mã hóa single-tile mặc định chậm hơn
  • Ngay cả tốc độ giải mã chậm nhất được đo cũng vẫn đủ nhanh so với tốc độ mã hóa

Gần như không mất mát về mặt thị giác và ảnh lớn

  • Biểu đồ chất lượng gần như không mất mát về mặt thị giác không bao gồm WebP
    • Nó không thể đạt được điểm chất lượng đó ở chế độ mất dữ liệu
    • Vì WebP bắt buộc dùng chroma subsampling 4:2:0
  • mozjpeg cũng không được thiết kế cho điểm chất lượng này nên vừa nén vừa tốc độ đều kém hơn libjpeg-turbo
  • Ở thiết lập tốc độ mặc định, libavif cho tệp nhỏ hơn libjpeg-turbo 20% nhưng thời gian mã hóa dài hơn một bậc độ lớn
  • Ở cùng điểm chất lượng, libjxl nhỏ hơn libavif 20% và nhanh hơn 2,5 lần
  • Biên Pareto ở chất lượng gần như không mất mát về mặt thị giác phần lớn do JPEG XL chiếm giữ, và JPEG cũng xuất hiện ở dải tốc độ nhanh nhất
  • Khác với bài test ảnh cỡ web khoảng 1 megapixel, kết quả trên ảnh lớn thay đổi đáng kể
    • Ở điểm chất lượng cao, WebP, mozjpeg và AVIF đều kém hơn libjpeg-turbo
    • HEIC mang lại mức tiết kiệm đáng kể so với libjpeg-turbo
    • jpegli cũng mang lại mức tiết kiệm đáng kể với tốc độ tốt hơn
    • JPEG XL nén ảnh xuống dưới 1,3bpp, trong khi AVIF, libjpeg-turbo và WebP đều cần trên 2bpp

Vị thế cuối cùng của libjxl 0.10

  • libjxl 0.10 giảm mức dùng bộ nhớ xuống một chữ số lần cho cả nén không mất dữ liệu lẫn mất dữ liệu
  • Tốc độ cũng được cải thiện, đặc biệt thiết lập effort mặc định của mã hóa không mất dữ liệu đa luồng tăng tốc ở mức một chữ số lần
  • JPEG XL được khẳng định là codec ảnh mạnh cho cả nén không mất dữ liệu lẫn mất dữ liệu, đặc biệt trong dải chất lượng cao đến gần như không mất mát về mặt thị giác
  • Trên dải thiết lập tốc độ rộng, JPEG XL vẫn là lựa chọn gần tối ưu Pareto
  • JPEG truyền thống vẫn hấp dẫn nhờ các encoder mới
    • jpegli cải thiện mạnh cả tốc độ lẫn nén so với mozjpeg
    • Khi cần mã hóa cực nhanh, JPEG truyền thống vẫn có thể là lựa chọn tốt nhất

Bài viết liên quan

2 bình luận

 
dofuuz 2024-03-08

Bộ mã hóa jpegli lại một lần nữa kéo dài tuổi thọ của jpg sau mozjpeg...
Được phe JXL tạo ra, nhưng trớ trêu thay, nó cũng có thể cản trở việc phổ biến JXL...
 
GN⁺ 2024-03-02
Các ý kiến trên Hacker News

  • Cũng cần chú ý WebP không mất dữ liệu tốt đến mức nào
    Điều này thường bị lấn át bởi nhận định rằng WebP không có lợi thế rõ rệt so với mã hóa MozJPEG, hoặc thậm chí còn tệ hơn, nhưng WebP không mất dữ liệu thực sự xuất sắc về hiệu năng và tốc độ
    Nó tốt hơn PNG hay OptiPNG rất nhiều, mức hỗ trợ trực tuyến cũng đã đủ, và tất nhiên vượt xa AVIF không mất dữ liệu vốn rất tệ

    • WebP không mất dữ liệu thực sự tốt, nhưng vì chỉ hỗ trợ 8-bit nên khả năng chống lỗi thời kém
      Với ảnh SDR thì ổn, nhưng với HDR thì đây trở thành giới hạn nền tảng, giống như GIF bị giới hạn ở 256 màu
    • WebP không mất dữ liệu có vấn đề là chỉ hỗ trợ (A)RGB, còn ảnh thang xám thì được mã hóa bằng một cách đi đường vòng còn kém hơn hỗ trợ đơn sắc
      Nếu nén cả một bộ truyện tranh thì PNG vẫn là lựa chọn đúng, và khi đó nên dùng oxipng hơn là optipng gần như đã bị bỏ rơi
      Một điểm còn thiếu ở đây là JPEG2000 không mất dữ liệu có thể bất ngờ tốt và nhanh với nội dung ảnh chụp
    • WebP còn có chế độ mã hóa gần như không mất dữ liệu dựa trên đặc tả WebP không mất dữ liệu, nhưng hầu như không được quảng bá
      Với đa số mục đích sử dụng, nó đáng được ưu tiên hơn chế độ không mất dữ liệu thực sự, và thường giảm được kích thước thêm một nửa mà không có suy hao nhìn thấy được
    • Việc các phiên bản không mất dữ liệu của các định dạng ảnh mới AVIF và HEIC lại có hiệu năng tệ đến vậy so với PNG cũ là khá sốc
    • Có vẻ vẫn còn dư địa giảm thêm trong AVIF không mất dữ liệu: https://www.reddit.com/r/AV1/comments/1b3lh08/comment/kstmbr...

  • Ở các thiết lập chất lượng rất thấp, thật đáng ngạc nhiên là dù JPEG trông như một mớ hỗn độn kiểu tranh lập thể khi nhìn gần vì các artifact dễ thấy, nó vẫn giữ được xấp xỉ chi tiết sắc nét giúp bảo toàn chất lượng tổng thể của ảnh tốt hơn
    Thực chất nó biến ảnh thành một kiểu nghệ thuật trừu tượng nào đó, trong khi JXL và AVIF thì chỉ bị nhòe đi

    • Đó là vì JPEG được cấp 0,5 bit cho mỗi pixel, còn JPEG XL và AVIF chỉ khoảng 0,22 và 0,2 bit
      Các ảnh này không nhằm cùng tỷ lệ nén, mà nhằm khớp cùng mức méo, và số bit trên mỗi pixel được hiển thị bên cạnh ảnh
      Trên Internet thực tế, dùng chất lượng 65 là hiếm và chỉ thấy ở các trang chất lượng thấp nhất; chất lượng 75 là mức chất lượng thấp phổ biến, còn chất lượng 85 gần với mức trung bình
      Khi cần nén, tôi dùng chất lượng 94 yuv444 trở lên
    • Nếu đang nói đến ảnh này https://res.cloudinary.com/jon/qp-low.png
      Bitrate nằm ở cột bên trái, và JPG chất lượng thấp có cùng kích thước với mức chất lượng trung bình-thấp 0,4bpp của JXL/AVIF, nên cần so sánh hình dưới cùng bên trái với hình ở giữa phía trên và hình bên phải
    • JPEG vẫn dùng số bit trên mỗi pixel nhiều gần gấp đôi, nên kích thước tệp kết quả lớn hơn nhiều
      Không nên bị cuốn theo một phép so sánh sai; nếu cho JXL và AVIF kích thước tệp gấp đôi thì chúng cũng trông tốt hơn nhiều
    • Vì bitrate của JPEG cao hơn, trong bài kiểm tra này điều đó gần với việc nói rằng SSIMULACRA2 là chỉ số sai
      SSIMULACRA2 phạt artifact dạng khối rất nặng nhưng dường như không quan tâm nhiều đến độ nhòe, và tôi đồng ý rằng với cùng điểm SSIMULACRA2 thì phiên bản JPEG trông đẹp hơn
    • Kết luận tôi rút ra từ bài này cũng là JPEG giữ độ sắc nét ở rìa như lông mi thực sự tốt, trong khi JXL và AVIF làm mượt và làm bẹp mọi chi tiết của ảnh

  • Tôi không hiểu vì sao bài này lại tập trung nhiều vào tốc độ mã hóa như vậy, trong khi phần giải mã — thứ tôi cho là chiếm 99% mức sử dụng trong môi trường kết nối web — lại được xử lý qua loa
    Nó chỉ lướt qua kiểu “tốc độ giải mã không phải vấn đề lớn trên máy tính hiện đại, nhưng xem nhanh các con số thì cũng thú vị”

    • Nếu vượt quá 100MB/giây thì tôi cho là đủ cho Internet
      Vì từ thời điểm đó, nút thắt không còn là giải mã nữa
      Hầu hết các thuật toán nén hiện đại đều bất đối xứng, nên dù dành nhiều thời gian hơn rất nhiều cho nén, hiệu năng giải nén không bị ảnh hưởng lớn; một khi đạt được hiệu năng cơ bản thì nó bớt quan trọng
    • Tôi tò mò liệu có thực tế không khi giải mã các định dạng ảnh phái sinh từ định dạng video, như AVIF/AV1 hay HEIC/H264, bằng bộ giải mã video phần cứng
      Nếu có thể, đó có thể là lý do mạnh để ưu tiên chúng hơn JPEG XL, vốn hiện đều phải giải mã bằng phần mềm trên phần cứng hiện tại
      Giải mã H264 có ở khắp nơi, còn giải mã AV1 cũng đang dần trở thành tính năng tiêu chuẩn
    • Trong một số trường hợp sử dụng, công ty trả chi phí mã hóa, còn client thực hiện giải mã
      Chỉ cần client giải mã vài ảnh trên trang nhanh đến mức con người không cảm nhận được là đủ; ngược lại, chỉ cần cải thiện vài phần trăm ở khâu mã hóa cũng có thể tiết kiệm chi phí thực sự
    • Mã hóa thời gian thực khá phổ biến, nên tốc độ mã hóa rất quan trọng
    • Vì đó là trường hợp sử dụng của Cloudinary
      Thực tế họ chi hàng triệu đô la cho mã hóa ảnh

  • Tôi đã bật cười khi thấy QOI xuất hiện trong benchmark không mất dữ liệu
    Đây là một định dạng thực chất không liên quan, không được hỗ trợ mặc định trong phần mềm đại chúng, và mục tiêu chỉ là “ổn” chứ không phải “tốt”, nhưng việc nó vẫn chiếm một chỗ trong biểu đồ mã hóa phi ảnh chụp thì khá thú vị

    • GameMaker Studio đã bắt kịp làn sóng QOI khá nhanh, và 2 năm trước đã đổi texture PNG sang QOI rồi nén thêm BZ2 bên trên, đạt mức giảm kích thước trung bình 20%
      Vì vậy GameMaker Studio và các game được làm trong khoảng 2 năm gần đây thực sự dùng QOI nội bộ
      Người tiêu dùng không chủ động dùng nó, nhưng cũng khó nói là hoàn toàn không liên quan
    • Dù vậy, nó vẫn không chạm tới biên Pareto
      Nhìn lại thì điều đó là hiển nhiên, vì giải mã QOI về bản chất là tuần tự nên không dễ song song hóa

  • Tôi thắc mắc liệu sự xuất sắc của JXL là nhờ bản thân định dạng hay nhờ encoder
    Khả năng tạo ra ảnh nhỏ mà chất lượng cao chỉ với -d 1.0 kỳ lạ đến mức khó tin; với các codec khác, để đạt kết quả tương tự thì phải đặt chất lượng khác nhau tùy theo loại ảnh

    • Đây là một điểm rất hay
      Với tốc độ phát triển này, sẽ không ngạc nhiên nếu libjxl trở thành x264 của giới encoder ảnh
      Ngược lại, libvpx luôn là một encoder tầm thường, và tôi nghĩ đó có thể là nguyên nhân khiến định dạng vp8/vp9 có hiệu năng đáng thất vọng, không chỉ về tốc độ mà cả hiệu năng tổng thể
      Điều này tất yếu cũng ảnh hưởng đến hiệu năng WebP có mất dữ liệu, và Dark Shikari từng so sánh hiệu năng ảnh tĩnh của x264 với vp8 [0]
      [0] https://web.archive.org/web/20150419071902/http://x264dev.mu...
    • Pik ban đầu được thiết kế để đạt mức tốt nhất có thể ở khoảng cách 1.0 mà không có tùy chọn chất lượng
      Nó vẫn tập trung nhiều vào mức không mất dữ liệu về mặt thị giác, và không muốn đưa vào các tính năng định dạng chỉ làm tăng độ phức tạp mà không giúp ích cho các thiết lập chất lượng cao
      Ngoài các tính năng mô hình hóa, mô hình hóa ngữ cảnh và hiệu quả mã hóa entropy cũng rất quan trọng ở chất lượng cao
      Tôi cho rằng mã hóa entropy của AVIF không phù hợp lắm với ảnh chụp chất lượng cao hoặc không mất dữ liệu
    • Họ cũng tạo JPEG encoder cjpegli với cùng giao diện -d 1.0

  • Cũng đáng nhắc rằng từ công việc với JPEG XL đã xuất hiện một thư viện song song hóa mới rất tuyệt tên là Highway
    Thư viện này không chỉ được dùng trong JPEG XL mà còn trong các mô hình AI Gemma mới nhất của Google

    • Nếu quan tâm đến Highway thì có thể xem [0]
      [1] cũng đề cập đến nó, mở đầu như sau: “Hôm nay chúng tôi chia sẻ mã nguồn mở có thể sắp xếp mảng số nhanh hơn khoảng 10 lần so với C++ std::sort, đồng thời vẫn giữ tính portable trên mọi kiến trúc CPU hiện đại và còn nhanh hơn các thuật toán tối tân theo từng kiến trúc. Bên dưới, chúng tôi thảo luận cách đạt được điều này.”
      [0] https://github.com/google/highway
      [1] https://opensource.googleblog.com/2022/06/Vectorized%20and%2..., bài báo liên quan là https://arxiv.org/pdf/2205.05982.pdf
    • Và còn có VIPS nữa
      Có vẻ đây là cách tốt nhất để có SIMD portable trong C++

  • Bất kể JPEG XL tự nó tỏa sáng đến mức nào, chỉ riêng việc nó làm được điều sau đã chắc chắn rất ấn tượng
    a.jpg có 615504 byte và SHA-1 là 716744d950ecf9e5757c565041143775a810e10f
    Khi chạy cjxl a.jpg a.jxl, nó đọc JPEG 615504 byte và nén xuống 537339 byte, bao gồm cả container
    Nhưng khi chạy djxl a.jxl b.jpg, nó đọc dữ liệu nén 537339 byte rồi tái tạo thành JPEG, và b.jpg cũng có 615504 byte với SHA-1 hoàn toàn giống hệt
    Nếu nghĩ đến việc trên đời có hàng tỷ file JPEG mà ta muốn bảo tồn, thì việc nén lại JPEG hiện có bằng định dạng mất dữ liệu sẽ làm giảm chất lượng
    Nhưng JPEG XL có thể tiết kiệm 15~30% mà vẫn cho phép khôi phục JPG gốc giống 100% đến từng bit nếu muốn
    Thật sự rất tuyệt
    Tiếc là tôi đang dùng Debian stable 12 Bookworm với ImageMagick 6.9, và theo tôi biết Emacs có lẽ dùng ImageMagick khi hiển thị ảnh
    Hỗ trợ JPEG XL chỉ mới được thêm vào ImageMagick 7, và tôi vẫn chưa đào sâu thêm

    • Tôi đã góp phần đưa yêu cầu đó vào JPEG XL
      Tôi nghĩ nó sẽ giúp bảo tồn nguyên vẹn di sản số mà không cần tái mã hóa mất dữ liệu
    • Đây hẳn sẽ là tính năng được những người dùng chụp màn hình JPEG rồi gửi lại qua WhatsApp cực kỳ trân quý :P

  • Rất ấn tượng khi phiên bản mới của libjxl đã giảm mức dùng bộ nhớ xuống một chữ số lần cho cả nén có mất dữ liệu lẫn không mất dữ liệu, đồng thời cải thiện tốc độ
    Tôi đặc biệt thích phần thiết lập effort mặc định cho mã hóa lossless đa luồng giờ nhanh hơn một chữ số lần, và bài viết cũng được viết tốt

  • Tôi tự hỏi có website nào giải thích chi tiết từng bước của định dạng JPEG XL không
    Khác với JPEG truyền thống, tôi khó tìm được tài liệu hướng dẫn rõ ràng các bước liên quan, và thật đáng tiếc vì rõ ràng định dạng này tập hợp rất nhiều đổi mới thú vị
    Các thành phần riêng lẻ có lẽ cũng hữu ích theo cách riêng của chúng

  • Bài viết thiếu rav1e, thứ mã hóa AV1 và do đó là AVIF
    rav1e nhanh hơn nhiều so với bản triển khai tham chiếu aom; từng có trường hợp aom chờ 1 phút vẫn chưa chuyển đổi xong ảnh, trong khi rav1e mất chưa đến 10 giây

    • Tôi thắc mắc liệu đường cong Pareto của rav1e có vượt trước đường cong Pareto của libaom không
      Tôi cũng tò mò liệu rav1e nhanh có trông tốt hơn jpegli ở tốc độ mã hóa cao không
    • Cả rav1e lẫn libaom đều có thiết lập tốc độ
      Ở tốc độ tương tự, tôi chưa thấy khác biệt lớn về hiệu quả nén giữa hai bên