Kitas vartotojas nori įrašyti naują duomenų dalį į standųjį diską, bet neturi pakankamai laisvos vietos tai padaryti. Taip pat nenoriu nieko ištrinti, nes „viskas labai svarbu ir reikalinga“. Ir ką mes turėtume su juo daryti?
Niekas neturi šios problemos. Mūsų standžiuosiuose diskuose yra terabaitų informacijos ir šis kiekis nėra linkęs mažėti. Bet kuo jis unikalus? Galų gale visi failai yra tik tam tikro ilgio bitų rinkiniai ir, greičiausiai, naujasis mažai kuo skiriasi nuo jau saugomo.
Akivaizdu, kad kietajame diske jau saugomos informacijos paieška yra jei ne nesėkmė, tai bent jau ne efektyvi užduotis. Kita vertus, jei skirtumas nedidelis, tai galima šiek tiek pakoreguoti...
TL;DR – antrasis bandymas kalbėti apie keistą duomenų optimizavimo metodą naudojant JPEG failus, dabar suprantamesne forma.
Apie bitus ir skirtumus
Jei imsite du visiškai atsitiktinius duomenų gabalus, tada vidutiniškai pusė juose esančių bitų sutampa. Iš tiesų, tarp galimų kiekvienos poros išdėstymų ('00, 01, 10, 11') lygiai pusė turi tas pačias reikšmes, čia viskas paprasta.
Bet, žinoma, jei paimsime du failus ir vieną sutalpinsime į antrą, vieną iš jų prarasime. Jei išsaugosime pakeitimus, mes tiesiog išrasime iš naujo
Tarp ko ir ko tuomet galima pašalinti skirtumą? Na, tai yra, vartotojo parašytas naujas failas yra tik bitų seka, su kuria patys nieko negalime padaryti. Tada kietajame diske tereikia surasti tokius bitus, kad juos būtų galima pakeisti nekaupiant skirtumo, kad išgyventumėte jų praradimą be rimtų pasekmių. Ir tikslinga pakeisti ne tik patį FS failą, bet ir šiek tiek mažiau jautrios informacijos jame. Bet kuris ir kaip?
Tvirtinimo būdai
Į pagalbą ateina prarasti suspausti failai. Visuose šiuose jpeg, mp3 ir kituose, nors ir nuostolingo suspaudimo, yra krūva bitų, kuriuos galima saugiai pakeisti. Galima naudoti pažangias technologijas, kurios nepastebimai modifikuoja savo komponentus įvairiuose kodavimo etapuose. Laukti. Pažangios technikos... nepastebimos modifikacijos... viena bitė į kitą... beveik kaip
Iš tiesų, vienos informacijos įterpimas į kitą primena jos metodus kaip nieką kitą. Man taip pat imponuoja žmogaus pojūčių pokyčių nepastebėjimas. Ten, kur keliai skiriasi, yra slaptumas: mūsų užduotis tenka vartotojui įvesti papildomą informaciją į savo standųjį diską; tai jam tik pakenks. Jis vėl pamirš.
Todėl, nors galime juos naudoti, turime atlikti kai kuriuos pakeitimus. Tada aš papasakosiu ir parodysiu juos naudodamas vieno iš esamų metodų ir įprasto failo formato pavyzdį.
Apie šakalus
Jei tikrai jį suspausite, tai yra labiausiai suspaudžiamas dalykas pasaulyje. Žinoma, mes kalbame apie JPEG failus. Yra ne tik daugybė įrankių ir esamų metodų duomenims įterpti, bet tai yra populiariausias grafikos formatas šioje planetoje.
Tačiau norint neužsiimti šunų veisimu, tokio formato failuose reikia apriboti savo veiklos sritį. Niekam nepatinka vienspalviai kvadratai, atsirandantys dėl per didelio suspaudimo, todėl reikia apsiriboti darbu su jau suglaudintu failu, vengiant perkoduoti. Tiksliau, su sveikųjų skaičių koeficientais, kurie lieka po operacijų, atsakingų už duomenų praradimą - DCT ir kvantavimą, kuris puikiai rodomas kodavimo schemoje (dėka Baumano nacionalinės bibliotekos wiki):
Yra daug galimų jpeg failų optimizavimo būdų. Yra optimizavimas be nuostolių (jpegtran), yra optimizavimas "
F5
Šias sąlygas atitinka visa eilė algoritmų, su kuriais galite susipažinti
Patys pakeitimai susiveda į tai, kad tam tikromis sąlygomis (ty ne visada) absoliuti koeficientų vertė sumažinama vienu, o tai leidžia naudoti F5, kad optimizuotumėte duomenų saugojimą standžiajame diske. Esmė ta, kad koeficientas po tokio pakeitimo greičiausiai užims mažiau bitų po Huffmano kodavimo dėl statistinio reikšmių pasiskirstymo JPEG formatu, o nauji nuliai padidins juos koduojant naudojant RLE.
Būtinos modifikacijos apsiriboja dalies, atsakingos už slaptumą (slaptažodžio pertvarkymas), pašalinimu, o tai taupo išteklius ir vykdymo laiką, ir prideda mechanizmą, skirtą dirbti su daugybe failų, o ne po vieną. Vargu ar skaitytojas bus suinteresuotas pakeitimų procesu išsamiau, todėl pereikime prie įgyvendinimo aprašymo.
Aukštosios technologijos
Norėdamas parodyti, kaip veikia šis metodas, įdiegiau metodą gryname C ir atlikau daugybę optimizavimo tiek vykdymo greičio, tiek atminties atžvilgiu (neįsivaizduojate, kiek šios nuotraukos sveria be suspaudimo, net prieš DCT). Keli platforma pasiekiama naudojant bibliotekų derinį
Diegimas pasiekiamas kaip konsolės įrankis ir biblioteka. Norintieji daugiau sužinoti apie pastarojo naudojimą gali Github saugykloje esančiame readme, kurios nuorodą pridėsiu įrašo pabaigoje.
Kaip naudotis?
Atsargiai. Pakavimui naudojami vaizdai parenkami ieškant naudojant reguliariąją išraišką duotame šakniniame kataloge. Baigę failus galima perkelti, pervardyti ir kopijuoti savo nuožiūra, keisti failus ir operacines sistemas ir pan. Tačiau turėtumėte būti ypač atsargūs ir jokiu būdu nekeisti tiesioginio turinio. Praradus net vieno bito vertę gali būti neįmanoma atkurti informacijos.
Pasibaigus programai, programa palieka specialų archyvo failą, kuriame yra visa išpakavimui reikalinga informacija, įskaitant duomenis apie naudojamus vaizdus. Jis pats savaime sveria apie porą kilobaitų ir neturi jokios reikšmingos įtakos užimtai vietai diske.
Galite analizuoti galimą talpą naudodami žymą „-a“: „./f5ar -a [paieškos aplankas] [Su Perl suderinama reguliari išraiška]“. Supakavimas atliekamas naudojant komandą „./f5ar -p [paieškos aplankas] [su Perl suderinamas reguliarusis posakis] [supakuotas failas] [archyvo pavadinimas]“, o išpakavimas atliekamas naudojant „./f5ar -u [archyvo failas] [atkurto failo pavadinimas“. ]' .
Darbo demonstravimas
Kad parodyčiau metodo efektyvumą, iš tarnybos įkėliau 225 visiškai nemokamų šunų nuotraukų kolekciją.
Seka gana paprasta:
$ 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/
Ekrano nuotraukos gerbėjams
Išpakuotą failą galima ir vis tiek reikia skaityti:
Kaip matote, iš originalių 633 + 36 == 669 megabaitų duomenų standžiajame diske priėjome prie malonesnio 551. Toks radikalus skirtumas paaiškinamas koeficientų reikšmių sumažėjimu, kuris turi įtakos jų dydžiui. vėlesnis glaudinimas be nuostolių: sumažinimas po vieną gali lengvai „atpjauti keletą baitų iš galutinio failo. Tačiau tai vis tiek yra duomenų praradimas, nors ir labai mažas, su kuriuo turėsite taikstytis.
Laimei, jie yra visiškai nematomi akiai. Po spoileriu (kadangi habrastorage negali apdoroti didelių failų) skaitytojas gali įvertinti skirtumą tiek akimis, tiek jų intensyvumu, gautu iš originalo atėmus pakeisto komponento reikšmes:
Vietoj išvados
Atsižvelgiant į visus šiuos sunkumus, kietojo disko pirkimas ar visko įkėlimas į debesį gali atrodyti kaip daug paprastesnis problemos sprendimas. Bet nors dabar gyvename tokiu nuostabiu laiku, nėra garantijų, kad rytoj vis tiek bus galima prisijungti ir kur nors įkelti visus papildomus duomenis. Arba eikite į parduotuvę ir nusipirkite sau dar tūkstančio terabaitų standųjį diską. Bet jūs visada galite naudoti esamus namus.
->
Šaltinis: www.habr.com