हार्ड डिस्क स्थान बचत गर्न को लागी एक अनौठो विधि को बारे मा

अर्को प्रयोगकर्ताले हार्ड ड्राइभमा डाटाको नयाँ टुक्रा लेख्न चाहन्छ, तर यो गर्नको लागि उहाँसँग पर्याप्त खाली ठाउँ छैन। म केहि पनि मेटाउन चाहन्न, किनकि "सबै कुरा धेरै महत्त्वपूर्ण र आवश्यक छ।" र हामीले यसको साथ के गर्नुपर्छ?

कसैलाई यो समस्या छैन। हाम्रो हार्ड ड्राइभहरूमा टेराबाइट जानकारीहरू छन्, र यो रकम घट्ने प्रवृत्ति छैन। तर यो कति अद्वितीय छ? अन्तमा, सबै फाइलहरू एक निश्चित लम्बाइको बिटहरूको सेट मात्र हुन् र, सम्भवतः, नयाँ पहिले नै भण्डार गरिएको भन्दा धेरै फरक छैन।

यो स्पष्ट छ कि हार्ड ड्राइभमा पहिले नै भण्डारण गरिएको जानकारीको टुक्राहरू खोज्नु हो, यदि असफलता होइन, कम्तिमा प्रभावकारी कार्य होइन। अर्कोतर्फ, यदि भिन्नता सानो छ भने, तपाइँ यसलाई अलिकति समायोजन गर्न सक्नुहुन्छ ...

TL; DR - JPEG फाइलहरू प्रयोग गरेर डाटा अप्टिमाइज गर्ने एउटा अनौठो विधिको बारेमा कुरा गर्ने दोस्रो प्रयास, अब थप बुझ्न सकिने रूपमा।

बिट्स र भिन्नता को बारे मा

यदि तपाइँ डेटाको दुई पूर्ण रूपमा अनियमित टुक्राहरू लिनुहुन्छ भने, त्यसपछि बिट्सको औसत आधा तिनीहरूसँग मेल खान्छ। वास्तवमा, प्रत्येक जोडी ('00, 01, 10, 11') को लागि सम्भावित लेआउटहरू बीच, ठ्याक्कै आधा समान मानहरू छन्, यहाँ सबै कुरा सरल छ।

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

के र के बीचको भिन्नता मेटाउन सकिन्छ? ठीक छ, त्यो हो, प्रयोगकर्ता द्वारा लेखिएको नयाँ फाइल केवल बिटहरूको एक अनुक्रम हो, जसको साथ हामी आफैंले केहि गर्न सक्दैनौं। त्यसोभए तपाईंले हार्ड ड्राइभमा त्यस्ता बिटहरू फेला पार्न आवश्यक छ कि तिनीहरू फरक भण्डार नगरी परिवर्तन गर्न सकिन्छ, ताकि तपाईं गम्भीर परिणामहरू बिना तिनीहरूको हानि बाँच्न सक्नुहुन्छ। र यसले FS मा रहेको फाइललाई मात्र होइन, तर त्यसभित्रका केही कम संवेदनशील जानकारीलाई पनि परिवर्तन गर्न अर्थपूर्ण हुन्छ। तर कुन र कसरी?

फिटिंग विधिहरू

हानि कम्प्रेस गरिएका फाइलहरू उद्धारमा आउँछन्। यी सबै jpegs, mp3s र अन्य, हानिपूर्ण कम्प्रेसन भए तापनि, सुरक्षित रूपमा परिवर्तन गर्न सकिने बिटहरूको गुच्छा समावेश गर्दछ। यो उन्नत प्रविधिहरू प्रयोग गर्न सम्भव छ जसले इन्कोडिङको विभिन्न चरणहरूमा तिनीहरूको कम्पोनेन्टहरू अस्पष्ट रूपमा परिमार्जन गर्दछ। पर्खनुहोस्। उन्नत प्रविधिहरू... अगोचर परिमार्जन... एक बिट अर्कोमा... यो लगभग जस्तै छ स्टेग्नोग्राफी!

वास्तवमा, एउटा जानकारीलाई अर्कोमा इम्बेड गर्नु भनेको अरू केही जस्तो नभई उनको विधिहरूको सम्झना दिलाउने हो। मानव संवेदनामा भएका परिवर्तनहरूको अबोधताबाट म पनि प्रभावित छु। जहाँ बाटोहरू भिन्न हुन्छन् गोप्यतामा: हाम्रो कार्य प्रयोगकर्तालाई आफ्नो हार्ड ड्राइभमा थप जानकारी प्रविष्ट गर्न तल आउँछ; यसले उसलाई मात्र हानि गर्नेछ। उसले फेरि बिर्सनेछ।

