From: CugelOm bij de eerste twee getallen te beginnen
20 -> 3,9
87 -> 2,24
Wat doen we met 3,9 en 2,24... hoe slaan we die op?.... het zijn floating point getallen. Elke floating getal kost zeker 4 bytes... we kunnen het ook fix point opslaan maar kost het nog altijd 2 bytes per getal.
Dus voorlopig is de "compressie" -100%
Hoe verder?
Verder;
Met een film is het het makkelijkst als je begrijpt wat er precies opgelagen wordt per pixel op een bepaald tijdstip.
De drie primaire kleuren kun je in procenten weergeven tov. de verandering van de pixel. Je moet dus van elke scene
( als je de film in zeg 30 stukken knipt ) wel steeds het laatste plaatje in het RAM geheugen zetten om het eerste plaatje van de nieuwe scene uit te rekenen. Dit kost wel wat extra rekentijd maar geen opslag op de disc of USB stick.
Met geluid kun je dat per kanaal hetzelfde doen. Als je de sinus max. 1 laat zijn heb je altijd een straal die varieert vanaf het nulpunt en dus als het ware een op- en neerwaardse beweging maakt. Hier kies je gewoon wat gemiddeld het beste uitkomt, dus waarschijnlijk het verschil tov. 1 (eventueel kun je met een differentieel ook de oppervalktes uitrekenen en dat dus ook weer vergelijken met het dichstbijzijnde priemgetal. De priemgetallen set kan dus per kleur en geluidskanaal verschillen en wordt ook per scene opgegeven. In het rom/ram geheugen moet natuurlijk wel een priemgetallen generator zitten anders zou je alle priemgetallen op moeten slaan en zit je toch weer aan veel opslagcapaciteit ).
Theoretisch is dit naar mijn mening goed mogelijk. Jan heeft het nl. ook moeten doen met componenten die hij toen voorhanden had. Vanuit ons huidige standpunt was dat toen erg primitief en zo moet je het ook "terugdenken".
Het probleem zit hem echter in de heel grote getallen en de rekentijd die je hebt tov. de refreshrate.
Als de totaalsom van de eerste scene zeg 104723 ( teruggerekend naar binair naar decimaal ) is dan is het verschil maar 6 met het volgende priemgetal. Als je dan de piramide laat beginnen met bijv. 104701 dan geef je dit weer weer als 6,6. Dit kost je wel je floating point ruimte maar veel minder ruimte dan 104723 binair weergegeven.
Nog heel wat te doen dus.