Er zijn nogal wat discussies over het Jan Sloot en zijn zgn. super algoritme/methode om video te opslaan. De discussies gaan over of het hoax is of niet. Laten we kijken of het hoax is. Zie ook deze link


Background informatie
[quote]
Het Sloot Digital Coding System (soes) zou de wereld opschudden: Een nieuw alfabet voor digitale informatieopslag dat niet langer meer gebruikmaakt van het binaire stelsel van nulletjes en eentjes, maar een veel efficiŽntere methode hanteert. Het principe werkte ogenschijnlijk simpel. Net zoals er voor een stuk tekst maar een beperkt aantal karakters beschikbaar is, wordt een film uit een eindig aantal kleuren en geluiden opgebouwd. Al die basisgegevens werden in vijf algoritmes in vijf verschillende geheugens opgeslagen. Bij de opslag van films zou ieder algoritme een maximale omvang van 74 megabyte krijgen. In totaal dus 370 megabyte: de motor van de vinding. Het enige wat nodig was om die te starten was een passende sleutel. Sloot berekende voor iedere bladzijde van een boek, of ieder beeld van een film, een unieke code waarvan het geheel ook weer resulteerde in een unieke code. Die laatste code, de sleutel, nam slechts ťťn kilobyte geheugen in beslag, ongeacht de lengte van de film of de dikte van het boek. Op ťťn simpele chipkaart konden op die manier tientallen sleutels worden opgeslagen. Iemand zou bijvoorbeeld, tegen betaling, met een gsm binnen enkele seconden de sleutels van een aantal films kunnen verkrijgen om die thuis via een afspeler met de basisalgoritmes te bekijken.
[/quote]


Persoonlijk denk ik dat het een grote hoax is, maar laat ik eerst wat informatie geven over basis compressie algoritmen en dan zul je zien dat het niet zo bijzonder is wat Sloot gedaan heeft en waarom het eigenlijk onmogelijk is.


Compressie
De basis principe van elke compressie algoritme is het herkennen van patronen. Doordat deze patronen meerdere keren voorkomen in de informatie kun je referenties naar deze patronen opslaan met een lijst van patronen. Een voorbeeld met een stukje tekst:


ik ga naar huis en omdat het erg druk is op straat ben ik erg laat thuis gekomen waardoor het eten koud is geworden. ben ik hier blij mee? ik weet het niet. ik ga meteen slapen omdat het eten koud was. volgende dag ben ik wakker geworden doordat er op straat door de drukte.....
 


Dit voorbeeld alinea bevat 280 karakters. We kunnen nu een aantal patronen herkenen die we als referentie kunnen opslaan. Voorbeeld van een patroon is het bijvoorbeeld: "ik ", en "huis " en "aa". Deze worden redundant genoemd omdat ze meerdere keren voorkomen. Het comprimeerde tekst zou er bijvoorbeeld zo uit kunnen zien:


4ga n1r 58om97erg druk $op str1t b84erg l1t t5gekom8w1rd3r 7et8#$gewor6n. b84hier blij m2? 4w2t 7niet. 4ga met2n slap8om97et8#was. volgen6 dag b84wakker gewor6n d3r9er op str1t d3r 6 drukte..... (1=aa2=ee3=oo4=ik 5=huis 6=de7=het 8=en 9=dat #=koud $=is )


Nu is de tekst 256 karakters geworden. Het lijkt misschien geen grote winst maar als je dit met een heel boek zou doen kun je aardig mee afsnoepen. De clou met patroon herkenning is, dat er genoeg referenties aanwezig moeten zijn om uiteindelijk winst te boeken ondanks de overhead voor opslag en administratie van de patronen. Om nog efficiŽnter bezig te zijn kun je nog bijvoorbeeld patronen binnen patronen gebruiken. Een voorbeeld hiervoor met de woorden zorghuis, zorgtehuis en zorghuis:


zorgtehuis zorghuis tehuis zorgtehuis zorghuis tehuis
stap 1.) 2te1 21 te1 2te1 21 te1(1=huis;2=zorg)
stap 2.) 5 4 3 5 4 3(1=huis;2=zorg;3=te1;4=21;5=23)
stap 3.) 6 6(1=huis;2=zorg;3=te1;4=21;5=23;6=5 4 3)
stap 4.) 7(1=huis;2=zorg;3=te1;4=21;5=23;6=5 4 3;7=6 6)


dus in het geval van


zorgtehuis zorghuis tehuis zorgtehuis zorghuis tehuis
zorg zorgtehuis zorghuis tehuis zorgtehuis zorghuis
tehuis



kun je dit vertalen naar


stap 1.) 2te1 21 te1 2te1 21 te1 2 2te1 21 te1 2te1 21
te1(1=huis;2=zorg)
stap 2.) 5 4 3 5 4 3 2 5 4 3 5 4 3
(1=huis;2=zorg;3=te1;4=21;5=23)
stap 3.) 6 6 2 6 6(1=huis;2=zorg;3=te1;4=21;5=23;6=5 4 3)
stap 4.) 7 2 7(1=huis;2=zorg;3=te1;4=21;5=23;6=5 4 3;7=6
6)



waarbij je bij de laatste 2 stappen een compressie krijgt van meer dan 50% in vergelijking met het originele tekst.


Sloot algoritme
Nu terugkomend op de algoritme van Sloot. Wat ik begrijp uit de quoted tekst is, dat Sloot een library heeft met een grootte van 370 MB en dat hij door gebruik te maken van deze library een 1ste referentie (sleutel) maakt en daarna deze verzameling van sleutel nog eens door versleuteld totdat hij de ultieme sleutel krijgt. Terugkomend op onze "huis en zorg" voorbeeld zou het als volgt uitzien:

zorgtehuis zorghuis tehuis zorgtehuis zorghuis tehuis
zorg zorgtehuis zorghuis tehuis zorgtehuis zorghuis
tehuis


wordt dus

23 21 3 23 21 3 2 231 21 31 231 21 31
 
waarbij 1, 2 en 3 gedefinieerd zijn in de library.

Hij gaat dan door en verkleint dit tot:
7 2 7 (4=21;5=23;6=5 4
3;7=6 6)

wat dan de uiteindelijke sleutel is.
Als je dus de library hebt, zou je in principe met "
7 2 7
(4=21;5=23;6=5 4 3;7=6 6)
"
het origineel kunnen reconstrueren. Als dan toevallig 4 en 5 ook in de library zouden voorkomen (omdat dit ook patroon is die vaak voorkomt) dan zou je genoeg hebben aan:


7 2 7 (7=5 4 3)
of 5 4 3 2 5 4 3


Dit zelfde principe zou je dus met video beelden ook kunnen doen. Ik ga vanuit dat dit het idee is achter de Sloot algoritme. Maar zoals al duidelijk is de library heel erg belangrijk. Laten we eens kijken naar bijvoorbeeld tekst en transfer van tekst documenten met html.


Er zijn ongeveer 50 tot 60 miljoen woorden in het nederlands met alle varianten (zie ook link). Laten we aannemen dat er eigenlijk 0,5 miljoen unieke basis woorden zijn en dat de rest hiervan kan worden afgeleid. Als je al deze woorden als referentie wilt opslaan heb je 5 bytes nodig. Stel we gebruiken 6 bytes om ook de voorkomende varianten te kunnen adresseren. Als we nu van uitgaan dat we alle woorden willen opslaan hebben we een bestand nodig van 0,5 miljoen * 5 karakters (gem. lengte woord) komen we uit op een bestand van ruwweg 2 MB. Hiernaast nog alle varianten van woorden gebaseerd op de basis library, laten we zeggen dat we dan een bestand hebben van 4MB. (Dit is ook ongeveer dezelfde grootte als de proofing tool voor NL die meegeleverd wordt met Microsoft Word). Nu gaan je deze nog eens met een tradionele zip actie comprimeren en heb je bestand van zeg 1 MB of misschien meer of minder. Nog wat overhead en we hebben nu een library van 1,2 MB.


