Traiter des images MODIS avec R pour calculer un NDVI

La Nasa propose depuis 1999 des images MODIS (Moderate-Resolution Imaging Spectroradiometer) à différentes résolutions spatiales et temporelles. Elles sont produites par deux satellites en orbite, Terra (1999) et Aqua  (2002), qui embarquent des capteurs pour le programme Earth Observing system.

Les instruments permettent d’enregistrer 36 bandes spectrales avec une fréquence de passage de 1 à 2 jours. La résolution des images diffère selon les bandes enregistrées et varie entre 0.25 et 1 km. Nous parlions il y a quelques jours du site reverb|echo de la Nasa, il se trouve qu’un certain nombre d’images sont disponibles sur le site.

Quelles données ?

Mais pour ça il faut savoir ce qu’on cherche, et la nomenclature des produits n’est pas vraiment transparente [1].  À titre d’exemple :

  • MOD9Q1 – Surface Reflectance 8-Day L3 Global 250m
  • MOD13Q1 – Vegetation Indices 16-Day L3 Global 250m
  • MOD11A2 – Land Surface Temperature/Emissivity 8-Day L3 Global 1km

Une fois qu’on en sait un peu plus sur le type de produit que l’on veut utiliser, il va falloir le télécharger et le traiter. Dans un post précédent, j’expliquais comment configurer sa machine pour utiliser wget. Si vous optez pour cette solution, il vous faudra utiliser le MRT pour reprojeter et assembler vos images. L’interface est assez intuitive et on peut faire du traitement de masse.

Mais je suis tombé aussi ce matin sur les logs de release d’un package R que je me suis empressé de tester : MODIStsp. Si vous avez déjà regardé MRT, MODISStsp n’est qu’un moyen de rester dans R pour télécharger les images. On pourra aussi regarder du côté du package MODIS qui lui n’intègre pas d’interface graphique.

Bon mais on parlait de NDVI dans le titre !

Traiter les images NDVI : MOD13Q1

En cherchant comment traiter les images MODIS, je suis tombé sur des ressources intéressantes. Notamment une page qui vous prend par la main pour traiter les données MODIS (MOD13Q1) dans R[2]. Je vous propose donc de faire un petit point pas à pas !

J’ai téléchargé et projeté les données grâce au package MODISStsp. J’ai donc un dossier qui contient les fichiers hrf, mais aussi un autre qui contient les fichiers tiff produits par le package.

Or quand on ouvre les données (dans Qgis), les gammes de valeurs ne correspondent pas à celles attendues pour du NDVI! On devrait avoir des valeurs entre -1 et 1 !

 

Freq. pour la tuille 16 – 17/01/2016

Il va falloir retravailler le raster pour obtenir les bonnes valeurs . Heureusement « the office of outer space affaire » nous donne la marche à suivre dans R[3]. Je vous propose donc ici un script commenté et customisé pour l’occasion.

library(raster)  
library(sp)
library(doParallel)
library(rgdal)
library(magrittr)

rm(list = ls()) ##clear env.

#create stack from tif NDVI files
path.v = "~/Documents/futurSahel/MOD13Q1_TS/VI_16Days_250m_v6/NDVI/"
l.files = list.files(path.v, pattern = ".tif")


my.stack = stack(paste0(path.v,l.files)) ##create raster stack of files in a directory
# load borders
border = shapefile("~/Documents/futurSahel/Senegal_gadm.org/SEN_adm0.shp") #ToDo: insert link to the shapefile with the country borders


## We use doParallel and magrittr packages to pipe different actions (crop and mask)
registerDoParallel(6) #we will use 6 parrallel thread
result = foreach(i = 1:dim(my.stack)[3],.packages='raster',.inorder=T) %dopar% {
  my.stack[[i]] %>% 
    crop(border) %>%
    mask(border)
}
endCluster()
ndvi.stack = stack(result)

ndvi.stack = ndvi.stack*0.0001 #rescaling of MODIS data
ndvi.stack[ndvi.stack ==-0.3]=NA #Fill value(-0,3) in NA
ndvi.stack[ndvi.stack<(-0.2)]=NA # as valid range is -0.2 -1 , all values smaller than -0,2 are masked out
names(ndvi.stack) = seq.POSIXt(from = ISOdate(2016,1,17), by = "16 day", length.out = 23) # atribut name as date for each layer

