Fiche technique | |
---|---|
Type | Bitmap |
Taille maximum de l'image | 65536 x 65536 pixels |
Supporte plusieurs images | Non, une seule image est présente par fichier |
Format des nombres | Big-endian |
Auteur | Digital Research |
Plateforme | MS-DOS, DR-DOS, Atari ST |
Introduction
L'extension de fichier «.GEM» ou «.IMG» permet d'indiquer des images qu'utilisait l'environnement graphique GEM destiné au MS-DOS et à l'Atari ST de Digital Research dans le milieu des années 1980. Aujourd'hui, Digital Research n'existe plus, et GEM est passé à travers l'histoire. On se souviendra très probablement de GEM pour son rôle en tant qu'environnement graphique d'origine avec sa plus célèbre application, Ventura Publisher. Le logiciel Ventura Publisher a mis GEM sur la carte et a fait de la prise en charge des formats de fichiers graphiques de GEM une pratique répandue. Deux formats en particulier méritent d'être mentionnés, le format GEM et le format GEM IMG. Le premier est un format vectoriel, similaire à bien des égards au format de métafichier de Windows. Le second, le format IMG est format Bitmap et est comparable au format PCX ou au format BMP de Windows.
Structure global du fichier
Un fichier GEM IMG est simplement structuré et se compose d'un entête de fichier suivi d'un Bitmap codé. L'entête est assez bref, composé de valeurs de 8 mots (16 octets au total). Le Bitmap est codé à l'aide d'une variante RLE étant légèrement plus compliquée que les autres schémas de compression RLE. À l'apogée de GEM, le niveau de l'art des adaptateurs graphiques était l'EGA. Cette situation se reflète dans la gamme de types d'images convertie par le format. Seules les images multiplanaires de 1 bit par pixel peuvent être codées, ce qui limite le format aux images monochromes et 16 couleurs. Un fichier IMG de 256 couleurs n'existait pas. Le format IMG n'est pas un format particulièrement bien conçu, et malgré sa simplicité, il est quelque peu problématique de travailler avec. D'une part, l'entête du format ne spécifie pas la hauteur de l'image encodée. Au lieu de cela, il indique le nombre d'éléments de ligne de numérisation; chaque élément composé d'un indicateur de répétition facultatif et d'une ligne de numérisation codée. L'indicateur de répétition indique le nombre de fois pour répliquer la ligne de balayage suivante; s'il n'est pas présent, un compte de répétition de un est implicite. Un problème avec ce schéma est que la hauteur réelle d'une image ne peut être déterminée qu'en décodant complètement le Bitmap du fichier. Un autre problème avec le schéma est qu'il n'y a aucun moyen de déterminer si un nombre de répétitions de ligne de balayage est présent, sauf pour essayer de le lire. S'il n'est pas présent, un programme vient de lire une partie d'une ligne de balayage codée. Cette situation tend à compliquer inutilement la logique de décodage.
Structure d'entête du fichier
L'entête d'un fichier IMG est contenu dans les 8 premiers mots du fichier (16 octets). Un aspect intéressant (mais irritant) de l'entête est que l'ordre des octets de chaque mot n'est pas cohérent avec l'ordre utilisé par les processeurs Intel. Par conséquent, les deux octets de chacun des 8 mots de l'entête doivent être échangés avant d'être utilisés. On utilisera par exemple, la fonction SWAP du Turbo Pascal pour échanger la valeur des 2 octets. Un programmeur prudent peut vouloir vérifier que l'ordre des octets d'un entête IMG a été inversé avant d'utiliser l'entête. La méthode la plus fiable est probablement de tester la valeur du champ de longueur de l'entête. La valeur devrait être 8, mais sera 8 fois 256 ou 2048, si l'ordre des octets de l'entête n'a pas été inversé. Voici l'entête d'un format d'image Gem/Img Ventura :
Déplacement | Taille | Description |
---|---|---|
0 | 2 octets | Ce champ contient la signature : 00h 01h |
2 | 1 mot | Ce champ contient le point de départ en format de mot Gros-boutiste des puces de Motorola |
4 | 1 mot | Ce champ contient le nombre de bits par pixel en format de mot Gros-boutiste des puces de Motorola |
6 | 1 mot | Ce champ contient la taille de la palette |
8 | 2 octets | Ce champ contient la largeur d'un pixel en microns |
10 | 2 octets | Ce champ contient la hauteur d'un pixel en microns |
12 | 1 mot | Ce champ contient la largeur de l'image en format de mot Gros-boutiste des puces de Motorola |
14 | 1 mot | Ce champ contient la hauteur de l'image en format de mot Gros-boutiste des puces de Motorola |
16 | 3 octets | Ce champ est réservé pour un usage interne ou futur |
L'image suit naturellement après l'entête.
Le schéma de compression IMG
Le format IMG contient une variante RLE pour compresser les images. Chaque plan de bits de chaque ligne de balayage est codé séparément comme un nombre entier d'octets. Si la largeur de l'image en pixels n'est pas un multiple de 8, chaque ligne de plan de bits est remplie de bits inutilisés à des fins de compression. Chaque ligne de balayage codée est précédée d'un nombre de répétitions facultatif, indiquant le nombre de fois qu'il faut répéter la ligne de balayage. Si le nombre de répétitions n'est pas présent, un nombre de 1 est implicitement utilisé. Lorsqu'il est présent, le nombre de répétitions est codé sur 4 octets au format suivant :
00h 00h FFh Compteur |
Le comptage est un octet unique avec une valeur comprise entre 2 et 255. Bien qu'un comptage de 1 puisse être codé, il est habituel d'indiquer des comptages de 1 en omettant simplement la séquence de comptage de répétition. En pratique, un lecteur de format lira 4 octets et testera les 3 premiers pour les valeurs spéciales. S'ils correspondent, le quatrième octet est utilisé pour le comptage. Sinon, le compte est 1 et les 4 octets doivent être non lus. La façon la plus simple de procéder consiste à rechercher dans le fichier 4 octets à partir de la position actuelle. Une fois le nombre de répétitions déterminé, une ligne de balayage codée est décodée. Gardez à l'esprit que chaque plan d'une image multiplane est codé séparément. La ligne de balayage codée consistera en une ou plusieurs des trois constructions de codage possibles. Celles-ci sont appelées exécutions solides, exécutions de modèle et chaînes de bits. Ils codent tous un certain nombre d'octets, pas de pixels. Une exécution solide se compose d'un seul octet indiquant un état et le nombre d'octets possédant cet état. Le bit de poids fort indique une valeur d'octet de 00h s'il est effacé et une valeur d'octet de FFh s'il est défini. Les 7 bits restants indiquent le nombre de répétitions de la valeur d'octet dans le flux de données. Par exemple, 83h signifie 3 octets de FFh et 0Fh signifie 15 octets de 00h. Une exécution de modèle est indiquée lorsqu'un octet avec la valeur 00h est lu. L'octet lu suivant détermine le nombre de répétitions de la palette. La longueur de la palette est indiquée dans l'entête du fichier. Une seule répétition de palette suit l'octet de comptage dans le flux de données. Il est lu puis répliqué dans le flux de sortie le nombre de fois indiqué. Voici un exemple, supposons que la longueur de la palette soit 2 et que l'image contienne ces 6 octets :
10h 20h 10h 20h 10h 20h |
Les données serait donc codé comme ceci :
00h 03h 10h 20h |
où 00h indique une palette exécuté, 03h est le nombre de répétitions et 10h 20h est la palette. Si un segment d'une ligne de balayage ne peut pas être codé en tant qu'exécution solide ou exécution de palette, il est alors codé en tant que chaîne de bits. Cette situation est signalé lorsqu'un octet de valeur 80h est lu. L'octet suivant dans le flux codé indique un nombre d'octets, et ce nombre d'octets est lu dans le fichier et utilisé tel quel. Par exemple, la séquence d'octets d'image suivante :
10h 2Ah 34h 17h |
peut être codé comme la chaîne de bits suivante :
80h 04h 10h 2Ah 34h 17h |
La valeur 80h signale une chaîne de bits et l'octet suivant indique que la chaîne de bits fait 4 octets de long. La chaîne de bits elle-même suit ces 2 octets. Comme vous pouvez le voir, le schéma de compression est légèrement plus complexe que ceux des formats PCX et MSP. En moyenne, il offre à peu près les mêmes degrés de compression. Notez que les résultats réels obtenus sont affectés par le choix de la longueur de palette. Une bonne valeur pour une image d'écran typique est 1 ou 2.
Remarque
- La valeur 1 de palette fait que l'algorithme se comporte très bien comme le schéma de compression PCX et est peut-être le meilleur choix par défaut.
Exemple
Voici un exemple montrant la structure de ce format suivant en Turbo Pascal 7 :
- Type
- {Entête d'un format d'image Gem/Img Ventura}
- HeaderGemImgRec=Record
- Sign:Array[0..1]of Char; { Signature: #$00#$01 }
- StartOff:Word; { Point de départ (format Motorola) }
- BitsPerPixel:Word; { Bits par pixel (format Motorola) }
- PatternSize:Word; { Taille de la palette }
- ResA:Array[8..11]of Byte; { Réservés }
- NumXPixels:Word; { Largeur de l'image (format Motorola) }
- NumYPixels:Word; { Hauteur de l'image (format Motorola) }
- ResB:Array[16..18]of Byte;{ Réservés }
- End;
Voir également
Langage de programmation - Traitement d'image - Accueil