Forum: De Broncode (104 topics)  
Topic: Mijn broncode  
Cugel
29-1-2005 23:10:00
Als je een film in stukken hakt waarvan de optelsom een benadering heeft van een bepaald priemgetal kun je daarvan het verschil weergeven. Stel dat het eerste deel de optelsom van 10 is dan pak je 11 als eerste hoger priemgetal en word dat deel weergegeven als het getal één. Het maakt dus niet uit hoe groot de optelsom is, als het verschil met dat priemgetal maar klein blijft. Als je dan nog eens alle optelsommen van alle scenes achter elkaar zet
heb je weer een getal wat je kunt verkleinen door het te vergelijken met een priem getal en voila....geef alle itteraties een nummer en sein dat eerst over het netwerk en daarna het uiteindelijke nr ( getal ) wat dus de gehele film weergeeft. Als beveiliging jun je deze hele code weer in je piramidemodel stoppen en zo weet je dus nooit welk getal nu de film voorstelt. Bijna een oneindige verkleining dus. Je kunt dus oneindig veel films op één CD kwijt.
Boven in de piramide stop je één getal samen met de itteratie code en naar beneden toe rekent zich een uitslag uit die weer te zien is als film...

waar of niet waar ?
 
weertj
30-1-2005 10:50:00
[quote]Als je een film in stukken hakt waarvan de optelsom een benadering heeft van een bepaald priemgetal kun je daarvan het verschil weergeven. Stel dat het eerste deel de optelsom van 10 is dan pak je 11 als eerste hoger priemgetal en word dat deel weergegeven als het getal één. Het maakt dus niet uit hoe groot de optelsom is, als het verschil met dat priemgetal maar klein blijft. Als je dan nog eens alle optelsommen van alle scenes achter elkaar zet
heb je weer een getal wat je kunt verkleinen door het te vergelijken met een priem getal en voila....geef alle itteraties een nummer en sein dat eerst over het netwerk en daarna het uiteindelijke nr ( getal ) wat dus de gehele film weergeeft. Als beveiliging jun je deze hele code weer in je piramidemodel stoppen en zo weet je dus nooit welk getal nu de film voorstelt. Bijna een oneindige verkleining dus. Je kunt dus oneindig veel films op één CD kwijt.
Boven in de piramide stop je één getal samen met de itteratie code en naar beneden toe rekent zich een uitslag uit die weer te zien is als film...

waar of niet waar ?[/quote]

niet waar

Ik heb de getallen (bytes);

20 87 234 5 0 24 87 165 89 64 3 6 100 9 250 210

Probeer het hier maar 'ns mee. Coderen en(!) decoderen.

suc6


Jacco

 
 
Cugel
31-1-2005 22:24:00

niet waar

Ik heb de getallen (bytes);

20 87 234 5 0 24 87 165 89 64 3 6 100 9 250 210

Probeer het hier maar 'ns mee. Coderen en(!) decoderen.

suc6


Jacco

Er zijn oneindig veel oplossingen.

Neem bijv dat getal 20 > dat kun je opslaan als: 3,9 ( 3 lager dan het 9e priemgetal )
Het getal 87 > 2,24 ( 2 lager dan het 24e priemgetal )
Als je ook nog eens vast houdt aan de regel dat een oneven getal tov. het hoger gelegen priemgetal even is en vice versa kom je heel erg ver.

De rest kun je zelf makkelijk uit laten rekenen. Als alle max. waardes van elke originele optelsom niet hoger dan bijv.
1009 komt en niet lager dan zeg 5 kun je de piramide zichzelf de ordes laten vaststellen. Dit wordt aan het begin van de string weergegeven zodat de ontvangende kant weet hoe de getallen uitgerekend moeten worden. Zo kun je per stap nog verder gaan door weer een orde lager te gaan.
Als je er vanuit gaat dat het werkt moet je alleen een afspraak over de uitzonderingen maken ( en dat zijn er erg veel! ).

Suc1,4






Jacco

[/quote]
 
weertj
31-1-2005 22:57:00
[quote]

Er zijn oneindig veel oplossingen.

Neem bijv dat getal 20 > dat kun je opslaan als: 3,9 ( 3 lager dan het 9e priemgetal )
Het getal 87 > 2,24 ( 2 lager dan het 24e priemgetal )
Als je ook nog eens vast houdt aan de regel dat een oneven getal tov. het hoger gelegen priemgetal even is en vice versa kom je heel erg ver.

De rest kun je zelf makkelijk uit laten rekenen. Als alle max. waardes van elke originele optelsom niet hoger dan bijv.
1009 komt en niet lager dan zeg 5 kun je de piramide zichzelf de ordes laten vaststellen. Dit wordt aan het begin van de string weergegeven zodat de ontvangende kant weet hoe de getallen uitgerekend moeten worden. Zo kun je per stap nog verder gaan door weer een orde lager te gaan.
Als je er vanuit gaat dat het werkt moet je alleen een afspraak over de uitzonderingen maken ( en dat zijn er erg veel! ).

Suc1,4
[/quote]

Klinkt allemaal erg wazig. In woorden kan het algoritme niet volgen. Ik hoef ook geen wiskundig bewijs te zien maar een simpele cijfer oefening moet toch kunnen?
Ik zie een soort Huffmann er in... piramide is een binaire boom in IT.

Om 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?


Jacco




 
 
Cugel
1-2-2005 22:34:00
[quote][quote]


Om 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.




[/quote]
 
ralphs
2-2-2005 0:13:00
Gefeliciteerd, jullie komen in de buurt.

Gr, Ralph
 
Cugel
2-2-2005 21:15:00
[quote]Gefeliciteerd, jullie komen in de buurt.

Gr, Ralph[/quote]

Ralph,

De buurt is erg groot en erg simpel. De moeilijkheid zit hem alleen in de codering van de priemgetal piramide per scene...thats all.

Heeft één van jullie wel eens uitgerekend wat dat aan opslagcappaciteit scheelt. Ga maar eens rekenen met de TB's aan storage van een gemiddelde bank..je komt dan al snel aan een schijf van 20 GB waar je meer dan genoeg aan hebt. Wereldwijd zou dat een enorme afname van de energiebehoefte tot gevolg hebben en een enorme snelheids performance over een gewone koperen leiding. Met een 56K6 modem kun je dan net zo snel werken als nu met glas!
 
ralphs
4-2-2005 23:56:00
Cugel,

Als je slim bent hou je op met posten, werk mee aan een nieuw patent. Neem contact met me op, dan vertel ik je meer. Dan kan je volgend jaar met pensioen.

gr, Ralph
 
Cugel
5-2-2005 21:24:00
[quote]Cugel,

Als je slim bent hou je op met posten, werk mee aan een nieuw patent. Neem contact met me op, dan vertel ik je meer. Dan kan je volgend jaar met pensioen.

gr, Ralph[/quote]

Ralph,

De vinding gaat binnenkort wereldwijd toegepast worden ala Linux. Het is en blijft een natuurlijk metafysich fenomeen dat aan iedereen toebehoort. Ik wil absoluut niet rijk worden want dat ben ik al. En met pensioen wil ik al helemaal niet. Er komt geen patent voor mijn vorm daar ik het complementerende deel nog niet verteld heb. Die priemgetallen
business is nog maar peanuts vergeleken bij exact dezelfde toepassing op de DNA string. Dit is pas het begin...lees eens wat meer over Imhotep, over natuurlijke low frequenty amplifiers en de stand van de Cheops pyramide op Tep Zepi...wellicht dat er meer mensen wakker worden.
 
MatrixView
5-2-2005 22:41:00
[quote][quote]Cugel,

Als je slim bent hou je op met posten, werk mee aan een nieuw patent. Neem contact met me op, dan vertel ik je meer. Dan kan je volgend jaar met pensioen.

gr, Ralph[/quote]

Ralph,

De vinding gaat binnenkort wereldwijd toegepast worden ala Linux. Het is en blijft een natuurlijk metafysich fenomeen dat aan iedereen toebehoort. Ik wil absoluut niet rijk worden want dat ben ik al. En met pensioen wil ik al helemaal niet. Er komt geen patent voor mijn vorm daar ik het complementerende deel nog niet verteld heb. Die priemgetallen
business is nog maar peanuts vergeleken bij exact dezelfde toepassing op de DNA string. Dit is pas het begin...lees eens wat meer over Imhotep, over natuurlijke low frequenty amplifiers en de stand van de Cheops pyramide op Tep Zepi...wellicht dat er meer mensen wakker worden.[/quote]

hahahahahaha! Ik denk dat jij wakker moet worden. Serieus.

Volgens mij zijn er hier teveel mensen die zelfs in Lord of the Rings (willen) geloven...
Complotten, esoterische bullshit... zero point energy...etc...
't stikt van die sites op 't web...

Ik wil/kan best buiten de standaard denken hoor, maar de tijd van efteling heb ik echt gehad.

Nou, ik zie jullie wel op 't journaal: "2 hobbits bedenken uitvinding van de eeuw." Ik kan niet wachten, dus schiet maar gauw op...


 
 
ralphs
6-2-2005 12:17:00
Cugel, stop met posten, serieus.

De dna toepassingen zijn eindeloos, maar als de verkeerde mensen hiermee aan de haal gaan heb je iets dat krachtiger is dan een atoombom. Denk na voordat je nu nog stappen zet, lees literatuur op internet. De wil toch niet iemand worden die de geschiedenis boeken in gaat als iemand erger dan stalin, hitler of mister dynamiet.

Gr, Ralph
 
MatrixView
6-2-2005 17:47:00
[quote]Cugel, stop met posten, serieus.

