Au secours, je passe trop de temps à concevoir plutôt qu'à réaliser... !

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Salut les amis,

Inspiré par ce qu’a fait un membre de ZdS, j’ai décidé d’écrire un petit programme qui soit capable de dire si oui ou non une image qu’on lui présente est de type "X" (paysage avec ciel et terre, paysage avec ciel et océan, bref des images avec peu de couleurs), en apprenant par lui-même à distinguer ces types. Pour ce faire, j’utilise les chaînes de Markov (le membre dont je me suis inspiré a fait un générateur de musiques irlandaises, c’est encore plus stylé !).

L’idée générale est la suivante :

  1. Je défini des couleurs avec plus ou moins de précision (e.g. : "un pixel bleu est un pixel dont le RGB est compris entre X et Y").

  2. Je présente un tas d’images "paysage avec ciel et terre", sans mentionner le nom de cette catégorie. Mon programme ajuste les probabilités des liens entre états Markov en faisant une moyenne coef 1 (e.g. : "un pixel bleu est suivi par un pixel bleu dans 90% des cas", le 90% étant issu de la moyenne coef 1 effectuée sur cette même probabilité trouvée sur chaque image). Bon en soi une seule image (et conséquemment pas de moyenne) suffirait je pense, mais au cas où je préfère prendre un échantillon. (vous aurez compris que chaque état correspond à une couleur).

  3. A l’issue de cette phase d’entraînement, je passerai en phase de production. Je donnerai à mon programme une nouvelle image, et il devra me dire (1) si elle appartient à une catégorie et le cas échéant, à quelle catégorie (2). Pour ce faire (1 et 2), il calculera les probabilités Markov sur cette image (comme expliqué dans la deuxième puce, mais juste sur cette image) et calculera la distance entre chaque probabilité (rappel : toute proba se situe sur un lien entre états Markov) et la probabilité moyenne correspondante (calculée dans la deuxième puce). Si un état correspondant n’existe pas (i.e. : une couleur n’existe pas), et que cette couleur se trouve en grande proportion dans l’image (arbitrairement : 20% au moins de toutes les couleurs présentes dans l’image), alors le programme considérera que l’image n’appartient pas à cette catégorie (ce qui peut être faux, mais je rapelle que j’ai fait l’hypothèse, dans le tout premier paragraphe de ce message, que l’image doit compter peu de couleurs).

  4. La création de la chaîne de Markov et son exploitation se fera de manière distribuée dans un cluster de machines avec Apache Spark.

Bref. Vous savez où j’en suis rendu ? :p

A… la conception d’un… générateur de chaînes de Markov. Autant dire que j’ai plein de trucs à faire encore. Et c’est justement ça le problème. J’ai l’impression de perdre mon temps, ça fait environ 8H que je bosse sur un document de quelques lignes, parce que je tiens à être le plus précis possible dans les mots que je choisis, et parce que je me rends compte que j’ai parfois mal appréhendé le générateur, son fonctionnement (alors du coup j’efface quelques phrases que je réécris)…

Tenez, voici ce que j’ai écrit pour l’instant (rédigé en anglais, ce qui ne me prend pas du tout plus de temps que si je l’avais fait en français) : https://pastebin.com/KFX3AUpx

Mais en attendant, je n’ai toujours pas débuté mon vrai projet (le générateur de Markov étant un simple outil du projet, outil que je n’ai même pas commencé à écrire non plus…). Le pire c’est que je ne connais pas encore très bien Apache Spark (plus précisément le paradigme map/reduce), donc il va falloir que je fasse encore des recherches…

Bref, après tout ceci ma question va vous sembler courte et dérisoire. Mais… : vous avez une astuce pour avoir des résultats plus rapides ?

Édité par The-Aloha-Protocol

+4 -0

Ce qui s’énonce clairement se concoit clairement. Ce n’est pas inutile, bien au contraire ! Tout ce travail te facilitera à l’exécution. Je prends un exemple simple : quand tu regarde De Vinci, avant le premier coup de peinture, il y a des heures de croquis. Là, c’est pareil !

écolo-utopiste altermondialiste radicalisé sur Internet | La tero estas nur unu lando | Géographe de service | Cliquez 👍 pour dire merci

+0 -0

Les chaines de Markov, je pense avoir compris le principe, et je ne vois vraiment pas comment ça pourrait mener à un outil de classification d’images.

Par contre, on peut lire des trucs sur les champs aléatoires de Markov (Markov Random Field ou MRF). Ca, je ne connais pas, mais, effectivement, ça mène vers des outils de classification d’images.

