View source for Olena/ImageTypes

{{OlenaMenu}}

=== reda 25 nov. 2002 ===

dans olena il existe deux macros pour determiner
le type exacte d'un objet :

1- <tt>Exact</tt> : si j'ai bien compris, cette macro est utilisée
pour tous les types sauf les images.

2- <tt>Concrete</tt> : c'est pour les images

si c'est correct ce que je dis, pourquoi les noms des deux
macros sont tellement differents pourquoi pas :

<tt>Exact</tt> et <tt>Exact_Image</tt>

ou

<tt>Concrete</tt> et <tt>Concrete_image</tt>

=== pollux 7 jan 2003 ===

Je n'ai pas vu de réponse précise à cette question.

Concrete ne sert effectivement que pour les images.
<tt>Exact</tt> '''peut aussi''' être utilisé sur les images.

<tt>Exact</tt> retourne le type exact d'une image au sens hiérarchique,
c'est-à-dire le type qui a servi à instancier l'image.



Concrete retourne un type d'image concret, c'est-à-dire
possédant de vrais pixels modifiables, avec les même
caractéristiques de dimension et type de valeurs que l'argument.

Suppose qu'un algorithme reçoive en argument un type d'image qui
soit en fait une fonction : aucune valeur n'est stockée, et les
valeurs demandée sont calculées à la volée.  Le type exact est
celui qui à servit à déclarer l'image, par exemple
<tt>FunctionalImage2D&lt;int_u8, myFunctor&gt;</tt>.  

Un tel type ne peut être utilisé qu'en lecture.  Si l'algorithme
doit créer une nouvelle image à partir de cet argument, il ne
peut utiliser ce type exact.  À la place, il doit créer une
image de type <tt>Image2d&lt;int_u8&gt;</tt>.  C'est précisément ce que
retourne <tt>Concrete</tt> : un type d'image similaire, mais modifiable.

Dans Olena, Concrete est (ou était, je ne suis plus très à la
page) donc utilisé pour tous les types de retour et les
variables temporaires lorsqu'elles sont modifiées, tandis
qu' <tt>Exact</tt> est utilisé (souvent à travers <tt>Exact_ref</tt> our
<tt>Exact_cref</tt>), pour caster les arguments en entrée.

Si je me souviens bien, c'est Théo qui m'avait fait introduire
cette différence.

=== david 16 fev 2003 ===

Commencons avec le plus simple : le comportement de <tt>Exact(I)</tt>. 
Je me base sur la dernière version d'Olena, 8.3 (prcs).


'''<pre> oln/core/type.hh </pre>'''
<syntaxhighlight lang="cpp" line enclose="div">
# define Exact(Type) \
typename type::exact<Type>::ret
</syntaxhighlight>