De dna toepassingen zijn eindeloos, maar als de verkeerde mensen hiermee aan de haal gaan heb je iets dat krachtiger is dan een atoombom. Denk na voordat je nu nog stappen zet, lees literatuur op internet. De wil toch niet iemand worden die de geschiedenis boeken in gaat als iemand erger dan stalin, hitler of mister dynamiet.

Gr, Ralph[/quote]

Ralph, stop jij ook gelijk met posten! Je kraamt steeds grotere onzin uit... 't was erg vermakelijk, maar 't begint nu echt irritant te worden. Compressie/codering is een serieus onderwerp, waar je geen kaas van hebt gegeten, dat is me wel duidelijk geworden. Je fantasie na het lezen van Smits' boek is een beetje teveel op hol geslagen...

Ik raad je aan om niet verder te fantaseren, maar om ECHT eens aan het programmeren en testen te slaan...
Je zult er dan snel achter komen dat je ideetjes NIET werken. :-)

het volgen van de newsgroepen: comp.compression en comp.compression.research is ook een goede klets water over je plaat.

Je hoort echt thuis tussen een kudde klingonsprekende paranoïde nerds die met pindakaas op hun hoofd in een graancirkel dansen om free-energie op te wekken.

Trek een blauwe jurk aan en probeer het in een veehal in Tiel.... mafketel.
 
 
Cugel
7-2-2005 21:05:00
[quote][quote

hahahahahaha! Ik denk dat jij wakker moet worden. Serieus.

Volgens mij zijn er hier teveel mensen die zelfs in Lord of the Rings (willen) geloven...
Complotten, esoterische bullshit... zero point energy...etc...
't stikt van die sites op 't web...

Ik wil/kan best buiten de standaard denken hoor, maar de tijd van efteling heb ik echt gehad.

Nou, ik zie jullie wel op 't journaal: "2 hobbits bedenken uitvinding van de eeuw." Ik kan niet wachten, dus schiet maar gauw op...



Geen complot geen esoterische bullshit.

Als je DNA opslaat en wacht op de juiste parameters totdat het zichzelf uitpakt zul je het op een bepaalde manier willen coderen zoals nu het geval is met de vorm van DNA zoals die in de natuur voorkomt. Ergo moet er een trigger zijn die overal in het heelal voorkomt en dat is de low freq van... Het DNA klapt zichzelf dan uit aan de hand van parameters ( priemgetalgewijs ) en groeit aan de hand van de combinaties die de hoeveelheid van die trigger uitzend.
"in leven" wordt de reeks aangepast maar er wordt wel steeds gekoezen voor een mogelijkheid die altijd al aanwezig is geweest. Andersom werkt dit precies hetzelfde.
In principe kun je dus ook een Hobbit reconstrueren. Het is ook niet zo gek dat iedereen anders denkt en doet maar dit is wel gelimmiteerd aan het aantal mogelijkheden per itteratie. Een reactie als bovenstaand is dan ook niet "vreemd".


[/quote]
 
MatrixView
7-2-2005 23:39:00
[quote] Geen complot geen esoterische bullshit.

Als je DNA opslaat en wacht op de juiste parameters totdat het zichzelf uitpakt zul je het op een bepaalde manier willen coderen zoals nu het geval is met de vorm van DNA zoals die in de natuur voorkomt. Ergo moet er een trigger zijn die overal in het heelal voorkomt en dat is de low freq van... Het DNA klapt zichzelf dan uit aan de hand van parameters ( priemgetalgewijs ) en groeit aan de hand van de combinaties die de hoeveelheid van die trigger uitzend.
"in leven" wordt de reeks aangepast maar er wordt wel steeds gekoezen voor een mogelijkheid die altijd al aanwezig is geweest. Andersom werkt dit precies hetzelfde.
In principe kun je dus ook een Hobbit reconstrueren. Het is ook niet zo gek dat iedereen anders denkt en doet maar dit is wel gelimmiteerd aan het aantal mogelijkheden per itteratie. Een reactie als bovenstaand is dan ook niet "vreemd".

[/quote]

Cugel, lieve jongen,

Laat ik nou toevallig dagelijks de automatisering verzorgen in een lab vol ontwikkellingsbiologen... I'm not kidding!
En ik durf mezelf niet eens expert te noemen op dat gebied... Maar jij weet ècht niet waarover je praat, kolere zeg, wat een ontzettende stierenpoep! Whoahahaha!

Als ik jou was zou ik die jip-en-janneke aflevering van Discovery, waarvan je 3 woorden hebt onthouden en vermengd met je priemgetallen fetish, nog maar eens goed bekijken. :-)

Dit forum heeft geen kloot meer met Sloot's uitvinding te maken... Gelul in de ruimte en gelul over Pieper. Jammer.

Logging Out.
 
Cugel
8-2-2005 21:41:00


Zozo....en jouw moeten we wel geloven.

a) ben ik geen jongen
b) weet ik wel waarover ik praat ( jij leeft nog in het tijdperk dat de aarde weer plat is waarschijnlijk )
c) Jan Sloot heeft inderdaad niets uitgevonden, het is er altijd al geweest. Gewoon een natuurlijk fenomeen.
d) Ik ga Fiep een mailtje sturen :-)
 
MatrixView
9-2-2005 0:25:00
Dag wijffie,

[quote]
Zozo....en jouw moeten we wel geloven.
[/quote]

Niks moet. Ik zeg alleen dat jij uit je nek lult. That much I know.

[quote]
a) ben ik geen jongen
[/quote]

Tja... dat verklaart een hoop. Ik zal er in het vervolg rekening mee houden.
Hey, maar eh... hoe bevalt die LOI cursus Windows 98 nou? Of doe je Astrologie?

[quote]
b) weet ik wel waarover ik praat ( jij leeft nog in het tijdperk dat de aarde weer plat is waarschijnlijk )
[/quote]

Nice. I'll take you to the edge of the earth and then push you over it...

[quote]
c) Jan Sloot heeft inderdaad niets uitgevonden, het is er altijd al geweest. Gewoon een natuurlijk fenomeen.
[/quote]

't is heel fijn dat jij al weet hoe Sloot 't precies geflikt heeft en dat je dat zo prachtig weet te koppelen aan een natuurlijk fenomeen... Ik ben zelf nog steeds bij het stadium dat ik ernstig twijfel aan zijn uitspraken... Tenzij jij "The Counting Argument" wiskundig kunt weerleggen... wiskundig... dus niet de stand van Toetanchamon's erectie erbij gaan halen, a.u.b.

[quote]
d) Ik ga Fiep een mailtje sturen :-)
[/quote]

Doe Jip de groeten van me; Janneke niet... da's zo'n slet.


Volgens mij dwaal ik af... komt allemaal door jou...
 
 
Cugel
9-2-2005 21:36:00
Jij weet waarschijnlijk wel dat een film een wis/natuurkundig maximum heeft qua grootte.
Dit houdt in dat er een gem. onder- en bovenwaarde is voor alle signalen per film.
De priemgetallen die rond die grenzen liggen, liggen dus als het ware vast.
Dit houdt in dat je ergens bij het 20.000e priemgetal begint en bij het ~ eindigt.
Wiskundig gezien integreer je dus tussen een range van mogelijkheden.
De kneep zit 'm in de afspraken die je maakt per scene of per tijdseenheid
die een priemgetal benaderd qua totaalsom.
De database of index is op deze manier moeilijk over te sturen..maar je kunt de generator ook standaardiseren.
En dit wil natuurlijk niemand want dat is commercieel niet aantrekkelijk.
Zelfs met Win 98 SE en een cursus van de LOI kom je er ook wel uit.
 
 
MatrixView
9-2-2005 23:34:00
[quote]Jij weet waarschijnlijk wel dat een film een wis/natuurkundig maximum heeft qua grootte.[/quote]

Grootte van wat? Aantal kleuren? Resolutie? Speelduur? Tenzij je over deze parameters afspraken maakt (grenzen stelt), kan een film in principe oneindig groot zijn. Dus verklaar je nader.


[quote]Dit houdt in dat er een gem. onder- en bovenwaarde is voor alle signalen per film.[/quote]

Weer zo lekker vaag.... Welke signalen? ...Kleur? ...Geluidsfrequentie? En die onder en bovenwaarde...? van wat? Het aantal keer dat een signaal voorkomt? De hoogte of duur van een gedigitaliseerd "signaal"?

[quote]De priemgetallen die rond die grenzen liggen, liggen dus als het ware vast.
Dit houdt in dat je ergens bij het 20.000e priemgetal begint en bij het ~ eindigt.[/quote]

... Nog vager... Zolang ik niet weet wat je met je "grenzen" bedoelt, ligt er voor mij helemaal niks vast.
En wat is er zo speciaal aan het 20.000ste prime volgens jou?

[quote]Wiskundig gezien integreer je dus tussen een range van mogelijkheden.
De kneep zit 'm in de afspraken die je maakt per scene of per tijdseenheid
die een priemgetal benaderd qua totaalsom. [/quote]

Nu mag je mij eens vertellen waarom je denkt zo zeker te weten dat Sloot gebruik maakte van priemgetallen en andere vage dingen die je eruit flapt? Sloot was geen wiskundige en rekenkracht was ook niet erg super eind 90-er jaren.

[quote]De database of index is op deze manier moeilijk over te sturen..maar je kunt de generator ook standaardiseren. En dit wil natuurlijk niemand want dat is commercieel niet aantrekkelijk.[/quote]

Alle nadelen van Sloot's uitvinding (mocht ie werken) wegen niet af tegen de voordelen.
Any major company would jump the bandwagon in a heartbeat....
Maar al die commerciele aspecten interesseren me geen drol, so let's just skip that.

