แต่เดิม Google ได้พัฒนา WebP เป็นรูปแบบรูปภาพแบบสูญเสียบางส่วนเพื่อแทนที่ JPEG ซึ่งเป็นไฟล์ที่สามารถสร้างไฟล์ที่มีขนาดเล็กกว่าไฟล์ภาพคุณภาพระดับเทียบเคียงซึ่งเข้ารหัสเป็น JPEG ได้ การอัปเดตรูปแบบในภายหลังได้แนะนำตัวเลือกในการบีบอัดแบบไม่สูญเสียรายละเอียด ความโปร่งใสของช่องอัลฟ่าแบบ PNG และภาพเคลื่อนไหวคล้าย GIF โดยทั้ง 2 แบบนี้สามารถใช้ควบคู่กับการบีบอัดแบบสูญเสียบางส่วนในรูปแบบ JPEG WebP เป็นรูปแบบที่อเนกประสงค์ไม่น่าเชื่อ
อัลกอริทึมการบีบอัดแบบสูญเสียบางส่วนของ WebP อิงตามวิธีที่ตัวแปลงรหัสวิดีโอ VP8 ใช้ในการบีบอัดคีย์เฟรมในวิดีโอ ในระดับสูง จะคล้ายกับการเข้ารหัส JPEG กล่าวคือ WebP ทำงานในรูปแบบ "บล็อก" ไม่ใช่แบบพิกเซลแต่ละพิกเซล และมีระดับความสว่างและสีตรงกันข้ามเหมือนกัน บล็อก Luma ของ WebP มีขนาด 16x16 ขณะที่โครมาบล็อกมีขนาด 8x8 และ "macroblocks" จะแยกย่อยออกเป็นบล็อกย่อยขนาด 4x4 ด้วยเช่นกัน
โดยที่ WebP แตกต่างจาก JPEG อย่างสิ้นเชิงใน 2 ฟีเจอร์ ได้แก่ "การคาดการณ์แบบบล็อก" และ "การวัดจำนวนบล็อกแบบปรับเปลี่ยนได้"
บล็อกการคาดการณ์
การคาดการณ์แบบบล็อกคือกระบวนการในการคาดการณ์เนื้อหาของบล็อกสีและความสว่างแต่ละบล็อกตามค่าของบล็อกที่อยู่โดยรอบ โดยเฉพาะบล็อกที่อยู่ด้านบนและด้านซ้ายของบล็อกปัจจุบัน คุณอาจจะจินตนาการได้ว่าอัลกอริทึมที่ใช้ทำงานนี้ค่อนข้างซับซ้อน แต่หากใช้ภาษาง่ายๆ เช่น "หากมีสีน้ำเงินเหนือบล็อกปัจจุบันและด้านซ้ายของบล็อกปัจจุบัน ให้สมมติว่าบล็อกปัจจุบันมีสีน้ำเงิน"
ในความเป็นจริง ทั้ง PNG และ JPEG ก็ทำการคาดคะเนแบบนี้บางระดับด้วยเช่นกัน อย่างไรก็ตาม WebP มีความพิเศษตรงที่สุ่มตัวอย่างข้อมูลของบล็อกโดยรอบ แล้วพยายามเติมข้อมูลบล็อกปัจจุบันโดยใช้ "โหมดการคาดการณ์" ต่างๆ อย่างมีประสิทธิภาพโดยพยายาม "วาด" ส่วนที่หายไปของรูปภาพ จากนั้นระบบจะนำผลลัพธ์ที่ได้จากโหมดการคาดการณ์แต่ละโหมดไปเปรียบเทียบกับข้อมูลรูปภาพจริง จากนั้นจึงเลือกการจับคู่ที่คาดการณ์ที่ใกล้เคียงที่สุด
แน่นอนว่าแม้แต่การจับคู่แบบคาดคะเนที่ใกล้เคียงที่สุดก็อาจไม่ใช่ผลลัพธ์ที่ถูกต้องนัก ดังนั้นความแตกต่างระหว่างค่าที่คาดการณ์และค่าจริงของการบล็อกนั้นจะถูกเข้ารหัสในไฟล์ เมื่อถอดรหัสรูปภาพ เครื่องมือการแสดงผลจะใช้ข้อมูลเดียวกันเพื่อนําตรรกะตามการคาดการณ์เดียวกันไปใช้ ซึ่งจะทําให้มีค่าที่คาดการณ์ไว้สําหรับแต่ละบล็อกเท่ากัน จากนั้นระบบจะนำความแตกต่างระหว่างการคาดการณ์และอิมเมจที่คาดไว้ที่เข้ารหัสไว้ในไฟล์ไปก่อนในการคาดการณ์ ซึ่งคล้ายกับการที่ Git คอมมิตแสดง Differential Patch ที่ใช้กับไฟล์ในเครื่อง แทนที่จะเป็นสำเนาใหม่ของไฟล์
เพื่อให้เห็นภาพว่า เราจะคิดค้นการเข้ารหัสแบบ WebP ที่มีโหมดการคาดการณ์แบบเดี่ยวขึ้นมา แทนที่จะเจาะลึกถึงการคำนวณที่ซับซ้อนซึ่งเกี่ยวข้องกับอัลกอริทึมการคาดการณ์ที่แท้จริง และใช้เพื่อส่งต่อตารางตัวเลขอย่างมีประสิทธิภาพแบบที่เราใช้กับรูปแบบเดิม อัลกอริทึมของเรามีโหมดการคาดการณ์แบบเดียว ซึ่งเราเรียกว่า "โหมดการคาดการณ์ 1" ค่าของแต่ละบล็อกคือผลรวมของค่าของบล็อกที่อยู่สูงกว่าและทางด้านซ้ายของบล็อก โดยเริ่มด้วย 1
ทีนี้สมมติว่าเราเริ่มด้วยข้อมูลภาพจริงต่อไปนี้
111151111
122456389
เราจะได้ผลลัพธ์ต่อไปนี้เมื่อใช้โมเดลการคาดการณ์เพื่อระบุเนื้อหาของตารางกริดขนาด 2x9
111111111
123456789
ข้อมูลของเราเหมาะกับอัลกอริทึมการคาดคะเนที่เราคิดค้นขึ้น โดยข้อมูลที่คาดการณ์นั้นใกล้เคียงกับข้อมูลจริงของเรา แน่นอนว่าข้อมูลยังไม่สมบูรณ์แบบ ข้อมูลจริงมีลักษณะแตกต่างจากข้อมูลที่คาดการณ์ไว้อยู่หลายช่วง ดังนั้นการเข้ารหัสที่เราส่งไม่ได้มีเพียงวิธีการคาดการณ์ที่จะใช้เท่านั้น แต่ยังรวมถึงความแตกต่างของบล็อกที่ควรแตกต่างจากค่าที่คาดการณ์ไว้ด้วย
_ _ _ _ +4 _ _ _ _
_ _ -1 _ _ _ -4 _ _
วางภาษาง่ายๆ เช่นเดียวกับการเข้ารหัสของรูปแบบเดิมบางส่วนที่เราได้กล่าวถึง:
ตารางกริดขนาด 2x9 โดยใช้โหมดการคาดการณ์ 1 +4 ถึง 1x5, -1 ถึง 2x3, -4 ถึง 2x7
ผลลัพธ์ที่ได้คือไฟล์เข้ารหัสที่มีประสิทธิภาพอย่างไม่น่าเชื่อ
การวัดปริมาณบล็อกแบบปรับอัตโนมัติ
การบีบอัด JPEG เป็นการดำเนินการแบบครอบคลุม โดยใช้การวัดปริมาณในระดับเดียวกับบล็อกทั้งหมดในรูปภาพ ในรูปภาพที่มีการจัดองค์ประกอบแบบเดียวกันนั้นถือว่าเหมาะสมแล้ว แต่รูปภาพในโลกความเป็นจริงนั้นไม่เหมือนกับโลกรอบตัวเรา ในทางปฏิบัติ การตั้งค่าการบีบอัด JPEG ของเราไม่ได้กำหนดโดยรายละเอียดความถี่สูง ซึ่งการบีบอัด JPEG สามารถทำได้อย่างดี แต่เป็นส่วนของภาพของเราที่มีโอกาสสร้างการบีบอัดมากที่สุด
อย่างที่เห็นในตัวอย่างที่เกินจริงนี้ ปีกของกษัตริย์ในเบื้องหน้าดูค่อนข้างคมชัด เป็นเม็ดหยาบเล็กน้อยเมื่อเทียบกับต้นฉบับที่มีความละเอียดสูง แต่แน่นอนว่าจะสังเกตเห็นไม่ได้หากไม่มีของดั้งเดิมเทียบเคียง ในทำนองเดียวกัน ขยายออกของนมวัวและใบไม้ในเบื้องหน้า คุณและผมก็อาจเห็นร่องรอยของสิ่งประดิษฐ์ที่ใช้บีบอัดด้วยตาของเรา แต่แม้จะมีการบีบอัดซึ่งปรับขยายออกมาได้เกินกว่าระดับที่เหมาะสม สิ่งที่อยู่เบื้องหน้าก็ยังคงดูคมชัด ข้อมูลความถี่ต่ำที่ด้านซ้ายบนของรูปภาพหรือฉากหลังสีเขียวเบลอของใบไม้ดูแย่ แม้แต่ผู้ชมที่ยังไม่ได้ฝึก ก็จะสังเกตเห็นปัญหาด้านคุณภาพทันที การไล่ระดับสีแบบเบาๆ ในพื้นหลังจะปัดลงเป็นบล็อกสีทึบแบบหยัก
เพื่อหลีกเลี่ยงปัญหานี้ WebP จึงใช้วิธีปรับเปลี่ยนในการวัดปริมาณ กล่าวคือ รูปภาพจะแบ่งออกเป็นกลุ่มที่มีลักษณะคล้ายกันสูงสุด 4 กลุ่ม และจะมีการปรับแต่งพารามิเตอร์การบีบอัดสำหรับกลุ่มเหล่านั้นแยกกัน การใช้การบีบอัดที่มีขนาดเกินขนาดเดียวกันใน WebP
ไฟล์ภาพทั้ง 2 ไฟล์มีขนาดใกล้เคียงกัน เมื่อดูปีกกษัตริย์ คุณภาพก็พอๆ กัน เมื่อดูปีกของกษัตริย์ คุณจะเห็นความแตกต่างเล็กๆ น้อยๆ ในผลลัพธ์สุดท้ายหากดูใกล้ชิดมาก แต่คุณภาพโดยรวมไม่มีอะไรต่างกันเลย ใน WebP นั้น ดอกมิลวีดจะคมชัดกว่านิดหน่อย แต่น่าจะไม่ชัดพอที่จะเห็นได้ชัด เว้นแต่ว่าคุณจะเปรียบเทียบ 2 อย่างนี้เปรียบเทียบกันจริงๆ แล้วมองหาความแตกต่างในคุณภาพอย่างที่เราเห็นอยู่ รูปภาพพื้นหลังเป็นเรื่องราวที่ต่างกัน โดยภาพรวมนั้นแทบจะไม่มีร่องรอยของสิ่งประดิษฐ์อันเจิดจ้าของ JPEG เลยทีเดียว WebP ให้ขนาดไฟล์เท่ากัน แต่รูปภาพมีคุณภาพสูงกว่ามาก โดยให้หรือถ่ายภาพรายละเอียดเล็กๆ น้อยๆ ที่ระบบภาพจิตของเราไม่สามารถตรวจพบได้หากเราไม่ได้เปรียบเทียบรูปภาพทั้ง 2 ขนาดนี้อย่างใกล้ชิด
การใช้ WebP
การทำงานภายในของ WebP อาจซับซ้อนกว่าการเข้ารหัส JPEG มาก แต่สำหรับวัตถุประสงค์ในการทำงานประจำวันของเรานั้นง่ายมาก กล่าวคือ ความซับซ้อนทั้งหมดของการเข้ารหัส WebP จะมีมาตรฐานอยู่ที่ค่า "คุณภาพ" ค่าเดียวซึ่งแสดงตั้งแต่ 0-100 เช่นเดียวกับ JPEG อย่างไรก็ตาม ไม่ได้หมายความว่าคุณจะจำกัดการตั้งค่า "คุณภาพ" เพียงการตั้งค่าเดียว คุณสามารถและควรปรับแต่งรายละเอียดทั้งหมดของการเข้ารหัส WebP เพื่อให้เข้าใจได้ดีขึ้นว่าการตั้งค่าที่ปกติแล้วมองไม่เห็นเหล่านี้ส่งผลต่อขนาดและคุณภาพของไฟล์อย่างไร
Google มีโปรแกรมเปลี่ยนไฟล์สำหรับบรรทัดคำสั่ง cwebp ที่ช่วยให้คุณแปลงหรือบีบอัดไฟล์รูปภาพทีละไฟล์หรือทั้งไดเรกทอรีได้
$ cwebp -q 80 butterfly.jpg -o butterfly.webp
Saving file 'butterfly.webp'
File: butterfly.jpg
Dimension: 1676 x 1418
Output: 208418 bytes Y-U-V-All-PSNR 41.00 43.99 44.95 41.87 dB
(0.70 bpp)
block count: intra4: 7644 (81.80%)
Intra16: 1701 (18.20%)
Skipped: 63 (0.67%)
bytes used: header: 249 (0.1%)
mode-partition: 36885 (17.7%)
Residuals bytes |segment 1|segment 2|segment 3|segment 4| total
macroblocks: | 8%| 22%| 26%| 44%| 9345
quantizer: | 27 | 25 | 21 | 13 |
filter level: | 8 | 6 | 19 | 16 |
และหากคุณไม่เห็นด้วยกับบรรทัดคำสั่ง Squoosh ก็จะให้บริการเราในการเข้ารหัส WebP เช่นกัน ซึ่งทำให้เรามีทางเลือกในการเปรียบเทียบการเข้ารหัส การตั้งค่า ระดับคุณภาพ และความแตกต่างของขนาดไฟล์จากการเข้ารหัส JPEG