Wiki du LAMA (UMR 5127) - Contributions [fr]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-17T19:34:19Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque [[https://numpy.org/ Numpy]] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page, je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet ([[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images ici]]) pour bien comprendre le fonctionnement du programme et son but.

== Quelles étaient les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bons rendus. Néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devenait problématique si on voulait faire un transfert de couleurs entre 2 images avec un grand nombre de pixels. 

=== Quelques statistiques sur les temps de calcul ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

''A noter que ces tests ont été réalisés avec un nombre de répétition de 20 dans le programme.'' 
Ce nombre est une valeur de référence suffisante pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur. 
On remarque par ces chiffres que lorsque l'on transfert des images de petite résolution, le temps de transfert reste tout à fait correct. Néanmoins dès que l'on va vouloir prendre des images de résolution plus importante (HD ou même 4K), le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables de faire un milliard de calculs par seconde mais <code>Python</code> est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau).

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme, nous utilisons de nombreux tableaux afin de stocker toutes les variables dont nous avons besoin, et la bibliothèque <code>Numpy</code> possède des tableaux bien plus compacts. De plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire une boucle pour appliquer ces calculs sur chaque variable. 
De ce fait, on gagne énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très complète et si vous voulez plus d'informations je vous conseille de vous rendre sur la page officielle [[https://numpy.org/ Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
Ces tests ont eux aussi été réalisés avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de <code>Numpy</code> permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition pour avoir un meilleur résultat en gardant un temps d’exécution correct.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image ''' / ''' Nombres de tours dans le programme ->''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

Plus on augmente la taille de l'image et le nombre de tour, plus le temps d'exécution devient important. En effet, les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de haute qualité, de regrouper plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrait d'avoir moins de pixels à traiter sans pour autant avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nu.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet, l'espace RVB est très bien mais il correspond aux écrans et non à l’œil humain, tandis que l'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L*a*b CIE 1976]] a pour but de mieux approximer la réalité.
Cet espace, autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 

=== Calcul nécessaire ===
==== Passage RVB -> Lab ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtient avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composante de l'espace CIELAB et on peut ensuite calculer l'écart de couleur de la même manière que dans l'espace RVB. 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage Lab -> RVB ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permettent d'avoir dans certains cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs. 
Néanmoins, on peut voir qu'on à plus de mal a distinguer le relief sur la seconde image.

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy
{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme dans l'espace RGB ''' ||~6sec || ~13sec|| ~30sec || ~2min
|-
| ''' Temps d’exécution du programme dans l'espace CIELAB ''' ||~37sec ||~1min20 ||~3min || ~12min30
|}
On remarque que le temps d’exécution du programme dans l'espace CIELAB est plus long. La différence se fait durant les calculs pour les changements d'espace; le programme doit en effet faire des étapes supplémentaires sur tous les pixels au début et à la fin. 

== Code ==
J'ai mis mes 2 programmes sur GitHub [https://github.com/FloowD/VISI201_transfert_couleurs ici] 
Pour utiliser le programme il faut lancer la fonction suivante :
<code>main_numpy("image1.jpg","image2.jpg","image3.jpg")</code> 
A noter que les 2 premiers paramètres ne sont pas obligatoirement au même format mais doivent tout deux être des images. 
Penser à bien indiquer le format de l'image 3 dans la fonction.

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-17T19:27:00Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque [[https://numpy.org/ Numpy]] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page, je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet ([[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images ici]]) pour bien comprendre le fonctionnement du programme et son but.

== Quelles étaient les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bons rendus. Néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devenait problématique si on voulait faire un transfert de couleurs entre 2 images avec un grand nombre de pixels. 

=== Quelques statistiques sur les temps de calcul ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

''A noter que ces tests ont été réalisés avec un nombre de répétition de 20 dans le programme.'' 
Ce nombre est une valeur de référence suffisante pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur. 
On remarque par ces chiffres que lorsque l'on transfert des images de petite résolution, le temps de transfert reste tout à fait correct. Néanmoins dès que l'on va vouloir prendre des images de résolution plus importante (HD ou même 4K), le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables de faire un milliard de calculs par seconde mais <code>Python</code> est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau).

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme, nous utilisons de nombreux tableaux afin de stocker toutes les variables dont nous avons besoin, et la bibliothèque <code>Numpy</code> possède des tableaux bien plus compacts. De plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire une boucle pour appliquer ces calculs sur chaque variable. 
De ce fait, on gagne énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très complète et si vous voulez plus d'informations je vous conseille de vous rendre sur la page officielle [[https://numpy.org/ Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
Ces tests ont eux aussi été réalisés avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de <code>Numpy</code> permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition pour avoir un meilleur résultat en gardant un temps d’exécution correct.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ||!colspan="5"| ''' Nombres de tours dans le programme'''
|-
| ''' Taille de l'image ''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

Plus on augmente la taille de l'image et le nombre de tour, plus le temps d'exécution devient important. En effet, les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de haute qualité, de regrouper plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrait d'avoir moins de pixels à traiter sans pour autant avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nu.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet, l'espace RVB est très bien mais il correspond aux écrans et non à l’œil humain, tandis que l'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L*a*b CIE 1976]] a pour but de mieux approximer la réalité.
Cet espace, autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 

=== Calcul nécessaire ===
==== Passage RVB -> Lab ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtient avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composante de l'espace CIELAB et on peut ensuite calculer l'écart de couleur de la même manière que dans l'espace RVB. 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage Lab -> RVB ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permettent d'avoir dans certains cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs. 
Néanmoins, on peut voir qu'on à plus de mal a distinguer le relief sur la seconde image.

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy
{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme dans l'espace RGB ''' ||~6sec || ~13sec|| ~30sec || ~2min
|-
| ''' Temps d’exécution du programme dans l'espace CIELAB ''' ||~37sec ||~1min20 ||~3min || ~12min30
|}
On remarque que le temps d’exécution du programme dans l'espace CIELAB est plus long. La différence se fait durant les calculs pour les changements d'espace; le programme doit en effet faire des étapes supplémentaires sur tous les pixels au début et à la fin. 

== Code ==
J'ai mis mes 2 programmes sur GitHub [https://github.com/FloowD/VISI201_transfert_couleurs ici] 
Pour utiliser le programme il faut lancer la fonction suivante :
<code>main_numpy("image1.jpg","image2.jpg","image3.jpg")</code> 
A noter que les 2 premiers paramètres ne sont pas obligatoirement au même format mais doivent tout deux être des images. 
Penser à bien indiquer le format de l'image 3 dans la fonction.

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-17T18:48:43Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque [[https://numpy.org/ Numpy]] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page, je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet ([[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images ici]]) pour bien comprendre le fonctionnement du programme et son but.

== Quelles étaient les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bons rendus. Néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devenait problématique si on voulait faire un transfert de couleurs entre 2 images avec un grand nombre de pixels. 

=== Quelques statistiques sur les temps de calcul ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

''A noter que ces tests ont été réalisés avec un nombre de répétition de 20 dans le programme.'' 
Ce nombre est une valeur de référence suffisante pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur. 
On remarque par ces chiffres que lorsque l'on transfert des images de petite résolution, le temps de transfert reste tout à fait correct. Néanmoins dès que l'on va vouloir prendre des images de résolution plus importante (HD ou même 4K), le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables de faire un milliard de calculs par seconde mais <code>Python</code> est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau).

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme, nous utilisons de nombreux tableaux afin de stocker toutes les variables dont nous avons besoin, et la bibliothèque <code>Numpy</code> possède des tableaux bien plus compacts, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire une boucle pour appliquer les calculs sur chaque variable. 
De ce fait, on gagne énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très complète et si vous voulez plus d'informations je vous conseille de vous rendre sur la page officielle [[https://numpy.org/ Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus, ces tests ont été réalisés avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de <code>Numpy</code> permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correct.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nombres de tours dans le programme''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

Plus on augmente la taille de l'image et le nombre de tour, plus le temps d'exécution devient important. En effet, les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de haute qualité, de regrouper plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nu.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet, l'espace RVB est très bien mais il correspond aux écrans et non à l’œil humain, tandis que cet espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage.

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtient avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composante de l'espace CIELAB et on peut ensuite calculer l'écart de couleur de la même manière que dans l'espace RVB. 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permettent d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs. 
Néanmoins, on peut voir qu'on à plus de mal a distinguer le relief sur la seconde image.

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy
{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme dans l'espace RGB ''' ||~6sec || ~13sec|| ~30sec || ~2min
|-
| ''' Temps d’exécution du programme dans l'espace CIELAB ''' ||~37sec ||~1min20 ||~3min || ~12min30
|}
On remarque que le temps d’exécution du programme dans l'espace CIELAB est plus long. La différence se fait durant les calculs pour les changements d'espace, le programme doit en effet faire des étapes supplémentaires sur tous les pixels au début et à la fin. 

== Code ==
J'ai mis mes 2 programmes sur GitHub [https://github.com/FloowD/VISI201_transfert_couleurs ici] 
Pour utiliser le programme il faut lancer la fonction suivante :
<code>main_numpy("image1.jpg","image2.jpg","image3.jpg")</code> 
A noter que les 2 premiers paramètres ne sont pas obligatoirement au même format mais doivent tout deux rester des images. 
Penser à bien indiquer le format de l'image 3 dans la fonction.

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-17T18:08:21Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque [[https://numpy.org/ Numpy]] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page, je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet ([[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images ici]]) pour bien comprendre le fonctionnement du programme et son but.

== Quelles étaient les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bons rendus. Néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devenait problématique si on voulait faire un transfert de couleurs entre 2 images avec un grand nombre de pixels. 

=== Quelques statistiques sur les temps de calcul ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

''A noter que ces tests ont été réalisés avec un nombre de répétition de 20 dans le programme.'' 
Ce nombre est une valeur de référence suffisante pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur. 
On remarque par ces chiffres que lorsque l'on transfert des images de petite résolution, le temps de transfert reste tout à fait correct. Néanmoins dès que l'on va vouloir prendre des images de résolution plus importante (HD ou même 4K), le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables de faire un milliard de calculs par seconde mais <code>Python</code> est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau).

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme, nous utilisons de nombreux tableaux afin de stocker toutes les variables dont nous avons besoin, et la bibliothèque <code>Numpy</code> possède des tableaux bien plus compacts, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire une boucle pour appliquer les calculs sur chaque variable. 
De ce fait, on gagne énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très complète et si vous voulez plus d'informations je vous conseille de vous rendre sur la page officielle [[https://numpy.org/ Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus, ces tests ont été réalisés avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de <code>Numpy</code> permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correct.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nombres de tours dans le programme''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, de regrouper plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nu.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cet espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permettent d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs. 
Néanmoins on peut voir qu'on à plus de mal a distinguer le relief sur la seconde image.

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy
{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme dans l'espace RGB ''' ||~6sec || ~13sec|| ~30sec || ~2min
|-
| ''' Temps d’exécution du programme dans l'espace CIELAB ''' ||~37sec ||~1min20 ||~3min || ~12min30
|}
On remarque que le temps d’exécution du programme dans l'espace CIELAB est plus long. La différence ce fait durant les calculs pour les changements d'espace, le programme doit en effet faire des étapes supplémentaires sur tous les pixels au début et à la fin. 

== Code ==
J'ai mis mes 2 programmes sur GitHub [https://github.com/FloowD/VISI201_transfert_couleurs ici] 
Pour utiliser le programme il faut lancer la fonction suivante :
<code>main_numpy("image1.jpg","image2.jpg","image3.jpg")</code> 
A noter que les 2 premiers fichiers ne sont pas obligatoirement au même format mais doivent tout deux rester des images. 
Penser à bien indiquer le format de l'image 3 dans la fonction

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-17T18:05:30Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque [[https://numpy.org/ Numpy]] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page, je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet ([[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images ici]]) pour bien comprendre le fonctionnement du programme et son but.

== Quelles étaient les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bons rendus. Néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devenait problématique si on voulait faire un transfert de couleurs entre 2 images avec un grand nombre de pixels. 

=== Quelques statistiques sur les temps de calcul ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

''A noter que ces tests ont été réalisés avec un nombre de répétition de 20 dans le programme.'' 
Ce nombre est une valeur de référence suffisante pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur. 
On remarque par ces chiffres que lorsque l'on transfert des images de petite résolution, le temps de transfert reste tout à fait correct. Néanmoins dès que l'on va vouloir prendre des images de résolution plus importante (HD ou même 4K), le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables de faire un milliard de calculs par seconde mais <code>Python</code> est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau).

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme, nous utilisons de nombreux tableaux afin de stocker toutes les variables dont nous avons besoin, et la bibliothèque <code>Numpy</code> possède des tableaux bien plus compacts, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire une boucle pour appliquer les calculs sur chaque variable. 
De ce fait, on gagne énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très complète et si vous voulez plus d'informations je vous conseille de vous rendre sur la page officielle [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nombres de tours dans le programme''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, de regrouper plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nu.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cet espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permettent d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs. 
Néanmoins on peut voir qu'on à plus de mal a distinguer le relief sur la seconde image.

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy
{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme dans l'espace RGB ''' ||~6sec || ~13sec|| ~30sec || ~2min
|-
| ''' Temps d’exécution du programme dans l'espace CIELAB ''' ||~37sec ||~1min20 ||~3min || ~12min30
|}
On remarque que le temps d’exécution du programme dans l'espace CIELAB est plus long. La différence ce fait durant les calculs pour les changements d'espace, le programme doit en effet faire des étapes supplémentaires sur tous les pixels au début et à la fin. 

== Code ==
J'ai mis mes 2 programmes sur GitHub [https://github.com/FloowD/VISI201_transfert_couleurs ici] 
Pour utiliser le programme il faut lancer la fonction suivante :
<code>main_numpy("image1.jpg","image2.jpg","image3.jpg")</code> 
A noter que les 2 premiers fichiers ne sont pas obligatoirement au même format mais doivent tout deux rester des images. 
Penser à bien indiquer le format de l'image 3 dans la fonction

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-15T09:44:09Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque [[https://numpy.org/ Numpy]] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page, je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet ([[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images ici]]) pour bien comprendre le fonctionnement du programme et son but.

== Quelles étaient les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bons rendus. Néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devenait problématique si on voulait faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calcul de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

''A noter que ces tests ont été réalisés avec un nombre de répétition de 20 dans le programme.'' 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffres que lorsque l'on transfert des images de petite résolution, le temps de transfert reste tout à fait correct. Néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K), le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables de faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compacts, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire une boucle pour appliquer les calculs sur chaque variable. 
De ce fait, on gagne énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseille de vous rendre sur la page officielle [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nombres de tours dans le programme''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, de regrouper plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nu.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cet espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permettent d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs. 
Néanmoins on peut voir qu'on à plus de mal a distinguer le relief sur la seconde image.

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy
{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme dans l'espace RGB ''' ||~6sec || ~13sec|| ~30sec || ~2min
|-
| ''' Temps d’exécution du programme dans l'espace CIELAB ''' ||~37sec ||~1min20 ||~3min || ~12min30
|}
On remarque que le temps d’exécution du programme dans l'espace CIELAB est plus long. La différence ce fait durant les calculs pour les changements d'espace, le programme doit en effet faire des étapes supplémentaires sur tous les pixels au début et à la fin. 

== Code ==
J'ai mis mes 2 programmes sur GitHub [https://github.com/FloowD/VISI201_transfert_couleurs ici] 
Pour utiliser le programme il faut lancer la fonction suivante :
<code>main_numpy("image1.jpg","image2.jpg","image3.jpg")</code> 
A noter que les 2 premiers fichiers ne sont pas obligatoirement au même format mais doivent tout deux rester des images. 
Penser à bien indiquer le format de l'image 3 dans la fonction

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-15T09:06:11Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque [[https://numpy.org/ Numpy]] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet ([[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images ici]]) pour bien comprendre le fonctionnement du programme et son but.

== Quelles étaient les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bons rendus. Néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devenait problématique si on voulait faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calcul de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

''A noter que ces tests ont été réalisés avec un nombre de répétition de 20 dans le programme.'' 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffres que lorsque l'on transfert des images de petite résolution, le temps de transfert reste tout à fait correct. Néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K), le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables de faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compacts, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire une boucle pour appliquer les calculs sur chaque variable. 
De ce fait, on gagne énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseille de vous rendre sur la page officielle [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nombres de tours dans le programme''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, de regrouper plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nu.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cet espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permettent d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs. 
Néanmoins on peut voir qu'on à plus de mal a distinguer le relief sur la seconde image.

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy
{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme dans l'espace RGB ''' ||~6sec || ~13sec|| ~30sec || ~2min
|-
| ''' Temps d’exécution du programme dans l'espace CIELAB ''' ||~37sec ||~1min20 ||~3min || ~12min30
|}
On remarque que le temps d’exécution du programme dans l'espace CIELAB est plus long. La différence ce fait durant les calculs pour les changements d'espace, le programme doit en effet faire des étapes supplémentaires sur tous les pixels au début et à la fin. 

== Code ==
J'ai mis mes 2 programmes sur GitHub [https://github.com/FloowD/VISI201_transfert_couleurs ici] 
Pour utiliser le programme il faut lancer la fonction suivante :
<code>main_numpy("image1.jpg","image2.jpg","image3.jpg")</code> 
A noter que les 2 premiers fichiers ne sont pas obligatoirement au même format mais doivent tout deux rester des images. 
Penser à bien indiquer le format de l'image 3 dans la fonction

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-15T08:58:24Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque [[https://numpy.org/ Numpy]] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet ([[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images ici]]) pour bien comprendre le fonctionnement du programme et son but.

== Quelles étaient les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calcul de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

''A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme.'' 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffres que lorsqu'on transfert des images de petite résolution, le temps de transfert reste tout à fait correct, néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compactes, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire un boucle pour appliquer les calculs sur chaque variable. 
De ce fait cela nous permet de gagner énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseil de vous rendre sur la page officiel [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nombres de tours dans le programme''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, a regroupé plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nue.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cette espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permette d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs. 
Néanmoins on peut voir qu'on a plus de mal a distinguer le relief sur la seconde image.

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy
{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme dans l'espace RGB ''' ||~6sec || ~13sec|| ~30sec || ~2min
|-
| ''' Temps d’exécution du programme dans l'espace CIELAB ''' ||~37sec ||~1min20 ||~3min || ~12min30
|}
On remarque que le temps d'execution du programme dans l'espace CIELAB est plus long, la différence ce fait durant les calculs pour les changements d'espace, le programme doit en effet faire des étapes supplémentaires sur le tous les pixels au début et à la fin. 

== Code ==
J'ai mit mes 2 programmes sur GitHub [https://github.com/FloowD/VISI201_transfert_couleurs ici] 
Pour utiliser le programme il faut lancer la fonction suivante :
<code>main_numpy("image1.jpg","image2.jpg","image3.jpg")</code> 
A noter que les 2 premiers fichiers ne sont pas obligatoirement au même format mais doivent tout deux rester des images. 
Penser à bien indiquer le format de l'image 3 dans la fonction

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-15T08:57:52Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque [[https://numpy.org/ Numpy]] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet ([[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images ici]]) pour bien comprendre le fonctionnement du programme et son but.

== Quelles étaient les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

''A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme.'' 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffres que lorsqu'on transfert des images de petite résolution, le temps de transfert reste tout à fait correct, néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compactes, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire un boucle pour appliquer les calculs sur chaque variable. 
De ce fait cela nous permet de gagner énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseil de vous rendre sur la page officiel [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nombres de tours dans le programme''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, a regroupé plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nue.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cette espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permette d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs. 
Néanmoins on peut voir qu'on a plus de mal a distinguer le relief sur la seconde image.

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy
{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme dans l'espace RGB ''' ||~6sec || ~13sec|| ~30sec || ~2min
|-
| ''' Temps d’exécution du programme dans l'espace CIELAB ''' ||~37sec ||~1min20 ||~3min || ~12min30
|}
On remarque que le temps d'execution du programme dans l'espace CIELAB est plus long, la différence ce fait durant les calculs pour les changements d'espace, le programme doit en effet faire des étapes supplémentaires sur le tous les pixels au début et à la fin. 

== Code ==
J'ai mit mes 2 programmes sur GitHub [https://github.com/FloowD/VISI201_transfert_couleurs ici] 
Pour utiliser le programme il faut lancer la fonction suivante :
<code>main_numpy("image1.jpg","image2.jpg","image3.jpg")</code> 
A noter que les 2 premiers fichiers ne sont pas obligatoirement au même format mais doivent tout deux rester des images. 
Penser à bien indiquer le format de l'image 3 dans la fonction

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-15T08:57:26Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque [[https://numpy.org/ Numpy]] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet ([[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images ici]]) pour bien comprendre le fonctionnement du programme et son but.

== Quelles était les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

''A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme.'' 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffres que lorsqu'on transfert des images de petite résolution, le temps de transfert reste tout à fait correct, néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compactes, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire un boucle pour appliquer les calculs sur chaque variable. 
De ce fait cela nous permet de gagner énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseil de vous rendre sur la page officiel [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nombres de tours dans le programme''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, a regroupé plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nue.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cette espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permette d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs. 
Néanmoins on peut voir qu'on a plus de mal a distinguer le relief sur la seconde image.

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy
{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme dans l'espace RGB ''' ||~6sec || ~13sec|| ~30sec || ~2min
|-
| ''' Temps d’exécution du programme dans l'espace CIELAB ''' ||~37sec ||~1min20 ||~3min || ~12min30
|}
On remarque que le temps d'execution du programme dans l'espace CIELAB est plus long, la différence ce fait durant les calculs pour les changements d'espace, le programme doit en effet faire des étapes supplémentaires sur le tous les pixels au début et à la fin. 

== Code ==
J'ai mit mes 2 programmes sur GitHub [https://github.com/FloowD/VISI201_transfert_couleurs ici] 
Pour utiliser le programme il faut lancer la fonction suivante :
<code>main_numpy("image1.jpg","image2.jpg","image3.jpg")</code> 
A noter que les 2 premiers fichiers ne sont pas obligatoirement au même format mais doivent tout deux rester des images. 
Penser à bien indiquer le format de l'image 3 dans la fonction

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-15T08:56:29Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque [[https://numpy.org/ Numpy]] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet (le lien précédant) et bien comprendre le fonctionnement du programme et son but.

== Quelles était les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

''A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme.'' 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffres que lorsqu'on transfert des images de petite résolution, le temps de transfert reste tout à fait correct, néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compactes, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire un boucle pour appliquer les calculs sur chaque variable. 
De ce fait cela nous permet de gagner énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseil de vous rendre sur la page officiel [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nombres de tours dans le programme''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, a regroupé plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nue.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cette espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permette d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs. 
Néanmoins on peut voir qu'on a plus de mal a distinguer le relief sur la seconde image.

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy
{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme dans l'espace RGB ''' ||~6sec || ~13sec|| ~30sec || ~2min
|-
| ''' Temps d’exécution du programme dans l'espace CIELAB ''' ||~37sec ||~1min20 ||~3min || ~12min30
|}
On remarque que le temps d'execution du programme dans l'espace CIELAB est plus long, la différence ce fait durant les calculs pour les changements d'espace, le programme doit en effet faire des étapes supplémentaires sur le tous les pixels au début et à la fin. 

== Code ==
J'ai mit mes 2 programmes sur GitHub [https://github.com/FloowD/VISI201_transfert_couleurs ici] 
Pour utiliser le programme il faut lancer la fonction suivante :
<code>main_numpy("image1.jpg","image2.jpg","image3.jpg")</code> 
A noter que les 2 premiers fichiers ne sont pas obligatoirement au même format mais doivent tout deux rester des images. 
Penser à bien indiquer le format de l'image 3 dans la fonction

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-14T17:23:37Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque https://numpy.org/ Numpy] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet (le lien précédant) et bien comprendre le fonctionnement du programme et son but.

== Quelles était les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

''A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme.'' 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffres que lorsqu'on transfert des images de petite résolution, le temps de transfert reste tout à fait correct, néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compactes, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire un boucle pour appliquer les calculs sur chaque variable. 
De ce fait cela nous permet de gagner énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseil de vous rendre sur la page officiel [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nombres de tours dans le programme''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, a regroupé plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nue.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cette espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permette d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs. 
Néanmoins on peut voir qu'on a plus de mal a distinguer le relief sur la seconde image.

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy
{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme dans l'espace RGB ''' ||~6sec || ~13sec|| ~30sec || ~2min
|-
| ''' Temps d’exécution du programme dans l'espace CIELAB ''' ||~37sec ||~1min20 ||~3min || ~12min30
|}
On remarque que le temps d'execution du programme dans l'espace CIELAB est plus long, la différence ce fait durant les calculs pour les changements d'espace, le programme doit en effet faire des étapes supplémentaires sur le tous les pixels au début et à la fin. 

== Code ==
J'ai mit mes 2 programmes sur GitHub [https://github.com/FloowD/VISI201_transfert_couleurs ici] 
Pour utiliser le programme il faut lancer la fonction suivante :
<code>main_numpy("image1.jpg","image2.jpg","image3.jpg")</code> 
A noter que les 2 premiers fichiers ne sont pas obligatoirement au même format mais doivent tout deux rester des images. 
Penser à bien indiquer le format de l'image 3 dans la fonction

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-14T17:23:22Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque https://numpy.org/ Numpy] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet (le lien précédant) et bien comprendre le fonctionnement du programme et son but.

== Quelles était les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

''A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme.'' 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffres que lorsqu'on transfert des images de petite résolution, le temps de transfert reste tout à fait correct, néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compactes, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire un boucle pour appliquer les calculs sur chaque variable. 
De ce fait cela nous permet de gagner énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseil de vous rendre sur la page officiel [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nombres tours dans le programme''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, a regroupé plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nue.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cette espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permette d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs. 
Néanmoins on peut voir qu'on a plus de mal a distinguer le relief sur la seconde image.

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy
{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme dans l'espace RGB ''' ||~6sec || ~13sec|| ~30sec || ~2min
|-
| ''' Temps d’exécution du programme dans l'espace CIELAB ''' ||~37sec ||~1min20 ||~3min || ~12min30
|}
On remarque que le temps d'execution du programme dans l'espace CIELAB est plus long, la différence ce fait durant les calculs pour les changements d'espace, le programme doit en effet faire des étapes supplémentaires sur le tous les pixels au début et à la fin. 

== Code ==
J'ai mit mes 2 programmes sur GitHub [https://github.com/FloowD/VISI201_transfert_couleurs ici] 
Pour utiliser le programme il faut lancer la fonction suivante :
<code>main_numpy("image1.jpg","image2.jpg","image3.jpg")</code> 
A noter que les 2 premiers fichiers ne sont pas obligatoirement au même format mais doivent tout deux rester des images. 
Penser à bien indiquer le format de l'image 3 dans la fonction

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-13T13:55:50Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque https://numpy.org/ Numpy] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet (le lien précédant) et bien comprendre le fonctionnement du programme et son but.

== Quelles était les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

''A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme.'' 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffres que lorsqu'on transfert des images de petite résolution, le temps de transfert reste tout à fait correct, néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compactes, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire un boucle pour appliquer les calculs sur chaque variable. 
De ce fait cela nous permet de gagner énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseil de vous rendre sur la page officiel [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nb tours''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, a regroupé plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nue.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cette espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permette d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs. 
Néanmoins on peut voir qu'on a plus de mal a distinguer le relief sur la seconde image.

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy
{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme dans l'espace RGB ''' ||~6sec || ~13sec|| ~30sec || ~2min
|-
| ''' Temps d’exécution du programme dans l'espace CIELAB ''' ||~37sec ||~1min20 ||~3min || ~12min30
|}
On remarque que le temps d'execution du programme dans l'espace CIELAB est plus long, la différence ce fait durant les calculs pour les changements d'espace, le programme doit en effet faire des étapes supplémentaires sur le tous les pixels au début et à la fin. 

== Code ==
J'ai mit mes 2 programmes sur GitHub [https://github.com/FloowD/VISI201_transfert_couleurs ici] 
Pour utiliser le programme il faut lancer la fonction suivante :
<code>main_numpy("image1.jpg","image2.jpg","image3.jpg")</code> 
A noter que les 2 premiers fichiers ne sont pas obligatoirement au même format mais doivent tout deux rester des images. 
Penser à bien indiquer le format de l'image 3 dans la fonction

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-13T13:35:22Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque https://numpy.org/ Numpy] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet (le lien précédant) et bien comprendre le fonctionnement du programme et son but.

== Quelles était les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

''A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme.'' 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffres que lorsqu'on transfert des images de petite résolution, le temps de transfert reste tout à fait correct, néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compactes, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire un boucle pour appliquer les calculs sur chaque variable. 
De ce fait cela nous permet de gagner énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseil de vous rendre sur la page officiel [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nb tours''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, a regroupé plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nue.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cette espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permette d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs.

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy
{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme dans l'espace RGB ''' ||~6sec || ~13sec|| ~30sec || ~2min
|-
| ''' Temps d’exécution du programme dans l'espace CIELAB ''' ||~37sec ||~1min20 ||~3min || ~12min30
|}
On remarque que le temps d'execution du programme dans l'espace CIELAB est plus long, la différence ce fait durant les calculs pour les changements d'espace, le programme doit en effet faire des étapes supplémentaires sur le tous les pixels au début et à la fin. 

== Code ==
J'ai mit mes 2 programmes sur GitHub [http://www.example.com ici]
== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-12T16:36:25Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque https://numpy.org/ Numpy] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet (le lien précédant) et bien comprendre le fonctionnement du programme et son but.

== Quelles était les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme. 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffre que lorsqu'on transfert des images de petites résolution, le temps de transfert reste tout à fait correct, ,néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compactes, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire un boucle pour appliquer les calculs sur chaque variable. 
De ce fait cela nous permet de gagner énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseil de vous rendre sur la page officiel [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nb tours''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, a regroupé plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nue.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cette espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permette d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs.

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-12T16:24:51Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposée par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalités. La plus importante étant la bibliothèque https://numpy.org/ Numpy] afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet (le lien précédant) et bien comprendre le fonctionnement du programme et son but.

== Quelles était les limites de l'ancien programme ==

Le programme précédant fonctionnait très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme. 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffre que lorsqu'on transfert des images de petites résolution, le temps de transfert reste tout à fait correct, ,néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compactes, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire un boucle pour appliquer les calculs sur chaque variable. 
De ce fait cela nous permet de gagner énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseil de vous rendre sur la page officiel [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nb tours''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, a regroupé plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nue.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cette espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permette d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs

===Temps d’exécution ===
On peut comparer la vitesse du nouveau programme avec celui réalisé avec numpy

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-12T16:09:40Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposé par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalitées. La plus importante étant la bibliothèque numpy afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet (le lien précédant) et bien comprendre le fonctionnement du programme et son but.

== Quelles était les limites de l'ancien programme ==

Le programme précédant fonctionner très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme. 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffre que lorsqu'on transfert des images de petites résolution, le temps de transfert reste tout à fait correct, ,néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compactes, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire un boucle pour appliquer les calculs sur chaque variable. 
De ce fait cela nous permet de gagner énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseil de vous rendre sur la page officiel [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nb tours''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, a regroupé plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nue.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cette espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permette d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}
On peut voir que dans la version avec l'espace CIELAB, les couleurs sont plus harmonieuses, et restent dans la même intensité de couleurs

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-12T16:05:45Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposé par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalitées. La plus importante étant la bibliothèque numpy afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet (le lien précédant) et bien comprendre le fonctionnement du programme et son but.

== Quelles était les limites de l'ancien programme ==

Le programme précédant fonctionner très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme. 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffre que lorsqu'on transfert des images de petites résolution, le temps de transfert reste tout à fait correct, ,néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compactes, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire un boucle pour appliquer les calculs sur chaque variable. 
De ce fait cela nous permet de gagner énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseil de vous rendre sur la page officiel [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nb tours''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, a regroupé plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nue.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cette espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permette d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg|600px]] || [[Fichier:canyon_vert_Lab.jpg|600px]]
|}

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-12T16:05:16Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposé par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalitées. La plus importante étant la bibliothèque numpy afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet (le lien précédant) et bien comprendre le fonctionnement du programme et son but.

== Quelles était les limites de l'ancien programme ==

Le programme précédant fonctionner très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme. 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffre que lorsqu'on transfert des images de petites résolution, le temps de transfert reste tout à fait correct, ,néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compactes, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire un boucle pour appliquer les calculs sur chaque variable. 
De ce fait cela nous permet de gagner énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseil de vous rendre sur la page officiel [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nb tours''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, a regroupé plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nue.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cette espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permette d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images 
[[Fichier:Grand_canyon.jpg|600px]]
[[Fichier:degrade_vert.jpg|600px]] 

Regardons maintenant le résultat avec les 2 programmes : 
{| class="wikitable"
| ''' Rendu avec le programme classique''' || '''Rendu avec l'espace CIELAB '''
|-
| [[Fichier:canyon_vert_numpy.jpg]] || [[Fichier:canyon_vert_Lab.jpg]]
|}

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Fichier:Canyon vert Lab.jpg

2020-05-12T16:04:50Z

Fdufaure :

Fichier:Canyon vert numpy.jpg

2020-05-12T16:04:18Z

Fdufaure :

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-12T15:58:23Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposé par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalitées. La plus importante étant la bibliothèque numpy afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet (le lien précédant) et bien comprendre le fonctionnement du programme et son but.

== Quelles était les limites de l'ancien programme ==

Le programme précédant fonctionner très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme. 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffre que lorsqu'on transfert des images de petites résolution, le temps de transfert reste tout à fait correct, ,néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compactes, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire un boucle pour appliquer les calculs sur chaque variable. 
De ce fait cela nous permet de gagner énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseil de vous rendre sur la page officiel [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nb tours''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, a regroupé plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nue.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cette espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous permette d'avoir dans certain cas un meilleur rendu. 
Prenons l'exemple de ces 2 images
[[Fichier:Grand_canyon.jpg]]
[[Fichier:degrade_vert.jpg]]

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Fichier:Degrade vert.jpg

2020-05-12T15:58:16Z

Fdufaure :

Fichier:Grand canyon.jpg

2020-05-12T15:57:59Z

Fdufaure :

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-12T14:59:52Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposé par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalitées. La plus importante étant la bibliothèque numpy afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet (le lien précédant) et bien comprendre le fonctionnement du programme et son but.

== Quelles était les limites de l'ancien programme ==

Le programme précédant fonctionner très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme. 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffre que lorsqu'on transfert des images de petites résolution, le temps de transfert reste tout à fait correct, ,néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compactes, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire un boucle pour appliquer les calculs sur chaque variable. 
De ce fait cela nous permet de gagner énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseil de vous rendre sur la page officiel [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nb tours''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, a regroupé plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nue.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cette espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous donne un meilleur rendu sur certaine image
[[Fichier:Exemple.jpg]]

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy] 
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-12T14:42:10Z

Fdufaure :

Le but de ce projet est une amélioration de la version proposé par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalitées. La plus importante étant la bibliothèque numpy afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet (le lien précédant) et bien comprendre le fonctionnement du programme et son but.

== Quelles était les limites de l'ancien programme ==

Le programme précédant fonctionner très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme. 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffre que lorsqu'on transfert des images de petites résolution, le temps de transfert reste tout à fait correct, ,néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

== Nouvelle version avec numpy ==

=== Pourquoi numpy ===

Dans ce programme nous utilisons de nombreux tableaux afin de stocker toute les variables dont nous avons besoin, et la bibliothèque numpy possède des tableaux bien plus compactes, et de plus, l'avantage majeur est que l'on peut appliquer des calculs directement sur l'ensemble du tableau au lieu de faire un boucle pour appliquer les calculs sur chaque variable. 
De ce fait cela nous permet de gagner énormément de temps de calcul en évitant de nombreuses boucles. 
Cette bibliothèque est très compléte et si vous voulez plus d'informations je vous conseil de vous rendre sur la page officiel [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Numpy]]

=== Comparaison première version avec la version numpy ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|-
| ''' Temps d’exécution avec numpy ''' || ~6sec || ~13sec || ~30sec || ~2min
|}
De plus ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme 
On voit ainsi que l'utilisation de numpy permet de rendre le programme environ 10 fois plus rapide.
Ainsi on peut donc penser maintenant à augmenter le nombre de répétition avant d'avoir un meilleur résultat en gardant un temps d’exécution correcte.

{| class="wikitable"
!colspan="6"|Temps d’exécution du programme
|-
| ''' Taille de l'image '''/''' Nb tours''' || 20 || 40 || 50 || 75 || 100
|-
| 720x576 || 6sec || 10sec || 13sec || 18sec || 24sec
|-
| 1280x720 || 13sec || 25sec || 30sec || 48sec || 1min
|-
| 1920x1080 || 30sec || 54sec || 1min10 || 1min40 || 2min
|-
| 3840x2160 || 2min || 3min50 || 5min || 7min15 || 9min30
|}

On remarque ainsi que la taille de l'image augmente, et le nombre de répétitions aussi, plus le temps d’exécution devient important, surtout pour les très grandes images (comme celle de 3840x2160 pixels). En effet les tailles deviennent exponentielles avec l'augmentation de la qualité ce qui demande énormément de pixels à traiter. 
On pourrait ainsi imaginer, pour les images de hautes qualités, a regroupé plusieurs pixels en 'paquets' et les traiter ainsi. 
Cela permettrai d'avoir moins de pixels à traiter et de plus cela ne devrait pas avoir un énorme impact sur la qualité de l'image, on ne devrait pas voir une grande différence à l’œil nue.

== Changement d'espace chromatique ==
Maintenant que l’algorithme fonctionne plus vite, on peut penser à modifier l'espace de couleurs afin d'obtenir un meilleur rendu.

=== L'espace chromatique L*a*b CIE 1976 ===
En effet l'espace RVB est très bien mais il correspond aux écrans et non à l'oeil humain, tandis que cette espace a pour but de mieux approximer la réalité.
L'espace [[https://fr.wikipedia.org/wiki/L*a*b*_CIE_1976 L'espace chromatique L*a*b CIE 1976]], autrement appelé : CIELAB est un espace reposant sur 3 composantes : la clarté L* et l'écart de la couleur par rapport à celle d'une surface grise de même clarté pour a* et b*. 
La première étape consiste à passer les composantes RVB dans l'espace XYZ. On utilise pour cela une matrice de passage

=== Calcul nécessaire ===
==== Passage Lab RVB ====
Afin de passer dans l'espace CIELAB nous devons d'abord passer dans l'espace [[https://fr.wikipedia.org/wiki/CIE_XYZ CIE XYZ]] car il est défini par ce dernier.
<center>
<math>\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
=
\begin{pmatrix}
0.618 & 0.177 & 0.205 \\
0.299 & 0.587 & 0.205 \\
0 & 0.056 & 0.944 \\
\end{pmatrix}
\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
</math>
</center>
On passe ensuite de l'espace XYZ à l'espace CIELAB grâce aux formules suivantes :
<center>
:{|
|-
|<math>\begin{align}
L^* &= 116 f(Y/Y_n) - 16\\
a^* &= 500 \left[f(X/X_n) - f(Y/Y_n)\right]\\
b^* &= 200 \left[f(Y/Y_n) - f(Z/Z_n)\right]
\end{align}</math>

|<math>\qquad \mathrm o \mathrm \grave{u}~f(t) = \begin{cases}
t^{1/3} & \mbox{si } t > (\frac{6}{29})^3 \\
\frac13 \left( \frac{29}{6} \right)^2 t + \frac{4}{29} & \mbox{sinon}
\end{cases}</math>
|}
</center>
Ici ''<math>X_n</math>'', ''<math>Y_n</math>'' et ''<math>Z_n</math>'' sont les composantes du blanc de référence, ce sont des constantes valant 255, on les obtiens avec RVB =(255,255,255).

On récupère ainsi les valeurs de chaque composantes de l'espace CIELAB et on peut ensuite calculer l'écart de couleurs de la même manière que dans l'espace RVB : 
<center><math>\Delta E = \sqrt{(\Delta L^*)^2 + (\Delta a^*)^2 + (\Delta b^*)^2 }</math></center>
==== Passage RVB Lab ====
De la même manière on doit d'abord repasser dans l'espace XYZ avant de revenir dans l'espace RGB
<center>
:{|
|-
||<math>Y = Y_n \cdot f^{-1}\left(\frac{L^*+16}{116}\right)</math>
|rowspan=3|<math>\qquad \mathrm o \mathrm \grave{u}~f^{-1}(t) = \begin{cases}
t^3 & \mbox{si } t > \tfrac{6}{29} \\
3\left(\tfrac{6}{29}\right)^2\left(t - \tfrac{4}{29}\right) & \mbox{sinon}
\end{cases}</math>
|-
|<math>X = X_n \cdot f^{-1}\left(\frac{L^*+16}{116} + \frac{a^*}{500}\right)</math>
|-
|<math>Z = Z_n \cdot f^{-1}\left(\frac{L^*+16}{116} - \frac{b^*}{200}\right)</math>
|}
</center>
 
On repasse ensuite dans l'espace RVB avec de nouveau une matrice de passage
<center>
<math>\begin{pmatrix}
R \\
V \\
B \\
\end{pmatrix}
=
\begin{pmatrix}
1.876 & -0.533 & -0.343 \\
-0.967 & 1.998 & -0.031 \\
0.057 & -0.118 & 1.061 \\
\end{pmatrix}
\begin{pmatrix}
X \\
Y \\
Z \\
\end{pmatrix}
</math>
</center>

=== Rendu des images ===
Les images dans l'espace CIELAB nous donne un meilleur rendu sur certaine image

== Sources ==
[https://numpy.org/ Numpy] 
[https://www.geeksforgeeks.org/numpy-mathematical-function/ Fonction numpy]
[http://www.tsi.enst.fr/pages/enseignement/ressources/beti/correl_couleur/lab.html Espace CIELAB]

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-12T14:24:41Z

Fdufaure :

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-05T16:13:39Z

Fdufaure :

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-05T15:03:08Z

Fdufaure :

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-05T13:45:17Z

Fdufaure :

Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy

2020-05-05T13:35:09Z

Fdufaure : Page créée avec « == Modification de Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy == Le but de ce projet est une amélioration de la version proposé par... »

== Modification de Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy ==

Le but de ce projet est une amélioration de la version proposé par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalitées. La plus importante étant la bibliothèque numpy afin d'accélérer la vitesse d'exécution du programme. 
Afin de comprendre correctement cette page je vous invite tout d'abord à vous rendre sur la page de la première version de ce sujet (le lien précédant) et bien comprendre le fonctionnement du programme et son but.

== Quelles était les limites de l'ancien programme ==

Le programme précédant fonctionner très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme. 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffre que lorsqu'on transfert des images de petites résolution, le temps de transfert reste tout à fait correct, ,néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)

Discussion utilisateur:Fdufaure

2020-05-05T13:34:51Z

Fdufaure : Page blanchie

Discussion utilisateur:Fdufaure

2020-05-03T10:02:14Z

Fdufaure :

Discussion utilisateur:Fdufaure

2020-05-03T10:00:27Z

Fdufaure : /* Modification de Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy */ nouvelle section

== Modification de Transport optimal par coupe 1D et transfert de couleurs entre images avec numpy ==

Le but de ce projet est une amélioration de la version proposé par [[https://www.lama.univ-savoie.fr/mediawiki/index.php/Transport_optimal_par_coupe_1D_et_transfert_de_couleurs_entre_images Lucas Chardonnet]] en ajoutant des fonctionnalitées. La plus importante étant la bibliothèque numpy afin d'accélérer la vitesse d'exécution du programme

== Quelles était les limites de l'ancien programme ==

Le programme précédant fonctionner très bien et donnait de bon rendu, néanmoins il mettait un temps relativement long pour effectuer les calculs, ce qui devient problématique si on veut faire un transfert de couleurs entre 2 images avec un grand nombres de pixels. 

=== Quelques statistiques sur les temps de calculs de l'ancien programme ===

{| class="wikitable"
| ''' Taille de l'image ''' (en pixel) || 720x576 || 1280x720 || 1920x1080 || 3840x2160
|-
| ''' Temps d’exécution du programme ''' || ~48sec || ~2min25 || ~5min30 || ~20min25
|}

A noter que ces tests ont été réalisé avec un nombre de répétition de 20 dans le programme. 
C'est une bonne valeur de référence pour avoir assez de tests pour trouver un bon vecteur pour le transfert de couleur 
On remarque par ces chiffre que lorsqu'on transfert des images de petites résolution, le temps de transfert reste tout à fait correct, ,néanmoins dès que l'on va vouloir prendre des images des résolution plus importante (HD ou même 4K) le temps d'exécution devient bien plus important. 

En effet l'ancien programme comporte bon nombre de boucle '' for '', la machine doit donc faire quelques centaines de milliers de boucle. Cela semble très simple pour nos processeurs qui sont capables d'en faire un milliard de calculs par seconde mais python est un langage interprété, ce qui rajoute un temps de calcul non négligeable (comme on peut le voir par les valeurs dans le tableau)