M'n bullshit-detector rinkelt nog voordurend, mede doordat ik al meerdere van die vage prime-number ideetjes voorbij heb zien komen op de verschillende fora en newsgroups... Iedere week komt er wel weer zo'n flippo die denkt/zegt ieder type data iteratief te kunnen verkleinen... Als hen dan uitgelegd wordt dat dat onmogelijk is (met wiskundig bewijs) hoor je er niks meer van... waarschijnlijk ruw uit de droom ontwaakt. :-)

Vandaar mijn uitdaging voor jou (die nog steeds staat): Weerleg "The Counting Argument" (ookwel genoemd: "The Pigeonhole Principle")

Iedereen die denkt data te kunnen (blijven) verkleinen zou met deze stof bekend moeten zijn. Look it up.
 
 
Cugel
10-2-2005 21:41:00


Om het wat eenvoudiger te maken:

Ieder pixel heeft een maximum waarde qua kleur(soort) en diepte. bij een res. van bijv. 800x 600
hebben dus al die pixels een bepaalde waarde. Als je voor het gemak het geluid per kanaal per seconde
bekijkt heb je daar ook een maximale en minimale waarde in de bandbreedte zeg. 20 Hz - 20 kHz.
Bij de opname kun je dus al heel snel een onder en bovenwaarde van de kleur en diepte bepalen.
En dat is weer af te bepalen aan de hand hoe je de verticale en horizontale platen aanstuurt(stuurde) in de
tijd van Sloot. Hij heeft waarschijnlijk een film bekeken op een osciloscope ( moet je ook eens doen ).
Zo'n osci geeft gelijk realtime een gemmidelde weer en de onder- en boven grens. Vergelijk dit met het
dichstbijzijnde priemgetal ( dat 20000e was zomaar een voorbeeld ) en voila. Het is niet de data die je
bekijkt maar de waarde ervan die achter elkaar "het scherm op wordt geschoten".
Dit doe je in zulke hapjes dat je niet in de knoei komt met je refreshrate

Vraag maar eens aan je collega's wat er zou gebeuren als je elk roosje van een bloemkool een verschillend
kleurtje zou geven en dit proces omkeert van groei naar krimpen. Als elk roosje een pixelwaarde weergeeft zit er als het ware een film aan de buitenkant. De kunst is dus om elk roosje een ander waarde te geven....in japan zijn ze al heel erg ver hiermee en daar hebben ze ook al de link gelegd tussen DNA en priem itteraties aangezwengeld door
low freq. radiation van stoffen die in het gehele heelal voorkomen.
een film aan de buitenkant

Waarschijnlijk moet het proces van waarde generaties wel omgedraaid worden van de meeste fenomenen opdat het natuurlijk blijft. We zijn gewoon verkeerd om begonnen.
 
MatrixView
11-2-2005 0:32:00
>Om het wat eenvoudiger te maken:

Duidelijker. Daar gaat het om. En eenvoud maakt de zaak duidelijker. Maar goed, I'll play your game... kijken waar we uitkomen... mijn vermoeden en logica zegt me dat me dat we eindigen zoals iedere discussie over "oneindige compressie"... maar ik ben benieuwd of je me ergens kunt verrassen... ik sta ervoor open, maar ik zie 't niet gebeuren...

>Ieder pixel heeft een maximum waarde qua kleur(soort) en diepte. bij een res. van bijv. 800x 600
hebben dus al die pixels een bepaalde waarde. Als je voor het gemak het geluid per kanaal per seconde
bekijkt heb je daar ook een maximale en minimale waarde in de bandbreedte zeg. 20 Hz - 20 kHz.

Ok, laten we in deze thread voor het gemak een film van 800x640 in 32 bits kleur aannemen. 25 frames per sec. Speelduur 100 minuten. De macroblokken houden we even op 16x16 pixels (dus 50x40 blokken per frame en 4 bytes per pixel). Geluid laten we voor 't gemak even achterwege. OK?

>Bij de opname kun je dus al heel snel een onder en bovenwaarde van de kleur en diepte bepalen.

Als je 1 pixel dat pikzwart is treft in een blok nemen we een waarde van 0 aan voor die pixel. Als in datzelfde blok een fel-witte pixel voorkomt heeft die de waarde 2^32. De onderwaarde is dan 0 en de bovenwaarde 2^32ste-1. (Ik begrijp dat dit een extreem voorbeeld is, want de meeste blokken zullen een onder en bovenwaarde hebben die niet zo heel ver van elkaar liggen, vanwege de grote correlatie inter en intra blok en frame (scene) gewijs.)

>En dat is weer af te bepalen aan de hand hoe je de verticale en horizontale platen aanstuurt(stuurde) in de
tijd van Sloot. Hij heeft waarschijnlijk een film bekeken op een osciloscope ( moet je ook eens doen ).
Zo'n osci geeft gelijk realtime een gemmidelde weer en de onder- en boven grens. Vergelijk dit met het
dichstbijzijnde priemgetal ( dat 20000e was zomaar een voorbeeld ) en voila. Het is niet de data die je
bekijkt maar de waarde ervan die achter elkaar "het scherm op wordt geschoten".

Ok, dat hij wel eens een film bekeken heeft op een oscilloscope is zeer aannemelijk. TV-reparateurs hebben vaak zo'n ding tussen hun gereedschap. Dus we hebben nu een extreme onder en bovenwaarde van 0 resp. (2^32)-1. Let wel dat als je zoals jij zegt met gemiddelden gaat werken, je geen exacte registratie doet en dus LOSSY gaat compressen! Laten we het exact houden (LOSSLESS), dus wat ga je doen met je "gemiddelden"? Als je alleen de gemiddelde boven en onderwaarde opslaat van kleuren in een macroblok, weet je nog bar weinig over de kleurwaarde van iedere pixel binnen het macroblok (wat nodig is voor een exacte weergave)... dus wat ga je doen? De gemiddelden zijn alleen handig voor 't verkleinen van het verschil van iedere pixel-kleurwaarde.

Wat bedoel je met de horizontale en vericale platen? De macroblokken? Voordat we elkaar begrijpen moeten we eerst dezelfde taal spreken...

>Dit doe je in zulke hapjes dat je niet in de knoei komt met je refreshrate

Wat bedoel je? 1 Hapje = 1 Macroblok? En met refreshrate? = na exact 16x16 pixels een nieuwe boven en onderwaarde registreren??? Dus... wat heb jij nu en hoe ga je verder? Wat sla jij op en op welke wijze? Wees zo simpel en duidelijk mogelijk aub. dat scheelt verwarring en dus tijd. Bovendien kan iedereen het dan volgen.

>Vraag maar eens aan je collega's wat er zou gebeuren als je elk roosje van een bloemkool een verschillend
kleurtje zou geven en dit proces omkeert van groei naar krimpen. Als elk roosje een pixelwaarde weergeeft zit er als het ware een film aan de buitenkant. De kunst is dus om elk roosje een ander waarde te geven....in japan zijn ze al heel erg ver hiermee en daar hebben ze ook al de link gelegd tussen DNA en priem itteraties aangezwengeld door
low freq. radiation van stoffen die in het gehele heelal voorkomen.
een film aan de buitenkant. Waarschijnlijk moet het proces van waarde generaties wel omgedraaid worden van de meeste fenomenen opdat het natuurlijk blijft. We zijn gewoon verkeerd om begonnen.

First things first.... Laten we nog even niet gaan filosoferen, maar bij het voorbeeld blijven. :-)

Till next time.

 
 
Cugel
12-2-2005 22:45:00


Duidelijker. Daar gaat het om. En eenvoud maakt de zaak duidelijker.

----
En daar raak je precies het punt waar het om-draait !

Je rekent de verkeerde kant op en alleen maar met begrippen die je aangeleerd zijn
( of natuurlijk zelf hebt eigen gemaakt ). Er zijn maar twee in/outputs ; sound & vision.
Wel rekening houden met R,G,B en Zw en W.
Twee strings die synchroon lopen in de itteratie. De bit waarde van de kleur staat al vast
eer er gerekend gaat worden. De uitslag ( som ) van de eerste scene wordt alleen maar
vergeleken met een priemgetal omdat die nu eenmaal vastliggen van nature. Het verschil
wat je van dat priemgetal weer aftrekt geeft weer de waarde van de string en vice versa.
Je kunt dit inderdaad niet oneindig herhalen omdat je de priemgatallen die je gebruikt ook
moet opslaan zodat het maar steeds een fractie van het origineel blijft.
Stel je maar eens een pyramide voor( punt boven ) die naast een piramide staat die op zijn kop
staat. Beide piramides hebben dezelfde afmetingen en vormen zo elkaars complement.
De itteratie ziet er exact hetzelfde uit.

Een heel kort filmpje: 1 ( 104728 ) > de bovengrens was het 10.000e priemgetal.

Ga gerust heel moeilijke vragen bedenken...die los ik niet op voor je ( waarschijnlijk niemand )
Deze techniek is eerst terug naar af en helemaal overnieuw beginnen.

Suc1
 
Drazic
14-2-2005 17:14:00
Als ik je goed begrijp zit je idee ongeveer zo in elkaar (corrigeer me als ik het fout heb graag):

- Elk frame van een film kun je weergeven als een getal dat tussen de 0 en een fixte
bovenwaarde (die bovenwaarde word bepaald door de kleurdiepte, resolutie, etc.
en ligt dus vast, ik noem deze bovenwaarde vanaf nu 'Y' )

- Deze frames verdeel je in blokken van bijvoorbeeld 100 frames, deze blokken met
frames noem ik vanaf nu ' Scenes'

- Vervolgens bekijk je van elke scene ( = 100 getallen tussen de 0 en Y)
wat het laagste en het hoogste getal zijn van die 100 getallen.
Er is een heele grote kans dat het laagste getal veel groter is dan 0,
en tevens een heeel grote kans dat het hoogste getal veel lager ligt dan Y.

- Met deze info kun je nu voor elke scene de bovengrens (Y) al een stuk verlagen ,
door een offset op te tellen bij elk afzonderlijk framegetal (die offset is het laagste
getal dat bij die 100 getallen van de betreffende scene zat) en de bovengrens Y word
nu: het grootste getal dat er tussen die 100 zat, minus die offset...

- Als je nu voor elke scene de offset en de bovengrens opslaat, kun je die 100 getallen
nu in verreweg de meeste gevallen in minder bits opslaan, ondanks dat je wat extra
info bij elke scene opslaat (nl. de offset en de nieuwe bovengrens)

- Nu ga je van elke scene weer opnieuw de getallen bekijken, en vervang je elk getal
door de volgende 2 getallen: - dichtsbijzijnde priemgetal, - verschil met dit priemgetal
Dit dichtbijliggende priemgetal noteer je niet met de absolute waarde (bijv. 2389) maar
door te zeggen het 1700e priemgetal vanaf 0... Das al een beetje kleiner 2389 word 1700,
en daar komt alleen nog een kleine correctie bij die je ook moet opslaan (bijv. framegetal ligt
113 hoger dan het 1700e priemgetal)

Is dit ongeveer wat je bedoeld? Zoja, dan maak ik dit verhaal nog ff af :-p







 
 
Cugel
14-2-2005 22:57:00
ff...?

Visueel zit je op de goede weg. Rekenkundig ziet het eruit als die piramide vorm ( de itteratie ).
Maar de waardes bewegen in een bolvorm ( met de waardes X,Y,Z ). Het nulpunt ( midden ) is steeds
het uitgangspunt om optimale spanning te houden in de verhouding van de waardes ). De database
schuift als het ware steeds het volgende priemgetal naar het midden toe en heeft dan weer steeds
diezelfde maximale waardes. Dit impliceert ook dat de waardes negatief kunnen zijn vectorieel gezien
maar worden wel absoluut gemeten. De waardes worden gekoppeld aan de spanning die op de horizontale
en verticale platen staan icm. het electronenkanon.

Zie het als een zygote die groeit vanuit de neurale buis. Met de juiste parameters komt er een plaatje uit van
een ..... . In dit geval een film of natuurlijk het reciproke deel.







[/quote]
 
MatrixView
15-2-2005 1:05:00
[quote]ff...?

Visueel zit je op de goede weg. Rekenkundig ziet het eruit als die piramide vorm ( de itteratie ).
Maar de waardes bewegen in een bolvorm ( met de waardes X,Y,Z ). Het nulpunt ( midden ) is steeds
het uitgangspunt om optimale spanning te houden in de verhouding van de waardes ). De database
schuift als het ware steeds het volgende priemgetal naar het midden toe en heeft dan weer steeds
diezelfde maximale waardes. Dit impliceert ook dat de waardes negatief kunnen zijn vectorieel gezien
maar worden wel absoluut gemeten. De waardes worden gekoppeld aan de spanning die op de horizontale
en verticale platen staan icm. het electronenkanon.

Zie het als een zygote die groeit vanuit de neurale buis. Met de juiste parameters komt er een plaatje uit van
een ..... . In dit geval een film of natuurlijk het reciproke deel.

[/quote]

Ja joh, slinger er nog maar wat termen bij... 't kan niet op! hahaha!

Weet je, ik kan er werkelijk geen touw aan vastknopen, hoe vager en mooier je 't probeert te verklaren, hoe minder ik je geloof... We hadden zo'n mooi voorbeeld, maar je wijkt er steeds weer vanaf...

Ik weet ook nog steeds niet wat je met horizontale en vertikale platen bedoelt... en nu wordt er ook nog een electronenkanon tussengeschoven en waardes die in een bolvorm bewegen... What the f*ck?

...'t heeft niks meer met eenvoud te maken... misschien is dat het wel, maar dan druk jij je nogal onbegrijpelijk en met veel poeha uit... is dat om ons te imponeren ofzo? ...ik raak daar niet van onder de indruk.

Jammer hoor.
 
Drazic
15-2-2005 10:32:00
Beste Cugel,

Ik ben programmeur, en wil best samen met je je plan
gaan testen, maar net zoals Matrix volg ik het ff nie meer....
Kun je nie eens proberen mijn stappenplan een beetje af
te maken.. Dus gewoon in normaal nederlands, de handelingen
opsommen die je moet doen om van een scene met frames
naar een 'magisch getal' te komen (en andersom natuurlijk :-) )
 
weertj
15-2-2005 12:58:00
[quote]Beste Cugel,

Ik ben programmeur, en wil best samen met je je plan
gaan testen, maar net zoals Matrix volg ik het ff nie meer....
Kun je nie eens proberen mijn stappenplan een beetje af
te maken.. Dus gewoon in normaal nederlands, de handelingen
opsommen die je moet doen om van een scene met frames
naar een 'magisch getal' te komen (en andersom natuurlijk :-) )[/quote]

Precies... dat laatste daar gaat het om.

En generiek algorithme (wat dit claimed te zijn) zal met een simpel voorbeeld verklaard kunnen.

Ik ben ook programmeur en wil ook best eens wat testen....


Jacco


 
 
Cugel
15-2-2005 23:01:00
Jacco & Drazic,

Drazic zit op de goede weg..als je zijn ingeslagen weg volgt kom je vanzelf tegen waar het fout gaat.
Het klinkt mischien gek maar dan heb je gelijk de oplossing. Wellicht dat deze link
licht in de duisternis geeft: http://www.win.tue.nl/~jessers/aansluiting/priemgetallen.htm

Stel je een simpel boek voor dat per bladzijde een resolutie heeft van een aantal letterplekken x regels
...dit is echt de laatste hint...ik lees eind april de oplossing wel van jullie.

Baai du wee; de hor. en vert. plaat zitten in een televisie en daar staat spanning op. De waarde van de spanning
bepaalt waar het deeltje dat afgeschoten wordt door het electronenkanon terecht komt ( bijv. linksonder in beeld ).
 
Drazic
16-2-2005 13:17:00
> Drazic zit op de goede weg..
> als je zijn ingeslagen weg volgt
> kom je vanzelf tegen waar het fout gaat.

Ik heb de ingeslagen weg al eens gevolgd,
en weet precies waar het fout gaat. In het
begin zijn de 'gaten' tussen de priemgetallen
vrij klein (en haal je dus weinig winst), en na
een tijdje worden de gaten groter, maar word
dus ook het verschil met de echte waarde groter
dus dan behaal je net zo min winst omdat je het
verschil ook nog moet op gaan slaan ... :-(

Nou kun je natuurlijk een priemgetallen tabel
gebruiken die geoptimaliseerd is voor het frame
of stukje scene dat je wilt gaan coderen, maar
om diezelfde tabel aan de andere kant van het
netwerk weer te genereren kost bijna net zoveel
informatieoverdracht dan dat je het zonder
'priemgetallentruuk' had overgezonden...

Tenzij jij dus een methode denkt te hebben om
priemgetallen te genereren die gunstig zijn voor
een bepaald frame/scene, werkt jouw idee niet.
Zelfs niet als je 100 tabellen zou opslaan en bij
elk frame/scene zou aangeven welke van die 100
de decoder moet gebruiken (de gunstigste die de
encoder heeft kunnen vinden), zijn er altijd nog
frames die juist groeien omdat er geen van de 100
gunstig genoeg is...

Het word een heel ander verhaal als alle waardes
van de frames of scenes vrij dicht bij elkaar liggen
of gesorteerd zijn, maar hoe krijg je ze dichtbij elkaar
of hoe hef je de sortering weer op (zonder extra info
op te hoeven slaan)?

Kortom, uiteindelijk loop je vast...

> Het klinkt mischien gek maar
> dan heb je gelijk de oplossing.

Nee hoor.. Ik niet iig :-p En als jij um
wel hebt ben ik zeer benieuwd en wil
ik je graag helpen :-p Een paar pagina's
terug schreef je dat jouw idee een soort
opensource moest worden net als Linux,
waarom geef je niet wat meer info over
je plan vrij dan?

> Wellicht dat deze link licht in de duisternis
> geeft: http://www.win.tue.nl/~jessers/aansluiting/priemgetallen.htm

Niet echt.. Bovendien kende ik de link al van
toen ik zelf met een soortgelijk idee bezig
was (naar aanleiding van het boek, net zoals jij)

Dus Cugel, ik word het steeds meer met
MatrixView eens: OF we werken samen
met z'n 3-en je idee uit om te zien of het
werkt, OF je moet ophouden met beweren
dat het werkt.... Aan jou de keus

 
 
MatrixView
16-2-2005 20:26:00
Hello again,

voor iedereen en in het bijzonder Juffrouw Cugel:
(Drazic en Jacco hebben geen uitleg nodig waarschijnlijk)

De onderstaande 2 stukjes komen uit de FAQ van de comp.compression newsgroup:
http://www.faqs.org/faqs/compression-faq/part1/section-8.html
------------------------------------------------------------------------------------------------

Yet another popular idea is to split the input bit stream into a sequence of
large numbers, and factorize those numbers. Unfortunately, the number of bits
required to encode the factors and their exponents is on average not smaller
than the number of bits of the original bit stream, so this scheme too cannot
compress all data. Another idea also related to primes is to encode each
number as an index into a table of primes and an offset relative to the indexed
prime; this idea doesn't work either because the number of bits required to
encode the index, the offset and the separation between index and offset
is on average not smaller than the number of bits of the original bit stream.

------------------------------------------------------------------------------------------------

9.2 The counting argument

Theorem:
No program can compress without loss *all* files of size >= N bits, for
any given integer N >= 0.

Proof:
Assume that the program can compress without loss all files of size >= N
bits. Compress with this program all the 2^N files which have exactly N
bits. All compressed files have at most N-1 bits, so there are at most
(2^N)-1 different compressed files [2^(N-1) files of size N-1, 2^(N-2) of
size N-2, and so on, down to 1 file of size 0]. So at least two different
input files must compress to the same output file. Hence the compression
program cannot be lossless.

The proof is called the "counting argument". It uses the so-called pigeon-hole
principle: you can't put 16 pigeons into 15 holes without using one of the
holes twice.

------------------------------------------------------------------------------------------------


@Drazic
[quote]Het word een heel ander verhaal als alle waardes
van de frames of scenes vrij dicht bij elkaar liggen
of gesorteerd zijn, maar hoe krijg je ze dichtbij elkaar
of hoe hef je de sortering weer op (zonder extra info
op te hoeven slaan)?[/quote]

't is niet helemaal wat je zoekt, maar een "Burrows-Wheeler transform"
komt het dichtst in de buurt (behoeft nog wel een indexnr naast de gesorteerde data)

@Jacco,
Zijn wij nu echt de enigen die van mening zijn dat Sloot niet lossless werkte?
 
Cugel
16-2-2005 21:11:00
[quote]Hello again,

voor iedereen en in het bijzonder Juffrouw Cugel:
(Drazic en Jacco hebben geen uitleg nodig waarschijnlijk)

Yet another popular idea is to split the input bit stream into a sequence of
large numbers, and factorize those numbers. Unfortunately, the number of bits
required to encode the factors and their exponents is on average not smaller
than the number of bits of the original bit stream, so this scheme too cannot
compress all data. Another idea also related to primes is to encode each
number as an index into a table of primes and an offset relative to the indexed
prime; this idea doesn't work either because the number of bits required to
encode the index, the offset and the separation between index and offset
is on average not smaller than the number of bits of the original bit stream.

The above is absolutely true. Altough completely false if you give the primenumber
a number of its position. The lowest number is the start of your index.
Ever realized that the positionnumber of a primenumber can be generated the same
as a primenumber and become a primenumber itself...Think guys...think!

CU
 
 
MatrixView
16-2-2005 22:03:00
[quote]
The above is absolutely true. Altough completely false if you give the primenumber
a number of its position. The lowest number is the start of your index.
Ever realized that the positionnumber of a primenumber can be generated the same
as a primenumber and become a primenumber itself...Think guys...think!

CU
[/quote]

Lieve schat, ik denk dat je nog eens naar de testbank moet, want ook dit zal je niet veel winst geven na een paar iteraties. Dat komt omdat iedere vorm van data ná een kleinere transformatie van diezelfde data relatief steeds meer informatie bevat. Het klote hiervan is dat je data dan gemiddeld steeds moeilijker kleiner te transformeren valt in de volgende iteratie...

Ik vraag me nog maar 1 ding af: Beweer jij iedere willekeurige data met "jouw" methode te kunnen verkleinen (iteratief zelfs, zoals je zegt) en van daaruit weer tot de exacte originele data te kunnen komen?

P.S. Zovelen zijn je voorgegaan met eenzelfde idee. Het is op zich een mooi streven, want er spreekt hoop uit, maar wiskunde liegt nou eenmaal niet... Ik begrijp je koppige enthousiasme wel, maar ja...

I was once a believer too.... tòt dat f*cking duivengat! Ignorance is bliss... :-)

