A legutóbbi bejegyzésben részleteztem, hogyan korlátoztuk jelentősen a nyilvános PDF-generálási funkciók elérhetőségét a museum-digital rendszerben a rendelkezésre álló erőforrások szerint. Ez azonban, mint kiderült, nem volt elegendő a rendszereink megbízható stabilitásának biztosításához. Miután a szerver ismét leállt december 26-án, az IIIF Image API-t ugyanabba a PHP-környezetbe helyeztük, amit a PDF-generálás is használ – ez azt jelenti, hogy bármely felhasználó/IP csak 10 lekérést hajthat végre percenként, és bármely museum-digital példánynál csak egy PHP worker szolgálja ki azt. Ez lehetővé tette, hogy a frontend többi részén a maximálisan elérhető erőforrásokat jelentősen csökkentsük. (Két eseten kívül, ahol az IIIF Image API akár 80 MB RAM-ot is használhat és a frontend más része nem haladja meg az 5 MB-ot). Azóta a rendszer úgy fut, mintha az AI scrapelés soha nem lett volna probléma.

Korlátozott búcsú az IIIF-től és a szerveroldali képmanipulációtól

Mit jelent ez a gyakorlatban? Egyrészt nem távolítottuk el teljesen az IIIF kép API-t. Minden általa generált link érvényes marad és továbbra is kiszolgálásra kerül, még ha viszonylag lassan is.

Másrészt a felhasználói élmény az IIIF-nézőben való képböngészéskor jelentősen romlik, bár ez nagymértékben függ az adott IIIF-nézőtől. A legnépszerűbb „teljes” IIIF-nézők a Mirador és a Universal Viewer. Jelentős problémák (vagy a tárgy képeinek teljes használhatatlansága) várhatók a Mirador esetében. A Mirador alapbeállításban a képet több szegmensre bontva tölti be, majd ezekből állítja össze a megjelenített képet. A szegmensek létrehozása a szerveren történik, így erőforrást igényel központilag. Emellett rendkívül alacsony határidőket szab a válaszidőkre, amit a museum-digital IIIF Image API-ja most rendszeresen túllép az agresszív lekéréskorlátozás miatt. Ha csak az Universal Viewer demó telepítését nézzük, a szoftver sokkal célzottabban hívja az API-t, és a korlátozások ellenére még jól működhet.

Amennyire tudom, nincsenek publikált adatok az egyes IIIF-nézők piaci részesedéséről, illetve arról, hogy a API-tól független IIIF-nézőket valójában mennyire használják rendszeresen. A legszkeptikusabb – és valószínűleg helytálló – feltételezés az lenne, hogy azoknak a felhasználóknak az aránya, akik IIIF-et használnak API-mellett nem hosztolt nézővel, elhanyagolható, és a legtöbben a fent említett nézők egyikét használják. Tapasztalatunk ismét alátámasztja ezt: 2020-ban adtuk ki az IIIF 2 implementációnkat, de lényegében senki sem vette észre, amíg nem kezdtünk IIIF-nézőt is hosztolni.

Mivel a Miradort használjuk nézőként, feltételezhetjük, hogy a museum-digital „látható” IIIF kép API-ja többé-kevésbé nem működik megfelelően. Azok a fejlesztők, akik közvetlenül használják az API-t Mirador telepítése nélkül, még mindig profitálhatnak az API-ból. De ezek viszonylag kevesen vannak.

Az IIIF Image API számára biztosított erőforrások radikális korlátozása így valószínűleg egy búcsút jelent az IIIF-től, korlátozott formában. Az alapötlet nagyszerű: egységes módon hivatkozni egy kép részeire (vagy később egy szélesebb médiafájlra) és annotálni azt. A megnövekedett botaktivitás, a csökkenő források és a várhatóan növekvő hosztingköltségek idején a mi példánk korai jelzés lehet arra, hogy az API-t a szolgáltatók által implementált módon meghatározó döntés korlátozza az IIIF teljes támogatásának lehetőségét a jól felszerelt intézményekre. És ahogy a források csökkennek, egyre kevesebb intézményre jut. Reméljük, hogy az IIIF által kívánt alapvető cél más módon is elérhető lesz a jövőben; oly módon, ami bárki számára hozzáférhető. Reálisan ez azt jelenti, hogy a számításnak a kliensgépeken kell történnie, nem a szerveren.

