Mijn broncode

[Webmaster]

From: MatrixView

Hi again,

Dat valt wel mee... Als je de data in blokken van een bepaalde grootte verdeeld, bijvoorbeeld 500 tekens, dan kunnen collisions alleen binnen een relatief kleine range optreden. Bovendien hebben de collisions een heel handige eigenschap die misschien uitgebuit kan worden: de spreiding over de range is heel erg regelmatig...!
Als je weer van bijv. 500 tekens uitgaat, dan zou je alle mogelijke hashes van data van 500 tekens in
een (hardwarematige?) lookup table kunnen plaatsen, bovendien kost een hash over kleinere blokken
berekenen veel sneller dan voor "een file met een beetje grootte"....

Hoe groter de md5 file, hoe kleiner het aantal collisions en andersom...

Bedankt voor het rekenwerk! Waarschijnlijk heb je wel gelijk, maar ik was maar een beetje aant brainstormen
in dit topic Het enigste wat ik er op aan wil merken is dat een MD5 die 50% van de orginele data in beslag
neemt zeer zeldzaam is Gaat vrijwel altijd om minder dan een procent en toch zijn er tot op heden nauwelijks
collisions gevonden.. Hoe verklaar je dat? :-p Bovendien is de bloklengte van mijn ideetje fixed, wat de kans op
collisions aanmerkelijk verminderd.. Laten we blijven zoeken

Geen dank. De 50% was een voorbeeld om te laten zien hoevel collisions er kunnen optreden bij zelfs een relatief zeer grote md5 file. ... de collisions bij een relatief kleine md5 file zijn nog veel groter!!!

Ik denk dat je je nog steeds verkijkt hierop.... Welke methode je ook gebruikt om data lossless te verkleinen (Hetzij de md5 methode, hetzij de primenumber, hetzij welke bekende of nog onbekende compressie methode dan ook) Het is ONMOGELIJK om IEDERE file van N bits, lossless te verkleinen tot N-1 bits. (=pigeonhole)

Zoals ik al zei kom je in het dageliijks leven bij bestaande files niet veel collisions tegen. Omdat zelfs ALLE bestaande files op de wereld maar een te verwaarlozen percentage is van alle MOGELIJKE (bestaande EN (nog) onbestaande) files. Dus ook de collisions die men tegenkomt zijn maar een te verwaarlozen percentage van het aantal mogelijke collisions.

Kortom, tenzij je alle bestaande files in kaart brengt met hun md5('s) EN iedereen verbiedt om nog nieuwe files aan te maken (da's lastig hoor! ), zal jouw md5 compressie methode helaas niet gaan werken...

Ik wil best met je meedenken hoor, maar zolang je nog geloofd/hoopt dat er een methode bestaat die iedere file lossless kan verkleinen heeft 't weinig zin. Vaak duurt 't even voor dat iemand wil geloven dat 't echt niet kan...
I've been there...

Lossy EN / OF een beperkte dataset, is een totaal ander verhaal (dat is WEL mogelijk).

[Webmaster]

From: MatrixView

Een kleurendatabase kun je percentueel verdelen in stapjes van 1% per kleur.
Per kleur dus maar 100 plaatsen, lagere percentages zie je niet!
Per pixel ( oplopend per 1/seconde afhankelijk van de refreshrate ) heb je dus altijd
een bepaalde waarde die wordt ingelezen tijdens het filmen.

@Cugel

Dat is al een stuk duidelijker (hou vast!), hoewel ik nog niet helemaal kan overzien hoe inventief of bruikbaar dit is voor -iedere- soort data. Het klinkt wel erg "lossy" die procentuele kleurverdeling, vandaar dat 't ook mijn aandacht trekt. Bovendien, een Quantizer is ook een "verdeler" Maar goed, 100x100x100 = 1 miljoen mogelijke kleuren... da's veel, maar genoeg?

Wat gebeurt er met je data als je als origineel ruis treft ipv een zeer correlerend video beeld? Al eens geprobeerd?

Hoeveel en welk rekenwerk heeft je methode nodig? Waar liggen de moeilijkheden en wat denk je eraan te doen?

[Webmaster]

From: Drazic


@Matrix

Dank voor de verheldering

