mega-compressie - deel 2 -

quote:

Op vrijdag 22 juli 2005 14:00 schreef Pietverdriet het volgende:
Dat is het logisch gevolg van het verhaal, BUG80, als de sleutels allleen een nummer zijn voor een fim, een sleutel, en de databank universeel is.

Uiteraard. Maar een DivX film is feitelijk ook een sleutel voor de codec. Als ik dus 750 MB aan random data aan een DivX decoder voer zou daar ook nieuwe film uit moeten komen. Of het ergens op lijkt is een tweede.

Waarom is het zo moeilijk te begrijpen dat je iets niet kunt blijven comprimeren zonder verlies. Dan is altijd alles 0 in het oneindige. Dan kan je alle informatie in het heelal opslaan in een schakelaar, die altijd uit staat.

quote:

Op vrijdag 22 juli 2005 14:02 schreef BUG80 het volgende:

[..]

Uiteraard. Maar een DivX film is feitelijk ook een sleutel voor de codec. Als ik dus 750 MB aan random data aan een DivX decoder voer zou daar ook nieuwe film uit moeten komen. Of het ergens op lijkt is een tweede.

Nee, want die 750MB bevat een hoeveelheid data die voldoende is om informatie voor ieder frame te beschrijven.
1/16 van 64 K niet.

Kijk, ik zie het verschil tussen 750 MB en 4 kB niet zo, of desnoods de 7 GB van een DVD. De grootte mag nog zoveel verschillen, het aantal de mogelijke permutaties is in alledrie de gevallen vrijwel oneindig (probeer het maar eens te berekenen).

De vraag is alleen: is het mogelijk om een algoritme te maken dat een willekeurige stroom data omzet naar zoiets kleins als 4 kB.

quote:

Op vrijdag 22 juli 2005 14:09 schreef Kaalhei het volgende:
Waarom is het zo moeilijk te begrijpen dat je iets niet kunt blijven comprimeren zonder verlies. Dan is altijd alles 0 in het oneindige. Dan kan je alle informatie in het heelal opslaan in een schakelaar, die altijd uit staat.

Ik zeg toch ook niet dat er geen ondergrens is? De vraag is alleen waar die ligt.

quote:

Op vrijdag 22 juli 2005 14:12 schreef Pietverdriet het volgende:

[..]

Nee, want die 750MB bevat een hoeveelheid data die voldoende is om informatie voor ieder frame te beschrijven.
1/16 van 64 K niet.

Het zou kunnen, maar alleen als een bepaalde sequentie van bijvoorbeeld 3 bits via de "database" omgezet kan worden naar meerdere frames. Maar dat geloof ik dus niet, dat zou zo'n grote database betekenen...

quote:

Op vrijdag 22 juli 2005 14:12 schreef BUG80 het volgende:
Kijk, ik zie het verschil tussen 750 MB en 4 kB niet zo, of desnoods de 7 GB van een DVD. De grootte mag nog zoveel verschillen, het aantal de mogelijke permutaties is in alledrie de gevallen vrijwel oneindig (probeer het maar eens te berekenen).

De vraag is alleen: is het mogelijk om een algoritme te maken dat een willekeurige stroom data omzet naar zoiets kleins als 4 kB.

Ja, alleen met zoveel verlies dat het alle informatie verliest.

quote:

Op vrijdag 22 juli 2005 14:16 schreef gelly het volgende:

[..]

D'r is toch ook niemand die beweert dat je tot de 0 grens kunt gaan. De vraag tot hoever je iets kunt comprimeren (of coderen) is wel interessant lijkt me. En of dat nou 4K of 1 Mb is...

Hoe meer je comprimeert, hoe meer info je verliest.

quote:

Op vrijdag 22 juli 2005 14:18 schreef gelly het volgende:

[..]

Natuurlijk niet. Elke film is uniek, zo ook de code om een film te beschrijven. Natuurlijk kun je een random sleutel invoeren, de kans is dan vrij klein (zo niet verwaarloosbaar) dat je meer dan een hoop ruis ziet.

