2016. augusztus 12., péntek
A kísérlet 2016. - Második rész
Fotók Lego elemekre történő mozaikos leképezésére írtam már korábban is programot. Tavaly nyáron (2015. augusztus) a Python nyelvvel való ismerkedésem egyik mementójaként készítettem egy kódot, ami képet kap bemenetként és elkészíti annak 1x1-es platekre, vagy csempékre hangszerelt mozaikját. A kód számos sebből vérzett, de a ráfordított idő arányában egész jónak számított. Első lépésben a képet lekicsinyítette 100 pixel szélesre, és egy megfelelő arányú magasságra, majd ezt az indexképet bontotta fel 20 egyforma darabra soronként. Az eredmény nem ritkán Error volt, mivel sok esetben indexelési hibákat generáltam a nem megfelelő arányok miatt.
Az egyes Lego elemeket reprezentáló pixelcsoportok elemeit először érvényes Lego színkódokra állítottam euklideszi távolság használatával, majd ezek közül többségi döntéssel választottam ki a nyerő színt. A kép nagy vonalakban emlékeztetett az eredeteire Természetesen minél nagyobb volt a felbontás részletessége, annál nagyobb volt a hasonlóság. Sajnos nem maradt fenn kép a keletkezett végeredményről. A kódot sikerült megmentenem az azóta bekövetkezett merevlemez hiba ellenére, így egy év elteltével már nem a nulláról kezdtem a program írását.
Ezek a lépések még távolról sem érintették az előző részben említett három fontos tényezőt. Első célul azt tűztem, hogy egyrészről megszüntessem a hibákat és egy univerzális méretekkel dolgozó kódom legyen, másrészről pedig egy olyan programrész megírását irányoztam elő, ami a képfájl mellett legenerálja a Lego tervezőprogramban is használható fájlformátumot is (.ldr).
Az univerzális méretezést úgy oldottam meg, hogy nem a képet méreteztem át, hanem az eredeti képméretet minimális igazítás után felbontottam egy paraméterezhető szélességű egyforma részre, valamint a hozzá igazodó magassági paraméter szerinti a függőleges felbontást is elvégeztem. Így megszűnt a túlindexelés. Ezek után meghagyhattam a korábbi kód felbontást végző részét, amely a tényleges képfájlt generálja.
A harmadik kifogásolt hiányosságot mindjárt az elején megpróbáltam orvosolni. Az eredeti Lego színkódokat kigyűjtöttem és RGB-re konvertáltam, Az euklideszi távolságot ezektől az értékektől számoltam, így őrizve meg a valósággal való kapcsolatot. A színek és elemek összerendelésére később az alkatrészszám csökkentésekor még szükség lesz!
Adott tehát egy program, ami kép input alapján előállít egy paraméterként kapott elemszámnyira felbontott képet, ami már valós Lego színekben pompázik. A három probléma egyikét (félig) már elimináltam. De a java még hátravan...
2016. augusztus 8., hétfő
A kísérlet 2016. - Első rész
Közel három évvel ezelőtt egy kora-téli délutánon érdekes kísérletre szántam el magam. Lego mozaikokkal kezdtem el foglalkozni, és különösen érdekelt az, hogy miképpen lehetne szebbet, jobbat, mást alkotni, mint mások. Már akkor is számos online mozaikgeneráló alkalmazás létezett a probléma megoldására, azonban bosszantott, hogy valamennyinek van valami apró defektje, ami az én maximalista szemléletemet igencsak zavarta.
Akkor néhány dolgos órát szántam ugyan arra, hogy egy készre generált mozaikot saját magam próbáljak kevesebb elemből is előállítani, végül nem foglalkoztam túl sokat a dologgal. Az akkori informatikai tudásom és leginkább az akkori munkamorálom visszatartott attól, hogy érdemben elkészítsek valamit a feltárt problémák orvoslására.
És ha már annyit emlegettem itt problémákat, a minap végiggondoltam, hogy mik is ezek a zavaró apró és nem apró pontatlanságok, amik az általam vizsgált és használt mozaikkészítőket körülveszik.
Alapvetően mindegyik generátor képet kér bemenetként, különösebb megkötés nélkül. Némelyiknél beállítható, hogy milyen formátumú felbontást (plate oldalfal, csempe, stb) akarunk használni. Jobb helyeken még a felhasználni kívánt színeket is kiválaszthattam.
Az általam kifogásolt dolgok az alábbiak voltak:
Akkor néhány dolgos órát szántam ugyan arra, hogy egy készre generált mozaikot saját magam próbáljak kevesebb elemből is előállítani, végül nem foglalkoztam túl sokat a dologgal. Az akkori informatikai tudásom és leginkább az akkori munkamorálom visszatartott attól, hogy érdemben elkészítsek valamit a feltárt problémák orvoslására.
És ha már annyit emlegettem itt problémákat, a minap végiggondoltam, hogy mik is ezek a zavaró apró és nem apró pontatlanságok, amik az általam vizsgált és használt mozaikkészítőket körülveszik.
Alapvetően mindegyik generátor képet kér bemenetként, különösebb megkötés nélkül. Némelyiknél beállítható, hogy milyen formátumú felbontást (plate oldalfal, csempe, stb) akarunk használni. Jobb helyeken még a felhasználni kívánt színeket is kiválaszthattam.
Az általam kifogásolt dolgok az alábbiak voltak:
- Végtelen pazarlás.
Minden esetben szigorúan 2D-s pixel (elem)tömbben gondolkodtak, ami azt jelenti, hogy egy nagy felületet is szépen kicsempézett 1x1-es elemekből. Nem csupán pazarló, de stabilitás szempontjából is katasztrófa. - A fizika törvényeinek semmibevétele. Az előzőből következik, hogy mindent 1x1-es elemből megoldva csempézni még csak-csak lehet, de plate oldalfalakból már csak szép, független tornyok keletkeznek, ami maga a katasztrófa.
- Elrugaszkodás a Lego univerzumtól.
A színhasználat sok esetben totálisan szabad, maximum az eredeti kép színeiből képez egy redukált halmazt, magyarán MEGVALÓSÍTHATATLAN. Szép, mutatós, de sohasem készül el, maximum 3D nyomtatóval.
Adott volt tehát a feladat (és szerencsére az idő is), hogy cukor, só és minden bigyó felhasználásával megalkossam a tökéletes mozaikkészítő alkalmazást. De a konkrét implementálásról majd csak a következő részekben...
Feliratkozás:
Bejegyzések (Atom)