Succes.
 
Drazic
18-2-2005 18:44:00
@Matrix:
Volgens mij heeft Sloot himself
gezegd dat het lossless zou zijn?
Bovendien zou zijn vinding voor
alle vormen van data werken,
maar niet alles kun je lossy opslaan.
Dus het moet wel lossles zijn.

btw, kijk hier eens is wel interessant:
http://www3.sympatico.ca/mt0000/bicom/bicom.html


 
 
MatrixView
18-2-2005 21:49:00
[quote]@Matrix:
Volgens mij heeft Sloot himself
gezegd dat het lossless zou zijn?
Bovendien zou zijn vinding voor
alle vormen van data werken,
maar niet alles kun je lossy opslaan.
Dus het moet wel lossles zijn.

btw, kijk hier eens is wel interessant:
http://www3.sympatico.ca/mt0000/bicom/bicom.html
[/quote]

Hoi Drazic,

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

Ja, over Sloot en (zijn) uitspraken... Ik zou 't graag geloven, maar helaas is dat niet mogelijk... je kan niet -iedere- data-file lossless tot 1024 bytes terugbrengen (ook niet met behulp van 400MB generic database)... zie bewijs in deze thread.

Maar dit kan wellicht wel als je lossy compresst... (alleen laat de kwaliteit dan waarschijnlijk erg te wensen over)... en het zou alleen voor (bewegende) beelden en geluid kunnen... Fouten in tekst en binaries zijn ongeoorloofd.
De repa-base zou dus wel lossless geweest moeten zijn, maar had waarschijnlijk niet zo'n geweldige compressie-ratio)

Het zou wellicht ook kunnen als de database niet generic is. (dan heb je dus ook een database-verstuur-probleem)

Zelf denk ik dat het een combinatie is van beiden. Sloot's database was waarschijnlijk NIET generic en hij compresste ook NIET lossless... (Hij/iemand) heeft dus een "beetje" gejokt... (Wat toch echt niet ondenkbaar is voor iemand die diep in de schulden zit en zich met een leugen daaruit zou kunnen redden). Maar goed, dat is mijn mening.

Zou Sloot dan nog wel een interessante uitvinding hebben? Dat denk ik wel, want tegenwoordig worden de overeenkomsten van micro-stukjes film/beeld/geluid tussen verschillende films nog steeds niet (slim) gecodeerd.
Sloot deed dit wel in zijn codebook (database). Hij sloeg alle gedetailleerde onderdelen van een aantal films maar eenmalig op (dezelde (of gelijkende) onderdelen, kregen eenzelfde code).

Wat betreft het lossy verhaal:
Je zou voor de grap 's even 1 van Sloots verwezen patenten moeten doornemen. Het beschrijft een Quantifier die gelijkende stukjes data eenzelfde code geeft (niet zijn patent). Er werd ook van nog meer andere slimme ideeen (patenten) gebruik gemaakt. De combinatie is waarschijnlijk uniek.

Groet,
MatrixView.
 
Cugel
21-2-2005 21:54:00


Wat betreft het lossy verhaal:
Je zou voor de grap 's even 1 van Sloots verwezen patenten moeten doornemen. Het beschrijft een Quantifier die gelijkende stukjes data eenzelfde code geeft (niet zijn patent). Er werd ook van nog meer andere slimme ideeen (patenten) gebruik gemaakt. De combinatie is waarschijnlijk uniek.

Groet,
MatrixView.[/quote]

Heeft één van jullie wel eens wat gelezen van over kleurenpercentages en de maximale verhoudingen daarvan.
Elektrisch gezien kom je dan op een wel heel erg interessante database uit...wel 5 om te verstaan. Voor het geluid
doe je exact hetzelfde. Optisch gezien zet je die 5 tegenover elkaar. 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.

Als je dus een fout in de reeks maakt krijg je helaas wel een wending in de film die de regiseur nog niet bedacht had.
Geschiedenis is dus maar net afhankelijk hoe je het weergeeft of wie het geschreven heeft....
 
 
Drazic
22-2-2005 12:57:00
@MatrixView:

[quote]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...[/quote]

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 :-p

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)

[quote]Heeft één van jullie wel eens wat gelezen van over kleurenpercentages
en de maximale verhoudingen daarvan.[/quote]

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?)

[quote]Elektrisch gezien kom je dan op een wel heel erg interessante database uit...[/quote]

Verklaar je nader...

[quote]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.[/quote]

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 :-)


 
 
MatrixView
22-2-2005 14:18:00
[quote]@MatrixView:

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 :-p [/quote]

Hoi Drazic,

:-) Het is een leuk idee dat je oppert, maar je vergeet 1 ding... Jij begint al met een file die kleiner is dan 1024 bytes (dus een compressed file waarvan je al weet dat die na N x compressen kleiner zal zijn dan 1024 bytes). Maar dat wil natuurlijk NIET zeggen dat -IEDERE- file tot kleiner dan 1024 bytes gecompressed kan worden.

Probeer maar eens ieder mogelijk bestand van 1025 bytes in 1024 bytes te stoppen... Dat zijn 2^(1025*8) verschillende files... en die kunnen helaas niet allemaal uniek zijn binnen 2^(1024*8) files...

OF

Neem iedere willekeurige file en ga die met Bicom iteratief compressen... Je zult er dan bij bijna iedere file al snel achter komen, dat je compressed file GROTER begint te worden na een aantal iteraties... Het aantal files dat dus lossless in 1024 bytes gepakt kan worden is dus enorm klein (t.o.v. ieder willekeurig ander bestand)

[quote]
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) [/quote]

Helaas...MD5 bevat niet de INFORMATIE uit het originele bestand... Uit (alleen) een MD5 bestand kun je dus niet het origineel toveren...

Tenzij MD5 voor iedere file uniek is (wat niet zo is) en er een database bestaat waar alle mogelijke files in staan (en dat is onmogelijk) met bijbehorende MD5 waarden, begin je hier niks mee.


[quote]Heeft één van jullie wel eens wat gelezen van over kleurenpercentages
en de maximale verhoudingen daarvan.[/quote]

@Cugel
Nee. Maar ik vrees dat jij ons er "alles" over gaat vertellen in je eigen vage onbegrijpelijke uitleg.

[quote]Elektrisch gezien kom je dan op een wel heel erg interessante database uit...
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.[/quote]

Zoals Drazic al zei: leg uit... (liefst met links en duidelijke taal, want de onbegrepen New Wave "professor" uithangen, dat kan iedereen.)

 
 
Drazic
22-2-2005 15:19:00
@MatrixView