Hogy a történet pozitívan záruljon: mióta korlátoztuk az IIIF Image API-t, rendszereink újra kiválóan futnak, és lehetővé vált a museum-digital portáljainak további lekéréskorlátozásainak csökkentése. Figyelni fogjuk a helyzetet, és fokozatosan növeljük a limiteket, hogy több egyidejű API-lekérés engedélyezett legyen anélkül, hogy a stabilitást veszélyeztetnénk.

Kommunikáció

Másodsorban az egész ügy kihívást jelentett a kommunikációs csatornáink számára. Ha bárhol jelentős hiba történik a museum-digital rendszerben, én személyesen titkosított hibaüzenetet kapok e-mailben. Általában. Ebben az esetben a fő komponens, ami leállt, a PHP-szerver volt, amely a levelek küldéséért is felelős. Ha egy szolgáltatás leállt, az elsődleges módja a hibáról való értesülésnek az volt, hogy erről kaptunk e-maileket. Így a reakcióidők rosszabbak voltak, mint kellett volna. Ez azt jelenti, hogy javítanunk kell a monitorozást.

Másrészt az is problémát jelentett, hogy elmagyarázzuk, mi történik. Volt egy fórumtémánk a fórumon, amit kevesen olvastak. Voltak a blogbejegyzések, amelyeket szintén kevesen olvastak. Hiányzik (vagy hiányzott) egy egységes információforrás a jelenlegi eseményekről, amit feltételezhetően mindenki olvasna. A blog pontosan ezt a célt szolgálhatná és kellene, hogy szolgálja.

A musdb bejelentkező képernyőjének jobb felső sarkában évek óta a régió legutóbbi két blogbejegyzését, valamint a blog „fejlesztés” kategóriájának legfrissebb bejegyzéseit mutatjuk. Ezután alapértelmezetté tettük a „maradjak bejelentkezve” funkciót, ami azt jelenti, hogy az emberek már nagyon ritkán látják a bejelentkező oldalt.

A legtöbb felhasználó első oldala bejelentkezéskor vagy musdb megnyitásakor a „főoldal”, amelynek alapértelmezett aloldala korábban összefoglalót nyújtott a felhasználó által elérhető adatbázis-tartalomról, egy csempét a személyes jegyzetekhez, egy csempét a régió adminisztrátorainak üzeneteivel, egy csempét a Discourse fórum integrációjához, valamint linkeket a múzeum webes megjelenéséhez.

Az adatbázis-tartalom összefoglalója és a múzeum linkjei mindenképp hasznosak. A többi funkció kevésbé. Az aktuális használat ellenőrzése azt mutatta, hogy szinte senki nem használta a jegyzetfunkciókat (valószínűleg azért is, mert a musdb máshol jobb alternatívát kínál), míg a Discourse integráció évek óta nem volt használatban. Így a musdb elsődleges funkciói nagyrészt kihasználatlanok maradtak, miközben helyet foglaltak, amely a releváns blogbejegyzésekhez tartozó feed számára hasznosítható lett volna.

Ezért eltávolítottuk a használaton kívüli funkciókat, és helyettük egy esztétikailag tetszetősebb feedet helyeztünk el. Ez a feed most tartalmazza a felhasználó nyelvén a fejlesztési feed két legújabb blogbejegyzését, a regionális vagy nemzeti feedet (szintén a felhasználó nyelvén), valamint – ami fontos – az angol nyelvű fejlesztési feedet. A legfrissebb fejlesztéssel kapcsolatos bejegyzések egyikét sem fordítottuk le más nyelvre, főként azért, mert az időt inkább a problémák enyhítésére vagy javítására fordítottuk, nem pedig újabb nyelven történő leírására. Ráadásul a legtöbb felhasználó elég angoltudással rendelkezik a bejegyzések megértéséhez. Azok számára pedig, akik nem: a közösségi hozzájárulások – beleértve a fordításokat is – mindig szívesen látottak.

Az eredeti szöveget Joshua Ramon Enslin publikálta, 2025. december 29-én.
Forrás: https://blog.museum-digital.org/2025/12/29/trimming/

Ez a tartalom a Creative Commons Attribution 4.0 Nemzetközi licenc alatt érhető el.

