หน้านี้ได้รับการแปลโดย Cloud Translation API

คำถามที่พบบ่อย

WebP คืออะไร ทำไมฉันจึงควรใช้

WebP คือวิธีการบีบอัดแบบสูญเสียและไม่สูญเสียรายละเอียด (Losyless) ที่สามารถนำไปใช้กับ ภาพถ่ายกราฟิก ภาพโปร่งแสง และภาพกราฟิกต่างๆ ที่พบบนเว็บ ระดับของการบีบอัดแบบสูญเสียบางส่วนสามารถปรับได้ เพื่อให้ผู้ใช้สามารถเลือก เพื่อหาสมดุลระหว่างขนาดไฟล์และคุณภาพของรูป WebP มักมีข้อดี การบีบอัดไฟล์ได้มากกว่า JPEG และ JPEG 2000 โดยเฉลี่ย 30% โดยไม่สูญเสียรูปภาพ คุณภาพ (ดูการศึกษาเปรียบเทียบ)

โดยพื้นฐานแล้ว รูปแบบ WebP มีจุดประสงค์เพื่อสร้างรูปภาพที่มีขนาดเล็กลงและดูดีขึ้น ที่จะช่วยให้เว็บทำงานเร็วขึ้น

เว็บเบราว์เซอร์ใดรองรับ WebP อยู่แล้วบ้าง

ผู้ดูแลเว็บที่สนใจจะปรับปรุงประสิทธิภาพของเว็บไซต์สามารถสร้าง ทางเลือกของ WebP ที่ปรับให้เหมาะกับรูปภาพปัจจุบันมากที่สุด และแสดงไว้ใน ที่กำหนดเป้าหมายเป็นเบราว์เซอร์ที่รองรับ WebP

การรองรับ WebP แบบสูญเสียบางส่วน
- Google Chrome (เดสก์ท็อป) 17 ขึ้นไป
- Google Chrome สำหรับ Android เวอร์ชัน 25 ขึ้นไป
- Microsoft Edge 18 ขึ้นไป
- Firefox 65 ขึ้นไป
- Opera 11.10 ขึ้นไป
- เว็บเบราว์เซอร์ที่มากับระบบ Android 4.0+ (ICS)
- Safari 14 ขึ้นไป (iOS 14 ขึ้นไป, macOS Big Sur+)
WebP แบบสูญเสียบางส่วน แบบไม่สูญเสียรายละเอียด และ การสนับสนุนเวอร์ชันอัลฟ่า
- Google Chrome (เดสก์ท็อป) 23 ขึ้นไป
- Google Chrome สำหรับ Android เวอร์ชัน 25 ขึ้นไป
- Microsoft Edge 18 ขึ้นไป
- Firefox 65 ขึ้นไป
- Opera 12.10 ขึ้นไป
- เว็บเบราว์เซอร์ที่มาพร้อมเครื่อง Android 4.2 ขึ้นไป (JB-MR1)
- ชมพูซีด 26 ปีขึ้นไป
- Safari 14 ขึ้นไป (iOS 14 ขึ้นไป, macOS Big Sur+)
การรองรับ WebP Animation
- Google Chrome (เดสก์ท็อปและ Android) 32 ขึ้นไป
- Microsoft Edge 18 ขึ้นไป
- Firefox 65 ขึ้นไป
- Opera 19+
- Safari 14 ขึ้นไป (iOS 14 ขึ้นไป, macOS Big Sur+)

และดู:

ฉันจะตรวจหาการรองรับเบราว์เซอร์สำหรับ WebP ได้อย่างไร

คุณจะต้องแสดงรูปภาพ WebP แก่ลูกค้าที่แสดงภาพดังกล่าวได้เท่านั้น อย่างเหมาะสม และกลับไปใช้รูปแบบเดิมสำหรับลูกค้าที่ไม่สามารถทำได้ โชคดี มีเทคนิคหลายอย่างในการตรวจหาการรองรับ WebP ทั้ง ฝั่งไคลเอ็นต์และฝั่งเซิร์ฟเวอร์ ผู้ให้บริการ CDN บางรายมีการตรวจหาการรองรับ WebP เป็นส่วนหนึ่งของบริการ

การเจรจาต่อรองเนื้อหาฝั่งเซิร์ฟเวอร์ผ่าน "ยอมรับส่วนหัว"

เป็นเรื่องปกติที่ไคลเอ็นต์เว็บจะส่งปุ่ม "ยอมรับ" ส่วนหัวของคำขอ ซึ่งระบุ รูปแบบเนื้อหาที่พวกเขา ยินดียอมรับในการตอบสนอง หากมี เบราว์เซอร์ระบุล่วงหน้าว่าจะ "ยอมรับ" รูปแบบ image/webp เว็บเซิร์ฟเวอร์รู้ว่าจะสามารถส่งรูปภาพ WebP ได้อย่างปลอดภัย ซึ่งเป็นการลดความซับซ้อน Content negotiation ดูข้อมูลเพิ่มเติมได้ที่ลิงก์ต่อไปนี้

Modernizr

Modernizr เป็นไลบรารี JavaScript เพื่อให้ตรวจหา HTML5 และ การรองรับฟีเจอร์ CSS3 ในเว็บเบราว์เซอร์ มองหาที่พัก Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha และ Modernizr.webp.animation

องค์ประกอบ `<picture>` ของ HTML5

HTML5 รองรับเอลิเมนต์ <picture> ซึ่งให้คุณแสดงรายการได้หลายรายการ เป้าหมายรูปภาพอื่นตามลำดับความสำคัญ ซึ่งลูกค้าจะส่งคำขอ ภาพของตัวเลือกแรกที่สามารถแสดงได้อย่างถูกต้อง โปรดดู การพูดคุยเกี่ยวกับ HTML5 Rocks นี้ องค์ประกอบ <picture> คือ ได้รับการรองรับโดยเบราว์เซอร์ต่างๆ มากขึ้นอยู่ตลอดเวลา

ใน JavaScript ของคุณเอง

วิธีตรวจหาอีกวิธีหนึ่งคือการพยายามถอดรหัสรูปภาพ WebP ที่มีขนาดเล็กมากซึ่ง ใช้ฟีเจอร์ที่เจาะจงและตรวจสอบความสำเร็จ ตัวอย่าง

// 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];
}

โปรดทราบว่าการโหลดรูปภาพจะไม่บล็อกและไม่พร้อมกัน ซึ่งหมายความว่า คุณควรใส่โค้ดที่ขึ้นอยู่กับการสนับสนุน WebP ไว้ใน Callback

ทำไม Google จึงเปิดตัว WebP เป็นโอเพนซอร์ส

เราเชื่อมั่นในความสำคัญของโมเดลโอเพนซอร์สนี้ มี WebP อยู่ใน แบบโอเพนซอร์ส ทุกคนสามารถทำงานกับรูปแบบนี้และแนะนำการปรับปรุงได้ ด้วย ข้อมูลและคำแนะนำของคุณ เราเชื่อว่า WebP จะมีประโยชน์มากยิ่งขึ้นไปอีก เป็นรูปแบบกราฟิกได้เมื่อเวลาผ่านไป

ฉันจะแปลงไฟล์รูปภาพส่วนตัวเป็น WebP ได้อย่างไร

คุณสามารถใช้ยูทิลิตีบรรทัดคำสั่ง WebP เพื่อแปลงไฟล์ภาพส่วนตัว เป็นรูปแบบ WebP ดูรายละเอียดเพิ่มเติมได้ที่การใช้ WebP

หากคุณมีรูปภาพจำนวนมากที่จะแปลง คุณสามารถใช้ Shell ของแพลตฟอร์มเพื่อ ช่วยให้การดำเนินการง่ายขึ้น เช่น หากต้องการแปลงไฟล์ jpeg ทั้งหมดในโฟลเดอร์ ให้ลอง ดังต่อไปนี้

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

ฉันจะประเมินคุณภาพรูปภาพ WebP สำหรับตนเองได้อย่างไร

ปัจจุบัน คุณดูไฟล์ WebP ได้โดยแปลงไฟล์ให้เป็นรูปแบบที่ใช้กันทั่วไป ที่ใช้การบีบอัดแบบไม่สูญเสียรายละเอียด เช่น PNG จากนั้นดูไฟล์ PNG ใน เบราว์เซอร์หรือโปรแกรมดูรูปภาพ หากต้องการทำความเข้าใจคร่าวๆ เกี่ยวกับคุณภาพ WebP โปรดดู แกลเลอรีในเว็บไซต์นี้สำหรับรูปภาพที่แสดงคู่กัน เปรียบเทียบ