[quote] Helaas...MD5 bevat niet de INFORMATIE uit het originele bestand...
Uit (alleen) een MD5 bestand kun je dus niet het origineel toveren... [/quote]

Uit ALLEEN een MD5 niet, maar de truuk zit hem in dat je het collision nummer
ook op slaat. Ik zal me ff nader verklaren (in tegenstelling tot Cugel lol),
stel ik heb de volgende string: "MatrixView" en daar bereken ik de MD5 voor.
Vervolgens ga ik voor string "AAAAAAAA", "AAAAAAAB" , "AAAAAAAC" etc. de
hashes berekenenen... Tot ik aan de orginele string kom ("MatrixView" in dit
geval, ongeveer op de helft, dus hoef niet door te gaan tot "zzzzzzzz").
Als ik noteer hoeveel strings ik onderweg tegen ben gekomen met dezelfde
MD5 hash als "MatrixView" (in veel gevallen zijn dit er 0 en anders 1 of 2),
dan kan ik de tekst weer uitpakken door vanaf een vast punt strings te gaan
genereren ("AAAAAAA" in dit voorbeeld) en als ik de gezochte md5 hash tegenkom
bij een van die strings, hoog ik het collision nummer weer op zoals hierboven,
en als dat nummer gelijk is aan het nummer dat doorgegeven is door de
compressor, dan weet ik dat de huidige string ("MatrixView") de goede moet zijn....

[quote]Tenzij MD5 voor iedere file uniek is (wat niet zo is)[quote]

Daar dient dat extra getalletje juist voor dat naast elke md5 word opgeslagen
door de compressor, ik noem het de 'collision count' vanaf nu :-p

De vraag is nu alleen of een MD5 + Collision count minder dataopslag vereist
als het orgineel. Ik denk van wel, maar heb dit nooit uitgerekend of getest tot nu toe...

 
 
MatrixView
22-2-2005 18:59:00
[quote] Daar dient dat extra getalletje juist voor dat naast elke md5 word opgeslagen
door de compressor, ik noem het de 'collision count' vanaf nu :-p

De vraag is nu alleen of een MD5 + Collision count minder dataopslag vereist
als het orgineel. Ik denk van wel, maar heb dit nooit uitgerekend of getest tot nu toe... [/quote]

Hey Drazic,

Bedankt voor je duidelijke uitleg. Dat zouden meer mensen moeten doen.

Praktisch gezien zijn computers niet snel genoeg om de "collision count" van een file met een beetje grootte te berekenen. Deze collision count is namelijk (in tegenstelling tot wat je denkt) ENORM groot als de MD5 file veel kleiner is dan de originele file.

Nu theoretisch:

Neem dit hele simpele voorbeeld: stel je voor dat er maar 256 orginele files bestaan. Die zijn dus lossless uncompressed op te slaan in 8 bits. Laten we zeggen dat hun MD5 opgeslagen wordt in 4 bits. (klinkt aardig, want dat is 50% compressie)... Maar helaas zijn er dan maar 2^4 = 16 verschillende (unieke) MD5 files.

Nu, hoe groot is de collision count? Er zijn dus 256 - 16 = 240 files die een bijbehorende MD5 file hebben die exact dezelfde is als van (in ieder geval) 1 andere originele file. Als het goed verdeeld is, is je collision count maximaal
240/16=15 en minimaal 0. En gemiddeld heb je 'm dus te pakken bij (15+0)/2=7,5 (= tussen de 7 en de 8). Om de waarde van de collision count op te slaan heb je gemiddeld dus 3,5 bits (= 4 bits) nodig.

Dus de MD5 + Collision Count zijn gemiddeld op te slaan in 4 + 4 = 8 bits... (=zelfde als aantal orginele files)

Kut hè...

In onze "echte" wereld komen we niet veel md5 collisions tegen omdat we praktisch gezien niet werken met iedere mogelijke file. (Met z'n allen hebben we zelfs maar een heel klein percentage van alle mogelijke files).
 
 
Drazic
22-2-2005 20:47:00
@Matrix

[quote]Deze collision count is namelijk (in tegenstelling tot wat je denkt) ENORM groot als de MD5 file veel kleiner is dan de originele file.[/quote]

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...!

[quote]Praktisch gezien zijn computers niet snel genoeg om de "collision count" van een file met een beetje grootte te berekenen. [/quote]

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"....

[quote]Nu theoretisch:

<snip>

Dus de MD5 + Collision Count zijn gemiddeld op te slaan in 4 + 4 = 8 bits... (=zelfde als aantal orginele files)[/quote]

Bedankt voor het rekenwerk! Waarschijnlijk heb je wel gelijk, maar ik was maar een beetje aant brainstormen
in dit topic :-p 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 :-p

 
 
Cugel
22-2-2005 21:37:00
[quote][quote][quote]

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.
Als we de R-database nemen van bijv. 10%R per pixel hoef je daar alleen maar aan te
geven welke seconde(s) dat voorkomt. Deze reeks daar gaat het om...die loopt gewoon
als counter van 0 naar hoe lang de film duurt. Per database geef je dus eerst aan wanneer
ze "op mogen treden". Het grappige is dat het complement van de kleuren zichzelf uitrekend
tot 100% tenzij R of G beide al 100% aangeven. Als er dus niets veranderd aan een specifieke
pixel sla je dus ook niets op. bij bijv. een res van 800 x 600 heeft pixel 1 (~sec =1 ) de positie
linksboven op een tv. Na ~sec=480000 heb je de pixelwaarde van de pixel rechtsonder berekend.
~sec=4800001 is weer linksboven etc. etc. Het enige wat je dus moet doen is opslaan bij welke pixel
de percentuele eigenschappen horen. Dit ziet er gek genoeg bijna in 100% van de gevallen uit als
een piramide vorm en de "secondeplekken" kun je weer vergelijken met een priemgetal.
In de tussentijd van de refreshrate heb je dus tijd om te rekenen, maar dan wel voor elke kleur appart.

Op de X-as staat het percentage van de kleur, op de Y-as de helderheid en op de Z-as de tijdstippen
dat het voorkomt. Probeer het eens uit op een velletje papier of in Excel. Je ziet dat er een max en min
is aan de waarden. Het eerste plaatje moet dus opgeslagen worden juist op de 64Kb USB stick en heeft
een nr. om deze op te roepen. De strings voor de settings van de X, Y, Z waarde gaan als priemgetalnr
door. De kneep zat/zit 'm dus ook in de kwaliteit van dat eerste plaatje.

Je moet je wel voorstellen dat juist het afstellen van kleuren en de eigenschappen van een kleurenkanon
Jan Sloots' paradepaardje waren. Door het uitlezen van de tv kon hij zo zien waar de fout zat.
Elke tv had zijn eigen karaktereigenschappen...vandaar ook dat je eens een film door een osciloscoop moet
kijken...dan zie je meteen wat er gaande is.
 
 
MatrixView
22-2-2005 22:06:00
Hi again,

[quote]
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"....
[/quote]

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

[quote]
Bedankt voor het rekenwerk! Waarschijnlijk heb je wel gelijk, maar ik was maar een beetje aant brainstormen
in dit topic :-p 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 :-p
[/quote]

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).
 
MatrixView
22-2-2005 22:44:00
[quote]

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.
[/quote]


@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?
 
Drazic
23-2-2005 0:43:00
@Matrix

Dank voor de verheldering :-p

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 :-p
 
 
MatrixView
23-2-2005 9:21:00
[quote]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?
[/quote]

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.


[quote]
@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 :-p
[/quote]

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...
 
Drazic
23-2-2005 20:27:00
[quote] FF afw88 dus, voordat we conclusies trekken... [/quote]

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

 
 
Cugel
23-2-2005 23:21:00
[quote]

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

 
 
MatrixView
24-2-2005 10:53:00
[quote]

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

[/quote]

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
 
Drazic
24-2-2005 12:14:00
Zou het wel jammer vinden als het hier eindigd...
Ben benieuwd naar die pyramide vorm en andere claims
 
Drazic
25-2-2005 19:52:00
Cugel where are u??
 
Cugel
25-2-2005 23:04:00
[quote]Cugel where are u??[/quote]

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.
 
MatrixView
26-2-2005 13:05:00
[quote] 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.[/quote]

Met het bovenstaande, valt ook weer niks te beginnen.

Hey...enne... ik ben niet degene die maar "iets bedenkt"....! Dat doe jij! Ik geef alleen feiten/bewijzen, voor dingen die niet kunnen.

Gaf jij maar 's een keer een paar feiten of een concreet algoritme (pseudocode is ook goed) [Vergeet je niet de DEcompressie!)

Nu jezelf niet gaan verschuilen achter: "De lol is er echt af als je 't niet zelf werkend kan maken".
 
Cugel
26-2-2005 23:34:00
[quote][quote][quote]

Je/jullie zullen het echt zelf moeten doen..en anders stopt het.

Eén tip; lees 1t/m4 noch eens terug maar dan tussen de regels door.

100495
 
Cugel
26-2-2005 23:43:00
[quote][quote] Geen complot geen esoterische bullshit.

Als je DNA opslaat en wacht op de juiste parameters totdat het zichzelf uitpakt zul je het op een bepaalde manier willen coderen zoals nu het geval is met de vorm van DNA zoals die in de natuur voorkomt. Ergo moet er een trigger zijn die overal in het heelal voorkomt en dat is de low freq van... Het DNA klapt zichzelf dan uit aan de hand van parameters ( priemgetalgewijs ) en groeit aan de hand van de combinaties die de hoeveelheid van die trigger uitzend.
"in leven" wordt de reeks aangepast maar er wordt wel steeds gekoezen voor een mogelijkheid die altijd al aanwezig is geweest. Andersom werkt dit precies hetzelfde.
In principe kun je dus ook een Hobbit reconstrueren. Het is ook niet zo gek dat iedereen anders denkt en doet maar dit is wel gelimmiteerd aan het aantal mogelijkheden per itteratie. Een reactie als bovenstaand is dan ook niet "vreemd".

