Archive for the ‘Outils’ Category

Moteur de montage: première analyse

Wednesday, February 25th, 2009

A partir d’un tracé enregistré sur le territoire de Renens, le moteur d’analyse – avec des réglages différents que ceux indiqués dans le post précédent – nous sort ce type de données (extrait):

THIS WALK IS NOT A LOOP
22/01/09 15:22:13 –> 46.53904, 06.58182 : LINEAR
22/01/09 15:22:13 –> 46.53904, 06.58182 : LINEAR
22/01/09 15:22:15 –> 46.53904, 06.58182 : LINEAR
22/01/09 15:22:16 –> 46.53904, 06.58182 : LINEAR
22/01/09 15:22:16 –> 46.53877, 06.58173 : LINEAR
22/01/09 15:22:17 –> 46.53877, 06.58173 : LINEAR
22/01/09 15:22:18 –> 46.53877, 06.58173 : LINEAR
22/01/09 15:22:18 –> 46.53877, 06.58173 : LINEAR
22/01/09 15:22:19 –> 46.53877, 06.58173 : LINEAR
22/01/09 15:22:19 –> 46.53877, 06.58173 : LINEAR
22/01/09 15:22:20 –> 46.53877, 06.58173 : LINEAR
22/01/09 15:22:20 –> 46.53877, 06.58173 : LINEAR
22/01/09 15:22:21 –> 46.53877, 06.58173 : LINEAR
22/01/09 15:22:21 –> 46.53877, 06.58173 : LINEAR
22/01/09 15:22:21 –> 46.53877, 06.58173 : LINEAR
22/01/09 15:22:22 –> 46.53877, 06.58173 : LINEAR
22/01/09 15:22:23 –> 46.53877, 06.58173 : LINEAR
22/01/09 15:22:30 –> 46.53866, 06.58158 : LINEAR
22/01/09 15:22:32 –> 46.53866, 06.58154 : LINEAR
22/01/09 15:22:34 –> 46.53866, 06.58152 : LINEAR, CUT
22/01/09 15:22:34 –> 46.53866, 06.58152 : LINEAR
22/01/09 15:22:35 –> 46.53866, 06.58152 : LINEAR
22/01/09 15:22:36 –> 46.53866, 06.58152 : LINEAR
22/01/09 15:22:38 –> 46.53866, 06.58152 : LINEAR
22/01/09 15:22:41 –> 46.53866, 06.58152 : LINEAR
22/01/09 15:22:43 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:45 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:47 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:47 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:49 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:51 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:51 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:52 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:53 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:53 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:54 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:54 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:55 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:56 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:56 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:56 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:57 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:58 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:58 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:58 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:22:59 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:00 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:00 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:00 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:01 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:02 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:02 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:02 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:03 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:03 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:04 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:04 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:05 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:05 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:06 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:06 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:08 –> 46.53864, 06.58148 : LINEAR
22/01/09 15:23:11 –> 46.53868, 06.58139 : LINEAR
22/01/09 15:23:12 –> 46.53868, 06.58139 : LINEAR
22/01/09 15:23:12 –> 46.53868, 06.58139 : LINEAR
22/01/09 15:23:12 –> 46.53868, 06.58139 : LINEAR
22/01/09 15:23:14 –> 46.53868, 06.58139 : CHAOTIC
22/01/09 15:23:14 –> 46.53868, 06.58139 : CHAOTIC
22/01/09 15:23:14 –> 46.53868, 06.58139 : CHAOTIC
22/01/09 15:23:16 –> 46.53868, 06.58139 : CHAOTIC
22/01/09 15:23:16 –> 46.53868, 06.58139 : CHAOTIC
22/01/09 15:23:17 –> 46.53868, 06.58139 : CHAOTIC
22/01/09 15:23:19 –> 46.53868, 06.58135 : CHAOTIC
22/01/09 15:23:20 –> 46.53868, 06.58133 : CHAOTIC
22/01/09 15:23:21 –> 46.53866, 06.58133 : CHAOTIC
22/01/09 15:23:23 –> 46.53866, 06.58133 : CHAOTIC
22/01/09 15:23:23 –> 46.53866, 06.58133 : CHAOTIC
22/01/09 15:23:25 –> 46.53866, 06.58133 : CHAOTIC
22/01/09 15:23:25 –> 46.53866, 06.58133 : CHAOTIC
22/01/09 15:23:27 –> 46.53863, 06.58133 : CHAOTIC
22/01/09 15:23:29 –> 46.53863, 06.58133 : CHAOTIC
22/01/09 15:23:30 –> 46.53863, 06.58135 : CHAOTIC
22/01/09 15:23:32 –> 46.53863, 06.58135 : CHAOTIC
22/01/09 15:23:34 –> 46.53863, 06.58135 : CHAOTIC