ฉันจะรับซอร์สโค้ดได้อย่างไร

โค้ด Conversion มีอยู่ใน ส่วนการดาวน์โหลดของโปรเจ็กต์โอเพนซอร์ส WebP โค้ดสำหรับตัวถอดรหัสน้ำหนักเบาและข้อกำหนด VP8 เปิดอยู่ เว็บไซต์ WebM โปรดดู หน้าคอนเทนเนอร์ RIFF สำหรับคอนเทนเนอร์

รูปภาพ WebP มีขนาดได้สูงสุดเท่าใด

โดย WebP เป็นบิตสตรีมที่เข้ากันได้กับ VP8 และใช้ 14 บิตสำหรับความกว้างและความสูง ขนาดพิกเซลสูงสุดของรูปภาพ WebP คือ 16383 x 16383

รูปแบบ WebP รองรับพื้นที่สีใดบ้าง

lossy WebP ทำงานเฉพาะกับ รูปแบบรูปภาพ Y'CbCr 4:2:0 แบบ 8 บิต (มักเรียกว่า YUV420) โปรดดูส่วน 2, "ภาพรวมของรูปแบบ" RFC 6386 คู่มือรูปแบบข้อมูลและการถอดรหัส VP8 เพื่อดูรายละเอียดเพิ่มเติม

Lossless WebP จะทํางานร่วมกับรูปแบบ RGBA เท่านั้น โปรดดู ข้อกำหนด Bitstream แบบไม่สูญเสียรายละเอียดของ WebP

รูปภาพ WebP มีขนาดใหญ่กว่ารูปภาพต้นฉบับได้ไหม

ได้ โดยทั่วไปแล้วเมื่อแปลงจากรูปแบบ Lossy เป็น WebP แบบไม่สูญเสียรายละเอียด หรือ ในทางกลับกัน สาเหตุหลักมาจากความแตกต่างของพื้นที่สี (YUV420 เทียบกับ ARGB) และ Conversion ระหว่าง Conversion เหล่านี้

โดยทั่วไปมี 3 สถานการณ์ต่อไปนี้

หากรูปภาพต้นฉบับอยู่ในรูปแบบ ARGB แบบไม่สูญเสียรายละเอียด การลดขนาดเชิงพื้นที่ ไปจนถึง YUV420 จะได้ใช้สีใหม่ที่บีบอัดได้ยากกว่า รายการเดิม สถานการณ์นี้มักเกิดขึ้นเมื่อแหล่งข้อมูล อยู่ในรูปแบบ PNG ที่มีสีไม่กี่สี: แปลงเป็น WebP แบบสูญเสียบางส่วน (หรือคล้ายกัน เป็น JPEG แบบสูญเสียบางส่วน) ก็อาจทำให้ขนาดไฟล์ใหญ่ขึ้น
หากแหล่งที่มาอยู่ในรูปแบบสูญเสียบางส่วน โดยใช้การบีบอัด WebP แบบไม่สูญเสียรายละเอียด ในการบันทึกลักษณะแบบสูญเสีย ของแหล่งที่มามักจะส่งผลให้เกิด ไฟล์ขนาดใหญ่กว่า เรื่องนี้ไม่ได้เกี่ยวข้องกับ WebP โดยเฉพาะ และอาจเกิดขึ้นเมื่อ เช่น การแปลงซอร์ส JPEG เป็นรูปแบบ WebP หรือ PNG แบบไม่สูญเสียรายละเอียด
หากต้นฉบับอยู่ในรูปแบบสูญหายและคุณกำลังพยายามบีบอัด เป็น WebP แบบสูญเสียบางส่วนและมีการตั้งค่าคุณภาพสูงกว่า ตัวอย่างเช่น การพยายามทำ แปลงไฟล์ JPEG ที่บันทึกที่คุณภาพ 80 เป็นไฟล์ WebP ที่มีคุณภาพ 95 จะทำให้ไฟล์มีขนาดใหญ่กว่า แม้ว่าทั้งสองรูปแบบจะสูญเสียข้อมูลก็ตาม การประเมินคุณภาพของแหล่งที่มามักจะเป็นไปไม่ได้ จึงขอแนะนําให้ ลดคุณภาพ WebP เป้าหมายลงหากไฟล์มีขนาดใหญ่ขึ้นอย่างสม่ำเสมอ อีกความเป็นไปได้ก็คือ หลีกเลี่ยงการใช้การตั้งค่าคุณภาพ และ กำหนดขนาดไฟล์เป้าหมายที่ต้องการโดยใช้ตัวเลือก -size ในเครื่องมือcwebp หรือ API ที่เทียบเท่า ตัวอย่างเช่น การกำหนดเป้าหมาย 80% ของไฟล์ต้นฉบับ ขนาดอาจเหมาะสมกว่า

