Niemand kan aantonen dat Jan Sloot's methode onmogelijk is.

[Webmaster]

From: Marko Nieuwenhuizen

J. J. Lodder schreef:

Marko Nieuwenhuizen schreef:
Zullen we de BV Perpmo oprichten, en de buit delen?

We doen het als volgt: met het patent van Jan Sloot
maak je informatie uit niets, dus gratis negatieve entropie.

En op negatieve entropie kan je een motortje laten lopen,
wat dus een perpmo van de tweede soort wordt.

Wie biedt voor een aandeel?

Lijkt me een goed plan. Dan maken we er gelijk [url down] van,
want die dotcoms hebben in het verleden bewezen veel geld te
genereren...

[Webmaster]

From: Femme Verbeek

Werther schreef:
Dus dan zou het mogelijk kunnen zijn.

Zet een TV met Dvd-speler 200 jaar terug en men zal hun ogen niet geloven.
De plaatselijke wiskundige zal zeggen dat dit niet kan.
Menig toeschouwer zal zeggen "that's it!"

T'is me eindelijk gelukt om het originele patent te pakken te krijgen.

Ik kan nu dus wel aantonen dat zijn methode niet werkt.

Het spijt me te moeten zeggen dat Sloot een broddelaar is die geen
donder heeft begrepen van informatie technologie.
Hij heeft een soort indexeringssysteem bedacht om beeld op te slaan.
Het komt er op neer dat hij van plan is om alle mogelijke combinaties
pixel patronen van te voren op te slaan op een drager.

Het gaat bij de eerste stap direct al mis.
Allereerst wil hij alle mogelijk kleur combinaties die een pixel kan
aannemen indexeren.
Dat is een zinloze bezigheid, want om de index op te slaan heb je
minimaal net zoveel bytes nodig als waardoor de oorspronkelijke pixel
beschreven was.
Vervolgens deelt hij het beeld in vlakjes van 16x16 pixels. Alle
mogelijke combinaties indexeert hij opnieuw en slaat hij op in
geheugens.
Daar gaat het nog veel erger mis. Want reken maar eens uit hoeveel
mogelijke combinaties er bestaan.
16x16 pixels met r g en b elk van 256 mogelijke waarden = 2^
(16x16x256x256x256) = 2^4294967296
Ik denk dat hij hier de plank misslaat door te denken dat er maar
4294967296 mogelijkheden bestonden terwijl het ruwweg een getal van 1.5
miljard cijfers is. Dit is meer geheugencapaciteit dan er op de hele
aarde op alle computers bij elkaar aanwezig is.
Bovendien is het zinloos om deze combinatiewaarden van te voren op te
slaan, je kunt ze beter parametrisch berekenen uit het index getal. En
hoera daar komt de informatie technologie ons weer te hulp, waaruit
blijkt dat het aantal benodigde bytes om het index getal op te slaan
precies even groot is als het oorspronkelijk aantal benodigde bytes met
informatie waarde.

De rest hoef ik niet te vertellen. Hij indexeert naar kolommen van 40
blokken en daarna naar frames van 64 kolommen etc, waarbij hij zich niet
afvraagt hoeveel informatie er in dat index getal moet worden
opgeslagen.

Je zou er natuurlijk ook voor kunnen kiezen om alleen de informatie van
de frames uit de film op te slaan, maar dan komt het er op neer dat je
inderdaad de volledige film van te voren op de harde schijf zet. Hij
hoopt natuurlijk dat er overeenkomst is in de blokken, maar die kans is
klein gezien het grote aantal mogelijke blokken. Het index getal wordt
er dus niet kleiner van. De harde schijf wordt veel zwaarder belast want
hij moet informatie voor een beeld van heel ver gaan halen. Bovendien
komt het er dan op neer dat je film gaat afspelen als frame 1(kolom 1
(blok 1 ...blok40) .....kolom 64( )) ....frame N( ).
Daar heb ik geen index sleutel voor nodig, dat had ik je zo wel kunnen
zeggen.


Kortom broddelwerk.

[Webmaster]

From: Femme Verbeek

