SlowMovideo pour des ralentis époustouflants

Super Slow Motion Beer Test
Super Slow Motion Beer Test (Photo credit: Nicholas Upton)

Faisant quelques vidéos pour mon club de cerf-volant Cramayailes j’ai bien entendu déjà eu l’envie de faire de jolis ralentis, un peu à la manière des vidéos de promotion d’ une célèbre caméra de sport. Pour cela il faut trivialement enregistrer à un taux d’image très élevé de sorte qu’une lecture au ralenti de soit pas saccadée. Par exemple si on enregistre à 240 images par seconde puis que l’on lit la vidéo en ne faisant défiler que 24 images par seconde, alors on a une vidéo fluide ralentie 10 fois par rapport à l’original. Si l’on a pas un débit original élevé disons 24 images par seconde, alors faire un ralenti simple, disons ne serait-ce que 2 fois plus lent, oblige à ne dérouler plus que 12 images par seconde, produisant un effet de saccade. La solution de la caméra à prise de vue rapide est la plus précise mais oblige à toujours enregistrer en haut débit de défilement pour finalement ne choisir au montage que de prendre certaines scènes au ralenti et de laisser tomber le débit orignal pour les autres scènes en supprimant les images en trop car au final la vidéo ne fera que 24 voire au maximum 60 images secondes.  Quel gâchis….

Le logiciel slowmovideo permet de créer des ralentis fluides à partir d’une séquence vidéo enregistrée en débit normal (par exemple 24 images par seconde). La fluidité est obtenue en interpolant des images intermédiaires afin de garder un débit constant (par exemple un ralenti 2 fois aura toujours 24 images par seconde). C’est une solution logicielles qui crée des images intermédiaires par détection de mouvement de pixel entre 2 images. L’auteur explique cela dans son mémoire.

Le résultat est très probant sur la vidéo suivante où l’on cherche à ralentir une séquence de 6 secondes pour la faire durer environ 20 secondes. Voici la vidéo originale:

Après un passage dans le logiciel Slomovideo on obtient :

CIGREF Publications: 2010 – Maturité et gouvernance de l’Open Source

Une publication du CIGREF à paraitre qui sera intéressant à lire et à diffuser. Voilà encore une preuve que l’open source est une solution de premier choix et que sa non utilisation doit maintenant être justifiée plutôt que de se demander si on peut ou non s’en servir.

CIGREF Publications: 2010 – Maturité et gouvernance de l’Open Source.

Planificateur de tâches dans Trac

wikipedia:Trac icon, modified for the Open Ico...
Image via Wikipedia

Trac est un outils de gestion de projet pour lequel il existe de nombreuses extensions que l’on trouve sur le site trac-hacks . Mais il existe un plugin qui manquait à cette liste: un planificateur de tâche comme Cron.

Pourquoi aurait-on besoin d’un cron? Certaines tâches récurrentes comme la création périodique de ticket de type tâche comme par exemple “revue de code” pourraient ne plus avoir besoin d’être créées à la main. Dans mon cas, j’ai une version personnalisée de Trac qui possède une fonction de synchronisation des utilisateurs natifs Trac avec une table spécifique mise à jour journalièrement. La synchronisation est codée dans une méthode appelée par un bouton dans l’interface d’administration. Cette synchronisation ne peut être appelée que depuis Trac car elle fait usage de l’API de Trac.

Pour parvenir à nos fins nous pouvons utiliser le planificateur de l’OS ( Cron unix ou AT de Windows) mais cette solution manque d’élégance car on va ajouter un adhérence avec l’OS. De plus même si on enrichie la commande trac-admin pour bénéficier de l’environnement de Trac, il restera à gérer la concurrence avec le processus trac. C’est pour ses raisons que le choix d’un ordonnanceur de tâche intégré à Trac a fait son chemin.

Comment développer un tel planificateur?

La documentation de Trac nous montre qu’il est possible de définir des “composant” et des “extension”. Un composant est un plugin Trac qui est instancié par Trac. Une extension est un composant qui implémente une interface. Dans Trac il existe des interface standard comme ITicketValidator qui indique que le composant sait valider les champs d’un ticket. Chaque composant peut utiliser des extensions.