Share

Moteur de montage: première mouture

Wednesday, February 25th, 2009

Florian Poulin a bien avancé sur le moteur de montage – ci dessous, les détails du fichier de configuration qui permettent d’ajuster les variables.

# ——————————————————————————
# GENERAL PARAMETERS
# ——————————————————————————

# Nom du fichier dans lequel lire le tracé du marcheur. Le fichier doit contenir
# pour chaque relevé GPS : le timestamp UNIX, la latitude, la longitude et
#l’altitude séparés par un espace), comme dans l’exemple suivant  :
# …
# 1232634081 46.539363 6.581905 475.000000
# 1232634082 46.539352 6.581883 475.000000
# 1232634083 46.539341 6.581862 475.000000
# …
GPS_FILE_PATH    = gps1.log

# ——————————————————————————
# WALKANALYZER PARAMETERS
# ——————————————————————————

# Nom du fichier dans lequel les résultats bruts de l’analyse seront enregistrés
# (notez que ce fichier n’est utile que pour des tests et pour la configuration
# du système).
OUTPUT_ANALYZE   = _analyze.txt

# Paramètres permettant de contrôler l’élimination des trames GPS erronées. Le
# premier permet de spécifier la différence d’altitude maximale tolérée entre
# deux positions GPS (en mètres). Au-delà de cette limite, la trame lue est
# ignorée. Le second paramètre donne la vitesse limite admise entre deux trames
# (en km/h). Au-delà de cette vitesse de déplacement, la dernière trame lue est
# ignorée.
IGNORE_DELTA_ALTITUDE = 30
IGNORE_WALK_SPEED_KMH = 10

# Paramètres permettant de contrôler si le parcours correspond à une boucle ou
# à un aller simple. Un parcours est considéré comme une boucle si la première
# position du parcours coïncide (à un seuil de tolérance près, le premier
# paramètre, donné en mètres) avec l’une des positions connues sur les X
# derniers mètres du parcours (X étant le second paramètre).
LOOP_POSITION_TOLERANCE = 3
LOOP_END_WINDOW_SIZE = 30

# Paramètres permettant de contrôler la détection des portions de parcours
# chaotiques ou linéaires. Pour un point donné, on considère l’évolution du
# tracé sur une portion de tracé entourant le point, et dont la taille est
# donnée par le premier paramètre (en mètres). Sur cette portion de tracé, on
# calcule le rapport entre la distance à vol d’oiseau entre le premier et le
# dernier point, et la distance réelle parcourue. Si ce rapport dépasse la
# valeur du second paramètre, la position est considérée comme chaotique.
CHAOS_WINDOW_SIZE = 15
CHAOS_THRESHOLD   = 0.2

# Paramètres permettant de contrôler la détection des recoupements. Pour chaque
# point du tracé, on contrôle si un futur point du tracé coïncide avec (à un
# seuil de tolérance près, le premier paramètre). Si c’est le cas, un
# recoupement est détecté. Le second paramètre permet de spécifier la taille
# minimum admise pour un recoupement (distance parcourue dans la boucle). Pour
# éviter la détection abusive de recoupements, il faut veiller à conserver ce
# paramètre à une valeur suffisamment élevée.
CUT_POSITION_TOLERANCE = 3
CUT_MIN_LENGTH         = 30

# Paramètres permettant de contrôler la détection des aller-retours. Pour chaque
# point du tracé, on contrôle si ses points successeurs coïncident avec ses
# points prédécesseurs (à un seuil de tolérance près, le premier paramètre).
# Si c’est le cas, un aller-retour est détecté. Le second paramètre permet de
# spécifier la taille minimum admise pour un recoupement (distance parcourue
# durant l’aller-retour). Pour éviter la détection abusive d’aller-retours, il
# faut veiller à conserver ce paramètre à une valeur suffisamment élevée.
RT_POSITION_TOLERANCE = 5
RT_MIN_LENGTH = 30

