Re: [pymecavideo] []banche changementStockageDonnees]Avant basculement

[ Thread Index | Date Index | More lists.tuxfamily.org/pymecavideo Archives ]


Bonjour Jean-Baptiste,

merci pour le rappel quant à l'utilité d'openCV pur pour nous.

Donc, détrompe-moi si je radote :

inutile de faire autrement quant à l'extraction des images de la vidéo,
ni quant à la fabrication d'une vidéo recadrée dynamiquement ; si on se
passe du "lecteur de vidéo" simplifié d'openCV et qu'on délègue
la lecture de la vidéo calculée à un lecteur comme VLC,

... il ne reste que le suivi d'un fragment d'image au long de la vidéo
comme prérogative exclusive d'openCV.

Pour cette prérogative, je pense que nous avons de nombreux progrès à
faire :
- si le détail à suivre se distingue pas sa couleur, il vaut mieux
  calculer l'auto-corrélation dans l'espace HSV (hue-saturation-value)
  plutôt que dans l'espace RGB, en donnant un poids fort à "hue".
- il conviendrait de faire une recherche du détail dans une région plus
  restreinte que la totalité du cadre de la vidéo. Si par exemple on a
  trouvé le détail en x,y dans l'image n, alors ça vaut la peine de
  n'explorer qu'un voisinage proche de x,y pour l'image (n+1) : ça évite
  des fautes grossières et ça accélère le calcul
- à mesure qu'on arrive à suivre le détail d'image en image, on devient
  capable d'en extraire un meilleur modèle que l'échantillon d'image
  présenté en première intention ; on peut se permettre de remplacer le
  premier modèle par quelque chose qui tienne compte de celui-ci et des
  portions d'images reconnues en suivant ; le résultat serait peut-être
  qu'on gagnerait en possibilités de suivi si les conditions d'éclairage
  du détail à suivre changent d'une image à l'autre.
- en se basant sur la totalité de la vidéo, il y a moyen de voir si on a
  affaire à un plan fixe, et le cas échéant, reconstituer l'image de
  fond pour augmenter ensuite la qualité du suivi des objets mobiles, en
  soustrayant d'une façon ou d'une autre le fond immobile.

Qu'en penses-tu ?

Amitiés,			Georges.

Jean-Baptiste BUTET a écrit :
> Bonjour les gens...
> 
> Bon... dans cette branche qu'est ce qui ne fonctionne pas de manière
> optimale ?
> -> le redimensionnement. C'est un casse-tête sans nom. Je ne comprends pas
> la logique Qt.
> 
> Pour le reste. Je crois que tout est finalisé. Le seul truc que j'ai vu,
> c'est en capture automatique des points, le dernier point de la vidéo ne se
> fait pas. (alors qu'à la main, il est atteignable)
> Je pense clairement que cette version est pas mal, très rapide et MEME la
> réinitialisaiton foncitonne !!
> 
> 
> Pour le redimensionnement :
> 
> Si quelqu'un se sent d'y jeter un coup d'oeil...
> -> les objectifs :
> 1) que le label_video se redimensionne quand on redimensionne et avec le
> bon ratio. ---> variables touchées : self.largeur et self.hauteur dont le
> calcul se fait dans self.determineLargeurHauteur()
> 
> 2) que la fenetre principale (self) se redimensionne en fonction de
> self.label_video
> Seulement ATTENTION !! si à la récupération du resizeEvent, on fait un
> calcul de hauteur/largeur que l'on le réinjecte dans un self.geometry ou un
> self.setFixedWidth ou tout autre chose qui change la taille, on relance un
> resizeEvent. Vous la voyez venir la boucle infinie ?? Linux s'en sort assez
> bien. (complètement transparent à l'utilisateur...Bug ou feature ?? ) par
> contre sous windows... freeze total.
> 
> C'est pourquoi apparaît dansle resizeEvent un petit timer qui externalise
> en "1coup" cette commande de redimensionnement et coupe la boucle du coup.
> 
> Bref... j'y ai passé plusieurs heures à me casser les dents... j'arrête. Le
> mécanisme actuel est moyen mais fait presque ce qu'on lui demande.
> Je laisse ça à des gens plus rigoureux que moi ;)
> (y'a des histoires de layout, de sizepolicy que je ne maitrise pas mais qui
> sont très intéressantes)
> 
> NB : il y a des traductions à faire pour les courageur !
> 
> JB

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70

Attachment: signature.asc
Description: Digital signature



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/