Ce tutoriel a été retiré de la bêta-zone par un validateur ou un administrateur car il ne satisfait pas aux règles de publication en bêta-test. Pour de plus amples informations sur les règles de publication en bêta-test, reportez-vous à ce sujet.

En somme : Ce tuto.. ..ne sortira pas en tuto, c'est un brouillon pour un topic qui sortira sur un des forums (autres langages)
Dans le cadre des exercices pour débutants (en C, à la base)

http://www.siteduzero.com/forum-83-742 [...] nts-en-c.html

Previously :

Lucas :

Lien sur le format BMP.

Sylafrs :

Ah, désolé, lucas ^^"
Je vois que tu es en train de faire la fusion, je vais éviter de toucher au texte en attendant
==> vu que je vois pas trop de changement, je continue dans une autre partie
==> j'ai rajouté la partie

Tosh :

Du coup, ça ne sera pas un exo pour Autres langages ?

Sylafrs :

=> Bah, je pense que c'est possible, si..
Ce n'est pas parce que j'ai mis du C que l'on ne peut pas le faire avec d'autres langages;

Partie 1) Fichiers structurés
Partie 2) Algorithmie graphique
Partie 3) Fichiers structurés (apprentissage d'un format .bmp)
Partie 4) Programmation graphique

Maëlan

Quelques questions et remarques :
− C’est possible un nombre magique de 4 bytes ?
− À quoi sert le dernier champ de l’en-tête (nombre de bits par composante) ?
− Les lignes de l’image sont décrites de gaut en bas ou de bas en haut ? Il faudrait le préciser. Il faudrait aussi préciser d’autres détails sur le format : les valeurs possibles pour le nombre de bits par pixel, s’il y a du padding éventuel à la fin des lignes, le boutisme utilisé, si les sections sont « collées » ou s’il y a de l’espace… Vu que c’est du binaire, il faut être ultra-précis, au bit près.
− D’ailleurs, est-ce que vous rajoutez qu’il faut gérer le boutisme ? C’est nécessaire pour la portabilité (si les Zéros s’échangent leurs images), mais ça complique les choses.
− Il y a une erreur dans le prototype en C de getPixel : il manque dans les paramètres l’image à examiner !

Sylafrs

Citation

C’est possible un nombre magique de 4 bytes ?

Déjà fait : zBmp est sur 4 octets

Citation

À quoi sert le dernier champ de l’en-tête (nombre de bits par composante) ?

Pour la palette. Exemple : si on met 8, la couleur sera sur 4*8 = 32 bits

Citation

Les lignes de l’image sont décrites de gaut en bas ou de bas en haut ? Il faudrait le préciser.

Haut -> Bas, Gauche -> Droite

Citation

les valeurs possibles pour le nombre de bits par pixel

On supposera les valeurs qui ne sont pas dans la palette comme étant blanc transparent ?

Citation

s’il y a du padding éventuel à la fin des lignes, le boutisme utilisé

Erf, là c'est du chinois pur pour moi ^^"

si tu parles de l'endianess pour le boutisme, bah je suppose que l'on va faire selon le langage binaire "lisible", genre : 0010 = 2

si tu parles d'un flag pour signaler la fin d'une ligne pour le padding : on spécifie la taille d'une ligne, donc c'est inutile

Citation

si les sections sont « collées » ou s’il y a de l’espace… Vu que c’est du binaire

Pas d'espace : c'est du binaire, en même temps

Citation

Il y a une erreur dans le prototype en C de getPixel : il manque dans les paramètres l’image à examiner !

Bien vu

Désolé pour le message ici, j’avais pas vu ça.

Citation : SylafrsOne

Citation

C’est possible un nombre magique de 4 bytes ?

Déjà fait : zBmp est sur 4 octets

Je demandais si c’était autorisé. Apparemment ça n’a pas de taille fixe et réglementaire, oublie ma question.

Citation : SylafrsOne

Citation

les valeurs possibles pour le nombre de bits par pixel

On supposera les valeurs qui ne sont pas dans la palette comme étant blanc transparent ?

