CONFRONTO DI ALGORITMI
SFM IN ARCHEOLOGIA - IL
CASO DELLE TERME DI
TRAIANO IN ROMA
Simone Gianolio (Univ. “La Sapienza”)
[email protected]
LOW-COST 3D: Sensori, algoritmi e applicazioni
8-9 marzo Trento 2012
Algoritmi SfM in archeologia
Il progredire delle tecniche e delle tecnologie rendono
sempre più evidente l’assenza di un solido background
informatico nelle discipline umanistiche, in particolare quella
archeologica che massimo giovamento trarrebbe
dall’utilizzo del 3D per la registrazione di dati ad elevata
complessità interpretativa. Questo si scontra con il
progressivo regredire dei finanziamenti a disposizione per
la ricerca archeologica, senza chiudere gli occhi di fronte
alla loro mala amministrazione.
Negli ultimi anni pertanto è cresciuto l’utilizzo di algoritmi di
Structure from Motion come soluzioni dall’impatto economico
nullo e dal risultato garantito in termini temporali più che
accettabili, cosa che può consentire la registrazione
tridimensionale di un gran numero di informazioni.
Algoritmi SfM in archeologia
Tuttavia come risaputo gli algoritmi di SfM sono ben
lungi dal restituire quella precisione e quella
accuratezza propri di sistemi di rilevamento strumentale
indiretto (fotogrammetria, laser scanner, stazione totale,
etc.) o manuale diretto.
Viene così chiaramente a scontrarsi l’esigenza da parte
dell’archeologo di lavorare sempre su dati dalla
massima precisione possibile con l’inevitabile
approssimazione di soluzioni computer vision, per
quanto in grado di offrire una sempre più veloce analisi
del dato sottomesso con lo sviluppo di soluzioni “cloud”
o “gpu-computing” in caso di assenza di rete.
Algoritmi SfM e documentazione
archeologica
Gli algoritmi SfM rischiano
pertanto di essere visti come
soluzioni push-button in grado
di restituire a costi irrisori e
senza la necessità di un
corretto background
scientifico il rilievo
tridimensionale di un
manufatto. Questo può
essere vero nell’occasionalità,
nei progetti che non
richiedono affidabilità del
dato, ma non può essere vero
nell’ambito della
documentazione archeologica
intesa come processo
scientifico di acquisizione di
dati grezzi da elaborare per
giungere ad una ricostruzione
verosimile della storia antica.
Ancora oggi siamo insomma
fermi a quello slogan ideato
da George Eastman per
lanciare la prima fotocamera
Kodak nel novembre del
1889 “You press the button, - - - we do the rest.”
Le Terme di Traiano in Roma
Il principale ambito di analisi di questa comparativa sono state le
Terme di Traiano in Roma, edificio costruito dall’omonimo imperatore
ispanico su progetto di Apollodoro di Damasco occludendo la Domus
Aurea tra il 104 ed il 109 d.C.
L’area, per oltre 1500 anni destinata prevalentemente ad orti,
boschetti e casalini di nobili e confraternite romane, è stata nel
1935/1936 sistemata a parco pubblico su progetto di A. Muñoz,
con la creazione di un giardino, di un viale panoramico e
procedendo alla rimozione di alcune strutture che insistevano
sull’area.
I resti delle Terme di Traiano, già menomati nella loro omogeneità
dal progetto del parco, si trovano inglobati all’interno di cancellate,
circondate ed in alcuni casi sovrastate dalla vegetazione; alcuni
punti di vista sono attualmente chiusi per le ben note vicende
relative alla Domus Aurea.
Le Terme di Traiano in Roma
I resti oggetto
del test
costituiscono un
corpo di grosse
dimensioni
disposto su una
vasta area
nell’angolo nordoccidentale del
complesso che,
oltre alle
strutture visibili
nella foto
accanto,
comprendono la
c.d. “Aula
biabsidata” ed
una grossa
esedra
riconosciuta come
ninfeo.
Struttura di Test 01
Nessun algoritmo è riuscito a mettere insieme
l’intero set di fotografie, a causa della presenza di
impedimenti naturali e dell’impossibilità di costruire
una adeguata rete di punti comuni nel passaggio
sotto l’arco.
La dimensione delle strutture e lo spazio presente
tra le stesse e la rete protettiva sono risultate
sufficienti a consentire un match completo del set
riguardante il lato meridionale dell’intero corpo
architettonico.
Le Terme di Traiano in Roma
La c.d. “Esedra L”
è uno dei corpi
meglio conservati
delle Terme:
come in
precedenza, una
cancellata a
maglie strette
ostruisce la
ripresa
fotografica,
possibile soltanto
attraverso delle
aperture nella
rete che tuttavia
rendono molto
difficile includere
l’intero corpo
anche all’interno
della focale da
17mm utilizzata.
Struttura di Test 02
Sebbene l’angolatura di presa non sia stata
completa a causa della chiusura di un settore del
parco, tutti gli algoritmi hanno restituito una buona
elaborazione del set di fotografie.
I risultati finali sono stati comunque altalenanti, nella
generazione della texture e nella definizione del
modello, in particolare nella parte inferiore del
terreno dove sono conservate anche dei resti di
volta crollati di potenziale interesse.
L’Arco di Costantino in Roma
L’Arco di
Costantino è
risultato un
caso di grande
interesse per
via
dell’elevato
dettaglio (in
bassorilievo o
a tutto tondo)
presente sul
monumento, a
cui si aggiunge
una cancellata
che penalizza
fortemente le
riprese
fotografiche
per gli SfM.
L’Arco di Costantino in Roma
L’Arco di Costantino, dedicato all’imperatore dal
Senato, è il frutto di una serie di riutilizzi di
elementi provenienti da altri monumenti:
bassorilievi, statue a tutto tondo, colonne, particolari
decorativi architettonici molto fini.
La vicinanza delle strutture metalliche ha reso
impossibile completare l’intera struttura: pur
utilizzando un 17mm solo VisualSfM è riuscito a
computare i match creando modelli differenti, ma
non 1 unico modello.
Criteri di analisi
L’operazione svolta sugli algoritmi SfM presi in esame è
volta alla creazione di una tabella di usabilità che tenga
conto delle seguenti caratteristiche, partendo dal
background tecnologico a disposizione di un archeologo:
Interfaccia user-friendly dell’applicazione e semplicità
d’installazione-configurazione
Licenza d’uso del software/servizio web
Tipologia di output del rilievo (mesh, point cloud, formato del file
generato)
Capacità di risoluzione dei dataset a disposizione
Qualità del risultato finale generato
Coerenza della geometria generata con i resti in situ
Point cloud & mesh
Dal punto di vista della documentazione
archeologica, prescindendo dall’aspetto di
scientificità che con algoritmi SfM non può essere
ancora ottenuto, è comunque necessario rispondere
a determinati parametri che qualificano
positivamente o negativamente un progetto:
Open
data, open format dei dati grezzi
Documenti disponibili in multipiattaforma
Corrispondenza con il dato archeologico
I software analizzati
Sono stati presi in esame una serie di software che
fanno riferimento a tecnologie di SfM differenti:
Autodesk 123DCatch beta (già Project Photofly)
Microsoft Photosynth
Hypr3D
Arc3D
Visual Structure from Motion 0.5.13
Structure from Motion Toolkit
V3D Structure from Motion
Bundler SfM 0.4
OSM Bundler
Etc.
Piattaforma di test
Windows 7 SP1 64bit
Intel i7 920 @ 3,4Ghz + nVidia Quadro 2000 +
12GB di RAM + 1GB GDDR5
Canon 5D Mark II (sensore FF 21MP) + Canon EF 1740mm f/4L + Canon EF 24-70mm f/2.8L: scatto in
RAW e sviluppo con Digital Photo Professional
Samsung Galaxy W i8150 (sensore 5MP):
elaborazione immagini con Adobe Photoshop
Autodesk 3DS Max; Meshlab
Immagini totali prese: >500 in 3 distinti dataset
Caratteristiche software
Software
Piattaforma
Licenza
Interfaccia
Facilità
d’uso
Feature
aggiuntive
123DCatch
Web-based: client
for Windows
Autodesk has a
perpetual royaltyfree license on
model if you use a
web-service
User-friendly
5
Strumenti della
famiglia 123D
per modellazione libera e
prototipazione
Photosynth
Web-based: client
for Windows
Free use, share &
embed; CC, public
domain, © for photo
up to 20GB
Simple & minimal
5
Microsoft Image
Composite
Editor
Hypr3D
Web-based
Free use, share &
embed up 1GB.
Hypr3D has a
perpetual royaltyfree license on
model
Simple & Minimal
5
Mesh from
video file
Caratteristiche software
Software
Piattaforma
Licenza
Interfaccia
Facilità Feature
d’uso
aggiuntive
VisualSfM
Windows-MacLinux
Personal, non-profit
or research use with
references
User-friendly GUI but
advanced
4
Arc3D
Web-based:
client for
Windows-MacLinux & others
Non-commercial
only; public use with
references
Simple & minimal
5
GPU-computing
for matching;
dense reconstruction;
automatching
point clouds
Formati di esportazione
123DCatch
Hypr3D
VisualSfM
PhotoSynth*
Arc3D
DWG
DAE+jpg
PLY
PLY
V3D
FBX
PLY
sparse+dense
OBJ
OBJ
RZI
STL
VRML
OBJ
HiRe+LowRe
X3D
IPM
LAS
Low+Mid+HiRe
*= via SynthExport 1.1.0
ST1: 123DCatch vs Hypr3D
Per il corpo del settore nord-orientale delle terme, delle dimensioni di
ca. 40x15 metri, sono stati effettuati diversi momenti di presa per un
totale superiore alle 200 immagini. Quelle realmente utilizzate
ammontano a ca. 80 per la presenza di impedimenti naturali che hanno
ostacolato il match dell’intero set.
Il comportamento generale dei due algoritmi può definirsi
soddisfacente: i punti deboli rilevati sono stati il ponteggio di sostegno
alla volta non riconosciuto da 123DCatch al contrario di Hypr3D, il
quale ha però mostrato un comportamento non idoneo nel trattamento
del terreno erboso risultato troppo frastagliato.
In termini di definizione, Hypr3D 80.000 vertici maggiormente
concentrali sulla geometria architettonica, 123DCatch 113.000
vertici maggiormente concentrali sulla geometria “accessoria”.
ST1: 123DCatch vs Hypr3D
Il diverso
comportamento
nella definizione
del terreno ha
portato i due
algoritmi ad una
diversa
definizione
dell’area
occidentale del
modello 3D:
risulta in ogni
caso da
preferirsi
l’approssimazione
operata da
123DCatch
rispetto a quella
di Hypr3D.
ST1: PhotoSynth vs ARC3D
Microsoft
PhotoSynth ha
costruito una
nuvola di punti
troppo sparsa
per essere
utilizzata ai fini
della definizione
di una mesh
coerente con le
strutture rilevate.
ARC3D ha
gentilmente
restituito un
messaggio di
errore nel quale
segnalava
l’impossibilità di
processare il set
di immagini.
ST1: VisualSfM
VSfM ha
restituito una
buona nuvola
di punti, ben
processando il
ponteggio di
sostegno della
volta, meno
altri particolari
pure ben
visibili nelle
foto ed
andando in
crisi con i punti
più scuri
dell’immagine
come la
vernice nera
del portoncino.
ST2: 123DCatch vs Hypr3D
Nel caso dell’esedra L il comportamento dei 2 software può definirsi sovrapponibile
al 95% ca.: Hypr3D ha generato un modello ad alto dettaglio di oltre 100.000
vertici dai quali sono state ricavate ca. 200.000 facce, al contrario Autodesk si è
limitato a computare poco più di 33.000 vertici per un totale di 66.000 facce ca.
La più alta risoluzione ha consentito al primo di definire meglio i particolari posti
nella parte inferiore del modello, come frammenti di volta crollati e aperture dei
praefurnia.
Il trattamento cromatico della texture è risultato più fedele nel software Autodesk
piuttosto che nell’algoritmo di Viztu che ha introdotto una eccessiva dominante blu
nell’immagine.
Nella creazione del file .jpg Autodesk rispetta maggiormente gli standard della
mappatura UVW costruendo un file compatibile con il modificatore Unwrap UVW
di 3DS Max che lo riconosce, apre e gestisce correttamente; questo facilita
eventuali operazioni di postproduzione sulla texture che dovessero essere necessari.
Al contrario, Hypr3D tende a mosaicizzare in maniera eccessiva la texture che pur
essendo correttamente riconosciuta dall’Unwrap UVW di Max non è assolutamente
gestibile in fase di postproduzione, poiché i riquadri contenenti informazioni sul
colore delle facce ne assumono anche le dimensioni, risultando non più grandi di
poche decine di pixel.
ST2: 123DCatch vs Hypr3D
Hypr3D High Detail mesh
Sovrapposizione mesh
Autodesk mesh
ST2: 123DCatch vs Hypr3D
Hypr3D texture
Autodesk texture
ST2: PhotoSynth vs ARC3D
Sia l’algoritmo
di Microsoft
che quello di
ARC3D si sono
rivelati
insufficienti a
definire il
modello:
PhotoSynth a
causa di una
nuvola di punti
troppo sparsa,
il secondo per
manifesta
incapacità di
processare il
modello.
ST2: VisualSfM
AoC: 123DCatch vs Hypr3D
Il servizio della
Autodesk e quello
di Viztu forniscono
la mesh più
interessante del
dataset sottoposto:
la differenza può
arrivare al >30%
(dato non statistico)
di differenza sul
modello, che può
tuttavia definirsi
accettabile in
entrambi i casi.
Hypr3D restituisce
una elaborazione in
alta risoluzione che
conta tuttavia 2/3
in meno dei
poligoni rispetto al
modello Autodesk.
AoC: 123DCatch vs Hypr3D
Nel test dell’Arco
di Costantino la
palma della
migliore mesh va
al programma
Autodesk (viola),
più preciso nei
dettagli e nelle
sfumature. Solo il
programma
Autodesk è
riuscito per altro
ma in parte a
non “decapitare”
gli 8 guerrieri
Daci presenti
nella parte
superiore
dell’Arco.
AoC: VSfM vs 123DCatch
VisualSfM al
contrario degli
altri algoritmi è
in grado di
generare una
dense point cloud
attraverso l’uso
di CMVS/PMVS,
possibilità in
assoluto da
preferirsi per la
documentazione
archeologica.
Rispetto al
programma
Autodesk è stato
in grado di
computare fino a
>11 volte il
numero di vertici
utilizzati.
AoC: Photosynth vs Arc3D
Nella generazione di
modelli 3D nessuno dei
due servizi si è
dimostrato adeguato
alle esigenze
archeologiche. Arc3D
ha fallito nella
computazione del
match mentre
Photosynth si limita a
riconoscere una blanda
quantità di punti utile
soltanto a generare
ambienti 3D da prese
fotografiche; al fine di
ottenere risultati
soddisfacenti sotto il
piano visuale
l’algoritmo Microsoft
necessita di una
puntuale pianificazione
del programma di
prese fotografiche per
non spezzettare troppo
la navigazione
interattiva all’interno
dell’ambiente virtuale.
È disponibile la
funzione “panorama”
per utenti iOS 4.2 e ss.
Conclusioni
Dal punto di vista della formazione archeologica “standard” e dei risultati ottenibili
dall’utilizzo di algoritmi SfM per la registrazione tridimensionale veloce di
manufatti antichi, è possibile concludere che:
VisualSfM ed Autodesk 123DCatch sono attualmente i software migliori per generare
point cloud e mesh controllate; VSfM è tuttavia da preferirsi qualora si disponesse di
ottimali risorse hardware per il calcolo, poiché più completo
Microsoft Photosynth genera modelli con una risoluzione eccessivamente bassa nella nuvola
di punti, cosa che costringe l’elaboratore ad una approssimazione non controllata della
mesh risultante
Arc3D non è stato capace di processare i set inviati
Bundler, V3D, OSM non hanno chiuso la task segnalata, andando in crash; alcuni bugs sono
ampiamente segnalati agli sviluppatori ma non risolti; Bundler in particolare per essere
utilizzato in ambiente Win necessita la compilazione di CYGWin: sarebbe preferibile
quindi utilizzarlo in ambiente Linux, con il corollario di dover chiedere all’archeologo di
imparare un nuovo sistema operativo e/o la programmazione da shell. Inevitabile
scegliere dunque VSfM
Hypr3D è un algoritmo molto promettente, ma allo stato attuale i progetti possono soltanto
essere pubblici e questa non è una condizione idonea nella fase iniziale di un progetto di
studio archeologico. È comunque prevista una futura implementazione dell’opzione “make
private”. La possibilità inoltre di generare modelli da video costituisce un valore aggiunto
Algoritmi SfM per l’archeologia
VisualSfM per la sua capacità di generare point cloud dense (=dato grezzo) offline
e con risorse temporali e computazionali adeguate, unitamente ad una serie di
strumenti in grado di automatizzare realmente l’intero flusso di lavoro, risulta il
toolkit più efficace per la generazione di documentazione speditiva 3D. Riguardo
gli standard della documentazione archeologica, come detto inizialmente non è
possibile valutarne l’affidabilità, inoltre va in difficoltà quando deve analizzare
aree troppo scure o il terreno, nei set sempre non computato a differenza degli
altri algoritmi.
123DCatch ha dimostrato una perfetta integrazione con la suite di modellazione
sia gratuita (famiglia 123D) che commerciale (Entertainment Creation) di Autodesk,
divenendo un buon tool per la generazione di modelli 3D destinati alla creazione di
ambienti tridimensionali virtuali. Presenta 3 livelli di definizione della mesh,
sebbene l’appossimazione della risoluzione non andrebbe lasciata al software. Per
contro, non con tutti i set di test ha avuto un comportamento soddisfacente.
Hypr3D ha avuto un comportamento altalenante: non buona gestione della texture
ai fini di un modello importabile in ambienti virtuali, maggiore definizione della
mesh geometrica con qualche errore di troppo che nel caso della ST01 ha inficiato
gravemente la qualità finale a fini archeologici pur presentando una migliore
elaborazione generale del set fotografico.
Algoritmi SfM per l’archeologia
VisualSfM si è inoltre ben comportato nelle successive analisi di diverse
prese ottenute in tempi diversi di uno stesso set; al contrario, 123DCatch,
pur contemplando la possibilità di analisi successive dello stesso modello ed
un tool per la definizione manuale di punti comuni, ha mostrato una carenza
strutturale dovuta all’incapacità di mantenere inalterata la mesh già
computata, che veniva progressivamente deteriorata.
Gli algoritmi SfM danno in definitiva il meglio di sé in situazioni “ideali” su
dimensioni relativamente contenute del manufatto e con una decente
presenza di dettagli per l’individuazione di punti comuni. Hanno tutti invece
dimostrato una discreta indipendenza dal fattore hardware legato al
sensore fotografico che fa sentire il suo peso soltanto nella qualità delle
texture generate.
In definitiva, se ne consiglia l’utilizzo in archeologia sotto due precise
indicazioni: non trarre dai loro risultati elementi di documentazione
archeologica nel senso classico dell’espressione, limitarsi ad utilizzare per
un intero progetto lo stesso algoritmo, accettandone i limiti ma
minimizzando e per questo standardizzando l’errore su tutti i dati.
Thank you for your attention!
For further information:
[email protected]
