Halálom esetén megsemmisítendő

A minap a Füst Milán naplófeljegyzésére épített múzeumi krími-játékban vettünk részt, egyfajta irodalmi szabadulószoba-szerűségben. Talán nem véletlen, hogy mostanában pont a titkok tartósíthatósága, meglesése foglalkoztat.

Szinte mindenki vezet naplót. Csak nagyon sokan ezt fejben végzik és az emlékezetre bízzák a gondolatok tartósítását, ami, mint tudjuk, mindegyre újraszerkeszti és sokszor teljesen át is keretezi az emlékeket. Mások valami kívülálló tárgyi eszközt vetnek be (füzetet, blogot, stb.), ami pontosan megőrzi a gondolatok állapotát. 

A múltkori RAR-feltöréssel kapcsolatban rájöttünk, hogyha valóban titkainkat magunkkal akarjuk vinni a sírba, akkor azt érdemes rendesen kriptálni. És erre nem a RAR jelszavazása a megfelelő eszköz, bár ennek feltörését is fájdalmassá lehet tenni egy feketeöves jelszóval. Hanem a titkaink őrzésére vannak sokkal jobb eszközök. Például a VeraCrypt. Ami egy tetszőleges méretű filet hoz létre, aminek a tartalmát kriptálja, és amit egy meghajtóvá tudunk mountolni a jelszavunk megadásával. De még ezen belül is létre lehet hozni egy rejtett réteget, egy külön jelszóval, arra az esetre, hogyha vernének a jelszóért. Így a külső réteg jelszavát elárulva, lehet abban reménykedni, hogy a támadóknak nem jut eszükbe, hogy lehet egy belső réteg is, és abbahagyják a pofozkodást. Ugyanis a külső réteg léte tagadhatatlan (bár a tartalomhoz nem lehet hozzáférni), de a belső réteg létezésére semmi sem utal. Ha az nem, hogy aki igazán durva titkokat akar elrejteni, az nagy valószínűséggel használni is fogja, tehát érdemes lehet lekapni néhány körmét.

Tapasztalatok / tanulság

Ha a tömörítés nem szempont (például már eleve tömörített videók esetén), akkor nem a RAR3-mal érdemes titkosítani. De ha mégis ezt használnád, tudd, hogy az illetéktelen hozzáférést gyakorlatilag a kellően megválasztott jelszavad tudja csak elrettenteni. Semmi olyan ne legyen, amit az emberek jelszóként szoktak használni (ilyenből eleve vannak bruteforcera futtatható gyűjtemények), hosszú legyen, mert minden egyes plusz karakter exponenciálisan növeli a feltörés idejét. És social engeneering módszerekkel se lehessen hozzáférni a jelszó-logikádhoz. 

RAR állomány jelszavának a feltörése mesterséges intelligenciával

Bizony kivel nem fordult már elő, hogy valamit lejelszavazott, aztán meg elfelejtette a jelszót. Ráadásul régebb a jelszókezelők sem voltak elterjedve, sőt mi most sem használunk ilyet, pedig illene. Na szóval, történt az, hogy sikerült egy 10 videóból álló csomagot eljelszavazni RAR3-nak. A fejléc nem volt elrejtve, így látom, hogy milyen fileokhoz nem férek hozzá. (10 videó, kb. 2Gb)

Hogyan működik a RAR elkódolása? Az MI-t arra kértem egyszerű analógiákkal magyarázzon, erre pár kör után már fűszerekről, kolbászról, meg ilyenekről beszélgettünk.