Ennek megfelelően kibővítettük az erőforrás-igényes kulcsfunkciók újragondolására irányuló erőfeszítéseinket a nagyobb stabilitás érdekében. A korábbi gyakorlattól eltérően most már olyan funkciókat is teljesen eltávolítunk vagy letiltunk, amelyek a jelenlegi körülmények között egyszerűen nem tarthatók fenn.

PDF-generálás

Eddig alapvetően kétféle PDF készült (szerveroldalon) a museum-digital portáljain: egyrészt a tárgyoldalak PDF-reprezentációi („adatlap”), másrészt olyan PDF-ek, amelyek egy tárgy összes képét egyetlen dokumentumba foglalták az egyszerű nyomtatás érdekében.

Ez utóbbi – már a feladat jellegéből adódóan is – rendkívül erőforrás-igényes volt. Az összes képfájlt be kellett tölteni, beágyazni a PDF-be, tömöríteni, majd elérhetővé tenni. Emiatt ez az opció egyre kevesebb tárgynál volt elérhető. Míg eredetileg minden háromnál több képpel rendelkező tárgynál használható volt, később már csak a 40 képnél kevesebbel rendelkező tárgyakra korlátoztuk. Így az elérhetőségét egyre nehezebb volt egyértelműen kommunikálni, miközben a hasznossága csökkent az összes kép letöltését lehetővé tevő új funkció bevezetésével. Az alapvető erőforrás-igényesség azonban megmaradt, és mivel a scraperek minden elérhető linkre rákattintanak, ez a PDF-generálási forma továbbra is meglehetősen gyakran futott (a legutóbbi botaktivitás-növekedés előtt néhány másodpercenként). A funkciót a múlt héten teljes egészében eltávolítottuk.

Az „adatlap” PDF-ek generálását szintén tovább korlátoztuk. Ahogy az előző blogbejegyzésben is írtuk, a hasznosságuk jelentősen csökkent a nyomtatási stíluslap bevezetésével (jobb eredményt érhetünk el, ha egyszerűen a CTRL + P billentyűkombinációval nyomtatjuk PDF-be a tárgyoldalt). Ennek ellenére továbbra is népszerűek maradtak, ezért nem szüntettük meg őket teljesen. A szerver stabilitásának védelme érdekében azonban további korlátozásokat vezettünk be: ha a szerverterhelés a kényelmes szint fölé emelkedik, a PDF nem készül el, és hibaüzenet jelenik meg. Ha a terhelés magas (a kényelmes szint kb. 70%-a felett), és a felhasználó böngészőjének nyelve nem az adott museum-digital példány alapértelmezett nyelve, ugyanez a hibaüzenet jelenik meg.

Sikertelen keresési oldalak

Ha egy tárgykeresés nem ad találatot, a felhasználó egy sikertelen keresési oldalra kerül, ahol alternatív keresési javaslatokat kínálunk. Ez lényegében ugyanaz az elv, mint amikor a Google automatikusan javításokat javasol elgépelések esetén. Az alternatívák azonosítása és az előnézetek felkínálása azonban nem „ingyenes”: erőforrásokat igényel, miközben a javaslatok hasznossága és pontossága esetről esetre változik.

A naplófájlokat vizsgálva nagyszámú lekérdezést láttunk nem létező entitásokra – nyilvánvalóan olyan scraperektől, amelyek az URL-sémát elemezve különböző azonosítókat próbálgattak. Minden egyes ilyen lekérdezés lefutott, majd a sikertelen keresési oldalra irányított, ami újabb javaslatok és előnézetek betöltését váltotta ki, így kevés haszon mellett további szervererőforrásokat használt (azon túl, hogy még több letapogatható linket kínált). Most a PDF-adatlapoknál alkalmazotthoz hasonló logikát vezettünk be: a javaslatok és előnézetek csak akkor generálódnak, ha a szerverterhelés viszonylag alacsony, és ebben az esetben is az elsődleges nyelvet használó felhasználók enyhe előnyt élveznek.

Idővonalak

