Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 57 reacties
Submitter: Rafe

Dropbox heeft een tool ontwikkeld met de naam 'Lepton' om jpeg-beeldmateriaal zonder verlies gemiddeld 22 procent te comprimeren. Het scheelt naast veel opslagruimte ook veel in het direct streaming serveren van beelden en het drukt het bandbreedtegebruik.

DropboxHet opslagbedrijf schrijft op zijn blog dat het Lepton al heeft ingezet om 16 miljard beelden te comprimeren die op de servers van het bedrijf opgeslagen staan. Dit zou al een besparing van meerdere petabytes hebben opgeleverd.

Lepton voorspelt coëfficiënten in jpeg-blokken en voert deze voorspellingen als context in een rekenkundig model in. Lepton behoudt daarbij het originele jpeg-bestand bit-voor-bit. Het comprimeert de jpeg-bestanden met een snelheid van vijf megabyte per seconde en decodeert ze terug naar de originele bits met 15MB/s.

Een van de technieken die Lepton gebruikt, heeft te maken met het voorspellen van de verschillen in helderheid tussen groepen pixels. Het algoritme gebruikt daarvoor blokken pixels van 8 bij 8 pixels binnen de jpeg. Lepton kijkt naar de randen van een nog niet gecomprimeerd blok, dat omringd is door blokken waarbij de compressie al wel is uitgevoerd. Het algoritme weet de helderheidgradient van de randen van die blokken dus al. Op de scheidslijn tussen de gecodeerde en ongecodeerd blokken, neemt het algoritme in het midden een punt, en van hieruit wordt het verloop van de helderheid voorspeld. Lepton slaat vervolgens alleen de delta op tussen de voorspelling en de echte waarde.

Dropbox LeptonDropbox Lepton

Uit automatische testprocessen die Dropbox tot nu toe met Lepton heeft gedraaid, blijkt dat het zich deterministisch gedraagt, ofwel de uitkomst is altijd gelijk aan de invoer. Dit heeft het bedrijf nu al met meer dan 4 miljard beelden getest. Dit betekent dat op het moment dat Dropbox een beeld voor de eerste keer verifieert, het weer decodeert naar de originele bits waaruit de ingevoerde jpeg bestaat. Als dit zo is, dan kan ook in de toekomst altijd weer naar het originele bestand teruggegaan worden.

Om te voorkomen dat er toch fouten gemaakt worden door het compressie-algoritme, wordt elk gecomprimeerd bestand ten minste één keer gedecodeerd naar het ongecomprimeerde bestand en wordt het resultaat bit-voor-bit vergeleken met het origineel voordat het door Lepton gecomprimeerde bestand wordt doorgezet.

Het compressie-algoritme is open source en staat op GitHub. Dropbox nodigt de community uit mee te denken aan verbeteringen van het algoritme.

Moderatie-faq Wijzig weergave

Reacties (57)

Het is niet dat het algoritme de blokken van 8 bij 8 pixels 'binnen de jpeg' maakt, dit zijn namelijk al de blokken waar een JPEG afbeelding uit bestaat. JPEG werkt door middel van een DCT van de kleurwaardes van de pixels. Deze wordt per 8×8 blok pixels uitgevoerd, waarna de hoogste frequentie gegevens weggegooid worden (=> lossy compressie, je verliest details/gegevens ten opzichte van een bitmap of PNG afbeelding).

Wat Dropbox nu heeft gedaan, en wat dus nog niet gebeurde in JPEG, is een verband leggen tussen de gegevens van deze 8×8 blokken, om zo vergelijkbare blokken efficiënter te kunnen comprimeren. Dropbox claimt dat dit proces lossless (zonder verlies van gegevens) plaatsvindt.

Het is overigens niet zo dat deze compressie je afbeeldingen hiermee lossless comprimeert; je zit nog steeds met de lossy compressie inherent aan JPEG afbeeldingen. Echter garandeert Dropbox hier dat de extra compressie die ze bovenop JPEG compressie toepassen ("Lepton"), wél lossless is. Dat wil zeggen; het originele JPEG bestand komt weer te voorschijn wanneer je de afbeelding uit je Dropbox folder haalt.

Overigens best indrukwekkend dat ze met deze techniek zo'n 20% ruimtebesparing kunnen genereren. Probeer maar eens je vakantiefoto's in een zip-bestand te zetten. Daar bespaar je hooguit 4 à 5 procent mee, waarschijnlijk zelfs minder. Met de automatische synchronisatie van foto's die door veel gebruikers van Dropbox wordt gebruikt, is wel te begrijpen waarom dit zo'n grote impact heeft op de ruimtebesparing van Dropbox.
Is dit dezelfde compressie welke PAQ gebruikt?
https://en.wikipedia.org/wiki/PAQ
PAQ8o bijv; een singlethreaded compressor pakt jpeg bestanden nog verder in en kan het origineel precies repliceren. Het ziet zelfs jpeg-data in PDF bestanden die het comprimeert.
OneDrive zou dit ook kunnen inzetten. Alleen is PAQ extreem rekenintensief. Vandaar de vraag. Ook omdat er vermeldt wordt dat het met 5 MB/s gaat. Ongeveer hetzelfde wat PAQ haalt bij 12.000 MIPS.

[Reactie gewijzigd door jimh307 op 15 juli 2016 16:32]

Misschien een stomme vraag, maar zien we deze besparing ook terug als Dropbox gebruiker in totaal gebruikte opslagruimte? Of het is met name voor Dropbox een mooie besparing aan de server kant..
Dit is geen stomme vraag.
Dit zie je niet terug in je te gebruiken ruimte. Dit is puur een server-based compressie die ten gunste is voor de opslagruimte. Het heeft weinig zin zulke zware compressie te gebruiken als de bespaarde ruimte aan gebruikers terug moet worden gegeven. Het is een noodzaak die nodig is om de toenemende honger naar dataopslag het hoofd te kunnen bieden. De bespaarde terabytes bieden weer ruimte voor nieuwe accounts. Dus meer gebruikers van opslag voorzien met dezelfde capaciteit.
Wil je zelf zoveel mogelijk kwijt kunnen op je Dropbox-account dan zou je PAQ8o kunnen overwegen. Peazip ondersteund deze extreem zware compressie. Alleen haal je dan het gemak weg om snel een foto te kunnen delen met vrienden. Dropbox decomprimeert de data voordat deze op jouw beeldscherm terecht komen. Voor jou een gemak en voor hun besparing in opslagruimte. Voor elk wat wils :)
Ok helder. Als ze dat uiteindelijk voor alle data kunnen doen en zeg ca. 20-25% kunnen besparen, en mensen betalen voor de originele grootte is dat wel een interessante case.
Ik vraag me wel af of het inderdaad serverside gebeurt of dat het in de dropbox client verwerkt zit. In het artikel staat namelijk dat het ook voor bandbreedte besparing bedoelt is. Bovendien zal dat ze een hoop cpu tijd schelen.
Dit zie je niet terug in je te gebruiken ruimte. Dit is puur een server-based compressie die ten gunste is voor de opslagruimte. Het heeft weinig zin zulke zware compressie te gebruiken als de bespaarde ruimte aan gebruikers terug moet worden gegeven.
Zeker wel! De échte besparing is er voor Dropbox al als ze het gemiddelde verbruik van een gebruiker terug kunnen schroeven, ook als de limiet voor die gebruiker hetzelfde blijft.
Het is een noodzaak die nodig is om de toenemende honger naar dataopslag het hoofd te kunnen bieden. De bespaarde terabytes bieden weer ruimte voor nieuwe accounts. Dus meer gebruikers van opslag voorzien met dezelfde capaciteit.
Dropbox baseert zijn werkelijk beschikbare hoeveelheid opslagruimte op het gemiddelde verbruik van zijn gebruikers. De volledige opslagruimte die ze beloven bestaat niet: Nagenoeg niemand zit aan de limiet. Als iedere gebruiker nu tot aan de limiet zijn Dropbox volgooit, dan is de boel over een half uur nog offline.