my_palette = colorRampPalette(c("red", "yellow", "lightgreen")) #Create a color palette for our values
## Plot X maps in the same layout
spplot(ndvi.stack, layout=c(4, 6),
       col.regions = my_palette(16))

Ce qui nous donne pour les 23 pas de temps étudiés l’image suivante. On voit bien reverdir la partie supérieure de la carte entre juillet et octobre en 2016.

Indice NDVI à partir des données MODIS MOD13Q1 sur le Sénégal pour 2016

Pour avoir un ordre d’idée, traiter 23 images et produire le graphe, en parallélisant une partie, me prend 11 min .

Des ressources :

[1]Type d’images disponible : https://modis.gsfc.nasa.gov/data/dataprod/

[2]http://www.un-spider.org/advisory-support/recommended-practices/recommended-practice-drought-monitoring/step-by-step/R

[3]http://www.un-spider.org/sites/default/files/Skript%20VCI%20final.R

Earthdata des données SIG pour l’environnement

Voilà plusieurs mois que je n’avais pas pris le temps de faire un post sur mon blog !
On trouve toujours beaucoup d’excuses, des papiers sur le feu, un déménagement, un nouveau post-doctorat… Alors pour recommencer doucement, une petite note sur un service de la NASA que j’ai découvert aujourd’hui : Reverb | echo[1]

logo earthdata
Un peu de contexte à cette découverte, mon nouveau post-doc m’a amené à sortir de ma zone de confort, on s’éloigne de la viticulture et de l’eau (encore que), pour travailler sur la zone sahélienne du Sénégal. Je cherchais des indicateurs de désertification… Et je suis tombé sur un blog génial de Martin Brandt[2] (chercheur au Department of Geosciences and Natural Resource Management à l’université de Copenhagen (Denmark)). En plus de pointer sur des papiers scientifiques, il y a aussi quelques posts sur des outils de télédétection (GRASS-GIS) et des liens vers des pourvoyeurs de données. C’est là que j’ai découvert LE truc.

Reverb est un silo de données environnementales propulsées par la NASA qui contient des choses incroyables et un puissant moteur de recherche. Je vous engage donc à regarder cette petite vidéo d’explication[3] (en anglais).

Je ne reviendrai pas sur la manière de trouver ses données, la vidéo est là, par contre une chose géniale qui pourrait inspirer d’autres sites : une fois que j’ai fait mon petit marché, le service me propose de télécharger un fichier TXT contenant les URLs des ressources demandées. L’idée est génial. Il y a quelques semaines, j’avais du faire une centaine de copier-coller depuis le site opendata.gouv.fr pour pouvoir automatiser un traitement sur le RGP de 2012[4] (j’en parlerai peut-être dans quelques mois quand l’article sera publié).

Donc une grande satisfaction, je disais, pour cette bonne pratique… je voulais donc me lancer dans un script bash et du wget… mais les ennuis arrivent …

wget http://e4ftl01.cr.usgs.gov//MODV6_Cmp_B/MOLT/MOD09Q1.006/2016.09.05/MOD09Q1.A2016249.h16v07.006.2016258071050.hdf

Connexion à urs.earthdata.nasa.gov (urs.earthdata.nasa.gov)|198.118.243.33|:443… connecté.
requête HTTP transmise, en attente de la réponse… 401 Unauthorized
Échec d’authentification par identifiant et mot de passe.
URL transformed to HTTPS due to an HSTS policy

Mince un login ! Nooon ! Pourtant Martin Brandt ne semble pas avoir ce problème. La solution est en deux étapes. Dans un premier temps, il faudra se créer un compte « earthdata » en cliquant sur login en haut à gauche. Ensuite, et la solution est sur le wiki [5], il faudra faire un petit fichier de config « curl ».

cd ~
touch .netrc
echo "machine urs.earthdata.nasa.gov login ; password " > .netrc
chmod 0600 .netrc

Vous l’aurez compris, il ne reste qu’à remplacer par votre login et par votre mot de passe. Et cette fois-ci les requêtes passeront !

wget http://e4ftl01.cr.usgs.gov//MODV6_Cmp_B/MOLT/MOD09Q1.006/2016.09.05/MOD09Q1.A2016249.h16v07.006.2016258071050.hdf

Sauvegarde en : « MOD09Q1.A2016249.h16v07.006.2016258071050.hdf »
MOD09Q1.A2016249.h1 100%[===================>]  64,76M   344KB/s    in 1m 51s

