De Broncode

De Broncode

Re: De Broncode

Berichtdoor Michael1954 » zo 29 aug 2010, 06:49

From: Bartjes

317070 schreef:
Er is dan wel nog een 2e factor in de discusse, namelijk dat het algoritme om die codering te decoderen net zo groot wordt als al de films samen ;)
M.a.w. zo'n codering is een schijncodering, de benodigde opslagruimte blijft even groot, maar nu kruipt bijna alle ruimte in je decoderingsalgrotime. Dat het een ondergrens is klopt wel.

Mijn voorstel betreft een verschuiving van het probleem, daar heb je gelijk in. Maar ik zie niet zo gauw dat er zo - per definitie - geen winst meer te behalen is. Het is niet de bedoeling alle mogelijke echte films ergens op te slaan, en die dan aan te roepen. Dat zou inderdaad een schijnoplossing zijn. Wat je wel zou moeten doen is de steeds terugkerende patronen in echte films rubriceren, en die aanroepen. De daarna nog ontbrekende gegevens kunnen op de gebruikelijke manier worden ingekleurd.

Hoe dit in de praktijk zou moeten, weet ik zelf ook niet. 8-)
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » zo 29 aug 2010, 06:51

From: 317070

Bartjes schreef:
Wat je wel zou moeten doen is de steeds terugkerende patronen in echte films rubriceren, en die aanroepen. De daarna nog ontbrekende gegevens kunnen op de gebruikelijke manier worden ingekleurd.

Hoe dit in de praktijk zou moeten, weet ik zelf ook niet. 8-)

Daar heb je gelijk in, er is inderdaad nog (veel) verbetering mogelijk, maar praktisch is het niet zo interessant. Een gewone mens bekijkt iets van een duizendtal films op 1 dvd-speler. (oke, een echte cinefiel) Als je die dvd-speler dan moet uitrusten om alle patronen van miljarden films op te slaan, dan ben je niet echt efficient bezig. Je kunt er zoveel aan verbeteren als je wil, maar je grootte-orde van alle (mogelijke) zinvolle films is zo ongeloofelijk groot, dat zo'n algoritme nog niet vast te leggen is.

Er zijn wel al dingen die die richting uitgaan, zoals flash filmpjes waarvan de lettertypes al op je PC opgeslagen zitten, of ingame videos die je dan kunt afspelen binnen het spelletje op je eigen PC. (die laatste gaan wel gemakkelijk onder de MB voor enkele minuten)

Maar er is een reden dat films als Shrek niet afgespeeld worden door alle frames 1 voor 1 te renderen. Dit zou een zeer sterke compressie betekenen, anderzijds hebben de mainframes bij pixar al enkele mintuen nodig om 1 enkele frame te renderen. Ze moeten soms een uur rekenen voor 1 seconde film. Dus je ziet: de compressie kan er zeer sterk zijn, maar het algoritme wordt dan zo zwaar dat het niet meer praktisch haalbaar is.

Dus het algoritme moet passen op de gegeven ruimte, moet snel genoeg kunnen rekenen en de extra data voor de specifieke film moet zo klein mogelijk zijn om praktisch te kunnen zijn.
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » zo 29 aug 2010, 06:52

From: Bartjes

317070 schreef:
Daar heb je gelijk in, er is inderdaad nog (veel) verbetering mogelijk, maar praktisch is het niet zo interessant. Een gewone mens bekijkt iets van een duizendtal films op 1 dvd-speler. (oke, een echte cinefiel) Als je die dvd-speler dan moet uitrusten om alle patronen van miljarden films op te slaan, dan ben je niet echt efficient bezig. Je kunt er zoveel aan verbeteren als je wil, maar je grootte-orde van alle (mogelijke) zinvolle films is zo ongeloofelijk groot, dat zo'n algoritme nog niet vast te leggen is.

Er zijn wel al dingen die die richting uitgaan, zoals flash filmpjes waarvan de lettertypes al op je PC opgeslagen zitten, of ingame videos die je dan kunt afspelen binnen het spelletje op je eigen PC. (die laatste gaan wel gemakkelijk onder de MB voor enkele minuten)