Euh… Je voulais dire, quelles valeurs notre petit format autorise-t-il pour le champ « nombre de bits par pixel » : 4, 8, 16, 32… Il ne faut pas qu’on puisse y mettre n’importe quoi (par exemple, 3 ce serait vraiment pas une bonne idée).


Pour le padding à la fin des lignes : le format BMP dit que le nombre d’octet des lignes doit être un multiple de 4 (plus pratique pour l’alignement). Si ce n’est pas le cas, on rajoute des octets de padding (« bourrage » en français) exprès. Ceux-ci ne contiennent pas d’informations et sont ignorés, ils servent juste à aligner les données.

Pour le boutisme : effectivement, je parlais de l’endianness (little ou big principalement). Vu qu’elle varie d’un ordi à l’autre, les formats de fichier doivent en imposer un pour qu’on puisse s’échanger les fichiers créés sans problème de compatibilité. Par exemple, le format BMP dit que toutes les données doivent être codées en little-endian.
Gérer ça pose une difficulté supplémentaire. Si on veut du big et que notre machine est en big, on n’aura pas de problème ; par contre, si notre machine est en little, il faudra tout inverser à la lecture du fichier et à son écriture…

Citation : SylafrsOne

Citation

si les sections sont « collées » ou s’il y a de l’espace… Vu que c’est du binaire

Pas d'espace : c'est du binaire, en même temps

Ça n’empêche pas. On pourrait par exemple laisser des octets de padding entre la palette et les pixels pour avoir un certain alignement (et pour permettre d’agrandir la palette sans devoir tout décaler).

Y'a aucun intérêt à donner la représentation binaire d'un fichier, c'est absolument indigeste. Donne-le en hexadécimal plutôt.

On peut forcer le nombre de bits possibles (divisible par 4)

Pour le coup, pour l'alignement, on pourrait faire en sorte que chaque ligne termine un octet (padding de 4 uns si le nombre n'est pas divisible par 8)

Pour l'endianness, je ne sais lequel est le mieux..

==> Pour l'hexa : oky
(même si je préfère le binaire :p)

C’est bien mieux en hexa.

OK pour le nombre de bits par pixel qui est un multiple de 4.
Le nombre de couleurs de la palette est calculée en fonction de ça (2ⁿ, ou 0 si le nombre de bits par pixel est ≥ 16) ? Au fait, je ne sais pas si le champ « nombre de bits par composante » pour la palette est une bonne idée. Ce serait plus simple de dire qu’une entrée prend 4 octets, un pour chaque composante RVBA.

Pour le padding, effectivement, c’est préférable que les lignes utilisent un nombre entier d’octets.
Pour le boutisme, on n’a qu’à laisser tomber (ou rajouter son support dans un niveau à part du genre « Allons plus loin »). C’est trop compliqué si on doit en plus expliquer en quoi ça consiste.

Je veux bien me charger de rédiger la partie sur l’exportation en BMP.

Bah, je pensais que ce serait plus simple
Pour le nombre de couleurs de la palette, je pense qu'il faudra ajouter une entrée pour le coup..

Si on a un header comme ça, c'est bon ?

OFFSET   TAILLE  DESCRIPTION
0        4       Nombre magique du fichier à définir. (zBmp)
4        2       Nombre de pixels par ligne (i.e. : largeur)
6        2       Nombre de couleurs
8        2       Nombre de semi-octets par pixels.
10       2       Nombre de bits pour une composante de couleur.

Perso, je préfère mettre dans le header des informations comme celles-ci plutot que "Nombre de bits pour une couleur" : ça implique de devoir faire des calculs et, en plus, l'entier sera plus long...

