Obligement - L'Amiga au maximum

Vendredi 23 mai 2025 - 18:27  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

Actualité (récente)
Actualité (archive)
Comparatifs
Dossiers
Entrevues
Matériel (tests)
Matériel (bidouilles)
Points de vue
En pratique
Programmation
Reportages
Quizz
Tests de jeux
Tests de logiciels
Tests de compilations
Trucs et astuces
Articles divers

Articles in English


Réseaux sociaux

Suivez-nous sur X




Liste des jeux Amiga

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


Trucs et astuces

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


Glossaire

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


Galeries

Menu des galeries

BD d'Amiga Spécial
Caricatures Dudai
Caricatures Jet d'ail
Diagrammes de Jay Miner
Images insolites
Fin de jeux (de A à E)
Fin de Jeux (de F à O)
Fin de jeux (de P à Z)
Galerie de Mike Dafunk
Logos d'Obligement
Pubs pour matériels
Systèmes d'exploitation
Trombinoscope Alchimie 7
Vidéos


Téléchargement

Documents
Jeux
Logiciels
Magazines
Divers


Liens

Associations
Jeux
Logiciels
Matériel
Magazines et médias
Pages personnelles
Réparateurs
Revendeurs
Scène démo
Sites de téléchargement
Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


Dossier : Le format IFF ILBM
(Article écrit par divers auteurs et extrait de Wikipédia - janvier 2025)


Note : article sous licence Creative Commons Attribution 4.0.

Le format ILBM (InterLeaved BitMap) est un format de fichier image conforme à la norme Interchange File Format (IFF). C'est une image bitmap entrelacée avec carte de couleurs. Ce format pour images matricielles est indépendant de la plate-forme, ce fut le format de fichier image standard pour l'Amiga dans les années 1980 et le début des années 1990 (notamment pour les logiciels de dessin et les jeux), et il était également utile dans d'autres environnements informatiques (portages de jeux Amiga, programmes utilisant des ressources graphiques conçues sur Amiga).

Développé par Electronic Arts avec l'aide de Commodore, sa version initiale est sortie le 14 janvier 1985 avec le standard EA IFF 85 mis au point par les personnes suivantes : Bob Burns (Commodore-Amiga), R.J. Mical (Commodore-Amiga), Jerry Morrison (Electronic Arts), Greg Riker (Electronic Arts), Steve Shaw (Electronic Arts), Dan Silva (Electronic Arts) et Barry Walsh (Commodore-Amiga).

Une caractéristique de ce format est qu'il stocke les bitmaps sous la forme de plans de bits entrelacés, ce qui donne son nom au format ; cela reflète la façon dont le matériel graphique Amiga lit nativement les données graphiques à partir de la mémoire. Packbits, une forme simple de compression, est gérée pour rendre les fichiers ILBM plus compacts.

Sur Amiga, ces fichiers ne sont pas associés à une extension de fichier particulière. Mais depuis qu'ils ont commencé à être utilisés sur les systèmes PC, où les extensions sont systématiquement utilisées, l'utilisation des extensions ".iff", ".lbm" ou occasionnellement ".pbm" était de mise.

1. Format de fichier

ILBM est une implémentation du format de fichier IFF composée d'un certain nombre de blocs de données (ou segments, "chunks" en anglais) consécutifs, dont l'ordre peut, dans une certaine mesure, être modifié. Chaque bloc de données a une fonction différente et a le même format de base. Cela signifie qu'un programme n'a pas besoin de lire ou de décoder chaque bloc de données d'un fichier, mais uniquement ceux qu'il souhaite traiter ou ceux qu'il peut comprendre.

Les fichiers ILBM contiennent généralement suffisamment d'informations pour permettre leur affichage par un programme d'édition d'images, notamment les dimensions de l'image, la palette et les données de pixels. Certains fichiers ont été conçus pour servir de palettes pour les programmes de dessin (les données de pixels sont laissées vides) ou pour être fusionnés dans une autre image. Cela les rend beaucoup plus flexibles, mais aussi beaucoup plus complexes que d'autres formats tels que le BMP.

Pour l'ILBM, le bloc de données BMHD (Bit Map HeaDer) et tout autre bloc de données "vital" doivent apparaître avant le bloc de données BODY. Tout bloc de données apparaissant après BODY est considéré comme "supplémentaire" et de nombreux programmes ne les liront pas. Les fichiers dans ce format commencent par la séquence de quatre caractères FORM, suivi de la longueur du fichier, et de l'indicatif ILBM :