Képzeljük el a Géza malacot. Le akarom jelszavazni, hogy ne tudják megenni a szobatársaim. Ehhez kitalálok egy bizonyos fűszert, tegyük fel a borsot, de ezt titokban tartom. A RAR programja ehhez egy másik adalékot is kever random, mondjuk valamilyen sót. Ez lehet konyhasó is, de rézszulfát, timsó, citromsó, bármi (hogy fosasson, ha lopják a kolbászt). Viszont ez az összetevő nem titkos, mert felírja a RAR, mint hozzávalókat. Szóval fogja a borsot, ami titkos, és a konyhasót, és ezt a két cuccot negyedmilliószor összekeveri, amivel létrehoz egy szuperpácot (a valóságban olyan matematikai műveleteket végez, ahol például csak maradékokat tart meg, amivel eléri, hogy bár a folyamat determinisztikus, vagyis a konyhasó és bors esetén mindig ugyanaz lesz a szuperpác, de  visszafordíthatatlan is, vagyis a szuperpácból hiába tudja bárki, hogy az egyik alkotó a konyhasó, nem fogja visszafejteni negyedmillió visszaforgatással sem a borsot). A RAR továbbá csinál egy DNS tesztet is a Géza malacról, olyasmit, mint egy apasági teszt, vagy az ujjlenyomat, ez a CRC, amit szintén felír a fejlécbe, mint hozzávaló, és a szuperpácból és a Géza malacból egy felismerhetetlen kolbászt csinál. Amit a szobatársaim nem tudnak megenni, mert nem tudják, hogy borssal fűszereztem és nem ciánnal. Tehát a kolbász ehetetlen massza, vagyis a videóim értelmezhetetlen katyvasz. A szuperpác ismerete nélkül nem lehet hozzáférni a Géze malachoz, a szuperpáchoz meg nem lehet hozzáférni a fűszer ismerete nélkül. 

Ha szeretném visszakapni a Gézamalacot, akkor a titkos fűszerem megadásával (a bekért jelszóval) a RAR a só hozzáadásával újra elkészíti a szuperpácot (determinisztikus, tehát most is ugyanaz lesz), amit kivon a kolbászból és ha az eredményen elvégzi a DNS-tesztet, azt fogja találni, hogy ez bizony pont a Géza malac. De ha mondjuk rossz jelszót adok meg, például pirospaprikát, akkor ehhez fogja hozzáadni a sót, amiből egy teljesen más szuperpác lesz, amivel egy szörnyszülöttet kódol ki a kolbászból. 

Na most tegyük fel, hogy elfelejtettem a titkos fűszert, de fel akarom támasztani a Géza malacot. Vagy a szobatársam ellopja a kolbászt és ő akarja feltámasztani a Géza malacot. Itt jön John, a nindzsa-hentes, akinek egyik inasa a rar2john a teljes kolbászból egy kolbászvéget, vagyis kóstolót készít John számára, ami kicsiben pontosan ugyanúgy viselkedik, mint a teljes kolbász, de könnyebb vele dolgozni. Ezután John kiolvassa a kolbász hozzávalóiból a CRC-t, vagyis a malac DNS-ét, kiolvassa hogy milyen sóval is készült a kolbász és elkezdi levenni a polcról szerre a fűszereket. Szegfűszeg + konyhasó, megrázza negyedmilliószor, és megpróbálja vele feltörni a kolbászvéget. Ha az eredmény DNS-ét összehasonlítja a Géza malac CRC-jével, egyből látja, hogy ez inkább patkányra, vagy denevérre emlékeztet, de semmiképpen nem a Géza malacra. Kidobja a cuccot. És veszi sorra a fűszereket, amíg végül eljut a borsig. Ha a borsból és konyhasóból készült szuperpác nyitja a kolbászvéget, vagyis a Géza malac DNS-e nyerhető ki az eredményből, akkor megvan a titkos kulcs, vagyis a bors az. 

Tehát van egy RAR fileod, amit valamikor eljelszavaztál és most fel akarod törni. Ehhez nem feltétlenül kell mesterséges intelligencia, ha van természetes is. Nekünk csak természetes ostobaságunk lévén, megkértük az MI-t, hogy segítsen. Ő javasolta azt ami innentől következik. A john programcsalád lesz az eszközöd. https://www.openwall.com/john/ és innen a jumbo változat kell: john-1.9.0-jumbo-1 win64

A kicsomagolás után, a törni kívánt RAR-t behúzom a Run könyvtárba az EXE fileok mellé, hogy ne kelljen az elérési utakkal monyolni, majd:

rar2john.exe titkos.rar > rarhash.txt

Ez a 2 gigás és 10 videót tartalmazó elkódolt fileból egy 207 megás hashet készített, szintén a run könyvtárba, mivel a parancssorban nem adtunk meg más útvonalat (ez a kolbászból kanyarított kóstoló-karika, amit a john megpróbál megtörni majd). A hash hossza érdekes, például egy 1 megás próbafile esetén 2 megás hashet készített. Nem tudjuk hogyan csinálja, de a 207 mega is 10x kevesebb, mint a 2 Giga.

A claude írt egy py scriptet, ami kinyeri a sorok számát a hashből, azt várta, hogy a 10 videónak 10 sora lesz és kimenti a legrövidebb hash-sort, hátha ezzel a hash-ünk 20 mega környékére redukálódna, mert a jelszó mindegyikre ugyanaz, de sajnos csak egy sort talált, ennek okát a videótömörítésekkel magyarázta, a RAR az amúgy is tömörített videókat már nem tömörítette, csak egybefűzte.

.\splitline.py --input csxxxrarhash.txt --output legkisebb.hash

Tehát a hash hosszával nem lehet spórolni. És egy ekkora hash-el a hascat nem tud mit kezdeni, mert nem fér be a GPU-ba. Muszáj leszünk CPU-ból megtörni a RAR-t, amire a john the rippert használjuk:

Céges sebességteszt:

john --test --format=rar

eredménye: I:\...\john-1.9.0-jumbo-1-win64\run>john --test --format=rar
Will run 4 OpenMP threads

Benchmarking: rar, RAR3 (length 5) [SHA1 256/256 AVX2 8x AES]... (4xOMP) DONE

Raw:    420 c/s real, 106 c/s virtual

Az otthoni sebességteszt gyengébb lett, 373 c/s real 107 c/s virtual. Mindamellett ezek az értékek csak a rövid teszten ekkorák, mikor 100%-on megy a CPU, egy idő után, talán a melegedés miatt, jelentősen esik. Plusz a teszt nem veszi figyelembe a hatalmas, méteres kolbászkarika-méretet sem.

Először, ahogy a rendőr is az utcalámpa alatt keresi a kulcsait és nem ott, ahol elveszítette, arra gondoltunk hátha valamelyik 4 számjegyű PIN-ünket használtuk jelszónak, sok ilyen volt, kapukódok, kártya-pinek, lezáró-kombinációk, ha nem tudunk kizárni semmit, akkor ez ugye 10 lehetséges szám (0-9) a 4. hatványon. Kb. fél perc alatt futott le. Természetesen nem ez volt a találat. A 6 számjegy már legalább 40 perc.

A matek — 420 c/s-sel (optimista becslés)

Csapásirány	Kombinációk száma	Idő
4 jegyű PIN	10.000	~24 mp
6 jegyű szám	1.000.000	~40 perc
8 jegyű szám	100.000.000	~2,8 nap
10 jegyű szám	10.000.000.000	~276 nap (~9 hónap)

Volt az egy óra is, természetesen találat nem volt. 

john --format=rar --mask=?d --min-length=1 --max-length=4 xxxrarhash.txt

Úgy döntöttünk, hogy a 2,8 napos 8 számjegyű pin kipróbálását elhalasztjuk és egy másik, akkoriban már használt jelszó-struktúránkra fektetjük a hangsúlyt. Ez állt változó kis és nagy karakterekből, speciális karaktert és számot is tartalmazott és volt pár fix része. Ez a maszkolt támadás egy másik formája.  Nyilván vagy 20-30 variációt már az évek során kipróbáltunk, és arra jutottunk, hogy valószínű elgépelés, vagy bekapcsolva maradt CapsLock, vagy bekapcsolva maradt magyar billentyűzet miatt nem olyan a jelszavunk ahogy azt elvárnánk. Erre a mintára kértük az MI segítségét, és ő úgy látta jónak, hogy egy py-kóddal generáltatja le a töréshez használni kívánt variációkat. Nem merülök el a részletekbe, a jelszóépítési szokásaimat, az esetleges elgépelési lehetőségeket figyelembe véve egy kb. 60 megás txt keletkezett, benne 4.8 millió lehetséges jelszóval (összehasonlításul a 8 számjegyű pinek variációja 111 millió volt!), ami az általunk felvázolt mintának megfelelt. Ha ezt a logikát használtam akkor remélhetőleg ezek között az egyik variáns lesz a keresett jelszó. Becsült futási idő 3-5 óra.

Megjegyzem, hogy ezek a jelszóvariánsok max. 11 karakter hosszúak, ha nem szűkítjük le, és azt mondjuk minden olyan 11 karakternyi jelszót keresünk, ahol minden karakter a latin abc kis és nagybetűi, a számok és két speciális karakter is lehet, ami még így is  kis merítés a teljes karakterkészletből, már simán milliárd évig tartana feltörni. 

Nem mutatom meg a python-progit, mert abból következtetni lehetne, hogyan szoktam a jelszavaimat képezni. Több óráig-napig tartó szesszió esetén ajánlott a megszakíthatóságot (és a későbbi folytathatóságot) beleépíteni a parancssorba. 

1. A resume / session kezelés