Overigens schijnt Sloot zelf - in tegenstelling tot de media - nooit
te hebben beweerd dat hij videomateriaal met een factor 2 miljoen kon
comprimeren. Sloot diende op 20 augustus 1998, een klein jaar voor
zijn dood, een octrooiaanvrage in. De beschrijving hiervan kun je
opzoeken en nalezen op [..] onder nummer
NL1009908. In de beschrijving claimt Sloot zelf een compressie van ca.
1 op 8. Ten tijde van zijn dood was de octrooiaanvrage nog in
behandeling. Het is onwaarschijnlijk dat Sloot in de ruim 10 maanden
die hem nog restten een belangrijke doorbraak heeft bereikt, want in
dat geval zou hij zijn nog lopende octrooiaanvrage toch wel hebben
aangepast of anders een nieuwe c.q. aanvullende aanvrage hebben
ingediend, en dat heeft hij niet gedaan.

Een nederlands octrooi wordt per definitie verleend.
Ik zie dat hij de stap naar internationalisering via PCT al gemaakt
heeft.
Er ontbreekt echter een antwoord op het nieuwheidsonderzoek.
Hij zal op het moment van zijn dood ongeveer aan de nationale fase
aanvraag per land zijn toegeweest.
Als je dan niet een paar euro tonnen achter de hand hebt red je het
niet.

Ik heb het sterke vermoeden dat die zg enorme geclaimde compressie
voortkomt uit een verkeerd begrip door de media en dat Sloot dat nooit
beweerd heeft. Tegelijk kan ik ook argumenten verzinnen in de vorm van
herkenning van objecten die wel in heel weinig bytes is op te slaan
die wellicht voortvloeit uit zijn methode. En dat daar weldegelijk
interessant aspecten aan zitten.

Uit eigen ervaring weet ik dat patenten en uitvindingen soms tot media
hypes kunnen leiden, en je wilt niet weten wat voor onzin er dan
allemaal beweert wordt.

Inmiddels de patent text gelezen.

Hahahahahahahahahahahahahahahaha..

Zie mijn rechtstreeks commentaar op de OP

[Webmaster]

From: Maarten D. de Jong

Femme Verbeek schreef:
Kortom broddelwerk.

Complimenten voor je speurwerk en natuurlijk absoluut de juiste conclusie.
Naar mijn idee is een nog veel ernstiger conclusie dat het patentbureau niet
over de hersenen beschikte om *meteen* in te zien dat deze methode niet werkt.
Nu is er een patent op onzin toegekend, wordt er in de samenzweerderscircuits
heftig gediscussieerd over de methode-Sloot en wordt er door het journaille
dat er *ook* geen moer van begrijpt uitgebreid aandacht aan besteed, op kosten
van de belastingbetaler.

Het valt me trouwens vies tegen van 'prof.' Pieper, nota bene afgestudeerd in
de informatietechnologie, dat hij deze onzin ondersteunde.

Maarten

[Webmaster]

From: J. J. Lodder

Jeroen Makkinje schreef:

J. J. Lodder schreef:
Nu kom je wel op een probleem waar ik mee zit. Stel je
hebt een geheugen module van 1 GB. Je wilt deze vullen
met een unieke serie van gegevens. Weet je dan van te
voren hoeveel vrije energie dit minimaal gaat kosten?

(De specificaties van de module zijn uiteraard onbekend)

Practisch gezien zou ik zeggen dat er op zijn minst
een energiebarriere moet overwinnen tussen 0 en 1
(door thermische fluctuaties zullen die de neiging
hebben in elkaar over te lopen), aan de andere kant
zou die energie weer kunnen terugwinnen. Ik heb het
gevoel dat er iets fundamentelers moet zijn.

Nee hoor, dat is het.
Je hebt minimaal kT per bit nodig,

Jan

[Webmaster]

From: Bert \( A W RvB \)

Maarten D. de Jong schreef:

Femme Verbeek schreef:
Kortom broddelwerk.

Complimenten voor je speurwerk en natuurlijk absoluut de juiste conclusie.
Naar mijn idee is een nog veel ernstiger conclusie dat het patentbureau
niet over de hersenen beschikte om *meteen* in te zien dat deze methode niet
werkt.
Nu is er een patent op onzin toegekend, wordt er in de samenzweerderscircuits
heftig gediscussieerd over de methode-Sloot en wordt er door het journaille
dat er *ook* geen moer van begrijpt uitgebreid aandacht aan besteed, op kosten
van de belastingbetaler.