โปรดทราบว่าการแปลงแหล่งที่มา JPEG เป็น WebP แบบสูญเสียบางส่วน หรือแหล่งที่มา PNG เป็นแบบไม่สูญเสียรายละเอียด WebP ไม่มีแนวโน้มที่จะทำให้เกิดขนาดไฟล์ที่ไม่คาดคิด

WebP รองรับการแสดงผลแบบโปรเกรสซีฟหรือแบบอินเตอร์เลซไหม

WebP ไม่มีการรีเฟรชการถอดรหัสแบบโพรเกรสซีฟหรือแบบอินเตอร์เลซใน JPEG หรือ รู้สึกแบบ PNG ซึ่งมีแนวโน้มที่จะเพิ่มแรงกดดันให้กับ CPU และหน่วยความจำของ การถอดรหัสไคลเอ็นต์เนื่องจากเหตุการณ์การรีเฟรชแต่ละครั้งจะต้องมีการส่งผ่าน ยกเลิกการบีบอัด

โดยเฉลี่ยแล้ว การถอดรหัสภาพ JPEG แบบโปรเกรสซีฟเทียบเท่ากับการถอดรหัส เกณฑ์พื้นฐาน 1 ครั้ง 3 ครั้ง

นอกจากนี้ WebP จะเสนอการถอดรหัสเพิ่มขึ้น เมื่อรองรับการถอดรหัสทั้งหมด ระบบจะใช้ไบต์ของบิตสตรีมเพื่อพยายามสร้างแถวตัวอย่างที่แสดงได้ โดยเร็วที่สุด ซึ่งช่วยประหยัดหน่วยความจำ, CPU และการระบายสีใหม่บน ของคุณในขณะที่ให้ภาพบ่งบอกสถานะการดาวน์โหลด ส่วนเพิ่ม ฟีเจอร์การถอดรหัสพร้อมใช้งานผ่าน API การถอดรหัสขั้นสูง

ฉันจะใช้การเชื่อมโยง Java ของ libwebp ในโปรเจ็กต์ Android ได้อย่างไร

WebP มีการรองรับการเชื่อมโยง JNI กับโปรแกรมเปลี่ยนไฟล์และตัวถอดรหัสแบบง่าย ในไดเรกทอรี swig/

การสร้างไลบรารีใน Eclipse:

ตรวจสอบว่าคุณมี ปลั๊กอิน ADT ที่ติดตั้งในเครื่องมือ NDK และเส้นทาง NDK ได้รับการตั้งค่าอย่างถูกต้อง (ค่ากำหนด > Android > NDK)
สร้างโปรเจ็กต์ใหม่: ไฟล์ > ใหม่ > โปรเจ็กต์ > Android โปรเจ็กต์แอปพลิเคชัน
โคลน หรือ คลายแพ็ก libwebp ไปยังโฟลเดอร์ชื่อ jni ในโปรเจ็กต์ใหม่
เพิ่ม swig/libwebp_java_wrap.c ในรายการ LOCAL_SRC_FILES
คลิกขวาที่โปรเจ็กต์ใหม่และเลือก Android Tools > เพิ่ม การสนับสนุนดั้งเดิม ... เพื่อรวมไลบรารีไว้ในบิลด์ของคุณ
เปิดคุณสมบัติของโครงการและไปที่ C/C++ บิลด์ > ลักษณะการทำงาน เพิ่ม ENABLE_SHARED=1 ไปยังส่วน Build (Incremental build) เพื่อสร้าง libwebp เป็นไลบรารีที่ใช้ร่วมกัน

