क्यों ये (दोषरहित) कई समान png छवियों के अप्रभावी तरीके अप्रभावी हैं?

Question

मैं बस निम्नलिखित चीज़ों पर आया: मैंने एक png छवि की कई समान प्रतियाँ एक फ़ोल्डर में डाल दीं और फिर उस फ़ोल्डर को निम्न विधियों से संपीड़ित करने का प्रयास किया:

• tar czf folder.tar.gz folder/
• tar cf folder.tar folder/ && xz --stdout folder.tar > folder.tar.xz (यह एक जैसी छवियों के लिए अच्छी तरह से काम करता है, हालांकि समान छवियों के लिए लाभ शून्य है)
• zip -r folder.zip folder/

जब मैं के आकार की जाँच की .tar.gz, .tar.xz, .zipमुझे एहसास हुआ कि यह लगभग एक के रूप में एक ही है कि folder/।
मैं समझता हूं कि एक png छवि में ही उच्च स्तर की संपीड़न हो सकती है और इसलिए इसे आगे संकुचित नहीं किया जा सकता है। हालाँकि जब कई समान (इस मामले में भी समान) विलय करने के लिए एक संग्रह के लिए छवियों png और फिर संग्रह को संपीड़ित करने के लिए मैं अपेक्षित आकार को स्पष्ट रूप से कम करने की उम्मीद करूंगा। समरूप छवियों के मामले में मैं एक एकल छवि के आकार के आकार की अपेक्षा करूंगा।

Comments

यह व्यवहार केवल png फ़ाइलों के साथ मौजूद है?

— pdxter

इसे एक उत्तर के रूप में नहीं बना रहे हैं क्योंकि यह एक बिना पूछे गए प्रश्न का उत्तर देता है, लेकिन अगर आप जानते हैं कि आप लगभग समान छवियों के बहुत से संपीड़ित होने जा रहे हैं, तो आप हमेशा सभी छवियों को बदल सकते हैं लेकिन पहले के मुकाबले एक द्विआधारी भिन्न छवि। मान लें कि छवि शोर नहीं है, तो आप बहुत संकुचित आउटपुट के साथ समाप्त हो जाएंगे, और मूल छवियां अभी भी प्रतिलिपि प्रस्तुत करने योग्य होंगी।

— बाल्ड्रिक

यदि आप असम्पीडित फ़ाइलों (जैसे .bmp) का उपयोग करते हैं , तो tar.gz फ़ाइल को समानता का लाभ उठाने में सक्षम होना चाहिए। (कम से कम अगर समानता बहुत सारे पिक्सेल समान हो रही है)

— कोडइन्चोस

मैं इसके बारे में कुछ नहीं जानता, लेकिन विकिपीडिया के अनुसार, "ZPAQ" संग्रह प्रारूप समर्पण का समर्थन करता है, जो मुझे विश्वास है कि आप इसके बाद क्या कर रहे हैं। en.wikipedia.org/wiki/ZPAQ#Deduplication

— coneslayer

आप उस चीज़ को संपीड़ित करने का प्रयास कर रहे हैं जो पहले से संपीड़ित है। यहां देखें

— काइल खलफ

Answer 1

संपीड़न एल्गोरिदम कैसे काम करते हैं, इस पर एक नज़र डालें। कम से कम Lempel-Ziv परिवार में ( gzip LZ77 का उपयोग करता है , zipजाहिरा तौर पर ज्यादातर के रूप में अच्छी तरह से करता है , और xz LZMA का उपयोग करता है ) कुछ हद तक स्थानीय रूप से संपीड़ित करता है : समानताएं जो एक दूसरे से बहुत दूर हैं, उन्हें पहचाना नहीं जा सकता है।

विवरण विधियों के बीच भिन्न होते हैं, लेकिन नीचे की रेखा यह है कि जब तक एल्गोरिथ्म दूसरी छवि तक पहुंचता है, तब तक यह पहले से ही "भूल" चुका है। और इसी तरह।

आप संपीड़न विधि के मापदंडों को मैन्युअल रूप से बदलने की कोशिश कर सकते हैं; अगर खिड़की का आकार (LZ77) सम्मान। ब्लॉक / चंक आकार (बाद के तरीके) कम से कम दो छवियों के रूप में बड़े हैं, आप शायद आगे संपीड़न देखेंगे।

---

ध्यान दें कि उपरोक्त केवल तभी लागू होता है जब आपके पास समान चित्र या लगभग समान असम्पीडित चित्र हों। यदि मतभेद हैं, तो संपीड़ित छवियां स्मृति में समान रूप से कुछ भी नहीं देख सकती हैं। मुझे नहीं पता कि पीएनजी संपीड़न कैसे काम करता है; आप मैन्युअल रूप से साझा सबस्ट्रिंग के लिए आपके पास मौजूद छवियों की हेक्स अभ्यावेदन की जांच करना चाहते हैं।

यह भी ध्यान रखें कि शोषण करने के लिए परिवर्तित मापदंडों और अतिरेक के साथ भी, आप एक छवि के आकार के नीचे नहीं पहुंचेंगे। बड़े शब्दकोशों का मतलब बड़ा कोड-वर्ड आकार है, और भले ही दो छवियां समान हों, आपको कई कोड-शब्दों (जो पहले में इंगित करते हैं) का उपयोग करके दूसरे को एन्कोड करना पड़ सकता है।

Comments