Het valt me trouwens vies tegen van 'prof.' Pieper, nota bene afgestudeerd
in de informatietechnologie, dat hij deze onzin ondersteunde.

Maarten

Er is nog een methode en dat is met bitten.

Kijk voor elke bit op dezelfde plaats van de punten ( bit n dus ) in een
beeld of die aan of uit staat. Staan er zoveel bitten aan van alle punten op
het scherm dat het interessant is om ze allemaal aan te verklaren doe dat
dan en vermeld apart de punten waarbij ze uit staan. Dat kan ook anders om
voor de bitten die uit staan.

Krijg je dit:

Bit 00 : uit, aan: n1, n2, enz
Bit 01: aan, uit: n1, n2, enz.
........................
Bit 31: ............

Als er clusters zijn in een beeld dan kan je die cluster apart benoemen.

Als je al die mogelijkheden gebruikt dan kan het wel wat worden.

Of dit er ook nog bij:

CLS

Line(x1,y1)-(x2,y2),kleur

Haal er nog maar wat programma's bij

Bert RvB.

[Webmaster]

From: Sander Nijdam

Bert \( A W RvB \) schreef:
[..]
Als je al die mogelijkheden gebruikt dan kan het wel wat worden.
Of dit er ook nog bij:

CLS

Line(x1,y1)-(x2,y2),kleur

Haal er nog maar wat programma's bij

Zo kan je inderdaad de Simpsons of Pokemon prima comprimeren. Een
echte film wordt echter een stuk moeilijker (lees: minder
compressie mogelijk).

Sander...

[Webmaster]

From: Dik T. Winter

Maarten D. de Jong schreef:

Femme Verbeek schreef:
Kortom broddelwerk.

Complimenten voor je speurwerk en natuurlijk absoluut de juiste conclusie.
Naar mijn idee is een nog veel ernstiger conclusie dat het patentbureau niet
over de hersenen beschikte om *meteen* in te zien dat deze methode niet
werkt.

Het patentbureau is er niet voor om uit te zoeken of een patent werkt. Het
moet gewoon een aangevraagd patent dat er redelijk uitziet toekennen.

Nu is er een patent op onzin toegekend,

Er worden zoveel patenten op onzin toegekend.

wordt er in de samenzweerderscircuits
heftig gediscussieerd over de methode-Sloot en wordt er door het journaille
dat er *ook* geen moer van begrijpt uitgebreid aandacht aan besteed, op
kosten van de belastingbetaler.

Hoezo op kosten van de belastingbetaler? Ik denk trouwens dat het de
belastingbetaler veel meer geld zou kosten als het patentbureau eerst
moest onderzoeken of iets werkt. En daarna nog de rechtzaken van de
aanvragers die vinden dat hun aanvragen onterecht zijn afgewezen.

[Webmaster]

From: Dik T. Winter

Femme Verbeek schreef:
....
Het gaat bij de eerste stap direct al mis.
Allereerst wil hij alle mogelijk kleur combinaties die een pixel kan
aannemen indexeren.
Dat is een zinloze bezigheid, want om de index op te slaan heb je
minimaal net zoveel bytes nodig als waardoor de oorspronkelijke pixel
beschreven was.

Tsja, die viel mij ook al op, daarom heb ik hem in mijn beschrijving
maar weggelaten. Maar je opmerking is niet helemaal waar. Het is niet
nodig dat alle te beschrijven kleuren ook werkelijk voorkomen.

Vervolgens deelt hij het beeld in vlakjes van 16x16 pixels. Alle
mogelijke combinaties indexeert hij opnieuw en slaat hij op in
geheugens.
Daar gaat het nog veel erger mis. Want reken maar eens uit hoeveel
mogelijke combinaties er bestaan.

Voorzover ik het gelezen heb was het niet de bedoeling om alle mogelijke
combinaties op te slaan, maar alleen die combinaties die voor een
bepaalde film nodig zijn (de coderingsfase). En dan valt hier wellicht
enige winst te behalen.