Az idővonalak továbbra is népszerűek, de egyben problémásak is. A naplókban gyakran láttunk olyan lekérdezéseket, amelyek az idővonalakat kezdő- és záródátum szerinti kereséssel kombinálták. Ez valószínűleg egy újabb, végtelen URL-generálási ciklus lehetőségét jelentette a scraperek számára: megadni egy idővonalat, ami továbbirányít egy adott időszakra szűrt keresési oldalra, majd megnyitni az adott időszak idővonalát. Ezt a viselkedést most lehetetlenné tettük. Ha egy keresésnél idővonal-alapú szűrés („után”, „előtt”) van beállítva, az idővonalak többé nem jelennek meg az oldalsávban. Ha valaki URL-manipulációval vagy az API-n keresztül mégis megpróbálja őket előállítani, hibaoldalt kap.

Keresés: rendbetétel, képkeresés és entitások ellenőrzése

Egy összetettebb optimalizálás érintette a tárgykeresés magját is. Körülbelül 2021-ben vezettük be az új keresési logikát. Szinte minden, a központi keresési logikára épülő oldal – keresési eredményeket összefoglaló oldalak, térképek, idővonalak – átállt erre. Egyetlen kivétel volt: a képkeresés. Mivel azonban az új keresési logika újrahasznált bizonyos funkciókat a régi keresésből, mindkettőt külön osztályként tartottuk meg, amelyek idővel egyre nőttek. Már önmagában az új keresési logika betöltése is körülbelül 1 ms-ot vett igénybe (OPCache nélkül, PHPBench-csel mérve). Ez elsőre kevésnek tűnhet, de a kód modularizáltságának hiányára utal, és jelentőséggel bír sok kiszámíthatatlan kérés esetén.

Valóban, az új keresési logika írásakor nem választottuk szét kellőképpen a HTML-generálást, a lekérdezés-összeállítást és az adatbázis-lekérdezést. A múlt heti frissítésekkel ezekhez most külön osztályok tartoznak, és a kizárólag a régi keresési funkciókhoz kapcsolódó elemek átkerültek a képkeresési logikát kezelő osztályba. Ez az új / fő keresési logika indulási idejét körülbelül a felére csökkentette (kb. 0,6 ms).

Másodszor, csökkentettük a képkeresésnél elérhető keresési opciók számát. A megmaradó paraméterek vagy valóban a képekhez kapcsolódnak, vagy a kontrollált szótárakhoz kötődnek. Pozitív mellékhatásként ez kommunikációs problémákat is megold: eddig nehezen volt érthető a különbség aközött, hogy a képeket a saját licencük, vagy az általuk ábrázolt tárgyak (nem feltétlenül kapcsolódó) metaadatainak licence alapján keressük.

Végül, ahogy fentebb is említettük, a naplók sok olyan lekérdezést mutattak, amelyek például teljesen nem létező helyekhez, vagy olyan helyekhez kapcsolódtak, amelyek egyetlen tárgyhoz sem kötődnek. Ezért amikor egy helyre vagy kulcsszóra keresnek, már a lekérdezés összeállításakor ellenőrizzük, hogy az adott bevitelnek van-e bármilyen nyilvános előfordulása az adott példányban. Ha egyáltalán nincs kapcsolat, akkor egyértelmű, hogy a bevitel más paraméterekkel kombináló, részletesebb lekérdezés sem fog eredményt adni.

A jelenlegi helyzet

Mindezek a fejlesztések segítenek, de érdemes ránézni a jelenlegi valós adatokra is. Egyrészt az adatbázis-szerver terhelése most gyakran a várható érték felére vagy akár az alá is csökken. Ez pozitív jel a rendszer stabilitása szempontjából a csúcsidőn kívül.

Másrészt jól látható terhelési csúcsok jelentkeznek reggel (Németországban kb. 10:20 körül) és délután (kb. 17 óra körül kezdődően). A reggeli csúcs valószínűleg a munkanap kezdetéhez kapcsolódik, és a múlt héten többször is a szerver leállásához vezetett. Ezt feltehetően csak a PHP-FPM beállításainak további finomhangolásával lehet orvosolni. A délutáni és kora esti csúcsok okai nehezebben magyarázhatók, de összességében sokkal kevésbé kritikusak.

Dolgozunk rajta.

Az eredeti szöveget Joshua Ramon Enslin írta, 2025. december 22-én.
Forrás: https://blog.museum-digital.org/2025/12/22/cleaning-out-our-closet/

This content is licensed under a Creative Commons Attribution 4.0 International license.

1. ︎

A scraper (magyarul gyakran: adatgyűjtő robot, webes letapogató) egy olyan automatikus program vagy bot, amely weboldalakat látogat végig, és adatokat gyűjt ki róluk.