Pour notre besoin il nous suffit de :

  1. définir une interface de tâche ICronTask
  2. définir un composant Corequi utilisera les extensions de type ICronTask
  3. Le composant Core doit se charger de gérer l’ordonnanceur par une thread dédiée
  4. La thread dédiée doit se lancer dès le démarrage de Trac: pour cela on va intercepter l’instanciation du composant parce que Trac ne définit par d’interface pour capter son démarrage

Tels sont les éléments clés à mettre en œuvre auxquels s’ajoutent les point suivants pour une plus grande utilisabilité:

  1. Paramétrage dans trac.ini et par interface d’administration
  2. État de l’ordonnanceur : marche/arrêt paramétrable
  3. précision de l’ordonnanceur paramétrable
  4. plusieurs planification pour une même tâche
  5. planification dans l’interface d’administration

Désormais ce plugin existe, il est disponible sur Trac-Hacks, il s’agit de TracCronPlugin

Retour d’expérience sur la personnalisation de Trac

 

wikipedia:Trac icon, modified for the Open Ico...
Image via Wikipedia

 

Il y a quelques jours que j’ai commencé à personnaliser Trac pour les besoins de mon employeur. L’objectif était de fournir aux utilisateurs qui sont en grande majorité non informaticiens, un outils de saisie de demande. Le choix de Trac comme base peut paraitre incongru puisque Trac est avant tout destiné à gérer les projets de développement logiciel. Certes, mais Trac n’en demeure pas moins un outils de traitement de bug, de ticket et pourquoi pas de demandes?

D’autres arguments m’ont poussé à choisir Trac. Il est gratuit, open-source et libre. De plus il dispose d’une large base d’extension permettant d’ajouter sans codage (codage en python) de nouvelles fonctionnalités voire d’en modifier des existantes. Ce billet montre comment nous sommes parvenus avec un minimum de code à obtenir une application répondant aux besoins et couvre la version 0.12 de Trac.

En premier lieu on s’aperçoit rapidement qu’il y a plusieurs niveaux d’intervention. En effet Trac est conçu comme un conteneur de projet. L’outil finale sera donc constitué de Trac plus un projet. Dans ce cas on voit clairement les niveaux d’interventions suivants:

  1. Par ajout de plugin
  2. Par paramétrage dans le projet dédié
  3. Par développement dans le projet dédié
  4. Par développement dans Trac lui-même
  5. Par développement dans les plugin

Ajout de plugin

Les liens suivants contiennent une très longue liste de plugin: le site de trac et le site des plugin.

Les plugins sont soit des fichiers py (module python) soit des fichiers egg (livrable ou librairie python). Si le plugin est disponible uniquement sous forme de source alors il faudra le compiler pour générer un egg avec la commande:

python setup.py bdist_egg

Pour installer un plugin il est préférable de le mettre dans le répertoire du projet. Cela permet de faire cohabiter sur le même système plusieurs versions d’une librairie (chacune dans un processus python distinct). Par exemple si le projet s’appelle gesdem il faut placer les plugin dans

gesdem/plugins

Toutefois si Trac est en cours d’éxécution, on peut passer par l’interface d’administration d’un projet donné pour ajouter le plugin.

Paramétrage dans le projet dédié

Le paramétrage dans le projet dédié consiste à modifier les paramétres dans le fichier trac.ini du prjet. Soit dans le cas du projet qui s’appelle gesdem:

gesdem/conf/trac.ini

Le paramétrage du projet se fait également par la page d’administration. Ce paramétrage va mettre à jour le fichier trac.ini mais également la base de données pour certains plugins.

Développement dans le projet dédié

Nous entendons par développement tout simplement la modification des templates. Trac possède une notion d’héritage de configuration ainsi on peut mettre des templates dans le projet dédié qui vont écraser ceux par défaut.

Développement dans Trac lui-même

Si les sources de Trac sont dans un répertoire nommé trac-0.12 alors il faut se rendre dans le répertoire suivant pour trouver les modules python et les templates à modifier:

trac-0.12trac

Développement dans les plugin

Les plugins peuvent nécessiter des ajustements. Dans ce cas il faut télécharger les sources et prendre soin de au moins créer/modifier le fichier setup.cfg pour ajouter un suffixe remarquable puisque nous allons faire un fork. Voici un setup.cfg minimal:

[egg_info]

tag_build = monTagAMoi
tag_svn_revision = true

Remplacer monTagAMoi par le nom de votre organisation par exemple !