De rest hoef ik niet te vertellen. Hij indexeert naar kolommen van 40
blokken en daarna naar frames van 64 kolommen etc, waarbij hij zich niet
afvraagt hoeveel informatie er in dat index getal moet worden
opgeslagen.

Ik meende gelezen te hebben dat hij het over 60 kolommen had. In ieder geval
kan hij niet rekenen. 976 pixels zijn toch echt 61 kolommen... Uit deze
stappen is echter niet of nauwelijks winst te behalen, ik vermoed zelfs
dat ze verlies zullen opleveren.

Je zou er natuurlijk ook voor kunnen kiezen om alleen de informatie van
de frames uit de film op te slaan, maar dan komt het er op neer dat je
inderdaad de volledige film van te voren op de harde schijf zet.

En dat was denk ik precies de bedoeling.

Hij hoopt natuurlijk dat er overeenkomst is in de blokken, maar die kans is
klein gezien het grote aantal mogelijke blokken.

Voor tekenfilms is die kans behoorlijk wat groter dan voor speelfilms.
Niet dat het echt veel zal opleveren...

Bovendien
komt het er dan op neer dat je film gaat afspelen als frame 1(kolom 1
(blok 1 ...blok40) .....kolom 64( )) ....frame N( ).

Ik denk dat het meer iets wordt van frame 1 t/m 2440, frame 1, frame 2441,
frame 3, enz.

Daar heb ik geen index sleutel voor nodig, dat had ik je zo wel kunnen
zeggen.

En daar heb je wel een sleutel voor nodig.

Maar het is inderdaad verbazend wat dat soort technieken kunnen doen met
een beeld met een statische achtergrond, en ik denk dat Sloot zich daarop
heeft vastgepind. Ik heb ergens een animated gif van een spel op 576 x
576 pixels. Ieder frame is zo'n 32 kB. De animated gif van 1311 frames
is slechts 1,6 MB. Een compressie met een factor 26 ofzo. Wellicht
moeten de ontwerpers daarvan patent aanvragen.

Of wat te denken van een animated gif van 5348 frames van 560 x 360
tweekleuren? Direct rekenen levert 134.769.600 bytes op. Het resultaat
is slechts 2.920.945 bytes. Compressiefactor: 46.

Buiten dit soort toepassingen is de methode echter waardeloos, en bestaande
methoden werken voor dit soort toepassingen al veel beter.

Het aardige is dat ik ergens een spel heeft dat in 256 kleuren gespeeld
wil worden. Echter, het aantal kleuren dat het spel daadwerkelijk
gebruikt ligt belangrijk hoger. Regelmatig wordt dan ook het kleuren-
palet veranderd, en dat merkte ik toen mijn videokaart het begon te
begeven en die overgangen van kleurpalet niet meer goed verwerkte. (Ja,
ik heb nu een verse videokaart in mijn systeem.)

[Webmaster]

From: Femme Verbeek

Dik T. Winter schreef:

Femme Verbeek schreef:
...
Het gaat bij de eerste stap direct al mis.
Allereerst wil hij alle mogelijk kleur combinaties die een pixel
kan aannemen indexeren.
Dat is een zinloze bezigheid, want om de index op te slaan heb je
minimaal net zoveel bytes nodig als waardoor de oorspronkelijke
pixel beschreven was.

Tsja, die viel mij ook al op, daarom heb ik hem in mijn beschrijving
maar weggelaten. Maar je opmerking is niet helemaal waar. Het is
niet nodig dat alle te beschrijven kleuren ook werkelijk voorkomen.

Tuurlijk je kunt ervoor kiezen om de kleurinformatie in minder bits op
te slaan, maar dan krijg je dus kwaliteits verlies.
Overigens doet .AVI al iets dergelijks. Vergelijk het maar met de
geindexeerde kleur van .GIF
Sloot heeft het over exacte replicatie dus dan kun je geen informatie
weglaten.

Vervolgens deelt hij het beeld in vlakjes van 16x16 pixels. Alle
mogelijke combinaties indexeert hij opnieuw en slaat hij op in
geheugens.
Daar gaat het nog veel erger mis. Want reken maar eens uit hoeveel
mogelijke combinaties er bestaan.

