Détecter une sous-image avec transparence (sprite) dans une image

[zedrummer]

Bonjour

J'ai développé un système d'affichage de score de flipper virtuel sur DMD (affichage par matrice de LED commandé par un micro contrôleur ESP32) https://www.pincabpassion.net/t14798...ation-du-zedmd, pour avoir un affichage fidèle à un flipper réel.

Maintenant, je programme une amélioration du système de colorisation de cet affichage, car la plupart est en 4 voire 16 couleurs, enfin en dégradé sur 4 ou 16 tons d'une espèce d'orange, et on les passe en 64 voire 256 couleurs.
L'image se présente sous la forme d'un tableau de 128x32 octets (voire, rarement, de 192x64 octets ou 256x64 octets) de valeurs allant donc de 0 à 3 ou de 0 à 16 selon le nombre de tons pour produire ceci:



Maintenant, j'aimerais en temps réel détecter la présence d'un "sprite", c'est-à-dire une sous-image NON RECTANGULAIRE, par exemple défini par 2 rectangles de même taille: un masque de 0 et de 1 qui définit les pixels du rectangle qui font partie du sprite, et l'image de ce sprite avec le même dégradé sur 4 ou 16 couleurs que sur l'image complète. Par exemple, le personnage avec le cadeau ou le chien dans l'image ci-dessus. Sachant qu'il faudra ajouter du clipping, car le sprite peut-être à moitié affiché en sortant de l'image.
Est-ce qu'il y a un algorithme particulièrement efficace pour ce genre de détection en temps réel? Ou faut-il forcément passer par le "je commence ma comparaison en haut à gauche, puis je décale d'un pixel vers la droite et quand j'arrive en fin de ligne je passe à la ligne suivante"?

Merci
David
-----

[pm42]

Tu as des algos comme ça :

https://en.wikipedia.org/wiki/Scale-...ture_transform

Et des librairies spécialisées comme https://opencv.org et https://www.vlfeat.org qui peuvent te donner des idées mais dans tous les cas, ce sera relativement lent et CPU-intensif.
Est tu sur d'avoir besoin de détecter et ne pas pouvoir faire autrement ?

[Paraboloide_Hyperbolique]

Bonjour,

Est tu sur d'avoir besoin de détecter et ne pas pouvoir faire autrement ?

En effet, c'est la première question à se poser. D'habitude, un sprite est par définition une image séparée ajoutée sur un décors de fond. En général, on sait où l'ajout se fait en terme de pixels sur le décors.


Sinon, si le fond de l'image (la clôture) ne change pas, une simple différence de l'image contenant le sprite avec l'image de fond devrait faire l'affaire.

[zedrummer]

Merci à vous 2 de votre temps.
Je me suis déjà posé cette question, s'il n'y avait pas besoin de faire de détection, mais de composer l'image en couleur directement, je me serais facilité la vie.
Pour vous expliquer le principe de l'émulation: on utilise la rom originale qui est un programme qui compose directement l'affichage du score, on lui envoie juste des stimuli de type "la bille est passée dans cette rampe", "la bille a tapé dans telle cible", etc... et la ROM utilise son code pour générer une image des scores. On ne peut donc pas intervenir au moment de l'élaboration de l'image ou alors ça voudrait dire faire énormément de programmation pour chaque table de flipper qui existe.
Du coup, on est obligés d'identifier cette image complète avant de la coloriser.
Je vais regarder le code que vous m'avez fourni, merci beaucoup.

Sinon, si le fond de l'image (la clôture) ne change pas, une simple différence de l'image contenant le sprite avec l'image de fond devrait faire l'affaire.

Pourrais-tu expliciter ça plus précisément, ça m'intéresse?

[A voir en vidéo sur Futura]

[pm42]

Ok. Là comme ça, j'essaierais de détecter les sprite en reconnaissant juste certains de leurs motifs discriminants.
Dans l'exemple que tu donnes, l'oeil du chien par exemple.
Si tu as un motif discriminant pas trop gros pour chaque sprite et idéalement sur les mêmes lignes, tu parcours les dites lignes une seule fois et tu regardes pour chaque sprite. Ca limite la quantité de données à lire/comparer.

Après, détecter un sprite partiel qui est clippé à gauche ou à droite reste un poil plus compliqué.

[zedrummer]

Merci bien

[pm42]

Merci bien

De rien. Ce que je veux dire, c'est que la plupart des algos sont faits pour détecter des images qui peuvent varier en taille, orientation, couleur, etc.
C'est ce qui rend ce genre de reconnaissance compliquée et la raison pour laquelle il a fallu attendre le deep-learning pour être réellement très performant.

Mais toi, tu as des images parfaitement connues dont rien ne varie. Tu dois donc pouvoir utiliser ça.

[umfred]

Je ne comprends pas trop pourquoi vouloir détecter, vu que c'est toi qui génères l'image, donc toi qui génères les sprites et leur mouvement sur le fond

[zedrummer]

Tu n'as pas lu ma réponse sur l'émulation plus haut je pense.

[umfred]

Tu n'as pas lu ma réponse sur l'émulation plus haut je pense.

oups en effet, lu trop vite

[zedrummer]

Pas de souci

[Paraboloide_Hyperbolique]

Pourrais-tu expliciter ça plus précisément, ça m'intéresse?

Cela consiste à faire une différence des valeurs des pixels entre l'image à tester et une image de référence sans sprite. Là où les différences entre les pixels sont non-nulles correspondent au sprite.

Cependant, la réponse de pm42 me semble plus pertinente. Elle est un poil plus compliquée mais potentiellement bien plus rapide (si l'on code bien les choses) que la méthode que je propose.

[zedrummer]

Merci à tous, je vais tester ça

[umfred]

une autre idée qui me vient (je ne sais pas si elle viable): faire un peu de rétroenginering sur que l'eeprom envoie en image, voir si il n'y a pas 2 ou plusieurs phases pour composer l'image, genre une phase pour le fond, une phase pour le sprite1, une phase pour le sprite 2, une phase pour le score.

[zedrummer]

Le problème reste le même, ça ferait un boulot énorme s'il fallait faire ça pour toutes les tables.

[umfred]

Dans tous les cas ça sera un énorme boulot, vu que la coloration que tu veux faire sera différente pour chaque sprite.

Dans le principe, il me semblerait "plus simple" d'identifier la position des sprites dans la rom et de les "coloriser" directement dans la rom (si ça ne fait pas modifier la dimension du sprite en mémoire). Je suis tombé sur ça Pinball Explorer qui permettrait de customiser une rom https://pinside.com/pinball/forum/to...8#post-2722290

[zedrummer]

Merci, je vais jeter un oeil,