Trang này được dịch bởi Cloud Translation API.

Câu hỏi thường gặp

WebP là gì? Tại sao tôi nên dùng công cụ này?

WebP là một phương pháp nén có tổn hao và không tổn hao, có thể dùng trên nhiều loại hình ảnh chụp, trong suốt và đồ hoạ được tìm thấy trên web. Mức độ nén có tổn hao có thể điều chỉnh được để người dùng có thể chọn sự cân bằng giữa kích thước tệp và chất lượng hình ảnh. WebP thường đạt được có độ nén trung bình cao hơn 30% so với JPEG và JPEG 2000 mà không làm mất hình ảnh chất lượng (xem Nghiên cứu so sánh).

Về cơ bản, định dạng WebP nhằm mục đích tạo ra những hình ảnh nhỏ hơn, đẹp hơn có thể giúp tốc độ web nhanh hơn.

Những trình duyệt web nào hỗ trợ sẵn WebP?

Các quản trị viên trang web quan tâm đến việc cải thiện hiệu suất của trang web có thể dễ dàng tạo tối ưu hoá các phương án thay thế WebP cho hình ảnh hiện tại và phân phát chúng trên cơ sở nhắm mục tiêu đến các trình duyệt hỗ trợ WebP.

Hỗ trợ WebP suy hao
- Google Chrome (máy tính) 17 tuổi trở lên
- Google Chrome dành cho Android phiên bản 25 trở lên
- Microsoft Edge 18 trở lên
- Firefox 65 trở lên
- Opera 11.10 trở lên
- Trình duyệt web gốc, Android 4.0+ (ICS)
- Safari 14 trở lên (iOS 14 trở lên, macOS Big Sur trở lên)
WebP có tổn hao, không tổn hao và hỗ trợ alpha
- Google Chrome (máy tính) 23 tuổi trở lên
- Google Chrome dành cho Android phiên bản 25 trở lên
- Microsoft Edge 18 trở lên
- Firefox 65 trở lên
- Opera 12.10 trở lên
- Trình duyệt web gốc, Android 4.2 trở lên (JB-MR1)
- Vầng trăng nhạt 26 tuổi trở lên
- Safari 14 trở lên (iOS 14 trở lên, macOS Big Sur trở lên)
Hỗ trợ ảnh động WebP
- Google Chrome (máy tính và Android) 32 trở lên
- Microsoft Edge 18 trở lên
- Firefox 65 trở lên
- Opera 19 trở lên
- Safari 14 trở lên (iOS 14 trở lên, macOS Big Sur trở lên)

Xem thêm:

Làm cách nào để biết trình duyệt có hỗ trợ WebP không?

Bạn chỉ muốn phân phát hình ảnh WebP cho những ứng dụng khách có thể hiển thị hình ảnh đó đúng cách và quay lại định dạng cũ cho những khách hàng không thể. Rất may có một số kỹ thuật giúp phát hiện khả năng hỗ trợ WebP, cả trên phía máy khách và phía máy chủ. Một số nhà cung cấp CDN hỗ trợ phát hiện WebP như một phần trong dịch vụ của họ.

Thương lượng nội dung phía máy chủ thông qua tiêu đề Chấp nhận

Thông thường, các ứng dụng web sẽ gửi lệnh "Chấp nhận" tiêu đề của yêu cầu, cho biết định dạng nội dung nào họ sẵn sàng chấp nhận. Nếu một trình duyệt cho biết trước rằng sẽ "chấp nhận" định dạng image/webp, máy chủ web biết rằng nó có thể gửi hình ảnh WebP một cách an toàn, đơn giản hoá đáng kể thương lượng nội dung. Hãy truy cập vào các đường liên kết sau để biết thêm thông tin.

Modernizr

Modernizr là thư viện JavaScript giúp phát hiện HTML5 và Hỗ trợ tính năng CSS3 trong trình duyệt web. Tìm các thuộc tính Modernizr.webp, Modernizr.webp, Modernizr.webp và Modernizr.webp.animation.

Phần tử `<picture>` HTML5

HTML5 hỗ trợ phần tử <picture>, cho phép bạn liệt kê nhiều các mục tiêu hình ảnh thay thế theo thứ tự ưu tiên để ứng dụng sẽ yêu cầu hình ảnh đề xuất đầu tiên mà nó có thể hiển thị đúng cách. Xem cuộc thảo luận này về HTML5 Rocks. Phần tử <picture> là được nhiều trình duyệt khác hỗ trợ mọi lúc.

Trong JavaScript của riêng bạn

