Alia uzanto volas skribi novan datumon al la malmola disko, sed li ne havas sufiĉe da libera spaco por fari tion. Mi ankaŭ volas nenion forigi, ĉar "ĉio estas tre grava kaj necesa". Kaj kion ni faru kun ĝi?
Neniu havas ĉi tiun problemon. Estas terabajtoj da informoj sur niaj malmolaj diskoj, kaj ĉi tiu kvanto ne emas malpliiĝi. Sed kiom unika ĝi estas? En la fino, ĉiuj dosieroj estas nur aroj da bitoj de certa longo kaj, plej verŝajne, la nova ne multe diferencas de tiu, kiu estas jam konservita.
Estas klare, ke serĉi informojn jam konservitajn sur durdisko estas, se ne fiasko, tiam almenaŭ ne efika tasko. Aliflanke, se la diferenco estas malgranda, tiam vi povas ĝustigi ĝin iomete...
TL;DR - la dua provo paroli pri stranga metodo por optimumigi datumojn per JPEG-dosieroj, nun en pli komprenebla formo.
Pri pecoj kaj diferenco
Se vi prenas du tute hazardajn pecojn da datumoj, tiam averaĝe duono de la bitoj, kiujn ili enhavas, koincidas. Efektive, inter la eblaj aranĝoj por ĉiu paro ('00, 01, 10, 11′), ĝuste duono havas la samajn valorojn, ĉio estas simpla ĉi tie.
Sed kompreneble, se ni nur prenas du dosierojn kaj alĝustigu unu al la dua, tiam ni perdos unu el ili. Se ni konservos la ŝanĝojn, ni simple reinventos
Inter kio kaj kio do oni povas forigi la diferencon? Nu, tio estas, nova dosiero skribita de la uzanto estas nur sinsekvo de bitoj, per kiuj ni ne povas fari ion per si mem. Tiam vi nur bezonas trovi tiajn pecojn sur la malmola disko, ke ili povas esti ŝanĝitaj sen devi konservi la diferencon, por ke vi povu postvivi ilian perdon sen gravaj sekvoj. Kaj estas senco ŝanĝi ne nur la dosieron sur la FS mem, sed iujn malpli sentemajn informojn ene de ĝi. Sed kiu kaj kiel?
Agordaj metodoj
Perdaj kunpremitaj dosieroj venas al la savo. Ĉiuj ĉi tiuj jpeg-oj, mp3-oj kaj aliaj, kvankam perda kunpremado, enhavas amason da pecetoj, kiuj povas esti sekure ŝanĝitaj. Eblas uzi altnivelajn teknikojn, kiuj nerimarkeble modifas siajn komponantojn en diversaj stadioj de kodado. Atendu. Altnivelaj teknikoj... nerimarkebla modifo... iom en alian... estas preskaŭ kvazaŭ
Efektive, enigi unu informon en alian rememorigas ŝiajn metodojn kiel nenio alia. Ankaŭ min impresas la nerimarkebleco de la ŝanĝoj faritaj al la homaj sentoj. Kie la vojoj diverĝas estas sekrete: nia tasko dependas de la uzanto enigi pliajn informojn sur sian malmolan diskon; ĝi nur damaĝos lin. Li denove forgesos.
Tial, kvankam ni povas uzi ilin, ni devas fari iujn modifojn. Kaj tiam mi rakontos kaj montros ilin uzante la ekzemplon de unu el la ekzistantaj metodoj kaj komuna dosierformato.
Pri ŝakaloj
Se vi vere premas ĝin, ĝi estas la plej kunpremebla afero en la mondo. Ni, kompreneble, parolas pri JPEG-dosieroj. Ne nur ekzistas tunoj da iloj kaj ekzistantaj metodoj por enigi datumojn en ĝin, sed ĝi estas la plej populara grafika formato sur ĉi tiu planedo.
Tamen, por ne okupiĝi pri hunda bredado, vi devas limigi vian agadkampon en dosieroj de ĉi tiu formato. Neniu ŝatas monokromatajn kvadratojn, kiuj aperas pro troa kunpremo, do vi devas limigi vin labori kun jam kunpremita dosiero, evitante rekodigon. Pli specife, kun entjeraj koeficientoj, kiuj restas post operacioj respondecaj pri datumperdo - DCT kaj kvantigo, kiu perfekte montriĝas en la kodoskemo (danke al la vikio de la Nacia Biblioteko Bauman):
Estas multaj eblaj metodoj por optimumigi jpeg-dosierojn. Estas senperda optimumigo (jpegtran), estas optimumigo "
F5
Tuta familio de algoritmoj taŭgas por ĉi tiuj kondiĉoj, kun kiuj vi povas konatiĝi
La ŝanĝoj mem resumiĝas al redukto de la absoluta valoro de la koeficientoj je unu sub certaj kondiĉoj (tio estas, ne ĉiam), kio permesas vin uzi F5 por optimumigi datumstokadon sur via malmola disko. La punkto estas, ke la koeficiento post tia ŝanĝo plej verŝajne okupos malpli da bitoj post la kodado de Huffman pro la statistika distribuo de valoroj en JPEG, kaj la novaj nuloj donos gajnon kiam ili kodigos ilin per RLE.
La necesaj modifoj resumas al forigi la parton respondecan pri sekreteco (pasvortrearanĝo), kiu ŝparas rimedojn kaj ekzekuttempon, kaj aldonado de mekanismo por labori kun multaj dosieroj anstataŭ unu samtempe. La leganto verŝajne ne interesiĝos pri la ŝanĝprocezo pli detale, do ni transiru al priskribo de la efektivigo.
Alta teknologio
Por pruvi kiel ĉi tiu aliro funkcias, mi efektivigis la metodon en pura C kaj efektivigis kelkajn optimumojn kaj laŭ ekzekutrapideco kaj memoro (vi ne povas imagi kiom pezas ĉi tiuj bildoj sen kunpremado, eĉ antaŭ DCT). Multiplataforma atingita uzante kombinaĵon de bibliotekoj
La efektivigo haveblas en la formo de konzola ilo kaj biblioteko. Interesitoj povas ekscii pli pri uzado de ĉi-lasta en la legu min en la deponejo ĉe Github, la ligilon al kiu mi aldonos fine de la afiŝo.
Kiel uzi?
Zorgeme. La bildoj uzataj por pakado estas elektitaj per serĉado per regula esprimo en la donita radika dosierujo. Post kompletigo, dosieroj povas esti movitaj, renomitaj kaj kopiitaj laŭvole ene de ĝiaj limoj, ŝanĝi dosierojn kaj operaciumojn, ktp. Tamen vi devas esti ege singarda kaj ne ŝanĝi la tujan enhavon iel ajn. Perdi la valoron de eĉ unu bito povas malebligi reakiri informojn.
Post kompletigo, la utileco lasas specialan arkivan dosieron enhavantan ĉiujn informojn necesajn por malpakado, inkluzive de datumoj pri la uzitaj bildoj. Per si mem, ĝi pezas proksimume kelkajn kilobajtojn kaj ne havas signifan efikon al la okupata diskspaco.
Vi povas analizi la eblan kapaciton uzante la flagon '-a': './f5ar -a [serĉa dosierujo] [Perl-kongrua regula esprimo]'. Pakado estas farita per la komando './f5ar -p [serĉa dosierujo] [Perl-kongrua regula esprimo] [pakita dosiero] [arkivnomo]', kaj malpakado per './f5ar -u [arkivodosiero] [reakirita dosiernomo. ]' .
Demonstro de laboro
Por montri la efikecon de la metodo, mi alŝutis kolekton de 225 absolute senpagaj fotoj de hundoj de la servo
La sinsekvo estas sufiĉe simpla:
$ 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/
Ekrankopioj por ŝatantoj
La malpakita dosiero povas kaj devas esti legita:
Kiel vi povas vidi, de la originalaj 633 + 36 == 669 megabajtoj da datumoj sur la malmola disko, ni venis al pli agrabla 551. Tia radikala diferenco estas klarigita per la malkresko de la valoroj de la koeficientoj, kiu influas ilian posta senperda kunpremado: redukto de unu nur unu povas facile " detranĉi kelkajn bajtojn de la fina dosiero. Tamen, ĉi tio ankoraŭ estas perdo de datumoj, kvankam ege malgranda, kiun vi devos toleri.
Feliĉe, ili estas absolute nevideblaj al la okulo. Sub la spoiler (ĉar habrastorage ne povas manipuli grandajn dosierojn), la leganto povas taksi la diferencon kaj per okulo kaj ilia intenseco, akirita per subtraho de la valoroj de la ŝanĝita komponanto de la originalo:
Anstataŭ konkludo
Konsiderante ĉiujn ĉi tiujn malfacilaĵojn, aĉeti malmolan diskon aŭ alŝuti ĉion al la nubo povas ŝajni multe pli simpla solvo al la problemo. Sed kvankam ni vivas en tia mirinda tempo nun, ne estas garantioj, ke morgaŭ ankoraŭ eblos interrete kaj alŝuti ĉiujn viajn kromajn datumojn ien. Aŭ iru al la vendejo kaj aĉetu al vi alian mil terabajtan malmolan diskon. Sed vi ĉiam povas uzi ekzistantajn domojn.
->
fonto: www.habr.com