एक अधिक सटीक उत्तर: gzip और zip एक ही अंतर्निहित DEFLATE कोडेक का उपयोग करते हैं, जो LZ77 + हफ़मैन सिद्धांत पर आधारित है।

— नायुकी

हाँ! वह कहानी का आधा हिस्सा है; अन्य आधे के लिए मेरा जवाब देखें , या नायुकी का शानदार जवाब ।

— DW

पोस्टीरिटी के लिए: पुरालेख स्वरूप जो फाइलों के बीच अतिरेक का शोषण करते हैं, फाइलों को एक ही बूँद में समेट कर और ठोस करार देते हैं । निश्चित नहीं है कि 'ठोसता' के मध्यवर्ती स्तर के लिए अन्य शर्तें हैं, आदि

— अंडरस्कोर_ड

Answer 2

ऐसा क्यूँ होता है। वास्तव में दो अलग-अलग प्रभाव यहां हो रहे हैं:

• प्रत्येक फ़ाइल स्वतंत्र रूप से संपीड़ित होती है। ज़िप सहित कुछ संग्रह कार्यक्रम - प्रत्येक फ़ाइल को स्वतंत्र रूप से संपीड़ित करते हैं, जिसमें एक फ़ाइल से दूसरी फ़ाइल में कोई मेमोरी नहीं होती है। दूसरे शब्दों में, प्रत्येक फ़ाइल को अलग से संपीड़ित किया जाता है, फिर संपीड़ित फ़ाइलों को एक संग्रह में संक्षिप्त किया जाता है।

• अल्पकालिक स्मृति। कुछ संग्रह कार्यक्रम अगली फ़ाइल को बेहतर तरीके से संपीड़ित करने में मदद करने के लिए एक फ़ाइल के बारे में जानकारी का उपयोग कर सकते हैं। वे प्रभावी रूप से फ़ाइलों को संक्षिप्त करते हैं, फिर परिणाम को संक्षिप्त करते हैं। यह एक सुधार है।

  इसके बारे में अधिक चर्चा के लिए नायकी का जवाब भी देखें ।

  हालाँकि, एक दूसरी समस्या है। कुछ संपीड़न योजनाएं - जिनमें जिप, गज़िप और बज़िप 2 शामिल हैं - की एक सीमित मेमोरी है। वे डेटा को ऑन-द-फ्लाई संपीड़ित करते हैं, और डेटा के पिछले 32KB को याद करते हैं, लेकिन वे उस डेटा के बारे में कुछ भी याद नहीं करते हैं जो फ़ाइल में बहुत पहले हुआ था। दूसरे शब्दों में, वे डुप्लिकेट किए गए डेटा को नहीं पा सकते हैं यदि डुप्लिकेट 32KB से अलग होते हैं। परिणामस्वरूप, यदि समरूप फ़ाइलें छोटी होती हैं (लगभग 32KB से कम), तो कंप्रेशन एल्गोरिथ्म डुप्लिकेट किए गए डेटा को निकाल सकता है, लेकिन यदि समरूप फ़ाइलें लंबी हैं, तो कंप्रेशन एल्गोरिथ्म hosed हो जाता है और बेकार हो जाता है: यह किसी का भी पता नहीं लगा सकता है आपके डेटा में डुप्लिकेट। (Bzip को 32KB के बजाय पिछले 900KB या डेटा की याद है।)

  सभी मानक संपीड़न एल्गोरिदम में कुछ अधिकतम मेमोरी आकार होते हैं, जिसके आगे वे पैटर्न का पता लगाने में विफल होते हैं ... लेकिन कुछ के लिए, यह संख्या दूसरों की तुलना में बहुत बड़ी है। Bzip के लिए, यह 900KB जैसा कुछ है। Xz के लिए, यह 8MB (डिफ़ॉल्ट सेटिंग्स के साथ) जैसा है। 7z के लिए, यह 2GB जैसा कुछ है। 2GB, PNG फ़ाइलों की डुप्लिकेट की गई प्रतियों (जो आमतौर पर 2GB की तुलना में बहुत छोटी है) को पहचानने के लिए पर्याप्त से अधिक है। इसके अतिरिक्त, 7z भी उन फाइलों को रखने के बारे में चालाक होने की कोशिश करता है जो कि संग्रह में एक दूसरे के बगल में एक-दूसरे के समान होने की संभावना रखते हैं, कंप्रेसर के काम को बेहतर बनाने में मदद करने के लिए; इस बारे में कुछ भी पता नहीं है।

  इस प्रभाव के और अधिक स्पष्टीकरण के लिए राफेल का उत्तर और नायुकी का उत्तर भी देखें ।

यह आपकी सेटिंग पर कैसे लागू होता है। अपने विशिष्ट उदाहरण के लिए, आप PNG छवियों के साथ काम कर रहे हैं। PNG छवियां स्वयं संपीड़ित होती हैं, इसलिए आप प्रत्येक PNG फ़ाइल को मूल रूप से यादृच्छिक-दिखने वाले बाइट्स का एक क्रम मान सकते हैं, जिसमें फ़ाइल के भीतर कोई पैटर्न या दोहराव नहीं है। एक कंप्रेसर के लिए शोषण करने के लिए कुछ भी नहीं है, अगर यह एक एकल पीएनजी छवि को देखता है। इस प्रकार, यदि आप किसी एकल PNG फ़ाइल को संपीड़ित करने का प्रयास करते हैं (या सिर्फ एक PNG फ़ाइल युक्त एक ज़िप / टार / ... संग्रह बनाते हैं), तो आपको कोई संपीड़न नहीं मिलेगा।

