Student claimt 256GB-opslag op A4-velletje

@ junkbuster

het gaat om dat zelfde A4'tje en dat is hooguit een bestand van 1900xnogwat en dat kan gewoon als JPG opgeslagen zijn.
zo als je dit opent krijg je gewoon een wirwar van kleurtjes te zien, maar als je hem met een bepaald progje inleest, dan is het wel die 300GB

Jaja, als JPG nog wel. Dat zou handig zijn. Hahaha. Denk na man.

Je kan die jpg bestanden daarna uiteraard weer met dezelfde techniek opslaan op een A4'tje. Dan krijg je nog betere compressie en door hetzelfde jpegje een paar keer op te slaan op hetzelfde A4'tje krijg je ook nog redundancy. als er dan een kop koffie overheen gaat of een sukkel zet de perforator er in heb je mischien nog steeds je data....

Ik denk dat ik alvast patent ga aanvragen op deze hoax

@ spaceboy

je had 'm er wel even bij moete vertellen dat jpg aan pixel-negotiation doet (ofwel van een pixel met waar 1 en 3 respectivelijk pixels maakt van 2 en 2 ) ....

nu klink je meer als flaim en dat lijkt me niet de bedoeling...

nouja alsof een printer zo nauwkeurig nano pixels zou kunnen afdrukken. Daar heb je dan wel een speciaal apparaat voor nodig.

Oké misschien zitten er wat fouten in maar dit is waar ik op uitkom.

Een A4 is ongeveer 100 inch².
Ik zal wat dingen gewoon aannemen.

