Cleaned the images prompts in the doc
This commit is contained in:
+64
-52
@@ -106,7 +106,7 @@ Mais comme je possède un abonnement premium ++ à la F1TV, j'ai accès pour cha
|
||||
|
||||
Qui ressemble à ça :
|
||||
|
||||
|
||||
|
||||
|
||||
Donc la seule façon que je vois de récupérer ces données est de les prendre directement sur ce feed.
|
||||
|
||||
@@ -143,7 +143,7 @@ Voire même si c'est possible :
|
||||
|
||||
Voici un exemple d'interface possible pour une page :
|
||||
|
||||
|
||||
|
||||
|
||||
### Cas d'utilisation
|
||||
|
||||
@@ -343,11 +343,11 @@ Pour rappel, Amazon héberge directement le site de la F1TV et possède les droi
|
||||
|
||||
On peut voir ce nom apparaître assez souvent quand on regarde un Grand Prix car comme ils ont la main-mise sur les données ils peuvent insèrer des bandeaux d'informations sur le flux public sur ce qu'il se passe voir même faire des prédictions (Bien qu'un peu bancales)
|
||||
|
||||
|
||||
|
||||
|
||||
Ce service s'appelle F1 Insights (Oui c'est un meilleur nom de projet que F1 Companion mais bon) et c'est, je pense, la raison pour laquelle on ne voit aucune API publique qui permette de correctement se renseigner en donées en direct pendant un Grand Prix. Ils ont du dégotter un juteux contrat pour s'occuper de toute l'infrastructure digitale de la F1 (du moins publique) en échange d'une exclusivité totale sur certaines choses comme les Data
|
||||
|
||||
|
||||
|
||||
|
||||
Evidemment je ne fais que conjecturer et ce que j'ai dit n'est pas à prendre au pied de la lettre mais c'est une explication possible je pense de pourquoi il est si difficile de trouver des données sur la F1 facilement en temps réel.
|
||||
|
||||
@@ -357,7 +357,7 @@ On pourrait croire que c'est impossible car cela n'existe pas comme je l'ai dit
|
||||
|
||||
La Data Channel est une page de la F1TV qui permet, pour chaque Grand Prix, de visualiser, sous la forme d'un flux vidéo, différentes informations capitales sur la course.
|
||||
|
||||
|
||||
|
||||
|
||||
Le problème, c'est que comme je viens de le dire, ces données ne sont pas accessibles comme un tableau HTML ou un flux RSS ou un tableau JSON. C'est un flux vidéo.
|
||||
Il faut savoir qu'entretenir une diffusion de flux vidéo en 1080P pendant deux heures accessible par des milliers d'abonnés est EXTRÊMENT cher surtout quand on le compare à simplement afficher les données dans un tableau. Ce qui veut dire que ce choix est délibéré et a un sens au niveau économique.
|
||||
@@ -411,7 +411,7 @@ Cependant Firefox de pas sa nature Open Source utilise "OpenH264" pour lire ces
|
||||
|
||||
Sauf que Firefox n'est pas aussi facilement émulé que chrome et cela réduit notre choix de librairies à ... Une seule... Qui est Selenium. (Il existe aussi Pupetteer C# mais j'ai rencontré énormément de soucis avec cette dernière dès que je voulais lancer une vidéo)
|
||||
|
||||
{: style="height:150px;width:150px"}
|
||||
{: style="height:150px;width:150px"}
|
||||
|
||||
Mais même si la documentation est plutôt maigre parfois, c'est une bonne librairie qui permet de très bien contrôler une instance de chrome ou de Firefox.
|
||||
|
||||
@@ -503,7 +503,7 @@ Voici un screenshot de la page DATA de la F1TV que le programme va recevoir :
|
||||
Si on regarde de loin on peut se dire que la structure est plutôt simple mais c'est loin d'être le cas.
|
||||
On peut y voir au moins 4 zones contenant de l'information dans un format différent.
|
||||
|
||||
|
||||
|
||||
|
||||
Dans l'exemple ci dessus on peut voir 3 zones mais on aurait également pu comprendre la zone de position des pilotes autour du circuit pour faire 4.
|
||||
|
||||
@@ -544,33 +544,33 @@ Dernières choses pour comprendre le diagramme:
|
||||
|
||||
Voila donc un petit diagramme qui montre le découpage du programme :
|
||||
|
||||
|
||||
|
||||
|
||||
Pour visualiser encore un peu mieux comment ce découpage prend forme voici ce que chaque zone et Window contient.
|
||||
|
||||
Main Zone :
|
||||
|
||||
|
||||
|
||||
|
||||
Driver Zone :
|
||||
|
||||
|
||||
|
||||
|
||||
Driver Position Window :
|
||||
|
||||
|
||||
|
||||
|
||||
Driver name Window :
|
||||
|
||||
|
||||
|
||||
|
||||
Driver LapTime Window :
|
||||
|
||||
|
||||
|
||||
|
||||
Driver Tyre Window :
|
||||
|
||||
|
||||
|
||||
|
||||
Il existe d'autres types de Window mais ce sont les principaux.
|
||||
|
||||
@@ -600,25 +600,25 @@ Exemple :
|
||||
|
||||
Prenons le chiffre 9. Dans l'image il peut être représenté de cette manière :
|
||||
|
||||
|
||||
|
||||
|
||||
On peut voir qu'il est flou, pour nous cela ne pose pas de problème et je pense que à peu près nimporte qui peut dire que c'est un 9.
|
||||
|
||||
Cependant comme les contours sont flous et même si on essaie de retirer le background :
|
||||
|
||||
|
||||
|
||||
|
||||
On voit que le 9 n'est pas clairement définit. En effet on pourrait le comprendre comme :
|
||||
|
||||
|
||||
|
||||
|
||||
Ou comme :
|
||||
|
||||
|
||||
|
||||
|
||||
Voire même simplement comme :
|
||||
|
||||
|
||||
|
||||
|
||||
Et on se rend bien compte que les performances de detection ne sont pas les mêmes dans ces trois cas.
|
||||
|
||||
@@ -638,7 +638,7 @@ Cette reconnaissance concerne donc des lettres qui font des mots ou des noms.
|
||||
|
||||
Voici un exemple de la WINDOW nom de pilote en entrée :
|
||||
|
||||
|
||||
|
||||
|
||||
Ce texte peut paraitre bon, cependant quand on le lance dans Tesseract, il ne va pas toujours donner un résultat parfait. Il faut aussi savoir qu'il y a des noms pas mal plus pénibles que Tesseract a plus de mal à reconnaitres, soit à cause des lettres utilisées, soit car le nom est un nom d'une autre région et qui ne veut rien dire en anglais ce qui empêche l'utilisation de dictionnaire (Ex : Tsunoda est un nom japonais et parfois il est difficile pour Tesseract de le reconnaitre car si une lettre pose problême il ne peut pas trouver de contexte qui puisse l'aider).
|
||||
|
||||
@@ -650,15 +650,15 @@ Donc pour le rendre plus facilement lisible et augmenter les chances que toutes
|
||||
|
||||
2 : Je fais un *Treshhold* de 165 car avec moins le texte parfois prend trop du background et avec plus les lettres sont trop fines.
|
||||
|
||||
|
||||
|
||||
|
||||
3 : Je fais un *Resize* de l'image pour avoir une meilleure résolution et permettre une meilleure détection. J'augmente la hauteur et la largeur par un facteur 2. J'ai trouvé cette valeur suffisante et aller plus haut consomme beaucoup de ressources.
|
||||
|
||||
|
||||
|
||||
|
||||
4: Je fais une très rapide *Dilatation* du texte pour retirer le flou amené par la methode de Resize. Je n'utilise qu'une valeur de 1 car je ne veux pas trop changer comment le texte est modelé je veux juste retirer le flou.
|
||||
|
||||
|
||||
|
||||
|
||||
*Explication des methodes précises plus bas*
|
||||
|
||||
@@ -699,11 +699,11 @@ Cependant, tous ces temps possèdent le même type de post-traitement avant d'ê
|
||||
|
||||
Voici un exemple de temps au tour avant toute transformation :
|
||||
|
||||
|
||||
|
||||
|
||||
On peut avoir l'impression que ce texte est tout à fait lisible et facile à décoder surtout quand on le voit de loin comme ca. Cependant, il faut imaginer que ces chiffres font 13 pixels de haut en comptant le flou et comme expliqué plus haut ce flou dans ces echelles est terrible.
|
||||
|
||||
|
||||
|
||||
|
||||
Si on donne cette image à Tesseract, les '3' deviennent des '9', des '9' deviennent des '8', des '2' deviennent eux aussi des '9', le tout parfois inversement et de manière complêtement imprévisible. Ca n'est simplement pas utilisable.
|
||||
|
||||
@@ -713,19 +713,19 @@ Voici donc les étapes de post-traitement que j'ai mis en place pour leur détec
|
||||
|
||||
1: J'applique un *Treshold* de 185 pour enlever les ambiguités d'alisaising et avoir une image en noir et blanc claire. La valeur de 185 est assez élevée car le but est de vraiment garder uniquement les contours. Comme les chiffres se ressemlent beaucoup plu que les lettres, il faut tenter le plus possible de conserver leur formes spécifiques. Je me suis rendu compte que cette valeur était une de celles qui marchent le mieux.
|
||||
|
||||
|
||||
|
||||
|
||||
2: J'applique un *Resize* de 2 pour augmenter la résolution des chiffres et permettre une meilleure détection. Le but est d'avoir plus de pixels et donc de permettre à Tesseract de mieux utiliser ses matrices de convolution.
|
||||
|
||||
|
||||
|
||||
|
||||
3: Comme le *Resize* amène du flou, j'utilise une methode de Dilatation* qui me permet de retirer ce flou et de remplir un peu plus certaines parties qui ont été un peu laissée par le *Resize*;
|
||||
3: Comme le *Resize* amène du flou, j'utilise une methode de *Dilatation* qui me permet de retirer ce flou et de remplir un peu plus certaines parties qui ont été un peu laissée par le *Resize*;
|
||||
|
||||
|
||||
|
||||
|
||||
4: Contrairement aux mots plus haut, la rondeur ajoutée par la dilatation n'est pas vraiment désirée. En effet, elle peut rendre confuse certains chiffres et empêcher Tesseract de bien trouver le chiffre. Alors j'applique une *Erosion* qui me permet de contrecarrer en partie les rondeurs ajoutées par la dilatation et retrouver des chiffres bien formées. Pour l'*Erosion* et la *Dilatation* j'ai utilisé une valeur de 1 car je ne voulais pas trop changer les chiffres.
|
||||
|
||||
|
||||
|
||||
|
||||
*Explication des methodes précises plus bas*
|
||||
|
||||
@@ -764,7 +764,7 @@ Depuis 2019 en Formule 1 nous avons 5 grandes familles de pneus :
|
||||
- Les pneus intermédiaires
|
||||
- Les pneus pluie
|
||||
|
||||
|
||||
|
||||
|
||||
Les trois premiers pneus sont des pneus faits pour piste sèche, le pneu intermédiaire pour piste humide et le neu pluie pour la pluie.
|
||||
|
||||
@@ -774,19 +774,19 @@ Chaque pneu a une couleur donnée qui permet de les différencier.
|
||||
|
||||
Voici un exemple de ce à quoi une WINDOW de pneus peut ressembler :
|
||||
|
||||
|
||||
|
||||
|
||||
Mais cette zone peut aussi ressembler à ca :
|
||||
|
||||
|
||||
|
||||
|
||||
Mais aussi à ca :
|
||||
|
||||
|
||||
|
||||
|
||||
Voire même ca :
|
||||
|
||||
|
||||
|
||||
|
||||
Je pense que vous pouvez tout de suite comprendre la difficulté que représente la tâche de récupèration de données à partir de cette image.
|
||||
|
||||
@@ -809,11 +809,11 @@ Ensuite après avoir trouvé le premier obstacle, je récupère une zone qui doi
|
||||
|
||||
Voici un exemple avec cette image en entrée :
|
||||
|
||||
|
||||
|
||||
|
||||
Elle est automatiquement coupée de cette facon :
|
||||
|
||||
|
||||
|
||||
|
||||
Cela me permet d'isoler uniquement ce qui m'intéresse ce qui est très pratique pour Tesseract et pour la detection de couleur.
|
||||
|
||||
@@ -827,31 +827,31 @@ Il y a cinq couleurs des pneus possibles :
|
||||
|
||||
"#ff0000" pneu tendre/soft
|
||||
|
||||
|
||||
|
||||
|
||||
"#f5bf00" pneu medium
|
||||
|
||||
|
||||
|
||||
|
||||
"#a4a5a8" pneu dur/hard
|
||||
|
||||
|
||||
|
||||
|
||||
"#00a42e" pneu inter
|
||||
|
||||
|
||||
|
||||
|
||||
"#2760a6" pneu pluie/wet
|
||||
|
||||
|
||||
|
||||
|
||||
Ce qui est pratique c'est que même dans les cas ou il n'y a pas beaucoup de couleur comme celui la :
|
||||
|
||||
|
||||
|
||||
|
||||
On arrive à une couleur moyenne de :
|
||||
|
||||
|
||||
|
||||
|
||||
Et il est donc assez facile de determiner le type de pneu en question.
|
||||
|
||||
@@ -867,11 +867,11 @@ Il faut donc retirer le background et ensuite la couleur. Sauf que comme le chif
|
||||
|
||||
Pour se faire, j'ai tiré des traits depuis les bords de l'image jusqu'à ce qu'ils rencontrent le rond. Ensuite je retire tous les pixels entre le rond et les bords de l'image ce qui nous donne ceci :
|
||||
|
||||
|
||||
|
||||
|
||||
Ensuite on peu retirer les pixels qui ont une valeur dans un channel RGB plus haute qu'un certain seuil :
|
||||
|
||||
|
||||
|
||||
|
||||
Et la on a ce que l'on veut !
|
||||
|
||||
@@ -879,11 +879,11 @@ A partir de la c'est les filtres que l'on connait qui sont utilisés pour en fai
|
||||
|
||||
1 : On effectue un *Resize* de facteur 4 (oui c'est beaucoup mais en même temps le chiffre est vraiment petit à la base) qui permet d'avoir une image d'une bien meilleure résolution.
|
||||
|
||||
|
||||
|
||||
|
||||
2: On fait une *Dilatation* de facteur 1 pour retirer tout le flou de l'image pour aider Tesseract
|
||||
|
||||
|
||||
|
||||
|
||||
Et on a un chiffre qui est utilisable par Tesseract !
|
||||
|
||||
@@ -933,19 +933,19 @@ Cette methode sert à augmenter la résolution d'une image pour améliorer la pr
|
||||
|
||||
Il ne faut pas confondre cette methode d'augmentation de la taille avec une simple interpolation. En effet une augmentation de taille interpolée ne vas pas vraiment changer la résolution, l'image sera toujours aussi pixelisée, seulement, les pixels seront composées de plus de pixels comme dans l'exemple ci dessous :
|
||||
|
||||
|
||||
|
||||
|
||||
Dans mon projet j'utilise de l'interpolation bicubique qui va créer de l'information pour tenter de combler le vide et produire une image réellement plus grande et avec plus de details mais en ajoutant du flou.
|
||||
|
||||
|
||||
|
||||
|
||||
Le but est d'aller chercher dans les pixels alentours les couleurs qui sont déja présente et de jouer avec des poids pour tenter de faire une prédiction de ce que ce pixel aurait été si l'image avait plus de detail.
|
||||
|
||||
Voici un exemple assez parlant :
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
On pourrait croire que c'est inutile mais dans le contexte de Tesseract ajouter des détails pour tenter de simuler une meilleure résolution même en créant du flou est intéressant pour mieux remplir la matrice de convolution.
|
||||
|
||||
@@ -991,6 +991,18 @@ Il y aussi d'autre methodes comme un filtre Gaussien ou *Highlight countour* que
|
||||
|
||||
[A remplir au fur et à mesure dans la seconde moitié du travail de diplôme]
|
||||
|
||||
## Optimisation du programme
|
||||
|
||||
----
|
||||
|
||||
[A remplir à la fin du projet pour parler des différentes methodes d'optimisation]
|
||||
|
||||
## Ethique du projet
|
||||
|
||||
----
|
||||
|
||||
[A remplir à la fin du projet pour parler des questions ethiques du projet (Ex: Utilisation potentiellement abusive de la F1Tv ou L'histoire des cookies)]
|
||||
|
||||
## Améliorations futures
|
||||
|
||||
----
|
||||
|
||||
Reference in New Issue
Block a user