broncode

Fritz van Rikxoort fritz at RIKXOORT.DEMON.NL
Wed Sep 29 22:21:16 CEST 2004


REPLY TO: D66 at nic.surfnet.nl

Ik voelde niet met jou maar met Martin dat we ergens langs elkaar heen
praten als hij de random ruis van Plasterks opeenvolgende letterdiarree
perfect gestructureerd noemt. Kennelijk praten we daar elk over iets anders.
Dezelfde diarree die Plasterk genereert met willekeurige achtereenvolgende
letterbeelden kun je ook met gewone geluiden en beelden doen, of het
hoorbaar geluid anders dan ruis oplevert of voor het oog zichtbaar beeld
waag ik te betwijfelen, dat kennen we toch als we een bitmap als
lettertekens lezen of de antenne van de radio of tv eruit gaat (al zetten
moderne radio's en tv's het geluid dan uit en het beeld dan egaal strak,
patroonherkenning van ruis... of herkenning dat er geen signaal anders dan
ruis is).

Het gaat bij Sloot om meer dan patroonherkenning van een los beeld of een
los woord, mpeg herkent ook patronen in in de tijd naastgelegen beelden,
Sloot wil herkennen dwars door alle dimensies van tijd en plaats heen, zelfs
in meerdere slagen als ik zijn coderingen van compressies van pakketjes van
gegevens en hun lokaties lees in zijn octrooi...

Hoe ver je daarmee theoretisch minimaal en maximaal kunt komen en met echte
zinnige taalteksten en mooie muziek of dialoog en harmonieuze
beeldovergangen van de films die we graag zien kunt komen lijkt me minder
interessant dan alle compressie- en patroonherkennings- en
coderingstechnieken vrij en herhaald gebruikt door alle dimensies heen te
ontwikkelen.

Mooie voorbeelden wanneer in extreme mate wel en niet elke techniek iets
oplevert kan iedereen bedenken, wel leuk om te doen. Ook is steeds goed en
leuk te beseffen hoe het verwerken van informatiestromen en het omgekeerd
genereren (of in omgekeerde volgorde gezegd) elkaars inverse zijn. begrijpen
we dat echte teksten en geluiden en beeldfilms als animaties in meer of
mindere mate patroonmatig gemaakt worden (we zetten geen ruisgeneratoren
aan) dan is andersom het herkennen van de patronen evengoed denkbaar.
Bij patroonherkenning van drukwerk zou zo je wilt onbedoelde ruis
(onregelmatigheden in de druk) verloren kunnen gaan, bij geluiden
achtergrondruis, bij opgenomen beelden onbedoelde bibbers en
lichtschommelingen. Maar in essentie zijn gemaakte teksten, muziek en
spraak, en mooi geschoten films complexe animaties. Bij film wordt bewust
voor achtergronden of decor gekozen, objecten bewegen, mensen en gezichten
zelfs binnen hun eigen afbeeldingsgrenzen. Patroonherkenning en hoe je eea
verder optimaal kunt bewerken is in wezen de inverse van animaties maken.

Sloot zal dus net als anderen met hun ontwikkelde technieken eenvoudiger
animaties makkelijker aankunnen en er zijn complexere technieken nodig om de
patronen van complexere animaties te herkennen. Wat ik met ruis zou moeten
waaraan Plasterk rekent weet ik nog steeds niet... Niets toch? Wegfilteren?

Fritz

----- Original Message -----
From: "Henk Elegeert" <hmje at home.nl>
To: <D66 at nic.surfnet.nl>
Sent: Wednesday, September 29, 2004 9:12 PM
Subject: Re: broncode


> 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
> **********
>

**********
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
**********



More information about the D66 mailing list