तसर्थ, यद्यपि हामीले तिनीहरूलाई प्रयोग गर्न सक्छौं, हामीले केही परिमार्जनहरू गर्न आवश्यक छ। र त्यसपछि म तिनीहरूलाई अवस्थित विधिहरू र एक साझा फाइल ढाँचाको उदाहरण प्रयोग गरेर देखाउनेछु।

स्याल को बारेमा

यदि तपाइँ यसलाई साँच्चै निचोड गर्नुहुन्छ भने, यो संसारमा सबैभन्दा संकुचित चीज हो। हामी निस्सन्देह, जेपीईजी फाइलहरूको बारेमा कुरा गर्दैछौं। यसमा डाटा इम्बेड गर्नका लागि त्यहाँ धेरै उपकरणहरू र अवस्थित विधिहरू मात्र छैनन्, तर यो यस ग्रहमा सबैभन्दा लोकप्रिय ग्राफिक्स ढाँचा हो।

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

jpeg फाइलहरू अनुकूलन गर्न धेरै सम्भावित तरिकाहरू छन्। त्यहाँ हानिरहित अप्टिमाइजेसन (jpegtran) छ, त्यहाँ अनुकूलन छ "बेज पोटर", जसले वास्तवमा अरू केहि योगदान गर्दछ, तर हामी तिनीहरूको वास्ता गर्दैनौं। आखिर, यदि प्रयोगकर्ता खाली डिस्क स्पेस बढाउनको लागि एक जानकारी अर्कोमा इम्बेड गर्न तयार छ, त्यसपछि उसले या त आफ्नो छविहरू लामो समय पहिले अनुकूलित गर्यो, वा गुणस्तरको हानिको डरको लागि यो गर्न चाहँदैन।

F5

एल्गोरिदमको सम्पूर्ण परिवारले यी सर्तहरू फिट गर्दछ, जुन तपाईं आफैंसँग परिचित हुन सक्नुहुन्छ यो राम्रो प्रस्तुति मा। तिनीहरूमध्ये सबैभन्दा उन्नत एल्गोरिथ्म हो F5 Andreas Westfeld द्वारा, चमक घटक को गुणांक संग काम गर्दै, मानव आँखा यसको परिवर्तनहरु को लागी कम से कम संवेदनशील छ। यसबाहेक, यसले म्याट्रिक्स इन्कोडिङमा आधारित इम्बेडिङ प्रविधि प्रयोग गर्छ, जसले गर्दा प्रयोग गरिएको कन्टेनरको आकार जति ठूलो हुन्छ त्यति नै जानकारी इम्बेड गर्दा कम परिवर्तनहरू गर्न सम्भव बनाउँछ।

परिवर्तनहरू आफैंमा गुणांकहरूको निरपेक्ष मान घटाउन निश्चित परिस्थितिहरूमा (जसले सधैं होइन), जसले तपाईंलाई आफ्नो हार्ड ड्राइभमा डाटा भण्डारणलाई अनुकूलन गर्न F5 प्रयोग गर्न अनुमति दिन्छ। बिन्दु यो हो कि यस्तो परिवर्तन पछि गुणांकले JPEG मा मानहरूको सांख्यिकीय वितरणको कारण Huffman एन्कोडिङ पछि कम बिटहरू ओगटेको छ, र RLE प्रयोग गरेर तिनीहरूलाई एन्कोड गर्दा नयाँ शून्यहरूले लाभ दिनेछ।

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

उच्च टेक

यो दृष्टिकोणले कसरी काम गर्छ भनेर देखाउनको लागि, मैले शुद्ध C मा विधि लागू गरें र कार्यान्वयन गति र मेमोरीको सन्दर्भमा धेरै अप्टिमाइजेसनहरू गरे (तपाईंले कल्पना गर्न सक्नुहुन्न कि यी तस्विरहरू कम्प्रेसन बिना कति तौल हुन्छन्, DCT अघि पनि)। पुस्तकालयहरूको संयोजन प्रयोग गरेर प्राप्त गरिएको क्रस-प्लेटफर्म libjpeg, पीसीआरई и tinydirजसको लागि हामी उहाँहरूलाई धन्यवाद दिन्छौं। यो सबै 'मेक' द्वारा सँगै राखिएको छ, त्यसैले विन्डोज प्रयोगकर्ताहरूले मूल्याङ्कनका लागि आफैंको लागि केही साइगविन स्थापना गर्न चाहन्छन्, वा भिजुअल स्टुडियो र पुस्तकालयहरू आफैंसँग सम्झौता गर्न चाहन्छन्।

कार्यान्वयन कन्सोल उपयोगिता र पुस्तकालय को रूप मा उपलब्ध छ। ती इच्छुकहरूले Github मा रिपोजिटरीमा रीडमीमा पछिल्लो प्रयोग गर्ने बारे थप जान्न सक्छन्, जुन लिङ्क म पोस्टको अन्त्यमा संलग्न गर्नेछु।

कसरी प्रयोग गर्ने?

सावधानीपूर्वक। प्याकेजिङका लागि प्रयोग गरिएका छविहरू दिइएको रूट डाइरेक्टरीमा नियमित अभिव्यक्ति प्रयोग गरेर खोजी गरेर चयन गरिन्छ। पूरा भएपछि, फाइलहरू सार्न सकिन्छ, पुन: नामकरण गर्न सकिन्छ र यसको सीमा भित्र इच्छा अनुसार प्रतिलिपि गर्न सकिन्छ, फाइल र अपरेटिङ सिस्टमहरू परिवर्तन गर्नुहोस्, इत्यादि। यद्यपि, तपाईं अत्यन्तै होसियार हुनुपर्छ र तत्काल सामग्रीलाई कुनै पनि हिसाबले परिवर्तन नगर्नुहोस्। एक बिटको मूल्य पनि गुमाउँदा जानकारी रिकभर गर्न असम्भव बनाउन सक्छ।

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

तपाईंले '-a' झण्डा प्रयोग गरेर सम्भावित क्षमताको विश्लेषण गर्न सक्नुहुन्छ: './f5ar -a [खोज फोल्डर] [पर्ल-कम्प्याटिबल रेगुलर एक्सप्रेशन]'। प्याकिङ आदेश './f5ar -p [फोल्डर खोज्नुहोस्] [Perl-compatible नियमित अभिव्यक्ति] [packed file] [संग्रह नाम]', र './f5ar -u [संग्रह फाइल] [पुनः प्राप्त फाइल नामको साथ अनप्याकिङ गरी गरिन्छ। ]'।

कामको प्रदर्शन

विधिको प्रभावकारिता देखाउन, मैले सेवाबाट कुकुरहरूको 225 बिल्कुल निःशुल्क फोटोहरूको संग्रह अपलोड गरें। Unsplash र कागजातहरूमा दोस्रो खण्डको 45 मिटरको ठूलो pdf फेला पारियो प्रोग्रामिंग को कला Knuta।

क्रम एकदम सरल छ:

$ du -sh knuth.pdf dogs/
44M knuth.pdf
633M dogs/

$ ./f5ar -p dogs/ .*jpg knuth.pdf dogs.f5ar
Reading compressing file... ok
Initializing the archive... ok
Analysing library capacity... done in 17.0s
Detected somewhat guaranteed capacity of 48439359 bytes
Detected possible capacity of upto 102618787 bytes
Compressing... done in 39.4s
Saving the archive... ok

$ ./f5ar -u dogs/dogs.f5ar knuth_unpacked.pdf
Initializing the archive... ok
Reading the archive file... ok
Filling the archive with files... done in 1.4s
Decompressing... done in 21.0s
Writing extracted data... ok

$ sha1sum knuth.pdf knuth_unpacked.pdf
5bd1f496d2e45e382f33959eae5ab15da12cd666 knuth.pdf
5bd1f496d2e45e382f33959eae5ab15da12cd666 knuth_unpacked.pdf

$ du -sh dogs/
551M dogs/

प्रशंसकहरूको लागि स्क्रिनसटहरू

अनप्याक गरिएको फाइल अझै पनि पढ्न सकिन्छ र:

तपाईले देख्न सक्नुहुन्छ, हार्ड ड्राइभमा मूल 633 + 36 == 669 मेगाबाइट डाटाबाट, हामी अझ सुखद 551 मा आएका छौं। यस्तो कट्टरपन्थी भिन्नता गुणांकको मानहरूमा कमीले व्याख्या गरिएको छ, जसले तिनीहरूको प्रभाव पार्छ। त्यसपछिको हानिरहित कम्प्रेसन: एक एक गरेर घटाउँदा सजिलैसँग "अन्तिम फाइलबाट केही बाइटहरू काट्न सकिन्छ। जे होस्, यो अझै पनि एक डाटा हानि हो, एक अत्यन्तै सानो भए तापनि, जुन तपाईले राख्नुपर्नेछ।

सौभाग्य देखि, तिनीहरू आँखाको लागि बिल्कुल अदृश्य छन्। स्पोइलर अन्तर्गत (ह्याब्रास्टोरेजले ठूला फाइलहरू ह्यान्डल गर्न सक्दैन), पाठकले मूलबाट परिवर्तन गरिएको घटकको मानहरू घटाएर प्राप्त गरी, आँखा र तिनीहरूको तीव्रता दुवैबाट भिन्नता मूल्याङ्कन गर्न सक्छ: मूल, भित्र जानकारी संग, फरक (जति नीरस रंग, ब्लकमा सानो भिन्नता)।

बरु एक निष्कर्षमा को

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

-> GitHub

स्रोत: www.habr.com