Door het gemiddelde verbruik van een gebruiker met 20% terug te dringen kun je de hoeveelheid opslagruimte die je beschikbaar moet hebben ook terugdringen, óók als je het verminderde verbruik direct doorberekent aan de klanten.

Daarnaast is het ook nog zo dat het Dropbox rekenkracht bespaart als ze de compressie uit laten voeren bij hun klanten. Hun servers hoeven minder te doen, wat zich op zijn minst uit in minder energieverbruik, maar er ook zomaar voor kan zorgen dat er simpelweg minder servers ingezet hoeven te worden.

Reken daarbij nog eens het lagere bandbreedteverbruik (de bestanden die Dropbox vanuit zijn DC moet ontvangen en versturen zijn kleiner), en Dropbox moet eigenlijk wel gek zijn om deze compressie pas op de server toe te passen.

edit: typo

[Reactie gewijzigd door Patriot op 16 juli 2016 08:36]

Overigens best indrukwekkend dat ze met deze techniek zo'n 20% ruimtebesparing kunnen genereren. Probeer maar eens je vakantiefoto's in een zip-bestand te zetten. Daar bespaar je hooguit 4 à 5 procent mee, waarschijnlijk zelfs minder.
Je vergelijk met ZIP is nogal niets-zeggend: ZIP (net zoals RAR, deflate, 7zip, etc. etc.) is een generiek algorithme: het comprimeert bijna alle data wel een beetje, sommige soorten zelfs heel goed. Lepton is zeer specifiek: het werkt zo te horen prachtig op JPEG, maar alle andere soorten data is "meh, dat snap ik niet hoor"... Als ik zip data voer waar ie het heel goed op doet (bijvoorbeeld .txt of iets wat daar veel op lijkt, zoals .xml, .rst, .pas, .c, .h, ...) haalt ie al snel 70% compressie, tegen Lepton's 0%.

Met je constatering "indrukwekkend" ben ik het wel eens. :+

[Reactie gewijzigd door robvanwijk op 15 juli 2016 17:54]

Zou dit ook een indrukwekkende besparing opleveren op de macroblokken van AVC of HEVC / h264/h265 in video zoals .mp4?

20% is nogal een slok op een borrel en lijkt me erg interessant in video.
Met 15MB/s decode snelheid kan dat nog eens krap aan worden voor FHD, UHD en hoger. Elk beeld moet dan worden gedecode in een enkele seconde, ga ik gemakshalve uit van 60 frames per seconde, dan wordt het een flinke rekentaak en/of je geheugen wordt ook vol gegooid.
Daarnaast is x265/HVEC volgens mij deels hardwarematig geïmplementeerd om de snelheid te verbeteren, al ben ik een volledig leek op dat gebied.
15 MB/s is 120 Mbit. Een HD stream op Netflix is 5.8 Mbit. En dingen worden pass hardwarematig geïmplementeerd als ze eerst uitgevonden zijn. :)

Hoe toepasselijk het werkelijk is weet ik ook niet, vandaar de nieuwschierigheid, maar ik ben in ieder geval blij dat het open source is. Wie weet hoe de code toegepast gaat worden in de toekomst.
Ik ben geen expert, maar met mijn beperkte kennis en heel kort door de bocht:
MPEG is een JPEG (key frame), met daarna een heleboel keer een "diff" die alleen vertelt wat er veranderd is ten opzichte van het voorgaande frame (en bij de volgende scene / na maximaal x beelden heb je een nieuwe key frame). Je zou met deze techniek waarschijnlijk 20% kunnen besparen op het deel van de data waarin keyframes zijn vastgelegd; voor het deel dat alleen veranderingen vastlegt kun je (met de huidige versie van Lepton) nog niet eens één bitje verder comprimeren.

