Kummaline meetod kõvakettaruumi säästmiseks

Teine kasutaja soovib kirjutada kõvakettale uut andmeosa, kuid tal pole selleks piisavalt vaba ruumi. Samuti ei taha ma midagi kustutada, kuna "kõik on väga oluline ja vajalik". Ja mida me peaksime sellega tegema?

Seda probleemi pole kellelgi. Meie kõvaketastel on terabaite infot ja see hulk ei kipu vähenema. Aga kui ainulaadne see on? Lõpuks on kõik failid vaid teatud pikkusega bittide komplektid ja tõenäoliselt ei erine uus fail palju juba salvestatud failist.

On selge, et kõvakettale juba salvestatud teabe otsimine on kui mitte ebaõnnestumine, siis vähemalt mitte tõhus ülesanne. Teisest küljest, kui vahe on väike, siis saab seda veidi reguleerida...

Kummaline meetod kõvakettaruumi säästmiseks

TL;DR - teine ​​katse rääkida kummalisest meetodist andmete optimeerimiseks JPEG-failide abil, nüüd arusaadavamal kujul.

Bittide ja erinevuste kohta

Kui võtta kaks täiesti juhuslikku andmekildu, siis keskmiselt pooled nendes sisalduvatest bittidest ühtivad. Tõepoolest, iga paari ('00, 01, 10, 11') võimalike paigutuste hulgas on täpselt pooltel samad väärtused, siin on kõik lihtne.

Aga muidugi, kui võtame lihtsalt kaks faili ja sobitame ühe teisega, siis kaotame neist ühe. Kui salvestame muudatused, leiutame lihtsalt uuesti delta kodeering, mis eksisteerib suurepäraselt ka ilma meieta, kuigi seda tavaliselt samadel eesmärkidel ei kasutata. Võime proovida manustada väiksemat jada suuremasse, kuid isegi nii riskime kriitiliste andmesegmentide kaotamisega, kui kasutame seda kõigega hoolimatult.

Mille ja mille vahel saab siis erinevust kõrvaldada? Noh, see tähendab, et kasutaja kirjutatud uus fail on lihtsalt bittide jada, millega me ei saa ise midagi teha. Siis tuleb lihtsalt kõvakettalt leida sellised bitid, mida saaks vahetada ilma vahet salvestamata, et saaksid nende kaotuse ilma tõsiste tagajärgedeta üle elada. Ja on mõttekas muuta mitte ainult FS-i enda faili, vaid ka selle sees olevat vähem tundlikku teavet. Aga milline ja kuidas?

Paigaldusmeetodid

Appi tulevad kaduma läinud tihendatud failid. Kõik need jpeg-id, mp3-d ja muud, kuigi kadudega tihendatud, sisaldavad hunnikut bitte, mida saab turvaliselt muuta. Võimalik on kasutada täiustatud tehnikaid, mis kodeerimise erinevates etappides märkamatult oma komponente muudavad. Oota. Täiustatud tehnikad... märkamatu modifikatsioon... üks natuke teiseks... see on peaaegu nagu steganograafia!

Tõepoolest, ühe teabe põimimine teise meenutab tema meetodeid nagu ei midagi muud. Mulle avaldab muljet ka inimmeeltele tehtud muudatuste hoomamatus. Kui teed lahknevad, on saladus: meie ülesanne taandub kasutajale, kes sisestab oma kõvakettale lisateavet; see teeb talle ainult kahju. Ta unustab jälle.

Seega, kuigi me saame neid kasutada, peame tegema mõned muudatused. Ja siis ma räägin ja näitan neid ühe olemasoleva meetodi ja tavalise failivormingu näitel.

Šaakalite kohta

Kui seda tõesti pigistada, on see maailma kõige kokkusurutavam asi. Loomulikult räägime JPEG-failidest. Andmete sellesse manustamiseks pole mitte ainult palju tööriistu ja olemasolevaid meetodeid, vaid see on planeedi kõige populaarsem graafikavorming.

Kummaline meetod kõvakettaruumi säästmiseks

Kuid selleks, et mitte tegeleda koerakasvatusega, peate selle formaadi failides oma tegevusvaldkonda piirama. Kellelegi ei meeldi ühevärvilised ruudud, mis ilmuvad liigse tihendamise tõttu, seega peate piirduma juba tihendatud failiga töötamisega, ümberkodeerimise vältimine. Täpsemalt täisarvu koefitsientidega, mis jäävad pärast andmete kadumise eest vastutavaid toiminguid - DCT ja kvantiseerimine, mis on kodeerimisskeemis suurepäraselt kuvatud (tänu Baumani rahvusraamatukogu wikile):
Kummaline meetod kõvakettaruumi säästmiseks

Jpeg-failide optimeerimiseks on palju võimalikke meetodeid. On kadudeta optimeerimine (jpegtran), on optimeerimine "kaotust pole“, mis tegelikult annavad midagi muud, kuid me ei hooli neist. Lõppude lõpuks, kui kasutaja on vaba kettaruumi suurendamiseks valmis ühte teavet teise manustama, siis optimeeris ta oma pildid juba ammu või ei taha seda kvaliteedi kaotamise kartuses üldse teha.

F5

Nende tingimustega sobib terve algoritmide perekond, millega saate end kurssi viia selles heas esitluses. Neist kõige arenenum on algoritm F5 Andreas Westfeld, kes töötab heleduse komponendi koefitsientidega, kuna inimsilm on selle muutuste suhtes kõige vähem tundlik. Veelgi enam, see kasutab maatrikskodeeringul põhinevat manustamistehnikat, mis võimaldab sama teabehulga manustamisel teha vähem muudatusi, mida suurem on kasutatava konteineri suurus.

Muudatused ise taanduvad koefitsientide absoluutväärtuse vähendamisele teatud tingimustel (st mitte alati) ühe võrra, mis võimaldab teil kõvakettal andmete salvestamiseks optimeerida klahvi F5. Asi on selles, et pärast sellist muudatust võtab koefitsient pärast Huffmani kodeerimist JPEG-i väärtuste statistilise jaotuse tõttu tõenäoliselt vähem bitte ja uued nullid annavad nende RLE-ga kodeerimisel võimenduse.

Vajalikud muudatused taanduvad salajas hoidmise eest vastutava osa (paroolide ümberkorraldamise) kõrvaldamisele, mis säästab ressursse ja täitmisaega, ning lisades mehhanismi, mis võimaldab ühe korraga töötamiseks palju faile. Tõenäoliselt ei huvita lugeja muudatuste protsessi üksikasjalikumalt, nii et liigume juurutamise kirjelduse juurde.

Kõrgtehnoloogiline

Selle lähenemisviisi toimimise demonstreerimiseks rakendasin meetodi puhtas C-s ja tegin mitmeid optimeerimisi nii täitmiskiiruse kui ka mälu osas (te ei kujuta ette, kui palju need pildid kaaluvad ilma tihendamiseta, isegi enne DCT-d). Platvormideülene, mis saavutati teekide kombinatsiooni abil libjpeg, pcre и tinydir, mille eest täname neid. Kõik see on kokku pandud "make" abil, nii et Windowsi kasutajad soovivad omale hindamiseks installida Cygwini või tegeleda Visual Studio ja teekidega iseseisvalt.

Rakendus on saadaval konsooliutiliidi ja teegi kujul. Viimase kasutamise kohta saavad huvilised lähemalt tutvuda Githubis asuvas repositooriumis readme'is, mille lingi lisan postituse lõppu.

Kuidas kasutada?

Hoolikalt. Pakendamiseks kasutatavad pildid valitakse otsides regulaaravaldise abil antud juurkataloogis. Lõpetamisel saab faile teisaldada, ümber nimetada ja kopeerida vastavalt oma soovile, muuta faile ja operatsioonisüsteeme jne. Siiski peaksite olema äärmiselt ettevaatlik ja ärge muutke kohe sisu. Isegi ühe biti väärtuse kaotamine võib muuta teabe taastamise võimatuks.

Lõpetamisel jätab utiliit spetsiaalse arhiivifaili, mis sisaldab kogu lahtipakkimiseks vajalikku teavet, sealhulgas andmeid kasutatud piltide kohta. Iseenesest kaalub see umbes paar kilobaiti ega mõjuta oluliselt hõivatud kettaruumi.

Võimalikku mahtu saab analüüsida lipu '-a' abil: './f5ar -a [otsingukaust] [Perliga ühilduv regulaaravaldis]'. Pakkimine toimub käsuga './f5ar -p [otsingukaust] [Perliga ühilduv regulaaravaldis] [pakitud fail] [arhiivi nimi]' ja lahti pakkimine käsuga './f5ar -u [arhiivifail] [taastatud faili nimi ]' .

Töö demonstreerimine

Meetodi tõhususe näitamiseks laadisin teenusest üles 225 täiesti tasuta fotost koosneva kollektsiooni koertest. Unsplash ja leidis dokumentidest teise köite 45-meetrise suure pdf-i Programmeerimise kunst Knuta.

Järjekord on üsna lihtne:

$ 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/

Ekraanipildid fännidele

Kummaline meetod kõvakettaruumi säästmiseks

Lahtipakkitud faili saab lugeda ja peaks ikka lugema:

Kummaline meetod kõvakettaruumi säästmiseks

Nagu näete, jõudsime kõvaketta algsest 633 + 36 == 669 megabaidist andmemahust meeldivama 551-ni. Selline radikaalne erinevus on seletatav koefitsientide väärtuste vähenemisega, mis mõjutab nende mahtu. järgnev kadudeta pakkimine: ükshaaval vähendamine võib lihtsalt lõplikust failist paar baiti ära lõigata. See on siiski andmete kadu, ehkki väga väike, millega peate leppima.

Õnneks on need silmale täiesti nähtamatud. Spoileri all (kuna habrastorage ei suuda suuri faile käsitleda) saab lugeja hinnata erinevust nii silma kui ka nende intensiivsuse järgi, mis saadakse muudetud komponendi väärtuste lahutamisel originaalist: originaal, infoga sees, erinevus (mida tuhmim värv, seda väiksem on ploki vahe).

Selle asemel, et järeldus

Arvestades kõiki neid raskusi, võib kõvaketta ostmine või kõige pilvelaadimine tunduda probleemile palju lihtsam lahendus. Aga kuigi me elame praegu nii imelisel ajal, pole mingit garantiid, et homme on ikka võimalik netti minna ja kõik oma lisaandmed kuhugi üles laadida. Või mine poodi ja osta endale veel tuhande terabaidine kõvaketas. Kuid alati saab kasutada olemasolevaid maju.

-> GitHub

Allikas: www.habr.com

Lisa kommentaar