A Sampling Lánczos kutyái, Bilineár és Bikubik,megvesztek?

Remélem elég szürreális a cím, de azért az átjön, hogy továbbra is a samplingről van szó. Pontosabban a képméretezések laikusok általi soha meg nem érthetőségéről.

Az interneten sokan vállalkoznak arra, hogy ezeket nekünk elmagyarázzák, sajnos, amikor leellenőrizzük a gyakorlatban, mégiscsak azt tapasztaljuk, hogy a PS, GIMP, vagy IRFAN totál másképpen működik, mint a papírforma. Az elv mindenesetre nem bonyolult. Az alábbi ábrán a felső sor csak egy dimenzió mentén mutatja a műveleteket, minket a "bi" sor érdekel, mivel a fotó leginkább két dimenziós (bár tudjuk, hogy három, vagy legalábbis ezek permutációi).

Forrás

A nearest neighborról már volt szó. Elméletben a bilinear a súlyozott átlag alapján kellene működjön (legalábbis - ebben a videóban 4:30 környékén erről beszélnek). A valóságban azonban a PS teljesen más eredményt ad. Lássuk a konkrét példát a videóból. 100 és 200 legyen a kezdeti pixelek értéke. Ebből csináltunk egy 3*3-as pepitamintát. Ezt növeljük 7*7 pixelre, tehát minden létező pixel közé két új pixelt kell kitalálni. Legyen az alábbi ábrán a négy mérési pont: 100 - X - Y - 200 ahol az X pixelérték 2/3 távolságra van a 100-tól és 1/3 távolságra van a 200-tól. Az Y pedig 1/3 távolságra van a 100-tól de 2/3 távra a 200-tól. 

Tehát X= 2/3*100+1/3*200 = 133 , az Y= 1/3*100+2/3*200 = 166. Ha unod a számigálást van online kalkulátor is. 

Ezzel szemben mit mérünk PS-ban? Ezt:

az1-es és 4-es mérések a kiinduló pixelértékek, X a kettes, Y a hármas. 

Kijön 114 illetve 157. Hát hogy? Talán azért van, mert mi csak egy irányt számítottunk de ő két irányban maszatol? Ezért megnéztük csak 2 pixellel is, hogy ne tudjon a függőleges tengely mentén konspirálni.

Most meg 125 és 175 jön ki. Érzem, ahogy lassan  felmegy a cukrom.  

Ezt meg a GIMP ugyanabból, ugyancsak Linear (ott nem bilinear a neve) módszerrel. Na, itt hagyjuk abba. Tehát ahány program, annyiféle algoritmus. Persze lehetne próbálgatni, hogy vajon ez nem e amiatt van, mert túlságosan közel vannak a szélek, és hogy nagyobb környezetből számol. Lássuk akkor egyetlen nagyobb kép lineáris interpolációját 300 pixelről fel 400-ra, PS-ben és GIMP-ben. BMP-re konvertálva, nehogy a JPEG blokkocskák, vagy profileok bekavarjanak. 

Persze szabad szemmel nem látszik a két külön programból interpolált BMP között a különbség (Differencies módban vannak egymáson), de ha ezt egy görbével kihangsúlyozzuk, egyből nyilvánvaló, hogy nemcsak a kép szélein dolgozik másképp a két algoritmus, hanem mindenhol, ahol apró részletek vannak. 

Ezek után úgy döntöttünk, hogy a köbös és annál sokkal komplexebb módszerekbe (Lanczos, Spline, stb) nem is ártjuk bele magunkat. Sőt, már olyan tesztet sem kell csináljunk, ahol a különböző algoritmusokat hasonlítják össze, mert már létezik. Ezt, meg ezt is érdemes megnézni. Itt meg arról olvashatunk, hányféle bicubic módszer is lehetséges különféle programokban. 

Először volt a bugyi, most meg a maszk! Mi lesz a következő???

Forrás Amazon JINF

Ki tiltja meg, hogy elmondjam, mi bántott hazafelé menet? (JA)

Az alkesz vicc szerint azért nem egészséges vizet inni, mert abban nagyon durván basznak a halak, de ugyanez igaz a levegőre is, amit beszívunk. Hiszen, apró nyálcseppekkel szórjuk tele a levegőt, így utaztatunk vírusokat, baktériumokat, spórákat. De simán bele is fingunk, meg különben is mindenféle  testünkből kiszabadult atomokkal molekulázzuk tele a közös életteret. Amit aztán más benyel, bepislog, letüdőz. Hát pont így működik a szaglás, meg az ízlelés is: mások büdöséből néhány molekula felragad a mi szaglóidegünkre, nyelvünkre.

Tetszik, nem tetszik, az emberi test is anyagot ken szét maga körül, mint a csiga, különféle hulladékokat, váladékokat hagy maga után, és az, hogy ez másoknak izgalmas, vagy undorító, esetleg közömbös, vagy az egészségére ártalmas, az helyzetfüggő. Van akit undorít mások hámló bőre, és van aki szívesen nyomogatja mások pattanásait is. Szóval nem vagyunk egyformák. És nem is mindig zavar, hogy bozontosabb embertársaink közös életterünkbe hullatják a szőrüket (és úgy telebundázzák a vécéülőkét, mintha egy mókust tartanának a mogyoróik mellett), mindaddig, amíg az alsó szomszéd bog haja miatt a felső szomszéd kulája nem a mi budinkból szól ki, hogy heló.

Forrás: Amazon JINF

Rengeteg tevékenységünk direkt azt a célt szolgálja, hogy szimbolikusan, vagy valóságosan, de keveredjünk, atomokat, molekulákat csereberéljünk. Az egyszerű kézfogás, a vérszerződés, az egymás poharából ivás. A nyalakodáson át, az orvosilag indokolt és intézményesített, de sokkal szürreálisabb véradáson keresztül, egészen a szervcserékig, hogy a legbizarrabb szarátültetéses terápiákba ne is menjünk bele.
De kozmikus értelemben, is mindenki csereberéli az alkotóelemeit, amelyeket elcsépelten csillagpornak szoktunk mondani, mert zömmel valóban csillagokban született alkotóelemekről van szó, ami állandó körforgásban van a Földön (és hosszabb távon az Univerzumban). Ezért szokták mondani, hogy mára nagy valószínűséggel sokunkban van olyan vízmolekula is, amelyiket valamelyik római császár pisilt ki egy orgia után. 
Kiszuszogunk pár széntartalmú molekulát, amit fotoszintetizál a paradicsom, aztán valaki megveszi a piacon és beépíti a szervezetébe. Aztán valamikor, lehet ha csak halála után, továbbadja, de hiszen tudjátok, sírján fű nő, azt a tehén lelegeli ésatöbbi... Az átlagos emberi test 10^27 (tíz a huszonhetedik hatványon) nagyságrendű atomot tartalmaz, ami az univerzum csillagainak a számával hasonló nagyságrend, nem túlzás tehát az, hogy minden ember egy külön Univerzum. És ennek az atommennyiségnek jelentős részét sűrűn cseréli is az ember, míg például a csontokban megkötött atomokat viszonylag ritkábban.

