From: Drazic@MatrixView:
Thanx for the link, maar ik kende 'm al... datacompressie is een beetje een hobby van me...
Grappig hè, die eigenschap van (de PPM variant) BiCOM... je kunt ook een normale file zien als gecompresste file en daarmee gaan decompressen...
Precies! En als je de output daarvan nou ook weer eens zou zien als een gecompressede file, en dat
weer gaat uitpakken, en de output daarvan weer uitpakken, etc. dan kom je na 100x herhalen op een
heeeeeeel groot bestand uit... Volgens jou therorie kan ik dit bestand nooit in 1024 bytes kwijt. Volgens
de wet van Shannon of het pigeon hole effect ook niet. Maar als ik het kleine bestand waar ik mee
begonnen ben + het aantal herhalingen opsla, is dat misschien amper 1024 bytes, en daar kan ik dus
foutloos een bestand van een paar gig mee genereren. Het probleem is alleen hoe je dit process
omdraait zodat je zelf het bestand van 1 gig voor het kiezen hebt, en bruteforcend een weg zoekt
naar het meest optimale kleine bestand
Je zou ook bijv. een md5 hash van een groot databestand op kunnen slaan, vervolgens bruteforcen
(eventueel vanaf een meegegeven offset) tot je bij de goede md5+data uitkomt, en dan opslaan
hoeveel collisions (=zelfde md5 met andere brondata) je onderweg bent tegen gekomen tot de md5
en data kloppend zijn. De ontvanger hoeft nu alleen maar de md5 hash + collisionsaantal te ontvangen
en zou dan collisions kunnen gaan genereren totdat de collisioncount bereikt is, en voila data is weer
terug in orginele staat. Heb dit nooit uitgeprobeerd, en kost misschien wel veel cpu, maar is misschien
een ideetje? Er worden vrijwel geen collisions gevonden voor hashes als MD5 dus waarschijnlijk blijft
de collisioncount die je moet opslaan vrij laag altijd (misschien wel meestal 1 of 2)
Heeft één van jullie wel eens wat gelezen van over kleurenpercentages
en de maximale verhoudingen daarvan.
Ja... Sloot had het over 3D coderen ipv de gebruikelijke 2D. Mijn idee is dat hij over 3D
sprak omdat hij behalve de RGB waardes van een pixel ook de verandering in intensiteit
opsloeg oid (bedoel je dat met kleurenpercentages?)
Elektrisch gezien kom je dan op een wel heel erg interessante database uit...
Verklaar je nader...
Je geeft elke key ( pixel ) een tijdcode mee. En die tijdcode daar gaat het om op de
keycard. Het enige dat je uitrekend zijn die tijdcodes en dat loopt gewoon op net als van
1 t/m 10.000.000 tellen....en de scenes geef je ook weer in de database als een reeks van
een waarde. Jullie begrepen al dat juist die waarde een eitje is om weer te geven als priemgetal.
Ik snap het nut van je tijdcode nog niet echt... Normaal staan de frames toch zowiezo al gesorteerd
op tijd zou je zeggen... En je pixels dus ook...Enigste reden om een tijdcode op te gaan slaan (die
ik kan bedenken) is wanneer je sommige frames/pixels weglaat, en de film toch nog synchroon met
het orgineel wilt kunnen afspelen, of wil je alleen nog maar tijdcodes opslaan en niet de bijhorende kleuren?
Die tijdcodes kun iid heel efficient opslaan, maar je hoe kom je aan de database die je de goede kleur vertelt
voor elke tijdcode? Kortom, ik snap je plan nog niet helemaal, maar ben erg benieuwd naar wat je bedoeld