Ergo, je moet een hoeveelheid informatie hebben, en die informatie hoeveelheid van 4KB is veel te klein daarvoor.

quote:

Op vrijdag 22 juli 2005 14:19 schreef Pietverdriet het volgende:

[..]

Hoe meer je comprimeert, hoe meer info je verliest.

Niet per se. Ik kan wel degelijk een film comprimeren naar 4 kB door met een gigantische Huffman tree te werken (Sterker nog, als ik de tree net zo groot maak als de film heb ik genoeg aan 1 bit).

Het lijkt me alleen heel erg sterk dat ik dezelfde tree vervolgens kan gebruiken om een tweede film eveneens terug te brengen naar 4 kB. Dan komt er een gebrek aan redundantie de hoek om kijken.

quote:

Op vrijdag 22 juli 2005 14:21 schreef BUG80 het volgende:

[..]

Niet per se. Ik kan wel degelijk een film comprimeren naar 4 kB door met een gigantische Huffman tree te werken (Sterker nog, als ik de tree net zo groot maak als de film heb ik genoeg aan 1 bit).

Het lijkt me alleen heel erg sterk dat ik dezelfde tree vervolgens kan gebruiken om een tweede film eveneens terug te brengen naar 4 kB. Dan komt er een gebrek aan redundantie de hoek om kijken.

dat is dan eigenlijk geen compressie maar de informatie ergens anders neerleggen.

quote:

Op vrijdag 22 juli 2005 14:23 schreef gelly het volgende:

[..]

Je weet toch niet of Sloot een algoritme had bedacht dat in 4k pastte maar dat 700 Mb aan data kon genereren ?

Als dat zo is, en logischer wijze volgt dat uit de aanname dat sloot´s uitvinding echt was, dan zou je uit een random 4 K string een film moeten kunnen genereren. De hoeveelheid data in 4 K is niet voldoende voor informatie, maar alleen maar voor een catalogus nummer.

quote:

Op vrijdag 22 juli 2005 14:31 schreef Pietverdriet het volgende:

[..]

dat is dan eigenlijk geen compressie maar de informatie ergens anders neerleggen.

Ja inderdaad. Zip doet dat natuurlijk ook, maar die slaat de tree op bij de data, omdat elk bestand zijn eigen optimale tree heeft. Maar stel nu dat Sloot een tree heeft gevonden van bijvoorbeeld 1 GB die voor alle films goed werkt. Onwaarschijnlijk, maar stel.

quote:

Op vrijdag 22 juli 2005 14:34 schreef BUG80 het volgende:

[..]

Ja inderdaad. Zip doet dat natuurlijk ook, maar die slaat de tree op bij de data, omdat elk bestand zijn eigen optimale tree heeft. Maar stel nu dat Sloot een tree heeft gevonden van bijvoorbeeld 1 GB die voor alle films goed werkt. Onwaarschijnlijk, maar stel.

Een film is niet hetzelfde als een willekeurig bestand. Ongecomprimeerde films, die echt bestaan uit compleet opgeslagen frames zijn inderdaad gemakkelijk behoorlijk veel kleiner te krijgen. Net als dat je ongecomprimeerde BMPs kleiner kunt krijgen door het om te zetten naar GIF.

quote:

Op vrijdag 22 juli 2005 14:12 schreef BUG80 het volgende:
Kijk, ik zie het verschil tussen 750 MB en 4 kB niet zo

Waar je naar moet kijken is de entropie of het data "gewicht" van een bestand. Een uncompressed film is een dikke 150 GB. Hier zit natuurlijk ontzettend vele redundancy in, zodat je de essentie van die content ook wel in 700 MB (minder dan een half % van het origineel) kwijt kunt. Maar daar zit natuurlijk een grens aan.

Waar die grens ligt hangt van de film af (en wat je nog als acceptabele losses beschouwt), maar voor een normale gemiddelde speelfilm zal die grens onder de 700 MB maar ver boven de 4 KB liggen. 4KB gewoon te weinig. Het is vast wel wiskundig te bewijzen met Shannon ondergrenzen e.d. maar bovendien voel je gewoon op je klompen aan dat 4096 bytes gewoon te weinig zijn om een film te representeren (ik wel althans).