+0 -0
Auteur du sujet

Ce qui s’énonce clairement se concoit clairement. Ce n’est pas inutile, bien au contraire ! Tout ce travail te facilitera à l’exécution. Je prends un exemple simple : quand tu regarde De Vinci, avant le premier coup de peinture, il y a des heures de croquis. Là, c’est pareil !

qwerty

C’est ce que je me dis aussi mais j’ai l’impression d’avoir exagéré au niveau de la phase de conceptiok en fait.

Les chaines de Markov, je pense avoir compris le principe, et je ne vois vraiment pas comment ça pourrait mener à un outil de classification d’images.

Par contre, on peut lire des trucs sur les champs aléatoires de Markov (Markov Random Field ou MRF). Ca, je ne connais pas, mais, effectivement, ça mène vers des outils de classification d’images.

elegance

Je pars juste du principe que si les statistiques d’une image correspondent plus ou moins (distance faible) à celles de l’échantillon, c’est que l’image appartient à cet échantillon.

  1. Statistiques : ici ce mot correspond au mot "probabilités" que j’ai utilisé dans l’OP. Ie. : la valeur sur chaque lien entre 2 états.

  2. Image : l’image dont on veut savoir à quelle catégorie elle appartient.

  3. Échantillon : synonyme de catégorie. Correspond à l’ensemble des images appartenant à une certaine catégorie et ayant permis d’ajuster la valeur des liens lors de la phase d’entraînement.

EXEMPLE.

  1. Suite à l’entraînement, le programme a compris qu’en moyenne, dans une image ciel-terre : un pixel bleu est suivi à 95 % d’un pixel bleu et qu’un pixel marron est suivi à 95 % d’un pixel marron.

  2. Durant la phase de production, je soumets l’image d’une clémentine. Le programme voit alors qu’il y a du orange en grande quantité : retourne faux.

  3. Je soumets ensuite l’image d’un animal marron qui nage. Il detecte alors qu’un pixel bleu est suivi à 60 % d’un pixel bleu et à 40 % d’un pixel marron. Paf ! Même pas besoin de regarder pour les pixels marrons (qui seraient détectés comme étant suivis par un pixel marron dans 80 % des cas) : retourne faux aussi.

  4. Je souhaite ensuite montrer une image ciel-terre : le programme retrouvera des statistiques proches de l’échantillon d’entraînement. Donc retourne vrai.

Édité par The-Aloha-Protocol

+0 -0

Bonjour,

À une époque, la mode a été d’employer des "mixture models" pour reconnaître des images (des lettres manuscrites essentiellement). C’est une théorie liée à celle des MRF (Théorème de Hammersley-Clifford). L’idée est qu’un point est conditionné par ces voisins, et les MRF proposent une manière simple d’introduire des notions de dépendances en statistiques (cf. travaux de Besag). Ensuite, il suffit d’employer le résultat de Kaiser & Cressie (1999) afin de construire un modèle multivarié à partir de cet MRF.

En pratique, on peut:

  • Diviser son dataset en plusieurs catégories;
  • Convertir les bleus en "1" et les autres couleurs en "0";
  • Sans doute, réduire le nombre de dimensions (PCA);
  • Définir un "modèle de mélange" adapté (Bernouilli / Gaussien);
  • Entraîner ces dits modèles sur chacune des catégories (Expectation-Maximization ou Grandient Log-Likelihood);

Il suffit alors de donner un nouvel échantillon à chacun des modèles et de prendre celui qui retourne la meilleure probabilité.

Édité par Gawaboumga

+0 -0

@The-Aloha-Protocol : tu sais que les techniques les plus efficaces pour faire ça, taguer automatiquement une image, ce n’est PAS via des chaines de Markov ? Il y a surement un peu de littérature sur le sujet mais tes résultats seront très loin probablement de l’état de l’art.

Enfin pour info, il y a plusieurs dataset de ce type sur le net, le plus connu étant probablement imageNet. Tu peux les utiliser pour tester et te comparer.

Édité par Kje

+1 -0

La méthode que tu envisages d’utiliser n’a rien à voir avec les chaines de Markov. Il y a un point commun, c’est que dans les 2 cas, tu pars d’une lecture/analyse des images connues. Ok. Mais n’importe quel outil, Markov ou pas Markov, va partir d’une analyse des images connues.

Je pense que quelque part, au fond de ton cerveau, il y a ton instinct, qui te dit "Cette méthode ne peut pas aboutir". Et c’est pour cela que tu restes bloqué à cette étape.