Stel dat we nu een html of een tekst bestand hebben met een lap tekst met een grootte van 20 KB. Als we een zip actie uit laten voeren op een tekstbestand van 20 KB wordt deze al 4 KB. Omdat zip al de library ook al opslaat en in onze geval de library al voor gedefinieerd is kan dit stuk van de informatie uit de zip file. Ik denk dat we een bestand kunnen overhouden van 1 a 2 KB.Stel nu dat Microsoft, Linux en alle OS'sen deze library meeleveren en het algoritme toepassen op alle tekst based informatie. Dat betekent dus dat alle word documenten, html documenten etc, een factor 20 kleiner worden. Denk je nu eens in dat deze documenten over de Internet uitgewisseld worden. Bijvoorbeeld surfen op Internet gaat dan 20 keer zo snel. Met een traditionele modem lijn van 50 kps heb je nu eigenlijk een snelheid van 1000 kps wat toch rap is zou ik zeggen. Denk je eens in met mobiele telefoons en SMS. In plaats van 255 karakter kun je nu bijna een A4 opsturen. Misschien niet zo spectaculair als met video bestanden maar het zelfde idee. Er komen natuurlijk ook heleboel problemen bij kijken. (revisies tabellen,standaardisatie en noem maar op).

[remark]Als ik een keertje tijd heb zal ik een applicatie proberen in elkaar te steken die dit realiseert. Lijkt mij geinig om te zien dat dit echt kan werken. Misschien dat ik het kan verkopen aan de mobiele telefoonfabrikanten heheh[/remark]

Het bovenstaande voorbeeld is eigenlijk een zwaar overdreven en simplistisch voorbeeld wat Sloot ook zogenaamd heeft gedaan voor video. Echter zoals duidelijk is de basis library en de afgeleide versies heel erg belangrijk. De vraag is kun je een library maken van 370 MB waarvan alle films kan worden gereproduceerd? Ik kan me voorstellen dat er best wel diverse patronen zullen zijn die je kunt opnemen in een library... echter is het de vraag of het wel in 370 MB kan en of je met die library alle films kunt reproduceren. Bij tekst weet je uiteindelijk natuurlijk wel alle woorden omdat dat de basis is van een taal is de definitie van woorden. Bij video is er natuurlijk geen vooraf gedefinieerde data. Theoretisch kan een punt (oftewel pixel) elk willekeurige waarde bevatten, echter kan mij voorstellen dat er in het praktijk heel veel patronen zijn die je kunt herkennen. Bijvoorbeeld dat als een pixel blauw is, dat de pixels erom heen ook een toon van blauw is oftewel dat beelden geen echte harde lijnen bevatten maar gradadaties zijn van kleuren die in elkaar overlopen en noem maar op.


Laten we kijken of de library van 370 MB haalbaar is. Ten eerste een normale PAL beeld bestaat uit 174.000 pixels. We splitsen het signaal uit in RGB. Stel dat we patronen zullen hebben van gemiddeld 10x10 pixels in grijswaarden. Voor 1 object in de library hebben we dus
10 x 10 x 1 byte = 100 bytes nodig. Omdat we uitgaan dat het gehele library 370 MB is hebben we grofweg (370 * 1000000) / 100 = 3.700.000 objecten vanuit gaande dat er geen samengestelde patronen zijn. Stel dat ook nog eens zou zijn. Dan zou er (volgens mijn intuÔtie) ongeveer 6 a 7 miljoen patronen zijn. Dit lijkt veel maar of je hiermee een volledige film kunt coderen naar een relatief zeer kleine key? Ik denk het niet. Want je moet in ieder geval in je key, de patronen opslaan die niet voorkomen in je library en geloof me die zullen er zeker zijn.