หมายเหตุ การตั้งค่า NDK_TOOLCHAIN_VERSION=4.8 จะปรับปรุงโดยทั่วไป ประสิทธิภาพของบิลด์ 32 บิต
เพิ่ม swig/libwebp.jar ไปยังโฟลเดอร์โปรเจ็กต์ libs/
สร้างโปรเจ็กต์ การดำเนินการนี้จะสร้าง libs/<target-arch>/libwebp.so
ใช้ System.loadLibrary("webp") เพื่อโหลดไลบรารี ณ รันไทม์

โปรดทราบว่าสามารถสร้างไลบรารีด้วยตนเองได้โดยใช้ ndk-build และ Android.mk ในกรณีนี้ คุณนำขั้นตอนบางอย่างที่อธิบายไว้ข้างต้นมาใช้ใหม่ได้

ฉันจะใช้ libwebp กับ C# ได้อย่างไร

WebP สามารถสร้างเป็น DLL ซึ่งจะส่งออก libwebp API ฟังก์ชันเหล่านี้ เพื่อนำเข้าใน C#

สร้าง libwebp.dll การดำเนินการนี้จะตั้งค่า WEBP_EXTERN อย่างเหมาะสมให้ส่งออก API
```
libwebp> nmake /f Makefile.vc CFG=release-dynamic
```

เพิ่ม libwebp.dll ลงในโปรเจ็กต์และนำเข้าฟังก์ชันที่ต้องการ โปรดทราบว่าหากใช้ API แบบง่าย คุณควรเรียกใช้ WebPFree() เพื่อเพิ่มพื้นที่ว่างสำหรับบัฟเฟอร์ที่แสดงผล

[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);
}

เหตุใดฉันจึงควรใช้ WebP แบบภาพเคลื่อนไหว

ข้อดีของ WebP แบบเคลื่อนไหวเมื่อเทียบกับ GIF แบบเคลื่อนไหว

WebP รองรับสี RGB 24 บิตพร้อมด้วยช่องอัลฟ่า 8 บิตเมื่อเทียบกับ สี 8 บิตและอัลฟ่า 1 บิตของ GIF
WebP รองรับทั้งการบีบอัดแบบสูญเสียบางส่วนและไม่สูญเสียข้อมูล จริงๆ แล้ว งาน ภาพเคลื่อนไหวสามารถรวมเฟรมแบบสูญเสียบางส่วนและไม่สูญเสียรายละเอียดได้ GIF รองรับเฉพาะ แบบไม่สูญเสียรายละเอียด เทคนิคการบีบอัดแบบสูญเสียบางส่วนของ WebP เหมาะสมอย่างยิ่ง ไปจนถึงภาพเคลื่อนไหวที่สร้างจากวิดีโอในชีวิตจริง ซึ่งเป็นความนิยมที่เพิ่มขึ้น ของภาพเคลื่อนไหว
WebP ต้องใช้ไบต์น้อยกว่า GIF¹ GIF แบบเคลื่อนไหวที่แปลงเป็น WebP แบบสูญเสียบางส่วนมีขนาดเล็กลง 64% โดยไม่สูญเสียรายละเอียด WebP มีขนาดเล็กกว่า 19% ซึ่งเป็นสิ่งสำคัญโดยเฉพาะอย่างยิ่งสำหรับเครือข่ายมือถือ
WebP ใช้เวลาน้อยกว่าในการถอดรหัสเมื่อมีการกรอวิดีโอ ใน การกะพริบ การเลื่อนหรือเปลี่ยนแท็บสามารถ ซ่อนและแสดงรูปภาพ ซึ่งจะทำให้ภาพเคลื่อนไหวหยุดชั่วคราวแล้ว ข้ามไปยังจุดอื่น การใช้ CPU มากเกินไปซึ่งส่งผลให้เกิด ภาพเคลื่อนไหวที่วางเฟรมยังต้องใช้ตัวถอดรหัสเพื่อกรอไปข้างหน้า ภาพเคลื่อนไหว ในสถานการณ์เหล่านี้ WebP ที่เป็นภาพเคลื่อนไหวจะใช้ยอดรวมสูงถึง 0.57 เท่า decode time ² เป็น GIF ทำให้การกระตุกน้อยลง ในระหว่างการเลื่อนและการกู้คืนที่เร็วขึ้นจากการใช้งาน CPU ที่เพิ่มขึ้นอย่างรวดเร็ว นี่คือ ข้อดี 2 ข้อของ WebP ที่เหนือกว่า GIF มีดังนี้
- รูปภาพ WebP จัดเก็บข้อมูลเมตาที่ระบุว่าแต่ละเฟรมมีอัลฟ่าหรือไม่ โดยไม่จำเป็นต้องถอดรหัสเฟรม จึงช่วยให้อนุมานได้แม่นยำยิ่งขึ้นว่าเฟรมใดก่อนหน้านี้ ขึ้นอยู่กับเฟรม จึงช่วยลดการถอดรหัสที่ไม่จำเป็นของ ของเฟรม
- โปรแกรมเปลี่ยนไฟล์ WebP มีความสามารถเหมือนกับโปรแกรมเปลี่ยนไฟล์วิดีโอสมัยใหม่ คีย์เฟรมในช่วงเวลาที่สม่ำเสมอ (ซึ่งโปรแกรมเปลี่ยนไฟล์ GIF ส่วนใหญ่ไม่มี) วิธีนี้ช่วยปรับปรุงการค้นหาในภาพเคลื่อนไหวขนาดยาวได้อย่างมาก เพื่ออำนวยความสะดวก การแทรกเฟรมดังกล่าวโดยไม่ทำให้ขนาดภาพเพิ่มขึ้นอย่างมาก WebP เพิ่ม "Bilding Method" แจ้ง สำหรับแต่ละเฟรม นอกเหนือจากวิธีการกำจัดเฟรมที่ GIF ใช้ การทำเช่นนี้ทำให้คีย์เฟรมสามารถวาดได้เสมือนว่าได้ล้างรูปภาพทั้งรูปแล้ว เป็นสีพื้นหลังโดยไม่บังคับให้เฟรมก่อนหน้าเป็น ขนาดเต็ม