Verziókezelés

A MúzeumDigitár egyik fájóan hiányzó funkciója a részletes verziótörténet volt a rekordok esetében. A verziókezelés lehetővé teszi az adatok visszakövetését vagy visszaállítását egy elrontott tömeges feldolgozási kísérlet vagy egy mező tartalom véletlen törlése után.

Mostantól egy tárgyrekord összes korábbi verziója megtekinthető a „Rekord történet” fülön. A felületen egy új „Verziókezelés” (jelenleg: Open Versioning, fordítás hamarosan) gomb jelenik meg a fül tetején.

A gombra kattintva egy felugró ablak nyílik meg, amely táblázatos formában jeleníti meg a különböző verziókat. A tárgy különböző adatai külön füleken érhető el és ezáltal külön táblázatokra vannak bontva, például Alapadatok, Esemény, Kulcsszó stb.

Tömeges adatátvitel

Egy másik gyakran kért funkció – különösen importálás után – az a lehetőség, hogy egy tárgy egyik adatmezőjének tartalmát át lehessen vinni egy másikba.

Mint minden más „Tömeges változtatás” a tömeges átvitel is egy keresés találataira vonatkozik. A funkció elérhető a Tárgy menüpont oldalsávjából, miután egy keresést végrehajtottunk.

A szabad szöveges mezők mellett két „speciális forrás” is választható a Kiegészítő fülről. A „részletes méretadatok” és a szeparált „anyag” és „technika” mezők. Az adatmezők közötti átvitel során a célmező tartalma felülírható a forrásmező tartalmával, vagy a forrásmező tartalma elé vagy mögé fűzhető.

Az adatátvitel a musdb API-ján keresztül is használható. Ehhez egy új API útvonal került bevezetésre: /object/transfer_by_search/{mode}.

Ha a kis helyi örökségközpontok vagy a kiterjedt önkormányzati gyűjtemények kiállítási tárgyait az érdeklődők otthonuk kényelméből is megtalálhatják, és interaktív módon, időtől és helytől függetlenül minden oldalról megtekinthetik, az minden bizonnyal nagy hozzáadott értéket jelent.
Ezt teszi lehetővé például a 3D digitalizálás és a tárgyak MúzeumDigitár-on keresztül történő közzététele. Azonban a 3D projektek elriaszthatják a kollégákat, mivel gyakran olyan mértékű erőforrásokat igényelnek, amelyek a legtöbb múzeumban nem szerepelnek a tervezett költségvetésben. Különösen a pénzügyi kérdések állnak gyakran a 3D-digitalizált tárgyak felé tett első lépések útjában. De nem kell, hogy így legyen!

Alacsony küszöbértékű 3D megoldások

Mára már léteznek jó megoldások, amelyekkel kis pénzügyi ráfordítással lehet 3D modelleket készíteni és azokat közzétenni. Egy lehetséges utat szeretnénk itt röviden vázolni, és bemutatni, hogy a 3D technológia a MúzeumDigitár segítségével költséghatékonyan hozzáférhető.

A Bautzeni Sorbiai Intézet hasonló problémával szembesült egy harmadik fél által finanszírozott projekt keretében, amelynek célja Lotar Balke gyűjteményének fényképes rögzítése volt.

Mintegy 2000 szorbiai húsvéti tojást kellett lefényképezni és lépésről lépésre dokumentálni a MúzeumDigitár segítségével (Húsvéti tojásgyűjtemény, folyamatban). z így létrejött metaadatok a jövőben a Szorb Kulturális Nyilvántartásba kerülnek. A projektben azonban nem tervezték drága 3D technológia beszerzését. Azonban a projektben nem szerepelt drága 3D technológia beszerzése. Mégis úgy ítéltük meg, hogy figyelembe véve a 3D digitalizálás terén bekövetkező fejlődéseket, érdemes legalább néhány háromdimenziós digitális másolatot készíteni és kipróbálni a munkafolyamatokat.

Drága technológia – honnan szerezzük be, ha nem lopjuk el?

