Nieuwe start

[Webmaster]

From: Cugel

Zonde om de discussie die op gang is gezet te laten verzanden in onbruikbare ideëenuitwisselingen.
Ik heb wel het idee dat iedereen zo zijn eigen idee heeft over tot hoever compressie kan gaan en op
welke manier. Ik heb nog geen enkele programmeur horen praten bijv. in welke taal, uit de tijd van Sloot,
het het makkelijkst te programmeren is. Zoals jullie weten is de database opgebouwd uit een percentage
per pixel van R,G and B op een "oude" televisie....is daar iemand al eens mee bezig geweest ?

[Webmaster]

From: Supervalentino

Ik heb wel enige programmeerkennis, en kan zodoende compressie-programma's ontwikkelen. Echter, de vraag is welke methode nodig is. Het ontwikkelen van een programma is een tijdrovende zaak; en zonder aanknopingspunten iets maken is zinloos.

[Webmaster]

From: Supervalentino

Zoals jullie weten is de database opgebouwd uit een percentage
per pixel van R,G and B op een "oude" televisie....is daar iemand al eens mee bezig geweest ?

Op welke database doel je ?
Hoe zou jij dit principe inplementeren in een software-module ?

[Webmaster]

From: Cugel

Zoals jullie weten is de database opgebouwd uit een percentage
per pixel van R,G and B op een "oude" televisie....is daar iemand al eens mee bezig geweest ?

Op welke database doel je ?
Hoe zou jij dit principe inplementeren in een software-module ?

Een frame ( beeldje ) van bijv. 800 x 600 bestaat uit een fixed aantal pixels waarvan er elke
pixel weer bestaat uit een percentage R,G,B. Ooit is ergens gelezen dat een afwijking van 2%
niet te zien is per kleur, ergo je kunt 50 stappen per kleur nemen en dan heb je dus al een
matrix van 50 x 3. Bij een refreshrate van 75 Hz wordt die resolutie van 800 x 600 opgebouwd.
Dit houdt in dat binnen de rekentijd van 75 Hz met één frame er eigenlijk 800 x 600 frameseconden
zijn ( 480000 pixels ). Uitgaande dat pixel één linksboven is en pixel 480000 rechtsonder hoef je
dus alleen de frameseconden te matchen met een percentage uit de matrix. Wat er ontstaat is, achter
verschillende percentages van een kleur, een "sliert" van seconden van wanneer dit voorkomt.
De sequentie die onstaat per pixel qua verschijningsseconden is met name interessant om te compressen.
Die database blijft dus hetzelfde voor kleur maar ook voor geluid. De database voor geluid is ook fixed vanwege
het frequentiebereik van het gehoor. het opslaan van de toonhoogte per frameseconde gaat op dezelfde manier.
En die sliert moet dan ook weer gecompressed worden. Door de rekensnelheid hoor of zie je niet dat het digitaal is
maar heeft een analoog karakter.

Het is dus eigenlijk één database(je) voor alle frames waar een soort tijdworm doorheen gaat en alles meeneemt die
voor een bepaald moment moet verschijnen. Die sliert geef je een unieke code

Die sliert achter elke pixel en toon heeft een bepaalde totaalwaarde. vergelijk die met een priemgetal die net hoger ligt en geef daar alleen het verschil van aan. Tesamen met de database sla je ook het priemgetal op.

De keycode op de USB stick is de unieke code van de film gevolgd door de code van het verschil met dat priemgetal.

Kun jij dat uitschrijven ?

[Webmaster]

From: Troebelwater

Ik niet iig, maar komt voor de afwisseling wel lekker concreet over, respect

[Webmaster]

From: Supervalentino

Een dergelijk programma maken kost erg veel tijd, en ik weet niet zeker of dit een goede methode is.
SDCS werkte zoals Adobe PostScript; het was geen compressie, maar een andere manier van opslaan. Een voorbeeld :