Forrás: Amazon JINF

De valójában, az a lény, amit mi embernek nézünk, fenség, észak fok, idegenség, mennyire számít egyetlen élőlénynek, amikor sejtjeinek fele nem is emberi sejt (10:1 -től 1:1-ig arány között szól a szakirodalom, természetesen a baktériumok javára).
Nagyobb részünk baktériumok, vírusok, atkák, mindenféle jószágok lelkes kommunája, tehát egy random Kovács Bélabácsi, egyetlen emberből és 10.000 különféle egyéb életformából áll, de úgy, hogy az emberi sejtek száma semmilyen becslés szerint sem haladja meg a nem emberi sejtek számát. Most abba ne is menjünk bele, hogy többségünk mekkora nagy szarzsák, nem véletlenül oktatott minket, süldő legénykéket, Vén Farkas annak idején, hogy a legjobb nőben is két kiló van ebből az anyagból. 

Tehát minden ember egy hatalmas életközösség, nagy része boldog szimbiózisban, egy univerzum, amiről óhatatlanul lepotyognak élőlények, és rátapadnak újabbak másokról. Ahogyan egy denevérről, a tobzoskán át, rá a kínaira. És akkor itt érünk vissza a bevezetőhöz. Nem az a baj, hogy a levegőn üzekedünk, hanem hogy közben mindjárt kilenc milliárdan leszünk. És emiatt összeér a szimbolikus  fenekünk. Na ez az egészségtelen. És akkor már csak nézőpont kérdése, hogy a vírusra kell gyógyszert keresni, vagy a vírus maga egy bizarr gyógyszer, aminek ugyan a hatása nem túl erős, ellenben sok a káros mellékhatása. 

Teljesen világos, hogy a COVID-19 kapcsán felmerülő kötelező maszk-használat két némileg ellentmondó paradigmán alapszik. És most hagyjuk azt a burleszket, amit a járvány elején előadtak a véleményvezérek a maszkviseléssel kapcsolatban. Mi nem megyünk bele olyan tudományos és látszólag tudományos vitákba, hogy hasznos e a maszk és hogy magunkat, vagy mások édes jó anyukáját védjük e vele. Azt sem vitatjuk, hogy bárki a házában, üzletében elvárhatja a vendégeitől a maszk használatát. De a szabadban előírni a maszk használatát nincs jogotok! Beleszülettünk egy olyan rabságba, ahol a közös fórumainkon ágyékunkat takargatni kell. Bugyit húzattatok elődeink fenekére. Most meg a mi fejünkre? A számra azért ne... csak az arcomra ne! Azt én akarom eldönteni, mikor jött el az ideje annak, hogy maszkot húzzak a fejemre. Ne siettessétek a pillanatot.

Nem tilthatjátok meg testünket! Nem áshattok egy újabb árkot az emberek közé, ami alapján gyűlölhetik egymást, nincs szükség még a maszk-kérdésre is ahhoz, hogy megvessük és utáljuk egymást. És ahogy nem büntethető az, aki csóré seggel leül más kanapéjára, de seggbe azért még rúgható, ugyanúgy ránk lehet bízni azt a feladatot is, hogy a kézzel a taknyos orrát törlő és betegen hozzánk bújó embert elküldjük e más vidékre, vagy ápoljuk. Mert vannak vidékek. Nem kell ahhoz rendelet.

vannak vidékek

ahol a népek

csöndben az ágak

jelekkel élnek

beszélni félnek

viharra várnak (KS)

Mi már a bugyi kötelezővé tételével sem értünk egyet. De most mi lesz? A szájat is tabusítjuk, meg az orrot? Aztán mert néhányan csipások, jön a napszemüveg? A fülzsírosok miatt a fülvédő? A korpás hajúak miatt sapka? S mikor majd jogtalanul vegzálnak a rendőrök, mit mondasz nekik mérgedben? Hát a politikusoknak? Csókoljátok meg a... számat? 

Legyetek RAW diggerek!

Tényleg olyan sok adat van a RAW-ban? A *.NEF tömörítése.

Egy alapos Utazások olvasónak, amilyenből talán egy sincs (még Grimpix se), igazán feltűnhet, hogy az évek múlásával egyre több dologról derül ki, hogy az nem is pont úgy van, mint arról régebb írtunk. Ez azért van, mert minél egyszerűbbek vagyunk, annál egyszerűbbnek látjuk a világot. Vagy a google vázolta eddig a durvább tónusokat és ahogy haladunk az úton, csak adagolva keni fel az apróbb nüanszokat az összképre. 

Apropó tónusok. Mit tippelsz? Ha van egy kamerád, 12, vagy 14 bites AD konverterrel, akkor mennyi tónust is találsz a RAW-ban? Hmmm? Mi simán rávágtuk volna Grimpixszel, hogy hát az 4.096 illetve 16.384 tónus. És mivel lineáris, a legvilágosabb EV a tónusok felét használja, és így tovább lefelé. Ezt minden fotós tudja. Elméletben. Mert attól, hogy az AD konverzió 12, vagy 14 biten zajlik, még nem biztos, hogy a tárolás is. Merthogy tömörítenek. Persze erről olvastunk és arról is tudunk, hogy olykor hisztike is van a veszteség miatt. Nem minden gyártónál hasonló a módszer. A Nikon ezt írja a NEF-ről. 

Lossless Compressed 20 - 40%  

Compressed 35 - 55%  

Uncompressed No reduction in file size

A D5000-ben sajnos nem kiválasztható a veszteségmentesség. De konkrétan mi lesz a veszteség? Itt az áll, hogy a D5000-nél például a 12 bites 4096 tónust 769 tónusból megoldja. 

RawDigger lineáris hisztogram egy D5000-es  stúdiófelvételén. 
Jól látszik, hogy nem volt jobbra exponálva, a felső tartomány teljesen kihasználatlan.
Trehány munka, de nem mi készítettük.

A 114-es sötét értéktől (-2EV tartománytól) felfele kezdi gyomlálgatni ki a köztes tónusokat, eleinte csak minden másodikat, de a végén már csak minden ötödik értéket tartja meg. Azért ritkítja jobban a világosabb tónusokat, mert talán látásunk sajátossága okán a sötétebb tónusokban hamarább észrevennénk a trükköt? Ezt régebb úgy fogalmaztuk meg, hogy egy, illetve két gyertya fényerejében simán észleljük a különbséget, de egy, vagy két atomvillanást már nem tudnánk megkülönböztetni. Ezt egyszer, ha lesz atombombánk, majd tesztelni is szeretnénk. Meg hát ez még lineáris állapot, a legfelső egyetlen fényérték (+3EV) akkora helyen van tárolva, mint az összes alatta levő (2048 lépés), tehát ebből lehet a legjobban pancsolni, az alatta levő fényérték meg akkora, mint az összes alatta levő (1024), tehát ebből már kevésbé érdemes eldobni, és így lefele végig, 114 alatt már minden egyes tónust eltárol (már ez is kevés). Grafikonra téve elég lehangoló:

Tehát -3EV alatt a 12 bites konverterből kijövő adat 100% kerül tárolásra, aztán ez a +3EV tartományig fokozatosan leesik 10,69%-ra. -8EV-től felfele minden tartomány duplája az azelőttinek, de -3EV-tól fokozatosan esik ez az érték, 1,9-szerese, 1,5-szöröse és végül csak 1,41-szerese az azelőttinek. Pedig mi mindig úgy fújtuk az elméletet, hogy felefelé végig duplázódik a tónusok száma. Hát nem. 

Mindezt miért? Gyorsabb írás, nagyobb framerate, ilyenek miatt. Egy D5000 kb. 4288*2848 pixeles lapkája 12,2 millió pixelnyi 12 bites adatot termel, durván 18 Mb. Ennyi lenne egy tömörítetlen kép, persze ehhez még csomó apróság hozzáadódik, jpg előkép, meta, stb. Ezzel szemben egy NEF nekünk 8-10 Mb között szokott lenni. Persze még egy veszteségmentes tömörítést is kap a kép, ami még jobban árnyalja a dolgokat.

Érdekes korreláció, hogy a világosabb képek kicsit nagyobbak, mint a sötétek, Tehát ha egy szürke lapot végigexponálunk pl. -3 és +3 EV korrekcióval, akkor egyre nagyobb fileméretet kapunk, mindaddig, amíg a felülexponált képeken nem kezd kicsúszni a 4096-ból, ami +4EV korrekciónál már bekövetkezik a mi gépünkön, innen ahogy haladunk tovább megint egyre kisebb fileméretet kapunk. Lehet, hogy a sötétebb tónusokat eleve kevesebb bittel írja le?

Ugyanez a 14 bites D5600-nál 16.384 tónust (itt +2 EV van a D5000 12 bites konverteréhez képest, tehát nem +3EV-nél csordul, hanem +5EV-nél) 4.097 helyre mappel, ami azt is jelenti, hogy bár a D5000-hez képest elvileg 4-szer annyi tónusa van (16384/4096=4), de a veszteség nem annyira nagy, 5.3-szor annyi tónust ment el (4097/762=5.3).

Ráadásul az 1552-es értéktől kezdi gyomlálni a tónusokat, ami csodálatos, mert a D5000-hez képest 2EV-vel fennebbről kezdődik a veszteség. 

Egy RawDigger segítségével könnyen ellenőrizheted a Nikonodat, ha az Encoding táblázata megtalálható itt. A RawDigger képes nyers adatokat megjeleníteni. Kinagyítasz egy kellően világos homogén képrészletet (mert itt a legnagyobb az ugrás az értékek között), és pixelenként végigpásztázva nem fogsz tudni olyan tónusértéket találni, ami nincs benne az adott géptípus encoding táblázatában. 

Összefoglalva, D5000-es 12 bites konverter bár 12 biten értelmezi a pixelek elektromos töltéseit, ezt a NEF tárolásakor 769 tónusra szűkíti. Szóval, mikor legközelebb azt mondják, azért kell RAW-ba fotózni, mert ott eszméletlen mennyiségű adat van, hát nem. Csak alig háromszor annyi, mint a 8 bites JPEG-ben. Most kellene egy jól ráérő ember, aki kiszámolná nekünk, hogy ilyen körülmények között is megéri csurig jobbra exponálni a jobb tónusátmenetekért? Szerintünk még így is megéri, a nagyobb filememéret és hát a gyakorlat is azt mutatja. 

Update. Volt régesrégen egy Canon 450D gépünk is. Úgy tűnik, az teljesen másképpen tömörített, mert egyáltalán nem fésűs a felső régió. 

Monitor monitorozás

Volt már ilyen az Utazásokban, azonban most egy másik panelt elemzünk. Itt akár abba is hagyhatod az olvasást, és inkább tégy egy kirándulást erre az oldalra, ahol remek tesztek, meg optikai illúziók várnak, természetesen a saját monitorodnak megfelelő megjelenítésben. Ez meg egy másik monitortesztelgetős oldal, amellett, hogy jó játék, talán némi ismeret is ránkragad közben. 

Tehát ezt írják a gyártó oldalán (bővebben itt):

És hát rá kellett jöjjünk, hogy nem minden kifejezés világos. Vegyük sorra.
Screen Size Class. Miért "Class"? Hát mert a 27 coll körülbelül 26,9. De legalább közel áll hozzá. 

Refresh rate. 60Hz, vagyis 16,67ms (refresh rate összehasonlító videó). A Windows szerint ez 59,97, a teszten mért érték 59,94, ami kb. 1 microszekundum eltérés lehet, ennek okát most nem firtatjuk, mert hanem sosem lesz vége.  Közben belecsúszunk a Frame rate vs Refresh rate témakörébe, amiről itt bővebben olvashatsz. Röviden, a videokártya által tolt frame-szám és a monitor refresh-idejét szinkronban kell tudni tartani. Ideálisan másodpercenként 60, vagy 120, stb. frame jön ki a videokártyából és azt 60, 120, stb.  hertzen meg is jeleníti a panel, ha nem sikerül, akkor mindenféle ugrabugra keletkezik a képen.  Lényeg, hogy a mi panelünk elvileg tudja a AMD FreeSync cuccot (amire az Nvidia panelben van jópár beállítás is). 
IPS panel, ami állítólag sokkal feketébb feketét tud, mint a többiek, illetve a betekintési szöge is olyan széles, hogy nem kell megbillenteni a fotel magasságához.
A Gamutot itt tárgyaltuk részletesebben. sRGB 99%. Nem egy nagy szám manapság.

Contrast ratio, Mega. Na, ez mi az Istennyila? Emlékszünk erre a tesztre? Van ott sok más okosság is. 

A részletes leírásban 1000:1 statikus és 5000000:1 a dinamikus kontrasztérték erre a monitorra. Hát mi ennek a dinamikus izének a kapcsolóját sehol sem találtuk, pedig még az OnScreen Controlt is letöltöttük (mert ugye CD-n adták, az meg annyira, de annyira XX. század). Akinek van ötlete, ez a dinamika-dolog hol aktiválható, szóljon. Mindenesetre ez a mért érték elég lesújtó, szerencsére nem észleljük, így nem zavar a mindennapokban. Külön érdekesség, hogy a hosszú expozíció mennyire nem színhelyes, holott a fehéregyensúlyt a második tesztképen direkt fixre állítottuk, illetve hogy a négy sarokból világít be a backlight. Az alsó képeken ennek az ellenkezője látszik, de az az objektív peremsötétedésétől van. 

