Discussion :

[Philooo]

Bonjour,

N'ayant pas trouvé de réponses à ma question ni dans le forum, ni ailleurs sur le net, je me permets d'ouvrir un nouveau sujet. Voici donc mon problème :

Je développe une application d'enregistrement d'images en temps réel à partir d'une caméra. Pour diverses raisons, je dois enregistrer les images une à une (et non sous forme de séquence vidéo), au format JPEG.

Je fais donc appel à la fonction cvSaveImage("MonNomDImage.jpg", MonImage) à intervalle de temps régulier (par exemple toutes les 40 ms, si le framerate d'acquisition est à 25 images / secondes).

J'ai réalisé en cours de route que le simple appel à cette fonction prenait en moyenne une centaine de millisecondes (je précise que je travaille sur des images 1024*768 couleur), ce qui m'empêche d'enregistrer mes images à 25 images par secondes (bon, sans aller jusqu'à demander un tel framerate d'enregistrement, faire passer le temps que prend cvSaveImage de 100ms à 50 ms me suffirait amplement).

Donc mes questions sont les suivantes :
1. Vu le contexte d'utilisation (et notamment la taille des images), un tel temps (un dixième de seconde, ça me paraît énorme) pour la fonction cvSaveImage vous paraît-il normal ?
2. Si la réponse à la question 1. est "oui", à quoi est consommé le temps ? J'ai diverses idées, qui me paraissent toutes assez farfelues : temps d'encodage jpeg (mais si c'était la source du problème, comment serait-il possible d'encoder une vidéo en mjpeg en temps réel ?), temps d'accès disque (peut-être que l'enregistrement répété de fichiers différents demande un temps important au disque dur), ...
3. Si la réponse à la question 1. est "non", auriez-vous des suggestions pour améliorer ce temps ?

A toutes fins utiles, je précise que je suis sous Fedora Core 6, avec un processeur double coeur à 2,4 GHz, 2 Gigas de RAM. Ma version d'opencv est la 1.0.0.

Un grand merci d'avance à quiconque m'apporterait une réponse, une piste, un indice, une indication !

Philippe

[Vinsss84]

Pour éliminer le facteur temps d'encodage jpg teste l'enregistrement en tif ou bmp.
Cela dit je ne pense pas que ça change grand chose. Peux tu détailler un petit peu plus ton code?

Sinon tu utilises tes 2 coeurs ? Quid de l'utilisation mémoire lors du déroulement du programme?

Pourquoi ne pas enregistrer la séquence vidéo et la décomposer ensuite en frame? LE type d'application que tu souhaites développer exclu cette possibilité?

edit : je viens de tester la durée de cvSaveImage sur une image n/b 2274*1768 et je suis environ à 12 ms avec mon dual core 2.2 (un seul core utilisé)

[Philooo]

Bonjour Vinsss84,

Merci pour ta réponse, grâce à toi, j'ai bien l'impression que mon problème est partiellement résolu!

J'avais déjà essayé d'enregistrer les images en ppm. Dans ce format, l'enregistrement est encore plus lent qu'en jpg. Cependant, un coup d'oeil à mon moniteur réseau m'indique que c'est la latence E/S qui semble limiter l'enregistrement. Wikipedia dit que cette latence E/S est en rapport avec l'utilisation du disque dur (http://fr.wikipedia.org/wiki/Disque_dur#Performances), j'avais supposé que la taille conséquente de l'image en était la cause, et j'avais donc abandonné l'idée d'enregistrer mes images en un format non compressé.

PNG ne donnant rien d'intéressant non plus, j'étais revenu au jpg.

Suite à ton post, j'ai essayé d'enregistrer l'image en tif, puis en bmp, et là, le monde bascule! L'enregistrement en tif (ou bmp, d'ailleurs) est fluide, et j'atteint le framerate max d'enregistrement (15 images / secondes) ! Les images sont certes plus grosses, mais je trouverai des dérivatifs pour que ça ne pose pas de problème.

En y regardant de plus près, je constate que l'enregistrement en tif / bmp donne des images de 2,3 Mégas, là où l'enregistrement en PPM donnait des images de 11 Mégas... 2,3 Mégas, c'est intermédiaire : on n'a plus de problème de latence E/S, et pas de problèmes de compression non plus!

Pour répondre à tes autres questions, j'utilise mes deux coeurs, mais les autres threads sont sans rapport. Vu mon application, il serait lourd d'enregistrer la séquence vidéo, puis de la décomposer en frame. En ultime recours, ça resterait envisageable, mais ça représente plusieurs jours de refactoring...

Conclusion : problème de temps d'enregistrement résolu, nouveau problème (moins grave et contournable) de taille des images sur disques (1 minute d'enregistrement à 15 images / secondes fait tout de même 2 Gigas), et une nouvelle question pour éclairer ma lanterne :

J'avais cru comprendre au vu de mes pérégrinations sur internet que les format ppm et bmp étaient plus ou moins équivalents... Quid de la différence importante de taille entre la même image en ppm et en bmp/tif ?

Encore merci!

Philou

[Vinsss84]

Content d'avoir pu être utile

le ppm est un format "ASCII based" si tu ouvres un fichier ppm dans un txt tu verras pourquoi on dit ça JE pense que la réecriture en ascii du fichier image est couteuse en temps et en espace disque.
Le ppm à le merite de pouvoir se traiter sans librairie particulière
Pour le tif et le bmp le pixel storage se fait différement, d'ou peut être une écriture du fichier bien plus rapide.
Après je pense que tout dépend du type qui sort de ta caméra et après ça ça va dépendre du constructeur (précense ou non d'un up de compression, etc.)
Bon bref, à mon sens de toute façon le tif est le format le plus intéressant pour un traitement posterieur de l'image, libre à toi de refaire une conversion à posteriori.