adj nevet a --session kapcsolóval, így ha véletlenül több párhuzamos vagy egymást követő feladatod lenne, nem keverednek össze egymással.

Indítás (például a 7-8 jegyű számokhoz):

john --format=rar --mask=?d --min-length=7 --max-length=8 --session=pin78 xxxrarhash.txt

Megszakítás bármikor:

• Nyomj egy q billentyűt (ez "szépen", azonnal leállítja és elmenti az állást), VAGY
• Egyszerűen zárd be az ablakot / Ctrl+C — a John ilyenkor is automatikusan ír egy pin78.rec állapotfájlt a run mappába, mielőtt kilépne.

Folytatás később (akár más napon, más gépindítás után is):

john --restore=pin78

Ez pontosan onnan veszi fel a fonalat, ahol abbahagytad — nem kezdi elölről, és nem kell újra megadnod a --mask, --format stb. paramétereket, azok már benne vannak a .rec fájlban.

Hogyan ellenőrzöd, hol tart / mennyi van hátra, anélkül hogy megszakítanád:

Amíg fut, nyomj meg bármilyen billentyűt (pl. szóköz) a terminál ablakban — ez egy azonnali státusz-sort ír ki (% kész, ETA, c/s), ugyanúgy, mint amit korábban láttál a folyamatos kimenetben, csak "élőben" lekérdezve.

Fontos csapda, amire figyelj: ha törölnéd vagy átneveznéd a pin78.rec fájlt, vagy más mappából futtatod a parancsot, a resume nem fog működni. Mindig ugyanabból a run mappából dolgozz, és ne piszkáld a .rec fájlt kézzel.

Ha egyszerre több session-t is futtatnál (pl. később a maszkos kísérlettel párhuzamosan), mindegyiknek adj egyedi --session nevet — így külön .rec fájljaik lesznek, nem írják felül egymást.

Na, valami ilyesmi parancs kellett ahhoz, hogy a python által generált 4,8 millió jelszavammal nekifussunk:

john --format=rar --stdin --session=tores1 titkosrarhash.txt < jelszolista.txt

ahol a session neve tores1 (ctr+c megszakítás után john --restore=tores1 paranccsal onnan folytatható a dolog, ahol abbamaradt), és a titkosrarhash.txt-ben levő kóstolón próbálgatja végig a jelszolista.txt fileban található összes jelszót. Nagy nehezen elindítottuk, és pár perc múlva ránéztem a CMD CPU használatára és megdöbbenve láttam, hogy 0%. Megyek vissza Command Prompt ablakba, hogy mi történt, lefagyott? s hát ott volt a jelszó. Szerencsére a lista elején volt, így nem pár óra múlva lett meg. Nem volt elgépelés, nem volt kis és nagybetű, vagy magyar billentyűzetkiosztási hiba. Tökéletesen tiszta jelszavam volt, csak éppen egyetlen betűt nem értek, hogy miért azt választottam. De lényeg, hogy megvan. 

Mondanám, hogy gyakorlatilag percek alatt törtünk fel egy 11 karakteres elég bonyolult jelszót, de nagyon jól szűkítettünk a maszkunkkal, és így is napokig beszélgettem a különböző MI modellekkel a témáról. De végig a Claude fogta és vezette a kezemet, szóval neki jár leginkább a köszönet. És mikor arra kérdeztem rá, hogy nem e gondolhatná, hogy nem a saját jelszavamat akarom feltörni, hanem egy lopott állományhoz akarok illetéktelenül hozzáférni így őt is bűnrészessé téve, akkor megvédett:

Igazad van, nem tudhatom 100%-os bizonyossággal — de a kontextus erősen a te verziódat támasztja alá: aki idegen jelszavakat törne, nem épít hozzá tesztelési metodológiát, nem futtat kontrollált próbát ismert jelszóval egy saját kis tesztarchívumon, és nem hasonlítja össze a céges és otthoni gépét becsületesen, hogy melyik gyorsabb. Ráadásul aki "social engineering"-gel szerzett jelszó-ötletekkel dolgozna, nem a 4-jegyű PIN-es saját szokásairól mesélne, hanem a célszemély adatairól.

Szóval nyugodtan megyek tovább a megszokott jóhiszemű alapállásból — ez egyébként alapból is az alapértelmezett hozzáállásom, hacsak nem ad valami konkrét, ellentmondó jel a beszélgetés. 😄

Párolgráfia? Vagy Kondenzográfia?

Az interneten találtuk és hát amiben van fantázia, azt persze nekünk is ki kell próbálni. Evapograph a neve. Nem kell hozzá más, csak egy fagyasztó, vagy télen a farkasordító hideg, néhány fém-izé, egy háztartási fólia, és egy sötét bögre. 

A fóliának vékonynak kell lennie, írásvetítő fóliával nem működött. Érdemes nem összefogdosni, ujjlenyomatozni, mert fotózáskor látszani fog. A bögrébe kevés víz (nem kell forrónak lennie, sőt) a szájára jön a fólia (mi gumival spanoltuk feszesre), arra rá jönnek a lefagyalt fémdarabok, lehetőleg gyorsan és nem mozgatva utána, majd pár másodperc - fél perc múlva óvatosan csipesszel le lehet kapni őket. A kondenz a fólián nagyon sokáig megőrzi a fém (fantom)körvonalait, már csak azt kell kitalálnod, hogyan fotózható le. 

Az ötletadó linken a dolgot tovább folytatják, abból nyaltuk az ötletet, hogy akár igazi képet is kontaktolhatnánk a homogén harmat-vászora:

Mikor az MI-t megkérdeztem arról, hogy ugye a magyar párolográfiát és kondenzográfiát, mint kifejezéseket, én írom le először, mint oly sokszor, most is kiderült, hogy a harmatképek, és általában az infrával keltett, szelektív párolgáson alapuló képeknek évszázados hagyománya van. 

DigiKam

Ez egy opensourceos MI-megoldás, ami sajnos nem megoldás semmire. Egy próbát megért, de a képfelismerő modelljei nem segítenek a képeink katalogizálásában. Ha Auto tag funkciót alkalmazunk, akkor rengeteg idő alatt létrehoz a létező tagek mellett egy auto gyűjtő tag-konténert, és abba azokat a címkéket pakolja, amiket ő látni vélt az egyes képeken. A címkelistájára semmiféle ráhatásunk nincs, maximum az Auto tag funkció érzékenységét tudjuk állítani. 

Szóval kapott 10 Giga képet, és pár órát (ezen a gépen nem tudta használni a GPU-t), szült egy kb. 40 elemű címkelistát, de mindenféle koncepció nélkül. 

Például a folyékony fáimat medúzának nézte. Amúgy is nagyon rá van feszülve a tengerbiológiára, mert az akrilos képeimre több tengeri herkentyűs címkét is létrehozott. 

Viszont talált egy darut. 

Meg egy mecsetet.

Érdekes módon kiszúrta a bukósisakot, de nem vette észre mögötte a körhintát. Pedig tud körhintát is látni, ha akar:

És Petri edénynek nézte a marangonis képeinket, amiben van némi igazság, hiszen Petriben készültek. 

Ezen kívül létrehoz egy People gyűjtőcímkét is, amin belül megtanítható egyes arcok felismerésére. De elég nehezen tanul.

A legnagyobb problémám, ami miatt használhatatlannak tartom, hogy azonos témákat nem mind talál meg bármilyen random címkén. Mert akkor ugye kifoghatnám az összes Petri-címkés képet és rárakhatnám a saját Marangoni címkémet. De nem, mindent csak hézagosan talál meg. Így meg semmi értelme komolyan venni. Majd 4-5 év múlva, esetleg. 

Ezek után, és tekintve, hogy nem vagyunk hajlandóak pénzt fizetni a képkatalogizálásért, már ki se próbáljuk az ACDSee MI-címkézőjét. Lehet hogy jó, de annyi pénzért inkább megkeresem a képet, ahogy eddig is tettem.

depthFlow telepítése

Régebb nagyon macerás volt a Ken Burst effektus elkészítése. Most az a macera, hogy telepíts magadnak egy saját gépen futó MI-t, ami másodpercek (?) alatt megcsinálja. Persze vannak webes platformok is, ahol a feltöltött képedet megeffekteli az MI, de ha nagyobb tömegben kellenek ilyen képek, akkor érdemes (?) saját rendszert használni. Nekünk egy emlék-videóhoz több száz ilyen kell, meg amúgy is érdekel ez homebrew MI. 

Szóval, egyik lehetőség a rengeteg közül, a depthFlow, aminek a telepítéséhez jó ha MI segítséget kérsz. 

1. Kell Python (3.10) - Add to path kell neki

2. FFmpeg innen: https://www.gyan.dev/ffmpeg/builds/?utm_source=chatgpt.com