ข้อเสียของ WebP แบบเคลื่อนไหวเมื่อเทียบกับ GIF แบบเคลื่อนไหว

หากไม่มีการค้นหา การถอดรหัสแบบเส้นตรงของ WebP ก็จะมีประสิทธิภาพกว่า ใช้ CPU หนักกว่า GIF Lossy WebP ใช้เวลาถอดรหัสมากถึง 2.2 เท่า GIF ขณะที่ WebP แบบไม่สูญเสียรายละเอียดจะใช้เวลามากกว่า 1.5 เท่า
การรองรับ WebP ไม่ได้ครอบคลุมเกือบเท่าการรองรับ GIF ซึ่ง เป็นสากลได้อย่างมีประสิทธิภาพ
การเพิ่มการรองรับ WebP ในเบราว์เซอร์จะเพิ่มการใช้งานโค้ดและ พื้นที่การโจมตี ใน Blink จะมีบรรทัดเพิ่มเติมประมาณ 1,500 บรรทัด (รวมถึงไลบรารี WebP demux และรูปภาพ WebP แบบ Blink-side ตัวถอดรหัส) โปรดทราบว่าปัญหานี้อาจลดลงได้ในอนาคต หาก WebP และ WebM ใช้โค้ดถอดรหัสที่ใช้กันทั่วไปมากกว่า หรือหาก WebP จะมาอยู่ใน WebM

เหตุใดจึงไม่เพียงแค่รองรับ WebM ใน <img>

การรองรับรูปแบบวิดีโอใน <img> อาจมีประโยชน์ในระยะยาว แท็ก อย่างไรก็ตาม ด้วย Intent ที่ WebM ใน <img> จะกรอกข้อมูล บทบาทที่นำเสนอของ WebP แบบภาพเคลื่อนไหวนั้นก่อให้เกิดปัญหาดังนี้