We gebruiken een 1200dpi kleuren laser printer.
En een 2400dpi scanner (hogere res. Om lees fouten te voorkomen.

Om makelijk te rekenen het papier is pressies 10”x10”=100 inch².
Elke dot is 256 kleuren dat is dus gelijke aan een byte

Dan krijg je ongecomprimeerd +/-
((((1.200x10=12.000)X(1.200x10=12.000)=144.000.000byte)
/1024=140.625KB)/1024=137MB)

Je kan misschien het aantal kleuren naar 65536 16 bit = 2 byte verhooggen voor dat je het gevaar loopt op lees fouten, of de apparatuur te duur word en dan zit je op 300MB
Het kan wel natuurlijk nog wel hoger maar dan praat je over hele dure apparatuur (*)

Ik zie niet hoe je nog hoger kan komen zonder een algoritme dat alleen in theorie bestaat, zeker niet op 450GB tenzij het het befaamde compressie techniek van de overleden nederlander waar Roel Pieper in geloofd, maar mee gegaan is in het graf.

Of maak ik nu ergens een een fout ?

Hoe wel ik niet denk dat we aan 250GB of de 450GB van dailytech of de 90 to 450GB van arabnews zou kunnen komen.

Maar dan nog is de techniek wel interessant want 1cm² is nog steeds 4MB en kan op verschillende manieren gebruikt worden door een rainbow data blokje aan het einde te plaatsen b.v.

Tech/comp magazine (uitgebreide achtergrond info/ kleine programma's)
Documenten & rapports waar een hardcopy van bewaard moeten blijven.
Ect, ect.

*( kijk bv naar fotografen voor glossy magazine, die gebruiken nog steeds 36mm dia van wegen de hoogere resolutie, een gescande dia geeft een bestand van ongeveer 300.000.000 pixels @ 24 bit, maar zo een scan kost ongeveer 50 euro)

klinkt een beetje als het mega-image-database verhaal, dat gebruikt wordt om films mee te maken.
Een soort database die ieder mogelijke (jpg)-beeld bevat. Om later met een kortere index-code het complete beeld op te roepen.
Een film zou dan een sequence van nummers zijn, die corresponderen met de beelden in de database.

Een film zou dan een sequence van nummers zijn, die corresponderen met de beelden in de database.

Da's precies het Sloot-sprookje. Het probleem is dat wiskundig vastligt dat de index ZO groot moet worden dat je er helemaal nooit winst mee kunt behalen. (buiten hoe onmogelijk groot de tabel moet zijn, daar moet elke beeldje van elk nog te maken film zitten?)

Overigens werkt alle compressie met tabellen en indexeringen daarnaar, maar dan op kleine herhalende patronen.

Dat dat uberhaupt tot compressie leidt komt omdat de werkelijkheid zoals wij die waarnemen veel meer structuur bevat dan random data.

Tegelijkertijd kun je theoretische afbeeldingen (die voor je oog niks betekenen) maken die totaal niet te compressen zijn. Wij nemen die waar als ruis. (maar dat hoeft het niet te zijn, simpelweg omdat onze hersenen er geen structuur in herkennen)

Elk compressie algoritme heeft een bepaalde invoer waarop de uitvoer _langer_ moet zijn. Dit is theoretisch trouwens hartstikke makkelijk te onderbouwen. Een redenatie die iedereen moet kunnen volgen:

Stel de invoer is 2 bytes en de uitvoer is 1 byte van het compressie algoritme. Een byte heeft 256 verschillende mogelijke waardes. Dus er kunnen 256 unieke resultaten zijn van het compressie algoritme. Dat betekent dus dat gemiddeld elke invoer van twee bytes dezelfde uitvoer moet krijgen als 255 andere mogelijkheden.

Wat een lossless compressie algoritme doet is bepaalde soort data voortrekken. De som van alle mogelijke input permutaties zal altijd gelijk zijn aan de som van alle mogelijke output permutaties. Anders verlies je informatie die niet terug te winnen is en is de compressie dus niet losless.

Wat wil nou het geluk, wij kunnen echt informatie-volle data helemaal niet waarnemen. Wij kunnen uit zwaar gestructureerde data de structuur waarnemen. Zaken als beeld, geluid en muziek zijn veel wiskundiger dan wij vaak willen beseffen. Dat maakt dat we wel degelijk een lossless compressie algoritme voor muziek kunnen maken. Die alle muziek op aarde voortrekt, en zonder informatie verlies kleiner kan opslaan. Tegelijkertijd zou datzelfde algoritme bij volkomen willekeurige ruis een groter bestand moeten opleveren.

Als deze meneer een algemeen compressie algoritme heeft dat voor alle soorten data die wij dagelijks gebruiken kan compressen (wiskundige statistieken, muziek, beeld, kunst) dan dit algoritme de belangrijkste uitvinding in de hoek van AI zijn en niet compressie. Immers als het uit willekeurige data wiskundige verbanden weet te trekken in een acceptabele hoeveelheid tijd dat kan concurreren met onze eigen hersenen, dan is dat ook meteen de geboorte van echte AI. AI dat alles zelf kan leren: dat de werkelijkheid kan ontdekken door verbanden te trekken.

En dat is dan ook meteen het meest fascinerende aan informatica: het perfecte general-purpose compressie-algoritme en het perfecte leer-algoritme zal hetzelfde hetzelfde algoritme moeten zijn.

Ga er dus maar vanuit dat bla bla bla GB kunnen opslaan dmv compressie niks zegt als je niet weet wat de data was. Ik kan 3948293482 TB aan data (gevult met alleen maar nullen) in ieder geval met de hand lossless compressen tot 10 decimalen. Mijn supergecompresste bestand zou dan de volgende informatie bevatten:

3948293482

Mijn decompressor zou dat getal dat uitlezen en zoveel nullen wegschrijven.

Tada .. een compressie ratio van 1 op de 394829348,2 TB
Zonder te weten wat de data was, zegt een behaald resultaat qua compressie helemaal niks.

Als het nou Mp3's waren: dan was ik impressed. Als het DivX'jes waren dan was ik ook impressed. Als het .Wav's waren dan was ik al minder impressed. Als het een verzameling .raw foto's waren van hetzelfde voorwerp vanuit een andere hoek, dan ben ik totaal niet impressed.

Gij zult de wet der behoud van informatie gehoorzamen.

Het staat ook al in het bericht: in feite claimt hij een hele krachtige compressie, en de eerste compressie die zichzelf kan comprimeren moet nog gevonden worden
[edit]
Even voor de duidelijkheid: dat kan dus ook niet, als het wel kan dan zou je namelijk een ondeindige hoeveelheid data in 1 bit kunnen opslaan, en dat kan niet, zo dus:
Stel je hebt een compressie die er altijd 50% van af haalt:
5 MB -> 2,5 MB
2,5 MB -> 1,25 MB
1280 KB -> 640 KB
....
10 KB -> 5 KB
5120 B -> 2560 B
.....
10 B -> 5 B
40 b -> 20 b
...
5 bits

kan dus nooit

Homeopatishe compressie

Ongeveer dezelfde denkfout als het briljante idee van sommige beginnende PHP scripters die denken dat ze passwords extra veilig kunnen opslaan door er zo vaak mogelijk een hash van te maken. Dus de md5 [van de md5 van de md5...ad infinitum] van een password.

idd, er is altijd een hoeveelheid informatie, en er is een theoretisch maximum voor informatiedichtheid, wat niet overschreden kan worden. Deze is onafhankelijk van de inpakmethode, zolang deze binair blijft. Omdat de informatiedichtheid van een jpeg al tegen het maximum aanligt, heeft zippen geen enkele zin.

Grappig genoeg zijn de voorwaarden van de maximale informatiedichtheid gelijk aan die van totale random-informatie; in binaire zin komt 1 even vaak voor als 0, komen 00, 01, 10 en 11 even vaak voor, en ga zo maar door.

Wil je nog meer compressie, dan komt op een gegeven moment de 'informatie met max. dichtheid' in het compressieschema zelf terecht.

Ga maar na:
Ik maak een schema, waarin een 1 staat voor alle informatie op internet, en een 0 voor 'niks'. Dan kan ik het hele internet in een bestand van 1 bit weergeven, een goede compressie dus, alleen het algoritme moet dan heel het internet (daar was de 'informatie' dus gebleven )bevatten om terug te rekenen, dus uiteindelijk is de winst klein.

Tweede voorbeeld: Ik heb een film met 100.001 frames. Die nummer ik van 0 tot 100.000. Zodoende kan ik ieder frame weergeven met een getal, en de hele film met 100.000 getallen. Geweldige ongelofelijke datacompressie, maar het algoritme zal toch moeten vertellen hoe ik de getallen terugreken tot echte frames, dus de compressie is veel slechter dan hij lijkt.

In het geval van mensen die een enorme compressie claimen, zit er vaak een hele zooi info in het algoritme.

@Arakrys: nou dat is niet altijd een denkfout.
Waarom denk je dat 3DES veiliger is dan DES

@dtech, pfismvg e.a.:

jullie benadering van compressie is nogal "oldskool".
zoals in het bericht staat, wordt ook gebruik gemaakt van figuren, die groter zijn dan een paar pixels. en daar schuilt veel "compressiekracht" in.

figuren houden namelijk veel interpretatieve informatie in. dwz dat ze geometrisch misschien niet zoveel voorstellen, maar met een bepaalde uitleg heel veel kunnen betekenen. zo is een barcode is alleen maar een bende lijntjes, maar met een bepaalde interpretatie kan het een hele lijst aan gegevens betekenen. die barcode refereert dan naar een grotere verzameling data.
in de aanpak van deze student worden ook kleuren gebruikt. en hiermee kan ook zeer veel gerefereerd worden. het systeem hoeft niet eens binair, hexadecimaal o.i.d. te zijn. de vermelde speciale software zet het wel in een "standaard computertaal" om.
think out of the box

bij plaatjes zou een vector-interpretatie van beeldmateriaal een redelijke analogie zijn. een cirkel op een wit vlak opslaan in vectorformaat (oorsprong+straal) is zoals je begrijpt vele malen kleiner (en resolutievrij) dan zo'n figuur in een lossy/lossless bitmapformaat.

Wat enorm kortzichtig.. Mensen kunnen toch ook niet vliegen?

Waarom zou het niet als plaatje opgeslagen kunnen worden, en vervolgens weer kleiner afgedrukt worden, als er ergens bij vermeld wordt dat het bestand een plaatje is?

@Jimbolino

Dat gaat natuurlijk helemaal nergens over. Ten eerste is
3DES geen compressie maar een encryptie methode en 3DES is gewoonweg 'veiliger' omdat het 3x zo lang duurt om van decrypted -> encrypted te gaan. Dus een bruteforce duurt 3x zo lang, etc etc. Maw, DES is net zo veilig als de computer 3x zo traag is

namelijk een ondeindige hoeveelheid data in 1 bit kunnen opslaan, en dat kan niet

(Reactie op dtech)

Op zich kan je best een oneindige hoeveelheid data in 1 bit opbergen. Als je bij het bedenken van het compressie algorithme maar weet wat die data is.

Stel je een algoritme voor:

A ) als eerste bit==1 dan uitvoer = <oneindige tekst>
B ) anders volgt na deze bit de gewenste uitvoer