Type Nom Description
FOURCC chunkID "FORM"
UINT32BE lenChunk Longueur des données du bloc de données, en octets. N'inclut pas l'octet de remplissage. Sera identique à la taille du fichier moins huit octets (ce champ et chunkID ne sont pas inclus dans le décompte)
FOURCC formatID "ILBM" ou "PBM"
BYTE[lenChunk - 12] content Données réelles du bloc de données, constitué des autres sous-blocs de données ci-dessous
BYTE pad Octet de remplissage facultatif, présent uniquement si "lenChunk" n'est pas un multiple de 2

2. Les blocs de données

2.1 BMHD : Bitmap Header

Le bloc de données BMHD spécifie comment l'image doit être affichée et constitue généralement le premier bloc de données à l'intérieur de FORM. Il définit non seulement la hauteur/largeur de l'image, mais également l'endroit où elle est affichée sur l'écran, comment l'afficher dans différentes résolutions et si l'image est compressée. Le contenu de ce bloc de données est le suivant :

Type Nom Description
UINT16BE width Largeur de l'image, en pixels
UINT16BE height Hauteur de l'image, en pixels
INT16BE xOrigin Où se trouve sur l'écran, en pixels, le coin supérieur gauche de l'image. La valeur est généralement 0,0, sauf si l'image fait partie d'une image plus grande ou n'est pas en plein écran.
INT16BE yOrigin Où se trouve sur l'écran, en pixels, le coin supérieur gauche de l'image. La valeur est généralement 0,0, sauf si l'image fait partie d'une image plus grande ou n'est pas en plein écran.
UINT8 numPlanes Nombre de plans dans le bitmap ; 1 pour monochrome, 4 pour seize couleurs, 8 pour 256 couleurs ou 0 s'il n'y a qu'une carte de couleurs et aucune donnée d'image (c'est-à-dire que ce fichier est juste une carte de couleurs).
UINT8 mask 1=masqué, 2=couleur transparente, 3=lasso (pour MacPaint). Les données de masque ne sont pas considérées comme un plan de bits.
UINT8 compression 0=non compressé. 1=les données d'image sont compressées en RLE. 2="RLE vertical" de Deluxe Paint pour Atari ST. D'autres valeurs sont théoriquement possibles, représentant d'autres méthodes de compression.
UINT8 pad1 Ignoré lors de la lecture, définir sur 0 lors de l'écriture pour une compatibilité future.
UINT16BE transClr Couleur transparente, utile uniquement lorsque mask=2 ou supérieur.
UINT8 xAspect Aspect du pixel, un rapport largeur:hauteur ; utilisé pour afficher l'image sur une variété de résolutions d'écran différentes pour 320x200 5:6 ou 10:11.
UINT8 yAspect Aspect du pixel, un rapport largeur:hauteur ; utilisé pour afficher l'image sur une variété de résolutions d'écran différentes pour 320x200 5:6 ou 10:11.
INT16BE pageWidth La taille de l'écran sur lequel l'image doit être affichée, en pixels, généralement 320×200.
INT16BE pageHeight La taille de l'écran sur lequel l'image doit être affichée, en pixels, généralement 320×200.

2.2 BODY : données d'image

Le bloc de données BODY est généralement le dernier bloc d'un fichier et le plus grand. Dans les fichiers ILBM, le bloc de données BODY stocke les données d'image réelles sous forme de plans de bits entrelacés (et de masque facultatif) par ligne. Les plans de bits apparaissent en premier de 1 à n, suivis du plan de masque. Si l'image n'est pas compressée, chaque ligne sera composée de (width+15)/16 valeurs de 16 bits (c'est-à-dire un bit par pixel, arrondi au multiple de 16 bits le plus proche). Si elle est compressée, chaque ligne est compressée individuellement et est toujours un multiple de 16 bits de long lorsqu'elle est compressée.

Dans les fichiers PBM, le bloc de données BODY est plus simple car non compressé, il s'agit simplement d'un flux continu d'octets contenant des données d'image.

Compression

Si une image est compressée, chaque ligne de données (mais pas chaque plan de bits) est compressée individuellement, y compris les données de masque si elles sont présentes. La compression est une variante de la compression RLE utilisant des drapeaux. Elle peut être décodée comme suit :
  • Boucle jusqu'à avoir [Longueur finale] octets de données (longueur finale calculée à partir de la taille de l'image).
  • Tant que [Longueur des données décompressées] est inférieure à [Longueur finale] :
    1. Lit un octet [Valeur].
    2. Si [Valeur] est supérieur à 128, alors :
      • Lit l'octet suivant et le génère (257-[Valeur]) fois.
      • Avance de deux octets et revient à l'étape 1.
    3. Sinon, si [Valeur] est inférieur à 128, alors :
      • Lit et affiche les [Valeur+1] octets suivants.
      • Avance de [Valeur+2] octets et revient à l'étape 1.
    4. Enfin, si [Valeur]=128, sort de la boucle (arrêt la décompression).
Pour la routine de compression, il est préférable d'encoder une série répétée de deux octets en tant que série répliquée, sauf si elle est précédée et suivie d'une série littérale, auquel cas il est préférable de fusionner les trois en une seule série littérale. Toujours encoder les répétitions de plus de trois octets en tant que répliques.

2.3 CAMG : mode Amiga

Un bloc de données CAMG est spécifiquement destiné à l'Amiga. L'Amiga gère de nombreux modes d'affichage vidéo différents, comme l'entrelacé, l'Extra Half-Brite (EHB), le Hold And Modify (HAM), ainsi qu'une variété de nouveaux modes présents à partir d'AmigaOS 2.0. Un bloc de données CAMG contient un seul mot long (length=4) qui spécifie le mode d'affichage Amiga de l'image. Il permet également de spécifier les modes d'affichage "dual playfield" (double champ de jeu). Ce bloc de données est rare en dehors des jeux Amiga.

Type Nom Description
UINT32BE viewportMode Drapeaux de bits ; interprétés directement par le matériel Amiga.

Si vous devez convertir ou afficher des fichiers susceptibles de contenir des blocs de données CAMG significatifs, consultez les "Notes pour travailler avec l'ILBM" plus loin dans cet article.

2.4 CMAP : palette

Le bloc de données CMAP contient la palette de couleurs de l'image et se compose de valeurs RVB de trois octets pour chaque couleur utilisée. Chaque octet est compris entre 0 et 255 inclus. Ce bloc de données fait 3×numColours octets. Le nombre de couleurs dans la palette sera de 2^numBitplanes. Ce bloc est facultatif et une palette par défaut sera utilisée si elle n'est pas présente. Il est possible d'avoir moins d'entrées que prévu (par exemple, sept couleurs pour un bitmap quatre plans de seize couleurs). N'oubliez pas que s'il y a un nombre impair de couleurs, conformément à la spécification IFF, le bloc de données sera complété d'un octet pour en faire un nombre pair d'octets, mais l'octet de remplissage n'est pas inclus dans le champ de longueur du bloc de données.

2.5 CRNG : gamme de couleurs

Le bloc de données CRNG concerne la gamme de couleurs, c'est un bloc "non standard". Il est utilisé par le programme Deluxe Paint d'Electronic Arts pour identifier une gamme contiguë de registres de couleurs ou une "gamme de nuances" et un cycle de couleurs. Il peut y avoir zéro ou plusieurs blocs de données CRNG dans un fichier ILBM, mais tous doivent apparaître avant le bloc de données BODY. Deluxe Paint écrit normalement quatre blocs CRNG dans un fichier ILBM lorsque l'utilisateur lui demande "d'enregistrer l'image".

Type Nom Description
INT16BE padding 0x0000
INT16BE rate Taux de cycle de couleurs. Les unités sont telles qu'un taux de 60 pas par seconde est représenté par 214=16384. Des taux inférieurs peuvent être obtenus par mise à l'échelle linéaire : pour 30 pas/seconde, le taux est de 8192.
INT16BE flags Drapeaux qui contrôlent le cycle des couleurs dans la palette. Si bit0 est à 1, les couleurs doivent défiler, sinon cette plage de registres de couleurs est inactive et ne doit avoir aucun effet. Si bit1 est à 0, les couleurs défilent vers le haut, c'est-à-dire que chaque couleur se déplace vers la position d'index suivante dans la carte des couleurs et la couleur la plus haute de la plage descend vers la position la plus basse. Si bit1 est à 1, les couleurs défilent dans la direction opposée. Seules les couleurs entre les entrées basse et haute de la carte des couleurs doivent défiler.
UINT8 low L'index de la première entrée de la carte des couleurs qui fait partie de cette gamme.
UINT8 high L'index de la dernière entrée de la carte des couleurs qui fait partie de cette gamme.

2.6 CCRT : cycle de couleurs

Le programme Graphicraft de Commodore utilise le bloc de données CCRT pour la plage et la synchronisation des cycles de couleurs. Ce bloc de données contient une structure CycleInfo. Comme CRNG, il s'agit d'un bloc de données non standard.

Type Nom Description
INT16BE direction Sens du cycle : 0=pas de cycle, 1=vers l'avant, -1=vers l'arrière.
UINT8 low Registre de couleur le plus bas sélectionné.
UINT8 high Registre de couleurs le plus élevé sélectionné.
INT32BE delaySec Secondes entre les changements de couleurs.
INT32BE delayuS Microsecondes entre les changements de couleurs (ajoutées à delaySec pour obtenir le délai total).
INT16BE padding 0x0000

Les données sont similaires à un bloc de données CRNG. Un programme n'utiliserait probablement qu'une seule de ces deux méthodes pour exprimer les données du cycle de couleurs. Vous pouvez écrire les deux si vous souhaitez communiquer ces informations à la fois à Deluxe Paint et à Graphicraft.

2.7 DEST : combinaison de plans de bits

La propriété facultative DEST est un moyen de contrôler la manière dont sont dispersés zéro ou plusieurs plans de bits sources dans une image de destination d'une plus grande profondeur. Certains logiciels peuvent ignorer DEST.

Type Nom Description
UINT8 numPlanes Nombre de plans de bits dans l'image source.
UINT8 pad1 Inutilisé ; utiliser 0 pour la cohérence.
UINT16BE planePick Comment choisir des plans pour les disperser dans l'image de destination.
UINT16BE planeOnOff Données par défaut pour planePick.
UINT16BE planeMask Sélectionne les plans de bits dans lesquels stocker.

Le nombre de bits de faible profondeur d'ordre dans planePick, planeOnOff et planeMask correspond respectivement aux plans de bits de destination : bit 0 avec plan de bits 0, etc. Tous les bits d'ordre supérieur doivent être ignorés.

Les bits 1 dans planePick signifient "placer le plan de bits source suivant dans ce plan de bits", donc le nombre de bits 1 doit être égal à numPlanes. Les bits 0 signifient "placer le bit correspondant de planeOnOff dans ce plan de bits".

Concernant les bits dans la porte planeMask écrivant dans le plan de bits de destination, les bits 1 signifient "écrire dans ce plan de bits" tandis que les bits 0 signifient "laisser ce plan de bits tranquille". Le cas normal (sans bloc DEST) est équivalent à planePick=planeMask=(2^numPlanes)-1.

N'oubliez pas que les numéros de couleur sont formés par des pixels dans le bitmap de destination (plans de profondeur profonds) et non dans le bitmap source (numPlanes plans profonds).

2.8 GRAB : zone réactive

Le bloc de données GRAB optionnel localise une zone réactive ("hotspot") de l'image par rapport à son coin supérieur gauche, par exemple lorsqu'il est utilisé comme curseur de souris ou comme "pinceau". Ce bloc est facultatif.

Type Nom Description
INT16BE x Coordonnée X de la zone réactive, en pixels par rapport au coin supérieur gauche de l'image
INT16BE y Coordonnée Y de la zone réactive, en pixels par rapport au coin supérieur gauche de l'image

2.9 SPRT : ordre de plan ("z-order")

Le bloc de données SPRT indique qu'une image est destinée à être un sprite. Elle doit donc avoir un plan de masque ou une couleur transparente et ne doit pas être en plein écran. La manière dont cela est géré dépend du programme qui utilise l'image. La seule donnée stockée ici est l'ordre des sprites, utilisé par de nombreux programmes pour placer le sprite au premier plan (un sprite d'ordre 1 apparaît derrière un sprite d'ordre 0, etc.). C'est un bloc de données facultatif.

Type Nom Description
UINT16BE order Ordre de plan de l'image (0 est le plus proche du premier plan, les nombres plus grands sont plus éloignés/derrière)

2.10 TINY : miniature

Le bloc de données TINY contient une image miniature d'aperçu pour divers programmes graphiques, dont Deluxe Paint. Il est compressé et son format est similaire à celui du bloc de données BODY.

Type Nom Description
UINT16BE width Largeur de la miniature, en pixels
UINT16BE height Hauteur de la miniature, en pixels
BYTE[] data Données de pixels, stockées exactement de la même manière que le bloc de données BODY. Utilise exactement le même algorithme, mais remplace la largeur et la hauteur du bloc TINY par celles extraites du bloc BMHD.

3. Blocs de données proposés/enregistrés ultérieurement

Le standard IFF ILBM a continué à s'étoffer au fil des ans avec des ajouts ou propositions issus de développeurs tiers.

3.1 ILBM.CLUT : table de correspondance des couleurs

C'est un bloc de données IFF proposé le 2 juillet 1989 par Justin V. McCormick de la société Progressive Peripherals & Software pour son logiciel FG 2.0.

Un "CLUT" (Color Look Up Table - table de correspondance des couleurs) est un module de données à usage spécial contenant une table de 256 entrées de huit bits. Les entrées de cette table peuvent être utilisées directement pour traduire une valeur de huit bits en une autre.

Son objectif est de stocker des tables de correspondance des couleurs huit bits dans un format simple pour une récupération ultérieure. Ces tables sont utilisées pour convertir ou biaiser les registres d'intensité, de contraste, de saturation, de teinte ou de couleur huit bits ou d'autres données similaires de manière reproductible.

Type Nom Description
ULONG type Voir les définitions de type dans le tableau suivant
ULONG res0 Réservé pour une extension future
UBYTE lut[256] La table de correspondance de 256 octets

Définition Description
CLUT_MONO Une table de correspondance monochrome, de contraste ou d'intensité
CLUT_RED Une table de correspondance pour les rouges
CLUT_GREEN Une table de correspondance pour les verts
CLUT_BLUE Une table de correspondance pour les bleus
CLUT_HUE Une table de correspondance pour les teintes
CLUT_SAT Une table de correspondance pour la saturation
CLUT_UNUSED6 Que diriez-vous d'un drapeau de données signées ?
CLUT_UNUSED7 Ou un drapeau négatif présumé ?

3.2 ILBM.CMYK : cyan, magenta, yellow, black

C'est un bloc de données IFF proposé le 29 août 1991 par Dan Weiss, Deron Kazmaier et Gary Knight, pour FORM ILBM et FORM DR2D. Ce bloc de données permettrait de spécifier les couleurs en termes de cyan, magenta, jaune et noir (CMJN ou CMYK en anglais), contrairement au CMAP d'origine qui utilise le RVB. Le format serait le même que celui de la partie CMAP, à l'exception du fait que cette partie utilise quatre composants de couleur au lieu de trois. Le nombre de couleurs contenues dans le bloc de données serait la longueur du bloc/4. Ce bloc serait utilisé en plus du bloc CMAP.

Exemple :

CMYK 		- ID du bloc
000010 		- Longueur du bloc (16 octets, #couleurs=16/4=4)
00 00 00 00 	- Couleur n°1 (c=00, m=00, y=00, b=00)
FF FF 00 00 	- Couleur n°2 (c=ff, m=ff, y=00, b=00)
80 80 FF 10 	- Couleur n°3 (c=80, m=80, y=ff, b=10)
27 C6 AF 0B 	- Couleur n°4 (c=27, m=c6, y=af, b=0b)

3.3 ILBM.CNAM : nommage de couleur

C'est un bloc de données IFF proposé le 29 août 1991 par Dan Weiss, Deron Kazmaier et Gary Knight, pour FORM ILBM et FORM DR2D. Ce bloc de données fournit des noms pour les couleurs dans un bloc CMAP et CMYK. Chaque bloc CNAM contiendrait les noms d'un groupe consécutif de couleurs. Après la longueur du bloc, il y a deux mots qui identifient les numéros de couleur de départ et fin pour lesquels CNAM fournit des noms. Chaque nom est une chaîne de caractères à terminaison nulle (NULL). Il y aurait (fin-début)+1 nombre de chaînes à terminaison nulle dans le bloc CNAM.

Exemple :

CMAP 		- ID du bloc CMAP
00000009 	- longueur du bloc (9 octets)
FF 00 00 	- couleur n°1 (r=ff, g=00, b=00)
00 FF 00 	- couleur n°2 (r=00, g=ff. b=00)
00 00 FF 	- couleur n°3 (r=00, g=00, b=00)

CNAM 		- ID du bloc CNAM
00000011 	- Longueur du bloc (19 octets)
0000 		- n° de couleur de départ dans ce bloc CNAM
0002 		- n° de couleur de fin dans ce bloc CNAM
Red\0 		- nom de la couleur n°1 (terminaison nulle)
Green\0 	- nom de la couleur n°2 (terminaison nulle)
Blue\0 		- nom de la couleur n°3 (terminaison nulle)

3.4 ILBM.CTBL et ILBM.DYCP : couleurs Dynamic HAM

Ce sont des blocs de données IFF créés par Newtek pour les images en Dynamic HAM produites par son appareil de capture vidéo DigiView IV. Il y a ILBM.DYCP (palette de couleurs dynamiques) qui utilise trois mots longs (configuration du fichier), ainsi que ILBM.CTBL (table de mots, un pour chaque couleur - 0RVB).

3.5 ILBM.DPI : points par pouce

C'est un bloc de données IFF enregistré le 16 janvier 1990 par Spencer Shanson. ILBM.DPI (points par pouce) permet la sortie d'une image à la même résolution que celle à laquelle elle a été numérisée.

Type Nom Description
UWORD dpi_x Résolution horizontale en points par pouce
UWORD dpi_y Résolution verticale en points par pouce

Par exemple, une image numérisée à une résolution horizontale de 240 DPI et une résolution verticale de 300 DPI sera enregistrée sous la forme suivante :

44504920 00000004 00F0  012C
DPI      taille   dpi_x dpi_y

3.6 ILBM.DPPV : perspective

C'est un bloc de données créé en décembre 1986 par Dan Silva pour le logiciel de dessin Deluxe Paint 2. ILBM.DPPV décrit l'état de la perspective dans un fichier ILBM de Deluxe Paint 2.

/* The chunk identifier DPPV */
#define ID_DPPV    MakeID('D','P','P','V')

typedef LONG LongFrac;
typedef struct ( LongFrac x,y,z; )  LFPoint;
typedef LongFrac  APoint[3];

typedef union {
   LFPoint l;
   APoint  a;
   } UPoint;

/* values taken by variable rotType */
#define ROT_EULER  0
#define ROT_INCR   1

/* Disk record describing Perspective state */

typedef struct {
   WORD     rotType;           /* rotation type */
   WORD     iA, iB, iC;        /* rotation angles (in degrees) */
   LongFrac Depth;             /* perspective depth */
   WORD     uCenter, vCenter;  /* coords of center perspective,
                                * relative to backing bitmap,
                                * in Virtual coords
                                */
   WORD     fixCoord;          /* which coordinate is fixed */
   WORD     angleStep;         /* large angle stepping amount */
   UPoint   grid;              /* gridding spacing in X,Y,Z */
   UPoint   gridReset;         /* where the grid goes on Reset */
   UPoint   gridBrCenter;      /* Brush center when grid was last on,
                                * as reference point
                                */
   UPoint   permBrCenter;      /* Brush center the last time the mouse
                                * button was clicked, a rotation performed,
                                * or motion along "fixed" axis
                                */
   LongFrac rot[3][3];         /* rotation matrix */
   } PerspState;

3.7 ILBM.DRNG : cycle de couleurs amélioré

C'est un bloc de données IFF soumis par Lee Taran. ILBM.DRNG améliore les capacités de cyclage des couleurs dans Deluxe Paint 4. Ce logiciel gère un nouveau modèle de cycle de couleurs qui n'exige pas que les cycles de couleurs contiennent une plage contiguë de registres de couleur. Avec ce bloc de données, vous pouvez faire passer un seul registre par une série de valeurs RVB. Vous pouvez combiner le cycle RVB avec le cycle de couleurs traditionnel. Deluxe Paint sauvegardera une plage CRNG à l'ancienne si la plage correspond au modèle CRNG, sinon il sauvegardera un bloc DRNG.

Type Nom Description
UBYTE min Valeur minimale de la cellule
UBYTE max Valeur maximale de la cellule
SHORT rate Taux de cyclage des couleurs, 16384=60 pas/seconde
SHORT flags 1=RNG_ACTIVE, 4=RNG_DP_RESERVED
UBYTE ntrue Nombre de structures DColor à suivre
UBYTE nregs Nombre de structures DIndex à suivre

3.8 ILBM.EPSF : PostScript encapsulé

C'est un bloc de données IFF proposé par Kevin Saltzman. ILBM.EPSF permet de contenir une représentation PostScript de l'image graphique du fichier ILBM. Utilisé par le logiciel PixelScript dans son clip art.

Type Nom Description
WORD lowerleftx Position horizontale en bas à gauche
WORD lowerlefty Position verticale en bas à gauche
WORD upperrightx Position horizontale en haut à droite
WORD upperrighty Position verticale en haut à droite

3.9 ILBM.PCHG : informations sur le contrôle de la palette ligne par ligne

C'est un bloc de données IFF proposé le 28 novembre 1991 par Sebastiano Vigna. ILBM.PCHG est un nouveau format de contrôle de la palette ligne par ligne. Il permet de contrôler efficacement et raisonnablement les changements de palette à chaque ligne de balayage : spécifier uniquement les changements réellement nécessaires, les changements de couleur avec une précision de 24 bits et un canal alpha, spécifier correctement la relation PCHG<->CMAP, le tout avec un bloc de données plus petit que SHAM ou CTBL.

Specifications :

struct PCHGHeader {
   UWORD Compression;
   UWORD Flags;
   WORD  StartLine;
   UWORD LineCount;
   UWORD MinReg;
   UWORD MaxReg;
   UWORD TreeSize;
   UWORD Reserved;
   ULONG OriginalSize;
};

struct SmallLineChanges {
   UBYTE ChangeCount16;
   UBYTE ChangeCount32;
   UWORD PaletteChange[];
};

struct BigLineChanges {
   UWORD ChangeCount;
   struct BigPaletteChange PaletteChange[];
};

struct BigPaletteChange {
   UWORD Register;
   UBYTE Alpha, Red, Blue, Green;
};

PCHG ::= "PCHG" #{ (struct PCHGHeader) (LINEDATA | COMPLINEDATA) }

COMPLINEDATA ::= { TREE COMPDATA }
TREE ::= { UWORD* }
COMPDATA ::= { ULONG* }

COMPDATA, when unpacked, gives a LINEDATA.

LINEDATA ::= { LINEMASK ((struct SmallLineChanges)* | (struct BigLineChanges)*) }
LINEMASK ::= { ULONG* }

3.10 ILBM.PRVW : aperçu

C'est un bloc de données IFF enregistré en septembre 1991 par Gary Bonham de la société Oxxi. ILBM.PRVW est une version miniature d'une image ILBM utilisée pour la prévisualisation. ILBM.PRVW est comme un fichier ILBM mais est imbriqué dans un fichier ILBM.

3.11 ILBM.XBMI : informations bitmap étendues

C'est un bloc de données IFF soumis le 29 août 1991 par Dan Weiss, Deron Kazmaier et Gary Knight de la société Soft-Logik. ILBM.XBMI (eXtended BitMap Information) contient les points par pouce horizontaux et verticaux, ainsi que le type d'image. Chaque entrée a une longueur d'un mot (deux octets) pour une longueur totale de trois mots. Le premier mot contient le type d'image. Il y a six types d'images.

Type Numéro Description
ILBM_PAL 0 Données BODY = index dans la palette (CMAP)
numcolors = 1<<profondeur
ILBM_GREY 1 BODY = valeurs des niveaux de gris.
Bits par échantillon = nombre de plans de bits.
Échantillons par pixel = 1.
noir = 0, blanc = (1<<profondeur)-1
ILBM_RGB 2 Données BODY = valeurs de rouge, de vert et de bleu.
Bits par échantillon = profondeur/3.
Échantillons par pixel = 3.
ILBM_RGBA 3 Données BODY = valeurs de rouge, de vert, de bleu et du canal alpha.
Bits par échantollon = profondeur/4.
Échantillons par pixel = 4.
ILBM_CMYK 4 Données BODY = valeurs de cyan, de magenta, de jaune et de noir.
Bits par échantillon = profondeur/4.
Échantillons par pixel = 4.
ILBM_CMYKA 5 Données BODY = valeurs de cyan, de magenta, de jaune, de noir et du canal alpha.
Bits par échantillon = profondeur/5.
Échantillons par pixel = 5.
ILBM_BW 6 Données de BODY = bits de noir et de blanc.
Bits par échantillon = 1.
Échantillons par pixel = 1.
Blanc = 0, noir = 1.

3.12 ILBM.XSSL : image 3D X-Specs

C'est un bloc de données enregistré par la société Haitex. ILBM.XSSL ajoute un bloc d'identification pour les images des lunettes 3D X-Specs de Haitex. La présence d'un bloc de données XSSL dans un fichier ILBM indique que ce dernier doit être affiché en tant qu'image 3D. Ce bloc contient quatre octets de données réservées.

4. Diagramme en boîte de l'ILBM

Voici un diagramme en boîte pour un exemple simple : une image non compressée de 320x200 pixels de trois plans de bits. Le texte à droite du diagramme montre le schéma qui serait affiché par l'utilitaire IFFCheck pour ce fichier particulier.

diagramme ILBM IFF
Le "0" qui suit le bloc CMAP est un octet de remplissage

5. Notes pour travailler avec l'ILBM

Cartes en couleurs

Parfois, un fichier ILBM ne contient qu'une carte de couleurs et aucune donnée d'image. Il est souvent utilisé pour stocker une palette de couleurs qui peut être appliquée à une image séparément. Dans ce cas, le bloc de données BODY doit être vide et le champ numPlanes dans le bloc de données BMHD sera 0.

Images profondes ("deep images")

Certains fichiers ILBM contiennent des informations en "vraies couleurs" plutôt qu'en couleurs indexées. Ces fichiers dits "images profondes" n'ont pas de bloc de données CMAP et ont généralement 24 ou 32 plans de bits. L'ordre standard des plans de bits place le bit le moins significatif de la composante rouge en premier :

R0 R1 R2 R3 R4 R5 R6 R7 G0 G1 G2 G3 G4 G5 G6 G7 B0 B1 B2 B3 B4 B5 B6 B7

S'il y a des plans de 32 bits, les huit derniers plans de bits seront un canal alpha :

R0 R1 ... R7 G0 ... G7 B0 ... B6 B7 A0 A1 A2 A3 A4 A5 A6 A7

Une image ne contenant aucune carte de couleurs et seulement huit plans de bits peut être une image en niveaux de gris :

Je0 Je1 Je2 Je3 Je4 Je5 Je6 Je7

Extra Half-Brite

Si le fichier ILBM contient un bloc de données CAMG dans lequel le bit 7 est défini (c'est-à-dire 0x80 en hexadécimal), le fichier s'attend alors à utiliser le mode EHB (Extra Half-Brite) des jeux de composants OCS/ECS/AGA de l'Amiga. La carte de couleurs n'a pas plus de 32 entrées, mais l'image a six plans de bits. Le plan de bits le plus significatif doit être considéré comme un drapeau, et lorsqu'il n'est pas défini, il utilise les cinq bits inférieurs comme index dans la carte de couleurs comme d'habitude. Lorsque le drapeau est défini, utilise les cinq bits inférieurs comme index dans la carte de couleurs, mais la couleur réelle à utiliser doit être deux fois moins lumineuse, ce qui peut être obtenu en décalant les composants RVB de la couleur d'un bit vers la droite. Alternativement, il crée une carte de couleurs avec 64 entrées et copie les 32 entrées inférieures dans la moitié supérieure, en les convertissant en demi-luminosité ; puis utilise les six plans de bits comme index de couleur.

A noter que les images PBM ne peuvent pas exister en mode EHB.

Hold And Modify

Si le fichier ILBM contient un bloc de données CAMG dans lequel le bit 11 est défini (c'est-à-dire 0x800 en hexadécimal), le fichier s'attend à utiliser le mode HAM (Hold And Modify) des jeux de composants OCS/ECS/AGA de l'Amiga. Au format HAM6 (OCS/ECS), la carte des couleurs a jusqu'à seize entrées, mais l'image a six voire cinq plans de bits. Au format HAM8 (AGA), la carte des couleurs a jusqu'à 64 entrées, mais l'image a huit voire sept plans de bits.

Les deux derniers plans de bits (si un nombre impair de plans de bits suppose un plan de bits supplémentaire qui est toujours 0) sont des drapeaux de contrôle qui indiquent comment utiliser les quatre (ou six) premiers plans de bits.

Drapeaux de contrôle Description
00 Utilise les plans de bits 0-3 (ou 0-5) comme index de carte de couleurs comme d'habitude
01 Utilise la couleur du pixel précédent mais remplace le composant bleu par des bits des plans de bits 0-3 (ou 0-5)
10 Utilise la couleur du pixel précédent mais remplace le composant rouge par des bits des plans de bits 0-3 (ou 0-5)
11 Utilise la couleur du pixel précédent mais remplace le composant vert par des bits des plans binaires 0-3 (ou 0-5)

Si le premier pixel d'une ligne de balayage est un pixel de modification, alors il modifie et utilise la couleur de bordure de l'image.

Notez que lorsque vous utilisez quatre bits pour modifier un composant de couleur, vous devez utiliser les quatre bits dans les quatre bits supérieurs du composant et aussi dans les quatre bits inférieurs (afin d'éviter de réduire la gamme de couleurs globale). Lorsque vous utilisez six bits, cela est moins important, mais vous pouvez toujours placer les deux bits les plus significatifs des bits de modification dans les deux bits les moins significatifs du composant de couleur.

A noter également que les images PBM ne peuvent pas exister en mode HAM.

6. Utilitaires

La plupart des utilitaires qui fonctionnent avec les fichiers ILBM et PBM sont plutôt anciens, comme MacPaint ou Deluxe Paint. Presque toute la gamme d'utilitaires graphiques de l'Amiga sait gérer ce format de fichiers. Il y en a d'autres :
  • Netpbm est un lot de programmes et bibliothèques en code source ouvert, notamment pour le monde Unix, qui peut convertir des images d'ILBM vers son propre format PPM et inversement.
  • L'éditeur graphique en pixel GrafX2, inspiré de Deluxe Paint, peut charger et enregistrer des fichiers ILBM, mais est limité à 256 couleurs maximum, donc les images HAM ou ILBM 24 bits n'afficheront pas toutes les couleurs. Grafx2 a été porté sur MorphOS et AmigaOS 4.
  • ImageMagick et GraphicsMagick sont des outils en code source ouvert qui peuvent également afficher et convertir des images ILBM si les utilitaires ilbmtoppm et ppmtoilbm de Netpbm sont installés.
  • IrfanView est un outil Wondows qui permet de visualiser les fichiers, il est gratuit pour une utilisation non commerciale et peut aussi fonctionner sous Linux.
  • PNG2ILBM est un outil graphique multiplates-formes qui convertit les fichiers PNG aux formats ILBM et ACBM. Il peut convertir n'importe quel PNG, y compris les PNG à canal alpha et/ou à profondeur de 16 bits par canal. Il gère le rééchantillonnage, la quantification, le tramage, la préservation ou l'annulation des registres de couleurs sur tous les plans de bits de 1 à 8, y compris Extra Half-Brite et Hold And Modify.
  • Graphics Workshop 1.1Y est un logiciel Windows datant du milieu des années 1990, peut convertir depuis et vers toutes les variantes de fichiers ILBM.
  • Ultimate Paint pour Windows peut lire, écrire et afficher des animations de cycle de couleurs de palette.
  • XnView's nconvert est un convertisseur multiplates-formes en ligne de commande gratuit.
  • Image Converter Plus est un programme partagiciel pour Windows qui convertit les fichiers ILBM dans un grand nombre de formats.
  • Paint Shop Pro 7 et d'autres versions plus anciennes peuvent lire et écrire des fichiers ILBM, mais ne peuvent lire que des fichiers PBM.
7. Liens


[Retour en haut] / [Retour aux articles]