เมื่อถอดรหัสเฟรมที่ใช้เฟรมก่อนหน้า WebM จะต้องใช้ หน่วยความจำมากกว่า WebP แบบเคลื่อนไหว 50% เพื่อให้ได้จำนวนขั้นต่ำ เฟรมก่อนหน้า³
ตัวแปลงรหัสวิดีโอและการรองรับคอนเทนเนอร์จะแตกต่างกันไปในแต่ละเบราว์เซอร์และ อุปกรณ์ เพื่ออำนวยความสะดวกในการแปลงเนื้อหาอัตโนมัติ (เช่น พร็อกซีแบบประหยัดแบนด์วิดท์) เบราว์เซอร์จะต้องเพิ่มส่วนหัวที่ยอมรับ โดยระบุรูปแบบที่แท็กรูปภาพรองรับ แม้แต่สิ่งนี้อาจจะเป็น ไม่เพียงพอ เนื่องจากประเภท MIME เช่น "วิดีโอ/webm" หรือ "video/mpeg" นิ่ง ไม่ระบุการรองรับตัวแปลงรหัส (เช่น VP8 กับ VP9) ในอีกทาง รูปแบบ WebP นั้นหยุดนิ่งอย่างมีประสิทธิภาพ และถ้าผู้ขายที่จัดส่งสินค้า บริษัทตกลงว่าจะมีการส่ง WebP ที่เป็นภาพเคลื่อนไหว ซึ่งเป็นลักษณะการทำงานของ WebP ใน UA ทั้งหมด ควรสอดคล้องกัน และเนื่องจาก "image/webp" ส่วนหัวที่ยอมรับคือ ใช้เพื่อแสดงการรองรับ WebP แล้ว ไม่มีการเปลี่ยนแปลงส่วนหัวที่ยอมรับใหม่ ถือเป็นสิ่งจำเป็น
กลุ่มวิดีโอ Chromium ได้รับการเพิ่มประสิทธิภาพเพื่อ การเล่นได้อย่างราบรื่น และถือว่ามีวิดีโอเพียง 1-2 รายการที่กำลังเล่น ด้วยเหตุนี้ การนำไปใช้งานจึงเป็นเชิงรุกมากขึ้นสำหรับระบบที่ใช้ ทรัพยากร (ชุดข้อความ หน่วยความจำ ฯลฯ) เพื่อคุณภาพการเล่นสูงสุด เช่น นำไปใช้งานพร้อมกันไม่ได้ สำหรับหลายๆ วิดีโอ ต้องออกแบบใหม่ให้เหมาะสำหรับใช้กับหน้าเว็บที่เน้นรูปภาพ
ปัจจุบัน WebM ไม่ได้รวมเทคนิคการบีบอัดทั้งหมด จาก WebP ด้วยเหตุนี้ รูปภาพนี้ จะได้รับการบีบอัดด้วย WebP ที่ดีกว่าทางเลือกอื่นๆ อย่างมาก:

¹ สำหรับการเปรียบเทียบทั้งหมดระหว่าง GIF แบบเคลื่อนไหวและ WebP แบบเคลื่อนไหว เรา ใช้คลังรูปภาพ GIF แบบเคลื่อนไหวประมาณ 7,000 รูปที่ถ่ายแบบสุ่มจากเว็บ รูปภาพเหล่านี้แปลงเป็น WebP แบบเคลื่อนไหวโดยใช้ "gif2webp" การใช้เครื่องมือ การตั้งค่าเริ่มต้น (สร้างจาก แผนผังแหล่งที่มาของ libwebp ณ วันที่ 08/10/2013) จำนวนเปรียบเทียบคือค่าเฉลี่ยของตัวเลขเหล่านี้ รูปภาพ

² เวลาถอดรหัสจะคํานวณโดยใช้ libwebp + ToT ล่าสุด Blink ข้อมูล ณ วันที่ 08/10/2013 โดยใช้เครื่องมือการเปรียบเทียบ "เวลาถอดรหัส ด้วยการกรอวิดีโอ" ที่คำนวณเป็น "ถอดรหัส 5 เฟรมแรก ล้างเฟรม แคชบัฟเฟอร์ ถอดรหัส 5 เฟรมถัดไป เป็นต้น"

³ WebM จะเก็บเฟรมอ้างอิง YUV เฟรมไว้ในหน่วยความจำ 1 เฟรม โดยแต่ละเฟรม การจัดเก็บ (กว้าง+96)*(ความสูง+96) พิกเซล สำหรับ YUV 4:2:0 เราต้องการ 4 ไบต์ต่อ 6 พิกเซล (หรือ 3/2 ไบต์ต่อพิกเซล) ดังนั้น เฟรมอ้างอิงเหล่านี้ใช้ หน่วยความจำ 4*3/2*(width+96)*(height+96) ไบต์ ในขณะที่ WebP ต้องใช้เฉพาะเฟรมก่อนหน้า (ใน RGBA) เท่านั้น กล่าวคือ หน่วยความจำ 4*width*height ไบต์

⁴ การแสดงผล WebP แบบภาพเคลื่อนไหวต้องใช้ Google Chrome เวอร์ชัน 32 ขึ้นไป