अब देखते हैं कि यदि आप एक ही PNG फ़ाइल की कई प्रतियों को संग्रहीत करने का प्रयास करते हैं, तो क्या होता है:

• छोटी फाइलें। यदि पीएनजी फ़ाइल बहुत छोटी है, तो ज़िप को छोड़कर सब कुछ बहुत अच्छा काम करेगा। ज़िप शानदार रूप से विफल हो जाएगा: यह प्रत्येक फ़ाइल को स्वतंत्र रूप से संपीड़ित करता है, इसलिए इसके पास फ़ाइलों के बीच अतिरेक / दोहराव का पता लगाने का कोई मौका नहीं है। इसके अलावा, के रूप में यह प्रत्येक PNG फ़ाइल को संपीड़ित करने की कोशिश करता है, यह कोई संपीड़न प्राप्त नहीं करता है; ज़िप संग्रह का आकार बहुत बड़ा होगा। इसके विपरीत, टार आर्काइव का आकार (चाहे gzip, bzip2, या xz के साथ संकुचित हो) और एक 7z संग्रह छोटा होगा, क्योंकि यह मूल रूप से फ़ाइल की एक प्रति संग्रहीत करता है और फिर नोटिस करता है कि अन्य सभी समान हैं - उन्हें लाभ मेमोरी को एक फाइल से दूसरी में रखने से।

• बड़ी फाइलें। यदि पीएनजी फ़ाइल बड़ी है, तो केवल 7z अच्छी तरह से काम करता है। विशेष रूप से, ज़िप शानदार ढंग से विफल हो रहा है। इसके अलावा, tar.zip और tar.bzip2 बुरी तरह से विफल हो जाते हैं, क्योंकि फ़ाइल का आकार कंप्रेसर की मेमोरी विंडो से बड़ा है: जैसा कि कंप्रेसर फ़ाइल की पहली प्रति देखता है, वह इसे सिकोड़ नहीं सकता (क्योंकि यह पहले से ही संपीड़ित हो चुका है) ); जब तक यह फ़ाइल की दूसरी प्रति की शुरुआत को देखना शुरू करता है, तब तक यह पहले फ़ाइल की शुरुआत में देखी गई बाइट अनुक्रमों को भूल गया है और यह कनेक्शन नहीं बना सकता है कि यह डेटा वास्तव में एक डुप्लिकेट है।

  इसके विपरीत, एक बड़ी PNG फ़ाइल की कई प्रतियों के साथ tar.xz और 7z शानदार करते रहते हैं। उनके पास "छोटा मेमोरी साइज़" सीमा नहीं है और यह ध्यान देने योग्य है कि फ़ाइल की दूसरी कॉपी पहली कॉपी के समान है, इसलिए इसे दूसरी बार स्टोर करने की कोई आवश्यकता नहीं है।

आप इस बारे में क्या कर सकते हैं। 7z का उपयोग करें। इसमें हेरास्टिक का एक गुच्छा है जो समान या समान फ़ाइलों का पता लगाने में मदद करेगा और उस मामले में वास्तव में अच्छी तरह से संपीड़ित करेगा। तुम भी lzop संपीड़न के साथ lrzip को देख सकते हैं।

मुझे कैसे पता चलेगा? मैं यादृच्छिक बाइट्स वाली फ़ाइल की 100 प्रतियों के साथ कुछ प्रयोगों की कोशिश करके इसे सत्यापित करने में सक्षम था। मैंने एक 4KB फ़ाइल की 100 प्रतियां, 1MB फ़ाइल की 100 प्रतियां और 16MB फ़ाइल की 100 प्रतियों की कोशिश की। यहाँ मैं क्या पाया:

Size of file      Size of compressed archive (with 100 copies)
                  zip  tar.gz  tar.bz2  tar.xz    7z
         4KB    414KB     8KB     10KB     5KB    5KB
         1MB    101MB   101MB    101MB     1MB    2MB
        16MB    1.6G    1.6GB    1.6GB   1.6GB  401MB

जैसा कि आप देख सकते हैं, जिप भयानक है कोई फर्क नहीं पड़ता कि आपकी फ़ाइल कितनी छोटी है। 7z और xz दोनों अच्छे हैं यदि आपकी छवियां बहुत बड़ी नहीं हैं (लेकिन xz नाजुक और उस क्रम पर निर्भर करेगा जिसमें चित्र संग्रह में रखे जाते हैं, यदि आपके पास कुछ डुप्लिकेट हैं और कुछ गैर-डुप्लिकेट एक साथ मिश्रित हैं)। बड़ी फ़ाइलों के लिए भी 7z बहुत अच्छा है।

संदर्भ। यह सुपर उपयोगकर्ता पर पोस्ट के एक समूह में भी अच्छी तरह से समझाया गया है। जरा देखो तो:

• Gzip कम्प्रेशन डेटा के डुप्लीकेट विखंडू को समाप्त क्यों नहीं करता है?
• क्यों जिप एक ही सामग्री के साथ कई फ़ाइलों की तुलना में छोटी फ़ाइल को संपीड़ित करने में सक्षम है?
• ऐसी ही कई बड़ी फाइलों को समेटना
• समान रूप से फ़ाइलों को संपीड़ित करें
• क्या विंडोज के लिए एक संपीड़न या अभिलेखीय कार्यक्रम है जो कटौती भी करता है?
• कई समान फ़ाइलों के लिए अधिक कुशल फ़ाइल संपीड़न कार्यक्रम?