Dit compressie algorithme gebruikt dus voor 1 bekende oneindige hoeveelheid data precies 1 bit, en voor alle andere mogelijke data die je er mee comprimeert gebruikt hij precies 1 bit meer dan de invoer.

Dat is natuurlijk in de praktijk nutteloos (bovendien wordt je compressie programma dan oneindig groot) maar in oude encryptie algorithmen werden wel dergelijke trucjes gebruikt, door bijvoorbeeld veel gebruikte letters zoals de 'e' een heel korte bitcode te geven. Morse code doet dat bijvoorbeeld ook.

Maargoed dit is wel een beetje mierenneukerij hoor, want met de strekking van je post ben ik het verder wel eens

@Fireshade

Stel, je hebt een stukje papier van 8x8 pixels. We laten even kleuren buiten beschouwing, dan kan je daar in totaal 8x8 = 64 bits aan informatie opslaan. In totaal levert dan 2^64 mogelijke waarden op. In datzelfde stukje papier kan je dus 2^64 verschillende 'figuren' opslaan.

Je ziet dat het aantal mogelijkheden voor 'het uitlezen per pixel' en 'het uitlezen per figuur' exact hetzelfde is.

Nu gaan we een extra kleur toevoegen, je kan dan 3^64 'mogelijkheden' kwijt, of je het nu een 'figuur' noemt of 'een combinatie van pixels'.

