Student claimt 256GB-opslag op A4-velletje

Een Indiase student beweert door middel van gekleurde tekencombinaties 256GB aan data op een A4tje op te kunnen slaan, dat door middel van een scanner en speciale software weer uitgelezen kan worden.

De 24-jarige Indiase student Sainul Abideen claimt een goedkope manier van dataopslag met een hoge capaciteit te hebben ontwikkeld. Op papier zou data in Abideens 'regenboogformaat' met een dichtheid van zo'n 420MB per vierkante centimeter kunnen worden opgeslagen, en met een speciale scanner en software worden uitgelezen. Volgens de student kan deze capaciteit worden bereikt door de data te representeren in gekleurde geometrische figuren.

Feitelijk claimt Abideen, naast het kunnen afdrukken en lezen van pietluttig kleine figuurtjes op papier, een krachtige datacompressiemethode, en het is maar de vraag of zijn beweringen nadat deze langs het kritische oog van de wetenschappelijke wereld zijn getrokken, overeind zullen blijven staan. Hoewel het denkbaar is dat het gebruik van kleur tot extra gegevensopslag kan leiden, is het twijfelachtig of het gebruik van een symbolenalfabet wel tot de mogelijkheid leidt om meer informatie op te slaan dan de informatie in de pixels waarmee de symbolen worden afgebeeld. Wat dat betreft doet de claim enigzins denken aan de betwiste uitvinding die de Nederlander Jan Sloot bijna zes jaar geleden mee het graf in nam.

Reacties (255)

[418O2]

lijkt me weinig handig, als er per ongeluk een vouw in komt, zit je met corrupte data..

of moet je dan een extra notitievelletje er bij hebben voor de par blocks ofzo?

[Chesta]

dan neem je 3 velletjes voor raid 5

[justice strike]

Dit was toch allang bekend? anders zouden ze niet: "een plaatje zegt meer dan duizend woorden"

[Verwijderd]

Je moet ook niet bij dat ene A4tje blijven, maar je moet verder kijken. Stel je kan dit A4tje inscannen zodat je een gigantisch groot bestand krijgt, stel: 100MB. Dan kan je dus in principe op een CD van 700MB 7x256GB kwijt. Zo zijn er nog tal mogelijkheden om dit te gebruiken. Het gaat vooral om de techniek, niet zo zeer om het medium.

[Verwijderd]

elke 1mm² een puntje zetten op een A4tje van 30cm*21cm, dat zijn 63000mm² of 63.000 dotjes

stel 16 bitjes -> 2^16 = 65.536 mogelijke combinaties
stel 63.000 bitjes -> 2^63.000 = 7,7575901436957388708252721889017e+18964 combinaties

stel 63.000 puntjes met (256 kleurtjes) -> 256^63.000 = veel meer combinaties

niet?

ofwel vergroot je het aantal plaastjes (bits) ofwel vergroot je karakterset (binair, hex, 256 kleurtjes), lijkt me vrij logisch. Of het gebruik van geometrische figuren (beslaan meerdere pixels) zoveel nuttiger is weet ik niet direct.

[Verwijderd]

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...

[Verwijderd]

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.

[Verwijderd]

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.

[Verwijderd]

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.

[Verwijderd]

^^ 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

[Verwijderd]

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.

[Verwijderd]

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.

[Verwijderd]

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.

[TheCapK]

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.

[Verwijderd]

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.

[Verwijderd]

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?

[Verwijderd]

@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.

[Kobboi]

Om dan vervolgens die 100MB in "papiercode" te coderen die op een veel kleiner papiertje past, zodat je dat weer kan inscannen? Yeah right...

[dtech]

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

[toab]

Homeopatishe compressie

[kidde]

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.

[Fireshade]

@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.

[GekkePrutser]

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

[Verwijderd]

@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.

[Verwijderd]

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.

[Jimbolino]

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

[Iet]

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?

[Z!oN]

@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

[Verwijderd]

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...

[Verwijderd]

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.

[junkbuster]

256 GB (geclaimd) in een gescand bestand van 100 MB? Dat zou betekenen dat je een ultieme manier van compressie zou hebben bereikt. Ik ben bang dat dat niet gaat lukken.

(edit: verderop in deze thread staat dit ook)

[pfismvg]

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

[Verwijderd]

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.

[Bulls]

@ 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

[spaceboy]

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

[i-chat]

@ 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...

[Bulls]

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

[player-x]

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)

[Verwijderd]

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.

[Verwijderd]

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.

[Grrrrrene]

Dan moet je wel lossless scannen anders, heb je alsnog datacorruptie

[rulus]

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

[Verwijderd]

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.

[Verwijderd]

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

[cavey]

@redstorm:

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

[Verwijderd]

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

[knirfie244]

Ik denk dat je toch een serieuze DPI resolutie moet hebben voor de scan, laat staan dat ook maar enige vorm van compressie op de gescande data uit den boze is.

[_JGC_]

Of als je het blaadje in de zon laat liggen, is je blaadje verkleurd.

[TIGER79]

hhmm...
wij werken nu ook met bidimensionele barcodes en daar gaat het al wat vaker mis met het inlezen ervan aangezien er praktisch geen enkele OCR programma bestaat die steeds opnieuw precies dezelfde gegevens kan lezen...
als je een hele pagina vol tekeningetjes hebt en die laat je 2 keer inscannen en OCR dan zullen er 2 verschillende resultaten komen...
dus als het daadwerkelijk werkt dan heeft hij niet alleen een primeur qua dataopslag maar ook qua consequente optical recognition van een document met zoveel tekeningen erop !
die kerel wordt dan echt stinkend rijk als ie beide patenteerd

[Refragmental]

Best slim eigenlijk.

Met genoeg kleur en symbool combinaties kun je dan ieder een waarde toekennen aan een combinatie van beiden.
Een rood vierkantje kan dan de waarde 10010110 hebben, een blauw vierkantje 10010111 en een geel driehoekje met de punt naar rechts is dan 11011010.
Moet je natuurlijk 256 combinaties hebben om een symbool-kleur combinatie een byte te laten voorstellen.
Mits je de symbolen dan klein genoeg maakt kun je best veel informatie op papier krijgen.

In iedere hoek dan wat gegeven voor de scanner. Zoals wat is het begin (linksboven) En informatie voor de gebruiker die het a4tje in handen heeft. Zoals printdatum, pagina etc etc.

Vervolgens laat je het printen op hoog kwaliteit papier en plastificeer je de boel, met misschien nog een 2tal reserve kopieën

Met andere woorden... best slim ^O^

[ThE_ED]

Waarom printen als je het als plaatje kunt opslaan? En dan kom je weer terug bij het punt in de post; hij claimt dat het extreme manier van compressie is.

Hoewel ik moet zeggen dat de benadering wel ok is; niet kijken naar de patronen in je data maar naar wat je data voorstelt, maar ik kan me nauwelijks voorstellen dat dit de key is. Kleuren en posities zijn bij uitstek repeterende patronen dus waarom het uitschrijven daarvan kleiner is als gewoon de patronen in een zipje comprimeren is mijn intuïtief niet duidelijk.

[Rey Nemaattori]

Als je het plaatje opslaat in een lossless compressie formaat zallie ook wel aardig groot zijn...waarshcijnlij ktegen de 450gb aan

als je um al jpeg kon opslaan zou je oneindige dataoplslag lussen creeren

[Verwijderd]