Voorzover ik het gelezen heb was het niet de bedoeling om alle
mogelijke combinaties op te slaan, maar alleen die combinaties die voor een
bepaalde film nodig zijn (de coderingsfase). En dan valt hier wellicht
enige winst te behalen.

pag 2 regel 13,14

Een referentie geheugen waarin alle mogelijke waarden van elk van de
gegevens is opgeslagen.

De rest hoef ik niet te vertellen. Hij indexeert naar kolommen van 40
blokken en daarna naar frames van 64 kolommen etc, waarbij hij zich
niet afvraagt hoeveel informatie er in dat index getal moet worden
opgeslagen.

Ik meende gelezen te hebben dat hij het over 60 kolommen had. In
ieder geval kan hij niet rekenen. 976 pixels zijn toch echt 61 kolommen... Uit
deze stappen is echter niet of nauwelijks winst te behalen, ik vermoed
zelfs dat ze verlies zullen opleveren.

Pagina 3 onderste regel staat 64 x 40 blokken, maar je hebt gelijk hij
kan niet rekenen

Je zou er natuurlijk ook voor kunnen kiezen om alleen de informatie van
de frames uit de film op te slaan, maar dan komt het er op neer dat je
inderdaad de volledige film van te voren op de harde schijf zet.

En dat was denk ik precies de bedoeling.

Dan zou je veel simpeler met een encriptie algoritme kunnen werken,
zonder al die index poespas.

Hij hoopt natuurlijk dat er overeenkomst is in de blokken, maar die
kans is klein gezien het grote aantal mogelijke blokken.

Voor tekenfilms is die kans behoorlijk wat groter dan voor speelfilms.
Niet dat het echt veel zal opleveren...

Voor dat soort films biedt AVI al een uitstekende oplossing. Vergelijk
het maar met .gif voor getekende plaatjes.

Bovendien komt het er dan op neer dat je film gaat afspelen als frame 1(kolom 1
(blok 1 ...blok40) .....kolom 64( )) ....frame N( ).

Ik denk dat het meer iets wordt van frame 1 t/m 2440, frame 1, frame 2441,
frame 3, enz.

De informatie die in elke kolom wordt opgeslagen zal toch echt altijd
moeten bestaan uit 40 van die vreselijk grote indexgetallen,
onafhankelijk of er nou overeenkomst is tussen de blokken of niet.
Hetzelfde geldt voor de frames. De kans dat er overeenkomstige kolommen
zijn is nog veel kleiner, dus worden de kolommen gewoon doorgenummerd.

Daar heb ik geen index sleutel voor nodig, dat had ik je zo wel kunnen
zeggen.

En daar heb je wel een sleutel voor nodig.

Maar het is inderdaad verbazend wat dat soort technieken kunnen doen met
een beeld met een statische achtergrond, en ik denk dat Sloot zich daarop
heeft vastgepind. Ik heb ergens een animated gif van een spel op 576 x
576 pixels. Ieder frame is zo'n 32 kB. De animated gif van 1311
frames is slechts 1,6 MB. Een compressie met een factor 26 ofzo. Wellicht
moeten de ontwerpers daarvan patent aanvragen.

Laat ie er nou eens een factor tien mee winnen. Dan wordt dat
afschuwlijke 4294967296 bits index getal voor elk 16x16 blok een paar
bitjes korter. Daar zit geen winst in.
Er zijn trouwens al voldoende schandalige praktijken rond het .GIF
patent. Maar dat mag je zelf op zoeken.

Of wat te denken van een animated gif van 5348 frames van 560 x 360
tweekleuren? Direct rekenen levert 134.769.600 bytes op. Het resultaat
is slechts 2.920.945 bytes. Compressiefactor: 46.

..gif kijkt naar het voorkomen van reeksen van dezelfde waarde. Dus als
er 100 pixels met dezelfde kleurwaarde naast elkaar staan wordt dat
opgeslagen als 100x kleurwaarde. Animated kijkt als het goed is ook nog
eens naar wat er verandert in het beeld.
Er zijn vele .gif optimisers op het web te vinden. Daar kun je mogelijk
nog een heel eind verder mee komen.