Optimisation

Optimisation

by Ludovic Pujol -
Number of replies: 1

Bonsoir,

En cherchant comment je pouvais optimiser, j'ai d'abord cherché ce qui prenait du temps dans mon programme (avec le fichier tree.txt avec 2 filtrages).

Le demo est réalisé en 1.5 seconde et le miens en 2.5 secondes

Je me suis rendu compte de trois choses :

La première est que mon filtrage et mon seuillage sont presque instantanés (0.1 seconde pour les deux).

La seconde, est que l'écriture du nouveau fichier .ppm prend 1 seconde.

La dernière est que la lecture seule de tous les pixels (sans vérifier si il y a une erreur, style un valeur négative), prend 1.3 seconde.

C'est à dire que rien que la lecture et la réécriture des pixels dans le nouveau fichier prend déjà plus de temps que le programme entier demo (2+ secondes contre 1.5 seconde). Alors à moins que le prgm demo ne lise qu'une valeur sur deux et n'en écrive qu'une sur deux aussi, je voulais connaitre la magie qui se cache derrière.

Merci pour votre aide,

Pujol Ludovic

In reply to Ludovic Pujol

Re: Optimisation

by Ronan Boulic -

il n'y a rien de spécial dans le programme de démo ; seulement un peu de bon sens.

Du coté lecture, la donnée indique de faire le filtrage sur l'image codée. Il n'y a donc pas besoin de mémoriser l'image RGB. Chaque lecture d'un pixel permet de calculer son intensité et de prendre immédiatement la décision du code à stocker pour ce pixel.

Par ailleurs, il est important de réserver l'espace de l'image codée, par exemple avec un vector, dès qu'on connait le nb de lignes et de colonne. Ensuite on remplit cet espace avec une syntaxe [i][j].

C'est beaucoup plus lent de faire des appels à push_back() pour ajouter les valeurs au fur et à mesure à un vector.

Du coté "affichage dans le terminal" nous affichons directement les valeurs RGB à partir du code obtenu par filtrage. C'est inutile de construire une image RGB qui serait ensuite affichée dans le terminal.