Het hele verhaal rammelt sowieso aan alle kanten omdat er wordt gesteld dat iedere film (of zelfs iedere data) in een sleutel van dezelfde grootte past. Terwijl een film die twee keer zo lang duurt als een andere, met vergelijkbare content, natuurlijk ook twee keer zoveel entropie omvat.

quote:

Op vrijdag 22 juli 2005 14:42 schreef gelly het volgende:

Dat is net zo waarschijnlijk als in kladblok wat letters neerplempen, het door een compiler halen en dan windows XP nagemaakt hebben.

Windows XP is geen 4Kb groot

quote:

Je hoeft de data enkel te omschrijven, niet te comprimeren. 2^256 Geeft een enorm groot getal, maar is dus ook met 5 chars te beschrijven.

Maar niet elk willekeurig getal is te schrijven als 2^n met n een natuurlijk getal.

quote:

Op vrijdag 22 juli 2005 14:19 schreef Pietverdriet het volgende:

[..]

Hoe meer je comprimeert, hoe meer info je verliest.

Je hebt ook lossless comprimeren, WinZip bv.

quote:

Op vrijdag 22 juli 2005 14:31 schreef Pietverdriet het volgende:

[..]

dat is dan eigenlijk geen compressie maar de informatie ergens anders neerleggen.

Dan heb je maar 1 bit nodig voor de Matrix op I-max. Staat de bit op 0 dan gebeurt er niets, zet je de bit op 1 dan kijk je naar de sleutel. De sleutel is dan vervolgens de film van een paar gigabyte.

quote:

Op vrijdag 22 juli 2005 14:51 schreef gnomaat het volgende:

[..]

Waar je naar moet kijken is de entropie of het data "gewicht" van een bestand. Een uncompressed film is een dikke 150 GB. Hier zit natuurlijk ontzettend vele redundancy in, zodat je de essentie van die content ook wel in 700 MB (minder dan een half % van het origineel) kwijt kunt. Maar daar zit natuurlijk een grens aan.

Waar die grens ligt hangt van de film af (en wat je nog als acceptabele losses beschouwt), maar voor een normale gemiddelde speelfilm zal die grens onder de 700 MB maar ver boven de 4 KB liggen. 4KB gewoon te weinig. Het is vast wel wiskundig te bewijzen met Shannon ondergrenzen e.d. maar bovendien voel je gewoon op je klompen aan dat 4096 bytes gewoon te weinig zijn om een film te representeren (ik wel althans).

Wat dat betreft ben ik het helemaal met je eens, maar ben jij het met mij eens dat als je in het bezit bent van een soort super database/Huffman tree (die niet bestaat denk ik), het dan wel mogelijk moet zijn om veel verder te comprimeren dan dat, zolang je die database maar apart opslaat. Het blijft natuurlijk theoretisch gewauwel, maar 60 jaar geleden geloofde ook niemand dat je muziek op kon slaan op 1/7 van de grootte, zonder perceptioneel verlies. Zeg nooit nooit!

quote:

Op vrijdag 22 juli 2005 14:57 schreef Kaalhei het volgende:

[..]

Dan heb je maar 1 bit nodig voor de Matrix op I-max. Staat de bit op 0 dan gebeurt er niets, zet je de bit op 1 dan kijk je naar de sleutel. De sleutel is dan vervolgens de film van een paar gigabyte.

Dat is het idee ja. En als je die "tree" nou wat kleiner maakt dan een paar gigabyte gebruik je vervolgens niet 1 bit, maar 32768 bits. En wie weet, misschien kan je met diezelfde tree The Matrix Reloaded ook wel comprimeren.

_{Zelf geloof ik er ook niet zo in hoor}

Waar hebben jullie allemaal gestudeerd In mijn tijd kregen we gewoon economie en geschiedenis over Willem van Oranje op school