Een figuur is ook eigenlijk niks meer dan een combinatie van pixels.

Het aantal mogelijkheden dat met een bepaald aantal kleuren op een bepaalde ruimte te maken valt blijft precies gelijk. Hoewel 'uitlezen per pixel' toch wel heel wat makkelijker te implementeren valt.

1 foutje in je redenering, een oneindige tekst bestaat toch niet...er is geen tekst die nooit stopt want dat zou nutteloos...en ook deze tekst moet ergens gesaved worden...waar dan? inderdaad in het bestand...

jullie benadering van compressie is nogal "oldskool".
<knip>
zo is een barcode is alleen maar een bende lijntjes, maar met een bepaalde interpretatie kan het een hele lijst aan gegevens betekenen. die barcode refereert dan naar een grotere verzameling data.

Die van jou ook, ALLE compressie werkt met verwijzingen naar vaker voorkomende reeksen die meestal met de compressie als tabel worden meegestuurd.

figuren houden namelijk veel interpretatieve informatie in. dwz dat ze geometrisch misschien niet zoveel voorstellen, maar met een bepaalde uitleg heel veel kunnen betekenen.

Je spreekt hierin jezelf tegen:

bij plaatjes zou een vector-interpretatie van beeldmateriaal een redelijke analogie zijn. een cirkel op een wit vlak opslaan in vectorformaat (oorsprong+straal) is zoals je begrijpt vele malen kleiner (en resolutievrij) dan zo'n figuur in een lossy/lossless bitmapformaat.

Eerst zeg je dat een tekening meer info dan de vectorinfo kan bevatten en daarna erken je dat het eigenlijk andersom is en een tekening van data dus juist MINDER compressie zal opleveren...

Als z'n compressie fantastisch werkt met geometrische figuren, dan is hij knap stom, want dan kan hij juist met de wiskundige vergelijkingen van die figuren de tekening weer opnieuw produceren en met die vergelijkingen dus NOG een betere compressie hebben.

Je begint aan de oplossing

Iedere "kleur" is eigenlijk niet meer dan een symbool, dus het aantal kleuren is het aantal atomaire symbolen, de oerdataeenheden, waarin alle data uitgedrukt moet worden. Door "kleur" in het verhaal te vervangen door "symbool" kunnen we dat deel alvast abstraheren.

Het velletje A4 kan, afhankelijk van de grootte van de inktdot (die weer afhankelijk is van spuitmond, papier en de resolutie van de scanner) een n aantal symbolen bevatten. Het velletje A4 is dus je datadrager, je medium. Hebben we ook het papier geabstraheerd.

We hebben nu dus nog een medium over waarop n keer één van m symbolen kan worden opgeslagen. Wil je op dit medium 250 GB aan data opslaan, dan zal n x m/256 (1 byte is 8 bit dus 256 symbolen) gelijk moeten zijn aan 250 GB (uitgaande van puur random data (niet te comprimeren)).

Is dit te doen? Uiteraard, immers, door inkt te mengen is in theorie een onbeperkt scala aan "symbolen" mogelijk. De beperking ligt hem slechts in de nauwkeurigheid van de spuitmond en de scanner. En daar ligt dan ook meteen de dooddoener voor deze techniek; de kans op corruptie is simpelweg veel te groot. Verkleuring, vouwen, niet volledig recht scannen, vuiltjes op de scanplaat, vervuiling van de spuitmond; het voorkomt allemaal dat de benodigde resolutie met enige betrouwbaarheid gehaald kan worden.

Alle lof voor deze innovatieve methode, maar ik ben bang dat er weinig van terecht zal komen...

Je beschrijft het aantal combinatiemogelijkheden, niet de opslagcapaciteit.
Op een CD kun je meer combinaties van bitreeksen plaatsen dan er atomen in het zichtbare heelal zijn. toch past er maar 650MB op. Dat komt omat er maar één bitcombinatie per keer op kan.

Op dit papier kan er volgens jou berekening met 63000 bits en 8 bits per byte ongeveer 8 KB opslaan (zwart/wit).

Op een andere manier gezegd:
In 8 bits (één byte) kun je 256 combinaties maken. Maar per 8 bit kun je toch maar één (ASCII) code opslaan.