Comments

यह भी ध्यान में रखने योग्य हो सकता है कि ज़िप प्रारूप को 1990 के आसपास डिज़ाइन किया गया था (PKZIP ने 1989 में ज़िप प्रारूप पेश किया जिसे विकिपीडिया कहते हैं, और DEFLATE को 1993 में पेश किया गया था)। इस समय अवधि में, एक सामान्य रूप से सामान्य पीसी 286 या 386 हो सकता है (486 को 1989 में पेश किया गया था, लेकिन हमेशा की तरह, पकड़ने के लिए कुछ समय लिया गया) शायद 2-4 एमबी रैम के साथ डीओएस चल रहा है, केवल 400- जिनमें से 500 केबी सीधे प्रोग्रामिंग (ईएमएस, एक्सएमएस) समर्थन के बिना उपयोग करने योग्य था, जिसके लिए उपलब्ध होने की गारंटी नहीं थी। उस वातावरण में, एक छोटे से संपीड़न खिड़की का आकार बहुत अधिक आवश्यकता थी।

— एक CVn

"प्रत्येक फ़ाइल स्वतंत्र रूप से संपीड़ित होती है" - यह मानकों और उपकरणों के बीच बेतहाशा भिन्नता प्रतीत होती है। उबंटू के डिफॉल्ट पैकेजिंग सॉफ्टवेयर के साथ मेरा अनुभव यह है कि एक आर्काइव को खोलते समय सब कुछ डीकंप्रेस हो जाता है। मैंने अक्सर सोचा है कि इसे प्रत्येक फाइल को स्वतंत्र रूप से संपीड़ित करना चाहिए , क्योंकि प्रयोज्य लाभ आमतौर पर संपीड़न कमियां पल्ला झुकते हैं।

— राफेल

"यादृच्छिक बाइट्स वाली फ़ाइल की 100 प्रतियां" - "समान" फ़ाइलों के बारे में क्या? (वास्तविक प्रश्न की ओर, कैसे समान हैं इसी तरह की छवियों के PNG का?)

— राफेल

राफेल ने अपने जवाब में इस बारे में अच्छी बात की। वास्तव में मेरे पास कई समान (समान नहीं) छवियां हैं जिन्हें मैं संग्रहीत करना चाहता हूं। समान रूप से वे थोड़ी भिन्नता (तीव्रता और पृष्ठभूमि के संबंध में भी) के साथ समान संरचना दिखाते हैं। हालांकि मतभेद इतने कम हैं कि वे शायद ही दिखाई देते हैं। मैंने tarउनके लिए कोशिश की और फिर xz(जो समान छवियों के लिए बहुत अच्छा काम किया ) के साथ संपीड़ित किया गया, हालांकि समान छवियों के मामले में लाभ शून्य है। मैं ~ 831KB के आकार वाले प्रत्येक 71 चित्रों के साथ कोशिश की।

— a_guest

@a_guest - यह अच्छा नहीं चल रहा है। समान दिखने वाले PNG चित्रों में बहुत भिन्न बाइट सामग्री (PNG संपीड़न के कारण) होगी। Superuser.com/q/730592/93541 , superuser.com/q/418286/93541 , superuser.com/q/893206/93541 , superuser.com/q/921140/93541 पर भी देखें - मूल रूप से, कोई अच्छा समाधान नहीं हैं।

— DW

Answer 3

सबसे पहले, ध्यान दें कि पीएनजी छवि प्रारूप मूल रूप से कच्चे आरजीबी पिक्सल (कुछ प्रकाश फ़िल्टरिंग के साथ) में डीफ्लैट संपीड़न प्रारूप के माध्यम से धकेल दिया जाता है। सामान्यतया, संपीड़ित फ़ाइलें (PNG, JPEG, MP3, आदि) फिर से संकुचित होने से कोई लाभ नहीं दिखाई देगा। तो व्यावहारिक इरादों के लिए, हम आपकी पीएनजी फ़ाइल को शेष प्रयोग के लिए अयोग्य यादृच्छिक डेटा के रूप में मान सकते हैं।

दूसरा, ध्यान दें कि ज़िप और gzip प्रारूप भी DEFLATE कोडेक का उपयोग करते हैं। (यह बताएगा कि किसी एकल फ़ाइल को जिप करने के कारण अनिवार्य रूप से समान आउटपुट आकार का उत्पादन कैसे होगा।)

---

अब मुझे व्यक्तिगत रूप से प्रत्येक परीक्षण मामले पर टिप्पणी करने की अनुमति दें:

• tar czf folder.tar.gz folder/

  यह एक असम्पीडित (असम्पीडित) TAR फ़ाइल बनाता है जो आपकी सभी समरूप PNG फ़ाइलों (मेटाडेटा और पैडिंग की थोड़ी सी मात्रा के साथ) को मिला देती है। फिर इस एकल फ़ाइल को एक संकुचित आउटपुट फ़ाइल बनाने के लिए gzip कंप्रेसर के माध्यम से भेजा जाता है।

  दुर्भाग्य से, DEFLATE प्रारूप केवल 32768 बाइट्स के LZ77 शब्दकोश विंडो का समर्थन करता है। भले ही TAR में दोहरावदार डेटा होता है, लेकिन अगर आपकी PNG फ़ाइल 32 KiB से अधिक है, तो सुनिश्चित करें कि DEFLATE कंप्रेसर इस तथ्य का लाभ उठाने के लिए डेटा को वापस याद नहीं रख सकता है कि समान डेटा आवर्ती है।

  दूसरी ओर, यदि आप इस एक्सपीरिएंस को पुनः प्राप्त करते हैं, तो कहते हैं, 20 केबी पीएनजी फाइल को 10 बार डुप्लिकेट किया गया, तो यह बहुत संभावना है कि आपको जीजीपी फ़ाइल केवल 20 केबी से थोड़ी ही बड़ी मिलेगी।