Response time GTG (grey to grey). Valami olyasmit jellemez, hogy milyen gyorsan tud egy pixel egyik tónusból egy másikba átállni. Valószínűleg a kristályka beforgási idejével lehet kapcsolatos. A leírások szerint ez nem egy fix érték, 0-ról 100 százalékra tovább tart, mint 10-90% között, nem kizárt, hogy a derék marketingesek egy számukra tetszetős értéket adnak meg (a bővebb leírásban van az több is, az átlag 12ms). A Response Time Compensation technikával ennek a váltásnak a gyorsasága megpusholható. Ennél a panelnél az RT azt jelenti, hogy a 16,67 milliszekundum időegységből 5ms alatt áll be a pixel a kívánt értékre. Utána a maradék 11,67ms alatt kitartja ezt az állapotot (sample and hold). Ezzel rokon a Moving Picture Response Time is (MPRT), de ettől megfájdult a fejem, annyiféle technológia létezik, és nekünk nem kell mindent átlátni. Viszont van róla szakirodalom bőven. és ha hihetünk a fent meghivatkozott tesztelős oldalnak, akkor a mi MPRT értékünk olyan 10ms lehet nagyjából. 

Color depth, 10 bit színenként, de igazából 8 bit + FRC (Frame Rate Control) ez az LG szerint 1,073,741,824 szín. Vagyis két szín villogtatásával egy köztes szín illúzióját tudják kelteni. Meg nem számoljuk, az fix, de minek a nagy számokkal dobálózni, ha még az AdobeRGB sem megy nekik. Mellesleg a Windows 10-nek nem szóltak erről a plusz két bitnyi cuccról, mert az csak 8-nak látja, Display porton, nem HDMI-n.   A 30 bites workflowról egy jópár éves cikket itt találsz. Mindenesetre az NVidiat valahogy rávettük, hogy 3*10 bitesen tolja kifelé az infót, de semmilyen teszt nem igazolta vissza, hogy ez valóban meg is történt. Pl. 16 bites fekete-fehér átmenet PS-ből, ahol kifejezetten bekapcsoltuk a 30 bites workflowt (Edit>Preferencies>Performance>Advanced>30 bit output).

Aspect Ratio, na ebben legalább igazat mondanak. 3840*2160 pixel az cakkra 16:9 arány. 

Brightness, hát a mérésünk alapján ezt nem sikerült elérni. 250 helyett 231cd/m2 (lásd a kontrasztos ábrákon).

View angle, nem mértük be, de tényleg minden életszerű oldalszögből rendben van. Azért a 178 fokot kicsit nagyképűségnek érezzük, jó hogy nem oldalról...
Pixel Pitch, 595 milliméteren 3840 pixellel ez  0,1549, de ki számolja. Ez a pixelsűrűségben 163,9 szemben az általuk megadott 163-as értékkel. A marketinges elaludt, pedig ezt még én is felkerekítettem volna.

Erre egy napunk ráment, és sehova sem vezetett, a helyedben nem is olvastam volna el idáig, már a második bekezdésnél lecsatlakoztam volna a tesztelős oldalakhoz. De te tudod. 

Forgatások

Induljunk ki ebből a 3 éves Petapixel cikkből és 10 éves videóból. Az állítás az, hogy a képet 4 lépésben ferdítjük és torzítjuk és az ugyanaz mintha egy lépésben forgatnánk . 

Vagyis mondjuk 45 fokos jobbra forgatás esetén (a videóban 30 fokot használnak) a négylépéses módszer:

1. vízszintes ferdeség -45°

2. függőleges torzítás 1/(cos45)^2  - esetünkben 200%

3. függőleges ferdeség +45°

4. mindkét irányba cos(45) - esetünkben ez 70.7106% függőlegesen és vízszintesen.

A kérdés az, hogy valóban így dolgozik e a PS. Nekünk a megérzésünk az, hogy nem. A Petapixel és Youtube közönség-különbözősége jól lemérhető a hozzászólásokban. Petapixelen azért nem csak a semmirekellő jópofáskodás megy, hanem van ellenvélemény is. Teszteljük mi is, ugyancsak egy smiley-képpel. 

A két módszer működését a fenti képen végeztük el, a jobboldali rács 5 px fekete 5px fehér vonalakból áll. Interpolációra előbb Nearest Neighbort  próbáltuk:

A baloldali a torzítgatós módszerrel, a jobboldali a sima forgatás. 100%-ban látszik némi különbség, ez azonban adódhat a kerekítésből is. A különbség ellenére egyik változat sem jobb, mint a másik.

A BicubicAuto  interpolációval már jelentős a különbség, a torzítós módszerrel egy udvar is keletkezett a fekete-sárga találkozásánál. 

A Bilinear esetén a torzításos módszer sokkal lágyabb képet eredményez. 

Összességében azt gondoljuk, hogy a négylépéses módszer négy lépésben roncsolja a képet újabb interpolációkkal, míg a forgatás, bár nem kizárt, hogy a háttérben több lépést hajt végre, de semmiképpen sem ugyanezeket. Ebből meg annyi a tanulság, hogy finom textúrák esetén érdemes odafigyelni, hogy milyen módszerrel állítunk vízszintet egy képen. Sajnos az ACR straighten vízszintező módszeréről semmit sem találtunk, de a RawTherapee összes Transform műveleténél kiválasztható a linear vagy a logarithmic. Szóval érdemes próbálgatni, de sosem lehetünk biztosak, hogy egy adott nagyításnál szemlélve a tetszetős eredmény, más méretekben is pont jó lesz. 

Tőszomszédok - Nearest Neighbor

Fogadjunk, amíg nem gondolkozol el rajta, azt hinnéd a képek zoomolgatása, legyen az monitoron, vagy telefonon, egy banális művelet, széthúzod ujjbeggyel, vagy kontroll-pluszmínusz és kész. Az is világos, hogy egy digitális kép nem nagyítható akármekkorára, vagyis a filmekben, a megfigyelő kamera két pixeléből sem a CIA, sem az MI6 nem tudja kinyerni az elkövető kilétét, de aki kicsit érdeklődő, az már hallott arról is, hogy az AI megjelenésével ez valamennyire mégsem teljesen kizárt. 

De azért az mégis mekkora varázslat, amikor a kép mondjuk 100 pixele 101 pixelen kell megjelenjen. Vagy 99 pixelen. Az előző esetben ugyanis ki kell találni egy új pixelt, a második esetben meg el kell dobni egyet. Csak hát mindezt arányosan kell csinálni, nem elég egy új pixelt valahová beszúrni, vagy egyet eltüntetni. Mind az összes (diszkrét) pixelnek változnia kell, valamilyen szabály szerint. A dolog valahol rokon a BAYER demozaikolásával, ott is nemlétező információt kell kitalálni valamennyi létező információ alapján. És a felmerülő problémák is hasonlóak, tónusok, színek nem változhatnak, éles szegélyek, apró textúrák nem sérülhetnek túlságosan, nem jelenhetnek meg ronda artifactek illetve az egész számolgatás nem tarthat sokáig, ha telefonon belenagyítasz egy csücsörítős szelfi dekoltázsába, akkor annak lag nélkül kell működnie, mert hanem már élni sem érdemes.