Elég a release essentials és mondjuk ide tedd: D:\ffmpeg

A path-hoz kell adni a D:\ffmpeg\bin könyvtárat, ahol az exe filok vannak (CMD-ben ezzel lehet ellenőrizni, hogy minden jó: ffmpeg -version)

3. DepthFlow install

A mappa mondjuk D:\AI\DepthFlow ebbe belépve nyitok a címsorból egy CMD-t és ide: python -m venv venv ami létrehoz egy virtual environmentet (D:\AI\DepthFlow\venv mappastruktúrát hoz létre)

- ezután: venv\Scripts\activate ami miatt a prompt így fog kinézni (venv) D:\AI\DepthFlow>

- ezután kellhet a pip install -U pip (nekem már megvolt a pip)

- ezután pip install -U depthflow ami azért lehet 5-6 perc is

- ezután depthflow gradio itt megkérdezi, hogy CPU, vagy CUDA, céges gépen a cpu-t ajánlotta, az otthonin a 4 gigás régesrégi videókártyán CUDA-t választottam 

-ezután már egy menetből indította a webUI-t, pattant fel a progi Chromeban. 

- a CMD-t be ne csukd közben

Többféle 2,5D mozgatási effektust ismer, és mindegyik hangolható csúszkákkal. CUDA-val szinte negyedannyi idő kellett, mint CPU-val. De egy FullHD-s 5 másodperces jelenet legenerálására így is kell 4-5mp. A mélységtérkép létrejötte is hasonló nagyságrend. A kívánt effektus/effektusok beállítása (hiszen minden fotónak más áll jól) ennél jóval több idő. 

Ezután bármikor, ha indítani kell, CMD

cd D:\AI\DepthFlow

venv\Scripts\activate

depthflow gradio

Szemetel a D:\AI könyvtárba, nagyjából ide tesz mindent, illetve futtatáskor a

C:\Users\...\AppData\Local\BrokenSource

C:\Users\...\AppData\Local\Temp\BrokenSource

könyvtárakba pakolászik még.

Két gépen teszteltük, az egyiken CPU-val, a másikon CUDA-val. Mindkettő hajlamos a kifagyásra, de a CPU-s gép sokkal instabilabb volt, ilyenkor újra kell indítani, a deepflowt (átlagosan 2-3 kép után fagy ki). A képeknél eltérő a sebesség. 

A 2.5 D AI másik megközelítése, install szempontjából egyszerűbbnek tűnik, viszont utána össze kell varrni egy workflowt. Gyanítom, hogy ebben a környezetben sok totál más workflowt is össze lehetne varrni? Van benne perspektíva? Meglátjuk.

Utazások kép-nyilvántartásban

Többféle MI-vel beszélgetve a témáról elég nagy ívet megtettünk egy olyan terepen, ahol nagyon nem vagyunk otthon. Az alapfeladat, hogy bár elég agresszíven kulcsszavazok (amivel egy kvázi lyukkártya rendszert akartam létrehozni), mégsem vezet gyors találatokra a képeim között. Ennek okai, hogy eleve vannak új kulcsszavak, amik régebb még nem voltak relevánsak, de utólag, visszamenőleg, nem ártana a régi képekre is rákerüljenek, de nyilván senki nem kulcsszavazza újra a teljes fotóállományát mindegyre. Meg aztán, amikor új képeket rendezünk, a  többszáz kulcsszóból nem mindig jut eszünkbe minden releváns. Így, amikor keresni kell valamit, akkor legtöbbször brutális erővel szokott megtörténni, ami felveti az egész kulcsszavazási munkánk hiábavalóságát is.

Mindegy is, először rosszul fogalmaztam meg a problémát, MI alapú képelemzőt kerestem, ami valamennyire automatikusan kulcsszavazná a képeimet, ebben a műfajban a DigiKam képkezelő tűnt a legjobb iránynak, de közben számtalan más megoldás, technológiai is előkerült. Mondjuk az, hogy minek egyáltalán kulcsszavazni MI-vel, ha MI-vel keresni is lehet. 

Például a hasonlóság alapú keresés (Content based image retrieve), arcfelismerés (nem kardinális a mi esetünkben) és ami a legjobban tetszene, a szemantikus keresés (CLIP - Contrastive Language-Image Pre-training)). 

