ทำไมการเข้ารหัสของ Huffman จึงกำจัดเอนโทรปีที่ Lempel-Ziv ไม่ได้?


13

อัลกอริทึม DEFLATE ยอดนิยมใช้การเข้ารหัส Huffman ที่ด้านบนของ Lempel-Ziv

โดยทั่วไปถ้าเรามีแหล่งข้อมูลแบบสุ่ม (= 1 บิตเอนโทรปี / บิต) ไม่มีการเข้ารหัสรวมถึง Huffman มีแนวโน้มที่จะบีบอัดโดยเฉลี่ย ถ้า Lempel-Ziv นั้น "สมบูรณ์แบบ" (ซึ่งเป็นแนวทางสำหรับแหล่งเรียนส่วนใหญ่เมื่อความยาวสิ้นสุดลง) การเข้ารหัสโพสต์ด้วย Huffman จะไม่ช่วยอะไรเลย แน่นอน Lempel-Ziv ยังไม่สมบูรณ์แบบอย่างน้อยก็มีความยาว จำกัด และยังมีความเหลือเฟืออยู่บ้าง

นี่คือความซ้ำซ้อนที่เหลืออยู่ซึ่งการเข้ารหัส Huffman บางส่วนกำจัดและปรับปรุงการบีบอัด

คำถามของฉันคือ: เหตุใดจึงเหลือความซ้ำซ้อนที่เหลืออยู่นี้สำเร็จโดยการเข้ารหัส Huffman และไม่ใช่ LZ คุณสมบัติของ Huffman เทียบกับ LZ ทำให้สิ่งนี้เกิดขึ้นได้อย่างไร จะเรียกใช้ LZ อีกครั้ง (นั่นคือเข้ารหัสข้อมูลที่บีบอัด LZ ด้วย LZ เป็นครั้งที่สอง) ทำสิ่งที่คล้ายกันหรือไม่ ถ้าไม่ทำไมล่ะ ในทำนองเดียวกันก่อนจะบีบอัดกับ Huffman แล้วหลังจากนั้นกับ LZ ทำงานและถ้าไม่ทำไม?

UPDATE: เป็นที่ชัดเจนว่าแม้หลังจาก LZ ความซ้ำซ้อนบางอย่างจะยังคงอยู่ หลายคนทำในจุดนั้น สิ่งที่ไม่ชัดเจนคือ: เหตุใด Huffman จึงเหลือความซ้ำซ้อนที่เหลืออยู่จึงดีกว่า LZ มีอะไรแปลกใหม่เกี่ยวกับมันในทางตรงกันข้ามกับความซ้ำซ้อนของแหล่งกำเนิดดั้งเดิมที่ LZ ทำงานได้ดีกว่า Huffman

คำตอบ:


13

นี่เป็นความคิดเห็นเดิม แต่มันยาวเกินไป

ถ้าคุณดูที่ DEFLATE สิ่งที่จะถูกบีบอัดโดย Huffman คือผลลัพธ์ของ LZ77 LZ77 ทำงานโดย (เมื่อใช้บิตน้อยกว่าข้อมูลดิบ) ส่งตัวชี้ไปยังสตริงที่ถูกบีบอัดก่อนหน้านี้และความยาวของการจับคู่ที่บอกจำนวนสัญลักษณ์ที่จะใช้หลังจากตัวชี้ ทฤษฎีแสดงให้เห็นว่าถึงแม้จะไม่มีการบีบอัดเพิ่มเติมก็ตามเทคนิคนี้ก็แปรเปลี่ยนเป็นเอนโทรปีของแหล่งกำเนิด อย่างไรก็ตามในการบีบอัดข้อมูลเมื่อใดก็ตามที่คุณมีการแจกแจงที่ไม่สุ่มสมบูรณ์คุณก็อาจทำการบีบอัดข้อมูลได้เช่นกัน ไม่มีเหตุผลที่จะเชื่อได้ว่าผลลัพธ์ของ LZ77 - ตัวชี้และความยาวของการแข่งขัน - เป็นแบบสุ่มสมบูรณ์ พวกเขาจะต้องมาบรรจบกันเพื่อให้การสุ่มเสร็จสมบูรณ์ในขีด จำกัด ของซีมโทติคเนื่องจาก LZ77 นั้นดีที่สุดแบบอะซิมโทติค แต่ในทางปฏิบัติคุณใช้พจนานุกรม จำกัด เท่านั้น ดังนั้นพวกเขาน่าจะอยู่ห่างจากการสุ่มโดยสมบูรณ์ซึ่งคุณจะได้รับจากการบีบอัดต่อไป โดยปกติคุณใช้รหัส Huffman หนึ่งรหัสสำหรับตัวชี้และรหัสอื่นสำหรับความยาวของการจับคู่เนื่องจากทั้งสองกระบวนการมีสถิติแตกต่างกัน