Maar er is een reden dat films als Shrek niet afgespeeld worden door alle frames 1 voor 1 te renderen. Dit zou een zeer sterke compressie betekenen, anderzijds hebben de mainframes bij pixar al enkele mintuen nodig om 1 enkele frame te renderen. Ze moeten soms een uur rekenen voor 1 seconde film. Dus je ziet: de compressie kan er zeer sterk zijn, maar het algoritme wordt dan zo zwaar dat het niet meer praktisch haalbaar is.

Dus het algoritme moet passen op de gegeven ruimte, moet snel genoeg kunnen rekenen en de extra data voor de specifieke film moet zo klein mogelijk zijn om praktisch te kunnen zijn.

Van de praktische aspecten heb ik geen kaas gegeten. Het leek mij alleen wel leuk om te bedenken hoe je theoretisch gezien onder de gebruikelijke datacompressie-grens zou kunnen duiken. Zou het iets zijn om steeds alleen de veranderingen t.o.v. van een aantal karakteristieke shots en acties (gezichten, locaties, handelingen, etc.) te coderen - of wordt dit al gedaan?
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » zo 29 aug 2010, 06:53

From: 317070

Bartjes schreef:
Van de praktische aspecten heb ik geen kaas gegeten. Het leek mij alleen wel leuk om te bedenken hoe je theoretisch gezien onder de gebruikelijke datacompressie-grens zou kunnen duiken. Zou het iets zijn om steeds alleen de veranderingen t.o.v. van een aantal karakteristieke shots en acties (gezichten, locaties, handelingen, etc.) te coderen - of wordt dit al gedaan?

Wel, van ieder afzonderlijke shot zijn er zogenaamde I-beelden. Dit zijn beelden die feitelijk als foto opgeslagen zijn. Na een I-beeld heb je een hele hoop P-beelden. Dit zijn beelden die enkel afhangen van beelden die ervoor gekomen zijn. Tussen die beelden zijn er ook nog de B-beelden, dat zijn de beelden die afhangen van beelden die zowel ervoor als erna komen.

Ieder beeld wordt opgesplitst in macroblokken, en voor die macroblokken wordt dan in andere beelden gezocht naar een stukje beeld die er goed op lijkt. (aangezien het beeld in 5 frames meestal niet veel verandert, lukt dat heel goed) Dan sla je op waar je je referentieblok kunt vinden, en het verschil tussen jouw blok en het referentieblok. Dit verschil kan in de praktijk zeer gemakkelijk gecomprimeerd worden in het frequentiedomein door linear predictive coding of door de hoge frequenties uit het beeld weg te laten. In de praktijk zien we daar maar weinig/geen artefacten van.

Dit alles is afgestemd om goed te kunnen de film comprimeren, maar ook om het decoderen niet te zwaar te maken. Let er op dat je ieder beeld waaruit je later nog stukken als referentie kunnen gebruikt worden opgeslagen moeten blijven in het geheugen van de decoder. Meer zelfs, voor B-beelden moeten al beelden vooruit berekend worden. Meestal beperkt men de zoekruimte dan ook tot enkele beelden, bv enkel de I-beelden.

Dit is grotendeels de manier waarop de MPEG codecs werken. Let ook dat het codeer algoritme hier heel zwaar is. Om voor ieder macroblok op zoek te gaan in 30 beelden naar het beste stukje beeld als referentie is heel rekenintensief. Voor 30 beelden van 1 megapixel heb je dan namelijk al ongeveer 30 miljoen stukjes die als referentie kunnen dienen. Grote compressie is dus meestal ook niet geschikt om uit te voeren op bv. camera's of gsm's.

Je merkt, in het klein word je idee al gebruikt. Maar videocodecs zijn iets die zich meestal op de rand van het mogelijke zitten. Ieder beeld vereist veel geheugen, en iedere vorm van compressie en decompressie loopt al snel tegen rekentechnische grenzen aan. Vrijwel nooit is de compressie zelf de grens, meestal\altijd zijn het de rekencapaciteiten aan beide kanten voor het coderen en decoderen die de begrenzing vormen.
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » zo 29 aug 2010, 06:55

From: Bartjes

317070 schreef:
Je merkt, in het klein word je idee al gebruikt. Maar videocodecs zijn iets die zich meestal op de rand van het mogelijke zitten. Ieder beeld vereist veel geheugen, en iedere vorm van compressie en decompressie loopt al snel tegen rekentechnische grenzen aan. Vrijwel nooit is de compressie zelf de grens, meestal\altijd zijn het de rekencapaciteiten aan beide kanten voor het coderen en decoderen die de begrenzing vormen.

