Mega Image database met alle mogelijke beelden erin

[Benjamin23]

Stel je voor:

Je laat een computer alle mogelijke beelden creeeren voor een scherm van 320x420 pixels en een kleurendiepte van 256 (daar krijg je beste scherpe foto's mee)

Hoeveel combinaties zijn er mogelijk???

En bedenk eens wat er allemaal te vinden is in die database!
Er zijn waarschijnlijk meer combinaties mogelijk, dan er nu in het heelal zijn!  
Want een melkwegstelsel in de vorm van je naam. Zou dat bestaan?  

Uiteraard zit er ongeloofllijk veel ruis tussen, of beelden met een gedeelte ruis, maar het lijkt me wel cool om door de imagedatase te mogen scrollen!

Echt alles is mogelijk!
Denk aan:
-Jezelf met 3 armen
-Jezelf met 19 ogen
-Een planeet met 2 manen, 3 manen of 1000 manen
-Jezelf omringt door 20 mooie vrouwen, of 21 lelijke, of 22 aliens!
-De nieuwste gadgets
-etc en nog oneindig veel meer keer etc.!  

[frokamel]

wow...dat is wel cool ja!

[sparky]

Daar staan foto's bij, die de prive wel zou willen hebben!
Iedereen doet het met elkaar op een aantal van die foto's!

Gaat dat niet in tegen de wet van privacy!  

[Digihans]

Complete film op een diskette?
(ook gepost op tweakers.net, n.a.v. datacompressie verhaal van  Jan Sloot)

Het kan wel (complete film van +/- 2 MB!)

Om de compressie ratio te halen, maak je eerst een Mega De-Compressie Database, met daarin alle mogelijke beelden die er zijn.

Stel je hebt 640x480 pixels, met een kleurendiepte van 256 kleuren, dan heb je  het totaal aantal beelden = een antwoord met iets van 1500 nullen!!!
Met de huidige datadichtheid van hardeschijven, zit je dan op een fysieke grootte van een behoorlijk  sterrenstelsel. !!!

Maar ...Als je alle plaatjes hebt, kun je ieder beeld aanroepen door het nummer  op te geven.
dus 1 beeld 1500 tekens lang  is 1.5 kilobit groot! = 0,2 KByte ! (met huidige compressie technieken, kun je dat getal nog wel kleiner krijgen ook)

Een videofilm van 20 frames per seconde, en 5400 seconden lang (1.5 uur) bevat 10800 beeldjes
Daaruit volgt: 10800 x 0,2 KB per beeldje= +/- 2 MB

Een film past dan dus echt bijna op 1 diskette

Helaas zijn er een aantal nadelen:
1. De fysieke database is ENORM! (letterlijk lichtjaren groot!)
2. Het terugvinden van een beeldje duurt eeuwen, zoniet duizenden of zelfs miljoenen jaren
3. De database bevat grotendeels (signficant afgerond op 1500 nullen) alleen maar ruis (de rest is bruikbare beeldjes)

Voordeel:
1. Je film past op 1 diskette
2. De Database bevat alle foto's die kunnen bestaan.  (dus jij met 3 vrouwen , 4 vrouwen, 1 boom, 2 aliens, een stukje ruis, een halve arm, etc. )

Als je door die database mag spitten, kom je (naast alle ruis) dus echt de meest rare en bizarre beelden tegen... maar ook digital foto's die al een keer zijn gemaakt zitten in die database.
Je kan het zo gek niet verzinnen, of het staat ergens op een plaatje!

artikel op tweakers.net: revolutionaire datacompressietechniek van Jan Sloot

[Johan Claes]

stel:
je wil 10 pixels kleuren met 256 kleuren
256 kleuren wil zeggen 8 bits (1 byte) om alle mogelijkheden te maken..
dus voor 10 pixels heb je 10 byte nodig

Stel dus dat je iedere combinatie een nummer geeft, dan ga je net zoveel
getallen hebben als je in 10 bytes kan steken.

Neem dan die foto van jezelf met 3 armen en save hem als uncompressed bitmap (basically save je dan voor iedere pixel de kleurwaarde, en dat voor alle pixels achter elkaar), lees dan de hele file als 1 getal, en je hebt het nummer van het plaatje in de megadatabase.

Dit helpt dus niets

[bashanna]

je wil 10 pixels kleuren met 256 kleuren
256 kleuren wil zeggen 8 bits (1 byte) om alle mogelijkheden te maken..
dus voor 10 pixels heb je 10 byte nodig

Dit snap ik nog...

Stel dus dat je iedere combinatie een nummer geeft, dan ga je net zoveel
getallen hebben als je in 10 bytes kan steken.

Dit niet...

Het aantal combinaties met 10 pixels en een kleurendiepte van 256 is al behoorlijk enorm

rood - rood - rood - rood - rood - rood - rood - rood - rood - rood
rood - rood - rood - rood - rood - rood - rood - rood - rood - iets minder rood
rood - rood - rood - rood - rood - rood - rood - rood - rood - nog iets minder rood
rood - rood - rood - rood - rood - rood - rood - rood - rood - oranje

om dus alleen de combinaties met 9 x rood en een andere kleur te maken heb ik als 256 combinaties.
Ik wil niet eens gaan rekenen aan het totaal combinaties van 10 pixels.

Dat past never nooit niet in 10 byte.

 
De manier van Digihans klopt wel redelijk. alleen maakt hij een rekenfout met bits. Dat moet bytes zijn. Zijn oplossing wordt dan 8 zo groot = +/- 16 MB voor een complete film.

[Bram Wouters]

Volgens mij wordt het aantal bytes: (256^[aantal pixels] ) / 256
Bij een resolutie van 640x480=307200 wordt dit een onvoorstelbaar groot getal.
Bij een resolutie van 160x120=19200 pixels krijg je al een getal (database) van meer dan 45.000 cijfers... 

[HJ]

Beetje zinloze discussie dit...

Je kunt immers simpelweg niet meer informatie in minder stoppen.

Om het verhaal van Johan Claes iets duidelijker te maken:

Stel je voor dat je een zwart-wit plaatje hebt in 640x480.
Het totale aantal pixels dat je dan hebt is 307200.
Om alle mogelijke combinaties van dit plaatje weer te kunnen geven heb je 307200 / 8 = 38400 bytes nodig. Dat komt al neer op 37,5 Kb. (Je kunt dit controleren met bijv. MS Paint, maak een plaatje van 640x480 en sla het op in zwart wit bitmap formaat --> resultaat: een 37,5 Kb file)

Dat je een plaatje kleiner kunt maken qua formaat (bijvoorbeeld met JPEG) komt doordat er dan compressie technieken op worden toegepast. Hierdoor kunnen echter 2 (heel iets) verschillende plaatjes in JPEG precies dezelfde codering hebben omdat meer informatie in minder moet worden opgeslagen.

Ik hoop dat dit nog een beetje te volgen is, maar wat ik wil zeggen is dat als je een zwart-wit plaatje van 640 bij 480 wilt opslaan waarbij je zeker wilt weten dat er geen informatie verloren gaat, dat je dan ALTIJD minimaal 37,5 Kb nodig hebt.

Ditzelfde principe geldt ook als je plaatjes uit een database wilt zoeken. Als je alle plaatjes die mogelijk zijn, dus 2^307200 want elke pixel kan of zwart of wit zijn, in een database stopt, dan heb je alle getallen van 0 t/m 2^307200 nodig om deze plaatjes terug te vinden in de database. En om deze getallen op te slaan heb je  :)verrassing:) 37,5 Kb nodig.