Merci pour les données, et merci pour cette facilité d’utilisation !!!

Données MODIS issu de earthdata
Les liens

[1]https://reverb.echo.nasa.gov
[2]https://matinbrandt.wordpress.com
[3]https://www.youtube.com/watch?v=iBXzzUv3b4w
[4]https://www.data.gouv.fr/fr/datasets/registre-parcellaire-graphique-2012-contours-des-ilots-culturaux-et-leur-groupe-de-cultures-majorita/
[5]https://wiki.earthdata.nasa.gov/display/EL/How+To+Access+Data+With+cURL+And+Wget

benchmark CPU avec linux

Un vieux portable qui craque, une installation Gnu-Linux toute neuve ! Et voilà que me vient l’envie de regarder comment fonctionne mon CPU histoire de voir si je n’ai pas un thread qui a grillé :-p ! J’ai donc cherché à droite et à gauche des solutions en ligne de commande ! Et voilà! On ouvre deux terminaux et dans chacun on colle l’une des lignes suivantes :

La première va lancer, sur 4 thread 2000 calcule

sysbench --test=cpu --cpu-max-prime=20000 --num-threads=4 run

La seconde va nous permettre d’observer l’évolution de la fréquence du CPU

watch grep \"cpu MHz\" /proc/cpuinfo

Et voilà on peut voir 4 thread entre 800 et 3700 MHz ! Tout fonctionne 🙂

Capture d’écran_2016-05-22_20-14-48

GRASS-GIS 7 et R

Contexte

Avec @fabio_zottele, nous nous sommes replongés ce weekend sur un travail un peu vieux. Celui-ci remonte à 5 ans, et consiste à proposer un algorithme basé sur des librairies/logiciels libres afin de détecter les terrasses viticoles. Ce travail avait initialement été développé sur R gdal et grass 6.3. pour une petite zone de la val di Cembra.

Notre objectif est aujourd’hui de systématiser l’algorithme et de vérifier que l’évolution des technologies et des algorithmes sur lesquels nous nous étions basés produit toujours le résultat attendu.

Installation de GRASS7Grass-GIS

La première chose à faire est de compiler GRASS-GIS en version 7, car les dépôts ne sont pas encore à jour sur Fedora. Vous pouvez trouver toute la documentation sur le wiki de grass.

On pourra commencer par télécharger le weekly snapshot du projet , et installer les dépendances qui vont bien :

sudo dnf install gcc gcc-c++ bison flex ncurses-devel proj-epsg proj-nad xml2 \
proj-devel gdal gdal-devel gdal-python sqlite-devel mesa-libGL-devel \
fftw-devel mesa-libGLU-devel libXmu-devel libX11-devel geos geos-devel \
libtiff-devel lesstif-devel python-devel numpy wxPython wxGTK-devel \
python-dateutil python-imaging python-matplotlib-wx subversion doxygen python-sphinx \
netcdf-devel postgresql-devel lapack lapack-devel blas blas-devel atlas atlas-devel

On peut ensuite aller compiler les sources :

cd ~/Téléchargement/grass7.0.svn/
./configure \
  --with-cxx \
  --with-gdal=/usr/bin/gdal-config \
  --with-proj --with-proj-share=/usr/share/proj \
  --with-python=/usr/bin/python-config \
  --with-geos \
  --with-sqlite \
  --with-nls \
  --with-wxwidgets=/usr/bin/wx-config \
  --with-fftw \
  --with-cairo --with-cairo-ldflags=-lfontconfig \
  --with-freetype --with-freetype-includes=/usr/include/freetype2 \
  --enable-largefile \
  --without-odbc \
  --with-ffmpeg \
  --with-ffmpeg-includes="/usr/include/ffmpeg /usr/include/ffmpeg/libav* /usr/include/ffmpeg/libpostproc /usr/include/ffmpeg/libswscale" \
  --with-blas --with-blas-includes=/usr/include/atlas-x86_64-base/ \
  --with-lapack --with-lapack-includes=/usr/include/atlas-x86_64-base/ \
make -j4 #pour compiler sur 4 thread
sudo make install

Et nous voilà avec une belle installation de grass7. Je vous encourage à faire un tour du propriétaire parce qu’un travail formidable a été fait ! Bravo à l’équipe de dev!

Comment se passe la communication avec R ?

RlogoEt bien figurez-vous qu’il y a le package qui va bien 😀 : rgrass7 qui s’installe comme d’habitude dans R avec :

