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

coucou,

inutile de faire autrement quant à l'extraction des images de la vidéo,
ni quant à la fabrication d'une vidéo recadrée dynamiquement ;

ça c'est ffmpeg. Faudrait voir si on peut se basser sur libffmpeg.

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,

ouaip. Mais on avait opté pour opencv car ça allégeait clairement les dépendances...

Quand il est présent, c'est vrai que c'est très pratique..

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

vouaip, toutafé.

Pour cette prérogative, je pense que nous avons de nombreux progrès à
faire :

-> actuellement, on utilise l'algo

(ligne 62 de detect.py)

cv2.matchTemplate(image, part, cv.CV_TM_SQDIFF)

pourquoi celle-là ? euh... je sais pas. Elle marchait pas torp mal ;)
http://docs.opencv.org/doc/tutorials/imgproc/histograms/template_matching/template_matching.html

- si le détail à suivre se distingue par 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".

ouaip

- 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

ouaip. Ceci ne doit pas être dévolue à la future "bibliothèque" mais à pymecavideo : la fonction de détection prend 2 arguments principaux :

l'objet de référence, l'image totale.

Il suffirait, on peut déjà tenter de le faire, de ne refiler qu'une partie de l'image totale, située, par exemple dans un carré de 1/4 de côté de l'image totale (1/4, ça diminue par 16 le temps de calcul déjà...) pourquoi 1/4 ? je sais pas, ça me paraît correct. Certains chutes libres font 1/4 de la hauteur entre chaque image sur la fin de la chute.

- à 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.

-> oui, on peut se baser à chaque fois sur une "moyenne" de l'objet. Ceci est aussi encore implémentable déjà avec le mécanisme actuel.

- 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..

ça d'un coup, c'est autre chose, c'est la bibliothèque qui doit le faire, c'est trop intelligent pour être dans le code de pymecavideo.

On peut donc déjà travailler là-dessus.

Pour ma part, je travaille ce soir le 'defait/refait" ;)