Éppen ezért a különféle célokra különféle módszereket fejlesztettek. A legegyszerűbb eset, ami a cím is (amivel a neten a legtöbbet fogsz találkozni, mert majd hülyék lesznek az influenszerek sérvet kapni a problémásabb interpolációktól), az amikor a képet, kétszeresére/négyszeresére/stb. növeled. A tőszomszéd algoritmus ilyenkor nem csinál mást, mint minden pixelt megdupláz (mindkét irányba), ahol eddig egy - mondjuk fekete pixel volt, ott most négy vagy nyolc fekete pixel lesz. 

De mi van, ha egy pixelből nem négyet kell csinálni, hanem másfelet, vagy hármat, vagy egy felet, vagy mittudoménmennyit? Az alábbi ábra mutatja a Nearest Neighbor logikáját néhány esetre. 

A 3*3 pixeles kép különféle nagyításai láthatóak. Itt nincs átlagolás, csak azokat az értékeket vehetik fel az új pixelek, amelyek az eredetiben is voltak (jelen esetben fehér és fekete). A kiindulási mintát képzeletben ráhelyezzük a megnövelt képre (a középső oszlopban) és annak alapján színezzük az új pixeleket fehérre vagy feketére, hogy az új rács közepe a régi rács milyen színére esik. Másképpen megközelítve, az új pixelt milyen arányban fedi a régi leosztásból valamelyik szín. Ezt a PS és más képszerkesztők is pontosan ugyanúgy csinálják. 

Ugyanez a logika akkor is, ha csökkentjük a képet, mondjuk kétharmadára. Belátható, hogyha a fenti példában a középső pixelünk hupi-, vagy tiffanykék is lehetne, az új 2*2-es képen az semmit se nyomna a latban, az új csökkentett képről simán lemarad, tehát az eredmény 2*2 pixel fekete lesz. Tehát bizonyos szerencsétlen pozícióban levő információk teljesen el is tűnhetnek.  A neten többnyire azt emelik ki, hogy ez a módszer recés széleket okoz, de szerintünk ennél fontosabb tulajdonsága, hogy a nagyfrekvenciás képi részletek esetén, a nearest neighbor nem képes maradéktalanul az eredeti élményt hozni a megváltozott képméreten. Például a fenti 3*3 fekete-fehér pepitánk távolról nézve szürke. De 2*2-re csökkentve fekete lesz, akárhonnan nézed.  Például egy 8x8-as pepita 5x5-re csökkentve ilyen lesz:

Nagyobb mintázat esetén azért már van rá esély, hogy ha a textúrát nem is, de a tónust legalább megőrzi, hiszen az új kép fedettsége is nagyjából hasonlít az eredetiére. 

És ilyen a forgatás nearest neighborral:

Amit viszont nagyon tud ez a módsze, az a kemény szegélyek megtartása (preserve hard edges). Nagy képen ez okozhatja apró részletek, textúrák részleges, vagy teljes eltűnését, de sosem fog blúrolni.  2x, 4x, 8x, stb. növelésnél meg garantált a Minecraft-hatás.

Russell Kirsch lépcső alakú pixelei

Forrás

Halála előtt kilenc évvel, Russel Kirsch (akinek a nevéhez az első digitális szkennelés fűződik 1957-ben) arról beszélt ebben a vimeóban, hogy nála sokkal okosabb emberek, 1500 évvel ezelőtt, sokkal jobb pixeleket fejlesztettek (például a ravennai mozaikok). De hiába kapacitálja a kollégákat, semmit sem tesznek ebben az ügyben. Vagyishogy végre haladjuk meg a négyzet alakú pixelt és ezzel kiszabadulhatna a fotográfia ennek a modellnek a rabságából.

Világos, hogy a pixel nem négyzet, hanem pont, a pontnak meg nincs sem térbeli, sem síkbeli kiterjedése, mert egydimenziós. De akkor próbálj megjeleníteni egy kiterjedés nélküli, teljesen pontszerű pixelt egy kétdimenziós monitoron, majd próbáld megfogni egérrel, s átszínezni meg odébb rakni. Vagy nyomtass ki mondjuk egy piros pixelt papírlapra. Kiterjedés nélkül kinyomtatható? És kiterjedés nélkül piros lesz? De még a mindennapi beszédbe is úgy épült be, hogy a "pixeles" az nem a finom pontszerű felbontást jelöli, hanem az oredenáré, recésszélű minecraftosat. 

A Mester változó pixeleit sajnos nem áll módunkban kipróbálni a gyakorlatban, ehhez meg kell várnunk, amíg egy programozó lát benne annyi fantáziát, hogy hozzáférhetővé teszi számunkra is. Az előadás alapján mi úgy értelmezzük, hogy az elképzelés alapja egy 6*6 (vagy 8*8) pontmátrix. Ebből többféle felosztással alapformákat képezne, mint itt jobbra. Ezek elforgathatóak és színezhetőek lennének a célnak megfelelően (lásd alább a jobboldali kinagyított fül-részleten).
Valahogy úgy képzeljük ezt el, ahogyan az ofszetnyomtatásban a raszterpontot, azt is 16*16 vagy egyéb felbontású mátrixban képezik. Persze az így keltett háromszög (lépcső), meg osszefordított L-betű alakú pixeleket 36 apró szubpixelből kell megképezni, de ezt csak egyszer kellene leírni és sokszor fel lehetne használni a képen (itt sejtünk némi rokonságot a JPEG tömörítéssel), emiatt kevesebb adat kellene a teljes képhez. Pont mint a fenti mozaikon, ugyanannyi darab mozaikból, mint négyzetes pixelből, sokkal jobb felbontás elérhető. Persze, csomó része nem világos a modellnek és nem is nagyon hozzáférhetőek a Mester cuccai. Emiatt nem tudhatjuk, hogy amellett, hogy számtalan előnye lenne (pl. moiresodás kiküszöbölése, forgatás), nem e okozna előre nem látható problémákat. Mindenesetre izgalmas, és a szimulációja, amit szintén a fiáról készített (mint a legeslegelső szkennelt képet a világon), elég meggyőző:

Forrás a vimeóból.
A jobboldali kép a fennebb mutatott változó pixeleket használja,
 szemben a baloldali hagyományos, négyzet alakúval. 

Na, nem tudjuk megítélni, hogy ez valóban egy progresszív út e, vagy csak habókos volt az öreg, de mindenképpen szimpatikus figura. 