Wel zou je een Lepton-achtige benadering kunnen proberen om de bewegingen te voorspellen. Immers, als een bepaald stuk van het beeld zojuist tien pixels naar rechts en zes pixels naar boven is gegaan, dan is de volgende verandering waarschijnlijk veel dichter in de buurt van nog een keer tien naar rechts, zes naar boven, dan dat het nu opeens stilstaat. Of zo'n aanpak daadwerkelijk een kleinere file oplevert weet ik niet; om daar iets zinnigs over te zeggen zul je het ofwel moeten implementeren, ofwel heel veel verstand van videocodering moeten hebben.
Ja daar heb je wel een punt. Maar de veranderde (dus niet verplaatste) macroblokken in B- en P-frames zijn ook DCTs. Je zou kunnen zeggen dat een I-frame (of keyframe) een JPEG is (die dan dus 22% kleiner zou kunnen) en dat B- en P-frames een verzameling vectoren zijn met kleine stukjes JPEG zijn (en bij veel actie/verandering zijn dat er meer).

Ik kan het niet vinden, maar het zou interessant zijn om te zien hoeveel procent van de data in een videoframe bestaat uit unieke macroblokken.

Intra: 100%
Predicted: 40% (?)
Bi: 15% (?)

Hangt natuurlijk van het beeld, maar er zal wel een 'ongeveer' uitspraak te doen zijn.

[Reactie gewijzigd door Redsandro op 16 juli 2016 12:17]

De vergelijking met een general-purpose compressie algoritme zoals deflate gaat wel niet echt op.
Toffe technieke enzo (en dank voor de toelichting) maar is dit nou wezenlijk anders/beter dan bijv WebP?

Volgens mij is dit gewoon weer zon gevalletje 'we moeten wat doen om onder de aandacht te blijven', want tegenwoordig gebruiken volgens mij steeds minder mensen Dropbox (iedereen zn gratis ruimte-uitbreidingen (zoals die samsung jaren heeft uitgedeeld) lopen af hehe)
Hadden ze misschien beter gewoon WebP kunnen gaan gebruiken?

[Reactie gewijzigd door olivierh op 15 juli 2016 15:56]

Op de tweaker na zal niemand die Dropbox gebruikt dit weten en tevens zal ook geen gebruiker meer aangetrokken worden door deze techniek. Ze maken dit openbaar omdat ze de techniek open source hebben gemaakt en hopelijk daar naast hun eigen contributie aan de rest van de wereld mogelijk ook iets terug zien door handige(re) mensen die de code tweaken.
Ik zie het dan ook echt niet als onder de aandacht blijven.
Dus, als ik het goed begrijp (en ik heb ook even op de Github pagina gekeken) worden de JPEG files omgezet naar een ander formaat (*.lep) wat weer teruggeconverteerd kan worden naar het oorspronkelijke JPEG-formaat.

Het is dus niet een nieuwe techniek die compatible is met JPEG zelf (het is niet zo dat je er een JPEG file uit krijgt die gemiddeld 22% kleiner is dan het origineel).