install.packages(« rgrass7 », dependences = TRUE)

Mais l’utilisation diffère un peu de son grand frère. En effet, on peut désormais spécifier l’emplacement de votre GRASS7 fraichement compilé. On procèdera donc de la manière suivante :

remove(list=ls())
## Configuration Parametrs:
gisBaseLocation = "/opt/grass" #where the GRASS executables are
library(rgrass7) #load lib in R
initGRASS(gisBase=gisBaseLocation, override=TRUE) #Run GRASS in & Cancel previous running GRASS instance in R

L’exécution se fait ensuite avec une seule et même commande R à laquelle on passera en paramètre la commande GRASS

execGRASS(cmd= "g.remove", flags=c("f", "b"), parameters= list(type="raster", pattern="*"))

Ici on exécute donc dans R une commande GRASS qui va permettre de supprimer tous les rasters de la base de données GRASS.

Pour prendre un autre exemple :

execGRASS(cmd= "r.param.scale", flags= c("overwrite", "verbose"), parameters= list(input="DTM",output="CURVATURE", size=5, method="profc", zscale=2.0))

Ici on exécutera la commande r.param.scale  en spécifiant toutes les options.

Quand on veut ensuite sortir les résultats de GRASS pour les manipuler dans R, la méthode n’a pas beaucoup changé :

param.scale = raster(readRAST("CURVATURE"))

Ici on utilise la fonction raster du package éponyme pour convertir en raster les données en sortie de la fonction readRAST du package rgrass7.

Pour le plaisir des yeux

Voilà donc à partir de données LIDAR à 1m la proportion de surface avec des terrasses à l’échelle tu Trentino !

mappaEroica
Proportion de surfaces agricoles terrassées par tuile de données LIDAR à l’échelle de la région Trentino

Gephi 0.9 et Fedora 22

Les développeurs de Gephi nous ont fait un beau cadeau de Noël : la sortie de la version 0.9 de gephi. Ce qui me donne une bonne raison de vouloir le tester ce matin.

Je me suis donc lancé dans l’installation la fleur au fusil. Une fois le téléchargement effectué et la décompression faite, je lance fébrile le logiciel… gephi 0.8 n’avait jamais fonctionné de manière satisfaisante sur ma machine (Fedora 22 en 64 bits).

Caramba encore raté !  diaz-caramba-2

./gephi

me renvoie des erreurs, et si le logiciel se lance, je ne peux pas charger mon fichier gexf.

libEGL warning: DRI2: failed to open r600 (search paths /usr/lib/dri)
libEGL warning: DRI2: failed to open swrast (search paths /usr/lib/dri)
libGL error: unable to load driver: r600_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: r600
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast
libEGL warning: DRI2: failed to open r600 (search paths /usr/lib/dri)
libEGL warning: DRI2: failed to open swrast (search paths /usr/lib/dri)

Pourtant j’ai bien la librairie LibEGL ! Quelques visites de forum plus tard, il semble que le même problème se présente avec l’utilisation de steam sur des architectures 64bits. Et que le problème est résolut par l’installation du package mesa-dri-drivers.i686.

#dnf install mesa-dri-drivers.i686

et voilà gephi qui charge mon fichier ! Pas plus de difficulté ! Et en plus je n’ai pas installé Java proposé par Oracle, mais openJDK ! En tous cas merci la Team de dev gephi pour ce beau travail !

screenshot_105602

passage si vous cherchez quelques jeux de données super : la page de gephi dédiée, mais aussi quelques jeux de données bien geek dans l’univers de Marvel proposé par Kai Chang, Tom Turner, et Jefferson Braswell

Hyphe un web crawler pour l’HNA !

Je travaille depuis une semaine pour la Chaire « Capital Environnemental et la Gestion Durable des Cours d’Eau » de la fondation universitaire de Limoges. L’objectif est de travailler sur la dimension collective de gestion de l’eau et plus particulièrement sur les formes sociales qu’elle peuvent prendre.

La première chose que j’ai voulu faire a été de crawler un peu de web pour espérer comprendre comment étaient structurées les organisations autour de la gestion de l’eau sur mon terrain.

Pour cela, j’ai cherché pendant plusieurs heures un outil qui puisse, à partir d’une URL, identifier les liens et retrouver la constellation des renvois que font les sites institutionnels entre eux ; ce que les anglo-saxon appelle le HNA (hyperlink network analysis).

