เดิมที Google พัฒนา WebP เป็นรูปแบบรูปภาพแบบสูญเสียบางส่วนเพื่อใช้แทน JPEG ซึ่งสามารถสร้างไฟล์ที่มีขนาดเล็กกว่า ไฟล์ภาพที่เทียบเคียงกันได้ โดยเข้ารหัสเป็น JPEG หลังจากนั้น การอัปเดตรูปแบบก็นำเสนอตัวเลือกการบีบอัดแบบไม่สูญเสียข้อมูล ความโปร่งใสของช่องทางอัลฟ่าแบบ PNG และภาพเคลื่อนไหวคล้าย GIF ซึ่งสามารถใช้ควบคู่กับการบีบอัดแบบสูญเสียบางส่วนในรูปแบบ JPEG WebP เป็นรูปแบบที่ใช้งานได้หลากหลายอย่างไม่น่าเชื่อ
อัลกอริทึมการบีบอัดแบบสูญเสียบางส่วนของ WebP อิงตามวิธีการที่ตัวแปลงรหัสวิดีโอ VP8 ใช้เพื่อบีบอัดคีย์เฟรมในวิดีโอ ในระดับสูง การเข้ารหัสจะคล้ายกับการเข้ารหัส JPEG กล่าวคือ WebP ทำงานในแง่ของ "การบล็อก" แทนที่จะเป็นพิกเซลเดี่ยว และมีการแบ่งส่วน ที่คล้ายกันระหว่างความสว่างและความสว่าง บล็อก Luma ของ WebP มีขนาด 16x16 ขณะที่บล็อกโครมาขนาด 8x8 และ "macroblocks" คือ แยกย่อยออกเป็น 4x4 ด้วย
ลักษณะที่ WebP ต่างจาก JPEG โดยสิ้นเชิงคือ ฟีเจอร์ 2 รายการ ได้แก่ "การคาดการณ์การบล็อก" และ "การปรับขนาดบล็อกแบบปรับอัตโนมัติ"
การบล็อกการคาดการณ์
การคาดการณ์แบบบล็อกคือกระบวนการคาดการณ์เนื้อหาของแต่ละบล็อกค่าสีและความสว่างโดยอิงตามค่าต่างๆ ของบล็อกสี่เหลี่ยมที่อยู่รอบๆ โดยเฉพาะบล็อกด้านบนและด้านซ้ายของบล็อกปัจจุบัน คุณอาจนึกภาพออกว่า อัลกอริทึม ที่ทำงานนี้ค่อนข้างซับซ้อน แต่ควรพูดด้วยภาษาง่ายๆ "ถ้ามีสีน้ำเงินอยู่เหนือบล็อกปัจจุบัน และมีสีน้ำเงินอยู่ทางซ้ายมือ ของบล็อกปัจจุบัน ให้สมมติว่าบล็อกนี้เป็นสีน้ำเงิน"
ในความเป็นจริง ทั้ง PNG และ JPEG จะทำการคาดการณ์แบบนี้ด้วยระดับบางระดับด้วย อย่างไรก็ตาม WebP มีเอกลักษณ์ตรงที่ตัวอย่างจากสภาพแวดล้อม บล็อก จากนั้นจะพยายามเติมข้อมูลในบล็อกปัจจุบันโดยใช้ "โหมดการคาดคะเน" ที่แตกต่างกันหลายๆ แบบ โดยจะพยายาม "วาด" อย่างมีประสิทธิภาพ ส่วนที่ขาดหายไปในรูปภาพ ผลลัพธ์ที่ได้จากโหมดการคาดการณ์แต่ละโหมดจะถูกนำไปเปรียบเทียบกับข้อมูลภาพจริง และ เลือกการจับคู่แบบคาดคะเนแล้ว
แม้แต่การจับคู่แบบคาดคะเนที่ใกล้เคียงที่สุดก็อาจไม่ถูกต้องทั้งหมด ดังนั้นความแตกต่างระหว่างการคาดการณ์กับ มูลค่าจริงของบล็อกดังกล่าวจะเข้ารหัสในไฟล์ ในการถอดรหัสภาพ เครื่องมือแสดงผลจะใช้ข้อมูลเดียวกันนั้นในการนำไปใช้งาน ตรรกะตามการคาดการณ์เดียวกัน ซึ่งจะนำไปสู่ค่าที่คาดการณ์ไว้เดียวกันสำหรับแต่ละบล็อก ความแตกต่างระหว่างการคาดการณ์กับ จากนั้นระบบจะนำรูปภาพที่คาดไว้ซึ่งเข้ารหัสไว้ในไฟล์ไปใช้กับการคาดการณ์ ซึ่งคล้ายกับที่การคอมมิต Git แสดง Differential ที่มีผลกับไฟล์ในเครื่อง แทนที่จะเป็นสำเนาใหม่ของไฟล์
เพื่อให้เห็นภาพ: แทนที่จะเจาะลึกเรื่องคณิตศาสตร์ที่ซับซ้อนในอัลกอริทึมการคาดการณ์ที่แท้จริง เราจะสร้างการเข้ารหัสที่มีลักษณะเหมือน WebP ด้วยโหมดการคาดการณ์เดียว และใช้ในการส่งต่อตารางกริดตัวเลขอย่างมีประสิทธิภาพเหมือนกับรูปแบบเดิม อัลกอริทึมของเรา มีโหมดการคาดการณ์โหมดเดียว ซึ่งเราเรียกว่า "โหมดการคาดคะเนหนึ่ง:" ค่าของแต่ละบล็อกคือผลรวมของค่าของบล็อกต่างๆ ข้างต้น และด้านซ้ายของวิดีโอ เริ่มจาก 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