Visszatérve a legelső képre, a mozaikra. Erősen szemléletes, de  egyáltalán nem fair összehasonlítani egy mozaikot és egy arról készült pixeles képet. Ugyanis a mozaikok pontosan úgy vannak lerakva, hogy kontúrokat alkossanak, a pixeleknek ez nem áll módjában lekövetni. De így legalább kipróbáltuk a Mozaik és Crystal szűrőket, nyilván ez nem ugyanaz és semmit sem állít a változó pixelekről, csak pont ez jutott eszünkbe a témáról. Vagyishogy nagyon gyenge felbontás esetén vajon jobb eredményt ad e a mozaikszerű (random alakú és elrendezésű) pixel, mint a négyzetes. Mindkét szűrőt 8 pixel értékre állítottuk, így nagyjából a felbontás is hasonló. Mint látható, nem azon múlik, hogy a pixelek ne négyzet alakúak legyenek, hanem ki kell azt rendesen találni, hogy milyen alakú pixelek hogyan is rendeződjenek. Minket itt meghalad a dolog, de nem bánjuk, hogy megismertük Russell úr gondolatait, hisz ő is egy olyan óriás, akinek a válláról ma fotózhatunk. 

Létezik analóg fotózás, és ha igen, miért nem?

Milyen alakja van a pixelnek? Kocka? Négyzet? Kör? Gömb? Esetleg pont? 

 Miért, milyen alakú a foton? Grimpix szerint a foton inkább gömb, de semmi esetre sem kocka alakú, mert ha nem lapjával, hanem például egyik sarkával esne a szemedbe, az nagyon fájna. Na jó, az éles fény, éjjel, amikor kimész a budiba, az lehet ha dobócsillag alakú. Azért fáj.  Vagy a lézernek tutti, hogy százasszög az alakja. Azért szúrja ki a szemedet. Vagy a minap a szoliban az UV-nek meg sarokcsiszoló volt az alakja, le is reszelte a bőrömet mindenhonnan. Na, hogy ezt így megbeszéltük, haladjunk.

Káoszkép tintasugaras nyomaton mikroszkóp alatt. Ha hiszed ha nem, ez egy sakktábla minta. 

A világra azt mondjuk analóg, mi meg folyton megszondázzuk s diszkrét(en) mintákat veszünk belőle, ezek az egyszeri értékek már digitalizálhatók. Például, teszem azt, 90 fokos látószög mentén, kihasítunk egy párnaszerű sík-alakzatot a világból és annak 12 millió helyen (lehetőleg egyenletesen elosztva a felületen) megmérjük az erősségét a látható fényspektrumra. Ezt ha fényképezőgéppel csináljuk (mert azzal sokkal könnyebb) akkor hívjuk ezt a mérést digitális fotózásnak. A mérés teljesen nyitott rekesz mellett kör alakú apertúrát jelent (szűk rekesz esetén valamilyen sokszöget), de mégsem gondoljuk, hogy a pixelek emiatt kör, vagy nyolcszög alakúak lennének, mint például a bokeh. 

A CMOS többnyire valamilyen téglalap alakú, de az csak azért, mert vízszintesen több pontban mérünk, erre talán egyszer érdemes lenne visszatérni, miért szeretjük jobban ezt a formátumot, mint a négyzetest, vagy kört. A CMOS egyes pixelei szintén nem négyzet alakúak, leginkább kör alakúnak lehetne mondani mikroszkóp alatt, amelyek függőleges és vízszintes sorokba vannak rendezve, de azt is mondhatnánk, hogy ez csak a mikrolencséknek, vagy a BAYER-szűrőknek az alakja. 

Nyersen, demozaikolás előtt függőleges és vízszintes mátrixba szerveződnek ezek az adatok? Mi ez a texel, átlós? pepita? sakktábla? Persze négyzetként prezentálhatjuk a pixelt, de az is világos, hogy ez csupán egy modell. 

Wiki

Mert akkor mi van a Fuji, mára már archaikussá vált, Super CCD designer-elrendezésű pixeleivel? Eleve nem egy függőleges-vízszintes mátrixban vannak ezek a csuda-sokszögek, hanem átlók mentén, ami nem kis galibát okoz a demozaikolásban, nem csoda, hogy kihalt ez a technológia.

Forrás

Arról nem is beszélve, hogy ez csak a pixel felületének az alakja, a pixel a szilícium lapka mélységében, tehát térben is kiterjed valamennyire, mint egy kocka, vagy téglatest. Tehát a pixel alakját valószínűleg nem itt kell keresni.

Az imént említett méréssorozatot, ha eltároljuk, mondjuk mérésenként 32 biten, akkor azt hívjuk digitális képnek. Eltárolva aztán sokféle alakja lehet, merevlemezen valamilyen mágneses jelek körcikkek dirib-darabjaiba rendeződve, SD kártyán a jóisten se tudja milyen hosszú adatsorok tranzisztorokba zárt töltések formájában, és ha hozzávesszük, hogy a pixelek esetleg JPEG tömörítéssel vannak kiírva, akkor kismillió átfedés is lehet a pixeladatok között a hordozón. Tehát eltárolva inkább ne firtassuk a pixel alakját, mert a formához érzékszerv kell (látás, tapintás), de a digitális adat nem is látszik és nem is tapintható. Mondjuk optikai lemezen pont látszik, lyukkártyán meg tapintható.

Forrás - valahogy így nézhet ki DVD-n a pixel.

Ha viszont meg tudjuk jeleníteni, mondjuk úgy, hogy a digitális képhez hozzárendelünk 2 millió színes lámpácskát, akkor azt mondjuk, hogy FullHD felbontásban nézegetünk képeket. Ilyenkor több képi pixelt egyetlen monitorpixel jelenít meg. De ha a kép elég kicsiny, akkor olyan is lehet, hogy egy képi pixelt pontosan egy monitorpixel mutat meg. Sőt ha istenmáriásan felnagyítod, akkor olyan lesz, mint a Minecraft, és 4-16-64-stb. monitorpixel is megjeleníthet egyetlen képi pixelt. 

De ezek a színes monitor-lámpácskák sem négyzet alakúak, hanem dupla fánkok, vagy sorba rendezett pálcikák, subpixelek. Persze ezeket a subpixel-szerveződéseket (textúra-alapelemeket, texeleket) lehet négyzetnek tekinteni, de ha már nagyon kicsik, vagy távolról nézed, akkor inkább pontok. Egy texel 6 darab fánkja mondjuk egy fehér pont. Egy telefonkijelzőn például. De ha egy óriáskivetítőt nézel húsz centiről, akkor meg kifejezetten dióda alakja van. 

A pixelek így néznek ki a Corel digitális terében

Na jó, de mi van, ha át akarsz térni az analóg térbe (akármit is jelentsen ez most)? Hogyha ezt a digitális képet ki akarod nyomtatni egy tintasugaras nyomtatóval,  akkor  egy pixelt sok-sok tintapötty (droplet) fogja alkotni. Hogy ez a droplet lecsöppenő takony formájú, vagy tökéletes gömbbé válik a papírba becsapódás előtt, tökmindegy.  A papír rostjaiban leginkább szabálytalan alakú térbeli paca lesz egy-egy képpont, amiből jó sok alkotja meg az eredeti képünk egyetlen (diszkrét) képpontját. 

Kinyomtatva tintasugarason  300 ppi-vel meg így néznek ki.