En wat betreft Cugel's idee:
Het hoeft helemaal niet voor alle data te werken..! Als dit zou kloppen wat hij zegt is het al revolutonair genoeg denk ik, ken verder ook geen andere videocompressie die zo werkt!! Jij wel?

@Cugel
Ben heel benieuwd naar die Excel sheets... Want vooral die pyramide vorm zou heel goed te compressen zijn!! Ik heb nu geblowed, maar zal morgen nog eens rustig (en nuchter) je verhaal nalezen, en misschien dat ik er dan meer op aan te merken heb, maar tot nu toe wil ik niets liever dan meehelpen aan je research!!! Heb zo'n voorgevoel dat we op de goede weg zitten Sloot zou trots op je zijn

[Webmaster]

From: MatrixView

En wat betreft Cugel's idee: Het hoeft helemaal niet voor alle data te werken..! Als dit zou kloppen wat hij zegt is het al revolutonair genoeg denk ik, ken verder ook geen andere videocompressie die zo werkt!! Jij wel?

True, het hoeft niet persé voor alle data te werken. De meeste bestaande codecs zijn gericht op een bepaald type data. (bv mp3, xvid en de betere aanstormende AAC en AVC). Of het revolutionair is kan ik nu nog niet beoordelen. Ook niet of het uberhaupt werkt... Erg positief ben ik dus (nog) niet.

@Cugel
Ben heel benieuwd naar die Excel sheets... Want vooral die pyramide vorm zou heel goed te compressen zijn!! Ik heb nu geblowed, maar zal morgen nog eens rustig (en nuchter) je verhaal nalezen, en misschien dat ik er dan meer op aan te merken heb, maar tot nu toe wil ik niets liever dan meehelpen aan je research!!! Heb zo'n voorgevoel dat we op de goede weg zitten Sloot zou trots op je zijn

Ok, snel ff een "grouphug" dan! Geintje.... Nee, sorry ik weet echt niet of Cugel hier op de "goede weg" zit. Maar dat komt misschien omdat ik nooit een blowtje rook...

Ben alleen geintrigeerd omdat de methode "lossy" lijkt te zijn, maar tegelijk verwacht ik ook nogal wat problemen die ervoor zorgen dat de methode wellicht helemaal niet werkt. Ben bv erg benieuwd hoe Cugel de methode generic denkt te gaan maken...

Het is al een stukje duidelijker waar ie heen wil, maar zolang ik nog niet alles begrijp, kan ik hem niet helpen.

FF afw88 dus, voordat we conclusies trekken...

[Webmaster]

From: Drazic

FF afw88 dus, voordat we conclusies trekken...

Ben al de hele dag aant afw88 Hoop niet Cugel plots een hartaanval heeft gekregen...

[Webmaster]

From: Cugel

Een hartaanval...nee ik niet hoor. En blowen doe ik ook niet. Een mindfuck kun je ook krijgen
als je het boek der iluminanten leest en is waarschijnlijk goedkoper en gezonder!

Nu over het rekenwerk. Staan jullie wel eens stil dat deze methode van Jan heel veel lijkt op het Seti
project ? Er wordt geprobeerd om allerlei signalen te doorgronden of ze een bepaalde betekenis hebben.
Er wordt vanuit gegaan dat deze signalen een bepaalde logica moeten bezitten om intelligentie te herkennen
over en weer. Met Jans' methode kun je als het ware slechts één ping geven en alle data over geseind hebben
zonder dat de ontvanger doorheeft dat dat een bepaalde waarde heeft als je geen afspraak had gemaakt met de
"overkant".

Maw. het rekenwerk begint pas echt als het Ram geheugen vol zit en er een soort voorlooptijd met beeld ontstaat.
Het opgebouwde beeld moet dus altijd binnen de refreshtijd berekend zijn.
Kennen jullie de programmeertaal FUP of AWL nog uit de oudheid ? Zoek het eens op en vraag je dan eens af waarom
Windows bestaat en waarom alles nog zo traag is. Het antwoord om oneindig snel en oneidig klein te gaan is er al ( lang)....maar in één keer geïntroduceerd staat de hele economie die om IT is opgebouwd op zijn kop en stort de geldwereld in één keer in elkaar. De taart is al lang gebakken en elke dag wordt er een stukje van gegeten.
Helaas kan ik niet meer vertellen want dan gooi ik mijn eigen glas in.