+0 -0

Ce qui me surprend c’est que tu rédiges un doc de design. Ça me semble contre-productif.

Entre l’idée initiale, le design initial que tu vas faire, le design auquel tu vas aboutir à la fin de ta pré-conception, le design tel que tu l’auras revu pendant l’implémentation pour prendre tel ou tel détail que tu n’avais pas pris en compte, et ton programme final, il n’est pas rare ni surprenant de voir des disparités énormes.

Il est donc relativement peu utile de figer ton design dès le départ : bosse avec un crayon à papier et fais des dessins (ou bien un marqueur sur un tableau blanc) plutôt que rédiger une spec, laisse toi la possibilité de gommer et redessiner facilement. Mettre des mots sur ton design et coucher celui-ci à l’écrit, c’est déjà figer ta pensée et arrêter de créer.

Édité par nohar

I was a llama before it was cool

+3 -0
Auteur du sujet

Bonjour,

Merci, je tiens compte de vos remarques, mais je vais quand même essayer de mettre en place ce système. Simplement parce que… je ne vois pas pourquoi ça donnerait de si mauvais résultats que ça, que d’utiliser la conjonction "proportion de pixels bleus et proportion de pixels marrons" ET "statistiques qu’un pixel bleu soit suivi par un pixel bleu, etc." pour discriminer une image "terre-ciel". Franchement ça marchera forcément, tant que les images sont simples.

La méthode que tu envisages d’utiliser n’a rien à voir avec les chaines de Markov. Il y a un point commun, c’est que dans les 2 cas, tu pars d’une lecture/analyse des images connues. Ok. Mais n’importe quel outil, Markov ou pas Markov, va partir d’une analyse des images connues.

Je pense que quelque part, au fond de ton cerveau, il y a ton instinct, qui te dit "Cette méthode ne peut pas aboutir". Et c’est pour cela que tu restes bloqué à cette étape.

elegance

Bein j’ai lu la tribune : https://zestedesavoir.com/billets/1822/generer-de-la-musique-grace-aux-chaines-de-markov/ et ma chaîne de Markov à moi est identique peu ou prou à celle mentionnée dans la rubrique.

Ce qui me surprend c’est que tu rédiges un doc de design. Ça me semble contre-productif.

Entre l’idée initiale, le design initial que tu vas faire, le design auquel tu vas aboutir à la fin de ta pré-conception, le design tel que tu l’auras revu pendant l’implémentation pour prendre tel ou tel détail que tu n’avais pas pris en compte, et ton programme final, il n’est pas rare ni surprenant de voir des disparités énormes.

Il est donc relativement peu utile de figer ton design dès le départ : bosse avec un crayon à papier et fais des dessins (ou bien un marqueur sur un tableau blanc) plutôt que rédiger une spec, laisse toi la possibilité de gommer et redessiner facilement. Mettre des mots sur ton design et coucher celui-ci à l’écrit, c’est déjà figer ta pensée et arrêter de créer.

nohar

Justement, durant cette phase de conception je m’efforce de penser à tout, de tout prévoir, pour ensuite n’avoir plsu qu’à coder. Mais effectivement ça prend beaucoup de temps, et en attendant je n’ai toujours pas même fini mon "générateur" de Markov (qui en fait est surtout un outil de formatage, donc rien de bien compliqué puisque c’est juste… de la concaténation de chaînes de caractères........)

+0 -0

Justement, durant cette phase de conception je m’efforce de penser à tout, de tout prévoir, pour ensuite n’avoir plsu qu’à coder.

Les techniques d’ingénierie logicielle modernes partent toutes du principe que c’est impossible de tout prévoir, en fait, et qu’il vaut mieux itérer et continuellement améliorer un code qui fonctionne plutôt que de ne jamais voir fonctionner ton design parfait.

Édité par nohar

I was a llama before it was cool

+0 -0

Je rejoint nohar, à part pour des trucs vraiment trivial, j’ai jamais vu un truc ou la conception papier du début était parfaite et complète.

Il est beaucoup plus efficace et sûrs de faire un design grossier et de partir dans son implémentation avant de raffiner le tout.


Dans ton sujet tu nous demandes ce que tu peux faire pour avoir un résultat plus rapidement, c’est ce qu’on te dis : fais un design plus simple et grossier et code. Itère entre les phases de réflexion/design et d’implémentation. C’est beaucoup plus efficace. Tu ne pourra jamais pensé à tout, d’autant plus si tu ne maîtrise pas toutes les technos.

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte