|
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.
Posted by
Zero
at 9:14 PM
|
|
|