हार्ड डिस्क जागा वाचवण्याच्या एका विचित्र पद्धतीबद्दल

दुसरा वापरकर्ता हार्ड ड्राइव्हवर डेटाचा एक नवीन भाग लिहू इच्छितो, परंतु त्याच्याकडे हे करण्यासाठी पुरेशी मोकळी जागा नाही. मला काहीही हटवायचे नाही, कारण "प्रत्येक गोष्ट खूप महत्वाची आणि आवश्यक आहे." आणि आपण त्याचे काय करावे?

कोणालाही ही समस्या नाही. आमच्या हार्ड ड्राइव्हवर टेराबाइट्सची माहिती आहे आणि ही रक्कम कमी होत नाही. पण ते किती अद्वितीय आहे? सरतेशेवटी, सर्व फायली केवळ एका विशिष्ट लांबीच्या बिट्सचे संच असतात आणि बहुधा, नवीन आधीपासून संग्रहित केलेल्यापेक्षा फार वेगळी नसते.

हे स्पष्ट आहे की हार्ड ड्राइव्हवर आधीपासून संग्रहित केलेल्या माहितीचे तुकडे शोधणे हे अयशस्वी नसल्यास, किमान प्रभावी कार्य नाही. दुसरीकडे, जर फरक लहान असेल, तर तुम्ही तो थोडा समायोजित करू शकता...

TL;DR - JPEG फाइल्स वापरून डेटा ऑप्टिमाइझ करण्याच्या एका विचित्र पद्धतीबद्दल बोलण्याचा दुसरा प्रयत्न, आता अधिक समजण्यायोग्य स्वरूपात.

बिट्स आणि फरक बद्दल

आपण डेटाचे दोन पूर्णपणे यादृच्छिक तुकडे घेतल्यास, सरासरी अर्धे बिट्स त्यामध्ये असतात. खरंच, प्रत्येक जोडीसाठी संभाव्य मांडणींपैकी (’00, 01, 10, 11′), अगदी अर्ध्यामध्ये समान मूल्ये आहेत, येथे सर्वकाही सोपे आहे.

पण अर्थातच, जर आपण फक्त दोन फाईल्स घेतल्या आणि एक ते दुस-यामध्ये बसवल्या तर आपण त्यापैकी एक गमावू. आम्ही बदल जतन केल्यास, आम्ही फक्त पुन्हा शोधू डेल्टा एन्कोडिंग, जे आपल्याशिवाय पूर्णपणे चांगले अस्तित्वात आहे, जरी ते सामान्यतः समान हेतूंसाठी वापरले जात नाही. आम्‍ही एक लहान अनुक्रम एका मोठ्या क्रमात एम्बेड करण्‍याचा प्रयत्‍न करू शकतो, परंतु तरीही आम्‍ही डेटाचे गंभीर भाग गमावल्‍याचा धोका पत्करतो, जर आम्‍ही ते सर्व बाबतीत बेपर्वाईने वापरतो.

काय आणि काय दरम्यान फरक दूर केला जाऊ शकतो? बरं, म्हणजे, वापरकर्त्याने लिहिलेली नवीन फाईल ही फक्त बिट्सचा एक क्रम आहे, ज्याद्वारे आपण स्वतः काहीही करू शकत नाही. मग तुम्हाला फक्त हार्ड ड्राइव्हवर असे बिट्स शोधणे आवश्यक आहे की ते फरक संचयित केल्याशिवाय बदलले जाऊ शकतात, जेणेकरून तुम्ही गंभीर परिणामांशिवाय त्यांचे नुकसान टिकून राहू शकता. आणि केवळ FS वरील फाइलच नव्हे तर त्यातील काही कमी संवेदनशील माहिती बदलण्यात अर्थ आहे. पण कोणते आणि कसे?

फिटिंग पद्धती

नुकसानग्रस्त संकुचित फायली बचावासाठी येतात. हे सर्व jpegs, mp3 आणि इतर, जरी हानीकारक कॉम्प्रेशन असले तरी, त्यात काही बिट्स असतात जे सुरक्षितपणे बदलले जाऊ शकतात. प्रगत तंत्रे वापरणे शक्य आहे जे एन्कोडिंगच्या विविध टप्प्यांवर त्यांचे घटक अदृश्यपणे बदलतात. थांबा. प्रगत तंत्रे... अगोचर बदल... एक-दुस-यामध्ये... हे जवळजवळ तसे आहे स्टेग्नोग्राफी!

खरंच, एक माहिती दुसर्‍यामध्ये एम्बेड करणे ही तिच्या पद्धतींची आठवण करून देते जसे की इतर काहीही नाही. मानवी संवेदनांमध्ये होणार्‍या बदलांच्या अगम्यतेनेही मी प्रभावित झालो आहे. जेथे मार्ग वेगळे केले जातात ते गुप्ततेत असतात: आमचे कार्य वापरकर्त्याकडे त्याच्या हार्ड ड्राइव्हवर अतिरिक्त माहिती प्रविष्ट करण्यावर येते; यामुळे केवळ त्याचे नुकसान होईल. तो पुन्हा विसरेल.

त्यामुळे, जरी आपण त्यांचा वापर करू शकतो, तरीही आपल्याला काही बदल करणे आवश्यक आहे. आणि मग मी त्यांना विद्यमान पद्धतींपैकी एक आणि सामान्य फाइल स्वरूपाचे उदाहरण वापरून सांगेन आणि दाखवीन.

कोल्हा बद्दल

जर तुम्ही ते खरोखर पिळून काढले तर, ही जगातील सर्वात संकुचित गोष्ट आहे. आम्ही अर्थातच जेपीईजी फाइल्सबद्दल बोलत आहोत. त्यात डेटा एम्बेड करण्यासाठी केवळ बरीच साधने आणि विद्यमान पद्धती नाहीत, परंतु हे या ग्रहावरील सर्वात लोकप्रिय ग्राफिक्स स्वरूप आहे.

तथापि, कुत्र्यांच्या प्रजननात गुंतू नये म्हणून, आपल्याला या स्वरूपाच्या फायलींमध्ये आपल्या क्रियाकलापाचे क्षेत्र मर्यादित करणे आवश्यक आहे. जास्त कॉम्प्रेशनमुळे दिसणारे मोनोक्रोम स्क्वेअर कोणालाही आवडत नाहीत, म्हणून तुम्हाला आधीच संकुचित केलेल्या फाईलसह कार्य करण्यासाठी स्वतःला मर्यादित करणे आवश्यक आहे, रीकोडिंग टाळत आहे. अधिक विशेषतः, पूर्णांक गुणांकांसह, जे डेटा गमावण्यास जबाबदार असलेल्या ऑपरेशन्सनंतर राहतात - डीसीटी आणि क्वांटायझेशन, जे एन्कोडिंग स्कीममध्ये उत्तम प्रकारे प्रदर्शित केले जाते (बॉमन नॅशनल लायब्ररीच्या विकीला धन्यवाद):

jpeg फाइल्स ऑप्टिमाइझ करण्यासाठी अनेक संभाव्य पद्धती आहेत. लॉसलेस ऑप्टिमायझेशन आहे (jpegtran), ऑप्टिमायझेशन आहे "नुकसान नाही", जे प्रत्यक्षात दुसरे काहीतरी योगदान देतात, परंतु आम्हाला त्यांची काळजी नाही. तथापि, जर वापरकर्ता विनामूल्य डिस्क स्पेस वाढविण्यासाठी एक माहिती दुसर्‍यामध्ये एम्बेड करण्यास तयार असेल तर त्याने एकतर त्याच्या प्रतिमा खूप पूर्वी ऑप्टिमाइझ केल्या आहेत किंवा गुणवत्ता कमी होण्याच्या भीतीने हे अजिबात करू इच्छित नाही.

F5

अल्गोरिदमचे संपूर्ण कुटुंब या अटींशी जुळते, जे तुम्ही स्वतःला परिचित करू शकता या चांगल्या सादरीकरणात. त्यापैकी सर्वात प्रगत अल्गोरिदम आहे F5 अँड्रियास वेस्टफेल्ड द्वारे, ब्राइटनेस घटकाच्या गुणांकांसह कार्य करणे, कारण मानवी डोळा त्याच्या बदलांसाठी सर्वात कमी संवेदनशील असतो. शिवाय, ते मॅट्रिक्स एन्कोडिंगवर आधारित एम्बेडिंग तंत्र वापरते, जे वापरलेल्या कंटेनरचा आकार जितका मोठा असेल तितकीच माहिती एम्बेड करताना कमी बदल करणे शक्य करते.

बदल स्वतःच गुणांकांचे निरपेक्ष मूल्य एका विशिष्ट परिस्थितीत कमी करण्यासाठी उकळतात (म्हणजे नेहमीच नाही), जे तुम्हाला तुमच्या हार्ड ड्राइव्हवर डेटा स्टोरेज ऑप्टिमाइझ करण्यासाठी F5 वापरण्याची परवानगी देते. मुद्दा असा आहे की JPEG मधील मूल्यांच्या सांख्यिकीय वितरणामुळे Huffman एन्कोडिंगनंतर अशा बदलानंतर गुणांक बहुधा कमी बिट्स व्यापेल आणि RLE वापरून त्यांना एन्कोड करताना नवीन शून्य फायदा देईल.

आवश्यक सुधारणा गुप्ततेसाठी जबाबदार असलेला भाग काढून टाकण्यासाठी (संकेतशब्द पुनर्रचना) उकळतात, ज्यामुळे संसाधने आणि अंमलबजावणीचा वेळ वाचतो आणि एकाच वेळी अनेक फायलींसोबत काम करण्याची यंत्रणा जोडली जाते. वाचकांना बदल प्रक्रियेत अधिक तपशीलवार स्वारस्य असण्याची शक्यता नाही, म्हणून अंमलबजावणीच्या वर्णनाकडे वळूया.

हाय टेक

हा दृष्टीकोन कसा कार्य करतो हे दर्शविण्यासाठी, मी शुद्ध C मध्ये पद्धत लागू केली आणि अंमलबजावणीचा वेग आणि मेमरी या दोन्ही बाबतीत अनेक ऑप्टिमायझेशन केले (डीसीटीपूर्वीही, कॉम्प्रेशनशिवाय या चित्रांचे वजन किती आहे याची तुम्ही कल्पना करू शकत नाही). लायब्ररींच्या संयोजनाचा वापर करून क्रॉस-प्लॅटफॉर्म साध्य केले libjpeg, पीसीआरई и लहान दिर, ज्यासाठी आम्ही त्यांचे आभार मानतो. हे सर्व ‘मेक’ द्वारे एकत्रित केले आहे, म्हणून विंडोज वापरकर्त्यांना मूल्यमापनासाठी स्वतःसाठी काही सायग्विन स्थापित करायचे आहेत किंवा व्हिज्युअल स्टुडिओ आणि लायब्ररींशी स्वतःहून व्यवहार करायचे आहेत.

अंमलबजावणी कन्सोल युटिलिटी आणि लायब्ररीच्या स्वरूपात उपलब्ध आहे. ज्यांना स्वारस्य आहे ते Github वरील रेपॉजिटरीमध्ये रीडमीमध्ये नंतरचे वापरण्याबद्दल अधिक जाणून घेऊ शकतात, ज्याची लिंक मी पोस्टच्या शेवटी जोडेन.

कसे वापरावे?

काळजीपूर्वक. पॅकेजिंगसाठी वापरल्या जाणार्‍या प्रतिमा दिलेल्या रूट निर्देशिकेत नियमित अभिव्यक्ती वापरून शोधून निवडल्या जातात. पूर्ण झाल्यावर, फाइल्स त्याच्या हद्दीत हलवल्या जाऊ शकतात, पुनर्नामित केल्या जाऊ शकतात आणि कॉपी केल्या जाऊ शकतात, फाइल आणि ऑपरेटिंग सिस्टम बदलू शकतात, इ. तथापि, तुम्ही अत्यंत सावधगिरी बाळगली पाहिजे आणि कोणत्याही प्रकारे त्वरित सामग्री बदलू नये. अगदी एक बिटचे मूल्य गमावल्याने माहिती पुनर्प्राप्त करणे अशक्य होऊ शकते.

पूर्ण झाल्यावर, युटिलिटी एक विशेष संग्रहण फाइल सोडते ज्यामध्ये अनपॅक करण्यासाठी आवश्यक असलेली सर्व माहिती असते, ज्यामध्ये वापरलेल्या प्रतिमांबद्दल डेटा समाविष्ट असतो. स्वतःच, त्याचे वजन सुमारे दोन किलोबाइट्स आहे आणि व्यापलेल्या डिस्क स्पेसवर कोणताही महत्त्वपूर्ण प्रभाव पडत नाही.

तुम्ही '-a' ध्वज वापरून संभाव्य क्षमतेचे विश्लेषण करू शकता: './f5ar -a [शोध फोल्डर] [Perl-compatible नियमित अभिव्यक्ती]'. './f5ar -p [शोध फोल्डर] [Perl-compatible नियमित अभिव्यक्ती] [packed file] [archive name]', आणि './f5ar -u [archive file] [recovered file name] या कमांडसह पॅकिंग केले जाते. ]'.

कामाचे प्रात्यक्षिक

पद्धतीची प्रभावीता दर्शविण्यासाठी, मी सेवेतून कुत्र्यांच्या 225 पूर्णपणे विनामूल्य फोटोंचा संग्रह अपलोड केला आहे. Unsplash आणि दस्तऐवजांमध्ये दुसऱ्या खंडाच्या 45 मीटरचा मोठा पीडीएफ सापडला प्रोग्रामिंगची कला नुटा.

क्रम अगदी सोपा आहे:

$ 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