Stel je wilt een pixel opslaan in je plaatje dan zou je toch uitgaande van RGB bijvoorbeeld de volgende waarde opslaan. FC33A4 je kunt dit op je papier als één enkele pixel neerzetten. Dus niet 48 bits maar één pixel. Als je dit weer zou inscannen wordt het dus weer 48x zo groot. Let wel ik denk dat je het niet helemaal zo kan rekenen want je moet rekening houden dat je kleuren ver genoeg uit elkaar liggen om ze nog goed door de scanner te laten inlezen. Je zou dus voor kunnen kiezen om 1/3 van het kleurenpallet te gebruiken. En dan te zorgen voor kleuren die niet bij elkaar liggen. Wel moet ook een rand worden geprint ter callibratie. Ik zou zeggen is er nog niet een tweakende programmeur die dit thuis al even heeft uitgewerkt? Zodat we het even kunnen proberen?

[Verwijderd]

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.

[i8086]

Ik ben geen rekenwonder, maar geloof dat je dan wel nog de kleurcombinaties vergeet....

[Refragmental]

Madcat?

Waarom zeg je eerst dat dit op Slashdot al als Hoax is aangetoont door iemand met die berekening die je geeft... en haal je vervolgens alle referentie naar slashdot weg en doe je alsof je de berekening zelf hebt uitgevonden?

[TD-er]

je moet 256*1024*1024*1024*8 = 2199023255552 bits opslaan op een A4.
Dat is 210 mm x 297 mm = 62370 mm^2

Zullen we even in 2-machten gaan rekenen, dat maakt het net even wat makkelijker.
256 GB is 8+10+10+10+3 = 41 bits.
1 A4 is 100 vierkante inch.
Qua oppervlak is dat dus gelijk aan 10 bij 10 inch.
Dus over de afstand van 10 inch moet je dan 2^20.5 bits kwijt kunnen. (de zijde van een vierkant met oppervlak van 2^41)

Stel je kunt 2^24 kleuren kwijt per pixel, dan zit je dus op een dpi van (aantal bits per 10 inch/aantal inch/aantal bits per pixel) = 2^20.5/10/24 = net iets minder dan 6200 dpi.

1000 dpi inscannen heb je al een behoorlijk goede scanner voor nodig en zeker als je ook nog een betrouwbare kleurenscan wilt doen.
6200 dpi met 24 bits kleur is vrijwel onmogelijk te printen.

[ixl85]

Lees jij eens goed voor je begint te rekenen.

olgens de student kan deze capaciteit worden bereikt door de data te representeren in gekleurde geometrische figuren.

Als je figuren aanlegt krijg je weer meer mogelijkheden, aangezien er bijna een oneindig aantal figuren te maken zijn zou het wel kunnen.

En al dat gezeik over "ow, wat stom zeg, wat als het verkleurt"
Mensen; het is een idee van een student, het is geweldig. Dit zou ook op plastic schijven geprint kunnen worden. Er bestaat btw ook inkt die niet gevoelig is voor fotosynthese.

[.oisyn]

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.

[Verwijderd]

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

[Verwijderd]

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

[DeArmeStudent]

Even voor de duidelijkheid: kleurencombinaties worden niet opgeslagen als 1en en 0en, maar als 00ff23 bijvoorbeeld...zo kan dus 1 pixel 16,777,216 verschillende kleuren hebben (truecolor), waardoor je dus 1 pixel kan gebruiken om 16,777,216 verschillende waardes vast te leggen... Als deze waardes bekend zijn bij de scanner, wat een bepaalde kleur betekend, dan kan dus heel veel info op 1 A4tje
@Wumpus: je hoeft het niet eens uit te printen, je kunt het plaatje ook gewoon bewaren op je pc...Daarbij haal ik dit uit het bronartikel: "he used geometric shapes such as circles, squares and triangles for computing which combine with various colors and preserve the data in images." Dus daarbovenop gebruikt hij geometrie om data op te slaan...

[Verwijderd]

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.

[trogdor]

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

[martijnve]

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

[Verwijderd]

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?

[Blokker_1999]

Volgens dailytech gaat het om 450GB

En ik stel me hier toch ook vragen bij hoor. Hij is niet de eerste met een mirakeloplossing.

[tweaktubbie]

Volgens dailytech gaat het om 450GB

Inkoppertje: dubbelzijdig printen?