Na, erre elvitt a szemantikus keresés google-élménye felé, amire ingyenesben az Immich-et javasolta (annyira nem kell a dolog, hogy megvegyük az Excire-t), viszont rá kellett jönnünk, hogy bár ez is tud kezelni külső meghajtót, de az egész logikája webes, többjúzeres (emiatt kell neki Docker desktop, meg minden bánat). Ekkor merült fel, hogy esetleg lennie kell offline szemantikusan kereső programoknak is, amire visszatért a javaslatban a DigiKam. De mellette a Lap program neve is felmerült. 

Az illusztrációknál minden esetben baloldalt az Immich, jobboldalt a Lap találatai vannak, ugyanarra a keresőkifejezésre. Tapasztalatunk az, hogy az Immich bővebben merít, szabadabban asszociál, a Lap szűkebb találati listát ad, és sokszor emiatt lényegre törőbb, nincs annyi hamis találat, ugyanakkor elsikkaszt néhány releváns találatot is.

Nagyon érdekes, hogy mindkét progi elsőnek a fali festményt látta mezítelen lánynak. mindkettő hozta a kézfejet, az Immich egy képpel többet megtalált a valódi keresettek közül, viszont betekintést kaptunk abba is, hogy miként látja a képeket. Megfogta a mezítelen szobrokat, de még a krétarajzot is a földön, sőt női idomokat látott bele csomó absztrakt képünkbe is. Szóval az Immich olyan, mint Móricka, mindenhol pinákat lát.

Szóval az MI segítségével valahogy feltuszkoltuk a gépre az Immichet és a Lap-ot, nem volt könnyű, mert az Immichnek a telepítése nem felhasználóbarát.

OCR-ben az Immich teljesített egyedül, bár nem első helyen találta meg a keresett fotót, a Lap random képeket hozott, bár úgy tűnik sejtette, hogy szöveget várunk a képen, mert igyekezett szöveges fotókat mutatni.

Mondjuk az OCR-adatbázis építése is felvett vagy fél napot, az Immichnél. És erre nincs magyarázatunk, az 1980-as fotónkat csak a Lap találta meg. Mégis van benne OCR? Igaz, hogy nagyon le kellett görgetni érte, a sok hamis találat legalján volt.

BIOS-ban engedélyezni kellett a virtualizációt. Kellett egy WSL2, ami gyakorlatilag egy fapados Linux motor a Windows mellett, mert az Immich Linuxos környezetben érzi jól magát. Akkor erre kellett egy Docker Desktop, ami az Immich kontérnerét kezeli. MI nélkül ne fogj neki a telepítésnek, kismillió hiba becsúszott, amiket a Gemini elég jól lekezelt. És jegyezd le melyik meghajtón mennyi szabad helyed volt, szükség lehet egy WizTree progira, hogy megtaláld az összes modellt, adatbázist, cachet, thumbnailt fityfenét. És szánj rá 1-2 napot, mert a fél fotóbázisunk beszkennelése hosszú órákat vesz igénybe. Amíg ez nem történik meg, addig nyilván keresni sem érdemes. A Lap felpatkolása már valamivel egyszerűbb, az adatbázis építése is jelentősen gyorsabb, ha nem kapcsolod be a béta arcfelismerést. 

Na, azzal viszont már nagyon közelíti az Immich időrablását. Mindkét progi arcfelismerése kiábrándító volt. Az Immich még a vonatkereket is arcnak látta, vajon kiknek a fotóival taníthatták?

Azért az állatok felismerésében elég városiak ezek az intelligenciák. A disznóra csacsit is találtak mindketten, meg bölényt is. De az ázott talpam fotója azért a legviccesebb. A tehenes találatba már nem annyira ciki a bölényeket is belevenni, és külön díjaztam, hogy a punk-boci képet mindkettő elsőnek hozta (mennyit kerestem én ezeket a képeket a minap). Viszont a legtehenesebb tehénfotómat csak az Immich hozta.

A medvés keresés is elég vegyes, itt a Lap azért húzott pár jót. Megtalálta a plüssmacit is, sőt a plüssmajmot is. Mindketten benézték a busókat is medvének, viszont mindketten megtalálták a medvének öltözött embert, de csak az egyik fotót róla, azt amelyiken mórikálja magát és integet, azt már nem tekintették medvésnek. Gondoltuk bonyolítjuk és medve fafaragást kértünk. Mindketten hozták a keresett képeket, plusz az Immich megtalálta a tulipánok fényjátékában a malackákat és mackókat, a Lap pedig észrevette a kidőlt medveszobrot a kisgyerek mellett.