Si ma première réaction a été de me tourner vers R, je n’ai pas vraiment trouvé mon bonheur, et je ne voulais pas ré-écrire un web crawler. Du coup mes explorations m’ont poussé à découvrir :

  • SocNetv (un logiciel de réseau en Qt)
  • voson (un webservice sur inscription)
  • hyphe (un logiciel libre basé sur python et mongoDB)

Il se trouve que j’ai particulièrement aimé ce que propose hyphe, mais il n’est pas (encore) à proprement parlé multi-plateforme. Je me suis dit que ce serait l’occasion de tester Docker qui est une solution de virtualisation d’applications.

Docker quezako

Pour avoir un bon aperçu de ce qu’est Docker pour la virtualisation je vous encourage à lire un très bon post sur le blog de neogeo.

Utiliser Docker c’est magique ! Pour créer un conteneur sous Ubuntu voilà la marche à suivre.

sudo docker run -i -t ubuntu /bin/bash
adduser delaye
apt-get install sudo wget nano
nano /etc/sudoers
nano /usr/sbin/policy-rc.d
exit 0 #à la place de 101

Vous avez alors accès à une machine dans laquelle vous allez pouvoir monter un serveur, une application ou tout autre chose qui peut servir dans la vie d’un chercheur. Mais encore plus fort, vous pourrez déplacer le tout comme un fichier. Ce qui veut dire que vous pourrez échanger avec d’autres vos applications fonctionnelles dans des conteneurs.

Docker + Hyphe = <3

Revenons à nos moutons, la beauté du couple Docker / Hyphe, c’est que vous disposez sur le github de Hyphe d’un Dockerfile. Le Dockerfile vous permet dans un seul ficher texte de définir la configuration d’une application multi-conteneur. Dans notre cas @oncletom nous propose de faire fonctionner hyphe sur 4 conteneurs Docker :

Pour cela vous devez ajouter une brique à Docker : docker-compose. Cette brique s’installe facilement en suivant les indications de la doc.

Une fois que c’est fait, vous pouvez vous rendre dans le répertoire dans lequel vous avez cloné hyphe et lancer l’installation des conteneurs grâce au Dockerfile.

cd github/hyphe/
docker-compose up

Il est temps d’aller prendre un café parce que l’installation prend un certain temps (15 min chez moi). La prochaine fois que vous lancerez l’application avec docker-compose up l’instanciation des composants se fera beaucoup plus rapidement.

Vous accédez à l’application via votre navigateur (pour le moment, Firefox n’est pas supporter et vous devrez utiliser chrome ou chromium) à l’url suivante http://localhost:8000/#/login.

hyphe is workingVous pouvez explorer des projets « test », mais aussi et surtout vous lancer dans un nouveau projet et lâcher vos petits robot dans les méandres de la toile !

hyphe is crawling

Note

Si vous avez besoin de relancer l’installation des conteneurs (s’il y a eu des maj de hyphe par exemple) vous pouvez reconstruire les conteneurs avec

docker-compose build

Fedora : un script post-install pour géographe

Depuis 2011, je prenais soin d’un petit archlinux. Je m’en occupais et faisais bien attention logo Archlinuxà chaque mise à jour, ce qui se révélait parfois sportif, quand tout à coup, sans savoir pourquoi X11 ne répondait plus …

Quand il a fallu rentrer en rédaction de thèse, la première mise à jour difficile m’a fait chercher un système stable… et j’ai essayé Fedora. Voilà maintenant 1 an que je suis donc dans le monde bleu, l’antichambre de Redhat… Et contre toute attente, j’en suis très satisfait. Mais voilà, peut-être à cause du manque de temps, je n’avais pas fait la migration de Fedora 20 à 21… donc il y a quelques semaines, les dernières mises à jour sont arrivées… et rien n’est plus triste que d’avoir un système figé…

Je me suis lancé dans la sauvegarde et la réinstallation du système, mais il faut bien avouer que le pire de tout est la phase de logo Fedorapost-install… les quelques jours où, à chaque besoin logiciel, il faut procéder à une installation.

En soi ce n’est pas forcément problématique, mais en cas de déplacement ou de perte de connexion … rien de plus frustrant. Aussi suis-je partie en quête d’un script de post-install Fedora. J’en ai trouvé un, proposé par Sam Hewitt sur gitHub.