• tar cf folder.tar folder/ && xz --stdout folder.tar > folder.tar.xz

  यह पहले की तरह ही एक TAR फ़ाइल बनाता है, और फिर xz प्रारूप और LZMA / LZMA2 कंप्रेसर का उपयोग करता है। मैं इस स्थिति में LZMA के बारे में जानकारी नहीं पा सका, लेकिन विंडोज के लिए 7-ज़िप से मुझे पता है कि यह बड़े शब्दकोश विंडो के आकार (जैसे 64 MiB) का समर्थन कर सकता है। इसलिए यह संभव है कि आप उप-अपनाने वाली सेटिंग्स का उपयोग कर रहे थे, और यह कि LZMA कोडेक केवल एक PNG फ़ाइल के आकार के लिए TAR फ़ाइल को कम करने में सक्षम हो सकता है।

• zip -r folder.zip folder/

  ज़िप प्रारूप "ठोस" अभिलेखागार का समर्थन नहीं करता है; यह कहना है, हर फ़ाइल स्वतंत्र रूप से संकुचित है। हमने मान लिया कि हर फाइल असंगत है। इसलिए तथ्य यह है कि हर फ़ाइल समान है, शोषण नहीं किया जा सकता है, और ज़िप फ़ाइल सभी फ़ाइलों के सीधे संयोजन के रूप में बड़ी होगी।

Comments

xzडिफ़ॉल्ट रूप से xz -6मोड में चलता है, जो 8 MiB LZMA2 शब्दकोश का उपयोग करता है । मैं तुरंत अपने डेबियन सिस्टम पर उपलब्ध मैन पेज में नहीं मिल सका कि कंप्रेसर के लिए डिफ़ॉल्ट विंडो का आकार क्या है।

— एक CVn

अच्छा उत्तर! दूसरे मामले के लिए मैं वास्तव में निम्नलिखित कर रहा था: tar czf folder.tar.gz folder/ && xz --stdout folder.tar.gz > folder.tar.gz.xzबिना किसी प्रभाव के (जो आपके द्वारा समझाए गए अनुसार समझ में आता है)। मुझे लगता है कि मैं इस सभी संपीड़न सामान में थोड़ा खो गया हूं: डी का उपयोग करते समय tar cf folder.tar folder/ && xz --stdout folder.tar > folder.tar.xzमैं वास्तव में एक छवि के आकार से थोड़ा अधिक के साथ समाप्त होता हूं (जो कि 64 मिब के डिफ़ॉल्ट तानाशाह के आकार के अनुसार भी समझ में आता है)। मैंने उसी हिसाब से अपना सवाल अपडेट किया। धन्यवाद!

— a_guest

@a_guest ठीक है, इसलिए आपकी टिप्पणी एक दूसरे मामले का वर्णन करती है। समस्या यह है कि tar -> gzip -> xz, gzip DEFLATE PNG डेटा की प्रत्येक प्रतिलिपि को एक अलग तरीके से संपीड़ित कर सकता है, इसलिए xz अतिरेक का पता लगाने में सक्षम नहीं होगा।

— नायुकी

Answer 4

समस्या यह है, कि (अधिकांश) संपीड़न योजनाओं में आपके पास मौजूद डेटा पर ज्ञान का अभाव है। यहां तक ​​कि अगर आप अपने PNGs को बिटमैप्स पर डिपॉज़िट करते हैं और उन्हें टारबॉल में कंप्रेस करते हैं, तो आपको छोटे परिणाम नहीं मिलेंगे।

कई समान छवियों के मामले में, एक उपयुक्त संपीड़न योजना एक वीडियो कोडेक होगी।

दोषरहित कोडिंग का उपयोग करके आपको लगभग पूर्ण संपीड़न परिणाम प्राप्त करना चाहिए जिसकी आप अपेक्षा कर रहे हैं।

यदि आप इसका परीक्षण करना चाहते हैं, तो कुछ इस तरह का उपयोग करें:

ffmpeg -i img%03d.png -c:v libx264 -c:v libx264 -profile:v high444 -crf 0 out.mp4

https://trac.ffmpeg.org/wiki/Create%20a%20video%20slideshow%20from%20images

Comments

एक वीडियो एनकोडर का उपयोग करके अच्छी बात! मैं कोशिश करूँगा कि जब मैंने अपने Ubuntu कारण को 14.04 अपग्रेड किया तो डिफ़ॉल्ट रूप से ffmpeg शामिल नहीं है। मुझे लगता है कि इस वीडियो एनकोडर दोषरहित संपीड़न का उपयोग कर रहा है या कम से कम उसके लिए एक स्विच है? क्या आप जानते हैं?

— a_guest