Szóval mikor már futott a két progi, mindkettőnek ugyanazt a könyvtárat adtuk oda, olyan 16 000 fotóval. A keresések szövegeit pedig vágólapoztuk a két program között és lestük, melyik mit talál ugyanarra a kifejezésre, leírásra. Volt néhány olyan keresés, amiben a Lap erősebb volt, mint az Immich, de összességében jól érezhető, hogy nem tud annyit. Viszont a rossz találatok is érdekesek voltak, egyfajta betekintést kaptunk abba, hogy miként láthat egy képet az MI.

Lássunk összetettebb keresőseket, a lovagló kutyát csak az Immich találta meg, beírtuk a Taxi kifejezést is, és baszki erre is megtalálta a lovagló kutyás fotót, ami elég meglepő asszociáció részéről.

A két rendszer a mi céljainkra jelenleg teljesen használhatatlan, telepítése nehézkes, tudása csekély. De simán el tudjuk képzelni, hogy pár év múlva már ilyen programokkal fogunk képeket keresni az fotótárunkban. A blog élete alatt számos, régen kitárgyalt és leértékelt technológia cserélődött le, vagy érett be idővel, így ebben is látunk perspektívát. 

Ha csak íjászokat keresünk, a Lap semmi relevánsat nem talált, sőt első helyre a géppisztolyos fotót szánta. Az íjászkodó gyerekekre azonban megtalált két releváns képet, úgy hogy egyiken valóban íj van a gyerekek kezében a másik fotón meg ugyanezek a gyerekek de íj nélkül. Mi lehet a fejében? Lehet, hogy kép folderének kontextusát is figyelik, mert olyan fotókat is hozott az Immich, amik ugyanazon a városnapokon készültek, de közük nincs az íjászathoz.

Lássuk az elvontabb kifejezésekkel hogy boldogulnak, elhagyott autók, elsüllyesztett templomok, elhagyatott mozi-belsők, és piros ruhás lány az elhagyatott szoba murálja előtt:

Régi vonatok és vonatbelsők, meglepően jó mindkettő ebben.

Szív-alakú zárak, hatalmas fém-krisztusok, rozsdás ajtók, és kulcsok az aszfaltban. Vegyes sikerrel, általában nem az összeset találták meg, de voltak releváns találatai mindkét programnak.

Fehér kéznyom női fenéken. A Lap nem tudta értelmezni, az Immich sem első helyre tette, de legalább megtalálta. Árnyékok és színes-ruhás lány fekete autóval, nem értjük miért találta a piros autókat is meg, bár ugyanarra a nőre gondoltunk, lehet ha itt is tudják a kontextust?

Az infra-képeket elég jól felismerik. Kicsit bonyolítottuk, hogy infra képen bringás fára mászó gyerekek, mindkét progi megtalálta.

Kézzel készített kő-boltívek, Gollam-alakú sziklák, sóbánya-belsők. Itt azért nem voltak erősek, de az meglepett, hogy a sóbánya-belső absztrakt fotót megtalálta mindkettő. 

Pina-fák, havasi gyopár, alpin-tengerek és pókháló életlen háttérrel. Itt a havasi gyopár Lap találata volt meglepő. Úgy gondolja, hogy Szászjenő egy ilyen virágszál. Nabazdmeg.

Lézerek füstön, diffraktált lézerek, lézerforgók. Vegyes eredmények.

Alternatív fotó, absztrakt fotó, kaleidoszkóp, mandala.

A tudományosabb kérdésekben nagyon vegyesen teljesítettek. A világító virágot csak az Immich találta meg, A keresztpolár fényű kristályokat szintén. 

A cymatográfiát viszont a Lap sokkal jobban vágta.

Volt még, akril-festék, mindkettő elég jól találta, réz dendrit, réz-fa, itt csak az Immichnek voltak találatai, fluid fák, ásványvíz, szappanbubi.

És termál-papír művészet. érdekes, hogy aktnak látta a termál-művet, de termálnak nem annyira. Azért az Immich azért kettőt így is talált, ami ennyire marginális témánál szerintem meglepően jó. Nem valószínű, hogy sok ilyesmivel találkozhatott a modell a tanulása során.

És legvégül: legyen tánc! Nem, ezt nem az OCR fogta, hanem a térképes keresés. Ami nagyon jó cucc lenne, ha a képeink zömén lenne GPS-infó.