Algorithme de block matching -- Full search

Bonjour,

Je développe actuellement un algorithme de block matching sur GPU. J'implémente l'algorithme de full search et jusqu'à maintenant, je suivais les indications d'un article de recherche que j'avais pris comme référence et avais dimensionné mes tableaux pour pouvoir "accueillir" les données de tous les blocs candidats pour un bloc de taille 4*4 : pour une fenêtre de recherche de 16, cela me donnait un total de (2*16+1)² blocs candidats.
Mais dans un autre article que je viens de trouver, pour une fenêtre de recherche de 16, ils calculent 1024 positions.
Du coup, je suis perplexe :? Quelqu'un peut-il m'éclairer sur ce nombre de candidats ?

merci d'avance ;)

On peut avoir le nom (ou un lien) sur les papiers de recherche dont tu parles ?

Effectivement, ça pourrait être utile :oops:
Voilà pour le premier : http://vc.cs.nthu.edu.tw/home/paper/...0on%20CUDA.pdf (les 1024 SADs).
En ce qui concerne la seconde référence, il ne s'agit pas d'un papier à proprement parler mais d'un code de référence développé par un groupe de recherche de l'Illinois cité à de nombreuses reprises dans plusieurs papiers (surtout pour des benchmark) et dont le code source peut être disponible à cette adresse : http://impact.crhc.illinois.edu/parboil.php.
Il est aussi plus facilement visible sur le projet Ocelot, sur google code, à cette adresse précise : http://code.google.com/p/gpuocelot/s...ests/sad/sad.h.

Voici un extrait de SAD.h :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

/* Search offsets within 16 pixels of (0,0) */ #define SEARCH_RANGE 16   /* The total search area is 33 pixels square */ #define SEARCH_DIMENSION (2*SEARCH_RANGE+1)   /* The total number of search positions is 33^2 */ #define MAX_POS 1089   /* This is padded to a multiple of 8 when allocating memory */ #define MAX_POS_PADDED 1096

---

Ils déterminent donc que le nombre total de positions de recherche est de 1089 (et ils "pad" cette valeur pour pouvoir dans le code effectuer des accès mémoires coalescents depuis la mémoire du GPU). Alors que dans le premier document, au paragraphe 3.2, ils disent "the 32*32 search range leads to 1024 candidate positions".

Ok.

Alors visiblement, il y a ceux qui travaillent sur un carré centré sur un pixel => un nombre impair de lignes/colonnes => (2*16+1)² = 1089
Et puis il y a ceux qui travaillent sur un carré centré sur un interpixel => un nombre pair de lignes/colonnes => (2*16)² = 1024

Un peu le principe des piquets et des intervalles. :D