Discussion :

[Melem]

Bonjour tout le monde.

Grâce à la spec donnée par koala01 dans cette discussion, j'ai pu écrire une ébauche de ce que seraient nos classes couleur :

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
#ifndef H_FARFELUE_COLORS_H
 
#define H_FARFELUE_COLORS_H
 
template <typename color_value_type>
class Color
{
    typedef color_value_type value_type;
 
private:
    value_type value_;
 
public:
    Color(value_type value) { value_ = value; };
    virtual value_type get_value_() const { return value_; };
};
 
enum color1_value_type { COLOR1_BLACK, COLOR1_WHITE };
 
typedef Color<color1_value_type> Color1;
typedef Color<unsigned char> Color8;
 
class Color24 : public Color<unsigned int>
{
public:
    Color24(value_type value) : Color<value_type>(value) { };
    unsigned char red() const { return unsigned char(get_value_()); };
    unsigned char green() const { return unsigned char(get_value_() >> 8); };
    unsigned char blue() const { return unsigned char(get_value_() >> 16); };
};
 
class Color32 : public Color24
{
public:
    unsigned char alpha() const { return unsigned char(get_value_() >> 24); };
};
 
#endif

La présence d'un accesseur get_value_ dans la spec suggère que value_ doit être privé ou protégé, or pourquoi le protègerait-on ? N'est-il pas plus logique de le mettre en public car l'utilisateur devrait pouvoir modifier librement sa valeur ?

La question est donc : dois-je continuer avec value_ en private ou plutôt le muter en public ?

Merci.

[minnesota]

La présence d'un accesseur get_value_ dans la spec suggère que value_ doit être privé ou protégé, or pourquoi le protègerait-on ? N'est-il pas plus logique de le mettre en public car l'utilisateur devrait pouvoir modifier librement sa valeur ?

La question est donc : dois-je continuer avec value_ en private ou plutôt le muter en public ?

Merci.

Salut,

En faite, le diagramme auquel tu fais allusion est une ébauche ! Et tu viens de faire une ébauche d'ébauche. Je pense que tu peux t'accorder un regard plus critique et dire déjà si le diagramme te convient. En somme si tu vois des améliorations possibles.

<edit>Le problème que l'on rencontre dans ce projet, c'est qu'il n'y a pas de débats sur ce qui est déjà fait, du coup y'a des parcelles qui émergent, mais sans véritable cohésion.</edit>

[koala01]

Salut,

Selon moi, Color32 ne devrait pas hériter de... Color24, malgré la part commune importante

Il est d'ailleurs pas utile de faire hériter les différents types de couleur d'un type de base, fusse-t-il template, car Color2, Color24 et Color32 seront en réalité... des traits de politiques

Nous pouvons donc avoir quelque chose comme

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
class Color2
{
    /*...*/
};
class Color24
{
    /*...*/
};
class Color32
{
    /*...*/
};
 
template<class C>
class MaClass
{
    public:
        typedef C color_type;
        MaClass(color_type const & c)
    /*...*/
};
void foo()
{
    MaClass<Color2> obj(Color2(Color2::white));
}

En effet, tu dois te dire que, soit travailler en noir et blanc, soit en tons de gris, soit en couleur vraies (sans transparence), soit en couleur vraies (avec transparence), mais qu'il n'y a, a priori, aucune raison de faire cohabiter ces différents types de couleurs

Pour ce qui est du membre value_:

1- il faut, il est vrai, un accesseur, mais, je ne crois pas qu'il faille un mutateur, simplement, parce que j'envisage plus facilement de demander de créer un nouvel objet de type couleur que... de modifier cet objet: Après tout, si deux couleurs ne venaient, d'une manière ou d'une autre, à ne différer que par un seul bit, il s'agirait réellement de... deux couleurs différentes

2- Il est nécessaire de permettre de récupérer séparément les différentes valeurs (rouge, vert, bleu (, transparence) )

transformer la visibilité de value_ en public aurait pour résultat d'inciter l'utilisateur à effectuer lui-même le calcul, avec tous les risques qui pourraient en résulter:

• quid s'il effectue (par mégarde) le calcul sur... le membre lui-même
• quid s'il... n'utilise pas la logique correcte pour calculer les différentes valeurs

Enfin, une petite précision concernant l'énumération white et black:

• L'énumération devrait être imbriquée dans la classe... Color2 et devrait être une énumération anonyme
• Les valeurs énumérées ne sont normalement pas écrites en majuscules (elles sont normalement préfixées des initial de l'énumération, mais, comme il s'agit d'une énumération anonyme... )

[minnesota]

Koala01 a introduit un Color2 mais je crois qu'il pensait à voix haute, style 2 couleurs, c'est à dire Color1.

J'ai fait une petite synthèse sur les types de couleurs susceptibles d'être intéressants dans le cadre du projet, un genre de référentiel assez simple, sous forme schématique :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
Color1  | 01 bit  -> Monochrome         (2 tons)
Color2  | 02 bits -> Grayscale2         (4 tons)

Color3  | 03 bits -> RGB3               (8 couleurs vraies)

Color4  | 04 bits -> Grayscale4         (16 tons)
                  -> FullCGA/EGA4/VGA4  (16 couleurs)
                  -> RGBI               (8 couleurs vraies / 16 tons) (R1G1B1 - last bit for intensity)

Color8  | 08 bits -> Grayscale8         (256 tons)
                  -> VGA8/SuperVGA      (256 couleurs vraies)
                  -> ~RGB8              (256 couleurs vrais) (R3G3B2)

Color15 | 16 bits -> RGB15/Highcolor15  (32768 couleurs vraies) (R5G5B5 - last bit ignored)
Color15 | 16 bits -> RGB15+/Highcolor15+(32768 couleurs vraies) (R5G5B5 - last bit set to alpha channel)

Color16 | 16 bits -> RGB16/Highcolor16  (65536 couleurs vraies) (R5G6B5)

Color24 | 24 bits -> RGB24/Truecolor    (16777216 couleurs vraies) (R8G8B8)

Color30 | 32 bits -> RGB30/Hicolor      (1073741824 couleurs vraies) (R10G10B10 - last bits ignored)

Color32 | 32 bits -> RGB24+             (16777216 couleurs vraies) (R8G8B8 - last bists for Alpha_channel,Z-buffer or Bump mapping)

Pour plus de détails, vous pouvez consulter les sources que voici :

http://en.wikipedia.org/wiki/Color_depth
http://en.wikipedia.org/wiki/RGB_color_model
http://en.wikipedia.org/wiki/List_of...ttes#6-bit_RGB
http://en.wikipedia.org/wiki/List_of...B_arrangements

Accessoirement:
http://en.wikipedia.org/wiki/Alpha_channel
http://en.wikipedia.org/wiki/Z-buffer
http://en.wikipedia.org/wiki/Bump_mapping

[millie]

Comme dit Minnesota, tu sous-entends que tous les canaux sont de taille 8 bits.
Mais on peut vouloir travailler avec d'autres tailles (rarement vu plus de 32 bits, mais parfois 16 bits) même si les écrans ne peuvent afficher que 8 bits

Mais je dis ça de manière générale, je ne sais absolument pas l'utilité que tu en auras

[koala01]

Koala01 a introduit un Color2 mais je crois qu'il pensait à voix haute, style 2 couleurs, c'est à dire Color1.

J'ai fait une petite synthèse sur les types de couleurs susceptibles d'être intéressants dans le cadre du projet, un genre de référentiel assez simple, sous forme schématique :


Pour plus de détails, vous pouvez consulter les sources que voici :

http://en.wikipedia.org/wiki/Color_depth
http://en.wikipedia.org/wiki/RGB_color_model
http://en.wikipedia.org/wiki/List_of...ttes#6-bit_RGB
http://en.wikipedia.org/wiki/List_of...B_arrangements

Accessoirement:
http://en.wikipedia.org/wiki/Alpha_channel
http://en.wikipedia.org/wiki/Z-buffer
http://en.wikipedia.org/wiki/Bump_mapping

L'avantage des traits de politiques, c'est que l'on peut parfaitement en rajouter selon les besoins par la suite.

Je propose donc de nous limiter à quelques couleurs régulièrement utilisées (monochrome, même si ce serait, effectivement, Color1, 8 bits gris, 24 et 32 bits), quitte à en rajouter par la suite, si le besoin s'en fait sentir

Comme dit Minnesota, tu sous-entends que tous les canaux sont de taille 8 bits.
Mais on peut vouloir travailler avec d'autres tailles (rarement vu plus de 32 bits, mais parfois 16 bits) même si les écrans ne peuvent afficher que 8 bits

Mais je dis ça de manière générale, je ne sais absolument pas l'utilité que tu en auras

Tu n'as pas tord, seulement:

Il est plus facile de gérer les couleurs sur base de leur nombre total de bits pour évaluer la taille de chaque canal que d'essayer de faire le contraire.

Par contre, nous pourrions effectivement envisager une approche mixte, sous une forme proche de

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
class ColorMono
{
    /* aliases de types sur canal_type, value_type et color_type */
   /* valeurs énumérées "On" (1) et "Off" (0) */
};
template<typename Canal>
class TColorGray
{
    /* aliases de types sur canal_type, value_type et color_type */
};
template<typename Value, typename Canal>
class TColorRGB
{
    /* aliases de types sur canal_type, value_type et color_type */
    /* détermination du nombre de bit utilisés par chaque canal */
};
template<typename Value, typename Canal>
class TColorRGBA
{
    /* aliases de types sur canal_type, value_type et color_type */
    /* détermination du nombre de bit utilisés par chaque canal */
};
/* tous les autres types de couleur... qui peuvent attendre avant
 * d'être implémentés
 */

et donc d'avoir quelques typedef (colorRGB_24, colorRGBA_32, ...) pour la facilité, mais cela nécessite, de pouvoir déterminer non seulement le type capable de représenter la valeur elle-même de la couleur, mais aussi... le type capable de représenter la valeur du canal.

Ceci dit, le raisonnement pour obtenir la valeur d'un des canal resterait à chaque fois identique, et s'il est vrai que, pour l'instant, nous travaillons essentiellement avec des canaux 8 bits, cela nous assurerait l'évolutivité de la chose quand... les technologies pousseront à passer à autre chose

[dourouc05]

Ceci dit, le raisonnement pour obtenir la valeur d'un des canal resterait à chaque fois identique, et s'il est vrai que, pour l'instant, nous travaillons essentiellement avec des canaux 8 bits, cela nous assurerait l'évolutivité de la chose quand... les technologies pousseront à passer à autre chose

Quand on commence à jouer avec des rendus HDR

[dourouc05]

Ceci dit, le raisonnement pour obtenir la valeur d'un des canal resterait à chaque fois identique, et s'il est vrai que, pour l'instant, nous travaillons essentiellement avec des canaux 8 bits, cela nous assurerait l'évolutivité de la chose quand... les technologies pousseront à passer à autre chose

Quand on commence à jouer avec des rendus HDR (jeux vidéo, photographie...), on dépasse*forcément les huits malheureux bits disponibles par canaux : en moyenne, on atteint les seize. Certains vont même jusque 24 ou 32, mais ça devient de la folie, on n'est pas encore capables de le rendre quelque part. Les bons réflex numériques atteignent 12 ou 14 bits par canal, ça existe déjà. Je ne sais pas jusqu'où ces classes seront utilisées, si c'est réservé à un usage interne ou pas, mais ça risque d'être assez utile de gérer des canaux de plus de 8 bits.*



Certains écrans sont d'ores et déjà capables d'afficher presque tout le Adobe RGB ou le sRGB. La prochaine étape, c'est une dynamique plus étendue, donc des canaux de plus de 8 bits. Tentez donc au possible d'aller au-delà.*

[millie]

Tu n'as pas tord, seulement:

Il est plus facile de gérer les couleurs sur base de leur nombre total de bits pour évaluer la taille de chaque canal que d'essayer de faire le contraire.

Par contre, nous pourrions effectivement envisager une approche mixte, sous une forme proche de

et donc d'avoir quelques typedef (colorRGB_24, colorRGBA_32, ...) pour la facilité, mais cela nécessite, de pouvoir déterminer non seulement le type capable de représenter la valeur elle-même de la couleur, mais aussi... le type capable de représenter la valeur du canal.

Ceci dit, le raisonnement pour obtenir la valeur d'un des canal resterait à chaque fois identique, et s'il est vrai que, pour l'instant, nous travaillons essentiellement avec des canaux 8 bits, cela nous assurerait l'évolutivité de la chose quand... les technologies pousseront à passer à autre chose

Enfin je dis ça. Mais faut voir l'utilité réelle de la chose. Ca sert pas forcement à grand chose de se prendre la tête sur quelque chose qui ne sera jamais utilisée et qui peut être énormément simplifiée.

[minnesota]

Salut millie,

Mais je dis ça de manière générale, je ne sais absolument pas l'utilité que tu en auras

Avant ce projet de faire une interface homme-machine il y a eu une lon...gue discussion. Mais heureusement pour toi, il y a une synthèse qui t'aidera à savoir de quoi il s'agit exactement.

Peut-être devrait-elle être épinglée.

Sinon, en ce qui concerne cette discussion en particulier, elle fait référence à celle traitant des diagrammes de classes, notamment le diagramme 1 (fig128002.png)

salut dourouc05

La prochaine étape, c'est une dynamique plus étendue, donc des canaux de plus de 8 bits. Tentez donc au possible d'aller au-delà.*

Sur 32bits, on peut déjà monter jusqu'à 10bits par canal, soit au minimum un milliard de couleurs vraies garanties. En terme de définition c'est largement supérieur à la capacité de l'œil humain. Vouloir aller au-delà ce serait presque inutile.

L'avantage des traits de politiques, c'est que l'on peut parfaitement en rajouter selon les besoins par la suite.

Je propose donc de nous limiter à quelques couleurs régulièrement utilisées (monochrome, même si ce serait, effectivement, Color1, 8 bits gris, 24 et 32 bits), quitte à en rajouter par la suite, si le besoin s'en fait sentir

Moi ça ne me pose aucun problème tant qu'on intègre ma palette de 16 couleurs

[dourouc05]

Sur 32bits, on peut déjà monter jusqu'à 10bits par canal, soit au minimum un milliard de couleurs vraies garanties. En terme de définition c'est largement supérieur à la capacité de l'œil humain. Vouloir aller au-delà ce serait presque inutile.

Justement, l'oeil humain perçoit une dynamique des milliards de fois supérieures à ce que le numérique peut entrapercevoir. Regarde une façade claire avec une fenêtre donnant sur une pièce plus sombre : toi, tu ne verras pas soit le blanc de la façade soit le noir de la pièce, ce sera des détails un peu partout, ce qui correspond à une dynamique d'environ 16 bits (évaluation basée sur la photo : tu as besoin d'une dynamique de 16 bits pour avoir des détails dans les basses et hautes lumières).*


Le problème, sur ces 32 bits, c'est qu'apparemment il n'est prévu que de mettre des canaux de 8 bits, ce qui est plus que suffisant actuellement. Sur 32 bits, tu peux bien mettre deux canaux de 12 et un de 8 bits, par exemple, à condition que ce soit prévu.*

[koala01]

Quand on commence à jouer avec des rendus HDR (jeux vidéo, photographie...), on dépasse*forcément les huits malheureux bits disponibles par canaux : en moyenne, on atteint les seize. Certains vont même jusque 24 ou 32, mais ça devient de la folie, on n'est pas encore capables de le rendre quelque part. Les bons réflex numériques atteignent 12 ou 14 bits par canal, ça existe déjà. Je ne sais pas jusqu'où ces classes seront utilisées, si c'est réservé à un usage interne ou pas, mais ça risque d'être assez utile de gérer des canaux de plus de 8 bits.*

Je suis peut-être buté, mais, comme je l'ai déjà dit, l'idée est, avant tout, de fournir une bibliothèque IHM...

Le rendu d'images utilisant des canaux de plus de 8 bits et/ ou d'animations HDR, s'il peut être envisagé, ne devra l'être que dans le cadre de l'intégration de ces technologies à titre de plugins.

J'ai montré la possibilité de se donner la capacité d'intégrer cela par la suite, mais il faut se dire que ces capacités seront principalement intéressantes... lorsque l'on présentera une... façade permettant d'utiliser ces technologies

Certains écrans sont d'ores et déjà capables d'afficher presque tout le Adobe RGB ou le sRGB. La prochaine étape, c'est une dynamique plus étendue, donc des canaux de plus de 8 bits. Tentez donc au possible d'aller au-delà.*

Comme je viens de le démontrer, il est possible et intéressant de l'envisager et de le prévoir.

Mais il faut, malgré tout, garder le principe YAGNI en tête et, tout en prévoyant le coup, il ne me semble pas vraiment opportun de commencer à... implémenter réellement ces possibilités étendues dans l'immédiat (d'autant plus qu'il sera toujours possible à l'utilisateur, même s'il doit être "plus expérimenté" de définir ses propres classes de couleur RGB )

[koala01]

Moi ça ne me pose aucun problème tant qu'on intègre ma palette de 16 couleurs

Il faut, cependant, être bien conscient du fait que la plus petite unité de valeur représentable à l'exception du bit est... le byte, qui fait classiquement 8 bits, et qui autorise donc...256 valeurs possibles.

A partir de là, tu peux t'organiser comme bon te semble pour représenter ta palette de 16 couleurs:

Soit, te base sur le fait que quatre bits suffisent pour les représenter pour estimer que un byte représente... deux pixels

Soit tu défini une suite de 16 valeurs différentes dans l'intervalle autorisé par le byte qui seront utilisées à l'exception de toute autre.

Qui peut le plus peut le moins

[koala01]

Justement, l'oeil humain perçoit une dynamique des milliards de fois supérieures à ce que le numérique peut entrapercevoir. Regarde une façade claire avec une fenêtre donnant sur une pièce plus sombre : toi, tu ne verras pas soit le blanc de la façade soit le noir de la pièce, ce sera des détails un peu partout, ce qui correspond à une dynamique d'environ 16 bits (évaluation basée sur la photo : tu as besoin d'une dynamique de 16 bits pour avoir des détails dans les basses et hautes lumières).*


Le problème, sur ces 32 bits, c'est qu'apparemment il n'est prévu que de mettre des canaux de 8 bits, ce qui est plus que suffisant actuellement. Sur 32 bits, tu peux bien mettre deux canaux de 12 et un de 8 bits, par exemple, à condition que ce soit prévu.*

N'oubliez pas, messieurs, que la résistance maximale d'une chaine n'est jamais que... celle de son maillon le plus faible.

Ici, le maillon faible réside... dans la taille du byte, qui est classiquement de 8 bits (et des autres types primitifs).

On dispose d'une certaine marge de manœuvre dans le sens où un type donné dont la taille est de deux byte (16 bits) permet fatalement de représenter des valeurs codées sur... 12 bits, mais il ne me semble pas vraiment opportun de commencer à se disputer sur ces points, alors que la forme même des différentes possibilités de couleurs n'est pas encore fixée.

On pourrait, aussi, s'abstraire de la notion même de rouge, vert, bleu et transparence, en envisageant en priorité le nombre de canal et le nombre de bit par canal et en accédant au premier, second, troisième ou quatrième canal selon le besoin.

Cependant, le problème sera, si on ne force pas l'utilisateur à choisir le type permettant de représenter l'ensemble des canaux d'une couleur, à déterminer celui-ci sur base du nombre de canal et du nombre de bits par canal, et, si on force l'utilisateur à définir le type permettant de représenter l'ensemble des canaux d'une couleur, le nombre de canaux et le nombre de bits par canal, de s'assurer que le type sélectionné est, effectivement, capable de représenter la palette complète

Je ne demande pas mieux que de pousser l'étude le plus loin possible, mais je voudrais également éviter d'avoir à nous faire du mal pour rien

[minnesota]

Il est plus facile de gérer les couleurs sur base de leur nombre total de bits pour évaluer la taille de chaque canal que d'essayer de faire le contraire.

Par contre, nous pourrions effectivement envisager une approche mixte, sous une forme proche de

Code c++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
class ColorMono
{
    /* aliases de types sur canal_type, value_type et color_type */
   /* valeurs énumérées "On" (1) et "Off" (0) */
};
template<typename Canal>
class TColorGray
{
    /* aliases de types sur canal_type, value_type et color_type */
};
template<typename Value, typename Canal>
class TColorRGB
{
    /* aliases de types sur canal_type, value_type et color_type */
    /* détermination du nombre de bit utilisés par chaque canal */
};
template<typename Value, typename Canal>
class TColorRGBA
{
    /* aliases de types sur canal_type, value_type et color_type */
    /* détermination du nombre de bit utilisés par chaque canal */
};
/* tous les autres types de couleur... qui peuvent attendre avant
 * d'être implémentés
 */

et donc d'avoir quelques typedef (colorRGB_24, colorRGBA_32, ...) pour la facilité, mais cela nécessite, de pouvoir déterminer non seulement le type capable de représenter la valeur elle-même de la couleur, mais aussi... le type capable de représenter la valeur du canal.

Ceci dit, le raisonnement pour obtenir la valeur d'un des canal resterait à chaque fois identique, et s'il est vrai que, pour l'instant, nous travaillons essentiellement avec des canaux 8 bits, cela nous assurerait l'évolutivité de la chose quand... les technologies pousseront à passer à autre chose

On pourrait aussi ajouter une notion de palette, style l'utilisateur choisit sa palette et sélectionne sa couleur conformément au type de la palette. Ce serait une approche plus intuitive selon moi. Qu’en dites-vous ?