[IDEE] Data compact opslaan

[Verwijderd]

Ik bedacht me onder het eten opeens dat je bijv. een film met verschillende beeldjes op kunt slaan als vorige beeldje met de verandering ten op zichte van het vorige beeldje(dat bestaat in ieder geval al), maar er dan ook er een functie op doen, die per kleur een lijn door het beeld heen trekt. Deze lijn is geen gewone lijn, maar een functie lijn, die bepaald wordt aan de hand van het originele beeld. Mijn wiskundeleraar heeft nl. ooit eens gezegd. Als je een aantal punten weet, kun je daar altijd een functie voor bedenken. Als je nu een programma zou hebben dat dat kan, ben je er.
Voor elke kleur moet een aparte functie worden geschreven. Misschien kan het ook dat een aantal kleuren dan samen een kleur zijn.
Let op: dit heb ik in 3 minuten gepost, dus het kan zijn dat het niet helemaal duidelijk is. Dit is een idee, en geen uitgewerkt iets. Misschien dat we samen een leuke theorie kunnen bedenken en anders niet.

[Lord Daemon]

Bedoel je te zeggen dat je ipv voor elke pixel zeggen welke kleur hij heeft, je voor elke kleur wil zeggen welke pixels erbij horen? Het lijkt me niet dat dat minder data kost?

[Verwijderd]

Niet helemaal, misschien is het mogelijk om op kruispunten van dit soort functies de kleuren op te laten tellen of juist te delen. Het komt er op neer dat je een functie laat genereren die over de hele film gezien, zo veel mogelijk definieert.

[Lord Daemon]

Kan je het misschien wiskundig iets beter uitwerken, want op deze manier is het een beetje vaag wat je bedoelt.

[Verwijderd]

Ik zou het wel kunnen, denk ik, maar ik ga nu slapen. In mijn ideeën wereld moet het in ieder geval kunnen.

[Delerium]

ik snap het idee, maar bedenk wel dat een plaatje waanzinnig veel random data bevat als je het in een assenstelsel wilt proppen.... dusdanig veel dat je x en y correlatie kansloos wordt en de z-as (volgende frame film) ook nogal lastig wordt (actiescenes etc).... en bij een nieuw beeld kan je goeddeels een nieuwe formule-set aanroepen.

Het zou kunnen, maar ik betwijfel ten zeerste de mogelijke compressiewinst en ook de benodigde rekenkracht: het is geen kattepis om uit een verzameling punten een formule te halen. Linieare functies kan net, maar de wat gevorderde puntenwolken vragen al om behoorlijke number-crunchers voor een knappe afgeleide functie.

* Delerium treft het dan niet met slechts een XP1800+

[StalieN]

Ik snap denk ik wat ie/je bedoelt...

Voor het coderen moet de codeerder (hoe noem je zoiets...) bij elk frame alle 32bit kleuren nagaan en de coordinaten vinden... stel: een plaatje van twee kleuren, om het te vergemakkelijken, van 800*600 met precies in het midden een verticale rode lijn van 1 pixel breedte, links daarvan een zwart vak en rechts daarvan een wit vak. De rode lijn schuift frame voor frame een pixel naar links en het witte en zwarte vak schuiven ook langzaam mee.
Frame 1 wordt als volgd opgeslagen (nog korter natuurlijk... maar je snaptwel):

code:

* Vierkant vanaf coordinaat (0,0) tot (399,600) vullen met zwart
* Lijn vanaf coordinaat (400,0) tot (400,600) vullen met rood
* Vierkant vanaf coordinaat (401,0) tot (800,600) vullen met wit