[it0]

Er zijn ook al verschillende sites die melden dat dit fake is.
http://itsoup.blogspot.com/2006/11/scam-of-indian- student-developing.html
http://www.digg.com/tech_news/Scam_of_Indian_stude nt_developing_technology_to_store_450_GB_on_paper
http://hardware.slashdot.org/article.pl?sid=06/11/26/140240

Het zou trouwens wel mogelijk moeten zijn om meer als 100Mb erop kwijt te kunnen.

Het is heel simpel eigenlijk, er kunnen maar zoveel dots per inch voordat ze beginnen over te lopen, en dan heb je ook nog een goede scanner nodig...

[Verwijderd]

geef een link dan

[Menthix]

http://digg.com/tech_news..._to_store_450_GB_on_paper

[AugmentoR]

Vergeet techworld niet met een mooie top 10 waarom dit niet kan: Expert opinion: No Way

[Verwijderd]

Van papier naar computer, en weer terug naar papier.

[Verwijderd]

hehe, straks krijgt internet nog concurrentie van de post

[Verwijderd]

Windows TPG post ?

[F5544]

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

[Cyw00d]

BPOD
Blue Paper Of Death

[pietje63]

@F5544

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

[tERRiON]

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

[_XipHiaS_]

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

[Strike_2]

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

[BlooDbeak]

Het is nu TNT post hoor

oranje ipv. rood, vast een fout bij het uitprinten

[Daimanta]

waarbij ook meteen de belastingen zitten.


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

[teh_twisted]

tis nog steeds sneller om een hardeschijf op te post te trappen dan uploaden dus concurrentie zullen ze altijd behouden

[lamme23]

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

[foppe-jan]

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

[Verwijderd]

Alleen niet erg geschikt voor een potje CS

[Gromba]

Zo iets heb ik wel eens gemaakt, maar dan voor png plaatjes:
http://gromba.nl/dev

De hele tekst uit dit nieuwsbericht kan je hiermee opslaan in een plaatje van 22x22 pixels

[martijnvanegdom]

Maar essentieel gezien verlies je geen bits. Je representateerd het alleen anders. het enige is dat er in de verliggen karakterstandaarden wat 'te veel informatie' zit.

Even een test gedaan..
In UTF8 is de tekst van dit nieuwsbericht 1,385 Bytes. Een bitmap van 22 bij 22 bij 24bits kleuren is 1,452 Bytes groot. Met andere woorden je hebt geen compressie toegepast.. nee je hebt het opgeblazen!

Dat je natuurlijk png compressie hebt maakt natuurlijk niet uit.. gooi ik er rar of zo tegen..

[No13]

Maar als je dit resultaat afdrukt op A4, hoeveel pixels kan je dan kwijt met dit systeem? en hoeveel data past daarin?

Om 1 RGB 24 bits pixel op te slaan op je HD heb je normaal zeg 3 bytes nodig. Om die ene pixel op papier te zetten heb je maar 1 vlekje nodig...

Of je nou zwart-wit, RGB 24 bits of weet ik wat voor een formaat pixels op een A4'tje wil zetten, ze kosten evenveel ruimte... Dat is niet vergelijkbaar met de digitale variant

Edit: Ff snel zitten rekenen
Een A4'tje van 210mm x 290mm
is 8.2677" x 11.4173"
bij 300 dpi is dat 2480 x 3425 pixels
zijn 8.494.000 pixels

Bij 8-bits kleuren (256 kleuren) heb je dus ~ 8 miljoen keer 8 bits (ookwel byte genoemd) ofwel 8 megabyte aan data.

Daar kan je aardig wat pagina's tekst in kwijt

Ik kan me voorstellen dat met een goede printer en scanner je wellicht het aantal kleuren en/of dpi kan opkrikken....

Toegeven, 450 GB klinkt echt als broodje-aap maar ik geloof best dat je aardig wat data op een A4'tje kan opslaan maar ik denk ook dat bij het inscannen deze data weer net zo groot is als deze was voor het wegschrijven... dat is het hele idee achter analoog <-> digitaal conversie

