broncode

[Henk Elegeert]

REPLY TO: D66 at nic.surfnet.nl

Fritz van Rikxoort wrote:

> REPLY TO: D66 at nic.surfnet.nl
>
> We praten echt langs elkaar heen, Martin,

Geen idee, maar het is lastige materie die zich niet
eenvoudig laat duiden. Hebben we het over beelden dan zijn
daarvan vele vormen bekend. Hebben we het over plaatjes,
pixels, data etc, idem dito. Voor velen onnavolgbaar.

Soms lees ik je Fritz en denk ik, 'nee hij snapt het niet',
wat ik bedoel. Later denk ik, 'hé toch". :) Zal andersom ook
zo zijn.

We spreken over verschillende op zichzelf technische
ingewikkelde materie en zoeken daarin naar de werking van
Sloot's systeem. Met alle mogelijk spraakverwarring vandien.

Als ik simpel zeg 'pixel', dan treedt dat probleem al op.

> Volsterkt onnodig want ik zie geeneens een gap tussen ons in globale kennis
> van reeds ontwikkelde technieken en theoretische en technische
> mogelijkheden, maar ik merk niet dat je serieus ingaat op waar het om ging,
> dat Plasterks bewijs van onmogelijkheden rammelt, niet serieus te nemen is,
> want wat is de zin van welke poging tot zinvolle efficiënte compressie en
> codering van welke willekeurige at random ruis dan ook...

Plasterk's bewijs is dat van een verdachte ...,iemand die op
basis van de huidige bekende technologie tot zo'n berekening
komt. Inclusief de veel te grote stromen aan data, waarmee
hij ergo; zelfs het bewijst ook nog eens denkt te leveren.

Dus exclusief de methode 'Sloot'. Sloot gaat uit van
technische informatie die naar het beeldscherm gaat. Sloot
'leest' die informatie uit die werkelijk naar het
beeldscherm gaat uit, en kijkt daarbij naar de verschillen
die optreden in blokjes van 16 bij 16 pixels en haalt daar
de slechts datgene uit wat zich wijzigt en verwerkt deze in
zijn systeem verder.

Niet voor niets die 16 bij 16 pixels, immers de register
grote (16 bits) uit die tijd. Daarmee beperkt hij data tot
enkel die, die er werkelijk toe doet.

Daarnaast (en nu leest ik Fritz beter, denk ik) gaat hij
daar mee bepalen waar die informatie heen gaat. 'Leest' als
het ware het patroon (de weg) uit dat die deze zal gaan
afleggen. Bijvoorbeeld de bewegende muiscursor van
rechtsboven in het beeldscherm naar linksonder.

Wordt door windowes nog steeds niet (h)erkent als veel
voorkomende handeling overigens, maar ik dwaal af. (OS-niveau)

Het gaat bovendien om de representant (de technische
beeldscherm informatie) en daarvan slechts datgene dat zich
wijzigt ofwel in kleur, in intensiteit, of in richting in
een 16 bij 16 matrices tot het hele beeldscherm.

EN DUS NIET: om alle data nodig voor het live uitvoeren en
zichtbaat maken van mijn handelingen, noch daar een bestand
van te maken dat dusdanig is samengesteld dat ik achteraf de
kleur van de cursor nog zou kunnen aanpassen, en die
gecomprimeerd wordt weg geschreven. (applicatie-niveau)

Sterker nog, hij kan die bepalen aan de hand van die (al
sterk gereduceerde) 16 bij 16 pixel-informatie (technische
info, maar slechts datgene wat in zijn matrix van status
wijzigt), kan deze immers 'lezen' en daaruit nieuwe data
genereren tot op het moment dat deze drastisch wijzigen.

Kan het dus bepalen aan de hand van de informatie die hij
uit zijn blokjes kan afleiden.

Zitten we op dezelfde golflengte om in die termen te blijven
Fritz?

> Ik stel vast dat de ontwikkeling van efficiënte compressie en codering
> inclusief reproductie van niet in gecodeerde patronen aangeleverde
> informatiestromen in volle gang is en vind het prima als wie dan ook wil
> bewijzen dat er grenzen zijn die we niet zullen kunnen overschrijden.
> Interessanter vind ik de vaststelling dat Sloot verder denkt dan
> bijvoorbeeld patroonherkenning binnen een stilstaand beeld óf zoals mpeg
> tussen opeenvolgende beeldjes in een film, wat goed werkt als het "beeld"
> (bijna) stilstaat in de tijd. Dat hij bij tekst en geluid en film patronen
> ook willekeurig door de dimensies ruimte en tijd wil herkennen en efficiënt
> wil coderen en reproduceren zie ik als een toevoeging aan de bestaande
> technieken en gedachten, inspirerend en zo vrijer denkend dan gebonden aan
> bestaande gebruiken openingen biedend tot toepassingen die verder gaan.

Absoluut, Fritz. Denk alleen al aan de reductie voor het
aanbieden van statische beelden aan informatie, vooral
'bewegende', die eigenlijk dan in 'animatie' op je
beeldscherm verschijnen. Opgebouwd uit minimale informatie
om de pixels via zijn systeem op jouw beeldscherm te
brengen. Voor interactiviteit minder geschikt lijkt me. Maar
wie weet gaan we daar straks ook wel weer anders mee om.

DMA betekent Direct Memory Access?
En is dat niet de naam van een techniek waarbij I/O devices
zonder directe tussenkomst van de CPU data van en naar het
werkgeheugen kunnen transporteren?

Ik fantaseer maar wat, maar met een aangepaste
DMAC(ontroller) kan die toch zelf bepalen waar de data in
het werkgeheugen geplaatst of opgehaald moet worden, een
mogelijk opdracht van de CPU daarover negerende?

DMA werkt toch ook voor het videogeheugen, niet?

(Martin?)

> Plasterk voegt aan de gedachten aan efficientere verwerking en opslag en
> reproductie met zijn ruisgenerator niets toe maar blaast wel hoog van de
> toren daarmee jegens ene Sloot en zijn octrooi en Pieper.

Dat beeld wordt mij ook steeds duidelijker, Fritz.

Geen innoveerder, als je het mij vraagt? ;)

Waaraan moet een formule, om zoiets aan te tonen, voldoen?
Want zo'n beetje iedereen lijkt op zoek te zijn naar het
'bewijs'.

Henk Elegeert

**********
Dit bericht is verzonden via de informele D66 discussielijst (D66 at nic.surfnet.nl).
Aanmelden: stuur een email naar LISTSERV at nic.surfnet.nl met in het tekstveld alleen: SUBSCRIBE D66 uwvoornaam uwachternaam
Afmelden: stuur een email naar LISTSERV at nic.surfnet.nl met in het tekstveld alleen: SIGNOFF D66
Het on-line archief is te vinden op: http://listserv.surfnet.nl/archives/d66.html
**********