Një përdorues tjetër dëshiron të regjistrojë një copë të re të dhënash në hard disk, por i mungon hapësira e lirë për këtë. Nuk dëshiron të fshij asgjë, pasi "gjithçka është shumë e rëndësishme dhe e nevojshme". Çfarë duhet të bëjmë me të?
Kjo problematikë nuk ndodhet vetëm te ai. Në hard diskët tanë prehen terabajt informacionesh, dhe kjo sasi nuk po bie. Por sa unike është ajo? Fundja, të gjitha skedarët nuk janë gjë tjetër veçse grupe bitësh me gjatësi të caktuar dhe, shumë për të, i reja nuk dallohet shumë nga ajo që është e ruajtur tashmë.
E kuptueshme, që të kërkosh për copat e informacionit të ruajtura në hard disk është një detyrë, nëse jo e dështuar, së paku joefikase. Në anën tjetër, nëse dallimi është i vogël, mund ta përshtatim disi...
TL;DR — një përpjekje tjetër për të treguar një metodë të çuditshme të optimizimit të të dhënave duke përdorur skedarë JPEG, tani në një format më të kuptueshëm.
Për bitët dhe dallimin
Nëse marrim dy copa të dhënash të rastësishme, atëherë në mes tyre përputhen në mesatare gjysma e bitëve të përfshira. Në të vërtetë, mes të gjitha kombinimeve të mundshme për çdo çift (’00, 01, 10, 11′), saktësisht gjysma ka vlera të përputhshme, këtu gjithçka është e thjeshtë.
Por sigurisht, nëse thjesht marrim dy skedarë dhe përshtatim njëri-një dhe, do të humbim njërin prej tyre. Nëse do t’i ruajmë ndryshimet, atëherë thjesht do të rindërtojmë , i cili edhe pa ne ekziston mjaft mirë, megjithëse zakonisht nuk përdoret për këto qëllime. Mund të përpiqemi të integrojmë një sekuencë më të vogël brenda një më të madhe, por edhe kështu rrezikojmë të humbasim segmente kritike të të dhënave në përdorim të papërgjegjshëm me çdo gjë.
Ajo çfarë mund të eliminojmë dallimin mes çfarë? Domethënë, skedari i ri që regjistrohet nga përdoruesi është thjesht një sekuencë bitësh, me të cilën ne vetë nuk mund të bëjmë asgjë. Atëherë duhet thjesht të gjejmë në hard disk atyre bitëve, në mënyrë që të mund të ndryshohen pa nevojën për të ruajtur diferencën, për të përballuar humbjen e tyre pa pasoja serioze. Dhe ka kuptim të ndryshohet jo vetëm vetë skedari në FSH, por ndonjë informacion më pak të ndjeshëm brenda tij. Por çfarë dhe si?
Metodat e përshtatjes
Files compressed with loss come to the rescue. All these jpegs, mp3s, and others, although they involve lossy compression, contain a lot of bits that can be safely modified. Advanced techniques can be used to subtly alter their components in various coding sections. Wait. Advanced techniques... subtle modification... bits into others... this is almost what !
Indeed, embedding one piece of information into another closely resembles its methods. The inconspicuousness of the changes made to human senses is also impressive. However, the paths diverge in secrecy: our task boils down to the user adding additional information to their hard drive, which will only cause them trouble. They'll forget it soon.
Therefore, even if we can use them, some modifications need to be made. I will explain and show these modifications using one of the existing methods and a widely used file format.
About jackals
If you are going to compress, compress the most compressible in the world. It’s obviously about JPEG files. Not only is there a ton of tools and existing methods to embed data into them, but it is also the most popular graphic format on the planet.
Nonetheless, to avoid excess, it’s necessary to limit the focus to files of this format. Nobody likes single-color squares that appear due to excessive compression, so it’s best to work with an already compressed file, avoiding transcoding. More specifically — with integer coefficients that remain after operations responsible for data loss — DCT and quantization, beautifully illustrated in the coding chart (thanks to the Bauman national library wiki):
There are numerous possible methods to optimize jpeg files. There is lossless optimization (jpegtran), and there is optimization that brings noticeable changes, but we won't be concerned with that. After all, if the user is ready to embed one piece of information into another for the sake of increasing free disk space, then they have either long optimized their images or prefer not to do so out of fear of losing quality.F5
F5
Këto kushte i përshtaten një familje të tërë algoritmesh, me të cilët mund të njiheni . Algoritmi më i avancuar ndër ta është në autorësinë e Andreas Westfeld, që punon me koeficientët e komponentës së ndriçimit, pasi syri njerzor është më pak i ndjeshëm ndaj ndryshimeve të saj. Më shumë se kaq, ai përdor një metodologi të enkriptimit, bazuar në kodimin e matricave, duke e lejuar kështu të bëjë më pak ndryshime në enkriptimin e të njëjtit informacion sa më i madh të jetë madhësia e enkriptuesit të përdorur.
Ndryshimet vijnë si rezultat i reduktimit të vlerës absolute të koeficientëve me një njësi në kushte të caktuara (dmth, jo gjithmonë), e cila lejon përdorimin e F5 për optimizimin e ruajtjes së të dhënave në hard disk. Problemi është se koeficienti pas këtij ndryshimi, me siguri, do të zërë një numër më të vogël bitësh pas kryerjes së kodimit Huffman për shkak të shpërndarjes statistikore të vlerave në JPEG, dhe zerot e rinj do të sjellin përfitime në kodimin e tyre me RLE.
Modifikimet e nevojshme reduktohen në eliminimin e pjesës që lidhet me sekretin (këmbimi i fjalëkalimeve), e cila lejon disa kursime burimesh dhe kohëzgjatjeje, dhe shtimin e mekanizmit për të punuar me shumë skedare në vend të njëri-tjetrit. Procesi i ndryshimit, me siguri, do të jetë i padëshirueshëm për lexuesin, prandaj kalojmë në përshkrimin e zbatimit.
Teknologji të larta
Për të demonstruar funksionimin e këtij qasje, kam implementuar një metodë në C të pastër dhe kam kryer një sërë optimizimesh për sa i përket shpejtësisë dhe kujtesës (nuk e imagjinoni sa peshojnë këto imazhe pa kompresim edhe deri në DCT). Platforma e ndërthurur u arrit përmes përdorimit të një kombinimi bibliotekash , dhe , për të cilat u falenderoj. Të gjitha këto mblidhen me ‘make’, prandaj përdoruesit e Windows duhet të instalojnë ndonjë Cygwin ose të merren me Visual Studio dhe bibliotekat e tjera vetë.
Implementimi është i disponueshëm si një utilitet konsolë dhe bibliotekë. Më shumë për përdorimin e këtij të fundit, ata që janë të interesuar mund të informohen në README në repo në GitHub, për lidhjen e të cilës do të përfshij në fund të postës.
Si të përdorni?
Me kujdes. Imazhet e përdorura për paketimin zgjidhen duke kërkuar me shprehje të rregullta në direktorinë e përcaktuar. Pasi të përfundojë, skedarët mund të transferohen, rinovohen dhe kopjohen sipas dëshirës brenda saj, të ndryshohen sistemet e skedarit dhe ato operative, etj. Megjithatë, duhen marrë masa jashtëzakonisht të kujdesshme dhe përmbajtja e drejtpërdrejtë nuk duhet të ndryshohet. Humbja e vlerës edhe të një biti mund të çojë në pamundësinë për të rikuperuar informacionin.
Pas përfundimit të punës, utilitarja lë një skedë arkivi speciale, e cila përmban gjithë informacionin e nevojshëm për dekomprimimin, duke përfshirë të dhënat mbi imazhet e përdorura. Ai vetë peson afërsisht disa kilobajtë dhe nuk ka ndonjë ndikim të rëndësishëm në hapësirën e okupuar në disk.
Mund të analizoni kapacitetin e mundshëm me ndihmën e flamurit '-a': './f5ar -a [folderi i kërkimit] [shprehja e rregullt e përputhshme me Perl]'. Paketimi bëhet me komandën './f5ar -p [folderi i kërkimit] [shprehja e rregullt e përputhshme me Perl] [skedari i paketuar] [emri i arkivit]', ndërsa dekomprimimi me './f5ar -u [skedari i arkivit] [emri i skedarit të rikuperuar]'.
Demonstrimi i funksionimit
Për të treguar efikasitetin e metodës, kam ngarkuar një koleksion prej 225 fotografive të papaguara të qenve nga shërbimi dhe gjeti në dokumente një pdf të madhe 45 metra nga vëllimi i dytë Knuth.
Seanci është mjaft e thjeshtë:
$ du -sh knuth.pdf dogs/
44M knuth.pdf
633M dogs/
$ ./f5ar -p dogs/ .*jpg knuth.pdf dogs.f5ar
Duke lexuar skedarin e kompresimit... në rregull
Duke iniciuar arkivin... në rregull
Duke analizuar kapacitetin e bibliotekës... e bërë në 17.0s
Kapaciteti i garantuar u zbulua shpërblim 48439359 byte
Kapaciteti i mundshëm deri në 102618787 byte
Duke kompresuar... e bërë në 39.4s
Duke shpëtuar arkivin... në rregull
$ ./f5ar -u dogs/dogs.f5ar knuth_unpacked.pdf
Duke iniciuar arkivin... në rregull
Duke lexuar skedarin e arkivit... në rregull
Duke mbushur arkivin me skedarë... e bërë në 1.4s
Duke dekompresuar... e bëra në 21.0s
Duke shkruar të dhënat e nxjerra... në rregull
$ sha1sum knuth.pdf knuth_unpacked.pdf
5bd1f496d2e45e382f33959eae5ab15da12cd666 knuth.pdf
5bd1f496d2e45e382f33959eae5ab15da12cd666 knuth_unpacked.pdf
$ du -sh dogs/
551M dogs/Screenshot për adhuruesit
Skedari i dekomprimuar ende mund dhe duhet të lexohet:
Si e duket, nga 633 + 36 == 669 megabajt të dhënash në hard disk, arritëm në 551 më të këndshme. Ky ndryshim radikal shpjegohet nga reduktimi i vlerave të koeficientëve, që ndikojnë në kompresimin e mëpasshëm pa humbje: reduktimi me vetëm një njësi mund të "prishë" disa byte nga skedari final. Megjithatë, këto janë akoma humbje të dhënash, edhe pse jashtëzakonisht të vogla, me të cilat duhet të pajtohemi.
Fatmirësisht, ato nuk janë aspak të dukshme për syrin. Nën spoiler (pasi habrastorage nuk mbështet skedarë të mëdhenj) lexuesi mund të vlerësojë ndryshimin si me sy ashtu edhe intensitetin e tij, të marrë nga zbritja e vlerave të komponentës të ndryshuara nga origjinali: , , (sa më e zbehtë të jetë ngjyra, aq më pak ndryshim ka në bllok).
Në përfundim
Duke parë të gjitha këto vështirësi, blerja e një hard disku ose ngarkimi i të gjitha në re mund të duket si një zgjidhje shumë më e thjeshtë e problemit. Por, ndonëse tani jetojmë në një kohë kaq të mrekullueshme, nuk ka asnjë garanci se nesër do të jetë ende e mundur të lidhemi në internet dhe të ngarkojmë të dhënat tona të tepërta diku. Ose të shkojmë në dyqan dhe të blejmë një hard disk tjetër prej një mijë terabajtësh. Por, përdorimi i atyre që janë rënduar në shtëpi mund të bëhet gjithmonë.
->
Burimi: habr.com
