Suivez-nous sur X
|
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z,
ALL
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
0,
A,
B,
C,
D,
E,
F,
G,
H,
I,
J,
K,
L,
M,
N,
O,
P,
Q,
R,
S,
T,
U,
V,
W,
X,
Y,
Z
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
Dossier : Le format IFF ILBM
(Article écrit par OK et Cancel et extrait d'Amiga News Tech - octobre 1989)
|
|
Comme vous le savez sans doute, le format IFF a été développé par Electronic Arts à la demande de Commodore Amiga, afin
de créer un standard pour la communication des données entre les différents logiciels. Il fut conçu par sept
personnes : Bob Burns (Commodore-Amiga), RJ Mical (Commodore-Amiga), Jerry Morrison (Electronic Arts), Greg Riker
(Electronic Arts), Steve Shaw (Electronic Arts), Dan Silva (Electronic Arts) et Barry Walsh (Commodore-Amiga).
Il fut réalisé le 14 janvier 1985, soit durant le processus de développement de la machine.
Ce format inclut en fait non seulement les dessins bitmap créés à l'aide de
programmes comme Deluxe Paint, mais aussi les textes, musiques, sons échantillonnés, etc.
Les quatre premiers octets d'un fichier IFF contiennent toujours la valeur "FORM" (codée en ASCII, bien sûr).
Une forme en IFF sert justement à différencier les blocs de données contenus dans le fichier (et nommés "chunks").
Plusieurs formes peuvent être mises à la suite dans un même fichier. On trouve ensuite un mot long (4 octets encore)
contenant la longueur de cette forme, exprimée en octets. Dans le cas d'un fichier IFF ne contenant qu'une
seule forme, ce mot long sera égal à la taille du fichier moins quatre. Un fichier IFF minimum aura donc une
taille de huit octets : 4 pour "FORM" et 4 autres pour la taille (0).
Suit alors un mot long (à nouveau 4 octets) indiquant le type du bloc de données. Il s'agit d'un mot de
quatre lettres ASCII, qui peut être :
- ILBM (InterLeaved BitMap) : graphique.
- PBM (Planar BitMap): graphique.
- WORD : texte.
- SMUS : musique.
- 8SVX : échantillon sonore 8 bits.
- ANIM : animation.
- etc.
Ce mot long est immédiatement suivi du nom du bloc de données à venir (4 octets) et de sa longueur (4
autres octets). Il existe à l'heure actuelle beaucoup de noms de blocs de données possibles, mais voici
toujours ceux que l'on peut trouver dans un fichier ILBM (pas forcément dans l'ordre !) :
- BMHD (BitMap HeaDer) : caractéristiques du dessin.
- CMAP (Color Map) : table des couleurs.
- BODY (corps) : données des plans de bits du dessin.
- CAMG (Commodore AMiGa) : mode de représentation.
- SPRT (SPRiTe) : l'image est un sprite.
- TINY (petit) : contient un petit aperçu d'une image.
On peut également trouver les blocs de données "NAME" et "AUTH" qui contiennent respectivement les
noms de l'oeuvre et de son auteur.
Voici maintenant la description du contenu de chacun de ces blocs de données. N'oubliez pas que le nom
d'un bloc de données est toujours suivi de sa longueur, exprimée sur un mot long, et non prise en
compte dans les décalages donnés :
Chunk BMHD
| Décalage |
Taille |
Signification |
| +0 |
1 mot |
Largeur du dessin |
| +2 |
1 mot |
Hauteur du dessin |
| +4 |
1 mot |
Position X du dessin dans la page |
| +6 |
1 mot |
Position Y du dessin dans la page |
| +8 |
1 octet |
Nombre de plan de bits |
| +9 |
1 octet |
Masquage :
0 = pas de masque
1 = masquage
2 = transparent
3 = lasso |
| +10 |
1 octet |
Compression :
0 = pas de compression
1 = compression "ByteRun1" |
| +11 |
1 octet |
Inutilisé |
| +12 |
1 mot |
Numéro de registre de couleur du fond |
| +14 |
1 octet |
Aspect X |
| +15 |
1 octet |
Aspect Y |
| +16 |
1 mot |
Largeur de la page source |
| +18 |
1 mot |
Hauteur de la page source |
Chunk CMAP (pour chaque couleur)
| Décalage |
Taille |
Signification |
| +0 |
1 octet |
Valeur du rouge |
| +1 |
1 octet |
Valeur du vert |
| +2 |
1 octet |
Valeur du bleu |
Chunk CAMG
| Décalage |
Taille |
Signification |
| +0 |
1 long |
Mode de représentation selon OpenScreen() |
Chunk BODY
| Décalage |
Taille |
Signification |
| +0 |
Taille |
Données des plans de bits, compressées ou non
selon le BMHD. Les plans de bits sont disposées
les uns à la suite des autres |
Faites attention à ce qu'un bloc de données doit toujours être d'une longueur paire dans le
fichier. Par exemple, dans un bloc de données CMAP avec une seule couleur, la longueur utile du bloc de données,
celle exprimée tout de suite après son nom, serait 3, mais sa longueur véritable dans le
fichier serait 4.
L'algorithme de compression utilisé porte le nom de "ByteRun1". Il est basé sur le
principe du comptage des octets identiques. Pour le décoder, il faut lire un octet,
et comparer sa valeur à 128 :
- S'il est inférieur à 128, il faudra lire autant d'octets dans le BODY et les afficher tels quels à l'écran.
- S'il est supérieur à 128, l'octet suivant dans le BODY sera répété (257 -octet) fois à l'écran.
- Enfin, une valeur égale à 128 indique... qu'il ne faut rien faire du tout !
On passe ensuite à l'octet suivant, et ainsi de suite jusqu'à la fin du fichier.
|
