Phân tích ưu và nhược điểm của công nghệ WebP (2021)
(eng.aurelienpierre.com)- Nhờ WordPress và các trình duyệt lớn hỗ trợ WebP, việc chuyển thư viện ảnh trở nên dễ dàng hơn, nhưng với ảnh thực tế thì hiện tượng hỏng như posterization và ringing lại lộ rõ hơn so với mức giảm dung lượng tệp
- Google và nhiều plugin WordPress cho rằng WebP nhỏ hơn JPEG và
lossy 80là đủ, nhưng khi chuyển JPEG có sẵn sang WebP thì nén mất dữ liệu bị chồng lặp có thể xảy ra - Với các ảnh mà gradient mượt là quan trọng như ảnh chân dung studio và ảnh scan phim, WebP 95~96 cho kết quả tương đương hoặc nặng hơn JPEG 85+kèm nhiễu
- Việc so sánh SSIM trung bình và kích thước tệp trung bình không đảm bảo khả năng xử lý các trường hợp xấu nhất mà nhiếp ảnh gia cần, và với các website khó tinh chỉnh chất lượng theo từng ảnh thì tính ổn định quan trọng hơn
- Nếu website coi trọng chất lượng hình ảnh, phương án thực tế hơn là giữ JPEG 85~90, thêm dithering hoặc nhiễu mịn, tránh tái mã hóa WebP từ JPEG có sẵn, và tận dụng CDN·ảnh responsive·lazy loading
Kỳ vọng khi áp dụng WebP và các vấn đề thực tế
- Khi WordPress chấp nhận tải lên MIME type
image/webpvà từ sau tháng 9/2020 các trình duyệt lớn đều có thể hiển thị WebP, việc chuyển thư viện ảnh sang WebP trở nên dễ dàng hơn - WebP có vẻ là lựa chọn hấp dẫn nhờ các so sánh cho rằng nó nhỏ hơn JPEG 15% ở cùng chất lượng, cùng với con số Google đưa ra là nhỏ hơn 25~34%
- Trên WordPress có nhiều plugin chuyển thư viện media hiện có sang WebP, và phần lớn hoạt động theo mô hình SaaS bằng cách chuyển đổi trên máy chủ bên ngoài
- Một số plugin và tài liệu kỹ thuật cho rằng mức chất lượng WebP
lossy 80trở lên là không cần thiết với đa số ảnh, nhưng các ví dụ logo không đại diện đầy đủ cho các vấn đề trong công việc xử lý ảnh thực tế
Hư hại khi nén lại JPEG hiện có sang WebP
- Sau khi chuyển đổi hàng loạt media WordPress ở chất lượng
lossy 80, các vòng posterization xuất hiện trên nền - Ảnh gặp vấn đề là ảnh scan khổ trung bình 6×7cm chụp trên phim Ilford Delta 400 bằng Mamiya RB 67, và bản gốc bắt đầu từ bản scan 16-bit
- Hạt bạc của Delta 400 hoạt động như một dạng dithering tự nhiên, có lợi trong việc ngăn posterization ở các vùng mượt, nhưng sau khi chuyển sang WebP thì gradient bị vỡ thành từng bậc
- JPEG gốc ở chất lượng 85 cũng không hoàn toàn sạch, nhưng vẫn tốt hơn bản chuyển WebP, và nguyên nhân lớn là do chồng thêm một lớp nén mất dữ liệu WebP lên trên JPEG vốn đã nén mất dữ liệu
- Google Page Speed Insights và nhiều plugin khuyến nghị hoặc khiến luồng tái mã hóa như vậy trở nên dễ thực hiện, nhưng về chất lượng thực tế thì điều đó không an toàn
Thử nghiệm so sánh trên ảnh thực tế
- Ngay cả trong điều kiện ảnh RAW được mã hóa trực tiếp từ darktable và chỉ nén một lần, điểm yếu của WebP vẫn lộ rõ
- Ảnh thử nghiệm là ảnh headshot studio thực tế, nơi ánh sáng chuyển mượt và gradient nền là yếu tố quan trọng
- Kết quả khi lưu cả JPEG và WebP ở chất lượng 90 và áp dụng Floyd-Steinberg dithering 8-bit:
- JPEG 85 và WebP 90 đều bị đánh giá là thất bại
- WebP trông tệ hơn vì độ tương phản của các vòng posterization cao hơn
- WebP 90 vẫn còn vấn đề dù chất lượng này cao hơn 10 điểm so với mức khuyến nghị
lossy 80 - JPEG 90 trông ổn nhưng kích thước tệp lớn hơn
- Khi lưu WebP ở chế độ lossless, chất lượng trở nên sạch sẽ nhưng kích thước tệp không còn hấp dẫn; trong khi JPEG 90 chỉ bằng khoảng 1/3 dung lượng mà khó phân biệt, còn JPEG 95 có vẻ tương tự ở mức hơn một nửa dung lượng một chút
- Trong thử nghiệm thay Floyd-Steinberg dithering bằng nhiễu ngẫu nhiên ở -48 dB PSNR, WebP vẫn dễ bị posterization hơn
- Mức chất lượng WebP cho độ mượt tương đương JPEG 85+kèm nhiễu nằm trong khoảng 95~96
- Trong điều kiện này, WebP nặng hơn JPEG 85+kèm nhiễu 39%, và cũng nặng hơn JPEG 90+Floyd-Steinberg dithering 30%
- Kết quả WebP vẫn còn ringing nhẹ
Khoảng cách giữa chỉ số trung bình và chất lượng ảnh
- Các đánh giá cho rằng WebP vượt trội phụ thuộc nhiều vào SSIM trung bình và dung lượng bit trung bình của tập dữ liệu ảnh
- Giá trị trung bình không đảm bảo độ ổn định đầu ra mà nhiếp ảnh gia cần cho portfolio web
- Portfolio ảnh không phải là nơi có thể chấp nhận backend nén ảnh thất bại ngẫu nhiên
- Việc tinh chỉnh tỉ mỉ chất lượng WebP cho từng ảnh tốn rất nhiều thời gian, và trong WordPress cũng khó triển khai theo cách đó
- SSIM là chỉ số đo độ tương đồng ảnh dựa trên trung bình, phương sai và hiệp phương sai, nên không phản ánh đầy đủ perceptual metric thực tế và vẫn còn gây tranh cãi
- Trong các lỗi do nén, không chỉ độ lớn sai lệch số học mà bản chất của artifact cũng quan trọng
- Nhiễu ngẫu nhiên có thể chấp nhận được ở một mức nào đó
- Các vết loang có quy luật hoặc gradient bậc thang phá hỏng ảnh nghiêm trọng hơn
Những cảnh mà WebP đặc biệt yếu
- Trong công việc ảnh, các cảnh khó xử lý nhất thường không phải là chi tiết sắc nét mà là gradient mượt
- Trong tình huống ánh sáng gần như điểm chiếu lên tường tạo ra nền tự nhiên, nền phải có đủ kết cấu nhưng không được cướp sự chú ý khỏi chủ thể
- Các ví dụ nén WebP thường cho thấy những cảnh sắc nét, độ sâu trường ảnh lớn và nhiều chi tiết tần số cao, nhưng những cảnh này ít có khả năng bị posterization nên không bộc lộ rõ điểm yếu của thuật toán
- Thiếu độ sắc nét chưa chắc đã phá hỏng một bức ảnh, nhưng hiện tượng vignette mượt bị vỡ thành bậc là dạng hư hại khó chấp nhận
Thiết kế định dạng và vấn đề màu sắc
- WebP ở dạng RGB hoặc RGBalpha nên không thể lưu ảnh đen trắng dưới dạng ảnh xám một kênh
- Trong thử nghiệm, hiện tượng posterization còn tệ hơn do các vòng màu magenta và xanh lá, được lý giải là sự lệch màu do chroma subsampling
- Nếu một định dạng đen trắng thuần có thể lưu dưới dạng một kênh thì có thể tránh tạo thêm dịch chuyển chroma
- AVIF đã giải quyết phần này, nhưng tác giả cho rằng phải mất ít nhất 10 năm nữa mới trở nên phổ biến và thực tế về mặt kỹ thuật
Cách ứng phó để giữ chất lượng hình ảnh
- Với các website mà hình ảnh là yếu tố quan trọng, đặc biệt là portfolio của nghệ sĩ thị giác, nên giữ JPEG ở chất lượng 90 hoặc ít nhất 85
- Để bảo vệ các gradient mượt, tác giả khuyến nghị luôn thêm dithering hoặc nhiễu rất nhẹ vào ảnh
- Tốt hơn là không chuyển JPEG hiện có sang WebP, trừ khi bạn chấp nhận mức hư hại như trong các ví dụ trước
- Để tăng tốc độ tải và độ phản hồi cảm nhận, an toàn hơn là tận dụng CDN, kích thước ảnh responsive, lazy loading ảnh thay vì chuyển đổi định dạng
- Cách SaaS chuyển đổi trên máy chủ bên ngoài vừa tốn chi phí, vừa không công khai hệ số chất lượng thực tế, và có thể phát sinh lỗi kết nối HTTP trong môi trường WordPress được tăng cường bằng plugin bảo mật
- Tốt hơn là chạy ImageMagick hoặc GraphicsMagick trực tiếp trên máy chủ, và nên dùng chương trình phía máy chủ trực tiếp thay vì giao diện PHP
- Nếu các nhà phát triển công nghệ và người thiết kế thuật toán ảnh thúc ép lựa chọn định dạng chỉ dựa trên các chỉ số trung bình, điều đó có thể gây mất thời gian và chi phí cho các nghệ sĩ thực tế
1 bình luận
Ý kiến trên Hacker News
Tôi cũng thấy vấn đề tương tự với WebP nên phần lớn đã quay lại dùng JPG/PNG; ảnh thì dùng jpg, còn ảnh kiểu UI thì dùng png
Có vẻ vấn đề thực sự là nhiều người không nhận ra sự khác biệt, và có lẽ là vì trong 10 năm qua màn hình desktop gần như không có đổi mới đáng kể. Một nửa ở đây có lẽ đang xem các ảnh ví dụ trên màn hình LCD 1920x1080 từ khoảng năm 2012, và đó cũng là một phần của vấn đề
Kỳ lạ là các màn hình nhỏ như điện thoại và các màn hình lớn như TV 4K đều đã có mật độ điểm ảnh rất tốt so với khoảng cách xem, nhưng các tấm nền 20~40 inch vẫn bị mắc kẹt ở mức của giữa những năm 2000
Ngoài ra, sẽ tốt hơn nếu tác giả dùng ảnh ví dụ có nền sáng hoặc đổi nền bài viết sang màu đen. Ảnh màu đen trên nền trắng khiến mắt khó thích nghi nên khó nhìn ra vấn đề, còn nếu đặt trên nền tối thì khác biệt sẽ dễ thấy hơn nhiều
Vì vậy tôi không nghĩ chất lượng màn hình là vấn đề cốt lõi. Cũng có thể là vấn đề driver hoặc bộ lọc hậu xử lý, hoặc đơn giản là không phải ai cũng có mắt nhìn ra những thứ này
Nếu bạn quan tâm đến xử lý ảnh thì theo kinh nghiệm, bạn sẽ nhìn ra những chi tiết như vậy. Tác giả chắc chắn có nhiều kinh nghiệm hơn tôi, và việc nhìn ra các chi tiết này có thể là một phần công việc của họ. Có lẽ họ vẫn nhận ra vấn đề ngay cả trên một màn hình tệ, và còn có thể nói rõ nó tệ theo cách nào
Ví dụ không tốt. Nếu muốn cho người khác thấy điều gì đó, bạn phải phóng to ảnh chụp màn hình để chỉ ra artifact
Khi đổi PNG sang WebP, có phải cái gọi là “lossless WebP” thực ra không thật sự là không mất dữ liệu không?
Tham khảo thêm: sau khi chuyển PNG sang WebP không mất dữ liệu rồi giải nén lại thành PNG, nếu lại chuyển PNG đó sang WebP thì sẽ ra đúng cùng một tệp WebP không mất dữ liệu. Dù mã hóa không mất dữ liệu trực tiếp từ PNG hay từ chính PNG đó sau khi đã “crush” bằng công cụ tối ưu PNG, kết quả WebP vẫn như nhau
Việc có người thật sự quan tâm đến kết quả tốt nhất là điều đáng mừng, nhưng tôi nghĩ đa số sẽ không nhận ra, cũng chẳng bận tâm
Tôi đã mở hai ảnh đầu tiên trong các tab riêng và chuyển qua lại thật nhanh, nhưng hoàn toàn không thấy khác biệt nào. Tôi thử trên hai màn hình khác nhau, với Chrome và Firefox, và cả các ảnh người đàn ông ở cuối cũng vậy.
Sửa: ở lần so sánh cuối thì lại là WebP xuất hiện hai lần và liên kết bị sai. jpg là ở đây, nhưng tôi vẫn không thấy khác biệt nào.
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
Sửa: để thấy sự thật thì phải bấm xem ảnh ở kích thước đầy đủ. Các ảnh nhúng trong bài, kể cả ảnh được ghi là lossless, cũng có artifact nén khá nặng.
Vì vậy ảnh WebP lossless kích thước đầy đủ https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... trông ổn, nhưng bản nhúng của cùng ảnh đó là https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... thì trông rất tệ.
Sửa 2: sự khác biệt giữa ba ảnh dưới đây khá rõ ràng.
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... lossy-noise.jpg (216 kB JPEG)
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (150 kB WebP)
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20... (301 kB WebP)
Cả hai ví dụ WebP, kể cả bản 301 kB, đều cho thấy hiện tượng posterization rõ rệt.
Tôi tự hỏi liệu có vấn đề gì với bộ mã hóa WebP hoặc các thiết lập đã dùng không.
Sửa 3: gamma màn hình và color profile có thể ảnh hưởng đến mức độ dễ thấy của hiện tượng posterization trong gradient.
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
Tuy vậy, nếu bạn không quan tâm đến ảnh chụp thì có thể sẽ không để ý nhiều.
Đây không phải khác biệt nhỏ. Những ai không nhìn ra hoặc phải soi kỹ mới thấy nên biết rằng với nhiều người, khác biệt này là thấy ngay lập tức.
Với ảnh thứ hai, tôi đã mở bản jpeg 90 [1] và webp 90 [2], và khi so sánh thì có vấn đề banding rõ ràng ở bên phải cổ. Dải tối hơn chạy quanh toàn bộ ảnh cũng bớt thấy hơn một chút, nhưng nếu biết phải nhìn chỗ nào thì vẫn thấy được.
Nếu so jpeg 90 với webp lossless, jpeg 100 hoặc jpeg 95, thì cũng có thể thấy banding rất nhẹ của jpeg 90 ở bên phải cổ. Nhưng nếu không phóng to thì cực kỳ khó nhận ra.
[1] https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
[2] https://eng.aurelienpierre.com/wp-content/uploads/sites/8/20...
Theo tôi, nhược điểm tệ nhất và dễ nhận ra nhất của WebP là việc ép buộc lấy mẫu phụ sắc độ 4:2:0. Ở nhiều ảnh có màu sáng, hiện tượng mất màu và mất độ sáng hiện rõ ngay cả khi không có con mắt chuyên nghiệp
Trong so sánh [1], có thể thấy rõ quả bóng ở góc trên bên phải đã mất đi màu đỏ rực rỡ, còn trong so sánh [2], tác phẩm neon xanh sáng ở giữa đã bị mất độ sáng
[1] https://storage.googleapis.com/demos.webmproject.org/webp/cm...
[2] https://storage.googleapis.com/demos.webmproject.org/webp/cm...
Tôi thắc mắc vì sao lệnh này lại tạo ra màu xanh nhạt khi chuyển đổi jpg > webp, trong khi các màu khác thì trông cũng tạm ổn
cwebp -pass 10 -m 6 -nostrong -sharp_yuv -quiet -q 60 -sharpness 2 $1 -oBài này không đề cập đến vấn đề lớn nhất mà tôi cảm thấy ở WebP. Sự bất tiện mà định dạng này gây ra bên ngoài trình duyệt còn lớn hơn mức tiết kiệm dung lượng ít ỏi của nó
Có những định dạng tốt hơn. Có HEIF, AVIF, các định dạng lấy cảm hứng từ codec video như những gì có thể xuất hiện từ H.266, hoặc cả JPEG XL nữa, còn WebP trông như một sự thỏa hiệp không có đủ ưu điểm
Nhiều người tranh cãi xem có nhìn thấy banding trên ảnh WEBP trong điều kiện gần như tối ưu hay không, nhưng ảnh WEBP ngoài đời thực thì phần lớn trông kinh khủng. Tôi chỉ mới bắt đầu nhận ra điều này một cách nghiêm túc gần đây
Tất nhiên giờ có thể “dọn dẹp” ảnh bằng quy trình upscale tạo sinh, nhưng thật khá mỉa mai khi phải tốn nhiều điện như vậy chỉ vì ai đó muốn tiết kiệm 45KB
Điều này cũng gợi nhớ thời GIF bị chuyển thành JPEG. Khoảng 25 năm trước có nhiều ảnh chụp màn hình GIF sạch sẽ mà 256 màu là đủ, nhưng JPEG đã phá hỏng chúng
Google khuyến khích các nhà phát triển dùng WEBP, nhưng lại chẳng có vấn đề gì khi phân phối quảng cáo video mà không ai muốn xem với quy mô hàng petabyte
Nếu ý là “với mắt người không chuyên thì có thể trông ổn, nhưng với nhiếp ảnh gia thì không”, thì có lẽ cần những ví dụ tốt hơn để cho “người không chuyên” thấy vì sao WebP tệ và để biện minh cho bài viết cũng như giọng điệu của nó
Có lẽ vì tôi xem trên Android nên mọi bức ảnh đều có vẻ cùng chất lượng
Và nếu bạn làm ảnh cho “con mắt chuyên nghiệp”, chẳng phải chỉ cần đừng dùng công nghệ không phù hợp với con mắt chuyên nghiệp hay sao? Hoặc đừng giao quyết định đó cho người khác?
Nhìn những bình luận trong chuỗi này nơi mọi người tự tin khẳng định là không có khác biệt như thể tác giả đang nói nhảm, thì sự bức bối đó có vẻ là chính đáng. Không sao nếu bạn không nhìn ra khác biệt ở những ảnh đầu tiên, nhưng vì thế mà tự tin nói mình biết hơn tác giả hoặc đi thiết kế codec ảnh thì không nên
Ngay cả khi không xem toàn màn hình tôi vẫn nhìn ra được. Hãy nhìn người đàn ông đang nhăn mặt, rồi nhìn mép áo gần vai của ông ấy
Ở bức ảnh chất lượng kém, quanh vùng vai có quầng sáng như thể bị ngược sáng
Ở bức ảnh chất lượng tốt, gradient mượt hơn. Không có quầng sáng kiểu ngược sáng quanh vai, nó chỉ trông như nền gradient mịn màng
Nói rõ luôn, tôi không phải nhiếp ảnh gia mà là kỹ sư DevOps. Lần gần nhất tôi dùng JavaScript trong công việc cũng đã ít nhất 11 năm trước
Nó đủ dễ thấy
[1] https://news.ycombinator.com/item?id=38653224
Toàn bộ tiền đề cơ bản của bài blog này dường như không nhằm vượt qua mức kiểm chứng tối thiểu như một phép so sánh giữa các định dạng, mà chỉ để tạo thêm lời phàn nàn và lượt nhấp
Nói thêm chút bối cảnh thì Aurelien Pierre được biết đến là một cộng tác viên chủ chốt của Darktable. Darktable là một công cụ hiện ảnh RAW/lập danh mục mã nguồn mở, tức kiểu như Adobe Lightroom mã nguồn mở
Ông ấy nổi tiếng là có quan điểm rất mạnh về cách làm đúng, đôi khi đến mức khá gay gắt, nên còn fork Darktable thành dự án riêng của mình tên là Ansel. Trước đây cũng đã có thảo luận trên HN https://news.ycombinator.com/item?id=38390914
Nếu quan tâm đến chất lượng ảnh lưu trữ, thì trừ khi có thể làm từ bản gốc không nén, sẽ không nén lại ảnh cũ sang định dạng mới. Tái mã hóa từ nguồn đã nén mất dữ liệu sẽ làm chất lượng kém đi. Lưu trữ thì rẻ và ngày càng rẻ hơn
Điều thực sự có ý nghĩa là chọn thiết lập an toàn khi nén ảnh mới sang định dạng mới
Trong bối cảnh này, Google đã chặn JPEG XL bằng cách gỡ hỗ trợ khỏi Chrome và cũng từ chối khôi phục, đồng thời cho rằng nó không có đủ “lợi ích gia tăng” so với các định dạng hiện có như WebP
-q100vẫn tạo ra banding có thể nhìn thấy, còn JPEG thì ngay cả ở-q90cũng gần như trong suốt về mặt thị giácCó vẻ tác giả đã tập trung sai chỗ. Họ tập trung vào khác biệt giữa các định dạng, nhưng lẽ ra phải tập trung vào cách nén. Mỗi chương trình xử lý ảnh cho ra kết quả nén khác nhau ngay cả khi đặt cùng một con số, ví dụ như “80”
Muốn so sánh thực sự có ý nghĩa thì không chỉ cần thử ảnh chân dung studio đen trắng với nền gradient mượt, mà còn phải thử nhiều loại ảnh khác như ảnh đủ màu với nền phức tạp. Cũng cần xem xét nhiều chương trình như imagemagik, graphicsMagick, sharp, photoshop và các dịch vụ đám mây khác nhau
Một vấn đề khác là trường hợp sử dụng. Nếu một nhiếp ảnh gia chuyên nghiệp muốn đăng ảnh kích thước đầy đủ, chất lượng cao nhất, thì có lẽ tốt hơn là không nén để kết quả sáng tạo/chỉnh sửa được giữ nguyên hoàn toàn. Nhưng đó không phải trường hợp sử dụng trung bình, nơi website hiển thị ảnh có kích thước và chất lượng hợp lý
Trong nhiều tình huống, ảnh nhỏ hơn nhiều đáng để chấp nhận mức nén mạnh hơn, và với nhiều ảnh, hiện tượng nén sẽ ít заметнее hơn so với ảnh studio chuyên nghiệp toàn độ phân giải có nền gradient lớn
Cá nhân tôi không thấy khác biệt gì có ý nghĩa, nên rõ ràng mắt tôi là kiểu “mắt không chuyên”
Điều tác giả đang phàn nàn là artifact xuất hiện trong nền ảnh
Thật lạ khi cảm nhận của mỗi người lại khác nhau đến vậy
Gradient của WebP thường trông giống như khung hình tĩnh từ video. Chroma subsampling làm giảm mật độ các giá trị độ chói gần đúng có thể dùng được, và áp dụng càng mạnh thì gradient càng xấu đi
Độ tương phản cao và chi tiết tần số cao không bị ảnh hưởng nhiều, nhưng gradient có thể hỏng rất nặng
Chroma nghĩa là màu sắc, và subsampling màu được dùng để tránh lấy bớt thông tin từ kênh độ chói quan trọng hơn