Jyrki Alakuijala, Tiến sĩ, Google, Inc.
Vincent Rabaud, Tiến sĩ, Google, Inc.
Cập nhật lần gần đây nhất: 1/8/2017
Abstract (Trừu tượng) – Chúng tôi so sánh mức sử dụng tài nguyên của bộ mã hoá/giải mã WebP với định dạng PNG ở cả chế độ không tổn hao và suy hao. Chúng tôi sử dụng một kho nội dung gồm 12000 hình ảnh PNG mờ được chọn ngẫu nhiên trên web và các phép đo đơn giản hơn để thể hiện sự khác biệt về hiệu suất. Chúng tôi đã nén các tệp PNG trong kho nội dung của mình để so sánh hình ảnh WebP với tệp PNG được tối ưu hoá về kích thước. Trong kết quả của mình, chúng tôi cho thấy WebP là một lựa chọn thay thế phù hợp cho PNG để sử dụng trên web về cả kích thước và tốc độ xử lý.
Giới thiệu
WebP hỗ trợ hình ảnh không mờ và mờ, khiến nó trở thành một lựa chọn thay thế cho định dạng PNG. Nhiều kỹ thuật cơ bản dùng trong quá trình nén PNG, chẳng hạn như mã hoá từ điển, mã hoá Huffman và tính năng biến đổi chỉ mục màu cũng được hỗ trợ trong WebP, dẫn đến tốc độ và mật độ nén tương tự trong trường hợp xấu nhất. Đồng thời, một số tính năng mới -- chẳng hạn như các mã entropy riêng biệt cho các kênh màu khác nhau, cục bộ 2D về khoảng cách tham chiếu ngược và bộ nhớ đệm màu của các màu được sử dụng gần đây -- cho phép cải thiện mật độ nén với hầu hết hình ảnh.
Trong công việc này, chúng tôi so sánh hiệu suất của WebP với PNG được nén ở mức cao bằng pngcrush và ZopfliPNG. Chúng tôi đã nén các tập dữ liệu tham khảo về hình ảnh trên web bằng các phương pháp hay nhất, đồng thời so sánh cả nén WebP không suy hao và tổn hao với kho dữ liệu này. Ngoài kho tài liệu tham khảo, chúng tôi đã chọn 2 hình ảnh lớn hơn, 1 hình ảnh và nội dung đồ họa còn lại, về việc đo điểm chuẩn tốc độ và mức sử dụng bộ nhớ.
Tốc độ giải mã nhanh hơn so với PNG đã được chứng minh, cũng như khả năng nén mật độ cao hơn 23% so với những gì có thể đạt được khi sử dụng định dạng PNG hiện tại. Chúng tôi kết luận rằng WebP là một giải pháp thay thế hiệu quả hơn cho định dạng hình ảnh PNG hiện tại. Ngoài ra, tính năng nén hình ảnh có tổn hao có hỗ trợ alpha không suy hao cung cấp thêm khả năng trong việc tăng tốc các trang web.
Phương pháp
Công cụ dòng lệnh
Chúng tôi sử dụng các công cụ dòng lệnh sau để đo lường hiệu suất:
cwebp và dwebp. Những công cụ này thuộc thư viện libwebp (được biên dịch từ đầu).
chuyển đổi. Đây là một phần công cụ dòng lệnh của phần mềm ImageMagick (6.7.7-10 2017-07-21).
pngcrush 1.8.12 (ngày 30 tháng 7 năm 2017)
ZopfliPNG (Ngày 17 tháng 7 năm 2017)
Chúng tôi sử dụng các công cụ dòng lệnh có cờ kiểm soát tương ứng. Ví dụ: nếu chúng ta tham chiếu đến cwebp -q 1 -m 0, tức là công cụ cwebp đã được gợi lên với các cờ -q 1 và -m 0.
Tập hợp hình ảnh
Ba tập sao lục đã được chọn:
Một ảnh chụp duy nhất (Hình 1),
Một hình ảnh đồ hoạ có độ trong suốt (Hình 2) và
Một kho dữ liệu web: 12000 hình ảnh PNG đã chọn ngẫu nhiên có độ trong suốt hoặc không trong suốt, được thu thập dữ liệu từ Internet. Các hình ảnh PNG này được tối ưu hoá thông qua chuyển đổi, pngcrush, ZopfliPNG và phiên bản nhỏ nhất của mỗi hình ảnh sẽ được xem xét cho nghiên cứu này.
Hình 1. Hình ảnh chụp, 1024 x 752 pixel. Thở bằng lửa Trang web của tác giả tại đây.
Hình 2. Hình ảnh đồ hoạ, 1024 x 752 pixel. Ảnh ghép từ Công cụ tạo biểu đồ của Google
Để đo lường toàn bộ khả năng của định dạng PNG hiện có, chúng tôi đã nén tất cả hình ảnh PNG gốc này bằng một số phương pháp:
Kẹp thành 8 bit trên mỗi thành phần: chuyển đổi input.png -depth 8 output.png
ImageMagick(1) không có trình dự đoán: chuyển đổi input.png -quality 90 output-candidate.png
ImageMagick với các trình dự đoán thích ứng: chuyển đổi input.png -quality 95 output-candidate.png
Pngcrush(2): pngcrush -brute -rem tEXt -rem tIME -rem iTXt -rem zTXt -rem gAMA -rem cHRM -rem iCCP -rem sRGB -rem alla -rem text.png output-png-dididate.png
ZopfliPNG(3): zopflipng --lossy_transparency input.png output-candidate.png
ZopfliPNG với tất cả các bộ lọc: zopflipng --iterations=500 --filter=01234mepb --lossy_8bit --lossy_transparency input.png output-candidate.png
Kết quả
Chúng tôi tính toán mật độ nén cho từng hình ảnh trong kho dữ liệu web, so với kích thước hình ảnh PNG được tối ưu hoá cho 3 phương thức:
WebP không suy hao (chế độ cài đặt mặc định)
WebP không suy hao với kích thước nhỏ nhất (-m 6 -q 100)
tốt nhất là không suy hao WebP và WebP suy hao với phiên bản alpha (chế độ cài đặt mặc định).
Chúng tôi sắp xếp các yếu tố nén này và đưa vào Hình 3.
Hình 3. Mật độ nén PNG được dùng làm tham chiếu ở 1.0. Các hình ảnh tương tự được nén bằng cả phương thức không tổn hao và suy hao. Đối với mỗi hình ảnh, tỷ lệ kích thước giữa định dạng PNG đã nén sẽ được tính toán và tỷ lệ kích thước được sắp xếp và hiển thị để nén ở cả dạng tổn hao và không tổn hao. Đối với đường cong nén tổn hao, nén không tổn hao sẽ được chọn trong những trường hợp nén tạo hình ảnh WebP nhỏ hơn.
WebP vượt khỏi mật độ nén PNG cho cả libpng ở chất lượng tối đa (chuyển đổi) cũng như ZopfliPNG (Bảng 1) với tốc độ mã hóa (Bảng 2) và tốc độ giải mã (Bảng 3) gần tương đương với tốc độ của PNG.
Bảng 1. Số bit trên mỗi pixel trung bình cho ba tập sao lục bằng cách sử dụng các phương thức nén khác nhau.
Bộ hình ảnh | chuyển đổi -chất lượng 95 | ZopfliPNG | WebP không suy hao -q 0 -m 1 | WebP không suy hao (chế độ cài đặt mặc định) | WebP không suy hao -m 6 -q 100 | Tỷ lệ mất dữ liệu WebP với alpha |
---|---|---|---|---|---|---|
ảnh | 12,3 | 12,2 | 10.5 | 10.1 | 9,83 | 0,81 |
phản cảm | 1,36 | 1,05 | 0,88 | 0,71 | 0,70 | 0,51 |
web | 6,85 | 5,05 | 4,42 | 4,04 | Euro | 1,92 |
Bảng 2. Thời gian mã hoá trung bình cho tập sao nén và cho các phương thức nén khác nhau.
Bộ hình ảnh | chuyển đổi -chất lượng 95 | ZopfliPNG | WebP không suy hao -q 0 -m 1 | WebP không suy hao (chế độ cài đặt mặc định) | WebP không suy hao -m 6 -q 100 | Tỷ lệ mất dữ liệu WebP với alpha |
---|---|---|---|---|---|---|
ảnh | 0,500 giây | 8,7 giây | 0,293 giây | 0,780 giây | 8.440 giây | 0,111 giây |
phản cảm | 0,179 giây | 14 giây | 0,065 giây | 0,140 giây | 3,510 giây | 0,184 giây |
web | 0,040 giây | 1,55 giây | 0,017 giây | 0,072 giây | 2,454 giây | 0,020 giây |
Bảng 3. Thời gian giải mã trung bình cho ba tập sao lục đối với các tệp hình ảnh được nén bằng các phương thức và chế độ cài đặt khác nhau.
Bộ hình ảnh | chuyển đổi -chất lượng 95 | ZopfliPNG | WebP không suy hao -q 0 -m 1 | WebP không suy hao (chế độ cài đặt mặc định) | WebP không suy hao -m 6 -q 100 | Tỷ lệ mất dữ liệu WebP với alpha |
---|---|---|---|---|---|---|
ảnh | 0,027 giây | 0,026 giây | 0,027 giây | 0,026 giây | 0,027 | 0,012 giây |
Đồ hoạ | 0,049 giây | 0,015 giây | 0,005 giây | 0,005 giây | 0,003 | 0,010 giây |
web | 0,007 giây | 0,005 giây | 0,003 giây | 0,003 giây | 0,003 | 0,003 giây |
Lập hồ sơ bộ nhớ
Đối với việc phân tích bộ nhớ, chúng tôi đã ghi lại kích thước cài đặt thường trú tối đa theo báo cáo của /usr/bin/time -v
Đối với kho dữ liệu web, kích thước của riêng hình ảnh lớn nhất sẽ xác định mức sử dụng bộ nhớ tối đa. Để đo lường bộ nhớ chính xác hơn, chúng ta sử dụng một hình ảnh chụp đơn (Hình 1) để cung cấp thông tin tổng quan về mức sử dụng bộ nhớ. Hình ảnh đồ hoạ cho kết quả tương tự.
Chúng tôi đo được từ 10 đến 19 MiB đối với libpng và ZopfliPNG, 25 MiB và 32 MiB đối với phương thức mã hoá không bị suy hao WebP tại phần cài đặt -q 0 -m 1 và -q 95 (với giá trị mặc định là -m).
Trong một thử nghiệm giải mã, việc chuyển đổi -resize 1x1 sẽ sử dụng 10 MiB cho cả tệp PNG do libpng và ZopfliPNG tạo ra. Sử dụng cwebp, giải mã không mất dữ liệu WebP sẽ sử dụng 7 MiB và trình giải mã mất dữ liệu 3 MiB.
Kết luận
Chúng tôi đã chỉ ra rằng cả tốc độ mã hoá và giải mã đều nằm trong cùng một miền của PNG. Mức sử dụng bộ nhớ tăng lên trong giai đoạn mã hoá, nhưng giai đoạn giải mã cho thấy mức giảm đáng kể, ít nhất là khi so sánh hành vi của cwebp với hoạt động chuyển đổi của ImageMagick.
Mật độ nén tốt hơn cho hơn 99% hình ảnh web, cho thấy rằng có thể thay đổi tương đối dễ dàng từ PNG sang WebP.
Khi chạy với chế độ cài đặt mặc định, WebP sẽ nén tốt hơn 42% so với libpng và 23% so với ZopfliPNG. Điều này cho thấy WebP đang hứa hẹn về việc tăng tốc hình ảnh cho các trang web nặng.
Tệp đối chiếu
Các liên kết bên ngoài
Sau đây là các nghiên cứu độc lập không được Google tài trợ và Google không nhất thiết phải đảm bảo tính chính xác của tất cả nội dung của họ.