เหตุใดจึงใช้ Huffman มากกว่า LZ สำหรับการบีบอัดรอบสอง ข้อได้เปรียบที่ยิ่งใหญ่ LZ มีมากกว่า Huffman คือการรักษาความสัมพันธ์ระหว่างสัญลักษณ์ ในภาษาอังกฤษหากตัวอักษรหนึ่งตัวคือ 'q' ตัวอักษรตัวถัดไปมีแนวโน้มที่จะเป็น 'u' และอื่น ๆ หากสัญลักษณ์เป็นเหตุการณ์อิสระ Huffman นั้นเรียบง่ายและทำงานได้ดีหรือดีกว่าสำหรับสตริงสั้น ๆ สำหรับผลลัพธ์ของ LZ77 ปรีชาของฉันคือสัญลักษณ์ควรเป็นอิสระพอสมควรดังนั้น Huffman ควรทำงานได้ดีขึ้น


ฉันอยู่กับคุณในย่อหน้าที่ 1: LZ ยังคงมีความซ้ำซ้อนในการบีบอัดเพิ่มเติม แต่ดูเหมือนว่าย่อหน้าที่สองของคุณจะยังคงกระโดดอยู่ถ้าไม่โบกมือ มีการยืนยันสองแบบ: 1. ความซ้ำซ้อนที่เหลืออยู่หลังจาก LZ เป็นศูนย์ลำดับ (นั่นคือ p (X_n) มีค่าประมาณเป็นอิสระจาก x_n-1 ฉันกำลังใช้คำสั่ง zero-order เช่นเดียวกับในรูปแบบ zero-order เช่นdata-compression.com/theory.shtml ) และ 2 สำหรับการซ้ำซ้อนแบบไม่มีคำสั่ง Huffman ทำงานได้ดีกว่า LZ; สำหรับความซ้ำซ้อนของคำสั่งที่สูงกว่า LZ ทำงานได้ดีขึ้น บางทีการยืนยันเหล่านี้อาจเป็นจริงทั้งคู่ แต่คุณยังไม่ได้รับการพิสูจน์
SRobertJames

2
@ Robert: ความสัมพันธ์ที่สูงขึ้นไม่มีผลกระทบใด ๆ กับการเข้ารหัส Huffman LZ ทำงานได้อย่างมีประสิทธิภาพแบบ asymptotically สำหรับความซ้ำซ้อนของคำสั่งที่สูงขึ้น แต่ค่าโสหุ้ยที่จำเป็นเพิ่มเติมนั้นหมายความว่ามันไม่ได้ทำเช่นเดียวกันกับแหล่งที่มาที่มีความยาวเป็นศูนย์ลำดับที่ จำกัด สิ่งนี้จะต้องได้รับการศึกษาทดลองในวรรณคดีที่ไหนสักแห่ง; บางทีคนอื่นสามารถให้ตัวชี้ไปที่การอ้างอิง สำหรับจุดที่ 1 สัญชาตญาณของฉันคือความซ้ำซ้อนที่สูงกว่าที่เหลืออยู่หลังจาก LZ นั้นซับซ้อนเกินกว่าที่จะใช้ในรูปแบบการเข้ารหัสที่เรียบง่าย แต่ฉันไม่มีวิธีที่ดีที่จะพิสูจน์สิ่งนี้
Peter Shor

10

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

(p,,c)pc

lognn

ดังนั้นในระยะสั้น Huffman เต้น LZ ในการบีบอัด tuples เนื่องจากรูปแบบ (การกระจายแบบคงที่และการซ้ำซ้อนที่แน่นอน) เป็นการจับคู่ที่ดีกว่าสำหรับข้อมูล


ขอบคุณ Jouni ดูเหมือนว่าความซ้ำซ้อนหลักที่เหลืออยู่คือความยาวของตัวแทนมักจะเล็กกว่าใหญ่กว่า (ไม่กระจายอย่างสม่ำเสมอทั่ว [0,2 ^ n]) Huffman ทำงานได้ดีบนคำสั่งไม่สมมาตรในขณะที่ LZ ต้องการคุณลักษณะที่ใหญ่กว่าเพื่อให้ทำงานได้ดี ถูกต้องหรือไม่ และทำไมไม่ใช้ Huffman เพื่อเริ่มต้น - ทำไมต้องกังวลกับ LZ เลย?
SRobertJames

3
หากเราบีบอัดข้อความโดยตรงกับ Huffman เราจะไม่สามารถบีบอัดได้ดีกว่าเอนโทรปีที่ไม่มีการเรียงลำดับ อย่างไรก็ตามข้อความจริงส่วนใหญ่มีแหล่งที่มาของความซ้ำซ้อนที่สำคัญซึ่งไม่สามารถสร้างแบบจำลองได้อย่างเพียงพอกับเอนโทรปีแบบไม่มีใบสั่ง ในหลายกรณีการใช้ LZ ก่อน Huffman ช่วยให้เราสามารถบีบอัดความซ้ำซ้อนนี้
Jouni Sirén

2

ฉันเชื่อว่าคำตอบอยู่ที่ขนาดพจนานุกรมค้นหา

ข้อมูลมีความรู้สึกของท้องถิ่น (กล่าวคือถ้ามีการใช้ข้อมูลเป็นไปได้ว่ามันจะถูกใช้อีกครั้งในเร็ว ๆ นี้) และอัลกอริธึม LZ ใช้ประโยชน์จากสิ่งนี้ในการสร้างพจนานุกรมการค้นหา มันสร้าง Trie มีจำนวน จำกัด ของโหนดที่เป็นไปได้เพื่อการค้นหาเก็บได้อย่างรวดเร็ว เมื่อมันถึงขีด จำกัด ขนาดมันทำให้ทั้งคู่อีกคน "ลืม" เกี่ยวกับก่อนหน้านี้ ดังนั้นจึงต้องสร้างตารางการค้นหาสำหรับตัวละครที่เรียบง่ายขึ้นอีกครั้ง แต่หากไม่ได้ใช้คำบางคำอีกต่อไปคำเหล่านั้นจะไม่ถูกเก็บไว้ในหน่วยความจำอีกต่อไปดังนั้นจึงสามารถใช้การเข้ารหัสขนาดเล็กลงได้

ดังนั้นเอาต์พุต LZ สามารถลดลงได้อีกเมื่อใช้การเข้ารหัส Huffman สำหรับความซ้ำซ้อนในการสร้างการค้นหาพยายามสามารถตรวจพบได้โดยการวิเคราะห์ทางสถิติ


ฉันยอมรับย่อหน้าแรก: คุณอธิบายว่าทำไม LZ ถึงมีความซ้ำซ้อน แต่ย่อหน้าที่สองนั้นดูเหมือนว่าจะเป็นการก้าวกระโดด: ทำไม Huffman ถึงมีความซ้ำซ้อนนี้ ทำไมไม่ลอง LZ อีกล่ะ? และถ้าฮัฟฟ์แมนครอบคลุมมากกว่าทำไมไม่เริ่มด้วยล่ะ
SRobertJames

2

บางทีฉันอาจจะออกนอกเส้นทางที่นี่ แต่การเข้ารหัส Huffman ดูที่อินพุตทั้งหมดเพื่อสร้างตารางการเข้ารหัส (ต้นไม้) ในขณะที่ Lempel-Ziv เข้ารหัสตามที่มันเข้ากัน นี่เป็นทั้งข้อดีและข้อเสียสำหรับ Huffman disandvantage นั้น obvioious คือว่าเราต้องดูข้อมูลทั้งหมดก่อนที่เราจะสามารถเริ่มต้น ข้อดีคือ Huffman จะพิจารณาสถิติที่เกิดขึ้นที่ใดก็ได้ในอินพุตในขณะที่ Lempel-Ziv จะต้องสร้างมันขึ้นมาเรื่อย ๆ หรือใช้วิธีอื่น Lempel-Ziv มี "ทิศทาง" ซึ่ง Huffman ไม่มี

