'n Ander gebruiker wil 'n nuwe stuk data op die hardeskyf skryf, maar hy het nie genoeg vrye spasie om dit te doen nie. Ek wil ook niks uitvee nie, aangesien "alles baie belangrik en nodig is." En wat moet ons daarmee doen?
Niemand het hierdie probleem nie. Daar is teragrepe van inligting op ons hardeskywe, en hierdie hoeveelheid is nie geneig om te verminder nie. Maar hoe uniek is dit? Op die ou end is alle lêers net stelle stukkies van 'n sekere lengte en heel waarskynlik verskil die nuwe een nie veel van die een wat reeds gestoor is nie.
Dit is duidelik dat soek na stukke inligting wat reeds op 'n hardeskyf gestoor is, indien nie 'n mislukking nie, dan ten minste nie 'n doeltreffende taak is nie. Aan die ander kant, as die verskil klein is, dan kan jy dit 'n bietjie aanpas ...
TL;DR - die tweede poging om te praat oor 'n vreemde metode om data met behulp van JPEG-lêers te optimaliseer, nou in 'n meer verstaanbare vorm.
Oor stukkies en verskille
As jy twee heeltemal ewekansige stukke data neem, val gemiddeld die helfte van die stukkies wat hulle bevat saam. Inderdaad, onder die moontlike uitlegte vir elke paar ('00, 01, 10, 11′), het presies die helfte dieselfde waardes, alles is eenvoudig hier.
Maar natuurlik, as ons net twee lêers neem en een by die tweede pas, dan sal ons een van hulle verloor. As ons die veranderinge stoor, sal ons eenvoudig weer uitvind , wat heeltemal goed bestaan sonder ons, hoewel dit nie gewoonlik vir dieselfde doeleindes gebruik word nie. Ons kan probeer om 'n kleiner reeks in 'n groter een in te sluit, maar selfs so loop ons die risiko om kritieke segmente van data te verloor as ons dit roekeloos met alles gebruik.
Tussen wat en wat kan die verskil dan uitgeskakel word? Wel, dit wil sê, 'n nuwe lêer wat deur die gebruiker geskryf is, is net 'n reeks stukkies, waarmee ons niks op sigself kan doen nie. Dan moet jy net sulke stukkies op die hardeskyf kry dat hulle verander kan word sonder dat jy die verskil hoef te stoor, sodat jy hul verlies sonder ernstige gevolge kan oorleef. En dit maak sin om nie net die lêer op die FS self te verander nie, maar 'n paar minder sensitiewe inligting daarin. Maar watter een en hoe?
Pasmetodes
Lossy saamgeperste lêers kom tot die redding. Al hierdie jpeg's, mp3's en ander, alhoewel kompressie verlies, bevat 'n klomp stukkies wat veilig verander kan word. Dit is moontlik om gevorderde tegnieke te gebruik wat hul komponente op verskillende stadiums van enkodering onmerkbaar verander. Wag. Gevorderde tegnieke ... onmerkbare modifikasie ... een bietjie in 'n ander ... dit is amper soos !
Inderdaad, die inbedding van een inligting in 'n ander herinner aan haar metodes soos niks anders nie. Ek is ook beïndruk deur die onmerkbaarheid van die veranderinge wat aan die menslike sintuie gemaak is. Waar die paaie verskil, is in geheimhouding: ons taak kom daarop neer dat die gebruiker bykomende inligting op sy hardeskyf invoer; dit sal hom net benadeel. Hy sal weer vergeet.
Daarom, hoewel ons dit kan gebruik, moet ons 'n paar wysigings aanbring. En dan sal ek hulle vertel en wys deur die voorbeeld van een van die bestaande metodes en 'n algemene lêerformaat te gebruik.
Oor jakkalse
As jy dit regtig druk, is dit die mees saamdrukbare ding in die wêreld. Ons praat natuurlik van JPEG-lêers. Nie net is daar tonne gereedskap en bestaande metodes om data daarin in te sluit nie, maar dit is die gewildste grafiese formaat op hierdie planeet.
Om egter nie by hondeteling betrokke te raak nie, moet jy jou aktiwiteitsveld in lêers van hierdie formaat beperk. Niemand hou van monochrome blokkies wat verskyn as gevolg van oormatige kompressie nie, so jy moet jouself beperk tot werk met 'n reeds saamgeperste lêer, vermy herkodering. Meer spesifiek, met heelgetalkoëffisiënte, wat oorbly na bedrywighede wat verantwoordelik is vir dataverlies - DCT en kwantisering, wat perfek vertoon word in die enkoderingskema (danksy die wiki van die Bauman Nasionale Biblioteek):
Daar is baie moontlike metodes om jpeg-lêers te optimaliseer. Daar is verlieslose optimalisering (jpegtran), daar is optimalisering "“, wat eintlik iets anders bydra, maar ons gee nie om vir hulle nie. Na alles, as die gebruiker gereed is om een inligting in 'n ander in te sluit om vrye skyfspasie te vergroot, dan het hy sy beelde lank gelede geoptimaliseer, of wil dit glad nie doen nie uit vrees vir verlies aan kwaliteit.
F5
’n Hele familie algoritmes pas by hierdie toestande, waarmee jy jouself kan vergewis . Die mees gevorderde van hulle is die algoritme deur Andreas Westfeld, wat met die koëffisiënte van die helderheidskomponent werk, aangesien die menslike oog die minste sensitief is vir die veranderinge daarvan. Boonop gebruik dit 'n inbeddingstegniek gebaseer op matrikskodering, wat dit moontlik maak om minder veranderinge aan te bring wanneer dieselfde hoeveelheid inligting ingebed word, hoe groter die grootte van die houer wat gebruik word.
Die veranderinge self kom daarop neer dat die absolute waarde van die koëffisiënte onder sekere omstandighede (dit wil sê nie altyd) met een verminder word, wat jou toelaat om F5 te gebruik om databerging op jou hardeskyf te optimaliseer. Die punt is dat die koëffisiënt na so 'n verandering heel waarskynlik minder bisse sal beset na Huffman-kodering as gevolg van die statistiese verspreiding van waardes in JPEG, en die nuwe nulle sal 'n wins gee wanneer dit met RLE gekodeer word.
Die nodige wysigings kom daarop neer om die deel wat verantwoordelik is vir geheimhouding (wagwoordherrangskikking), wat hulpbronne en uitvoeringstyd bespaar, uit te skakel en 'n meganisme by te voeg om met baie lêers te werk in plaas van een op 'n slag. Dit is onwaarskynlik dat die leser in meer besonderhede in die veranderingsproses sal belangstel, so kom ons gaan aan na 'n beskrywing van die implementering.
Hoë tegnologie
Om te demonstreer hoe hierdie benadering werk, het ek die metode in suiwer C geïmplementeer en 'n aantal optimaliserings uitgevoer, beide in terme van uitvoeringspoed en geheue (jy kan jou nie indink hoeveel hierdie prente weeg sonder kompressie nie, selfs voor DCT). Kruisplatform bereik met 'n kombinasie van biblioteke , и , waarvoor ons hulle bedank. Dit alles word saamgestel deur 'make', dus wil Windows-gebruikers 'n paar Cygwin vir hulself installeer vir evaluering, of met Visual Studio en biblioteke op hul eie omgaan.
Die implementering is beskikbaar in die vorm van 'n konsolehulpmiddel en biblioteek. Belangstellendes kan meer uitvind oor die gebruik van laasgenoemde in die readme in die repository op Github, die skakel waaraan ek aan die einde van die pos sal heg.
Hoe om te gebruik?
Versigtig. Die beelde wat vir verpakking gebruik word, word gekies deur te soek deur 'n gewone uitdrukking in die gegewe wortelgids te gebruik. Na voltooiing kan lêers na goeddunke binne sy grense geskuif, hernoem en gekopieer word, lêer en bedryfstelsels verander, ens. Jy moet egter uiters versigtig wees en nie die onmiddellike inhoud op enige manier verander nie. Om die waarde van selfs een bietjie te verloor, kan dit onmoontlik maak om inligting te herwin.
Na voltooiing laat die program 'n spesiale argieflêer wat al die inligting bevat wat nodig is om uit te pak, insluitend data oor die beelde wat gebruik is. Op sigself weeg dit ongeveer 'n paar kilogrepe en het geen noemenswaardige impak op die besette skyfspasie nie.
Jy kan die moontlike kapasiteit ontleed deur die '-a' vlag te gebruik: './f5ar -a [soekgids] [Perl-versoenbare gereelde uitdrukking]'. Verpakking word gedoen met die opdrag './f5ar -p [soek lêergids] [Perl-versoenbare gewone uitdrukking] [verpakte lêer] [argiefnaam]', en uitpak met './f5ar -u [argieflêer] [herwin lêernaam] ]'.
Demonstrasie van werk
Om die doeltreffendheid van die metode te wys, het ek 'n versameling van 225 absoluut gratis foto's van honde van die diens opgelaai en het in die dokumente 'n groot pdf van 45 meter van die tweede volume gevind Knuta.
Die volgorde is redelik eenvoudig:
$ 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/Skermkiekies vir aanhangers
Die uitgepakte lêer kan en moet steeds gelees word:
Soos u kan sien, het ons vanaf die oorspronklike 633 + 36 == 669 megagrepe data op die hardeskyf by meer aangename 551 gekom. So 'n radikale verskil word verklaar deur die afname in die waardes van die koëffisiënte, wat hul daaropvolgende verlieslose kompressie: om een vir een te verminder, kan maklik 'n paar grepe van die finale lêer afsny. Dit is egter steeds 'n dataverlies, al is dit 'n uiters klein een, waarmee u sal moet verdra.
Gelukkig is hulle absoluut onsigbaar vir die oog. Onder die bederf (aangesien habrastorage nie groot lêers kan hanteer nie), kan die leser die verskil volgens oog en hul intensiteit evalueer, verkry deur die waardes van die veranderde komponent van die oorspronklike af te trek: , , (hoe dowwer die kleur, hoe kleiner is die verskil in die blok).
In plaas daarvan om 'n gevolgtrekking
As u al hierdie probleme in ag neem, kan die aankoop van 'n hardeskyf of die oplaai van alles na die wolk na 'n baie eenvoudiger oplossing vir die probleem lyk. Maar al leef ons nou in so 'n wonderlike tyd, is daar geen waarborge dat dit môre steeds moontlik sal wees om aanlyn te gaan en al jou ekstra data iewers op te laai nie. Of gaan winkel toe en koop vir jou nog 'n duisend teragreep hardeskyf. Maar jy kan altyd bestaande huise gebruik.
->
Bron: will.com