हां, -crf 0 इसे दोषरहित बनाता है (या डॉक्स -qp 0 में उल्लिखित जैसा करता है - -qp 0 को प्राथमिकता दी जाती है)। trac.ffmpeg.org/wiki/Encode/H.264

— जोनास

Answer 5

PNG उस क्रम में फिल्टर + LZ77 + हफ़मैन (LZ77 + हफ़मैन के संयोजन को डिफलेट कहा जाता है) का संयोजन है:

चरण 1) यदि फ़िल्टर किसी से अलग नहीं है, तो पिक्सल के मूल्य को आसन्न पिक्सल से अंतर से बदल दिया जाता है (अधिक जानकारी के लिए http://www.libpng.org/pub/png/book/chapter09.html देखें ) । यह ग्रेडिएंट्स के साथ छवियों के संपीड़न को बढ़ाता है (इसलिए ... 4 5 6 7 बन जाता है ... 1 1 1 1) और यह उसी रंग के क्षेत्रों में मदद कर सकता है (... 3 3 3 5 5 5 5 5 0 हो जाता है 0 0 2 0 0 0 0 0)। डिफ़ॉल्ट फ़िल्टर 24-बिट छवियों में सक्षम होते हैं और पैलेट के साथ 8-बिट्स छवियों में अक्षम होते हैं।

चरण 2) डेटा LZ77 के साथ संपीड़ित होता है जो बाइट के बार-बार (मिलान) तारों को एक ट्यूपल के साथ मैच की दूरी और मैच की लंबाई से बदल देता है।

चरण 3) चरण 2 का परिणाम हफमैन कोड के साथ एन्कोड किया गया है जो निश्चित लंबाई के प्रतीकों को चर-लंबाई कोडों के साथ बदलता है, जितना अधिक बार प्रतीक उतना छोटा कोड होता है।

कई मुद्दे हैं:

कुछ पिक्सेल को प्रभावित करने वाले एक छोटे से परिवर्तन से परिणाम में परिवर्तन png संपीड़न के 3 चरणों से होगा:

1) आसन्न पिक्सेल का फ़िल्टर्ड मान बदल जाएगा (उपयोग किए गए फ़िल्टर के आधार पर)। यह छोटे परिवर्तनों के प्रभाव को बढ़ाएगा।

2) परिवर्तन का मतलब यह होगा कि उस क्षेत्र के मैच अलग-अलग होंगे। उदाहरण के लिए 333333 से 333533 को बदलने का कारण बनता है कि 333333 की एक और घटना अब मेल नहीं खाएगी इसलिए यह 333333 के लिए एक अलग दूरी के साथ एक और मैच का चयन करेगा या यह एक ही मैच का चयन करेगा लेकिन कम लंबाई के साथ और फिर पिछले तीन 3 मिनट के लिए एक और मैच। अपने आप से कि परिणाम बहुत बदल जाएगा।

3) सबसे बड़ा मुद्दा चरण 3 में है। हफ़मैन कोड बिट्स की एक परिवर्तनीय संख्या का उपयोग करता है इसलिए यहां तक ​​कि एक छोटे से परिवर्तन का परिणाम होगा कि जो कुछ भी अनुसरण करता है वह अब संरेखित नहीं है। AFAIK अधिकांश संपीड़न एल्गोरिदम उन मैचों का पता नहीं लगा सकते हैं जो बाइट संरेखित नहीं हैं ताकि पहले से संपीड़ित डेटा पर रोक (या कम से कम बहुत कम) संपीड़न हो सके जो परिवर्तन का अनुसरण करता है जब तक कि कंप्रेसर बाइट संरेखित नहीं होने वाले मैचों का पता लगा सकता है।

अन्य मुद्दों को पहले से ही अन्य उत्तरों द्वारा कवर किया गया है:

4) Gzip एक ही Deflate एल्गोरिथ्म का उपयोग 32KB डिक्शनरी के साथ करता है, इसलिए यदि png फाइलें 32KB से बड़ी हैं, तो मैच का पता नहीं चलेगा भले ही वे समान हों। Bzip2 उस पहलू में बेहतर है क्योंकि यह 900 KB ब्लॉक का उपयोग करता है। XZ LZMA का उपयोग करता है, जिसका IIRC डिफ़ॉल्ट संपीड़न स्तर में 4 एमबी शब्दकोश है। 5) ज़िप प्रारूप ठोस संपीड़न का उपयोग नहीं करता है इसलिए यह समान या समान फ़ाइलों को किसी भी बेहतर संपीड़ित नहीं करेगा।

शायद PAQ या PPMD ​​परिवार के कंप्रेशर्स बेहतर संपीड़ित करेंगे लेकिन अगर आपको बहुत सारी समान छवि फ़ाइलों को संपीड़ित करने की आवश्यकता है, तो आप 3 विकल्प देख सकते हैं:

1) छवियों को असम्पीडित (PNG -0 के साथ या बिना संपीड़न के एक प्रारूप में) स्टोर करें और एक कंप्रेसर के साथ एक बड़े शब्दकोश या ब्लॉक आकार के साथ संपीड़ित करें। (LZMA अच्छा काम करेगा)

2) एक अन्य विकल्प फ़िल्टर रखना होगा लेकिन PNGs से डीफ़्लैट संपीड़न हटा दें। उदाहरण के लिए ( AdvDef ) उपयोगिता के साथ किया जा सकता है । तब आप परिणामी असम्पीडित PNGs को संपीड़ित करते हैं। विघटन के बाद आप असम्पीडित PNG को रख सकते हैं या उन्हें AdvDef के साथ फिर से संपीड़ित कर सकते हैं (लेकिन इसमें समय लगेगा)।