Il ne me restait plus qu’à y ajouter quelques petites choses pour obtenir un beau script de post-install Fedora pour un géographe ! J’ai donc forké !

githuboctacat

On y retrouve toutes les librairies spatiales qui vont bien (gdal, geos, proj4, etc), mais aussi R (et ses packages super comme rgdal, ggplot2, etc), et enfin une fresh build de texlive !

De quoi gagner du temps aux prochaines installations !

la suite …

soutenance DELAYUn petit billet pour vous annoncer avec fierté mon passage dans le monde des docteurs en géographie. La soutenance s’est déroulée le 10 juin à 14h à la FLSH de Limoges. La thèse soutenue sous la direction de E. Rouvellac, N. Becu et P. Allée s’intitule : « Réflexions géographiques sur l’usage des systèmes multi-agents dans la compréhension des processus d’évolution des territoires viticoles de fortes pentes : le cas de la Côte Vermeille et de la val di Cembra« 

J’ai poussé sur github tout le matériel… la thèse (pour les curieux),  la présentation de la soutenance, les différents modèles à base d’agents. En avant-gout, en voilà le résumé :

En ce début de XXIe siècle, le vin et la vigne constituent une richesse importante pour bon nombre de pays. Les territoires viticoles, tout en conservant leurs qualités d’espace de production, développent des stratégies d’adaptation à la globalisation du marché et aux attentes des consommateurs toujours plus versatiles.
Or en raison de conditions orographiques particulières, les territoires de montagne et de fortes pentes voient leurs marges de manœuvre réduites. En effet, une grosse partie de leurs coûts de production reste bien souvent incompressible par rapport à la viticulture de plaine. Paradoxalement ces paysages viticoles, image du construit social et des équilibres environnementaux, participent à leur reconnaissance internationale.

Le travail présenté ici est né en réponse à la sensibilité croissante de ces vignobles de forte pente. En nous appuyant sur deux territoires d’étude, en France le vignoble de la Côte Vermeille et en Italie le val di Cembra, nous questionnons les spécificités de la viticulture de fortes pentes. Notre approche met l’accent sur les possibilités offertes par des méthodes empiriques de modélisation à base d’agents pour proposer un regard renouvelé sur le rôle des interactions société-environnement dans le maintien et le développement de ces territoires sous contraintes.

A travers une constellation de modèles multi-agents issus des questionnements récurrents des acteurs de la filière, et selon une démarche exploratoire et incrémentale, nous nous intéresserons ici à trois grands types de questions posées aux territoires viticoles de fortes pentes.
Le premier concerne la place du marché et ses conséquences sur les dynamiques de couvert végétal à petite échelle. Le second type de questionnement explore également les dynamiques spatiales du couvert végétal, mais se place à mezzo-échelle, et propose de s’intéresser à la définition des règles socio-économiques simples qui sous-tendent les dynamiques foncières à l’échelle de quelques communes. Enfin le dernier volet de ce travail se place à grande échelle et s’intéresse à des phénomènes très descriptifs.

L’ensemble de ces réflexions nous amènera ensuite à utiliser la modélisation co-construite avec les acteurs pour proposer une vision prospective globale pour les territoires de montagne et de fortes pentes. Cette approche prospective sera conduite en parallèle avec certains acteurs de la filière ce qui nous permettra de délimiter les variables structurelles propres aux systèmes de fortes pentes telles qu’elles sont ou non vécues par les acteurs. Basés sur la délimitation de ces variables, nous proposons enfin quatre scenarii prospectifs pour la viticulture en forte pente.

ScreenCast facile sous linux

J’utilise depuis 2 ans un très bon framework HTML et JavaScript du nom de reveal pour faire faire mes présentations. Comme on est en HTML, on peut bénéficier du lecteur de vidéo HTML5!

J’ai donc de temps à autre besoin de faire une capture d’écran sous forme de vidéo pour les intégrer aux présentations. Pour cela j’utilise un utilitaire en ligne de commande : recodremydesktop.

Comme près requis, il faut connaître l’ID de la fenêtre à screencaster. Ce qui est possible grâce a :

xwininfo

J’utilise ensuite recodremydesktop en lui indiquant la fenêtre d’intérêt :

recordmydesktop --no-sound --windowid 0x640001

Et parce que c’est pour intégrer ces vidéos dans reveal en html5 il faut faire une petite transformation en webm

ffmpeg -i foo.avi foo.webm

Et voilà ready !