En nu we toch bezig zijn kunnen we meteen de mythe van Jan Sloot even uit de wereld helpen. Het kan gewoon simpelweg niet zo zijn dat een complete film op te slaan is in 1Kb (oid), gewoon omdat het aantal combinaties simpelweg te groot is. Je hebt immers al 37,5 Kb nodig voor een simpel zwart wit plaatje van 640 bij 480. Ga zelf maar na hoe groot de film zal worden met 30 beeldjes per seconde en dan ook nog eens in heel veel kleuren! Dat DivX en alle andere codecs dit enorme aantal bytes iets terug weten te dringen komt simpel doordat ze minder bytes proberen te gebruiken. Het gevolg is dan dat niet alles uniek en precies zoals het oorspronkelijk was wordt afgebeeld --> kwaliteitsverlies.

Ik snap eerlijk gezegd dan ook niet dat zelfs Netwerk hier aandacht heeft besteedt en dat zoveel topbedrijven hier ingestonken zijn.

[Digihans]

Ditzelfde principe geldt ook als je plaatjes uit een database wilt zoeken. Als je alle plaatjes die mogelijk zijn, dus 2^307200 want elke pixel kan of zwart of wit zijn, in een database stopt, dan heb je alle getallen van 0 t/m 2^307200 nodig om deze plaatjes terug te vinden in de database. En om deze getallen op te slaan heb je  :)verrassing:) 37,5 Kb nodig.