^^ een CD werkt op een totaal andere manier. Daar staat redundante data op zodat de CD ook nog afspeelt als er bepaalde bits onleesbaar geworden zijn door krasjes enz

Een CD werkt op een heel vergelijkbare manier, alleen gebruikt het een deel van de ruimte voor foutcontrole. Dat doet niets af aan Xenan's punt: jouw berekening is fout. Het gaat niet om hoeveel *combinaties* van gegevens in een datareeks passen, maar hoe groot de datareeks is. Sterker nog, de cryptografie leunt op het feit dat het genereren van alle combinaties met een zeer korte lengte (bv. 128 bits) zo ontzettend lang duurt, dat het niet mogelijk is om al die combinaties af te werken (als je honderd miljard combinaties per seconde genereert, duurt het ongeveer 1E20 jaren om ze allemaal langs te gaan). Wou je nu beweren dat in 128 bits alle informatie op jouw harde schijf kan passen?

Even met jouw getallen een correcte berekening uitvoeren: als het 16-bits kleur ondersteunt en je hebt dus per 1mm2 16 bits opslagcapaciteit, is de capaciteit van een A4: 16 * 210 * 297 (niet exponentieel!), dus nog geen 1 Megabit (uitgaande van kantloos afdrukken). Je kunt ook kijken naar de gangbare maat van data-dichtheid: 16 bit/mm2. Harde schijven halen honderden megabits per vierkante mm (http://arstechnica.com/news.ars/post/20060605-6988.html), dus deze capaciteit stelt helemaal niets voor.

het gaat echt wel om "combinaties" hoor

je mag hieronder op elke x een 1 of een 0 invullen
hoeveel dingen kun je dan representeren ?
x x x x

en hieronder doe je hetzelfde, maar daar mag je de cijfers 1 t.e.m. 256 (aantal te gebruiken kleuren bv) gebruiken
hoeveel dingen kun je dan representeren?
x x x x


Zoals ik al zei dus. De achterliggende logica en conversiecodes (zoals ASCII codes) zetten de 4 plaatsen met elk een 1-256 waarde dan om in iets deftig.

Je snapt niet WAAROVER het hier gaat. Gewoon het noteren van data.
Zoals in het Nederlands:
wij schrijven "websitemaker" met 12 karakters, dus als we dat op papier zouden moeten printen, hebben we 12 eenheden nodig op ons papier. Als we nu het Chinese karaktersset (wat groter is dan onze 26 letters) gebruiken, is het woord "websitemaker" opeens maar 2 karakters groot. -> je kan gewoon meer printen in het Chinees dan in het Nederlands op eenzelfde blad
DAAROVER gaat het! Hoeveel krijg je op een blad. Cryptografie heeft hier niets me te zien enz.

OK. Stel ik heb 4 "hokjes" de ruimte: naarmate ik uit meer verschillende dingen kan kiezen per hokje, kan ik in die 4 hokjes meer spullen opslaan - tot zover zie je het goed. Niemand bestrijdt dat. De capaciteit kan ik echter blijven terugrekenen naar binaire capaciteit.
M.a.w. als ik voor elk hokje een 24-bits kleur kan kiezen, heb ik 4 * 24 = 196 bits aan datacapaciteit. Ik kan dezelfde hoeveelheid informatie ook kwijt in een lijst van 196 hokjes, waarbij in elk hokje een 0 of een 1 staat. In beide gevallen zijn dan 2^196 mogelijke combinaties van gegevens-eenheden, maar met dat getal kun je helemaal niets.

Het verschil is dat er van die kleine bit-hokjes honderden miljoenen per vierkante mm passen, terwijl grote kleur-hokjes misschien met z'n 100 per mm2 gaan. Stel ik heb 100 kleur-hokjes in 1 mm2: dat is 100 * 24 = 2400 bits (2^2400 combinaties voor jou). Op een harde schijf kan ik in dezelfde ruimte maar liefst een factor honderdduizend meer bits opslaan (ofwel 2^240000000 combinaties in jouw omslachtige rekenmethode). Zoals je ziet, kan de harde schijf veel, veel, veel meer combinaties opslaan dan papier op dezelfde oppervlakte, zelfs als ik aanneem dat elk kleur-hokje slechts 0.1 bij 0.1 mm klein is, wat veel kleiner dan jouw aanname is. Zelfs als je een kleur-hokje 0.01 bij 0.01 maakt (en dat is echt verdomd klein voor optische verwerking), reduceert het verschil tot een factor 1000 in het voordeel van de harde schijf.

Als een bit-hokje net zo groot was als een kleur-hokje, en een harde schijf dus 100 bits per mm2 kon opslaan, dan waren de kleuren interessant. Maar nu niet.

Je kunt wel koppig je eigen verhaaltje volhouden en denken dat je op een papiertje alle informatie in het hele universum kunt opslaan en dan nog flink wat ruimte overhoudt, maar het zou verstandiger te zijn om te lezen wat naast mij ook anderen uitgelegd hebben en daar iets van te leren.

Je zou toch ook alle data 2x op het papier kunnen opslaan. Halveert wel je opslagcapaciteit maar dan heb je een stuk minder kans op datacorruptie.

ublis je snapt het echt niet hé
Mijn HD van 500GB is kleiner dan een velletje papier jah. what's your point? Die kerel perst gewoon meer data op een velletje papier dan je eerst zou verwachten, that's all. Of dat de datadensiteit nu groter is op een HD of welk medium dan ook, who cares? Papier is lekker goedkoop i.t.t. je HD van 500GB. En 't is gewoon het principe.

Wat John probeert te zeggen is dat je voor BV Rood de binaire code 0111001100011100110 kan schrijven.
Voor Blauw is dat bv 1000111001001000111. Door nu Paars te nemen heb je dus de combinatie van Blauw en Rood dus een groter getal.
Zo kan je dus best heel erg veel comprimeren.
Als je dan bekijkt dat er oneindig veel kleuren/kleurencombinaties bestaan/mogelijk zijn dan begrijp je waarom het idee wat hierboven wordt beschreven misschien niet eens zo gek is.

Ik ben het er weer wel mee ens dat datacorrptie hier 1 van de grootste gevaren is. Zijn de echte floppy disks (5 1/4 ") al lang uitgefaseerd wegens te grote kans op datacorruptie doordat ze makkelijk gebogen kunnen worden etc dan gaan we nu zeker weer terug naar iets wat nog gevoeliger is voor dergelijke aanpak.

John Kruger

Die kerel perst gewoon meer data op een velletje papier dan je eerst zou verwachten, that's all.

Nee, dat is juist wat we hier aan het weerleggen zijn. Het is wiskundig onmogelijk.

Jij rekent steeds het aantal mogelijkheden uit, niet de capaciteit.

Een geheugenstik van 1 byte heeft een capaciteit van 1 byte, maar 256 mogelijkheden waarvan hij er steeds maar één tegelijk kan bevatten. Jij noemt deze stik van 1 byte een stik van 256 bytes.

Het is verder ook niet van belang naar welke 256 fantastische mogelijkheden het dan kan verwijzen uit een tabel.
-OF je moet die tabel elke keer meeleveren en je winst is dan dezelfde als een gewone compressie.
-OF je heb een vaste tabel die bij elke volgende film (of wat dan ook) nutteloos is omdat diezelfde 256 vaste reeksen niet voorkomen
-OF je hebt een gigantische onwerkbare database, waarbij belachelijke indexeringsgetallen nodig zijn die elke compressiewinst teniet doen.

k1n8fisher

Wat John probeert te zeggen is dat je voor BV Rood de binaire code 0111001100011100110 kan schrijven.
Voor Blauw is dat bv 1000111001001000111. Door nu Paars te nemen heb je dus de combinatie van Blauw en Rood dus een groter getal.
Zo kan je dus best heel erg veel comprimeren.

Totale onzin. Hoe weet je dan dan je daar oorspronkelijk weer rood en blauw als info uit wil krijgen? En niet gewoon paars? Daar is dus weer extra info voor nodig die de compressie weer teniet doet.

Het maakt niet uit of je over kleuren of bitcombinaties praat, heet gaat erom hoeveel verschillende waarden een bepaald deeltje of oppervlakte kan hebben. Daarna kan je het gewoon uitrekenen wat de capaciteit is. Harddisks doen dat op veel kleinere oppervlaktes dan printers.

Als je dan bekijkt dat er oneindig veel kleuren/kleurencombinaties bestaan/mogelijk zijn dan begrijp je waarom het idee wat hierboven wordt beschreven misschien niet eens zo gek is.

Een reeks van 100 bytes heeft ook een duizelingwekkend aantal mogelijkheden? Het kan zelfs alle mogelijke beginzinnen van elk boek van de wereld bevatten, zelfs van die nog niet geschreven zijn... Maar heeft nog steeds een totale capaciteit van slechts 100 bytes?

Wat hier steeds verward wordt is combinaties en capaciteit? Een dobbelsteen kan maar liefst 6 waardes bevatten maar je kan maar 1 waarde tegelijk mee gooien (bevatten). De capaciteit is dus 1, de mogelijkheden 6.

Het gaat om de hoeveelheid data een medium TEGELIJK kan bevatten, niet hoeveel mogelijkheden het in totaal aankan als je het oneindig mag beschrijven?

@ublis

Volgens mij moet jij heel snel je mond houden over crytografie. Je snapt er werkelijk niks van.

Er zit niet zoveel informatie opgeslagen in 128 bit dat je het niet meer kan berekenen.

De waarde in 128 bit key, is een eindige waarde.
Om einstein maar even te quoten:
- je hebt eindige telbare getallen
- je hebt oneindige telbare getallen
- je hebt eindige ontelbare getallen
- je hebt oneindige ontelbare getallen

Het feit dat sommige getallen niet berekenbaar zijn als resultaat van een bepaalde functie, betekent niet dat die getallen zelf niet heel klein kunnen zijn of dat ze opeens meer data bevatten.

In het geval van cryptografie, gaat het erom dat je de factor van een paar priemgetallen heel snel kunt uitrekenen. (het zijn immers gewoon vermenigvuldigingen). Aan de andere kant kun je gegeven het resultaat van die berekening niet makkelijk er achter komen welke priemgetallen gebruikt zijn.

Neem: 3 * 7 * 9 = 189
Om te ondekken welke priemgetallen je met elkaar moet vermenigvuldigen om 189 te krijgen zul je alle mogelijke combinaties van 1, 2, 3 etc. priemgetallen moeten proberen. De hoeveelheid mogelijkheden maakt dat dit al minstens een operatie'tje of 1000 is.

Het is die verhouding tussen algoritmische rekentijd van invoer naar uitvoer in vergelijk met de rekentijd van uitvoer naar invoer, waarop encryptie gebaseerd is.

Op geen enkele manier veranderd dit de informatie-dichtheid waarop je iets kunt compressen. Dat jij deze twee zaken bij elkaar haalt is bespottelijk.

Compressie werkt, net als een leeralgoritme, op basis van een aanname. Die aanname zorgt ervoor dat een bepaalde subset van invoer-data 'korter' wordt, terwijl een de complementaire subset van invoer-data langer wordt.

De som van alle mogelijke uitvoer (alle mogelijke invoeren) zal altijd groter of gelijk zijn aan de som van alle mogelijke invoer-permutaties.

Er zal voor elk compressor een bestand gemaakt kunnen worden, die meer ruimte inneemt dan oorspronkelijk.

Je zult waarschijnlijk een HD scanner en HD printer en A kwaliteit papier nodig hebben, maar zal denk (lees hoop) ik niet meer kosten dan een 250GB HDD.

Zou me niks verbasen dat door de techniek waarmee je papier kan hergebruik je ooit geen Blu-Ray-RW of HD-DVD-RW maar Papier-RW bij de computerboer kopen.

Papier-RW? Dat bestaal al !
nieuws: Toshiba ontwikkelt herbruikbaar printerpapier

@redstorm:

Stop nou eerst eens met steeds die Breezers(tm)(r) te drinken, wellicht kunnen we dan begrijpen wat je probeert over te brengen.

en *plop* dan ben je in 10 uur verlost van je digitale archief.
dat is trouwens ook nog monochromaal denk ik?

Redstorm: je weet toch dat een 250 gig HD maar 75 euro kost

...Met het verschil dat een vouw in een A4'tje die alles omgooit op een cd'tje niet kan...

Ooit wel eens een cd met vouw zien werken.?

Dan krijg je een blauw velletje met met de oorzaak van de corruptie

Het is nu TNT post hoor

oranje ipv. rood, vast een fout bij het uitprinten

waarbij ook meteen de belastingen zitten.


leuker kunnen ze het toch echt niet maken.....

BPOD
Blue Paper Of Death

@F5544

Dan krijgt het ontvangen van een blauwe evelop idd een hele andere betekenis.

@Cyw00d: Pas met je BPOD maar op dat je Apple niet op je dak krijgt voor het maken van inbreuk op hun "Pod"

Inbreuk? Zijn ze nou helemaal van de pod ge......

Ik wil niet veel zeggen, maar er zijn -slakken- die nog sneller zijn:

http://www.notes.co.il/benbasat/10991.asp
The little snail that could - Snails are faster than ADSL

ach.. met de 100mbit lijn zoals ik die hier heb denk ik niet dat dat waar is.. maar goed, studenten zijn waarschijnlijk geen doorsnee-nederlanders

Ik weet niet of je zo trots moet zijn op een 100 milli bit verbinding...

Een kopietje maken is toch zo gebeurd? Misschien dat je wel speciale apparatuur nodig hebt, maar het is wel sneller dan 256GB overpompen of branden (nu nog wel iig).

Dat wordt dus ook geclaimd ..........

En aangezien elke pixel een kleur heeft en niet alleen maar 0 of 1 is, kun je bij 65K kleuren dus al veel meer informatie kwijt, zeker als je dus een bepaalde codering hanteer die van unieke combinaties veel meer informatie kan genereren.

Volgens mij is het grote probleem hierbij domweg dat je hiermee niet elke benodigde code kunt omzetten en comprimeren, omdat er niet in voorzien is ( hij gebruikt een gekleurd(e) teken(combinatie) om iets te coderen en decoderen, maar heeft hierin bv geen teken(combinatie) voor mijn naam en kan die dus veel minder of zelfs helemaal niet coderen/comprimeren ) en dat het coderen en decoderen zoveel tijd in beslag neemt, dat het nagenoeg onbruikbaar is, nog buiten alle fysieke nadelen die hieraan kleven.

visstick???

Ten eerste sla je een 24-bits kleur (3 kleuren, 8 bits elk) op in... uh... 24 bits, niet 48 - vandaar ook de naam "24-bits". FC33A4 laat dat ook zien: FC (1 byte, 8 bits) is de rood-waarde, 33 is de groen-waarde (ook 1 byte) en A4 is de blauw-waarde (1 byte).

Ten tweede: wat is een pixel wanneer je het afdrukt? Een zekere oppervlakte op papier of je scherm. Wat is een bit? Een zekere informatiehoeveelheid. Zeggen dat een pixel 48x efficienter is dan een bit, is onzin. Het is net zoiets als claimen dat 3 kilometer minder is dan 4 Ampere, en vervolgens uit die onzin afleiden dat kilometers efficienter zijn dan Amperes.

Hehe, vergeet alleen de onzekerheid/meetfout niet. Printen in 24 bits en scannen in 24 bits wil niet zeggen dat je exact dezelfde waardes terug krijgt. Zeker niet op dat soort resoluties.
Ook moet je dan de CMYK koppen van je printer wel heel exact alignen.

Ja en om het te kunnen lezen heb je een scanner nodig die in een heel a4'tje op die mega hoge resolutie niet 1 pixel 1 bit verkeerd leest :-)
idem voor de printer.

Als je dat uitvindt ben je toch al rijk heb je je data opslag systeem al niet meer nodig :-)

edit: volgende keer eerst refreshen voor ik ga posten

daarom gebruikt hij natuurlijk die goemetrische vormen, als een correctie algorithme.

als je het bestand van 256 GB opslaat als een BMP (A4 1200dpi) zit je mss aan 200mb...
als je een bmp dan nog eens Rar'd, dan krijg je mss 108Mb
pretty great compression imo!

stel je hebt dan 256GB aan zulke BMP's (A4 1200dpi)
, je maakt daar een compressie van.... booja

en uiteindelijk heb je het hele internet op 1 velletje staan?

Alleen heb je dan nog meer resolutie nodig om de symbolen uit elkaar te houden, hoe complexer de symbolen hoe meer.

Denk jij eens goed voor je begint te reageren

Een printer print een plaatje, dat plaatje wordt gerepresenteerd door een array van pixels. Dan kun je wel x verschillende figuurtjes verzinnen die je data representeren, maar hoe je het ook went of keert, die figuurtjes worden op hun beurt weer gerepresenteerd door een array van pixels. Het is niet heel erg moeilijk om te bewijzen dat je niet meer figuurtjes kunt gebruiken dan het aantal verschillende combinaties van pixels die in die array mogelijk zijn, en dat het dus efficienter is om je data direct te bekijken als een array van pixels ipv er figuurtjes van te maken die slechts een subset beslaan van alle mogelijke pixelrepresentaties.

Kortom, wat deze student heeft verzonnen is niet geweldig, maar klinkklare onzin. De vergelijking met Jan Sloot wordt niet voor niets gemaakt.

En al dat gezeik over "ow, wat stom zeg, wat als het verkleurt"

Wel, in het geval dat het hele papier blootgesteld wordt aan dezelfde omstandigheden zou je dit grotendeels kunnen oplossen door het toevoegen van een referentie kleurbalk oid. De scanner zou dan de kleuren niet bekijken zoals ze binnekomen, maar tov de referentie.

M.i. heb je dit zowiezo nodig, gezien het feit dat elke printer elke kleur anders afdrukt, je kunt dus zowiezo nooit van absolute waarden uitgaan (en dan negeer ik nog de afwijkingen in de scanners)

Other then that: het idee is inderdaad super, en ik ben er zeker van da we hier de komende tijd zeker nog van gaan horen, al dan niet positief