Dus het is eigenlijk alleen handig als opslagformaat voor servers, maar als je het plaatje wilt zien moet het eerst weer teruggeconverteerd worden naar een *.jpg. Dus ruil je opslagruimte in voor processorkracht.
Dus het is eigenlijk alleen handig als opslagformaat voor servers, maar als je het plaatje wilt zien moet het eerst weer teruggeconverteerd worden naar een *.jpg. Dus ruil je opslagruimte in voor processorkracht.
Maar dat doe je ook door iets op te slaan als jpg en niet als bmp, niet? Er is dan ook een codeer/decodeerstap nodig die processorkracht vereist. Er komt vast een manier om direct van *.lep naar een plaatje op je scherm te gaan.
volgens mij doet uw eigen pc dat, het omzetten van jpg in iets zichtbaars
Precies. Mijn punt is dan ook dat je met een JPEG bestand ook processorkracht inruilt voor meer opslagruimte. Zo'n oplossing is dus niet alleen voor servers interessant.
Voor dat omzetten van jpeg op je eigen computer is wel een decoder nodig. Het algoritme om jpeg om te zetten in beeldmateriaal zit is zowat elk OS dat op de consumentenmarkt is. Voor *.lep bestanden is een apart stukje software nodig en het zal nog best lastig zijn om iedere Dropbox-gebruiker van deze decoder te voorzien.
Het is eigenlijk een beetje net zoals Flac-bestanden. Flac kan audio compacter opslaan zonder verlies, maar niet elk apparaat is voorzien van een Flac-decoder. Anders zou elke audio-cd opgenomen zijn in Flac zodat er ongeveer 2 uur aan audio op een CD past zonder verlies van kwaliteit.
Dat is dan slechts een kwestie van een decodeerstap voor een jpeg-viewer plaatsen.
Dat weet ik nog niet zo zeker.
jpeg-bestanden worden native ondersteund door zowat elk OS wat op de markt is. Bij het ophalen van *.lep bestanden is er inderdaad een extra stap nodig voordat jij de afbeeldingen kan zien. Dit kost extra software en buiten het feit dat dit niet zo erg is moet het toegankelijk zijn voor "elk" OS wat ook jpeg kan openen.
Hetzelfde als mijn antwoord een paar posts terug; als jij met *.lep bestanden kan werken met het gemak van jpeg dan is de ruimtebesparing op hun servers slechts een illusie. Ik vermoed dat het echt een intern iets is wat alleen gebeurt op hun servers. Hun besparen data, jij niet.
Dus het is eigenlijk alleen handig als opslagformaat voor servers, maar als je het plaatje wilt zien moet het eerst weer teruggeconverteerd worden naar een *.jpg. Dus ruil je opslagruimte in voor processorkracht.
Door dit in de Dropbox-client te bouwen kunnen ze het wel mooi combineren: minder opslag nodig in datacentra, minder dataverkeer/sneller syncen van JPG-bestanden. Decomprimeren met 15MB/s (aldus bronartikel) lijkt me snel zat om niet een merkbare vertraging te krijgen.
En maar 1/20e van mijn upload kunnen gebruiken om backups van mijn foto's maken? Liever doen ze die compressie maar aan de server kant.
Dat is enkel een kwestie van fine-tunen. In principe kunnen ze gewoon jouw computer zoveel mogelijk gebruiken en daarnaast nog gewoon jpg uploaden om op de server te doen. Alles wat op de client gebeurt is voor hun al een meevaller.

Niet iedereen zal jouw upload hebben namelijk. En zelfs met jouw upload kan je nog zelf iets comprimeren. Dit is distributed computing for the win als ze het goed gefinetuned krijgen.
Ik kan me voorstellen dat het op een platform als Dropbox wel wenselijk is om die ruil van opslagruimte voor processorkracht te maken. Waarschijnlijk is een overgroot deel van de meerderheid van de afbeeldingen op de servers enkel "opgeslagen" en worden niet continue bekeken/uitgelezen. Dus is de ruimtebesparing meer waard dan dat het kost aan de processorkracht.
Zijn we niet beter af als we zo snel mogelijk overstappen op formaten die van zichzelf al veel beter comprimeren dan jpeg, en allerlei andere wenselijke eigenschappen hebben zoals ook lossless compressie, en streaming (progressiv), en alpha channels?

