End of the day push

docs/index.md

@@ -1490,10 +1490,53 @@ Voici un exemple de ce dont cette méthode est capable :
 
 ![Artefacts de la detection de bords de Sobel](./Images/Screens/SobelArtefacts.png)
 
-### Interprétation des données
+Apparemment l'OCR aime assez bien cette methode et elle permet de beaucoup moins souvent oublier les '.' ou ':'
+
+### Traitement des données
+
+C'est bien gentil de recevoir des résultats de l'OCR, cependant on ne peut pas souvent les utiliser comme tels. En effet les resultats ne sont pas très constants et demandent d'être verifiés pour savoir si ils doivent être pris en compte.
+
+Le post traitement de ces données dépend complêtement du contexte et donc il est différent pour chque type de window.
+
+Voici un florilège des différents types de traitements :
+
+- Traitement du nom de pilote
+
+Rien de plus que ce qui est déja détaillé dans la partie OCR
+
+- Traitement des pneus
+
+Pareil
+
+- Traitement des temps
+
+La par contre c'est intéressant. Dans un monde parfait je pourrais simplement prendre les résultats de l'OCR et les traiter directement. Mais comme nous vivons dans un monde ou la souffrance et la douleur sont les seules choses autorisées on ne peut pas.
+
+Le problème vient du fait que les temps que l'on peut trouver sur la F1TV sont encodés avec des '.' et des ':' qui determinent les limites entre les chiffres qui désignent les minutes, les secondes et les milisecondes. Et le soucis avec ces séparateurs c'est qu'ils aiment bien mettre le chaos dans la reconnaissance. Quand ils ne sont pas compris comme des autres chiffres ils sont parfois simplement oubliés ou pris en double c'est un enfer.
+
+Il faut donc trouver un moyen de detecter quand cela arrive. Et je n'ai pas trouvé de meilleur moyen que de faire du cas par cas.
+
+Cela peut paraître simple quand on parle par exemple des secteurs. On sasit que on attend deux chiffres avant un '.' et trois chiffres après. Il est donc facile de voir que si je trouve six chiffres et pas de séparation le troisième est le séparateur mal compris.
+
+Mais l'exemple qui détruit vraiment tout c'est les écarts avec le leader. Autant un temps au tour c'est toujours x:xx.xxx et un temps de secteur c'est xx.xxx. Mais un écart avec le leader ca peut être 0.345 comme 1:12.345. Ce qui fait que quand je 121345 est-ce que c'est 12.345 ou 1:21.345...?
+
+Souvent on peut quand même déduire mais cela demande de prévoir presque tous les cas limites ce qui est assez pénible.
+
+On pourrait se dire qu'il suffit de voir si la valeur est trop en dehors des normes. Le soucis c'est que il n'est pas impossible que un temps au tour ou un écart prenne d'un coup une grosse différence. Cela arrive même assez souvent quand des pilotes sortent de la piste.
+
+!["Exemple temps au tour"](./Images/Screens/ExempleLapTimeBefore.png)
+!["Exemple temps secteur"](./Images/Screens/VanishRaw.png)
+
+Pour ce qui est du DRS et de la position des pilotes, il n'y a pas vraiment de traitement supplémentaire. Non pas car la detection est parfaite, mais par ce que la detection ne peut pas rater de 200 facons. Le DRS ne peut retourner que TRUE ou FALSE et la position du pilote est entre 1 et 20 compris. Le peu de nuance fait que ce sont des cas de figures qui ne demandent pas un traitement particulier au delà de l'OCR
 
 ### Stockage des données
 
+Dans ce projet le but n'est pas simplement de trouver les données et les afficher. L'intérêt de les récupèrer est de pouvoir les comparer à d'autres données précédentes.
+
+Le vrai soucis de la F1TV c'est justement que l'on ne peut pas facilement voir les évolutions. On ne peut voir que des "photos" de la situation actuelle de la course.
+
+Il faut donc garder en mémoire les différentes choses qui se sont passées. Techniquement on pourrait stocker ces données dans de bêtes listes C#.
+
 ### Affichage des données
 
 ### Prédictions