<tt>Exact</tt> est donc un outil générique (dans le sens ou il marche sur la hiérarchie d'images, mais pas que), pour dérouler les hiérarchies statiques (récursives), et obtenir le type finalement instancié.

Maintenant, regardons le comportement de <tt>Concrete(I)</tt>.

'''<pre> oln/core/image.hh </pre>'''
<syntaxhighlight lang="cpp" line enclose="div">
# define Concrete(ImgType)			\
typename mute<ImgType>::ret
</syntaxhighlight>

<tt>Concrete(I)</tt> lance le trait global <tt>mute&lt;I&gt;</tt> avec '''un seul''' paramètre.
Plus haut, dans le même fichier, on trouve:
<syntaxhighlight lang="cpp" line enclose="div">
// mute

  template<class I, class T = typename type::exact<I>::ret::value>
  struct mute
  {
	 typedef typename type::exact<I>::ret::mute<T>::ret ret;
  };
</syntaxhighlight>

Le trait <tt>mute</tt> global prend normalement deux paramètres:
* <tt>I=: un type d'image (ex: =image2d&lt;T1&gt;</tt>), qui est constitué d'un méta-type (<tt>image2d&lt;??&gt;</tt>), et d'un type de données T1 (qui vient boucher le trou du "??" précédent). 
* <tt>T=: un type de données, donné dans le but de remplacer le =T1</tt> précédent.
<tt>mute&lt;I, T&gt;</tt> a donc pour vocation de générer un nouveau type d'image ou l'on a remplacer le type de données initial (T1) par T, dans le type d'image I. On obtient ainsi <tt>image2d&lt;T&gt;</tt> a la place de <tt>I valant image2d&lt;T1&gt;</tt> dans notre exemple précédent.
Dans notre cas d'utilisation avec <tt>Concrete</tt>, un seul argument est passé. Le deuxième (T) est donc celui par défaut.
Cet argument par défaut est <tt>typename type::exact&lt;I&gt;::ret::value</tt>.

Celui-ci est obtenu en lançant le trait <tt>exact</tt> sur <tt>I= (résultat idem que Exact(I) ), et en accédant au typedef =value</tt>. 
<tt>value</tt> correspond au type de données de l'image (types Olena: <tt>int_u8</tt>, etc...).
On obtient donc comme deuxième paramètre du <tt>mute</tt> le type de données du type exact du premier paramètre =I=. (finalement, aucun changement de type de données).

Le trait <tt>mute</tt> définit un type <tt>ret</tt> comme résultat du trait <tt>mute</tt> cette fois-ci interne au type exact de I (<tt>type::exact&lt;I&gt;::ret</tt>). Cet "inner-trait" est lancé sur <tt>T=, valant, comme nous l'avons vu, le même type de données que celui de =type::exact&lt;I&gt;::ret</tt>.

Maintenant, pour obtenir le type résultat de notre <tt>Concrete(I)</tt>, il faut voir le comportement du "inner-trait" <tt>mute</tt> de I.
Un exemple, pour les images 2d

'''<pre> oln/core/image2d.hh </pre>'''
<syntaxhighlight lang="cpp" line enclose="div">
template<class T, class Inferior = type::bottom>
  class image2d : public internal::_real_image2d< T, image2d<T,Inferior> >
  {
	//....
	template<class U>
	 struct mute
	 {
		typedef image2d<U> ret;
	 };
  };
</syntaxhighlight>

A ma connaissance, dans toutes les classes d'images instanciables actuelles, cet "inner-trait" <tt>mute</tt> a le même comportement: permettre de définir un nouveau type d'image en changeant le type de données interne dans un méta-type d'image donné. i. e.: passer de <tt>image2d&lt;T1&gt;</tt> à <tt>image2d&lt;T2&gt;</tt>. 

Le seul effet de notre <tt>Concrete(I)</tt> lancé sur une <tt>image&lt;image2d&lt;int_u8&gt; &gt;</tt> par exemple sera de descendre au type concret <tt>image2d&lt;int_u8&gt;</tt>, puisque le <tt>mute</tt> de <tt>image2d</tt> ne change pas le meta-type <tt>image2d&lt;???&gt;</tt>, et que <tt>Concrete(image2d&lt;int_u8&gt;)</tt> lance précisement <tt>image2d&lt;int_u8&gt;::mute&lt;int_u8&gt;</tt> (pas de changement du type de données).

'''Conclusion perso'''

A ma connaisssance, avec les classes actuelles d'images, <tt>Concrete(I)</tt> et <tt>Exact(I)</tt> ont exactement le même comportement.
<tt>Concrete(I)</tt> n'est utilisable effectivement qu'avec les images, puisque seules les classes d'images semblent disposer d'inner-traits <tt>mute</tt>. 

Avec le comportement des inner <tt>mute</tt> des classes d'images actuelles, <tt>Concrete(I)</tt> revient donc à une torture pure et simple du compilateur, là où un <tt>Exact(I)</tt> autrement plus direct aurait suffi.

'''Par contre''', pour rejoindre Pollux (et Theo ?), on peut imaginer des classes d'images dont le inner <tt>mute</tt> changerait le méta-type d'image (peut-être existent-elles déjà, mais je ne les ai pas trouvées). 
Par exemple : <tt>FunctionalImage2d</tt> (cf exemples de Pollux), pourrait avoir un <tt>mute</tt> ainsi défini:

<syntaxhighlight lang="cpp" line enclose="div">
template<class T>
class FunctionalImage2d : // pouet
{
	//....
	template<class U>
	 struct mute
	 {
		typedef image2d<U> ret;
	 };
};
</syntaxhighlight>

Là, l'utilisation de <tt>Concrete(I)</tt> au lieu de <tt>Exact(I)</tt> aurait un sens (à chaque fois que l'on veut un type d'image avec des vrais pixels). C'est d'ailleurs surement cela que sous-entendent Pollux et Theo.

'''Post-Conclusion'''

Remarque judicieuse de Nicolas Burrus: 
il semble sémantiquement douteux que le "inner" mute d'une <tt>FunctionalImage2d</tt> definisse autre chose qu'un <tt>FunctionalImage2d&lt;U&gt;</tt>. Cela pourrait en effet gener le comportement d'algos utilisant directement <tt>mute</tt> dans le sens courant.

<tt>Concrete(I)</tt> n'aurait donc aucune utilité sous sa forme actuelle ???


En même temps, <tt>mute</tt> ayant généralement pour vocation sous-jacente une modification de typage de données, on peut se questionner sur sa sémantique dans le cas d'éventuelles images "read-only" comme l'exemple <tt>FunctionalImage2d</tt>. Dans ce cas, ne veut-on pas justement un type d'images "read/write" en retour du "inner" mute ?

Seul les concepteurs de cette séparation Concrete/Exact sauront répondre, ou tout du moins exposer leur but premier.