Zoals bijvoorbeeld het .flif formaat wat in alle opzichten superieur is aan jpg.
Volgens hun eigen website zijn ze in alle opzichten superieur aan lossless jpg, maar ze vergelijken zichzelf niet met lossy jpg en dat is nu juist de variant die in de meeste gevallen voor foto's en dergelijke gebruikt worden. Je kunt wel raden waarom ze zichzelf niet vergelijken met lossy compressie: lossless compressie zal in de meeste gevallen grotere bestanden opleveren dan lossy compressie en daardoor is het geen eerlijke vergelijking. Als je genoegen neemt met een forse vermindering in beeldkwaliteit, zal jpg altijd een stuk kleiner zijn welke lossless compressie je ook bouwt.
Jazeker wel, ook lossy presteert flif veel beter dan jpeg.

Flif is van zichzelf een lossless formaat, maar progressive, dus streambaar en je kunt de stream c.q. het bestand voortijdig truncaten en dan heb je een kleiner, maar lossy resultaat. Dat laat zich prima vergelijken met jpegs met dezelfde kwaliteit (waarbij de jpeg bestanden dan altijd groter uitpakken) of met jpegs met dezelfde bestandsgrootte (waarbij de jpeg kwaliteit dan altijd lager uitpakt).
Dat zou op zich een aardige zijn, maar JPEG is zo ingeburgerd dat de support hiervoor zo goed is (alles kan overweg met JPEG) dat het beetje extra opslag voor lief wordt genomen. Bij video wordt er wel overgestapt, omdat de winst daar veel groter is en de hoeveelheid data zo groot is dat 50% kleiner ook heel veel oplevert.

Daarbij heb je bij 4K toch al andere hardware nodig t.o.v. een FullHD, dus kan er ook een nieuwe codec gebruikt worden. Overigens zal daarnaast ook het FullHD (H.264) beschikbaar zijn naast de 5K (H.265). Storage zijn niet de kosten. Bij streaming video zitten de kosten in de bandbreedte.
Ik snap die koppeling tussen codec en resolutie nooit zo. H.264 wordt vaak geassocieerd met FullHD, en H.265 (HEVC) met 4K / 5K content. Waarom, iedere random codec kan in principe toch content in iedere random resolutie bevatten? (even afgezien van compressie-gerelateerde restricties als dat het veelvouden van 8 of 16 moeten zijn e.d.)

Misschien ietwat offtopic hier omdat dit vooral voor videoformaten lijkt op te gaan en niet voor imageformaten, maar ik vroeg het me af.
jpeg 2000 bestaat ook al 16 jaar, maar wie gebruikt het?
Zeker waar, maar ik meen me vaag te herinneren dat er aan jpeg2000 indertijd allerlei licentie bezwaren kleefden. Geen idee of dat nog steeds relevant is, maar inmiddels zijn er al allerlei formaten (zoals dat Flif wat ik noemde, maar ook BPG, WebP, etc) wat in alle opzichten beter is, dus het bestaansrecht van jpeg2000 is al lang verdwenen.
Beïnvloed dit ook de afbeeldingen die lokaal staan, je eigen kopie dus in de folder die gesynchroniseerd wordt?
Nee, dit is enkel van toepassing op de server van Dropbox. Lokaal opgeslagen bestanden blijven exact hetzelfde als hoe jij ze hebt aangemaakt. Ook als je ze weer synct op een andere computer, zijn ze exact hetzelfde aan het origineel.

[Reactie gewijzigd door ultimate-tester op 15 juli 2016 14:19]

Best kans dat de Dropbox client op je eigen computer ze al wel omzet naar het Lepton formaat, gezien jouw processortijd gratis is voor Dropbox, en die van haar eigen servers niet.
Akkoord, maar dit was niet de vraag. De vraag was of het de afbeeldingen die lokaal staan beinvloed. Dit is niet het geval. Het is mogelijk dat de client ze alvast compressed voor het ze opstuurt, maar dit is niet terug te zien aan het originele bestand dat lokaal staat.
Oh zeker, het was ook bedoeld als toevoeging, niet zozeer een correctie. :)
Nee, dit zou betekenen dat alle image viewers deze compressie methode moeten ondersteunen, dit zal tijdens het downloaden weer omgezet worden naar het originele formaat.
Wat mij verbaast... hoe heeft Dropbox zomaar toegang tot die 4 miljard jpg bestanden? Zijn die niet encrypted met een sleutel die alleen de eigenaar heeft? :?
Nee, anders zou het niet mogelijk zijn om op een nieuwe computer de Dropbox client te installeren en bij de bestanden te komen, zonder bijvoorbeeld handmatig met een USB stick een sleutel over te brengen.

