broncode

[Henk Elegeert]

REPLY TO: D66 at nic.surfnet.nl

Fritz van Rikxoort wrote:

> REPLY TO: D66 at nic.surfnet.nl
>
> Er lijkt sprake van onwil elkaar te begrijpen.

Ik doe overigens geen enkele poging de compressie te
begrijpen van Eric, Fritz. Wel de broncode....

Erik zorgt voor wat spraakverwarring waarna hij je graag
wijst op inconsistenties. Overigens altijd de zijne, maar
dat wil er nog niet erg in bij 'em. :)

> ...net als de weergave via
> pixels binnen marges fluctueert, maar a la...
>
> Wat Henk denk ik bedoelt is dat er meer mogelijk is dan "zuivere" compressie
> (zich herhalende patronen in ruimte en tijd niet elk opnieuw uitgebreid
> opslaan)

Dat lijkt de 'broncode' van Jan Sloot ook te behelzen. Voor
vover ik het zie richt hij zich slechts op de zich
veranderende pixels.

Vandaar zijn wat cryptische beschrijving dat alle films erin
besloten liggen.

> en zo bezien is het tegenbewijs waaraan Plasterk refereerde dat met
> zuivere compressie van willekeurige beeldjes (of andere uitngsvormen) geen
> bewijs dat slim vertalen (efficienter, versleutelen) van zich steeds weer
> herhalende patronen onmogelijk is.

Hij richt zich dus niet meer op de data, maar maakt data van
  zich wijzigende pixels. Dat vormt de gecodeerde bron voor
zijn 'film'.

> In de huidige beeldcompressie wordt zover ik weet nog slechts per beeld zich
> herhalende patronen in de willekeurige tweedimensionale beeldruimte
> gecomprimeerd (ja ook versleuteld), de theorie rond de broncode is dat met
> minder dan alle willekeurige theoretisch mogelijke beeldrepresentaties
> (opslag) en met "slim" gebruikmaken van herkenning van herhalingen ook in de
> tijd weergaven van samenhangende beelden gereproduceerd kunnen worden die
> niet merkbaar meer afwijken van andere weergaven met minder efficientere
> opslag- en reproductietechnieken.

De broncode nu (voor zover ik het zie en begrijp), Fritz
richt zich dus direct en specifiek op de pixels en de
mogelijke veranderingen die daarin op kunnen treden.

De rest kun je immers zo (re)generen (daarvan is immers
bekend wat het moet zijn. Zie de graphics drivers en
specifiek alle dat die nodig is het beeldscherm aan te
sturen) zonder hernieuwde invoer. Lees: geen data voor nodig
zelfs geen gecomprimeerde.

Slecht dat wat wijzigd wordt (pixels) is via een slimme
manier gedecodeerd opgeslagen. Terug uitgelezen kunnen die
zich wijzigde pixels geregenereerd worden waarbij de andere
(in het totale beeld) zonder invoer worden herhaald.

In het kort beschreven, zeg maar. Data (bron: wathever....)
wordt dus gecodeerd opgeslagen in de sleutel. Die wordt
uitgelezen en hoppa wijzigd slechts die pixels die gewijzigd
moeten worden (op een slimme manier) (vlak) voor ze naar het
beeldscherm gaan.

Hij maakt dus geen gebruik meer van nullen en ennen (data),
  maar van pixel wijzigingen, en ja dan weer wel van nullen
en enen, maar om het (beeld)scherm aan te sturen.

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