Ik geef toe dat het verschil tussen data compressie en coderen van data gevaarlijk dicht bij elkaar ligt. Bij compressie ga je eigenlijk beoordelen hoe je het kund coderen zodat het kleiner wordt. Er worden geen prijzen uitgereikt voor coderingen die het origineel groter maken
Volgens mij is coderen afspreken hoe je bepaalde informatie opslaat, en compressie is een codering die minder ruimte inneemt dan het origineel (meestal dan, lukt niet altijd
).
Stapje voor stapje beste Rogier! Als we nu eerst 'even' oplossen dat we 16x16 blokjes via analoog-digitaal vertaling altijd kleiner kunnen opslaan als de theoretische digitale codering dan hebben we al het eerste geheim ontrafelt.
Ja maar dat kan dus niet. Als je een blokje data van 16x16 (of welke andere afmeting dan ook) via wat voor proces dan ook omzet naar iets anders, dan
kan het niet zo zijn dat het resultaat altijd in minder bits past dan het origineel. Dat is aantoonbaar onmogelijk.
Dan moet je nog eens aan iets anders denken. Ik heb er niet de kennis voor maat ik denk als je een half uurtje willekeurige video eens zou analyseren op:
a. basis van 16 x 16 blokjes
b. basis van lijnen
c. basis van kolommen
ik het gevoel heb dat het aantal 16x16 blokjes dat in twee opeenvolgende frames nog steeds hetzelfde is groter is dan het aantal lijnen of kolommen. Of, anders gezegd, als ik het eerste frame zou opdelen in 16x16 blokjes en die zou coderen, ik een groot aantal van die blokjes, wellicht op een andere plaats, weer zou kunnen weergebruiken in het tweede frame.
Ik weet toevallig het een en ander van digitale video & image processing, en de winst die je hierbij haalt is marginaal. Dit neemt natuurlijk toe naarmate je meer verlies toestaat (d.w.z. dat je twee blokjes hetzelfde noemt als hun verschil onder een bepaald niveau ligt), maar je moet al heel veel informatie weggooien wil je hier echt ruimte mee winnen.
We hebben het trouwens over 1200 blokjes per frame (uitgaande van 640x480, TV resolutie is nog iets hoger). Nog even los van hoeveel 16x16 blokjes er in een gemiddelde film zitten (en dus hoeveel bits je nodig hebt om 1 blokje te indexeren), een lijst van 1200 verwijzingen naar blokjes per frame en 135000 frames per film, dat past
nooit in 4 KB.
Voor lijnen gaat dat zeker niet op, voor kolommen weet ik niet maar kolommen ligt minder voor de hand omdat TV beelden lijn georienteerd zijn.
Dat heeft er niets mee te maken, een TV bouwt fysiek het beeld op je scherm in horizontale lijnen op, maar staat helemaal los van de inhoud van dat beeld. De mate waarin verschillende lijnen danwel kolommen in een film overeenkomen hangt 100% af van de content van die film. Je zou ook een TV kunnen maken die je beeld opbouwt uit verticale kolommen, die kan dezelfde films tonen.
Rogier schreef:
Want het zou impliciet neerkomen op: een film is in digitale vorm x bits groot, en de "analoge instructies" voor die film kosten y bits, en y<x.
Precies, je begint mijn denkwijze te begrijpen!
Maar wat je wil is onmogelijk. Stel dat er een manier is om x bits om te zetten naar "analoge instructies" (of wat voor magische procedure je ook verzint) en die instructies kosten y bits om op te slaan, en y<x. Maar nu heb ik 2
y+1 films. Die passen niet allemaal in y bits, want daar kun je maar 2
y verschillende originelen uit reconstrueren.
Of anders gezegd: je kunt vervolgens hetzelfde proces ook toepassen op die y bits, waardoor je de analoge instructies voor de analoge instructies voor x in z bits krijgt, met z<y. Enzovoort. Of als het alleen werkt op blokken van x bits, dan doe je het met meerdere blokken van y bits (dit tezamen een veelvoud van x vormen) tegelijk. Op die manier krijg je alles naar 1 bit. En dat kan niet
Ik kan je gedachtengang begrijpen maar ik veronderstel dat jij net zo min als ik verstand hebt van analoge tv signalen en de karateristieken daarvan en we weten dat sloot die wel had. Te makkelijk om te zeggen: "Als ik het niet begrijp dan kan het niet". Geef ik die dooie Sloot toch het voordeel van de twijfel omdat hij kennis had die wij niet hebben. (Als was het alleen maar van Hoe praat ik Pieper en de ABN miljoenen uit de zak!)
Ik weet er wel iets van, ik begrijp hoe d.m.v. modulatie er meerdere signalen over 1 kabel gaan, maar niet zoveel als Sloot. Ik weet echter wél het nodige van informatie- en beeldverwerking, en er zijn dingen waarvan ik bij voorbaat kan bewijzen dat het onmogelijk is. Daar is geen ruimte voor analoge truuks of "voorbij het digitale denken" of andere hekserij die ik over het hoofd zie. Qua compressie is het einde nog niet in zicht, en qua fysieke informatieopslag
zeker niet. Maar sommige dingen zijn wiskundig glashelder te bewijzen.
Rogier schreef:Even naar de kern van de zaak: toen Jan Sloot claimde een manier te hebben om films (audiovisuele data) klein op te slaan, bedoelde hij dan:
- fysiek klein, dus een hoop films op een véél kleiner/compacter opslagmedium dan de harddisks of dvd's van nu (ongeacht de hoeveelheid informatie / bits hij daarvoor gebruikte per film)
- logisch klein, dus in minder bits (ongeacht of hij die data dan digitaal of analoog opslaat, en of hij daarvoor een klein compact of groot opslagmedium gebruikte)
Het eerste acht ik best mogelijk, maar dan is "16 films in 64KB" complete bullshit. Het tweede is onmogelijk.
I beg to differ on this:
Als we twee verschillende digitaliserings methoden voor video vergelijken, dan kan het zo zijn dat een zekere methode x een kleiner digitaal bestand oplevert dan methode y, waarbij de zichbare kwaliteit hetzelfde is.
Tuurlijk, als je 2 methoden vergelijkt kan de ene best altijd kleiner zijn dan de ander.
Maar ik had het over de 2 manieren om "kleiner dan de huidige technieken" te interpreteren. Wat bedoelde Jan Sloot of Pieper toen ze het over "klein opslaan" hadden?
(en als het om "fysiek klein" ging, dan slaan uitspraken als "16 films in 64KB" echt nergens op)
Je moet ervan uitgaan dat er inderdaad bepaalde kleuren in het 256x256x256 kleuren palet, waarvoor de meeste digitale technieken 'bits' reserveren niet worden gebruikt in een TV beeld. en 220x220x220 is substantieel kleiner dan 256x256x256.
Dan kan het nog zo zijn dat bepaalde kleuren met het menselijk oog niet te onderscheiden zijn en dat je daardoor het aantal kleuren dat je op moet slaan nog verder kunt vergelijken. Vergeet niet dat de demonstraties door menselijke ogen beoordeeld is en niet met een programmatje dat kijkt of alle bits er nog zijn.
Door 220 kleuren per kanaal te gebruiken ipv 256 win je 0.7 bit (van de 24) per pixel, een winst van nog geen 3%, dus die winst is te verwaarlozen. Je kunt inderdaad nog meer weggooien zonder zichtbaar verlies, gangbare compressies doen al soortgelijke dingen. In plaats van RGB wordt een kleur opgebouwd uit 1 intensiteit en 2 kleurcomponenten (YCbCr of YUV/YIQ) en van de 2 kleurcomponenten wordt de helft aan precisie weggegooid, of maar 1 keer per 4 pixels opgeslagen. Daarmee win je al 50%. Maar dat soort dingen zullen absoluut in de verste verte niet de compressieratio's halen die in dit verhaal genoemd werden.
Dan kunnen er nog andere zaken zijn waarbij je een PAL beeld met interpolatie lijnen niet vertaald naar een vol beeld maar naar een half beeld (50% van de lijnen) zoals dat in de PAL en NTSC broadcasting wordt gedaan en dat kan van belang zijn bij de uiteindelijke digitalisering.
Dat komt neer op de helft van je lijnen weggooien en naderhand weer erbij interpoleren. Kan, maar dat is beslist zichtbaar (kan ik je uit ervaring verzekeren
).
Het eindresultaat van een dergelijke stelling is dat je in theorie niet kunt aantonen dat het ALTIJD kleiner kan maar dat in de praktijk op een hele film met miljoenen beelden het ontwaarschijnlijk is dat het met geen enkel beeld kan.
je kunt dan zeggen dat de methode x altijd een kleiner digitaal bestand oplevert dan methode y.
Dat kan sowieso, maar beweren dat een methode (welke methode dan ook) altijd een digitaal bestand oplevert van zus of zoveel KB gaat op een bepaald moment gewoon niet meer op.
Kijk, ongecomprimeerd is een film op PAL resolutie zo'n 146 GB (uitgaande van 720x540, 90 minuten, 25 fps). Met hedendaagse compressie krijg je dit op acceptabele kwaliteit (afhankelijk van de content, maar de gemiddelde film zeg maar) wel op 700 MB. Dit is niet lossless, en de verschillen zijn zelfs zichtbaar, maar "voor het oog" ziet het er goed uit. In deze techniek zijn al de meest bizarre truuks en complexe optimilisaties toegepast, dubbele informatie weggooien, kleuren reduceren, noem maar op. En dan hebben we het over hele ingewikkelde informatie- & dataverwerkende processen. Geen gesleutel aan kastjes met draaiknoppen en transistoren, maar harde wiskunde.
Als je dat weet te verbeteren met procenten, is dat knap. Als je het kunt halveren, is het briljant. En Sloot, die geen informaticus was maar een analoge technicus, zou hier met 4KB per film zo'n 99,999% vanaf halen?
Dat een methode voor het gros van de films (ruw gezegd "bij iedere normale film") werkt, daar kan ik inkomen. Dat blijkt in de praktijk, iedere film die je met xvid comprimeert tot 700MB ziet er op z'n minst redelijk uit (random ruis of speciale patronen trouwens niet). Maar in een film zit een bepaalde hoeveelheid intrinsieke data, een "gewicht" aan informatie zeg maar, en die kun je niet willekeurig klein krijgen. Ongeacht wat voor analoge truuks, encoding manieren, niet-binaire datastructuren of wat dan ook, je hebt er uiteindelijk toch een bepaald aantal bits aan informatie voor nodig om op te slaan. 700 MB zal vast nog niet de ondergrens zijn, maar 4 KB zit er
ver onder.
In theory, there's no difference between theory and practice. In practice, there is.
