|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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 :
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 :
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 :
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.
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".
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.
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.
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.
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.
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.
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.
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 :
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 :
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.
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 :
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.
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.
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.
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 :
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.
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. ![]() Le "0" qui suit le bloc CMAP est un octet de remplissage 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 :
S'il y a des plans de 32 bits, les huit derniers plans de bits seront un canal alpha :
Une image ne contenant aucune carte de couleurs et seulement huit plans de bits peut être une image en niveaux de gris :
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.
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 :
|