Dus om alle plaatjes in zwart wit weer te geven heb je 37kb nodig?

Dan heb je toch een super compressie! Daar teken ik wel voor!


Nog 1 keer:

Een beeld van 2x2  met zwart wit geeft 16 combinaties

01. WWWW
02. WWWZ
03. WWZZ
04. WZZZ
05. ZZZZ
06. ZZZW
07. ZZWW
08. ZWWW
09. ZWWZ
10. WZZW
11. ZWZW
12. WZWZ
13. WZWW
14. ZWZZ
15. ZZWZ
16. WWZW


normaal zou een filmpje van 10 beelden bestaan uit 10x4 pixels  = 40 byte
Nu kun je gewoon zeggen : speel de volgende beelden af:
01 - 03 - 12 - 06 - 15 - 08 - 14 - 09 - 02 - 07
of korter (met fixed length scheiding)
01031206150814090207  (dit getal is slecht 20 tekens lang = 20 byte
--> compressie ratio = 20/40  = 1/2 (=50% van oorspronkelijke formaat)


Als een filmpje van 10x10 pixels met 8 kleuren hebt, krijg je dus 10.000.000.000.000.000 combinaties
Normaal zou een filmpje van 20 beelden dus 20 x 100 = 2000 byte

Met deze vorm van 'data restructurering' , heb je voor het aanroepen van ieder beel een getal tussen de 0 en 10 triljard nodig = 17 posities
20x17 = 340 byte
-> compressie ratio = 340/2000 = 17/100 = 17% van oorsrpronkelijk formaat

Als je een filmpje van 100x100 met 256 kleuren (aantal combinaties is een getal met iets van 1000 nullen (1000 posities))
Normaal zou een filmpje van 20 beelden 20 x 10.000 zijn  = 200 Kbyte

om een filmpje op te slaan hoef je nu alleen maar de sequence aan te geven voor iedere beeld heb 20 x 1000 = 20 Kb
-> Compressie ratio = 20.000/200.000 => 1/10 = 10% van oorspronkelijke formaat

De compressie ratio wordt dus steeds groter. (zal wel een limiet aan zitten)

Het probleem is dat al die beeldjes niet opgeslagen kunnen worden.
Om de film uiteindelijk te bekijken is dataverkeer natuurlijk wel gewoon 20x 10.000 = 200Kbyte (+ het versturen van de 20 Kbyte aan data)

[Digihans]

Het grappige aan de mega image database is denk ik het bladeren er doorheen.
Ieder beeld kan worden gegenereerd door een computer. Er komt geen licht meer aan te pas.
Als je de image-database patenteerd, heb je de rechten over elke foto en ieder stukje film wat er bestaat.
Je haalt ook gelijk een hoop privacy wetten overhoop, omdat je de raarste en naarste foto's van iedereen bezit. Tussen de foto's zit namelijk ook een hoop porno, en andere ranzige beelden.

Een stuk tekst is ook maar gewoon een combinatie van wit/zwarte pixels. Dus ook alle teksten (boeken, recepten, nieuwsberichte)  liggen al vast in de image database

Ook de oplossing van alle problemen staan in de imagedatabase beschreven.
Muziek is ook te herleiden tot zwart wit puntjes (noten of midi instructies)

Dus de imagedatabase is ook gelijk de grootste muziek database

3D objecten kunnen ook omschreven worden door tekst of vector instructies. Dus iedere object van iedere substantie staat ook al in deze database.

Chemische formules en verbindingen?  Geen probleem... alles ... maar dan ook echt alles staat in de Image database.

De vraag is: Hoe 'veel' of 'weinig' informatie heb je nodig om alles eruit te halen.
met 640x480 en 256 kleuren kom je een heel eind.
Met 320x240 en 80 kleuren kom je ook een heel eind

Waar ligt de limiet? of .. hoe groot moet de image database worden?
Je zou een beeld ook nog op kunnen delen in sectoren. en alleen de mogelijke combinaties voor een 'kleine' sector op slaan. Maar hiermee maak je de compressie minder. totdat je uiteindelijk weer op de 1/1 per pixel combinatie zit.

Een afweging tussen kleurendiepte, opsplitsing in sectoren, pixeltotaal zal leiden tot een ideale grootte van de database.

Als er anti ruis filters worden toegepast, kun je een hoop 'zinloze' informatie er uit filteren. (het merendeel is namelijk gewoon een random BREI van kleurenpixels, die niets zinnigs laten zien.
Ook beelden die teveel op elkaar lijken (omdat er maar een paar pixels veranderd zijn) zouden er uitgefilterd moeten worden.

Om de compressie nog groter te maken kun je de getallenreeksen gewoon comprimeren met speciale priemgetal reeksen of andere rekenkundige vereenvoudigingen.

Stel je hebt een getal  3802922510000864932319225
dan kun je:
-38025 schrijven als 195² + 4
-255 schrijven als 15²
-10000 schrijven als 100²
-8649 als 93²
-32319225 als 5685²

 

[HJ]

Dus om alle plaatjes in zwart wit weer te geven heb je 37kb nodig?
Dan heb je toch een super compressie! Daar teken ik wel voor!

Nee, wat ik wilde zeggen is dat je om èèn plaatje op te zoeken in de database een getal nodig hebt dat zo groot is als het plaatje zelf.

01031206150814090207  (dit getal is slecht 20 tekens lang = 20 byte

Verder klopt je redenatie niet helemaal, denk dat dat komt doordat je bits & bytes en binaire & decimale getallen een beetje door elkaar haalt.

Ten eerste wordt een bit gedefinieerd als een 0 of een 1, ofwel aan/uit, wel/niet, zwart/wit etc.
Een byte daaropvolgend is 8 bits. In èèn byte kun je dus acht pixels zwart of wit definieëren. Maar dat terzijde.

Om het voorbeeld hieronder een beetje simpel te houden zal ik rekenen met bits:
10 beelden van 4 pixels zwart of wit zou normaal dus 40 bits nodig hebben.
Echter, en nu komt het: om het getal 16 in binaire getallen te schrijven heb je vier bits nodig.
Dit komt omdat 16 = 2^4, dus om met nulletjes en eentjes het getal 16 te schrijven heb je 4 plaatsen nodig ipv de gebruikelijke 2 in het decimale stelsel.

Dus om dan weer een filmpje van 10 beeldjes te maken heb je weer 10 x 4 = 40 bits nodig. 

[Digihans]

en 100 beelden van 64 pixels = 6400 bits

om deze beeldjes aan te roepen heb je 100 cijfers van 4 karakters lang nodig = 400 bytes = 1600 bits. Dat is dus een verschil van 4800bits!

Hoe groter de plaatjes, hoe meer compressie er te behalen valt!

[Guru Evi]

Om even Digihans voorbeeld terug te halen:

Een beeld van 2x2  met zwart wit geeft 16 combinaties

01. 0000
..
16. 1111


normaal zou een filmpje van 10 beelden bestaan uit 10x4 pixels  = 40 bit (een pixel is maar 1 bit in jouw voorbeeld)
Nu kun je gewoon zeggen : speel de volgende beelden af:
01 - 03 - 12 - 06 - 15 - 08 - 14 - 09 - 02 - 07
of korter (met fixed length scheiding)
01031206150814090207  (dit getal is 20 tekens lang = 20 byte).

Hmm. klein verschil eh. Ik heb het ook proberen uit te zoeken en zo werkt het niet want zelfs al kort je het in bit-wise:

0000 - 0000
0001 - 0001
0010 - 0010

Zie je: om een gigantische imagedatabase te hebben moet je al evenveel data gebruiken voor datapointers als je data hebt. Natuurlijk kan je je datapointer compresseren maar dan kun je evengoed je data compresseren.

Wat je wel zou kunnen doen is een gigantische database van alle reeds bekende images te hebben en dan pointen naar iedere image. Dan kom je natuurlijk met het idee van een centrale database met alle data van iedereen en alles en dan moet iedereen ofwel de database alle dagen updaten en dat gaat dan evenveel of meer bandbreedte verbruiken dan vb. het filmpje dat je probeert te bekijken ofwel krijg je dan een redelijk ingewikkelde query die dan image per image van je filmpje gaat downloaden waarna je evenveel bandbreedte gebruikt hebt als voordien + je query. Het voordeel is dat je query hoogstwaarschijnlijk wel op een diskettje past. Je kunt natuurlijk ook wel een database hebben die de veranderingen tussen de verschillende images opslaat voor een bepaalde sequence en dat is een soort van compressie. Als ik me niet vergis gebruikt MPEG dit oa. voor compressie.

Ik denk dat het filmdiskettje onmogelijk is (wiskundig) behalve misschien door het gebruik van quantumtechnologie (wat ik nog maar begonnen ben).

[Robert]

Snap ik het nou ook niet, of zie ik wat over het hoofd??

Wat ik hier zie is een soort Midi formaat voor beeld.
Met een midifile kun je een muziekstuk tot gehoren brengen. Het midiformaat is veel kleiner als het uiteindelijke 'geluid' dat ermee geproduceerd kan worden.
Externe apparaten (synthesizers) produceren het uiteindelijke geluid.
In dit image-verhaal is de synthesizer een apparaat zo groot als een sterrenstelstel 

stel ik moet van een fullcolor plaatje (640x480)de 256 kleuren bijhouden dan krijg je dus een reeks van 307200 kleurcode-tekens achterelkaar. Dat is veel meer dan het plaatje aanroepen met een fictieve volgende combinatie: 2.832.947.285.017.562

Dus:
- een plaatje opslaan van 640x480 = 307200 pixels waarbij je van iedere pixel een kleurcode moet onthouden.
- een plaatje aanroepen uit de 'mega image database' is slechts een getal van 15 digits.

Uiteraard moet het plaatje dan nog naar de eindgebruiker worden verstuurd. En daar win je niets.
Maar de sequence voor de plaatjes is veel kleiner.

Om het zoeken in de database te vergemakkelijken kunnen de plaatjes worden gecatogoriseerd.
Bijvoorbeeld:
-plaatjes met overwegend rood, geel of blauw
-plaatjes met levende wezens
-plaatjes van object groter of kleiner dan...
-plaatjes met overwegend ... moleculen/atomen
-plaatjes met een lichtopbrengst van minimaal... lumen
-etc.

[alcortm]

...
stel ik moet van een fullcolor plaatje (640x480)de 256 kleuren bijhouden dan krijg je dus een reeks van 307200 kleurcode-tekens achterelkaar. Dat is veel meer dan het plaatje aanroepen met een fictieve volgende combinatie: 2.832.947.285.017.562

Misschien begrijp ik je niet goed, maar volgens mij is het aantal mogelijke plaatjes van 640x480, met 256 kleuren per pixel, gelijk aan 256^(640*480). Dat is een heel groot getal, waarvoor je precies 307200 bytes nodig hebt om het op te slaan. Geen compressie dus.

Neem als voorbeeld een plaatje van 16x16 pixels, met 256 kleurwaarden.

Daarmee kun je 256^(16*16) = 3.231700607131100730071487668867e+616 vershillende plaatjes maken (een getal met 617 cijfers).

Om die allemaal te kunnen indexeren, heb je een getal nodig van:
log(3.231700607131100730071487668867e+616) / log(2) = 2048 bits = 256 bytes.

Voor het ongecomprimeerd opslaan van het plaatje is nodig: 16*16 = 256 bytes.
Compressieratio = 1:1. Nog niet een bit winst dus...

[alcorhythm]

Dit onderwerp doet me denken aan een oud hersenspinsel waar ik ooit eens over nagedacht heb:

Met vier bits kun je 16 verschillende combinaties maken (2^4 = 16).

Vier tokens, kun je op 24 verschillende volgordes leggen (4! = 24).

Ergens zit daar voor mijn gevoel een compressie mogelijkheid in verscholen, of anders een efficiente opslagmethode. Als je je bijvoorbeeld een medium voorstelt waarop je 'tokens' kunt wegschrijven (bijv kleuren, of magnetische patroontjes, of verschillende vormen 'gaatjes') in plaats van alleen maar bits, dan kun je met een combinatie van 16 tokens al 20922789888000 verschillende volgordes maken, terwijl je met 16 bits maar 65536 combinaties kunt maken... meer data op hetzelfde oppervlak zeg maar.

Maar ja... als het zo makkelijk was, was het vast al wel gedaan   

[Guru Evi]

alcorhythm: dit zou inderdaad kunnen maar dan ga je over naar analoge opslag. Analoog kunnen er natuurlijk meerdere levels opgeslaan worden op de plaats van een 1 of een 0. Je kunt ook een harde schijf maken imho die verschillende levels van magnetisme opslaat (meer dan 2) en dat is bijvoorbeeld lang gebruikt geweest in tapes.

Het probleem die 2 posts daarboven staat over een MIDI-formaat voor images:
MIDI heeft geen informatie hoe de muziek uiteindelijk klinkt. Als iemand een muziekstuk maakt in MIDI, staat er bij welk instrument gebruikt en welke noten er gebruikt worden maar de uiteindelijke muziek moet gemaakt worden door een synthesizer die dat bepaald instrument heeft. Je kunt zelfs 100-en verschillende library's kopen/krijgen over hoe een vleugel klinkt of je eigen vleugel opnemen en omzetten naar een library in MIDI en die klinken allemaal anders.

Ik denk dat voor images het echte werk zit in compressie. Bij muziek kun je vb. de dingen die je niet hoort en gemaskeerd worden verwijderen en zien als een degelijke compressie (MP3), het probleem met images is dat we de volledige image zien en er niets gemaskeerd wordt omdat er geen levels (diepte) is in een 2d-oppervlak. Een 3d-image bijvoorbeeld gemaakt in Maya van een bepaald zichtpunt gezien kan gecompresseerd worden door de dingen die niet gezien worden te verwijderen uit het eindformaat zodat je een 2d-oppervlak terug hebt en nog steeds zul je dezelfde informatie hebben als het originele zichtpunt van de 3d-image. Je kunt ook beginnen blurren en een rij pixels wegnemen en dan de viewer de tussenliggende punten laten herberekenen of een constante inkorten en dat wordt dan ook gedaan door veel compressietechnieken.

Om een vernieuwende compressietechniek te verkrijgen zul je je helaas wel even moeten verdiepen in de gerelateerde (hogere) wiskunde en zoiets uitvinden. Kijk bijvoorbeeld naar de open source voorbeelden (PNG) en misschien kun je iets verbeteren eraan.

[merkator]

het bladeren in die database lijkt me wel bijzonder interessant!
Vooral als alle ruis eruit is gefilterd en de computers kunnen herkennen wat er op een afbeelding staat.
Dan kun je intypen ik wil zus en zo zien, met dit en dat. en flop.. in je visuele cortex geimporteerd (of gewoon nog ouderwets op je netvlies peprojecteerd) 

[Robert]

alle mogelijke uitvindingen zitten ook in die database. Je moet alleen even scrollen om de nieuwe I-Pod of Zune opvolger te vinden.

[Compact]

Stel je voor:

Je laat een computer alle mogelijke beelden creeeren voor een scherm van 320x240 pixels en een kleurendiepte van 256 (daar krijg je beste scherpe foto's mee)

Hoeveel combinaties zijn er mogelijk???

En bedenk eens wat er allemaal te vinden is in die database!
Er zijn waarschijnlijk meer combinaties mogelijk, dan er nu in het heelal zijn! 
Want een melkwegstelsel in de vorm van je naam. Zou dat bestaan? 

Uiteraard zit er ongeloofllijk veel ruis tussen, of beelden met een gedeelte ruis, maar het lijkt me wel cool om door de imagedatase te mogen scrollen!

Echt alles is mogelijk!
Denk aan:
-Jezelf met 3 armen
-Jezelf met 19 ogen
-Een planeet met 2 manen, 3 manen of 1000 manen
-Jezelf omringt door 20 mooie vrouwen, of 21 lelijke, of 22 aliens!
-De nieuwste gadgets
-etc en nog oneindig veel meer keer etc.! 

320 * 240 = 76800

Dat zijn dus 256^76800 mogelijkheden!
Maar het zou wel stoer zijn. Daar zitten waarschijnlijk ook de mooiste vrouwen tussen!
Maar het idee vind ik wel een beetje vaag, want ik zou denken dat er oneindig veel mogelijkheden zouden zijn. Maarja, de mens kan zulke grote getallen niet bevatten.

[edit]In bmp zijn dat 8,2 * 10^36630 terrabytes

[Mathijs]

een kleine rekensom

320x240=76800 pixels (75kilopixels)
deze kunnen elk 256*256*256 of 256^3 = 16777216 verschillende kleuren hebben (24bits)
In totaal dus  16777216^76800 = ...(heel veel)... mogelijke plaatjes.

Ik heb als programmeur hier natuurlijk even snel een programmatje voor gemaakt, dat zo'n plaatje genereerd, en dit 200% vergroot als GIF plaatje afbeeldt. Zie http://mathijs.serveftp.net:85/rommel/phpdraw.php
(bij elke refresh bedenkt hij een nieuw plaatje, er wordt niks opgeslagen)

[Digihans]

ik zie alleen maar steeds een zwart vlak

[Mathijs]

Sorry, ik ben er wat mee gaan spelen en op dit moment doet hij het niet helemaal. Ik zal een werkende versie achterlaten en op een andere pagina gaan experimenteren

Voor de geïnteresseerden:

Code: [Select]

<?

// set the size of the image
$imgWidth=320;
$imgHeight=280;

// send headers to browser
header("Content-type: image/gif");

// allocate memory for image
$image=imagecreatetruecolor($imgWidth, $imgHeight);

// fill image with random color pixels
for ($i=0; $i<=$imgWidth; $i++){
for ($j=0; $j<=$imgHeight; $j++){
imagesetpixel ($image,$i,$j,imagecolorallocate($image,rand(0,255),rand(0,255),rand(0,255)));
}
}

// display image
imagegif($image);

// clear image from memory
imagedestroy($image);

?>

[Vredenburg]

Leuk voor een psychologische test, maar al refresh je je hele leven zo'n pagina, never nooit niet dat je een compleet beeld gaat zien!

Er zouden eigenlijk meer 'algoritmes' bij geschreven moeten worden om kleurvlakken en vorm/contrast-lijnen te tekenen.

Een simpele truc kan zijn:"laat 1 kleur overwegend terug komen"
Maar dan nog, krijg je een vlak in een bepaalde kleurtint met allemaal randompuntjes die nog steeds duiden op ruis.

[sparky]

Hier een beeld toen ik refreshte!
Het lijkt ook echt ergens op 

[Mathijs]

Mijn uitgebreidere versie komt al dichter in de buurt:
http://mathijs.serveftp.net:85/rommel/draw.php?width=75&height=75&blur=4&zoom=4&greyscale=1
Hier kun je af en toe nog wel wat dingen in zien, zoals je ook in wolken etc. wel eens hebt.

overigens kun je zelf met de width, height, blur (niet te hoog zetten), zoom (is per 100%) en greyscale (0=kleur,1=z/w) spelen.

[dmeijering]

Het idee is opzich heel erg leuk, alleen je er zal zeker veel tijd inzitten om het te realiseren. Sowieso zou je het genereren van de plaatjes in stukken moeten opdelen, indien je alle mogelijke combinaties wil uitvoeren. Dus stel je neemt 1.000 computers en op elke computer worden 25 Threads gestart die allemaal een eigen stuk uitvoeren en de images dus genereren. Dit duurt wel "ff" maargoed het is opzich nogwel te doen lijkt mij. Het grootste probleem is gewoon het opslaan, want het is zeker een hele hoop data waarvan waarschijnlijk 60% bull is en je dus helemaal niet hoeft op te slaan. Daarbij moet je alles ook nog filteren op ruis en categoriseren zodat het ook nog terug te vinden is, dit lijkt mij lastiger te programmeren dan het daadwerkelijk genereren van de images.

Wat ik zo snel even kan bedenken qua compressie is dat je bij elke pixel opslaat of de aangrenzende pixel ook dezelfde kleurcode heeft, dan hoef je die code in ieder geval niet nog een keer op te slaan, dus stel je hebt 5 pixels rood naast elkaar, dan hoef je inplaats van 5 pixels maar 1 pixel op te slaan in je database. Als je dit doet moet je natuurlijk wel zelf iets schrijven wat uiteindelijk de pixels wel goed neerzet als ze opgevraagd worden door de gebruiker. Verder zou je sowieso gebruik moeten maken van gzip of iets dergelijks bij het opslaan in de database.

[Cornelisman]

stel: het lukt je. en dan? de rest van je leven plaatjes scrollen? het nut van zowel de database als de discussie is ver te zoeken. noem het dan: over pixels en plaatjes ofzo

[merkator]

Als die die database er is, kun je met OCR, gezichtsherkenning, patroonherkenning en een vleugje AI een hoop informatie uit deze database halen. Het is immers de grootste database met eigenlijk alles erin. Door dergelijke slimme filters toe te passen, krijg je een soort subset met meer realistische gegevens.
Maar inderdaad. . het nut zie ik ook niet helemaal, maar het is wel leuk om er over na te denken

[Digihans]

Ik heb laatst de broncode van Jan Sloot gelezen.
Wat hij beschrijft is dus geen compressie methode maar een codeer/decodeer algoritme.

Helaas weet niemand hoe dit zit.

[Rudy_x]

De benodigde computercapaciteit om alle beelden van een beetje redelijke grootte te genereren is enorm. Daarom zal dit in de praktijk nooit werken, en zelfs een theoretische supercomputer die deze beelden maakt sinds het ontstaan van het heelal zou op dit moment alleen alle plaatjes hebben geproduceerd die erg klein zijn.

Er is namelijk een theoretische bovengrens hoe snel computers kunnen werken. Zo is bijvoorbeeld de maximale capaciteit van een computer met een massa van 1 kg en een volume van 1 liter ongeveer 5 x 10^50 operaties per seconde. Stel dat sinds de geboorte van het heelal, bijna 14 miljard jaar geleden, alle massa in het waarneembare heelal is gebruikt voor een computer die de beelden maakt. Dus geen heelal met sterren, planeten, melkwegstelsels etc., het heelal is in dit geval een gigantische computer dat niets anders doet dan het genereren van deze plaatjes. Het blijkt dat deze computer ongeveer 10^120 operaties sinds het ontstaan van het heelal heeft kunnen uitvoeren. We nemen aan dat bij elke operatie van deze computer een nieuw plaatje ontstaat.

Gaan we uit van plaatjes met een kleurdiepte van 8 bits, dan heeft deze computer sinds het ontstaan van het heelal alle beelden kunnen genereren met een grootte van  slechts 7 x 7 pixels! Bij een kleurdiepte van 24 bits is dit slechts 4 x 4 pixels...