आपको यह देखने के लिए दोनों तरीकों का परीक्षण करने की आवश्यकता है कि कौन सा सबसे संकुचित करता है।

3) अंतिम विकल्प एक वीडियो में png छवियों को परिवर्तित करना होगा, इसे x264 दोषरहित (सही रंग प्रारूप का उपयोग करने का विशेष ध्यान रखना) जैसे दोषरहित वीडियो कंप्रेसर के साथ संपीड़ित करें और फिर निष्कर्षण पर अलग-अलग png छवियों को फ़्रेम निकालें। यह ffmpeg के साथ किया जा सकता है। आपको फ्रेम नंबर और मूल नाम के बीच मैपिंग भी रखनी होगी।

यह सबसे जटिल दृष्टिकोण होगा लेकिन अगर pngs किसी एनीमेशन का हिस्सा हैं तो यह सबसे प्रभावी हो सकता है। हालाँकि आपको एक वीडियो प्रारूप की आवश्यकता होगी जो पारदर्शिता का समर्थन करता है यदि आपको इसकी आवश्यकता है।

संपादित करें: MNG प्रारूप भी है जिसका उपयोग अक्सर नहीं किया जाता है।

Answer 6

जब आपके पास विशेष डेटासेट होते हैं तो आप विशेष एल्गोरिदम का उपयोग करते हैं, न कि बहुउद्देशीय उपकरण।

इसका उत्तर यह है कि आपके चुने हुए दोषरहित कंप्रेशन आप जो भी करते हैं उसके लिए नहीं होते हैं। कोई भी आपसे एक ही छवि को दो बार संपीड़ित करने की उम्मीद करता है, और यहां तक ​​कि अगर आप ऐसा करते हैं (दुर्घटना से) पिछले सभी इनपुट के खिलाफ जांच करने से आपका एल्गोरिथ्म ओ (एन ^ 2) होगा (शायद थोड़ा बेहतर है, लेकिन नाभि दृष्टिकोण कम से कम होगा ^ 2)।

आपके अधिकांश संपीड़न प्रोग्राम जिन्हें आपने O (n) में रन पर परीक्षण किया था, वे इष्टतम संपीड़न अनुपात पर गति बढ़ाते हैं। कोई अपने कंप्यूटर को चलाने के लिए सिर्फ 5 घंटे के लिए कुछ mb को छोड़ना चाहता है, खासकर इन दिनों। बड़े इनपुट के लिए O (n) से ऊपर कुछ भी रनटाइम का मुद्दा बन जाता है।

एक और मुद्दा राम है। आप किसी भी समय अपने इनपुट के हर हिस्से को एक्सेस नहीं कर सकते, जब इनपुट काफी बड़ा हो जाता है। यहां तक ​​कि इस की अवहेलना करते हुए, ज्यादातर लोग अपने पूरे राम या सीपीयू को छोड़ना नहीं चाहते हैं।

यदि आपकी फ़ाइलों में ऐसे पैटर्न हैं, जिन्हें आप कंप्रेस करना चाहते हैं, तो आपको उन पर मैनुएल ऑपरेशंस करने होंगे, अपना कम्प्रेशन लिखना होगा या संभावित रूप से "आर्काइव" -ाइप-कम्प्रेशन (नैनो) का उपयोग करना होगा। दीर्घकालिक भंडारण के लिए एक संपीड़न, जो रोजमर्रा के उपयोग के लिए बहुत धीमा है।

एक अन्य विकल्प संभावित रूप से एक दोषरहित वीडियो संपीड़न होगा।

Comments

यह देखते हुए कि निर्देशिका संरचनाओं के लिए विभिन्न स्थानों पर कई समान फ़ाइलों को समाहित करना बहुत आम है, यह एक अच्छा ज़िप-शैली उपयोगिता की तरह प्रतीत होगा, यह जाँचने के लिए एक विकल्प प्रदान करना चाहिए कि क्या संग्रह में जोड़ी जा रही फ़ाइल में संपीड़ित / असमान हैश मान और आकार हैं वह मौजूदा फ़ाइल से मेल खाता है। यदि दोनों हैश और दोनों आकार मेल खाते हैं, तो पहली फ़ाइल के साथ जुड़े डेटा ब्लॉक में दूसरा नाम संलग्न करना सार्थक होगा। यहां तक ​​कि अगर ज़िप इसे समायोजित नहीं कर सकता है, तो यह भविष्य के किसी भी प्रारूप में एक उपयोगी विशेषता प्रतीत होगी।

— सुपरकाट

आपका जवाब टार के संपीड़न एल्गोरिदम का अर्थ है कि कुछ प्रकार के अतिरेक को संपीड़ित करने के लिए अच्छा है, लेकिन ओपी के परिदृश्य में होने वाले प्रकार के लिए नहीं। आप यह वर्णन करना चाह सकते हैं कि आप किस प्रकार की अतिरेक को इसके लिए अच्छा मानते हैं , क्योंकि यह बिल्कुल स्पष्ट नहीं है। किसी के लिए, जिसने शायद इस कंप्रेसर का सफलतापूर्वक उपयोग कभी नहीं किया है, वे सब देख रहे हैं कि उन्होंने इसे किसी ऐसी चीज़ पर आज़माया है जो सिद्धांत में काफी संकुचित है, यह काम नहीं करता है, इसलिए बिल्ली इस कंप्रेसर के लिए वैसे भी क्या अच्छा है?