Một phương pháp phát hiện khác là cố gắng giải mã một hình ảnh WebP rất nhỏ sử dụng một tính năng cụ thể và kiểm tra xem có thành công không. Ví dụ:

// check_webp_feature:
//   'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.
//   'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)
function check_webp_feature(feature, callback) {
    var kTestImages = {
        lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
        lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
        alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
        animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
    };
    var img = new Image();
    img.onload = function () {
        var result = (img.width > 0) && (img.height > 0);
        callback(feature, result);
    };
    img.onerror = function () {
        callback(feature, false);
    };
    img.src = "data:image/webp;base64," + kTestImages[feature];
}

Lưu ý rằng quá trình tải hình ảnh mang tính không chặn và không đồng bộ. Điều này có nghĩa là bất kỳ đoạn mã phụ thuộc vào khả năng hỗ trợ WebP nên được đặt vào lệnh gọi lại .

Vì sao Google phát hành WebP dưới dạng nguồn mở?

Chúng tôi tin tưởng sâu sắc vào tầm quan trọng của mô hình nguồn mở. Với WebP ở định dạng nguồn mở, bất kỳ ai cũng có thể làm việc với định dạng đó và đề xuất cách cải thiện. Bằng ý kiến đóng góp và đề xuất của bạn, chúng tôi tin rằng WebP sẽ còn hữu ích hơn nữa làm định dạng đồ hoạ theo thời gian.

Làm cách nào để chuyển đổi tệp hình ảnh cá nhân sang WebP?

Bạn có thể dùng tiện ích dòng lệnh WebP để chuyển đổi tệp hình ảnh cá nhân sang định dạng WebP. Hãy xem bài viết Sử dụng WebP để biết thêm thông tin chi tiết.

Nếu có nhiều hình ảnh cần chuyển đổi, bạn có thể sử dụng shell của nền tảng để đơn giản hoá thao tác. Ví dụ: để chuyển đổi tất cả tệp jpeg trong một thư mục, hãy thử như sau:

Windows:

> for /R . %I in (*.jpg) do ( cwebp.exe %I -o %~fnI.webp )

Linux / macOS:

$ for F in *.jpg; do cwebp $F -o `basename ${F%.jpg}`.webp; done

Làm cách nào để tự đánh giá chất lượng hình ảnh WebP?

Hiện tại, bạn có thể xem tệp WebP bằng cách chuyển đổi các tệp đó sang một định dạng phổ biến sử dụng nén không tổn hao, chẳng hạn như PNG, rồi xem tệp PNG trong bất kỳ trình duyệt hoặc trình xem ảnh nào. Để tìm hiểu nhanh về chất lượng WebP, hãy xem Thư viện trên trang web này để chụp ảnh cạnh nhau các so sánh.

Làm cách nào để lấy mã nguồn?

Mã bộ chuyển đổi có trên phần tải xuống của dự án nguồn mở WebP . Mã cho bộ giải mã nhẹ và thông số kỹ thuật VP8 đang bật trang web WebM. Xem Trang Vùng chứa RIFF cho vùng chứa đặc điểm kỹ thuật.

Kích thước tối đa của một hình ảnh WebP có thể là bao nhiêu?

WebP tương thích với luồng bit với VP8 và sử dụng 14 bit cho chiều rộng và chiều cao. Kích thước pixel tối đa của hình ảnh WebP là 16383 x 16383.

Định dạng WebP hỗ trợ hệ màu nào?

Tương tự với luồng bit của VP8, WebP suy yếu chỉ hoạt động với Định dạng hình ảnh 8 bit Y'CbCr 4:2:0 (thường được gọi là YUV420). Vui lòng tham khảo Phần 2, "Tổng quan về định dạng" trong RFC 6386, Hướng dẫn giải mã và định dạng dữ liệu VPC8 để biết thêm chi tiết.

Nền tảng WebP không tổn hao chỉ hoạt động với định dạng RGBA. Xem Thông số kỹ thuật của luồng bit không tổn hao cho WebP.

Hình ảnh WebP có thể lớn hơn hình ảnh nguồn không?

Có, thường là khi chuyển đổi từ định dạng có tổn hao sang WebP không tổn hao hoặc ngược lại. Điều này chủ yếu là do sự khác biệt không gian màu (YUV420 so với ARGB) và chuyển đổi giữa các chỉ số này.

Có ba tình huống điển hình:

Nếu hình ảnh nguồn ở định dạng ARGB không tổn hao, thì việc giảm tần số lấy mẫu không gian Khi chuyển sang YUV420, màu mới khó nén hơn các bản ghi gốc. Trường hợp này thường có thể xảy ra khi mã nguồn ở định dạng PNG với ít màu sắc: chuyển đổi sang WebP có tổn hao (hoặc tương tự sang ảnh JPEG có tổn hao) sẽ có thể khiến kích thước tệp lớn hơn.
Nếu nguồn ở định dạng có tổn hao, hãy dùng phương thức nén WebP không tổn hao để nắm bắt tính chất mất mát của nguồn thường sẽ dẫn đến một tệp lớn hơn. Điều này không chỉ ảnh hưởng đến WebP và có thể xảy ra khi chẳng hạn như chuyển đổi nguồn JPEG sang định dạng WebP hoặc PNG không tổn hao.
Nếu nguồn có định dạng có tổn hao và bạn đang cố nén lại dưới dạng WebP có tổn hao với chế độ cài đặt chất lượng cao hơn. Ví dụ: cố gắng chuyển đổi tệp JPEG được lưu ở chất lượng 80 thành tệp WebP có chất lượng 95 thường sẽ dẫn đến tệp lớn hơn, ngay cả khi cả hai định dạng đều có tổn hao. Thông thường, bạn sẽ không thể đánh giá chất lượng của nguồn, vì vậy, bạn nên giảm chất lượng WebP mục tiêu nếu kích thước tệp liên tục lớn hơn. Một khả năng khác là tránh sử dụng cài đặt chất lượng và thay vào đó nhắm mục tiêu một kích thước tệp nhất định bằng cách sử dụng tuỳ chọn -size trong công cụ cwebp, hoặc API tương đương. Ví dụ: nhắm mục tiêu 80% tệp gốc có thể mạnh mẽ hơn.

Lưu ý rằng việc chuyển đổi nguồn JPEG sang WebP có tổn hao hoặc từ nguồn PNG thành không tổn hao WebP không dễ gặp vấn đề về kích thước tệp như vậy.

WebP có hỗ trợ hiển thị tăng dần hoặc xen kẽ không?

WebP không cung cấp tính năng làm mới giải mã tăng dần hoặc xen kẽ trong tệp JPEG hoặc PNG. Điều này có thể sẽ tạo quá nhiều áp lực lên CPU và bộ nhớ của vì mỗi sự kiện làm mới đều liên quan đến một lượt truyền đầy đủ thông qua hệ thống giải nén này.

Trung bình, việc giải mã một hình ảnh JPEG tiến bộ tương đương với việc giải mã đường cơ sở 1 3 lần.

Ngoài ra, WebP cung cấp tính năng giải mã tăng dần, trong đó tất cả kết quả có sẵn các byte của luồng bit được dùng để thử và tạo một hàng mẫu có thể hiển thị dưới dạng sớm nhất có thể. Điều này vừa giúp tiết kiệm bộ nhớ, CPU và vẽ lại trên đồng thời đưa ra chỉ dẫn trực quan về trạng thái tải xuống. Sự gia tăng tính năng giải mã này có sẵn thông qua API Giải mã nâng cao.

Làm cách nào để sử dụng liên kết Java libwebp trong dự án Android?

WebP có hỗ trợ các liên kết JNI với bộ mã hoá và bộ giải mã đơn giản các giao diện trong thư mục swig/.

Xây dựng thư viện trong Eclipse:

Đảm bảo bạn có Trình bổ trợ ADT được cài đặt cùng với các công cụ NDK và đường dẫn NDK của bạn được thiết lập chính xác (Lựa chọn ưu tiên > Android > NDK).
Tạo dự án mới: File > (Tệp >) Mới > Dự án > Android Dự án ứng dụng.
Nhân bản hoặc giải nén libwebp vào một thư mục có tên jni trong dự án mới.
Thêm swig/libwebp_java_wrap.c vào danh sách LOCAL_SRC_FILES.
Nhấp chuột phải vào dự án mới rồi chọn Android Tools (Công cụ Android) > Thêm Hỗ trợ gốc ... để đưa thư viện vào bản dựng của bạn.
Mở thuộc tính của dự án và chuyển đến phần Bản dựng C/C++ > Hành vi. Thêm ENABLE_SHARED=1 đến phần Build (Incremental build) để tạo bản dựng libwebp làm thư viện dùng chung.

Lưu ý Nhìn chung, việc đặt NDK_TOOLCHAIN_VERSION=4.8 sẽ được cải thiện Hiệu suất của bản dựng 32 bit.
Thêm swig/libwebp.jar vào thư mục dự án libs/.
Xây dựng dự án của bạn. Thao tác này sẽ tạo libs/<target-arch>/libwebp.so.
Sử dụng System.loadLibrary("webp") để tải thư viện trong thời gian chạy.