Bij het maken van websites (in HTML) zijn kleuren natuurlijk belangrijk. Deze kan je echter ook in een zogenaamde Stylesheet zetten (*.css). Je geeft in de HTML-pagina bijvoorbeeld alle onderdelen die de kleur rood moeten hebben de waarde '1'. In de Stylesheet zet je vervolgens '1 = rood'.
Zo krijg je een HTML-pagina die als het ware een soort kleurplaat is met nummertjes, en een Stylesheet die deze pagina inkleurt. Als je vervolgens allebei de HTML-pagina op de computer hebt staan, hoef je alleen de Stylesheet te versturen om de hele pagina in te kleuren.

Het gaat hierbij dus niet om compressie, maar om een andere manier van opslaan en versturen. SDCS bestond echter uit 5 basisbestanden die alle films konden maken, iets wat met bovenstaand voorbeeld niet mogelijk is.

Daarnaast hoor ik veel mensen op dit forum praten over kleurverschillen en videocompressie. SDCS was toepasbaar op álle bestanden; naast video dus ook audio en andere bestanden. Het gaat dus niet om videocodering, maar om een andere manier van binaire codering.
Je komt dus niet verder met het denken in key-frames en delta-frames, ook het werken met fractals brengt je niet veel verder.

[Webmaster]

From: Cugel

Duidelijk!

Alleen denk ik dat er een stap overgeslagen wordt.

Als er achter één van de 150 uit de Matrix een string ontstaat wanneer deze voor komt heb je hieronder een voorbeeld van wat ik bedoel. Op framesec 1,5,25 en 25 komt deze waarde voor:
ergo 1000100000000000000000001001 zet dit om in een analoog getal en vergelijk dit getal met een hoger gelegen
priemgetal en daar geef je het verschil van weer. Zo ontstaat er achter elk van de 150 mogelijkheden 150 strings.
Hieruit vloeien 150 verschillende priemgetallen die je alleen een nummer hoeft te geven ( zo is 3 het tweede priemgetal en 7 het vierde etc. etc ).

En het leuke is als je van links naar rechts werkt in de database en je zet die 150 getallen ( verschillen tov. het hoger gelegen priemgetal ) achter elkaar....dan heb je nog maar één getal...en je raadt het al: die vergelijk je weer met een hoger gelegen priemgetal. Kleiner kan het niet.

De paradox van dit verhaal is dat het berust op het RNA principe vanuit DNA. een fixed database die door parameters
wordt "aangeslagen" en met bepaalde shifts bepaalde data een ander functie laat krijgen.

Think out of the box !

[Webmaster]

From: Troebelwater

Offtopic, maar toch:

Ben ik nu toch benieuwd of R. Pieper naar de politieke partij van PrdV gaat

[Webmaster]

From: Supervalentino

Ik ben het helemaal met je eens ! Het is zonde dat de discussie in feite dood is verklaard... Ik heb ook het idee dat wij nog de enige twee zijn die op dit forum komen !

In ieder geval hoop ik dat iemand nog een goddelijke ingeving heeft waardoor we verder kunnen brainstormen.

[Webmaster]

From: Ferris

En het leuke is als je van links naar rechts werkt in de database en je zet die 150 getallen ( verschillen tov. het hoger gelegen priemgetal ) achter elkaar....dan heb je nog maar één getal...en je raadt het al: die vergelijk je weer met een hoger gelegen priemgetal. Kleiner kan het niet.

Dacht even dat die priemgetallen zouden helpen bij het "oneindig" uitpakken van 1 "getal" in andere m.b.v. een 2e getal: het verschil en een matrix om de boel aan de gang te houden.
Er zijn echter een paar probleempjes die steeds weer terugkomen:
hoe haal je die getallen die je achter elkaar zet weer uit elkaar?
Ik mis iets ook met die priemgetallen: er is geen formule die het dichtsbijzijnde priemgetal voor je uitrekent, dus je zal een priemgetallentabel binnen een zekere range moeten meenemen.
Maar dan kan je toch elke willekeurige tabel met getallen die maar ver genoeg van elkaar af staan gebruiken om wat ruimte te winnen?
Volgens mij zie ik iets over het hoofd in je verhaal, het

magische

? Waar ligt die magie? De trigger die de waarden uit elkaar trekt.