In theorie is hier dus nog veel mogelijk, wat praktisch vooralsnog onhaalbaar is. Grappig! :)
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » zo 29 aug 2010, 06:57

From: Rogier

In deze context wel een interessant nieuwtje: het record ligt inmiddels op 4 Tb per vierkante inch!
In het bericht staat tevens vermeld dat Seagate van de hierboven al besproken hamr-technologie zelfs 50 Tb/inch² verwacht.
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » za 21 jan 2012, 11:02

From: Frans1951

Zou de vinding van Sloot in deze tijd nog wel zin hebben als die ooit bestaan zou hebben ?

Op compressiegebied zie je maar weinig beweging.

Frans.
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » za 21 jan 2012, 11:04

From: 317070

O jawel, Mpeg4 en h264 zijn nu volop aan het opkomen, en in codering zijn de turbocodes aan hun opmars bezig. Maar dat is allemaal erg specialistisch. Bovendien lopen alle vorming van vernieuwing in het terrein vast in een spinnenweb van patenten en intellectueel recht. Zelfs de meest basisalgoritmes die je op een namiddagje zelf zou bedenken zoals adaptive Huffman zijn kapotgepatenteerd. Ook al kun je bewijzen dat dit eenvoudige algoritme het meest optimale algoritme mogelijk is voor hetgeen het doet.

Edit: ik zie dat dit een Sloot-topic is. Ik wil nog eens bevestigen: Sloot zijn uitvinding is onzin. Als je er iets van af weet, dan is een claim zoals dat van Sloot hetzelfde als gaan beweren dat je een computer kunt bouwen met een enkele transistor. Onzin dus.
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » za 21 jan 2012, 11:06

From: Frans1951

Een citaat van eerder geplaatste mening:
Dat oud verhaal van Sloot is overtrokken door de media om er een spectaculair verhaal van te maken. Zelfs de factor 2000000 is door de media berekend uitgaande van een statisch tabel waain, voor het gemak, deze in de berekening niet is opgenomen. Sloot heeft het nooit over zulk een enorme factor gehad nog over type tabel. Volgens de octrooien kwam hij niet verder dan een factor 8 zonder gebruik te maken van compressie. Op Wiki, http://jansloot.telcomsoft.nl en in Fok is meer over de media gecreëerde utopie te vinden. Interessant op dit gebied is een demo op youtube ( http://youtu.be/ECj_pTDt-pA ). Dat Sloot iets geniaals voor die tijd gemaakt heeft is wel duidelijk, zelfs de grote onder de IT'-goeroes waren zeer onder de indruk.

Frans
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

Re: De Broncode

Berichtdoor Michael1954 » za 21 jan 2012, 11:07

From: Rogier

Die "DNA" demo op youtube, alsmede die hele telcomsoft.nl site, zijn echt volslagen kolder. Na jaren discussie over Sloot's vermeende uitvinding worden de meest elementaire wiskundige principes kennelijk nog steeds genegeerd.

Aan iemand die claimt ieder bestand te kunnen terugbrengen tot een "DNA" bestand van 256 bytes, zou ik willen vragen hoe hij dat doet als ik 2257 verschillende bestanden heb.

En waarom 256 bytes, waarom niet nog kleiner. Stel dat ik 300 bestanden van ieder 1MB omzet naar DNA. Dan kan ik vervolgens toch ook de 300 DNA bestandjes achter elkaar plakken, dat geheel hernoemen naar .bin en dat -volgens dezelfde methode- ook weer reduceren tot 256 bytes? Is iedere 1MB nu opgeslagen in minder dan 1 bit?

Maar goed, ik hoop dat degene achter telcomsoft.nl een particuliere financier of durfinvesteerder weet te vinden. Het zou toch een fraaie grap zijn als iemand anno 2012 nog geld los weet te weken met deze bullshit :)
Avatar gebruiker
Michael1954
 
Berichten: 3618
Geregistreerd: zo 22 aug 2010, 16:39

VorigeVolgende

Keer terug naar Wetenschapsforum.nl (0112)

cron