A 3D technológia piaca az elmúlt években jelentősen megnőtt, és a különböző készülékek kínálata a közösségi médiás alkalmazásokhoz használt olcsó 360 fokos kameráktól a több tízezer euróba kerülő nagyméretű professzionális készülékekig terjed. A múzeumi gyűjtemények munkatársai ezzel egy átláthatatlan választékkal szembesülnek, amely különböző megközelítéseket kínál a fizikai világ háromdimenziós ábrázolására. Ahhoz, hogy alaposan megismerkedjenek a mögöttes technológiával és megalapozott döntéseket hozzanak saját igényeikről, gyakran nincs elegendő idő. Ennek ellenére a múzeumok és archívumok digitalizálási projektjeivel szemben támasztott követelmények egyre magasabbak.

Annál örömtelibb, hogy városi területeken fokozatosan alakulnak olyan helyek, amelyek megkönnyítik a hozzáférést a modern technikához. Ezek gyakran angol nevükön ismertek, amelyek a közreműködő jellegüket hangsúlyozzák. Így például Drezdában egy Makerspace, Cottbusban a CreativeOpenLab (COLab), Bautzenben pedig a Coworking- és Makerspace Tagwerk működik. Céljuk, hogy lehetőséget biztosítsanak az emberek számára, hogy ingyenesen vagy alacsony költségek mellett valósítsanak meg olyan projekteket, amelyekhez különben drága eszközöket kellene vásárolniuk. A fenntarthatóságot és a készségek megosztását segíti elő azáltal, hogy az intézmények közösen osztott gépparkot építenek ki, szemben az egyéni beszerzésű technológiával.

A drezdai SLUB makerspace-ben több 3D-szkenner is rendelkezésre áll, amelyeket a SLUB felhasználói ingyenesen használhatnak, miután részt vettek egy digitális munkavédelmi oktatáson és egy technikai bemutatón. A technikai bemutató alapvető ismereteket nyújt a 3D-szkennelés témájában, és lehetőséget biztosít arra, hogy a résztvevők saját tárgyakat szkenneljenek, majd számítógépen utólagos feldolgozást végezzenek. A mi húsvéti tojásainkhoz az Artec Spider 3D-szkennert ajánlották. Ez egy kézi eszköz, amely különösen kis tárgyakhoz ideális, és nagyon jól képes ábrázolni a részleteket. Négy alkalom alatt, előzetes ismeretek nélkül, 16 különböző méretű szorb húsvéti tojás 3D-szkennelése történt. A szkennert a hozzá tartozó forgóasztallal együtt használták. A tojást egy tartóval a forgóasztal közepére helyezték. A szkennelés indításakor az asztal automatikusan elkezd forogni, és a szkennert csak egyenletesen kell fentről lefelé mozgatni. A számítógépen valós időben nyomon követhető, hogy mely területek kerülnek éppen rögzítésre.

A teljes modell elkészítéséhez, a tárgy típusától függően, ebben a szkennelési módszerben szükséges legalább két felvételt készíteni, és a tárgyat közben a korábban nem látható oldalra kell forgatni. Így a két felvétel a számítógépen összekapcsolható egy teljes modellé. Az utómunka a számítógépen tehát elengedhetetlen, és a szkenneléssel, amely mindössze körülbelül öt percet vesz igénybe, összehasonlítva viszonylag időigényes. A húsvéti tojás modellek esetében fél órától körülbelül egy órát kellett szánni az utófeldolgozásra tojásenként. Ezt követően a modell a szükséges formátumban exportálható és menthető.

3D adatok feldolgozása

Aki még soha nem dolgoztt 3D fájlokkal, ezen a ponton egy kihívást jelentő kérdéssel találkozhat: milyen fájlformátumra van szükségem egyáltalán? A MúzeumDigitárba történő feltöltéshez .zip archívumot használnak. Ez egy tömörített fájlformátum, amelyben több fájl (akárcsak egy cipzárral, angolul „zipper”) összefoglalható. Ebben legalább egy .obj fájlnak kell lennie. Az „Object” formátum jelenleg az egyik legelterjedtebb formátum a 3D modellekhez. Ebben általában csak a 3D információk kerülnek tárolásra, nem pedig az objektum felületi színe, vagyis a textúra. A textúrák külön fájlban, általában .jpeg formátumban kerülnek mentésre. Ahhoz, hogy a 3D fájl és a textúra együttműködjön, szükség van a „mapping” folyamatra, ami egy olyan eljárás, amely a kétdimenziós képet a háromdimenziós objektumra helyezi. Elképzelhetjük úgy, mintha egy tésztát fóliába csomagolnánk. Ehhez azonban további információkra van szükség, amelyek külön .mtl fájlban (material template library) kerülnek tárolásra.

