On recommence...

L'effet indésirable vu ci-dessus vient du fait qu'on compare deux scène décalées physiquement (d'un pixel en vertical), donc qui n'ont rien à voir. Il faudrait comparer deux vues physiquement semblables, qui ne différent que dans le temps. Autrement dit, on va devoir faire non pas de la différence de trames, mais de la différence d'images.

Le problème est que la fréquence des images est deux fois plus faible que celle des trames. On pourrait faire clignoter la balise deux fois plus lentement, soit à 15Hz, mais :

• ça fait mal aux yeux, les caméras de télévision risquent de ne pas aimer, les spectateurs non plus
• ça double le temps d'acquisition de la position de la balise, qui est déjà long (cf. plus loin)...
• ça nécessite de stocker deux fois plus de pixels, et :
  • nos cartes sont limitées en RAM vidéo (rappel : on n'a pas de PC embarqué et autres PC104, nos cartes on les fait nous même, avec des vraies contraintes de systèmes embarqués...)
  • bon d'accord, on a quand même assez de RAM vidéo, mais bon, si il y a une solution meilleure, pourquoi gâcher ?
  • et puis, on aimerait bien garder la RAM vidéo externe pour d'autres traitements. Si on peut se contenter de la RAM interne au FPGA c'est mieux.
  • OK, on pourrait ne stocker et travailler que sur une trame sur deux. Mouais, reste quand même le clignotement à 15 Hz désagréable...

Pour travailler sur des images en gardant la même fréquence des balises et sans avoir à stocker des images entières, le seul moyen est d'augmenter la fréquence image. Par chance, la caméra OV7620 dispose d'un mode d'acquisition à 60 images/seconde : le QVGA à 60 images/seconde.

Dans ce mode-là, la caméra ne sort qu'un pixel sur deux en horizontal (ce qui divise la résolution horizontale par deux, mais ça ne pose pas de problème en pratique), et seulement les trames impaires (mais à une fréquence de 60Hz). Bingo, c'est exactement ce qu'on veut !