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...
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
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
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.
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):
Jpeg-failide optimeerimiseks on palju võimalikke meetodeid. On kadudeta optimeerimine (jpegtran), on optimeerimine "
F5
Nende tingimustega sobib terve algoritmide perekond, millega saate end kurssi viia
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
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.
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
Lahtipakkitud faili saab lugeda ja peaks ikka lugema:
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:
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.
->
Allikas: www.habr.com