[/quote]

Cugel, lieve jongen,

Laat ik nou toevallig dagelijks de automatisering verzorgen in een lab vol ontwikkellingsbiologen... I'm not kidding!
En ik durf mezelf niet eens expert te noemen op dat gebied... Maar jij weet ècht niet waarover je praat, kolere zeg, wat een ontzettende stierenpoep! Whoahahaha!

Als ik jou was zou ik die jip-en-janneke aflevering van Discovery, waarvan je 3 woorden hebt onthouden en vermengd met je priemgetallen fetish, nog maar eens goed bekijken. :-)

Dit forum heeft geen kloot meer met Sloot's uitvinding te maken... Gelul in de ruimte en gelul over Pieper. Jammer.

Logging Out.[/quote]


M; er zijn meer biologen die het bovenstaande niet begrijpen en een netwerkbeheerder die daar dan werkt hoeft er dan ook niet vanuit te gaan dat die biologen alles weten. Waar ik zit weten we meer dan zij waarschijnlijk ooit zullen
begrijpen. Vraag ze maar eens naar de relatie tussen axiomen en files op snelwegen en de relatie tussen cellen en steden......
 
MatrixView
27-2-2005 11:07:00
[quote]
Je/jullie zullen het echt zelf moeten doen..en anders stopt het.

Eén tip; lees 1t/m4 noch eens terug maar dan tussen de regels door.

100495[/quote]

Wat er staat valt geen koek van te bakken, laat staan dat we iets moeten lezen/begrijpen wat er niet eens instaat!
Je maakt hele stellige beweringen, maar je verzand gewoon in je slechte/afwezige uitleg, waardoor je ongeloofwaardig wordt.

Ik denk dat je te lui bent om je (te) vage theorie concreet uit te werken, dus wil je ons het werk laten doen. Iets concreets HEB je gewoon niet OF je bent te angstig om het te geven, omdat je dan voor lul staat als we het tegendeel bewijzen.

Drazic kwam ook met een theorie over de md5 methode, maar hij beweerde tenminste niks stelligs. Dus was het ook geen issue toen bleek dat 't niet werkte.

Dus Cugel: Brainstormen is ok, maar pas op als je dingen gaat beweren, waarvan je zelf niet eens weet OF het uberhaupt werkt. Want dat is volgens mij het geval hier.

Een tip voor jou: stop maar met posten...
 
MatrixView
27-2-2005 12:01:00
[quote]M; er zijn meer biologen die het bovenstaande niet begrijpen en een netwerkbeheerder die daar dan werkt hoeft er dan ook niet vanuit te gaan dat die biologen alles weten. Waar ik zit weten we meer dan zij waarschijnlijk ooit zullen
begrijpen. Vraag ze maar eens naar de relatie tussen axiomen en files op snelwegen en de relatie tussen cellen en steden......[/quote]


Kun jij die aliens naast je even vragen naar de relatie tussen een dakraam en een olifant? Of tussen een tang en een varken?

Cugel, even voor de duidelijkheid: ik heb geen heilig geloof in kennis van wetenschappers. Het zijn mensen en er zijn nog genoeg dingen die we niet weten. Punt.

Maar het verschil met een wetenschapper en jou is, dat jij niks bewijst van wat je verkondigd. Een wetenschapper publiceert zijn THEORIE, UITWERKING en de bijbehorende RESULTATEN -OF- WEERLEGT een stelling en doet dat allemaal in termen die in ieder geval duidelijk zijn voor vakgenoten.

Jij beweert alleen veel te weten (zelfs meer dan toppers op hun eigen vakgebied), maar dat dat waar is, blijkt nergens uit...

Probeer het nog eens op het HigherLevel.nl forum, waar je je "brainfarts" hebt opgedaan. Of waren ze je daar ook zat?

Tja... :-)
 
Cugel
1-3-2005 21:35:00
De relatie tussen een tang en een varken en een dakraam en een olifant is dat ze alle vier ontworpen zijn.

Net als jij!
 
marinusprins
8-3-2005 0:51:00
euh ja
waarom heeft een fruitvlieg net zoveel dna-stringen als een mens
 
marinusprins
8-3-2005 0:54:00
Dit is universitair niveau,volgens mij
Heeft sloot ook op de UT gezeten
 
MatrixView
8-3-2005 17:30:00
[quote]Dit is universitair niveau,volgens mij
Heeft sloot ook op de UT gezeten[/quote]

Welnee, deze thread is helemaal geen universitair niveau. Het is niet veel meer dan oeverloos gelul in de ruimte en wat simpele wiskunde om van sommige theorieen aan te tonen dat het onmogelijk is.

 
 
Cugel
8-3-2005 23:05:00
[quote]euh ja
waarom heeft een fruitvlieg net zoveel dna-stringen als een mens[/quote]

( bijna ) alle dieren/mensen hebben evenveel verschillende ei-gen-schappen.
De itteratie nadat de originele DNA naar RNA is omgezet ( dus een copy van de originele database )
maakt dat je bent wat je bent en dat geld voor zowel die vlieg, varken als mens.
Een universele sleutel die overal werkt. De omgeving bepaald de rest en geldt als input voor de parameters
die bepalen hoe het zich verder ontwikkeld. Elke som een ander antwoord ( plaatje in Sloots geval ).
 
MatrixView
9-3-2005 17:10:00
:-) ...sommige mensen willen altijd laten zien dat ze overal verstand van hebben... Ook al hebben ze dat duidelijk niet.
 
 
Cugel
9-3-2005 22:48:00
[quote

Is wel erg diep voor de vroege morgen...is dit een zelfbeschouwing?;-)

[/quote]
 
MatrixView
10-3-2005 0:48:00
[quote]

Is wel erg diep voor de vroege morgen...is dit een zelfbeschouwing?;-)

[/quote]

Nope... , maar dat had jij ook al in je glazen bol kunnen zien.

Er bestaan speciale forums voor jouw soort. Hurry up.
 
Jeroen
10-3-2005 9:20:00
Zeg Matrix, waarom zit jij in elke post negatief te doen? Ik weet dat je een hobbyzipper ben maar wat is precies jouw frustratie? Heb je nooit zelf iets nieuw bedacht wat je dolgraag zou willen? Zit je hier te loeren tot je iets van waarde vindt om zelf iets mee te doen? Wil je er echt verstand van krijgen? Kijk dan eens verder dan je neus lang is! Op deze site staan nu al zoveel tips dat als ik tijd had ik er een compleet werkend systeem mee zou kunnen maken! Jij hebt nog helemaal niets getest of uitgeprobeerd. Kun je eigenlijk wel een beetje C programmeren of ben je gewoon een brulaap? Van de beschreven technieken op deze site kun je gewoon op het web de dll's downloaden. Daarmee bouw je in no time een programmaatje waarmee je frames kun compressen. En dan maar losexperimenteren. Nee, gewoon door blijven zeueren zoals jij diet, dat heeft zin! Er is een speciale plek voor ventjes zoals jij. Hurry up (dat is trouwens een nepTwix en dat was weer een vernoemde Raider - weet jij veel, snotaap)!
 
MatrixView
10-3-2005 18:21:00
[quote]Zeg Matrix, waarom zit jij in elke post negatief te doen? Ik weet dat je een hobbyzipper ben maar wat is precies jouw frustratie? Heb je nooit zelf iets nieuw bedacht wat je dolgraag zou willen? Zit je hier te loeren tot je iets van waarde vindt om zelf iets mee te doen? Wil je er echt verstand van krijgen? Kijk dan eens verder dan je neus lang is! Op deze site staan nu al zoveel tips dat als ik tijd had ik er een compleet werkend systeem mee zou kunnen maken! Jij hebt nog helemaal niets getest of uitgeprobeerd. Kun je eigenlijk wel een beetje C programmeren of ben je gewoon een brulaap? Van de beschreven technieken op deze site kun je gewoon op het web de dll's downloaden. Daarmee bouw je in no time een programmaatje waarmee je frames kun compressen. En dan maar losexperimenteren. Nee, gewoon door blijven zeueren zoals jij diet, dat heeft zin! Er is een speciale plek voor ventjes zoals jij. Hurry up (dat is trouwens een nepTwix en dat was weer een vernoemde Raider - weet jij veel, snotaap)![/quote]

Ah... Jeroen, je bent er nog! ik vroeg me al af waar je zat.

Tja... dit was te verwachten... een prachtige kans om die oortjes van mij 's te wassen met een alles-behalve technische aanpak (jammer...). Mijn kritiek op je -niet werkende- idee heeft je pijn moeten doen. Want op je idee en verhaal had je wellicht tijden zitten broeden... En er dan ook nog Eric Smit mee weten bij te slepen... en shit... dan komt daar zo'n zeikerd die vertelt dat 't toch echt allemaal niet zo nieuw en bijzonder is... kut hey...

Dus jouw frustatie snap ik.

Ok, nou de mijne: Ik heb een hekel aan mensen die van alles beweren zonder er enig bewijs voor te geven. Zij doen hun ideeen voor alsof het DE waarheid is (waarschijnlijk geloven zij het zelf ook) en verbloemen het met mooie quasi-wetenschappelijke termen en filosofisch gelul... Op simpele technische vragen krijg je geen antwoord. Je zult ernaar moeten raden. Het is dus meer hun "geloof" dan wetenschap... ...dat is behoorlijk irritant en ik help ze er graag vanaf met (waar mogelijk) een gedegen bewijsvoering. Maar gelul in de ruimte is niet te bewijzen.