Megint más eset, hogyha ugyanezt a képet ofszet nyomtatásban, teszem azt 175 LPI ráccsal akarjuk kinyomtatni. A raszterpontok elrendeződése lehet rácsos (vonalpár) valamilyen szög mentén, de lehet szabálytalan elhelyezkedésű is, ezt hívjuk sztohasztikus rácsnak. A raszterpont alakja is sokféle lehet, kör, gyémánt, figyelembe veheti a pontnyúlást, de végső soron a raszterpont tovább bontható subraszter pontokra. 

Ez a rács például 150LPI és 2400dpi, egy DotTiff részlete kinagyítva a digit.

Ez azt jelenti, hogy egy 16*16pontos képpontmátrix ból kell megoldania a 0-100% fedettségű raszterpontot. Persze a subraszter pontok itt is négyzetként jelennek meg, de a valóságban az ofszetlemezen már teljesen más a helyzet. 

2400dpi - 175 LPI egy ofszetlemezen. 

Értjük, hogy a pixel leginkább pont alakú. De azt is tudjuk, hogy a dimenzió nélküli pontokból, akárhány gigamegapixel is legyen, csak végtelenül kicsiny képet lehetne nyomtatni. És hát a gyakorlat nem ezt mutatja. Tehát a pontnak igenis fánk, meg gyémánt, meg kutyus, meg cica, meg pálcika, meg mindenféle alakja lehet - és kész!

Na, és akkor vissza címbeli kérdésre. A wiki szerint, a jelek lehetnek analógok és diszkrétek. A világot lehet mérni álmainkkal, vonalzóval, órával, sok mindennel. De a világot kvarkok és leptonok alkotják, az idő jelenlegi egysége a Planck-idő (persze a felbontás még finomodhat idővel). A filmes "analóg" fotográfiában is fotonok dolgoznak, és ezüstklaszterek jönnek létre, amik csak akkor stabilak, ha megfelelő minimális számú ezüst atom jön létre. Nincs másfél foton, nincs másfél ezüstatom, nincs másfél Planck-idő. Semmi sem folytonos, minden diszkrét. Szerintetek ezek után állítható olyan, hogy létezik analóg fotózás? Szerintetek a világ analóg?

- Na igen, a lapos meg az új geoid, mi? - mormogta Grimpix bosszúsan  - És mind a Mátrixban vagyunk duracellnyuszik! - és lecsapta a fotólexikont.

A QR-kód halott, de élvezi

Nem, egyáltalán nem voltak illúzióink, hogy a csomagolóipar majd felismeri a QR kódok igazi lehetőségeit a költségcsökkentésre, és a környezettudatosságra. Mert a marketingnek ezek nem szempontok. Hogy ne hét nyelven (mert hétféle csomagolást mégsem lehet csinálni) hangyabetűkkel írják fel, amit 40 fölött már kihívás szemüveg nélkül elolvasni, hanem csak tegyenek rá egy QR-kódot, aztán mindenki a saját telefonján babrálja, legalább azalatt sem a facebookot görgeti. Vagy például a lepedő nagyságú gyógyszer-prospektusok helyett is lehetne a csomagolásra nyomni egy pár négyzet-centiméteres QR-t. Ami mellesleg még szép is tudna lenni. A sok favágó, papírmunkás, nyomdász meg elmehetne webdesignernek. 

Ellenérvnek felhozható lenne, hogy akkor a funkcionális analfabéták hogyan fogják megnézni hogyan hat a pirula, vagy hogy gluténmentes e a csoki? Hát az igazi analfabéták meg hogy? Na ugye?

QR creator - kicsit fapados, de ingyenes.

Aztán a másik, amit nem értünk, hogy minek kell erdőn-mezőn a tanösvények mellé (sok eus pénzből) hatalmas nagy paneleket kihelyezni, amiről aztán a szél kifújja, nap kiszíjja a színeket. Hát minek nem lehet csak egy szerény kis QR-kódot felszegezni, aztán aki akarja, az olvasgassa, az őzikéket meg nem baszná fel az ideg ahányszor csak futtából lefejelnek egy ilyen korhadó fa-monstrumot. Ennek némileg ellent mond az, hogy például a Vargyas-szorosban több a medve, mint a 4G, úgyhogy ott ne mind telefonozzatok, inkább figyeljetek oda, nehogy a lábára lépjetek a macinak.

A Visualed QR-gyártó elég aljadék módon ingyenes.
Ha beolvasod meglátod. Mellesleg máris megértetted, hogy milyen a dinamikus QR. 

A virtuális üzlet viszont szerintünk marhaság. A marketing egy újabb opportunista fattya. Ha valamit online akarunk vásárolni, akkor azt anélkül is megkereshetjük és megvehetjük a neten, hogy egy aluljáróban a pofánkba nyomnák a reklámot, meg amúgy is reklámellenesek vagyunk. Ha meg hazafelé jut eszünkbe, hogy nem vettünk kenyeret, akkor pont olyan macera egy olyan virtuális üzletet találni, ahonnan szkennelhetünk egy QR-kenyeret magunknak, mint egy igazi pékséget. Aztán van például a Munzee, ami a mára jóformán kihalt geocachingnek és a pokemon-vadászatnak valamiféle hibridje... biztos jó, annak aki szereti. 

A QR számomra úgy tűnt szinte kihalt (nálunk), de valamiféle folytonossága csak van, mások szerint még nem is jött el az igazi adventje és csak én vagyok türelmetlen (60 éve létezik és legalább 10 éve van mindenkinek okostelefonja). Na, de minket csupán a technológiája érdekel, mint a bárkódoknak. 

A kétdimenziós kódoknak, közöttük a QR egyik nagy előnye, hogy sérült állapotában, rossz fényviszonyok és random betekintési szög mellet is elég jól beolvasható. Tehát képes a sérült/hiányzó adat helyreállítására bizonyos keretek között. Ehhez nyilván valamennyire redundánsnak (forward error coding) kell lennie. A QR a Reel-Salomon módszert használja, amibe most nem megyünk bele. 

Főbb elemei, a három sarokjel, csendzónával körülötte. Pászítójelek (minél nagyobb a kód annál több), timing-sorok, formátum, verzió és hibajavító-szint információk. Az összes többi mező maga az adat. 

QR alapok, lépések, amelyek a QR-kód generálásához szükségesek.

Négy fő módot tud (és pár kiterjesztettet), ezekből minket leginkább a Numerikus, Alfanumerikus (csak nagybetűk) és a Bináris érdekel (a kínai/japán jelek nem annyira). Vegyes mód is lehetséges, ha indokolt. Ennek azért van értelme, mert így optimizálni lehet a kódoláshoz szükséges felületet, pl. a számokhoz kevesebb bit szükséges, UTF-8 szöveghez viszont már byte kell.