100495

[Webmaster]

From: MatrixView

Een hartaanval...nee ik niet hoor. En blowen doe ik ook niet. Een mindfuck kun je ook krijgen
als je het boek der iluminanten leest en is waarschijnlijk goedkoper en gezonder!

Nu over het rekenwerk. Staan jullie wel eens stil dat deze methode van Jan heel veel lijkt op het Seti
project ? Er wordt geprobeerd om allerlei signalen te doorgronden of ze een bepaalde betekenis hebben.
Er wordt vanuit gegaan dat deze signalen een bepaalde logica moeten bezitten om intelligentie te herkennen
over en weer. Met Jans' methode kun je als het ware slechts één ping geven en alle data over geseind hebben
zonder dat de ontvanger doorheeft dat dat een bepaalde waarde heeft als je geen afspraak had gemaakt met de
"overkant".

Maw. het rekenwerk begint pas echt als het Ram geheugen vol zit en er een soort voorlooptijd met beeld ontstaat.
Het opgebouwde beeld moet dus altijd binnen de refreshtijd berekend zijn.
Kennen jullie de programmeertaal FUP of AWL nog uit de oudheid ? Zoek het eens op en vraag je dan eens af waarom
Windows bestaat en waarom alles nog zo traag is. Het antwoord om oneindig snel en oneidig klein te gaan is er al ( lang)....maar in één keer geïntroduceerd staat de hele economie die om IT is opgebouwd op zijn kop en stort de geldwereld in één keer in elkaar. De taart is al lang gebakken en elke dag wordt er een stukje van gegeten.
Helaas kan ik niet meer vertellen want dan gooi ik mijn eigen glas in.

100495

And the saga ends...

Hans Klok kan er een puntje aan zuigen...Wat een hocus pocus allemaal weer... "ONEINDIG klein en snel"...
Je zou jezelf eens moeten horen... en dan gaan nadenken WAT je eigenlijk zegt...

Seti... dmv distributed computing proberen orde in chaos te ontdekken... quite a task...hahaha!

"The Illuminati"... I've read it. Leuk als je een "conspiracy"-fan bent... veel meer dan een glimlach bezorgde het me niet. Verre van een mindfuck.

FUP en AWL wordt nog steeds gebruikt bij het programmeren van PLC's... leuke hobby... als je tijd teveel hebt...

Je wilt niet meer vertellen, maar wat mij betreft heb ik al genoeg onzin gehoord.
De enige enigszins "interessante" post van je, was die over kleurpercentages.

i7083170

[Webmaster]

From: Drazic

Zou het wel jammer vinden als het hier eindigd...
Ben benieuwd naar die pyramide vorm en andere claims

[Webmaster]

From: Drazic

Cugel where are u??

[Webmaster]

From: Cugel

Cugel where are u??

Waar ik ben spreken ze geen Nederlands, dat maakt het wel makkelijker.
Die kleurendatabase is niet zo moeilijk.
Maak in een excelsheet 5 kolommen en per kolom 50 rijen. De kolommen
heten R,G,B,W,Z per rij 2% kleur. Aspraak is dat je de secondeteller na 100
sec weer bij nul laat beginnen. Elke set t/m 100 is een "hapje" of frame.
Elke kleurwaarde per sec film leg je vast op het percentage en zo stapelt het her en
der op op die matrix. Stel je doet dit met blokjes waar je aan de zijkant de sec op schrijft.
Als je dan klaar bent heb je overal torentjes. Zet alle getallen van de blokjes per veld
naast elkaar en maak daar één getal van en vergelijk dit met het meest nabij gelegen priemgetal.
Elk hapje heeft een opvolgend nummer. De laagste waarde van het aantal blokjes vormt het kleinste
priemgetal in de database en de hoogste waarde het hoogste priemgetal. Deze priemgetallen geef je een
opvolgend nummer. De rest moeten jullie met jullie kennis nu toch echt wel in kunnen vullen.

Matrixview zal van nature al het mogelijke bedenken om aan te tonen dat het niet zal werken, terwijl het echt veel minder moeite kost om het werkend te maken...je moet het wel zelf zien en werkend kunnen maken anders is de lol er echt vanaf.