IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Algorithmes et structures de données Discussion :

Estimation de mouvement


Sujet :

Algorithmes et structures de données

  1. #1
    Membre éclairé

    Inscrit en
    Juin 2004
    Messages
    1 397
    Détails du profil
    Informations forums :
    Inscription : Juin 2004
    Messages : 1 397
    Points : 763
    Points
    763
    Par défaut Estimation de mouvement
    Bonjour à tous !
    J'aimerais bien mettre en oeuvre, dans le cadre d'un algorithme n'ayant pas de rapport avec la compression, un algorithme (rapide) d'estimation de mouvement.
    J'ai bien sûr trouvé pas mal de doc à ce sujet, mais c'est la mise au point de l'algorithme qui me pose problème...

    J'ai en entrée deux images, l'une étant la référence, l'autre l'image à "prédire".
    Chacune des images est un tableau (de type unsigned char *, mais ce n'est pas la question), dont la composante (x,y) est calculée par :
    width étant bien sûr la largeur de l'image.

    Mon problème principal est :
    Comment copier dans un tableau (un vector en l'occurence) les MxM pixels constituant mon bloc, avec un algo (très) rapide ?
    Je précise que je code en C++, mais je cherche l'algorithme, pas le code .

    Merci d'avance de votre aide, je galère un peu...
    Aucune réponse à une question technique par MP.
    Ce qui vous pose problème peut poser problème à un(e) autre

    http://thebrutace.labrute.fr

  2. #2
    Expert éminent Avatar de Graffito
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    5 993
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 5 993
    Points : 7 903
    Points
    7 903
    Par défaut
    Bonjour,

    J'ai envie de dire :
    - Si les images ont des largeurs différentes, copier lignes par lignes par une copie de blocs mémoires (memcopy en C je crois)
    - Si elles ont la même largeur, une seule copie mémoire suffit.

    Mais, je ne suis pas sur d'avoir bien compris où était le problème.
    " Le croquemitaine ! Aaaaaah ! Où ça ? " ©Homer Simpson

  3. #3
    Rédacteur

    Avatar de millie
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    7 015
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 7 015
    Points : 9 818
    Points
    9 818
    Par défaut
    Citation Envoyé par progfou
    Comment copier dans un tableau (un vector en l'occurence) les MxM pixels constituant mon bloc, avec un algo (très) rapide ?
    De plus, utilise l'option de compilation (fonctionne avec g++) : -O3 (pour les optimisations de vitesse maximale). Ca peut donner un coup de pouce.
    Je ne répondrai à aucune question technique en privé

  4. #4
    Membre éclairé

    Inscrit en
    Juin 2004
    Messages
    1 397
    Détails du profil
    Informations forums :
    Inscription : Juin 2004
    Messages : 1 397
    Points : 763
    Points
    763
    Par défaut
    Je précise :
    Les blocs en question, de taille MxM, sont centrés en (x,y).
    Donc, il me faut aller chercher les pixels dans l'image de référence de (x-M/2) à (x+M/2) et de (y-M/2) à (y+M/2).
    Ensuite, je dois faire varier deux paramètres, qui sont les composantes d'un vecteur de déplacement (compris entre -w et +w, w entier), et aller chercher le bloc à l'emplacement [(x+wx), (y+wy)] dans l'image à estimer.

    Une fois que j'ai ces blocs, il me faut faire une différence, et ça ne me pose pas de problème, mais c'est la copie de ces blocs qui me gêne !
    Aucune réponse à une question technique par MP.
    Ce qui vous pose problème peut poser problème à un(e) autre

    http://thebrutace.labrute.fr

  5. #5
    Expert éminent Avatar de Graffito
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    5 993
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 5 993
    Points : 7 903
    Points
    7 903
    Par défaut
    Bonjour,

    Les pixels dans l'image de référence de la ligne j (avec j variant de y-M/2 à y+M/2) sont contenus dans des octets consécutifs du tableau, décalés par rapport au premier octet du tableau de (j*width+x-M/2)*size_of(Tab_item) et sur une longeur de M*size_of(Tab_item).
    " Le croquemitaine ! Aaaaaah ! Où ça ? " ©Homer Simpson

  6. #6
    Membre éclairé

    Inscrit en
    Juin 2004
    Messages
    1 397
    Détails du profil
    Informations forums :
    Inscription : Juin 2004
    Messages : 1 397
    Points : 763
    Points
    763
    Par défaut
    C'est quoi Tab_item ?
    Tu peux expliciter ce que tu as essayé de dire ?
    Aucune réponse à une question technique par MP.
    Ce qui vous pose problème peut poser problème à un(e) autre

    http://thebrutace.labrute.fr

  7. #7
    Expert éminent Avatar de Graffito
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    5 993
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 5 993
    Points : 7 903
    Points
    7 903
    Par défaut
    Tab_item c'est un élément du tableau.
    je suppose des unsigned char * [donc (sizeof(tab_item)=1], ce qui fait 256 couleurs seulement ou est-ce du noir et blanc avec un bit par pixel?

    Si c'est du noir et blanc, il faut traiter séparement les octets de sur bords de la ligne.
    " Le croquemitaine ! Aaaaaah ! Où ça ? " ©Homer Simpson

  8. #8
    Membre éclairé

    Inscrit en
    Juin 2004
    Messages
    1 397
    Détails du profil
    Informations forums :
    Inscription : Juin 2004
    Messages : 1 397
    Points : 763
    Points
    763
    Par défaut
    En fait, j'ai tendance à faire un parcours du tableau en y, avec une boucle imbriquée pour les x, mais ça me semble très lourd.
    Avec ce que tu as dit, je me dit, faire une boucle avec un memcopy, pourquoi pas...
    On peut être plus rapide ?
    Aucune réponse à une question technique par MP.
    Ce qui vous pose problème peut poser problème à un(e) autre

    http://thebrutace.labrute.fr

  9. #9
    Expert éminent Avatar de Graffito
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    5 993
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 5 993
    Points : 7 903
    Points
    7 903
    Par défaut
    Y a pas grand chose à gagner sauf si c'est un bit par pixel et que w n'est pas multiple de 8.
    " Le croquemitaine ! Aaaaaah ! Où ça ? " ©Homer Simpson

  10. #10
    Membre éclairé

    Inscrit en
    Juin 2004
    Messages
    1 397
    Détails du profil
    Informations forums :
    Inscription : Juin 2004
    Messages : 1 397
    Points : 763
    Points
    763
    Par défaut
    Oups, je n'ai pas répondu, donc, c'est du 8 bits par pixels, et w, en général n'est pas multiple de 8.

    J'ai une autre question de la même veine...
    J'ai une matrice m'indiquant l'ordre dans lequel je dois traiter mes pixels, par exemple :
    Comment je peux m'en servir dans mon programme ?
    Aucune réponse à une question technique par MP.
    Ce qui vous pose problème peut poser problème à un(e) autre

    http://thebrutace.labrute.fr

  11. #11
    Expert éminent Avatar de Graffito
    Profil pro
    Inscrit en
    Janvier 2006
    Messages
    5 993
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2006
    Messages : 5 993
    Points : 7 903
    Points
    7 903
    Par défaut
    0 2
    3 1
    A qoui correspondent les lignes et les colonnes ?
    " Le croquemitaine ! Aaaaaah ! Où ça ? " ©Homer Simpson

  12. #12
    Membre éclairé

    Inscrit en
    Juin 2004
    Messages
    1 397
    Détails du profil
    Informations forums :
    Inscription : Juin 2004
    Messages : 1 397
    Points : 763
    Points
    763
    Par défaut
    L'ordre dans lequel il faut prendre les pixels dans le bloc 2x2 (premier en haut à gauche, etc.).
    Aucune réponse à une question technique par MP.
    Ce qui vous pose problème peut poser problème à un(e) autre

    http://thebrutace.labrute.fr

  13. #13
    Inactif  
    Profil pro
    Inscrit en
    Mars 2004
    Messages
    743
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2004
    Messages : 743
    Points : 460
    Points
    460
    Par défaut
    Je sais bien que la discussion date un peu.
    Mais pour ceux que ça intéresse, j'ai mis en ligne mon code d'estimation de mouvement (très optimisé: MMX,SSE2,SSE3).
    Attention à la licence GPL!

    http://www.ient.rwth-aachen.de/team/...al/genial.html

    La compilation de mon code C++ est un peu délicate, le plus simple pour les utilisateurs de Pentium 4 consiste à utiliser les fonctions correspondantes (Interface C) de la bibliothèque pré-compilée.

Discussions similaires

  1. estimation de mouvement et la reconstruction 3d
    Par info_sara dans le forum Traitement d'images
    Réponses: 3
    Dernier message: 17/12/2011, 14h04
  2. Estimation de mouvement par homographie
    Par black_hole dans le forum Traitement d'images
    Réponses: 0
    Dernier message: 13/06/2011, 17h34
  3. Réponses: 1
    Dernier message: 16/05/2010, 20h58
  4. lucas kanade et estimation du mouvement
    Par hakemass dans le forum Traitement d'images
    Réponses: 2
    Dernier message: 31/08/2008, 09h41
  5. estimation de mouvement par la methode de flot optique
    Par hanane78 dans le forum Traitement d'images
    Réponses: 3
    Dernier message: 25/10/2007, 08h31

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo