super, funguje to.
zaplnil jsem úplně celý papír (199773 B) daty z /dev/urandom, resp. obrázkem vzniklým jejich zakódováním, vytiskl na naší laserovce s defaultním nastavením (ani nevím, kolik DPI), pak otřel scanner papírovou utěrkou, jak se v README doporučuje, ale vodou, ne Alpou, a trochu nakřivo oscanoval a ještě k tomu omylem vzhůru nohama (byl jsem líný to pak po preview oáčet), při grayscale jednou 600 a pak 1200 DPI PNG. Unoptar zjevně zatím blbuvzdorný není, protože si s obrázkem vzhůru nohama neporadil. Nějaká data sice vyplodil, ale při cca 50% chybovosti (což by asi tak odpovídalo věštění z koule). Ale po otočení původní data z 600DPI obrázku téměř komplet zrekonstruoval, při 0,05% neopravitelné chybovosti. No a z 1200DPI obrázku jsem už komplet data dostal. A bez namáčení.
Moc hezké, jen je trochu škoda, že se při dekódování musí pracovat s o 3 řády většími soubory (pokud jde o data která zaberou cca jeden list).
Jo, vuci otoceni vzhuru nohama to invariantni neni. Predpokladal jsem, ze clovek to automaticky do scanneru vlozi tak, aby text nebyl vzhuru nohama. Jak vidim, ten predpoklad byl chybny.
Uz jsem to dopsal do README.
Jakou statistiku Golayovych kodu to napsalo, kdyz to melo 0.05% neopravitelnou chybovost?
Zajimavy - me chodi 600dpi obrazky s prakticky stejnou chybovosti jako 1200dpi. Neprodukuje tvuj scanner PNG obrazky s vadnou gammou nebo tak neco?
17213 bits bad from 3196368, bit error rate 0.538517%. 97.5019% black dirt, 2.45164% white dirt and 8 (0.0464765%) irreparable.
Golay stats
===========
0 bad bits 117036
1 bad bit 15119
2 bad bits 989
3 bad bits 36
4 bad bits 2
total codewords 133182
1200 DPI:
5078 bits bad from 3196368, bit error rate 0.158868%. 99.3108% black dirt, 0.689248% white dirt and 0 (0%) irreparable.
Golay stats
===========
0 bad bits 128217
1 bad bit 4854
2 bad bits 109
3 bad bits 2
4 bad bits 0
total codewords 133182
Co se týče gammy, myslím, že ji xsane koriguje automaticky podle skenovaného pbrázku, ale moc jsem to neřešil a nehrál jsem si s tím. Ale mám teď dojem, že v jednom případě jsem tu autokorekci vypnul :). Nebo myslíš gammu ve výstupním PNG ?
Korekce nekorekce, ty data v tom obrazku maji nejakou gammu - tzn. bajt=pocet_fotonu^gamma. But PNG ji nema uvedenou a pak musi byt 0.4545, nebo ji ma uvedenou a pak musi byt uvedena spravne.
Napadlo me jeste, ze mas mozna nejaky nekvalitni scanner co na 600dpi vytvari prili velky sum nebo moc rozmazava nebo tak - mohl bys udelat nejake reprezentativni vyrezy obou tech nascanovanych obrazku a postnout?
Jeste bys moh zkusit vzit tech 1200dpi, v Gimpu to zmensit na 50% a zkusit jaky vysledek. To se pak ukaze jestli je to scannerem nebo jestli je nejaky mne neznamy fenomen ktery to kazi.
No skenuje na Linuxu, takže pokud neskenuje v optickém rozlišení skeneru, výsledkem mohou být "zubaté" obrázky (podle driveru). Sane je nekvalitou pověstné.
Toz jsem se na to podival. Problem byl v tom, ze ty PNG byly ulozeny spatne - mely gammu asi 1.0, ale zadnou gamma informaci ulozenou nemely, cili mely mit defaultni gammu 0.4545. Vysledek byl, ze obrazek pusobil neprirozene tmave, okraj kde bylo videt viko scanneru byl sedivy misto bily, a unoptar to pak cetl s chybami.
Chyba byla tedy v tom PNG. Kdyz jsem to Gimpem korigoval, precetlo se to bez chyb (posledni 2 cisla ve statistice Golaye byly taky 2 a 0).
Bylo to zpusobeny tim, ze ten obrazek byl spatne ulozeny - nemel nastavenou gammu cili se gamma predpokladala defaultni 0.4545, ale data zda se byla s gammout 1.0. Vypadala podezrele tmave.
Bylo to zpusobeny tim, ze ten obrazek byl spatne ulozeny - nemel nastavenou gammu cili se gamma predpokladala defaultni 0.4545, ale data zda se byla s gammout 1.0. Vypadala podezrele tmave.
Jinak - CD a DVD taky nejsou blbuvzdorne. Daji se do mechaniky dat obracene, na mechanice ani na CD/DVD se nikde nepise jak se tam maj vkladat, a kdyz se vlozi obracene tak to nefunguje. Jeste jsem nevidel, ze by si na to nekdo stezoval.