Dropbox gebruikt ook al langer andere manieren om opslagruimte te besparen, bijvoorbeeld door bestanden die meerdere gebruikers hebben slechts 1x op de server op te slaan indien ze precies hetzelfde zijn. Daarvoor is ook toegang tot de inhoud van de bestanden nodig.
Dropbox gebruikt ook al langer andere manieren om opslagruimte te besparen, bijvoorbeeld door bestanden die meerdere gebruikers hebben slechts 1x op de server op te slaan indien ze precies hetzelfde zijn. Daarvoor is ook toegang tot de inhoud van de bestanden nodig.
Ik meende juist dat ze hiervanaf gestapt waren vanwege het feit dat ze een piracy heaven werden. Gewoon tegen de dropbox-client zeggen dat je op een losse account die en die hash hebt en dropbox synched de films etc naar je toe.
Nee, daarvoor moet je bij bv. Stack of Mega zijn. Maar zelf dan is het beter om je bestanden op voorhand te encrypten
Ze zouden het eventueel in kunnen bouwen in de Dropbox Client, dan verplaatsen ze CPU load naar de gebruiker en verlagen ze de bandbreedte. Leuke techniek hoor.

[Reactie gewijzigd door DarkSand op 15 juli 2016 14:37]

Dat zuilen ze ongetwijfeld gaan doen. Computing is duurder dan storage, dus met een extra tussenstap wordt het alleen maar duurder dan simpelweg JPEGs oversturen. Maar ze hebben natuurlijk nu wel een leuke testset. :)

[Reactie gewijzigd door BugBoy op 15 juli 2016 15:57]

Zou dit algoritme ook gebruikt kunnen worden als plugin in je privé-NAS / -cloud zoals Freenas?
Dat kan je dan toch zelf maken? Alleen je moet wel eraan denken dat, net zoals hierboven beschreven word, dat je opslagruimte inruilt voor processorkracht. En dat laatste heb je niet al te veel op een NAS.

Alhoewel permanente back-ups wel handig met deze manier zouden kunnen.
Middle-outcompressie, net als in de tv-serie Silicon Valley. :)

Wat is de Weissman-score? :+
Dropbox doet me wel meer aan Hooli denken dan aan Pied Piper..
Huh, waar is Dropbox search dan? :P
Een besparing van 20% van je storage klinkt heel fijn, maar als je er zelf vervolgens flink wat extra computing power tegenaan moet gooien dan verdampt je winst heel snel. Computing is duurder dan storage in de meeste gevallen, dus dit principe kan eigenlijk alleen maar lonend zijn voor Dropbox als zowel de compressie en decompressie alvast op de client plaatsvinden. De client software wordt dus wat zwaarder en zal de CPU meer belasten.

Ik werk zelf aan een bestands uitwisselingsdienst (TransferXL) waar we hetzelfde grapje uithalen. In plaats van de ZIP file te maken op onze servers, wordt dit reeds in de browser gedaan. Daardoor heb je minder bandbreedte nodig, maar wij hoeven ook geen ZIP bestand te maken uit alle losse bestanden. Dat spaart een hele stap uit op de back-end, waardoor het voor ons goedkoper wordt, maar de download is ook nog eerder beschikbaar.

[Reactie gewijzigd door BugBoy op 15 juli 2016 15:52]

Op dit item kan niet meer gereageerd worden.



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x Watch_Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True