Bonjour.
Il faut que je code un algo de recherche d'image performant, et j'ai bien une idée de comment m'y prendre, mais je préfère demander si vous n'avez pas une meilleur solution, avant de me lancer :p (ou si vous trouvez que mon algo est pourris, afin de m'éviter de perdre du temps dessus)

Mon algo actuellement, pas encore testé :
Création de la base de donnée
-on rétrécis l'image a une taille fixée, par exemple 64*64
-on crée quelques images a partir de celle ci, avec la perte d'un bit de précision a chaque fois.
Par exemple pour une couleur 24bits 0x29F283, soit 10100111 11001010 000011
On auras, pour par exemple 4 images :
10100111 11001010 000011
10100110 11001010 000010
10100100 11001000 000000
10100000 11001000 000000
-on hache les images obtenus, et on les ajoutes a la base de données

Recherche de l'image
Même méthode pour transformer l'image.
Ensuite on compare le hachage obtenue avec ceux de la base de données.
Et la fonction retourne s'il on a trouvé l'image et la précision de la correspondance.

Qu'en pensez vous ?

je suppose que ça ne peut fonctionner que si les deux images sont exactes au pixel près, non ?

enfin, je suppose que t'aura du mal à trouver l'image correspondante si la balance de couleurs est différente, ou si elle à été retouchée.

Ouaip c'est le but, deux images exactement identiques.
La marge d'erreur en fait c'est au cas ou une image aurais subit quelques pertes après une compression jpeg, et encore, suis pas sur que ça fonctionne très bien.
Je devrais peut être séparer la luminance de la chrominance, et ne faire les tests que sur la luminance, au moins comme tu dit si y a eu une petite retouche ça devrais passer.
Bref c'est une ébauche d'algorithme, je suis sur que d'autres idées me viendrons pour améliorer le truc de base :b

bin pour des images aux pixels pret:

tu hache directement l'image.
tu fait un tableau code de hachache <-> chemin image

si tu veux que ça marche pour des images pas exactement pareil.
Tu fait un algorithme qui détruit peut à peut l'image, la simplifie ( genre passage en niveau de gris avec 8 niveau)
puis pareil hachache et tableau.


Bon après, les optimisations peuvent être faite sur le tableau.

Ok, bah c'est l'algo que je proposais donc x)

Sinon tu connais des algos pour images semi différentes ? Genre comme tineye.
(a titre instructif seulement :p)

Moi j'en connais aucun.
Mais je peux en imaginer un.

Pour deux images de même dimension

Tu définis une distance sur l’ensemble des images ( comme en math)

je te propose
D2(imgA,imgB) = Somme(pixel(x,y)) de ( imga.(x,y)-imgb(x,y) )²
D1(imgA,imgB) = Somme(pixel(x,y)) de abs( imga.(x,y)-imgb(x,y) )
Doo(imgA,imgB) = sup(pixel(x,y)) de abs ( imga.(x,y)-imgb(x,y) )

Deux images sont égales si elle sont peux éloigné au sens d'une de ces norme.

Ceci devrait marche bien. ( petite préférence pour la distance D2 )

Ensuite tu peux lancer un flou sur les images avant de mesurer la distance de l'un à l'autre, sa peux compenser un peux mieux un décalage entre deux images.

Moi, je passerais en YUV ou en HSL (HSV fera l'affaire) et je réduirait en 64*64, mais en moyennant les pixels.
Ensuite, je ferais :
- un hash sur les U et V (ou H et S, bref, l'info de la couleur),
- un hash sur le Y (la chroma / Luminosité),
- un hash sur un passe haut 4 bits sur le Y (V / L, la chroma).

Je sais pas si un hash ça fait bien ce que tu veux ... pour chercher la 'distance' d'une image à l'autre, je préconiserais plutôt de calculer la somme, la moyenne, la médiane et l'écart-type, et de tester tout ça.
Et je les testerais avec le passe-haut, c'est là où tu à ta dynamique d'image.


Après, c'est ce que je ferais, c'est pas dit que ça marcherais mieux ...

Pourquoi HSL ? YUV je comprend, mais pour HSL les opérations sont complexes, puis je vois pas non plus l'intérêt, mis a part d'avoir la luminance.
(car l'œil est plus réceptif a la luminance qu'a la chrominance, pour ceux qui suivent pas :b)

Sinon y a YCbCr qui demande quasiment pas d'opérations (moins que YUV), et il donneras de même la luminance séparé de la chrominance :p
C'est d'ailleurs utilisé dans le format jpeg, donc pour comparer deux images de ce type, a mon avis c'est le mieux. (puis faut prendre en compte les sous échantillonnages)

En tout cas, on a tous a peu près la même idée d'algorithme, ça veux donc dire que j'étais pas parti sur n'importe quoi :p
J'vais pouvoir commencer a coder, je vous tient au jus

Juste pour dire que l'algo marche du tonnerre :p
Et finalement, quand on rétrécis l'image en 64*64, on perd tellement de détails que même les artefacts jpeg ne sont pas détectés, et on a (d'après mes tests actuels) même pas besoin d'utiliser plusieurs hashs.
De plus créer la base de données pour ~1100 images prend a peu près 20sec, puis une fois fait, chercher une image met quelques fractions de secondes :b

Epic win :p

Joli, t'as plus qu'à ajouter des systèmes d'analyse de formes/couleurs /techniques pour retrouver l'auteur d'une œuvre !

Tu as deux semaines

Héhé, si ça faisais parti du projet j'aurais ptêtre essayé

Cool, merci, je vois que tu bosses dur