C'est pour ça que ces données semblent bizarre à première vue
(ouais, je sais "Nombre de semi-octets", c'est pas très classe ^^)

====================

Est-ce que ce sera nécessaire d'indiquer le nombre de lignes (la hauteur) ?
(en fait, oui, que si l'on souhaite éviter une première lecture si on fait de la memalloc)

OFFSET   TAILLE  DESCRIPTION
0        4       Nombre magique du fichier à définir. (zBmp)
4        2       Nombre de pixels par ligne (i.e. : largeur)
6        2       Nombre de lignes de pixels (i.e. : longueur)
8        2       Nombre de couleurs
10       2       Nombre de semi-octets par pixels.
12       2       Nombre de bits pour une composante de couleur.
14       2       L'entrée utilisée pour le bourrage

OK pour le nombre de « semi-octets ». (quoique, ça complique les calculs, alors que vérifier si le nombre de bits est multiple de 4 est facile à faire).

Citation : SylafrsOne

Bah, je pensais que ce serait plus simple
[…]
Perso, je préfère mettre dans le header des informations comme celles-ci plutot que "Nombre de bits pour une couleur" : ça implique de devoir faire des calculs et, en plus, l'entier sera plus long...

Moi, je trouve que c’est encore plus simple de ne pas mettre de champ pour ça et de fixer la taille des couleurs de la palette (4 octets). Ça fait encore moins de calculs et de vérifications.

Bien sûr qu’il faut indiquer la hauteur. C’est beaucoup plus simple (ce n’est pas toi qui parlais d’économiser des calculs ?).

C’est quoi, l’« entrée utilisée pour le bourrage » ?

Sinon, le reste du header me va.

Il faudrait dire quand il doit y avoir une palette et quand il ne doit pas y en avoir. Si les pixels font 32 bits par exemple, on n’en utilise pas, on stocke directement la couleur dedans. En revanche, s’ils n’en font que 4, alors là oui.

le padding (pour le bourrage ^^")
-> en fait, je pense pas que ce sera lu, mais en gros, si notre header est laissé tel quel, il faudra lui ajouter quelques zéros pour rendre le nombre d'octets rond...

Nombre de semi-octets par pixels.
-> Lors de l'élaboration du fichier, c'est nous qui choisissons, donc pas trop de calculs
-> Lors de la lecture, on a juste à faire une multiplication *4 pour le bpp, je vois pas où est le problème; et ça économise

Citation : SylafrsOne

le padding (pour le bourrage ^^")
-> en fait, je pense pas que ce sera lu, mais en gros, si notre header est laissé tel quel, il faudra lui ajouter quelques zéros pour rendre le nombre d'octets rond...

Tu avais pourtant dit que les différentes parties seraient « collées » sans espace ?

Citation : SylafrsOne

Nombre de semi-octets par pixels.
-> Lors de l'élaboration du fichier, c'est nous qui choisissons, donc pas trop de calculs
-> Lors de la lecture, on a juste à faire une multiplication *4 pour le bpp, je vois pas où est le problème; et ça économise

OK. Je pensais surtout aux calculs pour le nombre maximal de couleurs dans la palette, mais en fait ce n’est pas si terrible. J’ai rien dit.

Citation

Tu avais pourtant dit que les différentes parties seraient « collées » sans espace ?

Me suis emmele les pinceaux
J'ai confondu Bit et Byte ^^"

je ne sais pas pourquoi, je voulais mettre le nombre d'octets du header divisible par 4 ^^"

Donc :

OFFSET   TAILLE  DESCRIPTION
0        4       Nombre magique du fichier à définir. (zBmp)
4        2       Nombre de pixels par ligne (i.e. : largeur)
6        2       Nombre de lignes de pixels (i.e. : longueur)
8        2       Nombre de couleurs
10       2       Nombre de semi-octets par pixels.
12       2       Nombre de bits pour une composante de couleur.

Au fait, je préfère « zBMP » à « zBmp ».

(Comme tu as pu voir, j’ai commencé la rédaction de la partie sur l’exportation en BMP.)

oky

Je pense avoir fini la partie sur l’export en BMP.

Si quelqu’un qui s’y connait pouvait relire pour vérifier que je ne dis pas de bêtises, que je n’oublie pas des détails, etc. Ça serait sympa.

ToDo list :

masque binaire

Composante Alpha :

elle doit cependant toujours valoir 0 car le BMP ne gère pas la transparence.
=> Que se passe t-il si elle ne vaut pas 0 ?
=> On ne fait lire que les trois premières composantes, non ?
=> Alors où est le problème ?

Citation : SylafrsOne

ToDo list :

masque binaire

Ah oui, j‘avais oublié.

Après le reste, c’est de la mise en forme. Pour les retours à la ligne, c’était pour ne pas avoir un tableau trop large, ce qui ferai moche, mais après coup j’ai rajouté les champs « Palette » et « Bitmap »… Sinon, j’aime bien les titres à gauche.
Pourquoi tu veux virer le « pour notre exercice » ? Je l’avais écrit pour avertir que ce suit ne présente pas de façon complète le format, mais juste ce qu’il faut savoir pour les besoins de l’exo.

Citation : SylafrsOne

Composante Alpha :

elle doit cependant toujours valoir 0 car le BMP ne gère pas la transparence.
=> Que se passe t-il si elle ne vaut pas 0 ?
=> On ne fait lire que les trois premières composantes, non ?
=> Alors où est le problème ?

À vrai dire, je ne sais pas. Le format dit que cette composante doit valoir 0, donc autant le respecter (il faut bien leur donner une valeur). Peut-être que des programmes qui lisent le BMP détecteront le fichier comme invalide si le byte ne vaut pas 0.


Sinon, c’est bien ?

Ouais, t'as du galérer à faire ça
en plus, j'ai pas déceler décelé de faute du tout

Edit : en parlant de fautes

Ah, j’avais pas vu que tu avais édité le truc. Bon ben, c’est aussi bien comme t’as fait en fait. Plus qu’à expliquer pour le masque binaire, je le ferai une autre fois.

Je peux m'en occuper, si tu veux.
Au final c'est pas grand chose : c'est ce qui indique les bits que l'on utilise pour telle ou telle composante dans la couleur..
Je pourrais à la limite rediriger sur l'utilisation des masques par exemple pour l'IP ou bien sur un tuto sur les opérations logiques

Pas besoin de ça, je pense. Cet exo s’adresse à un certain niveau, ceux qui le font devraient déjà connaître.

Mais ça doit être un peu compliqué d’expliquer les masques binaires du format BMP, parce que c’est une section optionnelle qui remplace la palette, et en plus il faut mettre la valeur 3 au champ « compression ». Rien de très compliqué, mais il faut revoir la présentation.
Et il faut vérifier pour le mode 32 bits par pixel, parce que je crois qu’il ne peut s’utiliser qu’avec un masque binaire lui aussi.

Édit : bah, en fait, je m’en suis chargé. J’ai aussi fusionné nos deux versions.

Alors, on le publie ?
NB : désolé

Je sais pas. Je pense qu’il faudrait rajouter un peu plus de détails, surtout à propos de la description du format zBMP (comment est codée la palette, les couleurs, etc.). Je peux m’en charger maintenant si tu veux, pour pouvoir le publier rapidement.
Pour les différents niveaux, on les lâche un peu dans la nature sans beaucoup de précisions, mais bon ça peut être bien aussi de les laisser se débrouiller.

Je le verrais plutôt dans la catégorie défis que exercices.

Non, je pense que c'est à la portée des débutants
C'est juste un exercice un peu plus compliqué
Et puis.. ..y'aura toujours le topic du forum et le forum lui-même pour aider

Pour moi, l'étape la plus compilquée, est la deuxième, si on veut un algo efficace
Voir la 3ème, mais on tu as bien détaillé, alors

Citation : SylafrsOne

Non, je pense que c'est à la portée des débutants
C'est juste un exercice un peu plus compliqué
[…]

Ouais… donc un défi !

D'après ce que j'ai vu, le défi, c'est "je te donne l'énoncé : "fait ça." et tu te démerdes"

Enfin, d'après ce que j'ai vu

Citation : SylafrsOne

En somme : Ce tuto.. ..ne sortira pas en tuto, c'est un brouillon pour un topic qui sortira sur un des forums (autres langages)
Dans le cadre des exercices pour débutants (en C, à la base)

Heu, non.
Les tutos et les bêtas ne sont pas fait pour ça.

Je ferme.