De coordinaten zijn de pixels (links bovenin beeld is (0,0) rechts onderin is (800,600) (in dit geval van resolutie dan...)
Dit kan natuurlijk nog, maar als de kleur groen op (23,4) en (456,2) en (56,543) en (700,32) zit, dan wordt het natuurlijk langer om dat op te schrijven, dus kun je de computer daar een functie voor laten schrijven die de vier coordinaten bevat als je de functie in grafiek zou uitvoeren, dit kan dus inderdaad korter.
Ok als we nu 32bit kleuren nemen, dat is 2^32 is 4.294.967.296 is 4,2 miljard kleuren dan moet 'ie dus per frame 4,2 miljard verschillende kleuren nagaan, daarbij de frames opzoeken en er een functie bij schrijven, dit 25 frames per seconden dus dat komt neer op ruim 107 miljard functies schrijven per seconde, mits je real-time zou willen opnemen. Dit hoeft natuurlijk niet persé, maar bij het lezen moet dit natuurlijk wel zo zijn, en dit wordt een probleem denk ik. Ok het is 22:40 dus ik stop (JKX op v8, vet lache!), maar ik blijf de topic volgen... Leuk idee in elk geval

[Lord Daemon]

Ik zie niet in waarom een willekeurige functie iets anders gaat zijn dan een lijst van coordinaten.

[MSalters]

Kan. Een gebruikelijke variant is Fourier Transformatie, en wordt gebruikt in o.a. JPEG compressie. Dan gebruik je [co]sinus functies. De besparing zit'm in het weggooien van sinusjes die bijna nul zijn.

( Is overigens een goed teken als je vaak dingen uitvindt die anderen eerder hebben uitgevonden. Dan hoef je alleen hardnekkig te zijn om een keer de eerste te zijn )

[Verwijderd]

Gaat niet werken denk ik. De coëfficienten die je nodig hebt zijn minstens zo groot als de data zelf.

Wat je wiskundeleraar bedoelde zal wel zoiets geweest zijn als veelterm- / Lagrange functies. Functies van minimale graad die door een aantal vaste punten gaan enzo. Deze zijn niet zo geschikt om de grilligheid in de gemiddelde data van bijv. een film te beschrijven. Een lossless compressiemethode die alle films kleiner maakt bestaat sowieso niet, en als je lossy gaat compressen zijn dat soort functies niet zo geschikt. Wat dingetjes weglaten heeft dan al snel merkbare gevolgen.

Wat jpeg met plaatjes doet (of mp3 met geluid, of divx met films) is ook zoiets. Alhoewel dat hele andere 'functies' zijn, dat zijn slim gekozen soorten functies waarbij je wat data kan weglaten zonder dat de functie direct drastisch verandert (wel een beetje, dat zijn de artifacts die je ziet).

[Verwijderd]

Volgens mij is pure random data niet te compressen (correct me if i'm wrong),
maar juist zoiets als een film, daar zit volgens mij gruwelijk veel regelmatigheid in.
Natuurlijk is het nog steeds zo'n gigantische hoop data, maar met formules moet het toch te benaderen zijn.. Daar zal je ongetwijfeld veel formules voor nodig moeten hebben (misschien in totaal wel veel groter dan de film zelf),
maar:
Is het niet mogelijk om een heel groot aantal standaardformules die een vlak beschrijven CENTRAAL op te slaan, op het internet bijvoorbeeld, zodat iedereen er gebruik van kan maken. (tuurlijk, bandbreedte en rekenkracht zijn misschien nog niet toereikend, maar volgens mij is dat pas efficient data opslaan)

[Verwijderd]

Eh, ik kan het mis hebben maar deze methode lijkt erg veel op de manier waarop vectoren worden gebruikt in bijvoorbeeld Flash? Of heb ik het mis?

[StalieN]

Eh, ik kan het mis hebben maar deze methode lijkt erg veel op de manier waarop vectoren worden gebruikt in bijvoorbeeld Flash? Of heb ik het mis?

ja flash gebruikt inderdaad dat principe, dat is het mooie, als je daar inzoomt dan zal een circel nooit blokkerig worden
maar flash gebruikt deze functies alleen bij lijnen/vakken/wat dan ook die gegenereerd zijn in flash zelf: importeer maar eens een bitmap in flash en ga die vergroten, dat wordt wel blokkerig (logisch natuurlijk...).

Is het niet mogelijk om een heel groot aantal standaardformules die een vlak beschrijven CENTRAAL op te slaan, op het internet bijvoorbeeld, zodat iedereen er gebruik van kan maken. (tuurlijk, bandbreedte en rekenkracht zijn misschien nog niet toereikend, maar volgens mij is dat pas efficient data opslaan)

Je bedoelt de meest gebruikte functies (welke zijn dat dan? zwarte vlakken, witte letters voor de aftiteling ofzo..?) op internet zetten... Dat is dus de codec die we van voor deze compressiemethode zouden moeten maken voorzien van de meest gebruikte functies naast natuurlijk de codec zelf (het begrijpen van de functies en die kunnen vertalen en omzetten). Uiteraard moet de codec zoveel mogelijk functies bevatten, liefst allemaal (kan duh niet) zodat in de film alleen voor elk frame zoiets hoeft te komen:

code:

Frame 1:
* functie 502, variabele p=3, variabele q=4,5, kleur=groen
* functie 234, variabele p=2,12 variabele q=92, kleur=rood
* functie 121, variabele p=15, variabel q=24, kleur=zwart

Je kan in de codec de film nog meer verkleinen door van te voren bij elke kleur te kijken hoeveel pixels daarvan zijn, en de kleur met de meeste pixels de standaard kleur te laten zijn (dus een film waarveel bloed in zit, is bijvoorbeeld de kleur rood de meest gebruikte kleur in de film, dus als je alle pixels van elk frame van de film zou sorteren en naast elkaar zou leggen, dan zou rood het meest voorkomen). Dan wordt dit aan het begin van de code die de film beschrijft opgeschreven:

code:

Standaardkleur: rood

Dan hoef je bij het coderen elke pixel die rood is, niet in een functie te stoppen, die kun je dan weglaten. Als voor een frame, waarin rood voorkomt, alle functies zijn uitgevoerd, dan zijn alle kleuren die in dat frame voorkomen dus op de juiste plek geplaatst, maar een aantal coordinaten hebben nog een gekleurde pixel toegewezen gekregen, die worden dan roodgekleurd, omdat de standaardkleur rood is. Dat scheelt ook weer heel veel functies. (Als je me niet begrijpt, snap ik, zeg het maar dan zal ik het beter uit proberen te leggen...)

Ik zie niet in waarom een willekeurige functie iets anders gaat zijn dan een lijst van coordinaten.

Omdat een willekeurige functie, die meerdere coordinaten bevat kleiner is dan al die coordinaten een voor een opschrijven.

Dit lijkt mij toch duidelijk: als je een bitmap van 400*400 neemt, en die vul je volledig met wit, dan slaat de bitmap dit op als:

code:

size=400*400
(0,0)=wit
(0,1)=wit
(0,2)=wit
[...]
(399,397)=wit
(399,398)=wit
(399,399)=wit
END

400*400=1600000 keer zeggen dat een bepaalde pixel wit is...

En de hier besproken methode (ik noem het voor het gemak even: CBM (compact bitmap) en waarom dat zal ik zo uitleggen) schrijft dit als volgt:

code:

size=400*400
standardcolor=wit
end

Stel er loopt een verticale zwarte lijn in het midden:

code:

size=400*400
standardcolor=wit
line (200,0)(200,200) black
end

Dit is natuurlijk uitgebreid opgeschreven, in de code zou het dan veel korter staan.

Ok, wat we nu hebben is dus precies die bitmap, geen pixel die anders is geplaatst, maar wel veel kleiner, i.p.v. 160000 regels met kleurtoekenning, twee regels kleurentoekenning en nog twee regels als begin en eindkenmerk, vandaar: CBM: Compact BitMap (zo kunnen we er makkelijker over praten )

Ik heb een witte bitmap van 400*400 in 24bit opgeslagen: 468kb = 468000 tekens in dit bestand. Dezelfde bitmap opgeslagen in jpg wordt 3,05kb=3050 tekens; veel minder maar nog steeds veel.
Nu in CBM, zoals uiteindelijk opgeslagen:

code:

400~ FFFFFF !

uitleg: 400 geeft het aantal pixels breedte aan, ~ geeft aan dat de lengte idem is (bij 400*399 wordt het: 400*399; achter * komt dus nog een getal, ~ zegt op zich al genoeg)
FFFFFF staat voor #FFFFFF, wie wel eens grafisch doet, weet dit: de standaard voor kleurbeschrijving, dit is dus wit. De # kan weggehaald worden, die veranderd namelijk nooit.
Tenslotte staat de ! voor het einde van de code.
Sla de code op in een tekstbestandje, en waar kom je op uit? Exactement: 13bytes! Dan heb je dus exact wat de bitmap is, een compressiefactor van 468000/13=36.000!!! En ten opzichte van jpg: 3050/13= 234 (de compressie factor is dus het aantal maal kleiner, dit is uiteraard de grootste compressie factor die je kunt krijgen, omdat een wit vlak het beste te comprimeren is met CBM, maar bedenk eens, als was de compressiefactor in een film maar de helft, hoeveel kleiner wordt een film dan wel niet!

Okee, als dit zo is, was dit al eerder ontdekt, waar zit mijn fout..?

[Christiaan]

Ik geloof toch dat de topicstarter iets anders bedoeld. Zoals ik het begrijp wil hij een aantal lijnen door het beeld trekken. Alle rode pixels, alle blauwe pixels en alle groene pixels worden in de vorm van een (zeer chaotische lijn - amper lijn te noemen) door het beeld getrokken. Volgens mij zou je het kunnen zien als een lijn die alle groene pixels op het scherm met elkaar verbind. Hier wordt vervolgens een formule voor berekend die alleen deze lijnpunten als uitkomst kan geven.

Volgens mij is het tevens zwaar onmogelijk om dit te doen....maar ik heb niet het idee dat de starter het principe achter flash bedoeld oid.

[StalieN]

nee,ok flash doet het net iets anders, maar wel met functies: als in flash een cirkel getekent wordt, dan maakt flash een functie voor die cirkel ten opzichte van de grootte van het frame waar de cirkel in staat (de beeldgrootte is als variabele in de functie verwerkt). Wordt er ingezoomd, dus het beeld vergroot, dan verandert de functie en worden de lijnen anders getrokken, waardoor de cirkel altijd scherp blijft.
Het idee van CBM is idd die 'lijn' van pixels (met hier en daar breuken in de lijn omdat een plaatje nooit alle dezelfde gekleurde pixels aaneen heeft) in een functie verwerken, dit is mogelijk: elke lijn, hoe chaotisch en random getekent dan ook, is in een functie te verwerken, de lengte van de functie is een ander verhaal. Het voordeel van een functie is dat er nooit informatie verloren zal gaan (van het antwoord: 2+2 is 4, maar 4 is niet perse 2+2)

[Verwijderd]

Ik wil dat er automatisch een functie wordt gemaakt die als het ware een 3d Lissajous figuur is. ChristiaanVerwijs snapte het inderdaad. Ik denk dat een functie die dan ook nog alleen de verandering t.o.v. het vorige frame aangeeft, enorm veel verschil kan uitmaken. Deze manier is gewoon een manier, waar of gewoon puur logisch naar gekeken moet worden (om te bewijzen dat het niet kan) of het moet gewoon geprobeerd worden. De rekenkracht die hiervoor nodig is ( Ecteinascidin) zal inderdaad enorm zijn, maar dat zie ik zeker niet als een probleem.
/me is optimist over de toekomstige snelheden van computers

[TheLunatic]

Even vooraf :

• Ik heb niet het hele topic gelezen
• Ik ben niet Wiskunde-B-ig aangelegd

Okay, nu mijn antwoord. Je wilt voor elke kleur een functie maken. Dat zijn in een 16-bit-kleuren film dus 16^2 functies. Daar komt dan nog bij dat in zo goed als elke pixel iedere kleur ( R, G, B ) voorkomt. Dus je moet die functie voor elke pixel gebruiken. In totaal bij een 800x600 film dus 3x800x600=1.440.000 keer. Per frame.

Of maak ik geen sense? Ik heb het gevoel dat mijn verhaal ook maar half af is... Whatever

[ Voor 0% gewijzigd door TheLunatic op 03-08-2002 14:06 . Reden: Klotesmilies ]

[StalieN]

Okay, nu mijn antwoord. Je wilt voor elke kleur een functie maken. Dat zijn in een 16-bit-kleuren film dus 16^2 functies. Daar komt dan nog bij dat in zo goed als elke pixel iedere kleur ( R, G, B ) voorkomt. Dus je moet die functie voor elke pixel gebruiken. In totaal bij een 800x600 film dus 3x800x600=1.440.000 keer. Per frame.

ja misschien toch maar alle replies lezen... dit is al uitgerekend... alleen dan anders; 16^2 is bijv 2^16 en er werd gebruik gemaakt van een 32bit kleurenset:

Ok als we nu 32bit kleuren nemen, dat is 2^32 is 4.294.967.296 is 4,2 miljard kleuren dan moet 'ie dus per frame 4,2 miljard verschillende kleuren nagaan, daarbij de frames opzoeken en er een functie bij schrijven, dit 25 frames per seconden dus dat komt neer op ruim 107 miljard functies schrijven per seconde, mits je real-time zou willen opnemen. Dit hoeft natuurlijk niet persé, maar bij het lezen moet dit natuurlijk wel zo zijn, en dit wordt een probleem denk ik

[Verwijderd]

Je idee bestaat al, alleen iets ingewikkelder

Je kunt beeld (en geluid) comprimeren door die data als de output van een wiskundige functie te beschouwen. Aangezien veel van die data bijna-random is, moet die wiskundige functie ook chaotisch zijn, maw. het moet een fractal worden.

Hoe je een fractal-formule kunt berekenen uit de beeld-data, is een van de gecompliceerdste zaken waar theoretische informatici en mathematici zich tegenwoordig mee bezighouden. Doe maar eens een google op "fractal compression" of "wavelets", en je weet wat ik bedoel

[ Voor 0% gewijzigd door Verwijderd op 03-08-2002 14:34 . Reden: typo ]

[Christiaan]

Zou je niet kunnen volstaan door alleen rood, blauw en groen als kleuren te gebruiken? Uit die kleuren kunnen alle andere kleuren tenslotte 'gecombineerd' worden. Nah...dat kan trouwens niet eens geloof ik (heb hier nooit zo over nagedacht). Volgens mij schiet je er haast meer mee op door per beeld 1 formule te verzinnen die het patroon van pixels zoals je dat ziet te genereren - dat is echter onnoemelijk zwaar onmogelijk . Het decoderen is een eitje - je hebt tenslotte de formule. Het coderen is echter bijna onmogelijk. Je moet dan random formules blijven uitstampen totdat je iets hebt dat hetzelfde resultaat geeft (moet je eens kijken wat voor fine-tuning algorithmen er dan nodig zijn).

Maar goed. Misschien zeg ik iets heel doms

[Zoijar]

Verwijderd schreef op 03 augustus 2002 @ 14:32:
Doe maar eens een google op "fractal compression" of "wavelets", en je weet wat ik bedoel

Je bent me voor, ik wou ook net over wavelets beginnen...

Dat is eigenlijk wat hier beschreven wordt. Weet iemand of er patent zit op de wavelet technology? Het zou misschien een goed uitgangspunt zijn voor een nieuw formaat nu jpeg niet meer gratis is. Wat ik er van weet geeft het mooiere en betere compressie dan de jpeg manier.

[StalieN]

iets andere ingeving, als alle frames achter mekaar gezet zouden worden in een assenstelsel (x,y,z)? Je hebt dus bijv een film van 100 minuten, 25fps en een frame is 800*600 dan heb je:
[code]
x=800 pixels
y=600 pixels
z=25*60*100= 150.000 frames
als je dan gaat zoeken naar lijnen in de diepe (z)? die lijnen zijn per scene duidelijker en dus makkelijker de stoppen in een functie omdat een camera misschien langzaam beweegt naar links, dan komen er dus links pixels, dus lijnen in de z-as, dus nieuwe functies bij, en rechts verdwijnen er lijnen. Je kunt het vergelijken als een auto met glazen bodem die over een snelweg rijdt, als je dan naar beneden kijkt zie je als je van de meest linkse baan naar de vluchtstrook rijdt (met 100 km/u ofzo) van boven af gezien, allemaal lijnen die van rechts naar links schuiven, dat idee dus. Die lijnen zijn veel duidelijker dus daar is een betere functie voor te schrijven.
Kijk, ultieme compressie is het probleem niet, dat een CD-ROM miljarden gigabytes kan bevatten met het zelfde aantal bits op de CD is al bewezen, ook hier op GoT, het probleem is de processorkracht die beschikbaar is in een pc, een gemiddelde pc-er moet op het moment wel kunnen filmkijken, dat is het probleem deze dagen. Geloof me, over 100 jaar is de ultieme compressie ongeveer wel bereikt: dan zijn de cpu's er snel genoeg voor, het heeft gewoon tijd nodig. Maar het is wel leuk om erover te rekenen en denken

[TheLunatic]

Ik denk dat dat laatste niet waar is. Tegen de tijd dat computer snel genoeg zijn om de technieken die we NU willen hebben snel te kunnen uitvoeren, tegen die tijd willen we weer meer en anders. We hebben geen monitor meer maar een beamer voor op de muur, en dus willen we een resolutie van 100x zoveel pixels als nu, en dat ook nog es met (weet ik 'et) 128 bits kleuren. Dat zal dan ook gecompressed en gedecompressed moeten worden, en daar zijn natuurlijk die PC die er dan zijn ook weer veel te traag voor.

Met andere woorden : De hardware blijft altijd trager dan de software ze wil hebben

_{misschien een leuke sig}

[Zoijar]

StalieN schreef op 03 augustus 2002 @ 19:03:
Kijk, ultieme compressie is het probleem niet, dat een CD-ROM miljarden gigabytes kan bevatten met het zelfde aantal bits op de CD is al bewezen, ook hier op GoT,

Hmmm waren we het er niet over eens dat dat een fabeltje was? Het ligt er sowieso al aan wat je compressed, en dus ook of het lossless moet zijn. Ik denk persoonlijk dat we niet veel verder zullen komen met compressen dan wat we nu al hebben. Misschien nog iets betere film kwaliteit bij dezelfde grootte, maar echt revolutionaire dingen zullen we volgens mij niet meer meemaken op dit gebied.

[LordLarry]

MPeg maakt al gebruik van bewegings vectoren om te comprimeren en ook van het alleen de wijzigingen tenopzichte van het vorige plaatje opslaan. Verder worden de kleuren niet in RGB opgeslagen maar in YCbCr die beter te comprimeren te zijn met RLE. Ik weet niet of te topic starten dit precies bedoelde, maar t lijkt er iniedegeval veel op

[Oogst]

Het aantal kleuren is uiteraard veel te groot om voor elke kleur een grafiek te maken.

Verder geldt dat je misschien met wat kunst en vliegwerk wel voor elke rij punten een grafiek kunt maken, maar die grafieken worden dan in de meeste gevallen erg lang en dus niet bruikbaar.

Met recursievergelijkingen kun je dan al meer, maar ook die worden erg ingewikkeld, niet alleen om uit te rekenen, ook gewoon om op te schrijven.

En dan nog een extra probleempje: stel twee pixels liggen op dezelfde X-coördinaat, maar op verschillende Y-coördinaten? Dat kan niet met functies, want een functie ligt nooit twee keer op dezelfde X-plek. Tenzij je gaat werken met polaire functies, maar dan kun je weer maar één pixel per graad hebben, dus dat werkt ook niet.

[Verwijderd]

Oogst schreef op 03 augustus 2002 @ 21:47:
Het aantal kleuren is uiteraard veel te groot om voor elke kleur een grafiek te maken.

Verder geldt dat je misschien met wat kunst en vliegwerk wel voor elke rij punten een grafiek kunt maken, maar die grafieken worden dan in de meeste gevallen erg lang en dus niet bruikbaar.

Met recursievergelijkingen kun je dan al meer, maar ook die worden erg ingewikkeld, niet alleen om uit te rekenen, ook gewoon om op te schrijven.

En dan nog een extra probleempje: stel twee pixels liggen op dezelfde X-coördinaat, maar op verschillende Y-coördinaten? Dat kan niet met functies, want een functie ligt nooit twee keer op dezelfde X-plek. Tenzij je gaat werken met polaire functies, maar dan kun je weer maar één pixel per graad hebben, dus dat werkt ook niet.

Een functie kan voor een x waarde oneindig veel y-waarden hebben.
Nooit WIB gehad?
Zoek eens op Lissajousfuguren.

[Verwijderd]

Oogst schreef op 03 augustus 2002 @ 21:47:
Het aantal kleuren is uiteraard veel te groot om voor elke kleur een grafiek te maken.

Verder geldt dat je misschien met wat kunst en vliegwerk wel voor elke rij punten een grafiek kunt maken, maar die grafieken worden dan in de meeste gevallen erg lang en dus niet bruikbaar.

Met recursievergelijkingen kun je dan al meer, maar ook die worden erg ingewikkeld, niet alleen om uit te rekenen, ook gewoon om op te schrijven.

En dan nog een extra probleempje: stel twee pixels liggen op dezelfde X-coördinaat, maar op verschillende Y-coördinaten? Dat kan niet met functies, want een functie ligt nooit twee keer op dezelfde X-plek. Tenzij je gaat werken met polaire functies, maar dan kun je weer maar één pixel per graad hebben, dus dat werkt ook niet.

Een functie kan voor een x waarde oneindig veel y-waarden hebben.
Nooit WIB gehad?
Zoek eens op Lissajousfiguren.

[Zoijar]

Dat kan niet bij een functie van R naar R. Zo'n functie is namelijk iets van F(x):->[expressie met x] Je kan dus nooit voor dezelfde x twee andere uitkomsten krijgen.
Ik denk dat jij het over R2->R hebt.

[Verwijderd]

Verwijderd schreef op 02 augustus 2002 @ 21:45:
Ik bedacht me onder het eten opeens dat je bijv. een film met verschillende beeldjes op kunt slaan als vorige beeldje met de verandering ten op zichte van het vorige beeldje(dat bestaat in ieder geval al), maar er dan ook er een functie op doen, die per kleur een lijn door het beeld heen trekt. Deze lijn is geen gewone lijn, maar een functie lijn, die bepaald wordt aan de hand van het originele beeld.

beeld omzetten in formules: fractal-compressie doet dat al.

[StalieN]

[...]Met andere woorden : De hardware blijft altijd trager dan de software ze wil hebben

Ok daar heb je denk ik idd gelijk in. Men zal altijd net iets meer willen dan eigenlijk kan, dat is maar goed ook, want als we alleen willen wat al kan, dan is de drang voor technische vooruitgang verdwenen, de nood om meer geld te verdienen verdwenen en ligt de wereldwijde economie op z'n luie gat. Maar als nu bewezen zou worden dat een compressie die zonder dataloss werkt, laten we nu niet beginnnen over of het nu kan of niet; stel dat het bewezen is, maar de compressie vergt een flinke processorkracht, dan wil ieder bedrijf dat zich bezig houdt met dataopslag-technologie die techniek gebruiken - als het redabel zou zijn - en dan zouden zulke schijven uitgerust worden met een eigen processor die de rekenkracht doet om de processor op het moederbord te helpen, net zoals op sommige videokaarten hulpprocessoren zitten. Over de toekomst moeten geen zorgen gemaakt worden, de mens redt zich er wel uit, dat zit nu eenmaal in zijn aard.

Ik denk persoonlijk dat we niet veel verder zullen komen met compressen dan wat we nu al hebben. Misschien nog iets betere film kwaliteit bij dezelfde grootte, maar echt revolutionaire dingen zullen we volgens mij niet meer meemaken op dit gebied.

Toen de cassettebandjes en LP's in opmars waren, dat was het helemaal, toen kwam de CD, dat was (en is) het helemaal, toen kwam de DVD, dat is het helemaal. Over 30 jaar kent de helft van de wereld het woord cassettebandje niet meer, is de CD wat wij nu van de LP vinden en is de DVD wat wij nu van de videoband vinden. Techniek gaat door, misschien niet allemaal even snel, maar de mens krijgt kennis van de omgeving en de wereld, de kennis van de geschiedenis en van het heden, gaat daarop gebaseerd nieuwe kennis opbouwen, de volgende generatie heeft die kennis ook en baseerd daarop zijn volgende kennis, het is een spiraal, die ooit zal stoppen (dat zou bijna moeten; wanneer zijn de hersentjes eindelijk verzadigd?), maar voorlopig niet, want we zijn pas een kleine eeuw onderweg.

Maar dit wijkt een beetje af van de topic...

En dan nog een extra probleempje: stel twee pixels liggen op dezelfde X-coördinaat, maar op verschillende Y-coördinaten? Dat kan niet met functies, want een functie ligt nooit twee keer op dezelfde X-plek. Tenzij je gaat werken met polaire functies, maar dan kun je weer maar één pixel per graad hebben, dus dat werkt ook niet.

Er is wel een manier om meerdere punten op de x coordinaat te leggen, dacht ik, en anders is dat ook niet zo'n heel erg probleem, dan worden het iets meer functies...

[Zoijar]

StalieN schreef op 04 augustus 2002 @ 15:14:
[...]
Toen de cassettebandjes en LP's in opmars waren, dat was het helemaal, toen kwam de CD, dat was (en is) het helemaal, toen kwam de DVD, dat is het helemaal. Over 30 jaar kent de helft van de wereld het woord cassettebandje niet meer, is de CD wat wij nu van de LP vinden en is de DVD wat wij nu van de videoband vinden. Techniek gaat door, misschien niet allemaal even snel, maar de mens krijgt kennis van de omgeving en de wereld, de kennis van de geschiedenis en van het heden, gaat daarop gebaseerd nieuwe kennis opbouwen, de volgende generatie heeft die kennis ook en baseerd daarop zijn volgende kennis, het is een spiraal, die ooit zal stoppen (dat zou bijna moeten; wanneer zijn de hersentjes eindelijk verzadigd?), maar voorlopig niet, want we zijn pas een kleine eeuw onderweg.

Ja dat ben ik wel met je eens, maar je hebt het nu over opslag media. Dat er veel meer data op een DVD gaat dan op een CD is puur iets technisch. Ik had het echter over compressie, dat moet je uit een meer theoretische hoek benaderen.

Ik vergelijk het met statistiek. Daar heb je het begrip "volledige statistiek", ruwweg betekent dat dat je data weglaat maar toch nog alle informatie behoud. (bv dat je alleen de som van alle kwadraten bewaard) Er is een minimale volledige statistiek, en dat is dan je maximale (lossless) compressie. Dit verhaal klopt niet helemaal, maar het dient alleen om een denkbeeld weer te geven Dat er dus een duidelijke limiet aan compressie zit.

Ik _denk_ dat we met wavelet compressie wel redelijk dicht bij de limiet zitten. In feite is dit net zoiets als er in de start post naar voren wordt gehaald. Overigens doet JPEG dit ook al, alleen met normale fourier transformaties. Wavelets zijn weer net zoiets, alleen complexer (pun)

[StalieN]

maar bij compressie van bmp naar jpeg zit toch ook al dataloss? of begrijp ik het verkeerd?

[TheLunatic]

Klopt, daarom noemen we het ook een lossy compression method.

Als je niet het verschil weet tussen lossless en lossy:

Als je 'A' lossy compressed, en je decompressed het weer, dan is het anders dan 'A' eerst was.

Als je 'A' lossless compressed, en je decompressed het weer, dan is het hetzelfde als 'A' eerst was.

[Essence]

ChristiaanVerwijs schreef op 03 augustus 2002 @ 14:51:
Zou je niet kunnen volstaan door alleen rood, blauw en groen als kleuren te gebruiken? Uit die kleuren kunnen alle andere kleuren tenslotte 'gecombineerd' worden. Nah...dat kan trouwens niet eens geloof ik (heb hier nooit zo over nagedacht). Volgens mij schiet je er haast meer mee op door per beeld 1 formule te verzinnen die het patroon van pixels zoals je dat ziet te genereren - dat is echter onnoemelijk zwaar onmogelijk . Het decoderen is een eitje - je hebt tenslotte de formule. Het coderen is echter bijna onmogelijk. Je moet dan random formules blijven uitstampen totdat je iets hebt dat hetzelfde resultaat geeft (moet je eens kijken wat voor fine-tuning algorithmen er dan nodig zijn).

Maar goed. Misschien zeg ik iets heel doms

Ik denk het niet. Trouwens los van het feit dat het coderen heel veel tijd kost, is de uiteindelijk gevonden formule (mits die er al met zekerheid is, wanneer stop je met zoeken?) iedere keer voor elk plaatje weer anders. Nou kun je natuurlijk wel al deze mogelijke formules bijhouden/bewaren, maar ik heb zo'n donkerbruin vermoeden dat dat er heel veel zijn, bijv. orde grootte aantal mogelijk permutaties van de pixels in het beeld.

[StalieN]

Als je 'A' lossy compressed, en je decompressed het weer, dan is het anders dan 'A' eerst was.

Als je 'A' lossless compressed, en je decompressed het weer, dan is het hetzelfde als 'A' eerst was.

Ok ik snap dat dat bij een plaatje goed kan, daar kijk je naar het geheel en niet naar een pixel. Maar letters kun je toch niet lossy compressen? Dan gaat dat toch helemaal fout? (dat vroeg ik me ook altijd af hoe een txt bestandje zo gigantisch gecompressed kan worden)

[Verwijderd]

Maar letters kun je toch niet lossy compressen? Dan gaat dat toch helemaal fout? (dat vroeg ik me ook altijd af hoe een txt bestandje zo gigantisch gecompressed kan worden)

Text zou ik niet lossy compressen nee. Maar tekstbestanden kun je normaal gesproken goed compressen (dwz lossless maar toch met een redelijk hoge compressiefactor) doordat in normale tekst heel veel herhalende patronen zitten.

In een bestand neemt elk karakter 1 byte in (da's 8 bits = 256 mogelijkheden), terwijl in die meeste bytes alleen maar letters (= slechts 26 mogelijkheden) staan. Daar kun je dus al flink wat winst boeken.

Bovendien zitten er in de meeste talen zitten heel veel herhalende lettercombinaties (lettergrepen, klanknotaties, bla bla whatever). Dus een compressiemethode die gebaseerd is op herhalende patronen (huffman bijvoorbeeld) scoort sowieso goed met text.

[StalieN]

[-zie bovenstaande bericht-]

aha... ok ikke snapput

[maartenba]

Ok, heb niet het hele topic gelezen, wel goed over de helft, en heb ook nog een ideetje
Stel: je hebt een afbeelding van 2*2 pixels (om het simpel te houden, in Wiskunde stink ik )
Even in HEX kleurtjes:
1) FFFFFF 2) FF0000
3) FF0000 4) 00FF00

Kan je hier geen 3 functies op plakken, 1 voor elke kleur ?
Er is bijvoorbeeld de lijn voor rood die door pixel 1,2 en 3 moet, dan groen gaat door 1 en 4, en blauw enkel door 1. Als je die functies dan netjes uittekent, en over elkaar plakt, heb je dan niet alles terug ?

edit:

Eventueel kan je dit toepassen op plakjes van 10*10 of zo, om de formules beperkter te houden en processorkracht/dataruimte te sparen.

[Verwijderd]

Kan je hier geen 3 functies op plakken, 1 voor elke kleur ?
Er is bijvoorbeeld de lijn voor rood die door pixel 1,2 en 3 moet, dan groen gaat door 1 en 4, en blauw enkel door 1. Als je die functies dan netjes uittekent, en over elkaar plakt, heb je dan niet alles terug ?

Jawel, maar de complexiteit van die functies zorgen ervoor dat die functies meer ruimte kosten om op te slaan dan die pixels zelf.
Of je moet net mazzel hebben en een overduidelijke lijn/vectortekening hebben, zodat je steeds hele rijen pixels tegelijk kan "vangen" met 1 simpele line. Maar ten eerste is dat bepaald niet makkelijk om te detecten, en bovendien gaat het voor de meeste foto's niet op waardoor je dus geen ruimte bespaart.