# ———————————————
# NORMALIZER PARAMETERS
# ———————————————

# Nom du fichier dans lequel les résultats nornalisés seront enregistrés
# (échelle de temps linéaire et regroupement/élimination de périodes de
# chaos/linéarité).
OUTPUT_NORMALIZE = _normalize.txt

# Les données GPS originelles brutes sont reçues à intervalles variables. Le
# normaliseur se charge, à partir de ces données, de reconstruire une échelle
# de temps régulière. Ce paramètre permet de spécifier l’intervalle de temps
# (en secondes) souhaité entre deux valeurs. Notez que suivant l’intervalle, des
# valeurs originales pourront être perdues ou dupliquées.
SCALE_GRAIN_SECONDS  = 1

# Le premier paramètre permet de spécifier la durée minimum admise pour une
# période de chaos ou de linéarité (en secondes). Le normaliseur s’arrange pour
# ne jamais avoir de période de durée inférieur à cette valeur (en aggrandissant
# une période ou en la supprimant). En dessous d’une durée de période limite
# (donnée par le second paramètre) une période est systématiquement supprimée.
MIN_PERIOD_SECONDS   = 30
FORCE_DELETION_UNDER = 10

Share

Le CMS – mise en route de la base de données

Thursday, June 12th, 2008

Après une première phase de tests techniques et ergonomiques, nous sommes maintenant en train de “métadater” les médias (que des vidéos pour le moment) pour mettre à l’épreuve le concept et pouvoir faire les premières simulations.

Voici quelques captures d’écrans de ce CMS (qui reste pour le moment privé, usage interne du groupe de recherche). Un grand merci à Lionel Tardy qui a travaillé depuis février sur la construction de cette solution personnalisée aux besoins du projet !

A télécharger, un PDF qui donne une vision d’ensemble des champs et listes, ainsi que le type d’analyse et de règles qui vont être appliquées par le moteur de montage. Également à télécharger, un PDF qui donne une idée du montage type, en simulant un montage avec les règles.

La page de départ:

Cette page permet d’importer des fichiers créés dans Final Cut: toutes les vidéos sont pour le moment préparées dans FCP, puis exportées sous forme de fichiers QuickTime natifs, puis compressés au format flash (quelques exemples dans ce blog). Puis, il est possible de paramétrer les thèmes, les listes, de gérer la structure et d’ajouter des utilisateurs. La partie la plus importante est “Gestion des médias”.

CMS HOME

La page de gestion des médias:

C’est dans cette partie que nous devons définir:

– le titre artistique du média (sera présent sur la carte du module embarqué);
– le statut du média;
– le type de média;
– il est possible de placer le média d’origine sur la carte google intégrée, puis – et c’est là que commence le montage (spatial, ou spécial, c’est selon) – de placer le média sur la carte en fonction de ses combinaisons souhaitées avec d’autres médias placés dans les environs. C’est principalement ce choix qui va déterminer le premier choix de média intégré au film…

CMS_GESTION MEDIAS

La page des métadonnées subjectives:

Ici c’est encore le chantier expérimental – c’est une partie importante (contenant les règles, les logiques d’analyse etc, ainsi que d’autres informations utiles pour classer / chercher / présenter les médias). Ce n’est qu’en expérimentant avec une certaine masse de médias la plus variée possible que nous pourrons tirer des conclusions et préciser les besoins réels – ce chantier là est en cours, autour de 300 médias sont à disposition.

CMS_METADONNEES

La page pour définir les thématiques et les “tags” libres:

Page importante également: c’est ici qu’on détermine l’appartenance au nuage – c’est le choix du visiteur qui va déterminer dans quel “étage” thématique le média sera choisi; son choix aura forcément une incidence sur le contenu et la forme. Nous sommes en train d’expérimenter la l’indexation multiple d’un média à plusieurs nuages en même temps – mais avec une “intensité” différence (cf les 30/70 dans l’exemple).
Il y a également les tags qui permettent de personnaliser le contenu du média, puis ensuite de pouvoir former un nuage supplémentaire dans le site web (nuage de tags les plus utilisés par exemple).

