From: Nico
Het blijft een prachtig verhaal, helaas dat Jan sloot het niet meer kan vertellen.
Hier is mijn steentje in het hele proces. Als ik alles op een rijtje zet kom ik tot de volgende werkwijze die Jan naar mijn mening volgde.
Uit het octrooi kun je nagaan wat het principe is van het SDCS mechanisme, de meest simpele vergelijking die ik kan bedenken is die van Domino day. Wat Jan naar deed is het programmeren van een relationele database op pixel niveau. Het eindresultaat staat op een chipkaart en is eigenlijk de dominosteen die Domino day in gang zet. Nadat de eerste steen is gevallen volgen alle andere. Electronisch is dat natuurlijk veel sneller maar volgt wel hetzelfde principe. Conventionele opslag is gerelateerd aan tijd en zet alle informatie achter elkaar, wat jan deed is het tijdmechanisme er uit sleutelen en een beeld comprimeren naar 1 byte/word. Dat gaf de presentaties de snelheid, en de mogelijkheid 16 films tegelijk af te spelen.
Naar mijn mening was de hardware in het kastje niet al te ingewikkeld, video controllers, een flink geheugen en een processor zaten er wel in.
Jan gaf aan dat hij alle mogelijke waarden die een pixel kan aannemen in een geheugen zet. Omdat het tijdselement ontbreekt is alleen de structuur (pixel, blok, lijn, beeld) en de data van belang. Ik heb lang nagedacht hoe je dit doet, maar een relationele database lijkt het meest logisch. Volgens octrooi 1009908 komt een pixel binnen en wordt vergeleken met het basisgeheugen en krijgt het een nummer, bv 1, dat nummer komt in het basisgeheugen. Hetzelfde voor pixel 2,3 ...tot 256. Als tijdens het vergelijken van pixel 3 blijkt dat dit al benoemt is als pixel 1 sla je 1 op in het pixel geheugen i.p.v. 3. Dit geeft een getal dat je relateerd aan blok 1 en je gaat verder met blok 2...64. Dan kom je weer aan een getal en dat relateer je aan Lijn 1. Etc Bij lijn 40 heb je een getal voor beeld 1. Dan is beeld 1 gecodeerd, voor 90 min video moet je dit zo?n 135.000 keer doen. Video nummer 2 kun je er meteen achteraan coderen en begint met beeld 135.001. Op de chipkaart sla je dus op video 1 = beeld 1 tm 135000, video 2 = beeld 135001 ? 270001 etc. Het heen en weer spoellen van meerdere films is direct en wordt bepaald door de beeldnummers die je in de decoder zet.
Ik heb een klein stukje softwarematig nagemaakt en het werkt als een trein, in de database wereld is dit een linklist of Data Shunting.
Het probleem voor Jan was dat je films kunt coderen, beelden kunt terugbrengen tot één byte/word, maar dat je de matrix/relaties die de eigenlijke informatie bevatten in het geheugen moet hebben. Coderen en afspelen op 1 kastje geen probleem, maar coderen op 1 kastje, opslaan op chipcard en afspelen op ander kastje werkt niet, tenzij je het geheugen/matrix overzet. Dat is de kat in de zak waar the 5th Force mee zit.
Wat Jan bedacht is revolutionair, en veel beter als comprimeren.
Er zijn nog veel technieken om dit verder uit te werken, en dat is waar de Broncode in beeld komt, deze zal het matrix geheugen coderen en verkleinen. Je kunt het matrixgeheugen bv sorteren en patronen ontdekken. Of niet alle pixel informatie opslaan, maar een soort RISC-set en alle mogelijke combinaties van ?risc-pixels? wel opslaan waardoor je matrix generiek wordt en willekeurig elke film kan afspelen ( de matrix zit dan in de data verwerkt).