— डॉन हैच

@leftaroundabout: किसी भी यूनिक्स में ऐसा कोई तरीका नहीं है जिससे मैं मेल खाने वाली फाइलों के साथ "कॉपी-ऑन-राइट" शब्दार्थ का उपयोग करूं। कई मामलों में, निरर्थक प्रतियां इस तथ्य से निपटने के लिए मौजूद हैं कि आज जो चीजें समान हो सकती हैं, वे कल समान नहीं हो सकती हैं, और ऐसे मामलों में न तो सहानुभूति या हार्डलिंक उचित लगेगा।

— Supercat

@supercat: इस तरह की कई फाइलों के साथ एक "आधिकारिक", रीड-ओनली संस्करण के लिए एक सिमलिंक का उपयोग करना एक अच्छा समाधान है। यदि आप अपनी कॉपी बदलना चाहते हैं, तो सिमिलिंक को एक भौतिक कॉपी से बदल दें।

— leftaroundabout

@leftaroundabout: एक चीज जो मैंने कभी-कभी सोची होगी, अगर कोई इंजीनियर हैश टकराने के खतरे को एक स्वीकार्य स्तर तक कम कर सकता है, तो एक हैश-आधारित सार्वभौमिक संदर्भ पहचानकर्ता होना चाहिए, ताकि किसी "तार्किक" फ़ाइलनाम के साथ सहानुभूति रखने के बजाय कोई हैश के आधार पर एक लिंक बनाएगा। अभिलेखागार वास्तव में बड़ी फ़ाइलों को संग्रहीत करने के एवज में 256 बाइट्स या हैश का संग्रह करेगा। इस तरह के दृष्टिकोण की भिन्नता का उपयोग उन फ़ाइलों के कैशिंग को सक्षम करने के लिए भी किया जा सकता है जिन्हें परिवर्तन के खिलाफ संरक्षित करने की आवश्यकता होती है।

— सुपरकैट

Answer 7

PNG फ़ाइल प्रारूप पहले से ही आंतरिक रूप से DEFLATE संपीड़न एल्गोरिथ्म का उपयोग करता है। यह वही एल्गोरिथ्म है जैसा कि xz, gzip, और zip द्वारा उपयोग किया जाता है - बस कुछ बदलावों में। tar.gzऔर tar.xzफ़ाइलों के बीच समानता का लाभ उठाएं, जो zipनहीं करता है।

तो, वास्तव में, आप संपीड़ित फ़ाइलों पर DEFLATE संपीड़न करते हैं - यही कारण है कि फाइलें लगभग मूल आकार रखती हैं।

bzip2जब यह (लगभग) समान फ़ाइलों के लिए आता है प्रोग्राम (इन्हें संबंधित एल्गोरिथ्म) बेहतर है।

# for i in $(seq 4); do cp test.png test$i.png; done
# tar -cjf archive.tar.bz2 *.png
# ls -l
-rw-r--r-- 1 abcde users  43813 15. Jul 08:45 test.png
-rw-r--r-- 1 abcde users  43813 15. Jul 08:45 test1.png
-rw-r--r-- 1 abcde users  43813 15. Jul 08:46 test2.png
-rw-r--r-- 1 abcde users  43813 15. Jul 08:46 test3.png
-rw-r--r-- 1 abcde users  43813 15. Jul 08:46 test4.png
-rw-r--r-- 1 abcde users  68115 15. Jul 08:47 archive.tar.bz2

Comments

PNG - कृपया ध्यान रखें कि इसमें उपयोग किए जाने वाले फिल्टर हैं, गैर-मानक डिफ्लेट (जो किसी भी तरह मानक है?) और आप सही हैं कि एक ही एल्गोरिदम को दो बार चलाने से कुछ नहीं मिलता (या कम से कम यह फायदेमंद नहीं होना चाहिए), लेकिन रनिंग अलग सेटिंग्स के साथ एक ही एल्गोरिथ्म विफल होने की गारंटी नहीं है। इसके अलावा deflate32, deflate64, LZW, LZMA के बीच मतभेद हैं, आप बस यह नहीं कह सकते हैं कि उनमें से सभी एक ही अपस्फीति का उपयोग करते हैं।

— ईविल

यही कारण है कि मैंने कहा "कुछ विविधताओं में"। बेशक, DEFLATE एक निश्चित कार्यान्वयन के बजाय एक प्रकार के एल्गोरिथ्म को संदर्भित करता है।

— रेक्सकोगिटंस

यह बात याद आती है क्योंकि मैं इसे समझता हूं। हां, एक पीएनजी फ़ाइल अकेले पहले से ही संपीड़ित है, इसलिए मुझे किसी भी तरह के अधिक प्रभाव की उम्मीद नहीं होगी। लेकिन कई समान PNG फ़ाइलों (जो अनिवार्य रूप से यहां की स्थिति है) का एक संयोजन यथोचित रूप से उम्मीद कर सकता है कि उनमें से एक के आकार की तुलना में बहुत अधिक न हो।

— डॉन हैच

जाहिर है, उन संपीड़न एल्गोरिदम उस बिंदु को याद करते हैं। bzip2इसे पकड़ता है tar -cjf archive.tar.bz2 *.png:। मेरे उत्तर में अपडेट किया गया।

— रेक्सकोगिटन्स