CMS_THEMATIQUES

Prochainement sera publiée la liste des champs et des variables utilisées, ainsi qu’un schéma expliquant la méthode d’analyse et les règles implémentées.

En parallèle, les collaborateurs de la HEIG-VD sont en train de préparer un simulateur du moteur d’analyse – cette application nous permettra de tester des premières combinaisons basées sur un itinéraire urbain.
Techniquement, il s’agit d’une application JAVA qui lit un fichier .csv venant d’un tracé GPS enregistré sur le module embarqué, puis analyse avec un certain nombre de variables ce tracé pour pouvoir ensuite exporter un fichier décrivant une playlist (le montage sous forme de suite de fichiers avec durée).

UF 12.06.2008

Share

Les vidéos arrivent

Saturday, June 7th, 2008

Lionel Tardy a implémenté la possibilité d’ajouter des vidéos au format flash – ce qui nous permet maintenant de mettre quelques exemples (médias bruts sans montage) en ligne.

Le maître des grillades

Travaux et danse des ombres

Téléscopages

Et la concierge ?

D’autres exemples dans les pages et les posts – il y a actuellement autour de 500 médias en cours de cataloguage…

Share

Comment échantilloner et caractériser le parcours du visiteur

Tuesday, May 27th, 2008

Ce que ressort de nos derniers tests, c’est que nos outils d’analyse (GPS et accéléromètre) produisent un signal pas toujours très précis et avec pas mal de bruit.

-> Les GPS ne sont pas très fiables: d’un jour à l’autre, ils changent de comportement (ont-ils des humeurs ?), et ils dérapent parfois, sans crier gare, dans un parcours enregistré qui semble sans faute. Il faudra donc allier la force magnétique des rails (en fait un magnétisme sur les routes pour éviter de traverser un salon ou une chambre à coucher sans le vouloir) et un choix drastique sur le meilleur GPS existant (que nous devons encore trouver)

-> L’accéléromètre a trop de bruit: le comportement humain enregistré par cet outil (qui enregistre les variations de mouvement dans les 3 axes) est trop chaotique pour qu’il soit possible d’en tirer un comportement clair et évident. Ce qui peut être lu “facilement” c’est la différence entre une position au repos et un mouvement – ce qui est déjà une bonne base. L’idéal serait que pour la phase deux on puisse différencier également les états suivants:

  1. état marche en vitesse normale / état course
  2. état marche “lisse” / état marche “cahotique”

Voici une image graphique d’un test compilé par Nicolas Goy:

accelerometre_test

J’ai marché, puis couru, puis tourné sur moi même, puis je me suis assis et relevé…

Nous avons donc deux possibilités:

-> accepter les imperfections (en essayant d’optimiser un maximum les résultats que nous avons actuellement) en se disant que l’important est que le film résultant fonctionne. Il s’agit de se donner un but idéal qu’il s’agit de viser (quelle dose de poésie, de narration, de liens de causalité etc); un autre chantier.
De toutes manières, une partie de la logique de montage sera implémentée dans dans la base de données média – à travers un certain nombre de règles (chantier encore ouvert).

-> essayer de rajouter d’autre capteurs (lesquels ?) ou systèmes d’analyse (par exemple avec plus de “input” de la part du visiteur) afin de rendre l’analyse de ce parcours plus précis.

C’est une question importante: plus précis on sera dans cette analyse, plus on aura d’éléments pour “piloter” le montage – mais pour le moment on ne sait pas la dose exacte de données sortant de nos outils d’analyse qu’il faut pour que le système puisse permettre notre film idéal…
L’enjeu est de taille, et ce n’est qu’à travers des tests et re-tests que l’on pourra définir de quelle manière on pourra faire le pont entre les données à la sorties de nos deux modules et les métadonnées que nous aurons minutieusement indexées en amont.

UF le 29.05.2008

Share

TEST google map intégré dans le blog

Wednesday, February 6th, 2008

Un test pour lier une carte au blog, tout en intégrant le post ou des images sur la carte… voir cette page.

Mode d’emploi sur le net, ICI

Share