Xin lưu ý rằng bạn có thể tạo thư viện theo cách thủ công bằng ndk-build và các tiện ích bổ sung đi kèm Android.mk Bạn có thể sử dụng lại một số bước được mô tả ở trên trong trường hợp đó.

Làm cách nào để sử dụng libwebp với C#?

WebP có thể được xây dựng dưới dạng DLL để xuất API libwebp. Các hàm này có thể sau đó được nhập vào C#.

Tạo libwebp.dll. Thao tác này sẽ đặt WEBP_EXTERN đúng cách để xuất API .
```
libwebp> nmake /f Makefile.vc CFG=release-dynamic
```

Thêm libwebp.dll vào dự án của bạn và nhập các hàm mong muốn. Xin lưu ý rằng nếu bạn sử dụng API đơn giản bạn nên gọi WebPFree() để giải phóng mọi vùng đệm được trả về.

[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride,
                                 float quality_factor, out IntPtr output);
[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPFree(IntPtr p);

void Encode() {
  Bitmap source = new Bitmap("input.png");
  BitmapData data = source.LockBits(
      new Rectangle(0, 0, source.Width, source.Height),
      ImageLockMode.ReadOnly,
      PixelFormat.Format32bppArgb);
  IntPtr webp_data;
  const int size = WebPEncodeBGRA(data.Scan0,
                                  source.Width, source.Height, data.Stride,
                                  80, out webp_data);
  // ...
  WebPFree(webp_data);
}

Tại sao tôi nên sử dụng WebP động?

Ưu điểm của WebP động so với GIF động

WebP hỗ trợ màu RGB 24 bit với kênh alpha 8 bit, so với Màu 8 bit của GIF và alpha 1 bit.
WebP hỗ trợ cả nén có tổn hao và không tổn hao; trên thực tế, một ảnh động có thể kết hợp khung hình có tổn hao và không tổn hao. Chỉ hỗ trợ GIF nén không tổn hao. Các kỹ thuật nén có tổn hao của WebP rất phù hợp cho đến hoạt ảnh được tạo từ video thực tế, nguồn hình ảnh động.
WebP yêu cầu ít byte hơn GIF¹. Ảnh GIF động được chuyển đổi sang WebP có tổn hao nhỏ hơn 64%, đồng thời không tổn hao WebP nhỏ hơn 19%. Điều này đặc biệt quan trọng trên mạng di động.
WebP mất ít thời gian giải mã hơn khi có thao tác tìm kiếm. Trong Nhấp nháy, cuộn hoặc thay đổi thẻ có thể ẩn và hiển thị hình ảnh, dẫn đến hoạt ảnh bị tạm dừng, sau đó đã bỏ qua tới một điểm khác. Sử dụng CPU quá mức dẫn đến ảnh động thả khung cũng có thể yêu cầu bộ giải mã tìm kiếm chuyển tiếp ảnh động. Trong các trường hợp này, WebP động chiếm tổng cộng 0,57 lần thời gian giải mã² dưới dạng GIF, nhờ đó giảm hiện tượng giật trong khi cuộn và khôi phục nhanh hơn nhờ mức sử dụng CPU tăng đột biến. Đây là do hai ưu điểm của WebP so với GIF:
- Hình ảnh WebP lưu trữ siêu dữ liệu về việc mỗi khung hình có chứa alpha hay không, loại bỏ nhu cầu giải mã khung để đưa ra xác định này. Điều này dẫn đến suy luận chính xác hơn về những khung hình trước đó mà một đối tượng phụ thuộc vào, do đó giảm việc giải mã không cần thiết khung hình.
- Giống như một bộ mã hoá video hiện đại, bộ mã hoá WebP sẽ thêm theo cách suy nghiệm khung hình chính ở khoảng thời gian thông thường (điều mà hầu hết các bộ mã hoá GIF không làm được). Điều này cải thiện đáng kể việc tua trong ảnh động dài. Hỗ trợ chèn các khung hình như vậy mà không tăng đáng kể kích thước hình ảnh, WebP sẽ thêm một 'phương thức kết hợp' cờ cho từng khung hình ngoài phương thức loại bỏ khung mà GIF sử dụng. Điều này cho phép khung hình chính vẽ như thể toàn bộ hình ảnh đã bị xóa thành màu nền mà không bắt buộc khung hình trước kích thước đầy đủ.

Nhược điểm của WebP động so với GIF động

Khi không tìm kiếm, giải mã đường thẳng của WebP sẽ hiệu quả hơn Tốn CPU hơn ảnh GIF. WebP có tổn hao mất thời gian giải mã gấp 2,2 lần GIF, trong khi WebP không tổn hao chiếm 1,5 lần.
Hỗ trợ WebP không phổ biến rộng rãi như GIF hỗ trợ, tức là phổ biến một cách hiệu quả.
Việc thêm khả năng hỗ trợ WebP vào các trình duyệt sẽ làm tăng mức sử dụng mã và bề mặt tấn công. Trong Blink, đây là khoảng 1500 dòng bổ sung mã (bao gồm thư viện WebP demux và hình ảnh WebP phía Blink bộ giải mã). Xin lưu ý rằng vấn đề này có thể được giảm bớt trong tương lai nếu WebP và WebM dùng chung mã giải mã phổ biến hơn hoặc nếu WebP được đưa vào trong WebM.

Tại sao không chỉ hỗ trợ WebM trong <img>?

Về lâu dài, việc hỗ trợ các định dạng video trong <img> . Tuy nhiên, làm như vậy ngay bây giờ, với ý định mà WebM trong <img> có thể lấp đầy Vai trò đề xuất của WebP động là có vấn đề:

Khi giải mã một khung dựa trên các khung trước đó, WebM yêu cầu Bộ nhớ lớn hơn 50% so với WebP động để lưu trữ số lượng tối thiểu khung trước³.
Khả năng hỗ trợ vùng chứa và bộ mã hoá và giải mã video rất khác nhau giữa các trình duyệt và thiết bị. Để hỗ trợ quá trình chuyển mã nội dung tự động (ví dụ: proxy tiết kiệm băng thông), trình duyệt sẽ cần thêm tiêu đề chấp nhận cho biết thẻ hình ảnh của quảng cáo hỗ trợ những định dạng nào. Thậm chí điều này có thể không đủ, vì loại MIME như "video/webm" hoặc "video/mpeg" tĩnh không cho biết có hỗ trợ bộ mã hoá và giải mã (ví dụ: VP8 so với VP9). Mặt khác thì định dạng WebP sẽ bị treo một cách hiệu quả và nếu nhà cung cấp vận chuyển đồng ý gửi WebP động, hành vi của WebP trên tất cả UA phải nhất quán; và vì "image/webp" chấp nhận tiêu đề là vốn đã được dùng để cho biết rằng có hỗ trợ WebP, không có thay đổi mới nào để chấp nhận cho tiêu đề là cần thiết.
Ngăn xếp video Chromium được tối ưu hoá cho quá trình phát mượt mà và giả định rằng chỉ có một hoặc hai video đang phát trên bất cứ lúc nào. Do đó, việc triển khai tích cực trong việc tiêu thụ tài nguyên (luồng, bộ nhớ, v.v.) để tối đa hoá chất lượng phát. Đúng là không triển khai hiệu quả đối với nhiều video cùng lúc và sẽ cần được thiết kế lại cho phù hợp để sử dụng với các trang web có nhiều hình ảnh.
WebM hiện không kết hợp tất cả kỹ thuật nén từ WebP. Do đó, hình ảnh này nén tốt hơn đáng kể bằng WebP so với các phương án thay thế:

¹ Để so sánh giữa GIF động và WebP động, chúng tôi đã sử dụng một tập hợp khoảng 7000 hình ảnh GIF động được lấy ngẫu nhiên từ web. Những hình ảnh này đã được chuyển đổi sang WebP động bằng cách sử dụng "gif2webp" công cụ đang sử dụng các chế độ cài đặt mặc định (được tạo từ phiên bản cây nguồn libwebp tính đến ngày 10/8/2013). Số liệu so sánh là giá trị trung bình của hình ảnh.

² Thời gian giải mã được tính toán bằng cách sử dụng libwebp + ToT mới nhất Blink vào ngày 8/10/2013 bằng cách sử dụng công cụ đo điểm chuẩn. "Giải mã thời gian bằng cách tua" được tính là "Giải mã năm khung hình đầu tiên, xoá khung bộ nhớ đệm, giải mã năm khung tiếp theo, v.v.".

³ WebM lưu giữ 4 khung tham chiếu YUV trong bộ nhớ, với mỗi khung lưu trữ (chiều rộng+96)*(chiều cao+96) pixel. Đối với YUV 4:2:0, chúng ta cần 4 byte mỗi 6 pixel (hoặc 3/2 byte cho mỗi pixel). Vì vậy, các khung tham chiếu này sử dụng 4*3/2*(width+96)*(height+96) byte bộ nhớ. Mặt khác, WebP chỉ cần có sẵn khung hình trước đó (trong RGBA), tức là 4*width*height byte bộ nhớ.

⁴ Tính năng kết xuất WebP động yêu cầu Google Chrome phiên bản 32 trở lên