broncode

[Henk Elegeert]

REPLY TO: D66 at nic.surfnet.nl

Martin Lentink wrote:

> REPLY TO: D66 at nic.surfnet.nl
>
> Henk Elegeert wrote:
> <...>
>
>> Maar daar draait het helemaal niet om. De unieke sleutel
>> wordt immers samengesteld aan de hand van werking van Jan's
>> vinding. Daarmee codeerd hij de film (matrix van 16x16
>> blokjes) en decodeerd hij de 'sleutel' tot het her-creeren
>> van de beelden op pixel niveau.
>
> Blokjes van wat? een matrix van 16*16 pixels?

Ja daarmee kwam Jan tot een andere manier en die hij nodig
had om het beeldscherm opnieuw op te bouwen.

... betreft een voorkeursuitvoringsvorm van de werkwijze het
oplsaan van een beeld. .... bij voorkeur wordt het beeld
verdeeld in blokken van 16 x 16 pixels.

> Of wordt de bestaande
> resolutie omgezet in een matrix van 16*16 van x pixels?

Kijk, we hebben het voortdurend over pixels gehad zonder die
nader te specificeren.

Maar pixel informnatie in het geheugen van je kaart voor het
verzonden wordt naar je CRT is iets anders dan ook alle
informatie daarover zelf met je mee te sjouwen in data.
Die kun je veel beter heel slim verminder door bij blokjes
van 16 bij 16 te kijken welke bit daarvan verandert en die
informaite op een andere manier te verwerken maar zo dat je
die weer kunt hergebruiken om opnieuw het beeldscherm
(pixel) aan te sturen.

> <...>
>
>> Nee een keer slechts, en daarna heb je weer binaire data om
>> de beelden weer te kunnen regenereren. Die kun je dus zo
>> copieeeren.
>
> En wat heb je daarvoor dan, volgens jou?

Begrijp ik je vraag ?

Oh ja, binaire maar van een andere oorsprong.

Vanuit een bestand namelijk, waarin tal van andere
informatie ligt opgeslagen, als frames, het aantal frames
per second etc ..,  kleur, intensteit, vector etc. etc.,
maar allemaal zoals we dat gewend zijn. Door alle lagen heen
van software devices tot aan de hardware toe.

Tot en met het moment waarop alles klaar ligt om te worden
door gezonden naar de CRT.

En daar 'plakt' Jan er een 'eigen laag' overheen in blokjes
van 16 bij 16 pixels en weet daardoor precies welke pixels
op je beeldscherm van status veranderen. Wat hield ie over?
40  bij 64 om het hele beeld weer op te kunnen bouwen, later?

Maar alleen de informatie die zich in de pixel wijzigd niet
de rest van de informatie. Vlgns mij noemt ie dat het
referentie geheugen.

  De resolutie doet er hier niet toe, want die informatie
ligt daar net onder (referentiegeheugen?). Jan kijkt slechts
wat er nu verandert (electronische informatie) in zijn laag
en slaat die informatie op in zijn 'database' maar met veel
minder ballast aan informatie. En precies dat wat nodig is
om het beeld later opnieuw op te bouwen, zoals bv. toekennen
van een volgnummer.

>> Plasterk blijft - zoals zovelen - uitgaan van de data die nu
>> in een bestand staat. Overigens bestanden waarmee je ook
>> kunt werken om er zeg maar beeld tussen uit te knippen. Dat
>> gaat bij de film van Jan een heel stuk lastiger worden, zo
>> niet onmogelijk.
>
> En waar staat die data, als 'ie nu niet in een bestand staat, dan nu
> wél?

Die verwerkt ie opnieuw om deze gecodeerd op te slaan in de
sleutel.

> Op een Ampex tape? Op celluloid?

Waar je normaal data in opslaat. Kan ook de harddisk zijn
overigens. Ik had het beeld even nodig om duidelijk te maken
dat ik na de coderering de PC met OS etc. niet echt meer
nodig heb. Ook gecomprimeerde bestanden zoals mpeg's etc
niet. Slechts nog de grafische kaart (al is dat ook niet
zeker) en de CRT. Enkel om aan te geven welke informatie Jan
zelf nodig heeft om de beelden te kunnen coderen en opnieuw
op te bouwen.

Dus alle compromeren/decomprimeren, verder, hoe de pc veel
ballast aan informatie meesjouwd door verschillende
processoren tot het moment van werkelijk verzending naar CRT
niet meer nodig. Plasterk's verkeerde (bestaande) data.

En met hem vele vele anderen.

 > En hoe 'codeert' hij die dan?

Dat doet hij middels die 'eigen laag' en met kennis van zijn
eigen vinding voor hoe straks die 'beelden' weer opnieuw op
te kunnen bouwen (met een minimum aan informatie) en de
informatie door te geven aan de CRT.

16 bij 16 pixels (40 bij 64 voor het totale beeld) meen ik.
Merk nu  op dat 'pixel' iets naders is dan de informatie die
in het geheugen van je grafische kaart staat, want daar
staat immers veel meer informatie in namelijk alle die nodig
is om de CRT aan te sturen. Die heeft Jan zelf niet nodig,
want te regenereren. Bovendien staat het beeldscherm dan al
aan en lgit die informatie er. Het gaat slecht om dat wat
zich wijzigd en dan ook in een andere format.

Allemaal voor de beeldvorming, de werking van Jan's systeem.
Het is goed mogelijk dat Jan zich slechts richt op
electronische informatie verwerking zelf, daar ben ik voor
mezelf nog niet uit. We zouden dan moeten weten hoe het er
precies uitziet de vinding van Jan. In elk geval moet ie
eerst zijn unieke sleutel op zien te bouwen uit bestaande
informatie.

>>> In wezen stelt Plasterk dat niet voorkomende
>>> beeldopties en letter en woordopties wel uniek gecodeerd
>> moeten kunnen worden,
>>
>> Maar Plasterk blijft ook uitgaan van de verkeerde data.
>> Blijft denken in termen van comprimeren van bestaande data.
>>
> Wat zou hij anders moeten doen?

Een andere Goeroe?  Hij lijkt Balkenende wel met zijn
verkeerde goeroe. ;)

In elk geval een poging moeten doen te begrijpen wat Jan z'n
vinding behelst, op zijn minst.

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