A kódolási mód kiválasztása után a hibajavítási szintet kell beállítani (4 szint). Nyilván a redundánsabb kód nagyobb lesz, viszont kevésbé sérülékeny.
Tehát már tudjuk, hogy milyen módon, mekkora redundanciával kell kódolni. Ez megadja, hogy mekkora mátrixon lehetséges a kódolás. A különböző méretű QR kódokat verzióknak nevezik. Jelenleg a 40-es verzió 177*177-es mátrix a legnagyobb, ez nagyjából egy A4-es lap teljes szövegét képes tárolni (L-es hibajavítás mellett, 4296 karakter - a kapacitás a kódolási módtól függ, csak számokból több mint kétszer ennyi is lehet: 7089 szám - nyilván M, Q és H hibajavító szinteken ennél kevesebb adat tárolható). QR: 40-es verzió esetén legfeljebb 16 bitet használ arra, hogy a kódolt karakterek számát megadja. 

Ezután binárissá alakítja az adatot.
Numerikus esetén 3-as csoportokra bontja a kódolni kívánt számot, ezeket binárissá alakítja (a 999-es legnagyobb háromtagú szám 10 biten kódolható, tehát egy szám 3,3 bitet foglalhat el). Például az 1977-es szám 197 és 7 felbontva, vagyis binárisan: 1100 0101 illetve 111.
Alfanumerikus esetén (csak nagybetűk) karakterpárokra bontja a szöveget. Ezeket az alfanumerikus tábla alapján megfelelteti kétjegyű számoknak. Mivel az alfanumerikus tábla 44 elemű, ezért a karakterpárokat úgy alakítja számmá, hogy az első számot felszorozza 45-tel, majd hozzáadja a második számhoz. Ezután pont mint a numerikus esetén binárissá alakítja ezeket a számokat. Például a GRIMPIX így bomlik: 

GR - 16, 27  amiből 45*16 + 27 = 747 vagyis 10 1110 1011

IM - 18, 22   amiből 45*18 + 22 = 832 vagyis 11 0100 0000
PI - 25, 18     amiből 45*25 + 18 = 1143 vagyis 100 0111 0111
X -  33           amiből 33 = 10 0001
Tehát karakterenként 5,5 bit kell, mivel két darab kettőspont (44-es a tábla szerint) már például csak 11 biten kódolható (45*44+44 egyenlő 2024).

Bináris esetén, mondjuk UTF-8 szöveg (Grimpix - így, kis és nagybetűkkel) esetén a G ASCII kódja 71, vagyis binárisan 100 0111, a kicsi r  114 vagyis 111 0010 - és így tovább. 

Tehát összeáll a GRIMPIX kódunk (ezek alapján), mondjuk legyen alfanumerikus mód (0010), 7 betű hosszú az üzenet (9 biten kódolva) 0 0000 0111, maga a szöveg pedig 10 1110 1011 11 0100 0000 100 0111 0111 és még a végére biggyeszti a 0000 terminátor kódot. Ezt pedig kitölti nullásokkal a legközelebbi nyolccal osztható számig. 

00100000 00111101 11010111 10100000 01000111 01110000 ez esetben a végére nem kell nullával felpótolni, mert pontosan 8-cal osztható. 48 bit összesen. 

Egy 1-es verziójú kódba simán belefér, Q-hibajavító kódolás esetén viszont 13*8 (lásd a táblázatból az 1-Q résznél), vagyis 104 bit hosszú kell legyen a kódunk. Gyakorlatilag a kapacitás majdnem fele kihasználatlan maradt. A 64 bitünket fel kell pótolnunk 104 bitig a szabványban rögzített pad bytokkal (a 236 és 17 bináris kódjaival) 11101100 00010001. 
104-48 bit az 56/8 vagyis 7 pad byte kell még: 11101100 00010001 11101100 00010001 11101100 00010001 11101100
A teljes kód-kolbász tehát, ha valamit el nem rontottunk közben, tehát 13 byte (104 bit):
00100000 00111101 11010111 10100000 01000111 01110000 11101100 00010001 11101100 00010001 11101100 00010001 11101100

Amíg az 1-e verziójú Q hibafelismeréshez 13 kódszó kell (104 bit hosszú adatsor), addig egy 40-es H 10208 bites, az leírva kb. 150 sor 1-es és 0-s lenne. 

Eddig csupán macerás, de elméletben követhető a dolog. A hibajavítás viszont megkavarja a dolgot rendesen. A különböző verziójú és hibajavítású QR-eknek a kódjait feldarabolják és megfelelő számú codewordokkal paritásbitekkel gazdagítják pimpelgetik, sós kútba teszik, onnan is kiveszik, stb. aminek a matematikáját most szkippeljük mi is. Itt leírja ugyan, de most nincs nagy kedvünk hozzá, talán egyszer majd visszatérünk erre is.

A QR-kód négy hibajavító szintje (L, M, Q, H) például a keremarkan interpretálásában így néz ki balról jobbra, ha  blogunk címét kell megjeleníteni:

A wiki szerint a négy szint 7-15-25-illetve 30% hibát képes visszaállítani, de nem tudjuk, hogy ez a teljes kódra, vagy csak az információra vonatkozik e. Mindenesetre a 27*27-es mátrixon (729 mező - L vagyis 7% hibajavítás) egy 30 - 32 mezős maszkot szinte bárhová tehettünk, képes volt visszaolvasni, de a pászítójelek és a körülöttük levő csendzóna csak néhány mezejének letakarásával is olvashatatlan lett az egész. A spacer, verzióinformációk, illetve a hibajavító szint információit viszont letakarhatjuk, nem zavarja a visszaolvasást.

Érdekesség, hogy esetünkben a kód 27-31-31-35-ös mátrixokból áll, tehát az M és a Q biztonsági szint között nincs méretnövekedés (verzió növekedés). Elképzelhető, hogy az M nem használja ki a 31-es mátrix lehetőségeit - mint az előbb, amikor a GRIMPIX szöveget padbyteokkal töltöttük fel - a Q meg még pont elfér benne. A QR hibajavító szintjét amúgy a bal alsó sarok két pöttye mutatja, de úgy tűnik nincs szüksége rá a kikódoláshoz, ugyanis ha ezt letakarjuk, attól még simán kikódolja. 

Forrás

Kétféle generátorral, hasonló beállításokkal, ráadásul nem is ugyanazt a mintázatot kapjuk, bár a mátrixméret meg a kinyert és megjelenített link tökéletesen ugyanaz. 

Mindenesetre, ha otthon felejtenéd az okostelefonodat, nem érdemes papírlappal, számológéppel és ceruzával nekiállni megfejteni egy QR-kódot. Az viszont elgondolkoztató, hogy szabad e az információhoz való hozzáférésünket ennyire kiszolgáltatni a robotoknak. Másképpen fogalmazva, egy robot-hatalomátvétel esetén nem e szakadunk el hirtelen és végérvényesen a digitalizált információinktól?  Avagy mennyire lehet igazán fontos az olyan információ, amihez a hozzáférésünket egy képelemző algoritmus végezheti. 

Vegye meg a QR-kód leírását, akinek van erre a hülyeségre ennyi pénze.