Qui di seguito riporto il processo e il codice utilizzato per creare il dataset su cui poi verrà valutato il modello kosmos2.
Il dataset è stato creato a partire da una serie di ambienti generati proceduralmente in ProcThor.
Il dataset contiene 206 ambienti. Ogni ambiente è identificato con un numero e rappresentato da una directory nel dataset.
All’interno di una directory possiamo trovare:
un file json
una directory “images”
Il file json contiene informazioni riguardanti l’ambiente generato. Inoltre è il file che contiene informazioni riguardante gli oggetti presenti nell’ambiente, nonchè i vari bounding box.
Ad esempio, in questa immagine si può vedere le coordinate del bounding box dell’entità di un “TV stand” in una particolare immagine:
All’interno della directory “images” sono invece presenti queste immagini, in due varianti: con bounding box disegnati e senza bounding box.
Per gli scopi di questo progetto abbiamo utilizzato le immagini senza bounding box.
Fase 1: il primo csv
A questo punto quindi dobbiamo estrarre tutte le informazioni necessarie al nostro progetto ed isolarle in modo tale da poter effettuare una prima valutazione del modello.
Le informazioni di cui necessita il modello sono:
nome dell’entità di cui fare il grounding
immagine su cui fare il grounding
il bounding box dell’oggetto sull’immagine
le lexical reference dell’oggetto (cioè modi alternativi con cui ci si può riferire all’oggetto)
Queste informazioni sono state estratte utilizzando uno script python, con il quale ho messo queste informazioni in un dataframe, dal quale sono state esportate in un file CSV.
Lo script è il seguente:
Questo script, quindi processa ogni directory degli ambienti, e per ogni file json estrae, per ogni entità la posizione in ogni immagine.
Questo è un estratto del file csv, output di questa fase:
Il file completo ha circa 13000 entries.
Fase 2: Zero shot evaluation
A questo punto questo file viene diviso in due: Test split e Training split.
In questa fase utilizzeremo kosmos per generare il bounding box del “Test split”. Questa è una valutazione senza fine tuning, che potremmo definire “Zero shot”.
L’input di questa fase è il Test split dell’output della fase precedente, mentre L’output è un nuovo file csv che contiene anche le informazioni del bounding box generato da kosmos.
Kosmos ovviamente non prende in input un file csv. Il modello, prende in input un prompt e un’immagine, e, ci fornirà il bounding box dell’entità di cui abbiamo chiesto il grounding.
ES:
Input:
Prompt:
image:
output:
Quindi come per ogni entry del csv dobbiamo:
generare un prompt
rimediare l’immagine relativa
estrarre dall’output di kosmos il bounding box relativo all’entità di cui ha fatto il grounding
Valutare la bontà del bounding box generato
Aggiornare il csv
Tutto questo viene fatto con il seguente script:
L’output di questa fase è un file csv aggiornato con l’output di kosmos.
In più rispetto alla fase precedente ci sono altre tre colonne:
“kosmos bounding box”: il bounding box generato da kosmos
overlap index: il coefficiente che indica la percentuale di sovrapposizione tra il bounding box di kosmos e il target bounding box
Match: un valore booleano che indica se c’è un match tra i due bounding box (si ha un match quando i due BB si sovrappongono per più del 50%)
Fase 3: valutazione delle performance zero shot
Usando un altro semplice script possiamo valutare la performance del modello in zero shot.
Diagramma di flusso delle fasi
graph TD
Phase 2
subgraph Phase 2
D[test split csv file]
E[kosmos.py]
F[csv file updated]
end
D -->|input| E
E -->|processing agent| F
%% Connect phases
C -->|output| D