Natuurlijk zullen genoeg mensen mij ook -terecht- verdomd irritant vinden, want in de onderbouwing denk ik als laatste pas aan het gevoel van die persoon die het idee naar voren bracht. Maar uit ervaring weet ik dat sommige dingen niet werken, en vertel waarom. Dat neemt misschien wat gewenste hoop weg, maar ik lieg in ieder geval niemand voor... Mijn bek houden en mensen in hun -soms narcistische- waan laten, zou ik ook kunnen doen, maar als ze andere mensen mee gaan slepen in diezelfde onwaarheid, dan zeg ik er wat van ... zie het als een soort bullshit-filter... ;-)

Als ik met kut-opmerkingen daarbij toch iemand heb gekwetst dan spijt me dat. Til er vooral niet TE zwaar aan.

Het is misschien moeilijk te geloven maar toch kan ik over goede en originele ideeen zeer enthousiast/positief zijn, maar die zijn hier nog niet voorgekomen tot nu toe. Die zijn ook niet zo simpel uit de mouw te schudden. Dat is jammer. Goede ideeen lees/bestudeer ik vooral in allerlei patenten, waar ik het gros van mijn vrije tijd aan besteed. Kan dat iedereen aanraden!

Nog 1 ding: ...Om mij te provoceren, spreek je je twijfel uit over m'n kennis en ervaring op programmeer en compressie-gebied. Dat mag. Het tegendeel kan ik in anonieme toestand ook moeilijk bewijzen, niet?

Maar goed, programmeren doe ik nog regelmatig (C(++), assembly, pascal, java, php, python), maar vooral tijdens m'n studie informatica was ik hier actief mee. Onder Windows doe ik niet veel, dus dll's genereer/gebruik ik niet. Wel grappig dat je daar over begint, want heb al jaren mijn eigen compressie-libraries met allerlei compressie-algo's. Dat loopt van Arithmetic tot Lempel-Ziv en van Fractals tot Huffman en de vele varianten daarop. Maar ook lossy methoden voor video, audio en images. Maar mijn allergrootste interesse ligt bij "transforms" die meestal voorafgaan aan de eigenlijke compressie-methoden. (De data zo slim mogelijk rangschikken dat ie redundanter wordt).

Nou, tot kijk maar weer.
 
Cugel
10-3-2005 22:55:00
[quote]
(De data zo slim mogelijk rangschikken dat ie redundanter wordt).

Slimme matrix. Volgens mij zit je helemaal goed.
Je zou jezelf eens af moeten vragen in hoeveel signalen jijzelf beeld ontvangt met je ogen.
Maw...wat wordt er nu exact uitgezonden wat jij ontvangt en denkt/weet te zien.
Data is slim...wij rangschikken deze alleen fout met de huidige comm. methoden.
Lees eens wat over DNA/RNA!

 
 
Jeroen
11-3-2005 9:00:00
Raar meisje ben je, matrix! Je concludeert maar aan maar je hebt geen idee! Allereerst, hoe kom je erbij dat ik de Jeroen ben die het stuk geschreven heeft? Dat zou ik best wel willen! Zijn verhaal heeft me reuze geinteresseerd. En op ideeen gebracht...

Wel grappig dat je niet onder Windows met dll's van anderen programmeert (hoewel het gros natuurlijk Visual Basic knutselwerk is zijn daar toch belangrijke zaken bij) terwijl je toch de hele dag eenzaam zit af te wachten tot er iets te posten valt. Als je nu eens verder keek dan je neus lang is en gaat zoeken via Iterated Systems en verder... Jeroen kon er niets van vinden schreef hij maar ik ben er via Google achter gekomen welke bedrijven de technologie en patenten (he, had je ze toch moeten vinden, patentenlezer dat je er bent!) hebben overgenomen. En zowaar kon ik daar gewoon de dll's downloaden en de eerste resultaten zijn al bereikt. Maar dat gaat jou niks aan, negatieveling! Jij bent weer een van die mensen waar Sloot over verzuchtte dat ze helemaal verkeerd keken en er niets van begrepen. Blijf het rustig zoeken in standaard compressiemethoden en inderdaad, je kunt eeuwig negatief blijven want zo werkt het niet. En blijven zeuren dat het lossless moet zijn en dat dat niet kan heeft ook weinig zin. De wiskunde heeft al eeuwen geleden bewezen dat dergelijke compressie lossless niet mogelijk is. Luister maar eens wat meer naar Cugel. Je hele wereld is lossles. Denk je dat onze hersenen snel genoeg zijn om alle beelden die we ontvangen real-time te verweken? Sukkel! Natuurlijk niet. De natuur heeft het prachtig opgelost, er gaat informatie verloren maar je merkt er niets van. Is dat mooi of wat?

Jouw frustratie is me trouwens nu helemaal duidelijk! Als het al waar is wat je scrhijft, je hebt niet eens een naam: eerst informatica gestudeerd (jij bent een nerd maar vertel me eens welk jaar en waar je afgestudeerd bent dan heb je wellicht nog bij mijn colleges gezeten) en dan op een afdeling als systeembeheerder aan de slag. Hier wijze verhalen schrijven dat je zo'n beetje alles weet van compressie (niet dus) en dan geen enkel bedrijf die je daar een goedbetaalde baan in aan wil bieden. Ik wil niet raden naar je uiterlijk en leefomstandigheden maar ik denk dat je een zielig iemand bent. Om de paragraaf maar eens in je eigen trant af te sluiten: get a life!

En doe ons een lol en post hier pas weer als je zelf een mooie vinding gedaan hebt (jammer, geen fantasie) of als je het BEWIJS wilt posten dat iets niet kan (ook jammer want zelfs in het voorgaande priemgetallen voorbeeld, dat zich in een programmaatje van acht minuten laat weerleggen heb je dat niet gekund). Ik ben bang dat je helemaal niet gewenst bent hier. Terug naar de spiegel maar weer en hop met die nageltjes!
 
MatrixView
11-3-2005 12:22:00
Hoi Jeroen,

Je boosheid zit wel HEEL erg diep merk ik. Je grijpt echt alles aan om mij te provoceren (of het nu op waarheid berust of niet...) En lezen is ook niet echt je sterke kant... tjonge jonge... :-)
Ga eens goed na wie er wat heeft gezegd...

Calm down. Take a breath. Er is niks aan de hand, anders dan dat je reputatie een deukje opliep... en nu maak je 't zelfs nog erger... dat wil je vast niet...

Ik zou een lange post kunnen maken, die jouw domheid op door jezelf genoemde vlakken aantoont, maar volgens mij is dat niet meer nodig. De lezer is slim genoeg. 't moet ook een beetje een technisch forum blijven... geen persoonlijke flame-war.

Moest zo lachen om je veronderstellingen over mijn persoonlijk leven, thanx! :-)
Meer geduld heb ik niet voor je, dus ik ga nu weer verder, sorry.
 
Jeroen
11-3-2005 20:15:00
Nou jammer, kinderachtig hoor.
 
marinusprins
23-3-2005 21:43:00
Idealist en de realist ,levert altijd leuke confersaties op.
Matrixview geloof jij nog wel in de behaalde compressie van Sloot
Wat ik denk: Hij heeft die 'zogenaamde' compressie gebruikt om iets anders wat hij uitgevonden heeft te versluieren.
Ik denk dat hij die 80% procent inefficientie van de cpu heeft weggewerkt.

 
 
Jeroen
27-3-2005 14:06:00
He Marinus, Matrix is geen realist hoor! Bij ons thuis heet dat een pessimist!
 
marinusprins
27-3-2005 19:05:00
[quote]He Marinus, Matrix is geen realist hoor! Bij ons thuis heet dat een pessimist![/quote]

Daar ben ik het niet mee eens.

een ongecomprimeerde films kost terrabytes aan opslag,dat willen jullie reduceren tot een paar mb?
Komop maak je zelf niet wat wijs,

DONT DREAM YOUR LIFE , LIVE YOUR DREAM.

 
 
TheJungOne
15-9-2006 16:19:00
"[quote]He Marinus, Matrix is geen realist hoor! Bij ons thuis heet dat een pessimist![/quote]

Daar ben ik het niet mee eens.

een ongecomprimeerde films kost terrabytes aan opslag,dat willen jullie reduceren tot een paar mb?
Komop maak je zelf niet wat wijs,

DONT DREAM YOUR LIFE , LIVE YOUR DREAM.

"
Jongens jongens, blijf toch niet zo hangen in die compressie ellende !
Dat is waar het juist NIET om gaat.

Alle vorige discussies die discussieren kan je het beste verwijderen, het is slechts ruis !

Inmiddels ben ik erachter hoe die Jan Sloot het heeft gefixt, en heb ik adh van het boek 'de Broncode' Bijlage 1 begrepen hoe hij het heeft klaar gespeeld !

Lees het maar eens goed, zet dan op papier wat hij schrijft .....
Hij heeft het nog net niet compleet neergezet .......

Ik ga verder met uitontwikkelen, nu jullie nog ...... :)
 
FredZ
15-9-2006 23:26:00
"Jongens jongens, blijf toch niet zo hangen in die compressie ellende !
Dat is waar het juist NIET om gaat.

Alle vorige discussies die discussieren kan je het beste verwijderen, het is slechts ruis !

Inmiddels ben ik erachter hoe die Jan Sloot het heeft gefixt, en heb ik adh van het boek 'de Broncode' Bijlage 1 begrepen hoe hij het heeft klaar gespeeld !

Lees het maar eens goed, zet dan op papier wat hij schrijft .....
Hij heeft het nog net niet compleet neergezet .......

Ik ga verder met uitontwikkelen, nu jullie nog ...... :)"
Wat wil je bereiken met je opmerking? "Jongens jongens, blijf toch niet zo hangen in die compressie ellende !
Dat is waar het juist NIET om gaat."

Daar is de hele wereld al achter nu jij pas.