Al met al denk ben ik zelf ervan overtuigd dat je inderdaad door gebruik van een globale patronen database video (en foto bestanden kunt verkleinen. Echter de hoax zit hem in de 1 KB van de zgn. sleutelbestand waarin een volledige film mee gecodeerd wordt. Dat is gewoon onmogelijk omdat je in ieder geval 6 bytes nodig hebt voor 1 referentie naar een patroon (van het 7 miljoen). In 1 KB zitten dus 1024/6=170 patronen in. We gaan er nog eens uit dat de film volledig kan worden gereproduceerd uit de patronen in de library. Stel dat deze 170 patronen allemaal gecombineerde patronen zijn en dat ze uiteindelijk naar (zeer optimistisch geschat) naar 100.000 basis patronen verwijzen van 10x10. Uiteindelijk heb je dus 10x10x100.000 = 10.000.000 miljoen pixels. Een frame bevat 174.000 pixels oftewel je hebt 10 mln./174.000 = 57 beelden. Met 25 frames per seconde heb je eigenlijk 3 seconde film. Een lange film :). Het zou veel aannemelijker zijn als een film bijvoorbeeld 3 of 4 MB zou zijn ipv 1 KB. Want zoals ik uit de bovenstaande heb herleid, gaat in het meest optimale geval 3 sec in 1 KB. Dus 2 MB zou betekenen 2.000*3 sec = 6.000 sec is 100 minuten en plus 1 a 2 MB voor patronen gebaseerd op de library.


Daarnaast de redenering van "maakt niet uit hoe groot een film is" hij kan altijd worden opgeslagen in 1 KB slaat ook nergens op natuurlijk. Dus een film van 20 uur en een film van 1 minuut neemt dezelfde ruimte is beslag. Dit is zeer ongeloofwaardig. Het zou veel geloofwaardiger zijn geweest als er vermeld werd dat er per 1 uur film 1 KB werd opgeslagen. Een ander punt is waardoor het niet klopt is dat maar je alle films die ooit gemaakt zijn en gemaakt kunt worden met 1 KB kan beschrijven. Ik geef toe dat je met 2^8192 heel veel is, maar het gaat er bij mij niet in dat er tot nu
2^8192 = 1.1E2466 (dat is dus een nul met 2.466 nullen) films op de aarde bestaan. Doordat je 1 KB als sleutel hebt, wil dus zeggen dat je een limiet zet op het aantal films, tv-shows, home made movies plus alle variaties hierop van tot nu toe en de toekomst hebt gelimiteerd tot 1.1E2466. Ik ben van mening dan je hierop geen limiet kunt stellen en dat het het aantal film/video materiaal ongelimiteerd is.


Zoals elke compressie algoritme die met patronen werkt, zal ook sowieso het Sloot systeem falen met bijvoorbeeld willekeurige ruis, waar geen enkel patroon aanwezig is. Daarnaast heb ik mijn twijfels op een simpele tv reparateur de kennis heeft om een dergelijk algoritme te implementeren en zeker met de technologie van de jaren 90. Ook heb ik mijn twijfels of hij ooit een uniforme library met de basis patronen heeft kunnen creŽren, want om een dergelijk library te kunnen creŽren moet je weet ik veel hoeveel films analyseren en verwerken. Al met al is het dus een hoax.


Denk ik dat het niet kan? Ik zeg nooit nooit. Ik voorspel er dat er in de verre (of misschien met een beetje geluk in de nabije toekomst zeker algoritmes of methodieken komen om beeld materiaal op een zeer compacte manier op te slaan. Mijn mening is dat we eerst met kleine verbeteringen op de huidige methodieken inderdaad beeldmateriaal zullen gaan opslaan op steeds kleiner worden hardware. 20 jaar geleden van 1 GB veel, tegenwoordig lachen we erom. Deze ontwikkeling zal verder doorgaan totdat we een bepaalde limiet bereiken waarop wij niet meer verder kunnen en dan pas zal er met meer cpu power dit soort zaken bereikt worden en ondertussen zal ook een heleboel van de menselijke brein/lichaam ontdekt worden die we dan ook gaan gebruiken, want hoe je went of keert, al het rekenkracht van alle cpu’s in de wereld zijn niets vergeleken met de capaciteiten van 1 persoon zijn hersenen. Op het moment dat we dit mysterie ontrafelen denk ik dat er dan pas veel zal veranderen.





Facebook Twitter LinkedIn Translate Favorites More Services