Ahhoz, hogy a feldolgozás működjön, a fájlokban kölcsönös hivatkozások találhatók. Ha később megváltoztatjuk a fájlneveket, fontos, hogy a fájlokon belüli hivatkozásokat is módosítsuk. Ha ezt nem tesszük meg, a parancsok érvénytelenné válnak, és meglepődhetünk, hogy a 3D modellt nem látjuk, hanem egy fekete képernyőt. A hivatkozások módosítása egyszerűen elvégezhető egy szövegszerkesztő segítségével. A .mtl és .obj fájlok mindkettő nyithatók ezzel. A fájlokban egyszerű szöveg (plain text) információk jelennek meg, amelyek bár nem minden esetben érthetőek, de emberek számára olvashatóak. Általában már az elején megjelennek a hivatkozott fájlok, amelyek neveit egyszerűen módosíthatjuk. Ha minden hivatkozás helyes, elkészíthetjük a .zip archívumot. Windows rendszeren ezt egyszerűen a jobb gombbal, majd a „Compress to…” opcióval tehetjük meg. Az archívum automatikusan az első kiválasztott fájl nevét kapja, és nagyon fontos, hogy ennek meg kell egyeznie a .obj fájl nevével.

Publikáció a MúzeumDigitárban

A MúzeumDigitárban történő közzétételhez a tárgyat a megszokott módon kell rögzíteni és alapadatokkal ellátni. Ezt követően a „Média” fülön ki kell választani a „3D objektum” gombot. Ezek után a fájlt válasszunk ki a helyi tárolóból. (A .zip archívumot kell használni.) A feltöltés és a feldolgozás a hardver és az internetkapcsolat függvényében eltarthat egy ideig. Mindenesetre, ha mindent helyesen csináltunk, a kész 3D-modell fekete háttér előtt jelenik meg. Az objektumot bármilyen irányba el lehet forgatni és nagyítani. Így fogják látni a MúzeumDigitár látogatói is. A bal oldali oldalsó sávban információk adhatók meg a modell jogi státuszáról is. Ajánlott továbbá egy megfelelő előnézeti képet választani. Az előnézeti kép feltöltése hasonlóan működik, mint a hagyományos fényképek feltöltése. Egy egyszerű megoldás az előnézeti képhez lehet például a 3D modell képernyőmentése a MúzeumDigitár nézegetőjéből. A tárgy fényképei csak akkor ajánlottak előnézeti képként, ha azok nem állnak rendelkezésre más nézetekként is a modell mellett. Ha ugyanis így van, akkor a 3D modellt nem lehet kellően megkülönböztetni a többi fényképtől a látványban, mivel azok együtt jelennek meg.

Végül, de nem utolsósorban: hálózatépítés!

Amikor a kész 3D modell már publikálva van, büszkén tekinthetünk rá – és mindenképpen érdemes megmutatni! A 3D nézegető, amelyet a MúzeumDigitár biztosít, hatalmas előnyt jelent, amikor a múzeumi gyűjteményeket digitálisan elérhetővé kell tenni. Bátorítson más intézményeket is arra, hogy próbálják ki a technológiát, és ossza meg velük tapasztalatait. Természetesen, ahogyan az új munkafolyamatok kipróbálásakor lenni szokott, problémák is felmerülhetnek. Kérdések vagy technikai kihívások esetén a MúzeumDigitár csapata szívesen nyújt támogatást. Azokkal az intézményekkel való hálózatépítés is segíthet, amelyek már közzétettek 3D modelleket, és tapasztalataik segíthetnek a nehézségek leküzdésében.

Már több mint ezer olyan múzeum tagja a közösségnek (jelenleg: 1010 intézmény), amelyek legalább egy tárgyat a MúzeumDigitár segítségével tettek közzé.

Az összes közzétett gyűjteményük együttesen böngészhető a global.museum-digital.org oldalon.

The frontend of museum-digital is now available in Turkish. As a very nice side effect, this also unlocks the Turkish translations for keywords, and place and actor names we have been gathering for the last half a year.

Image credits: Eva Gonzalès: „Girl Awakening“, Kunsthalle Bremen – Der Kunstverein in Bremen (CC BY-NC-SA)