[Skinkie]

Als er een patent wordt aangevraagd zou ik zeker bezwaar aantekenen!

[DannyXP1600]

En als je dan een divx film opent in kladblok, de tekst kopieert en opslaat als png, dan kan je dat in een mini bestandje verzenden en dan werkt het daarna na het terug omzetten weer? Heb je een patent, anders gaat die gast van het nieuwsbericht ermee vandoor!

[edit]
Ik probeerde net een stukje mp3 van 180 kilobytes te openen in kladblok, omzetten naar PNG. Plaatje werd 90 kilobytes. Vet! Maar toen het plaatje terug naar tekst omzetten... Het was een andere tekst...
En dat weer in kladblok opslaan als iets.mp3 was nog maar 85 kb... En het werkte ook niet. Winamp crashte erop...

[mieJas]

De tekst "i earned 1 point of gay for reading a blog" in een simpele text-file is 42 bytes. Giet je dat in een PNG is het plots 117 bytes.

Het nut ontgaat me wat...

[TD-er]

De PNG-header kost ook ruimte.
Als ik 10080 bytes aan Lorem-ipsum tekst erin stop, krijg je een png van 58x58 pixels (is dus in raw-data 58x58x3 Bytes = 10092 Bytes)
De png file is dan 7169 Bytes groot.

72260 Bytes tekst levert een file op van 156x156pixels en de png is dan 52242 Bytes groot.

Kortom de enige compressie is dus de PNG-compressie. De data is alleen iets anders weergegeven.

Wat me wel opvalt is dat er zoveel donkere pixels in zitten. Wat je dus zou kunnen doen is het nog wat uitsmeren over iets meer pixels en het verbergen in een plaatje. Je ziet de storing dan vrijwel niet.

[Verwijderd]

Ik zou de geheime dienst bellen... wellicht dat ze dit soort technieken wel gebruiken voor het geheim versturen van gecodeerde berichten

ps. Dit was sarcastisch aangezien dit volgens mij in de koude oorlog al werd toegepast!

[Greyh0und]

Het lijkt mij logischer om een .txt in een .bmp bestand te veranderen en die in een .zip te zetten.

ivm foutjes die in een png kunnen bestaan... (omdat png compressie gebruikt...)

[WhiteDog]

Binnenkort Windows op een rol toiletpapier. Nu met Microsoft Plush technologie

[Vjeeten]

eerder Flush-technologie dan...

[Cardinal]

Wij van wc-eend hebben concurrentie gekregen

[Verwijderd]

"Windows om je kont mee af te vegen."

[RwD]

Ook handig als er een druppel water op komt, de data verkleurd door de zon. Iemand morst koffie... enz

Maar even de praktische bezwaren daar gelaten: Het is mooi dat er zoeveel gegevens op een a4 gezet zouden kunnen worden. Doet me wel denken aan de Duitsers die op een stukje plakband gegevens wilden opslaan en dan ook enkele Gb kwijt konden op een klein stukje (kan even geen link vinden. Als iemand iets weet...)

[Verwijderd]

Een backup maken lijkt mij een kleine moeite

[Rudi Vader]

Nou ja... dan blijft het toch wel weer 256Gb aan data voor een vol A4tje die je moet backuppen. Ga er maar vanuit dat je HP PSC het niet doet.

[HanH]

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).

[Verwijderd]

Dit lijkt me wel handig om aan doe-het-zelf datarecovery te doen: eerst scannen en dan gewoon softwarewerk

[Upsal]

Toevallig dat ik hier laatst op GoT ook een topic over zag lopen; forum: Data opslaan op A4

[Timfonie]

Hmm, waarom is dit al nieuws als iemand zoiets claimt en niet pas als het door anderen gereproduceerd is?

Ik kan me dan ook niet voorstellen dat zijn claim terecht is.