แต่ทั้งหมดนี้เป็นเพียงวิธีที่ไร้เดียงสาของฉันในการจินตนาการว่าสิ่งต่าง ๆ เป็นอย่างไร เราจะต้องมีหลักฐานจริงที่นี่เพื่อดูว่า Huffman มีประสิทธิภาพเหนือกว่า Lempel-Ziv อย่างแน่นอน


2
ผู้คนได้กำหนดการเข้ารหัส Huffman ที่ปรับเปลี่ยนได้ซึ่งจะตรวจสอบอินพุตเพียงครั้งเดียวเท่านั้น สำหรับวัตถุประสงค์ของการสนทนานี้การเข้ารหัส Huffman แบบปรับตัวและไม่ปรับตัวจะทำตัวเหมือนกัน
Peter Shor

2

คำตอบสั้น ๆ คือ LZ เป็นอัลกอริธึม "สากล" ที่ไม่จำเป็นต้องรู้การกระจายตัวของแหล่งที่แน่นอน (เพียงแค่ต้องการสมมติฐานที่ว่าแหล่งกำเนิดนั้นอยู่กับที่และมีอัตลักษณ์) แต่ Huffman ไม่ใช่ มันจำเป็นต้องรู้การกระจายที่แน่นอนจากแหล่งที่เป็นตัวอย่าง (สำหรับการสร้าง Huffman tree) ข้อมูลเพิ่มเติมนี้ทำให้ Huffman ได้รับการรับรองการบีบอัดข้อมูลที่แน่นหนา อย่างไรก็ตามสำหรับอัลกอริทึมการบีบอัดไฟล์ที่ใช้งานได้จริง Huffman อาจไม่ค่อยดีนักเนื่องจากมันจะต้องรวบรวมสถิติเชิงประจักษ์ของไฟล์จากนั้นทำการบีบอัดจริงในช่วงครึ่งหลังในขณะที่ LZ สามารถใช้งานออนไลน์ได้

รายละเอียดเพิ่มเติมสามารถพบได้ในตำราทฤษฎีข้อมูลมาตรฐานเช่นองค์ประกอบของข้อมูลทฤษฎีโดย Cover และโทมัส


ฉันคิดว่าแหล่งที่มาของอัตโนมัตคงที่เป็นเพียงข้อสันนิษฐานที่ทำให้ LZ ง่ายต่อการวิเคราะห์ ท้ายที่สุดการบีบอัดจะขึ้นอยู่กับคุณสมบัติ combinatorial ของอินพุตซึ่งเพิ่งเกิดขึ้นพร้อมกับคุณสมบัติทางสถิติในหลายกรณี ลองพิจารณาตัวอย่างเช่นชุดของข้อความภาษาอังกฤษในรูปแบบข้อความธรรมดาแล้วตามด้วยข้อความเดียวกันในรูปแบบ HTML LZ บีบอัดคอลเล็กชันนี้เป็นอย่างดีถึงแม้ว่ามันจะดูไม่เหมือนสิ่งที่สร้างขึ้นโดยแหล่งกำเนิดอัตลักษณ์ที่คงที่
Jouni Sirén

@Jouni: ฉันจะไม่เห็นด้วยกับความคิดเห็นนี้ ฉันคิดว่าในบางแง่ภาษาอังกฤษแบบตัวอักษรธรรมดาดูเหมือนจะเป็นแหล่งอัตลักษณ์แบบคงที่และความคล้ายคลึงกันนี้เป็นสิ่งที่ LZ ใช้ประโยชน์
Peter Shor

@Peter: แต่ในกรณีนี้แหล่งที่มาแรกจะสร้างข้อความบางส่วนในรูปแบบข้อความล้วนและจากนั้นเป็นข้อความเดียวกันในรูปแบบ HTML การเปลี่ยนแปลงนี้จากข้อความธรรมดาเป็น HTML ณ จุดใดจุดหนึ่งโดยพลการดูเหมือนว่าจะทำลายคุณสมบัติที่คงที่ของอัตลักษณ์ ในทางกลับกันผลลัพธ์การบีบอัดจะดีกว่าการบีบอัดข้อความธรรมดาและข้อความ HTML แยกกันเนื่องจากมีข้อมูลร่วมกันจำนวนมากระหว่างข้อความในรูปแบบข้อความธรรมดาและข้อความเดียวกันในรูปแบบ HTML
Jouni Sirén
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.