fascicule i – partie i

Transcription

GEOMETRIES ET COMMUNICATION GRAPHIQUE
TOME III
INFOGRAPHIE
FASCICULE I – PARTIE I
LES CONCEPTS DE BASE DE L’INFOGRAPHIE
Images de Synthèse, Bases de Données Graphiques,
Hardware Graphique, Logiciels DAO
2ème EDITION
( Année académique 2006-2007 )
Prof. Dr. ir. Y. DURAND
Faculté Polytechnique de Mons
Académie Universitaire Wallonie - Bruxelles
Ouvrage exclusivement réservé aux Etudiants
de 1ère Bachelier de la Faculté Polytechnique de Mons
Vente interdite en librairie
Tous droits de traduction, adaptation et reproduction
strictement soumis à l’autorisation écrite de l’Auteur
Ce document a été établi sur Portable TOSHIBA Satellite 2800-600 de N° de série T 71837950GS287-0 et imprimé sur
Imprimante Thermique à jet d’encre Hewlett Packard Deskjet 850C de N° de série SG63E3S1X6. Les dessins ont été
réalisés au moyen de DesignCAD 3000, Release du 29.01.01 , Licence N° H20408481048. Les textes ont été rédigés
sous Microsoft WORD 2000
TABLE DES MATIERES DU TOME III – FASCICULE I – PARTIE I
0. PREFACE
1. DEFINITION GENERALE D’UN LOGICIEL D’APPLICATION DEDICACE A LA
CREATION D’IMAGES DE SYNTHESE
1.1 LE CONCEPT DE « BASE DE DONNEES GRAPHIQUES »
1.2. LES DONNEES NUMERIQUES DE LA BASE DE DONNEES DECRIVANT DE FAÇON
PROPREMENT DITE L’IMAGE
1.3. LES PRINCIPES TECHNOLOGIQUES DE BASE DES ECRANS RASTER-SCAN CRT
1.3.1. NOTIONS DE BASE
1.3.2. LES PIXELS ET LA RESOLUTION D’UN ECRAN CRT
1.4. LES IMAGES ACHROMATIQUES ET LES IMAGES « COULEUR »
1.5. LES CARTES VIDEO
1.5.1. LA TRANSMISSION DES INFORMATIONS AU MONITEUR PAR LA CARTE VIDEO
1.5.2. LA MEMOIRE DE LA CARTE VIDEO
1.5.3. LE PROCESSEUR GRAPHIQUE
DE LA CARTE VIDEO
1.5.4. LES INTERFACES DE PROGRAMMATION GRAPHIQUE ( DirectX , OpenGL, PHIGS, GKS )
1.5.5. ARCHITECTURE DE L’ INTERFACE DE PROGRAMMATION GRAPHIQUE Microsoft Direct 3D
2. LES 2 CATEGORIES DE PROGICIELS D’APPLICATION CONDUISANT A LA
CONSTITUTION D’UNE BASE DE DONNEES GRAPHIQUES EN CREATION
D’IMAGES DE SYNTHESE
2.1. INTRODUCTION : SITUER LES OBJECTIFS DE CE COURS DANS LE CONTEXTE
GENERAL DES APPLICATIONS INFOGRAPHIQUES
2.2. GENERALITES A PROPOS DES 2 CATEGORIES DE PROGICIELS D’APPLICATION
CONDUISANT A LA CONSTITUTION D’UNE BASE DE DONNEES GRAPHIQUES EN
2.3. INTRODUCTION GENERALE AU MODE « PROGRAMMATION »
2.4. INTRODUCTION GENERALE AU MODE « DESSIN INTERACTIF
3. LE MODE DE DESSIN DAO INTERACTIF : INTRODUCTION DETAILLEE
3.1. L’INTERET DU MODE « DESSIN INTERACTIF »
3.2. LES OUTILS CLASSIQUES DE POINTAGE EN MODE « DESSIN INTERACTIF »
3.2. LE MODELE LOGIQUE D’UN ENSEMBLE DAO INTERACTIF : LES RETROACTIONS
3.4. LES LIENS ENTRE PROGICIELS DAO INTERACTIFS ET LES BIBLIOTHEQUES
GRAPHIQUES DE TYPE Phigs, OpenGL, …
3.5. LA DIFFERENCE FONDAMENTALE ENTRE UN DESSIN VECTORIEL ET UNE
IMAGE BITMAP
3.6. VECTORISER AUTOMATIQUEMENT UNE IMAGE BITMAP SOUS DESIGNCAD
PREFACE
L’Infographie ( en Anglais, « Computer Graphics » ) est, pour le vocabulaire français, un néologisme créé
en 1974 par le rapprochement des mots « Informatique » et « Graphique » par la Société Benson
( Constructeur de tables traçantes « à plumes » de grand format et de très haute qualité, à l’époque concurrent
dans ce secteur notamment des Sociétés Calcomp et Hewlett Packard ) pour désigner la branche de
l’informatique qui a pour objet la production et/ou le traitement d’images.
Jusqu’à la décennie 1980-1990, l’infographie était un domaine hyper-spécialisé, d’une part parce que le
matériel dédicacé était extrêmement coûteux ( une table traçante des années 1980 coûtait approximativement
10 fois ce qu’elle coûte aujourd’hui ; les écrans graphiques étaient très coûteux, du type « vectoriel » et non
« matriciel » comme actuellement et étaient réservés à des bureaux d’étude et de recherche très spécialisés ) et
d’autre part parce que les programmes graphiques d’application étaient très peu nombreux et très onéreux.
En fait, le développement et la « démocratisation » de l’Infographie n’ont trouvé leur point de départ que vers
1985 dans l’introduction des premiers micro-ordinateurs Apple puis IBM PS/2, notamment parce que les
concepteurs des premiers « Apple » avaient eu l’intuition géniale que l’usage d’une interface graphique
interactive ( menus déroulants, icônes, pointés par souris ) pour la gestion de l’Operating System notamment
était la voie à privilégier pour permettre à tout utilisateur « lambda » d’accéder en « mode conversationnel »
aux services de l’informatique.
Plus spécialement encore, cette expansion de l’infographie et de l’infographie interactive a été rendue possible
par l’introduction, sur les machines précitées, des écrans ponctuels à balayage de trame ( Raster Scan
Display ), directement dérivés de la technologie des écrans TV et, par conséquent de prix réduit par rapport
aux écrans spécialisés « vectoriels » ( Random Scan Display ) précédemment utilisés pour le tracé graphique
sur stations de travail dédicacées, la différence entre les 2 types étant que les « ponctuels » travaillent avec le
point comme primitive de base, tandis que les « vectoriels » admettent le segment de base comme primitive
de base pour le tracé : toute l’infographie contemporaine repose ainsi sur le concept associé aux écrans
« ponctuels » du graphique à matrice de points, concept qui reste toujours aujourd’hui d’actualité, même
avec les écrans plats les plus récents de type LCD à matrice active.
Comprendre cette technologie permet de comprendre les bases de l’infographie : vous constaterez ainsi que ce
cours débute par l’explication de ce concept incontournable.
Le domaine de l’infographie, tel qu’il s’est développé et se développe encore exponentiellement aujourd’hui,
étend son champ d’action dans 2 voies concurrentes : la création des images de synthèse d’une part,
l’acquisition et le traitement des images naturelles d’autre part.
Ce cours est plus particulièrement orienté « création d’images de synthèse ».
Les fascicules de ce cours, après une introduction générale applicable tant aux images de synthèse qu’aux
images naturelles numérisées, s’intéresseront plus particulièrement à un volet particulier de l’infographie
interactive : les progiciels DAO ( Dessin Assisté par Ordinateur ), très importants pour tout ingénieur
puisqu’aujourd’hui,tous les Bureaux d’Etudes en sont équipés.
Ces progiciels de Bureaux d’Etudes, pour être général, ne sont pas seulement de DAO, mais plutôt le plus
souvent de CAO ( en Anglais : « Computer Aided Design » ou CAD ) : un progiciel CAO ( Conception
Assistée par Ordinateur ) est un package intégré d’outils informatiques permettant aux concepteurs d’un
produit manufacturé de définir et mettre au point ce produit ainsi qu’en contrôler les aptitudes .
De tels progiciels CAO contiennent en général plusieurs modules compatibles entre eux :
-
un module de dessin DAO 2D / 3D
-
un ou des modules de calcul ( calcul par Eléments Finis de la résistance des pièces aux
sollicitations statiques, thermiques ou dynamiques qui leur sont imposées )
-
un ou des modules de gestion de bases de données relationnelles ( permettant p.ex.
d’associer aux pièces composant un ensemble des attributs, de matière p.ex., permettant
aussi la mise en œuvre de processus d’échanges d’informations digitalisées entre les
divers acteurs de la création et de la fabrication du produit )
-
une Bibliothèque d’objets pré-dessinés et paramétrables, répondant à des prescriptions
normalisées de morphologie ( p.ex. des vis, boulons, écrous, rondelles, paliers, . . . en
mécanique, des schémas de transistors, résistances, capacités, thyristors, . . . en
électronique, . . . )
-
une Bibliothèque Graphique, ensemble de routines pré-programmées appelables au sein
de programmes réalisés en C++ p.ex. en vue de permettre à l’Utilisateur d’établir luimême un programme de dessin de pièces particulières ( p.ex. une pièce dont ne face
serait un paraboloïde hyperbolique )
La présence du module de la 3ème catégorie précitée dans le package pouvant être compris comme une volonté
d’intégration dans la chaîne des processus industriels qui concernent directement les procédés de fabrication
eux-mêmes, comme par exemple la mise en place d’une base de données utiles pour cette fabrication, il est
alors d’usage d’étendre la dénomination de tels progiciels, plus complets encore que ceux du ressort de la
« simple » CAO, à la dénomination CFAO ( Conception et Fabrication Assistées par Ordinateur – en Anglais
Computer Aided Design and Manufacturing ) pouvant aller p.ex. jusqu’à la préparation de bases de données
pour la Commande Numérique de Machines-Outils ( CNMO – en Anglais : « Numerical Control for Machine
Tools » )
Actuellement, on trouve des progiciels CAO ou CFAO dans pratiquement tous les secteurs d’activités
industrielles, comme les CAO-Mécanique, les CAO-Bâtiment et Travaux Publics, les CAO-Electronique,…
Le « noyau » de tous ces progiciels reste cependant le module DAO qui va définir la base fondamentale de
données géométriques qui sera utilisée dans les opérations ultérieures de post-traitement CAO ou CFAO : un
programme d’Eléments Finis p.ex. repose sur le concept de discrétisation d’un volume en petites « briques »
élémentaires liées les unes aux autres, la transmission et la diffusion des efforts élémentaires s’opérant de
brique à brique ; il est clair que cette subdivision reposera sur la définition préliminaire DAO du volume de
l’objet concerné par l’analyse de la répartition des contraintes et déformations internes induites par les efforts
externes ( ou éventuellement internes s’il s’agit de sollicitations thermiques ) appliqués à l’objet.
Il existe ainsi des
impliquée :
-
modules DAO de 3 niveaux de complexité, selon le type d’application technique
le plus simple concerne la DAO 2D : comme le symbole l’indique, seules des primitives
géométriques du monde à 2 dimensions y sont traitées : ce type de progiciel peut trouver son
utilité en tant que module unique, utilisable de façon autonome dès lors que l’objectif resterait
simplement de substituer à la « planche à dessin » traditionnelle un outil informatique interactif
rendant le tracé plus aisé et plus précis pour la réalisation de plans classiques ( de type « Monge » ).
Il n’empêche que ce type de DAO 2D « de base » peut cependant être intégré à un outil CAO
parce que, p.ex., les calculs par éléments finis peuvent se satisfaire, dans de nombreux cas, d’une
analyse d’une « tranche » infiniment mince de l’objet, c.à.d. d’une analyse en 2D.
-
plus complexe déjà est la DAO 3D Surfacique : cette forme de DAO traite, de fait, les primitives
du monde 3D mais en écartant du package des formes construites les volumes solides proprement
dits, même si, du seul point de vue de leur représentation-image , de tels volumes peuvent malgré
tout y être modélisés par leurs surfaces- limites, mais aucune propriété associée au concept
de volume solide n’y est cependant alors considérée.
Considérons p.ex. un volume cylindrique exclusivement modélisé par le biais de ses surfaceslimites et supposons qu’il soit traversé par un autre volume cylindrique défini également par ses
surfaces-limites : l’opération booléenne d’intersection avec enlèvement de matière ne saurait en
aucun cas s’opérer pour définir automatiquement la surface d’intersection .
-
A contrario, la DAO 3D Volumique présente la caractéristique de pouvoir traiter des solides
volumiques proprement dits, c.à.d. pleins et continus, en les définissant encore p.ex. par le biais
de leurs surfaces-limites, mais dans ce cas, soit la surface-limite ( cas d’une sphère ou d’un tore
p.ex. ) doit être indispensablement refermée, soit les surfaces-limites ( chacune de type
« ouvert » ) doivent être strictement connexes en leurs frontières ( cas d’un cylindre de longueur
finie ou d’un cône p.ex. ) ; en outre, après avoir ainsi défini de telles surfaces-limites, une
procédure est à engager pour transformer l’entité surfacique en une entité solide proprement dite.
En tel cas de DAO 3D Volumique, les opérations booléennes sur les solides sont alors
parfaitement possibles, comme le montre l’exemple suivant de l’intersection d’un cône et d’un
cylindre réalisé en faisant usage du progiciel « DesignCAD » que vous utiliserez au laboratoire et
qui est un « vrai » modeleur 3D Volumique : 2 surfaces de clôture sont automatiquement
générées pour limiter les 2 parties solides du cône résultant de l’opération booléenne de
soustraction d’une partie de ce cône par un autre solide ( le cylindre ) :
Voici un autre exemple où une commande booléenne va maintenir les 2 solides, chacun subissant
cependant l’ablation de la partie volumique commune aux 2 objets solides :
Cette partie du Cours de Géométries et Communication Graphique dédicacé aux 1ères notions d’Infographie
sera structuré de la façon suivante :
1. Ce 1er fascicule sera consacré à une introduction générale à l’Infographie et à ses concepts
directeurs ;
2. Le 2ème fascicule posera les bases fondamentales de l’usage pratique d’un logiciel DAO
interactif ;
3. Le 3ème fascicule expliquera ce que sont les procédures dites « d’édition et de transformation des
primitives » qui constituent véritablement l’outil grâce auquel le Dessin Assisté par Ordinateur
trouve toute son efficience ;
4. Le 4ème fascicule s’intéressera à la programmation graphique et, plus particulièrement, à
l’algorithmique de l’Infographie.
1. DEFINITION GENERALE D’UN LOGICIEL D’APPLICATION DEDICACE A LA CREATION
D’IMAGES DE SYNTHESE
1.1. LE CONCEPT DE « BASE DE DONNEES GRAPHIQUES »
Un logiciel d’application pour la création d’images de synthèse est un programme établi
- pour gérer la constitution et les modifications d’une BASE DE DONNÉES régulant,
en sortie, l’affichage d’images sur un périphérique graphique ( un écran p.ex. )
- et pour interpréter, en entrée, toute action de l’utilisateur ( un « pointer / cliquer » de
souris sur commande de menu p.ex. ) visant à cette constitution ou à ces modifications.
Vous avez probablement déjà constaté que « Microsoft Windows » contient, en standard, des fichiers
d’images préenregistrées dont vous pouvez répertorier les fichiers, c.à.d. les bases de données, par les
commandes : « Démarrer / Documents » ( ou en examinant la liste des fichiers de ce type inclus dans le
fichier « Windows » via appel à l’ «Explorateur Windows » ) :
DETAIL :
Observez les extensions des noms de certains fichiers, autrement dit les codes d’identification qui
permettent d’en reconnaître le type à la simple lecture : « .bmp » ou « .GIF » sont ainsi des codes
d’identification de Fichiers Images.
Ces abréviations signifient respectivement : “ Windows BitMaP ” et “ Compuserve Graphics Interchange
Format ”.
Il s’agit là de 2 formats distincts de Fichiers Images ou, autrement dit, de Fichiers Graphiques, c.à.d. de
fichiers contenant la base de données permettant la juste reproduction à l’écran d’une image numérisée
ou, autrement dit, « digitalisée ».
Et en effet, par un Pointer / Cliquer ( B.G.S. ) sur l’icône de « Nuages.bmp » ou sur l’icône
de« HLPSTEP2.GIF », vous verrez successivement apparaître sur votre écran graphique « Windows » les
images suivantes :
Nous avons parlé, pour de telles images, d’une « Base de données digitale » : c’est bien sous cette
forme numérique que les « images » sont stockées en Mémoire du PC et transitent dans les composants du
PC avant d’être converties sous forme analogique pour l’affichage « écran ».
L’intérêt d’une telle numérisation est qu’elle conserve de façon stable l’intégrité et la qualité des données,
pour autant que les fichiers comportent des éléments de contrôle adéquats ( codes de correction d’erreurs ).
Ce principe général de numérisation de signaux analogiques ( image photo, image vidéo, son, … ) est
d’ailleurs devenu une règle générale pour tous les objets du Multimédia, imposant en parallèle le
développement d’une normalisation dont l’objectif est d’assurer la portabilité et la pérennité des fichiers
( d’une plate-forme à l’autre, en garantissant le maintien d’exploitation au travers du temps ).
Les intérêts des Producteurs et Fabricants ne sont d’ailleurs pas toujours en symbiose avec ceux des
Utilisateurs à propos de cette portabilité et c’est la raison pour laquelle il reste fort important pour tout
Ingénieur-Système responsable d’un parc informatique dans une Entreprise qui doit échanger des fichiers en
Input et en Output avec le monde extérieur de s’informer prioritairement du degré de portabilité des fichiers
traités par cette entreprise et donc de suivre de très près l’évolution des normes et standards afin d’éviter –
dans toute la mesure du possible – l’utilisation de fichiers générés avec des codages « propriétaires »,
c.à.d. des codages instruits par des Producteurs ou Fabricants voulant assurer, par ces codages spécifiques,
des situations de monopole si ces Producteurs ou Fabricants ne prévoient pas la disposition simultanée de
procédures de conversion vers d’autres formats pour garantir l’interopérabilité.
Dans le monde D.A.O., un exemple-type de codage « propriétaire » concerne le logiciel AutoCAD
développé par la Société Autodesk dont les fichiers sont de formats « .dxf » et « .dwg », formats
« propriétaires » créés à l’origine par Autodesk pour répondre de façon optimisée aux structures propres
d’AutoCAD mais qui, en raison du grand nombre de licences exploitées, sont devenus des Standards de fait
conduisant d’autres Sociétés concurrentes – comme Upperspace Corporation, le Producteur du progiciel
D.A.O. « DesignCAD » que vous serez amenés à utiliser pendant les laboratoires – à développer des
accords sectoriels afin de mettre en place l’interopérabilité des fichiers générés par les divers logiciels
concurrents qu’elles commercialisent.
Ainsi, p.ex., Upperspace Corp. est l’un des Membres fondateurs du Groupe « Alliance Open DWG » dont
l’objectif prioritaire est de garantir l’interopérabilité des fichiers générés par les logiciels des différents
Membres en offrant aux utilisateurs la garantie d’échanges sans altérations de fichiers graphiques via
fonctions d’importation et d’exportation selon le standard DWG qu’ils ont adopté comme standard
commun, même si ce standard n’est pas à proprement parler normalisé comme l’est le format SPIFF ( Still
Picture Interchange File Format ) pour les images fixes 2D ou le format VRLM ( Virtual Reality Modeling
Language ) pour les images 3D en rendu réaliste, statiques ou animées, qui, tous deux, sont définis par des
Normes Internationales ISO ( International Standards Organization ) et sont donc dans le domaine public.
Les fichiers natifs « DesignCAD » restent donc, comme ceux générés par AutoCAD, établis en 1ère ligne
selon un format propriétaire spécifique, en l’espèce le format propriétaire « .dc ».
Supposons alors qu’une entreprise X utilise DesignCAD mais fasse appel à un sous-traitant qui utilise
AutoCAD : il faudra qu’elle transmette ses fichiers à ce sous-traitant non pas sous le format « .dc » mais
bien sous le format « .dwg », exploitable par le logiciel AutoCAD du sous-traitant.
Réciproquement, les fichiers «.dwg » produits par ce sous-traitant devront pouvoir être traités par
l’entreprise X sous le format « .dc ».
L’interopérabilité est assurée par Upperspace Corp., au titre de sa participation à l’Alliance OpenDWG,
en offrant à l’utilisateur de son logiciel « DesignCAD » les fonctions appropriées de conversion des
fichiers « .dc » vers « .dwg » pour l’exportation d’abord et les fonctions appropriées de conversion des
fichiers « .dwg » vers « .dc » en importation d’autre part.
Il est clair que, pour accroître encore l’interopérabilité de DesignCAD, d’autres types de conversions
vers et depuis d’autres formats très utilisés en D.A.O. sont également offertes par Upperspace Corp.,comme
le montrent directement les Boîtes de dialogue « DesignCAD » illustrées ci-après :
En exportation : format DesignCAD « .dc » vers formats AutoCAD « .DWG » et « .DXF »
Une seconde Boîte de dialogue permettra de préciser la version utile d’AutoCAD :
L’examen de la liste déroulante « Type » montre en quels autres formats aussi un fichier
DesignCAD « .dc » peut être converti pour l’exportation :
« IGES » : « Initial Graphics Exchange Spécifications » , format très couramment utilisé en C.A.O.
( tous les logiciels de CAO Mécanique comme Catia, Cadkey, SolidWorks, … le
reconnaissent )
« RIB » : « RenderMan Interface » , format utilisé pour les traitements d’images avec rendu
réaliste au moyen de l’interface « RenderMan » développée par Pixar Corporation
« VRLM » : “ Virtual Reality Modeling Language ” spécifique aux images 3D Internet
“ WMF “ : “ Windows MetaFile” format utilisé par de multiples applications “Windows”
En importation : formats AutoCAD « .dwg » et « .dxf » vers format DesignCAD « .dc »
Le format complémentaire « XYZ » n’est pas un format de fichier graphique mais il est particulièrement
intéressant pour des ingénieurs qui sont souvent amenés à transcrire sous forme graphique des résultats de
calculs opérés avec un compilateur tiers qui génère, en sortie, des tableaux de valeurs exclusivement sous
une forme standard ASCII ( American Standard Code for Information Interchange ).
De tels fichiers peuvent aussi être constitués « manuellement » avec un éditeur de texte ASCII comme le
Bloc-Notes de Windows .
Si les valeurs consignées sous forme de tableaux de résultats des calculs peuvent être interprétées comme
des doublets ou des triplets de coordonnées ( X,Y ) ou ( X,Y,Z ) , l’importation par DesignCAD reportera
sur l’écran graphique soit les points identifiés par un « Marqueur » ( PolyMarker de type : Point épais,
croix, croix avec cercle, cercle, …) aux emplacements définis par les coordonnées ( dans l’espace 2D ou 3D ),
soit joindra ces points par de petits segments, soit joindra ces points par une courbe « lissée » de type
« Spline cubique », en fonction de l’option choisie dans une Boîte de dialogue :
Le grand intérêt pratique est que, dès ce tracé opéré dans la fenêtre de dessin interactif DesignCAD, il est
possible de réaliser un habillage circonstancié du graphique en bénéficiant de tous les outils de dessin
interactif inclus dans DesignCAD pour réaliser p.ex. les axes et leurs graduations, les légendes, les couleurs,
…
Pour un progiciel graphique « vectoriel », il est aussi de grande importance de pouvoir importer des
fichiers « bitmap » de type « photographies », notamment en format « .jpg » [ format normalisé par le
Comité de normalisation ISO « JPEG » ( Joint Photographic Experts Group ) ].
DesignCAD, p.ex., offre cette fonctionnalité d’importation d’images non vectorielles par appel à la fonction
« Charger Fichier Image » dont voici la Boîte de dialogue qui apparaît sur l’écran dès après appel de la
fonction dans le menu « Fichier » :
La liste déroulante complète dont le détail agrandi est donné ci-après montre le nombre important de
formats qu’il est ainsi possible d’importer :
Il faut d’ailleurs remarquer de façon plus générale encore que, le nombre de formats circulant dans le
domaine du Multimédia, de la DAO / CAO et de la PAO étant pléthorique, des logiciels spécialisés de
conversion existent sur le marché ( ex .: ACDSee version 5.0 – www. acdsystems.com ; Irfanview , cf. plus
loin ; JPEG Wizard – www.jpegwizard.com ; FireWork- www.telecharger.com ; les classiques de
traitement d’images comme ADOBE Photoshop, … ).
Une fois l’importation opérée, l’image apparaît sur l’écran graphique DesignCAD et il est alors possible,
non pas de « retravailler » l’image photographique comme le font des logiciels spécialisés dits « de retouche
d’images », comme Adobe Photoshop p.ex., mais bien d’y superposer un dessin vectoriel, par exemple
pour définir les contours de l’objet photographié.
Ce type d’opération peut se révéler très utile p.ex. pour un expert qui doit transcrire, sur un dessin annoté, le
tracé des fissures qui affectent une maçonnerie ou pour un architecte qui doit établir un croquis de façade à
partir d’une photographie.
L’exemple qui suit concerne une telle application : le tracé que nous avons opéré ici à titre d’exemple est
très sommaire et devrait bien entendu, pour une application « professionnelle », être nettement plus soigné.
Sur la copie d’écran, on trouvera, de gauche à droite :
- l’image photographique « brute », telle qu’elle se présente après importation ;
- une copie de cette image, réalisée par la fonction « copie » de DesignCAD, sur laquelle le tracé
vectoriel des contours a ensuite été réalisé en traits épais de couleur claire ;
- une copie translatée de ce tracé vectoriel.
Il reste aussi possible, grâce à des logiciels spécialisés, d’opérer la vectorisation automatique des images.
DesignCAD offre cependant cette possibilité en « standard » et voici p.ex. le résultat de la vectorisation
d’une photographie N/B :
Nous venons de montrer qu’il existait ainsi un grand nombre de formats d’images : toutes les opérations
d’échanges et de conversions entre formats se font évidemment via les fichiers numérisés correspondant
aux images traitées.
A l’aide des ressources de « dump » ( affichage de code organisé en séquences de lignes ) du « Microsoft
Visual Studio », nous pouvons ainsi vous montrer le début du fichier numérique correspondant p.ex. à
l’image « Nuages.bmp » :
.
Si vous n’avez pas accès au Microsoft Visual Studio ( distribué en même temps que le Kit de
développement Microsoft C++ ), vous pouvez obtenir le même résultat au moyen d’un logiciel Freeware
très intéressant , « Irfanview », que vous pouvez télécharger ( www.irfanview.com ) . Ce programme, créé
par le Développeur autrichien Irfan Skiljan ( Vienna, University of Technology ), permet également de
lire le fichier image sous forme numérique, exactement comme avec le Microsoft Visual Studio : dans la
barre principale de menu, cliquez sur « File » ( ou « Fichier » en version FR ) puis sur « Open in HEX
Viewer » et sélectionnez l’image à ouvrir : le résultat sera strictement identique à ce qui est montré cidessus.
Il s’agit en fait d’un fichier en « Hexadécimal » : de tels fichiers réclament, pour être lus et interprétés, de
solides connaissances très spécialisées, nécessitant en particulier de connaître les clés permettant leur
analyse.
Il existe ainsi 2 « Bibles » U.S. de référence pour les développeurs de programmes infographiques,
consignant et expliquant comment lire et comprendre tous les formats de fichiers utilisés ou ayant été
utilisés, parce que ces formats sont très nombreux et diversifiés, chacun répondant à des spécifications
bien précises. Ces Ouvrages sont :
- Encyclopedia of Graphics File Format de J.MURRAY & W.VAN
RYPER ( Ed. O’Reilly)
- Graphics File Formats Reference & Guide de W.BROWN &
B.SHEPHERD ( Ed. Manning Publications Co.)
Il n’entre pas dans le cadre de ce cours d’étudier le détail de ces formats, mais néanmoins, il reste utile de
savoir qu’ils existent, comment ils sont constitués dans les grandes lignes et ce qui les distingue.
Voyons ainsi d’un peu plus près le fichier décrit précédemment et examinons p.ex. le début de la
seconde ligne :
- « 00 00 80 02 » est à convertir en nombre décimal :
1er octet : « 20 » en hexadécimal donne, en décimal : ( 2 x 162 ) + ( 0 x 161 ) = 512
2ème octet : « 08 » en hexadécimal donne, en décimal : ( 0 x 162 ) + ( 8 x 161 ) = 128
------------------------------------------------------------------------------------------------------TOTAL
= 640
Ceci donne la largeur de l’image : 640 Pixels
- « 00 00 E0 01 » est à convertir en nombre décimal :
1er octet : « 10 » en hexadécimal donne, en décimal : ( 1 x 162 ) + ( 0 x 161 ) = 256
2ème octet : « 0E » en hexadécimal donne, en décimal : ( 0 x 162 ) + ( E x 161 ) = 224
------------------------------------------------------------------------------------------------------TOTAL
= 480
Ceci donne la hauteur de l’image : 480 Pixels
- etc …
Quel qu’en soit le format, un tel Fichier Image comporte en général 3 parties :
- un en-tête de fichier ;
- les données décrivant de façon proprement dite l’image à afficher ;
- un ensemble de « métadonnées » (pour les formats les plus récents seulement ).
L’En-tête de fichier est une espèce de « mode d’emploi » du contenu ( les données proprement dites )
donnant tout un ensemble d’indications générales relatives au type de codage, à la compression, au nombre
de pixels par ligne et par colonne( cf. le début de ligne décodé ), au nombre de bits par pixel,… Ces
renseignements assurent aussi la portabilité du fichier.
Les Données décrivant de façon proprement dite l’image sont organisées et structurées en
correspondance avec les règles qui sont conventionnellement définies et imposées par les prescrits d’entête, p.ex. en ce qui est de la « compression d’image » .
Ces 2 premiers blocs - Bloc d’en-tête et Bloc « données décrivant de façon proprement dite l’image » – se
retrouvent uniformément dans tous les types de formats, même les plus anciens ( format BMP notamment,
remontant au tout début du développement des applications graphiques sur PC ).
Par contre, Les Métadonnées qui constituent aujourd’hui le 3ème bloc de tout fichier graphique établi selon
les standards actuels sont une partie plus récente de ce type de fichier : elles répondent notamment au
besoin qui s’est fait jour depuis l’instauration d’Internet d’une « traçabilité » des fichiers - images, par
exemple, pour des questions de propriété intellectuelle et artistique.
Ces questions présentent aujourd’hui une importance de plus en plus préoccupante dès lors que la copie des
fichiers informatiques se pratique sans difficultés et que le « piratage » de logiciels est un fléau très
répandu.
Certaines Sociétés productrices de progiciels D.A.O. poursuivent d’ailleurs systématiquement en justice les
utilisateurs de versions « piratées », utilisateurs qui donc travaillent avec le logiciel sans en avoir payé la
licence d’exploitation.
Le choix que nous avons opéré du logiciel « DesignCAD » pour l’apprentissage de l’infographie est
d’ailleurs en rapport direct avec ce problème de piratage : ce logiciel, de qualité cependant toute
professionnelle, est tellement « bon marché » qu’il peut facilement être acquis selon une licence tout à fait
régulière par tout jeune ingénieur qui déciderait d’installer son propre Bureau d’Etudes sans investissements
trop lourds.
Ces Métadonnées ont fait l’objet d’une classification hiérarchique recommandée par un groupe de travail
international constitué de plus de 200 experts ( Groupe EBU/SMPTE ) pour suivre les directives de l’OMPI
( Organisation Mondiale de la Propriété intellectuelle ) :
-
Classe 0 :
en-tête de flot de données, permettant de savoir comment les données sont
organisées ;
-
Classe 1 :
métadonnées essentielles, permettant de décoder adéquatement le contenu
principal de l’objet multimédia ;
-
Classe 2 : accès au contenu, destinées à faciliter l’accès au contenu ou, au contraire,
à le restreindre, dans le cas de conditions d’accès contre rétribution p.ex. ;
-
Classe 3 : métadonnées paramétriques, décrivant les paramètres ayant présidé à
l’élaboration de l’image, p.ex. des réglages de caméra ;
-
Classe 4 : métadonnées de composition, décrivant les enchaînements d’objets
multimédia entre eux, p.ex. un son / une image ;
métadonnées d’héritage et de composition, décrivant d’éventuels « liens
de parenté » entre objets ;
-
Classe 5 : métadonnées relationnelles, précisant des synchronisations et en
particulier
métadonnées temporelles ;
-
Classe 6 : métadonnées géospatiales, décrivant p.ex. le positionnement d’une prise
de vue [ cf. la technologie actuelle du GPS ( Global Positioning System ) ] ;
-
Classe 7 : métadonnées descriptives, données de catalogue destinées aux moteurs
de recherche des bases de données documentaires ( auteur, titre, localisation,
mots-clés, type d’objet [ photo, peinture, …] ) ;
-
Classe 8 : métadonnées autres , tout ce qui n’est pas décrit dans les précédentes
mais qui seraient nécessaire pour des cas particuliers ;
-
Classe 9 : métadonnées définies par l’utilisateur, porte ouverte à la créativité du
concepteur d’une application.
Pour vous montrer que les fichiers images contiennent bien de tels renseignements, ouvrons dans
« IrfanView » l’image « Yosemite.jpg » fournie en standard dans le répertoire « / mes Documents / mes
Images » de Windows (Me) après avoir agrandi la fenêtre « IrfanView » de façon qu’elle remplisse tout
l’écran :
En cliquant (B.G.S. ) sur l’icône « i » ( cf. flèche ) une Boîte d’information relative à cette image va
apparaître sur l’écran dont voici la teneur :
Cette Boîte d’information contient un certain nombre de données explicitées « en clair » pour
l’utilisateur « lambda » : le logiciel IrfanView est allé rechercher ces données dans l’en-tête et dans les
métadonnées du fichier-image « Yosemite.jpg ».
Dans la suite de ce cours, nous allons nous attacher plus particulièrement à comprendre ce que sont les
données décrivant de façon proprement dite l’image et pourquoi il est nécessaire de les encoder selon les
structurations particulières dont les en-têtes et certaines des métadonnées font état, en particulier pour ce qui
est de la compression de ces données.
Dans la Boîte d’information anglo-saxonne ci-avant, l’unité relative à la taille du fichier est le « Byte »,
groupe de 8 chiffres binaires « 0 » ou « 1 », dits aussi « Bits ».
Un « Byte » se traduit en français par « octet » : il s’agit de la plus petite unité adressable en mémoire.
Par exemple, l’octet « 11010100 » qui se convertit en base 10 en « 212 » et en Hexadécimal en «D4 » :
212 = ( 1 x 27 ) + ( 1 x 26 ) + ( 0 x 25 ) + ( 1 x 24 ) + ( 0 x 23 ) + (1 x 22 ) + ( 0 x 21 ) + ( 0 x 20 )
( 1101 ) = 8 + 4 + 0 + 1 = 13 = D ….. ( 0100 ) = 0 + 4 + 0 + 0 = 4.
[ Nombre décimal :
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Equivalent Hexadécimal : 0 1 2 3 4 5 6 7 8 9 A B C D E F G ]
Les multiples de Bytes ou d’octets sont les suivants :
1 KB = “1 Kilo-Byte ” = 1 Ko = “1 Kilo-octet ” = 1024 octets = 210 octets
1 MB = “1 Méga-Byte ” = 1 Mo = “1 Méga-octet ” = 1024 KB = 1024 Ko = 220 octets
1 GB = “1 Giga-Byte ” = 1Go
= “1 Giga-octet ” = 1024 MB = 1024 Mo = 230 octets
1 TB = “1 Tétra-Byte” = 1To
= “1 Tétra-octet” = 1024 GB = 1024 Go = 240 octets
1 PB = “1 Péta-Byte”
= 1Po = “1 Péta-octet” = 1024 TB = 1024 To = 250 octets
Pour vous permettre de vous rendre compte de la signification concrète de ces chiffres, voici quelques
correspondances utiles en termes de ce qui peut être stocké dans un segment de mémoire de « X- octets » :
1 octet = 1 nombre de 0 à 256 ou 1 caractère
2 octets = un nombre de 256 à 64000
1Ko = +/- une page de texte de 25 lignes à 60 caractères
1Mo = +/- 1000 pages de texte ; 6 secondes de son en qualité CD
1.4 Mo = une image couleurs à 16.000.000 de couleurs en 800 x 600 pixels ( non compressé )
1Go = +/- un million de pages de texte ; 1h30 de son en qualité CD, 50 secondes de vidéo
1To = 62 jours de son qualité CD, 14h00 de vidéo
1Po = 170 années de son de qualité CD, 19 mois de vidéo.
L’exemple de Base de Données examiné précédemment dans ce texte concernait une image qui n’est pas
constituée de traits comme celle établie en faisant usage d’un progiciel DAO comme DesignCAD qui établit
des dessins de type « vectoriel », c.à.d. où les pixels sont générés automatiquement par le progiciel en
faisant appel à des routines « géométriques » préétablies où l’utilisateur n’a plus qu’à préciser la valeur de
certains paramètres pour que le tracé s’exécute automatiquement.
Ainsi, si l’utilisateur souhaite dessiner un cercle, il lui suffit de pointer / cliquer sur l’icône « cercle »dans
un menu résidant dans la fenêtre graphique DesignCAD puis de préciser les ccordonnées de son centre et la
valeur du rayon pour que le cercle se dessine
.
Voici une copie « écran » de la fenêtre graphique de DesignCAD où vous pouvez observer la présence de
nombreux menus avec icônes. Après avoir pointé / cliqué sur l’icône de dessin d’un cercle, l’utilisateur sera
amené à préciser numériquement, par frappe du pavé numérique de son clavier, les coordonnées du centre
de ce cercle dans une Boîte de dialogue comme celle qui apparaît sur la copie d’écran ci-dessous et de
même, toujours via autre Boîte de dialogue, l’utilisateur devra introduire une valeur numérique pour le
rayon : le cercle se dessinera sans autres interventions de l’utilisateur :
Pointer / Cliquer sur l’icône « cercle »
D’apparence, le trait est continu, comme si on l’avait tracé au compas sur une feuille.
Toutefois, en y regardant bien, des crénelages semblent apparaître.
Procédons à un agrandissement important ( v. p. suivante ).
Cet agrandissement confirme sans aucune ambiguïté cette fois ce phénomène de crénelage.
Comment l’expliquer ?
En fait, ce que le programme réalise, c’est une approche discrétisée du cercle par des points, des pixels
d’écran en fait, parce que l’affichage sur l’écran s’opère pixel par pixel .
La Fig. ci-dessous schématise, à très grande échelle, le détail entouré d’un rectangle de la copie déjà
agrandie d’écran ci-dessus :
ECRAN PHYSIQUE
PIXEL ALLUME
PIXEL ETEINT
C’est exactement comme cela aussi que se présente l’image photo « Nuage.bmp » dont voici un très
grand agrandissement d’un très petit détail :
Ainsi, bien que les modes de construction des 2 images soient radicalement différents, le résultat final au
niveau de ce qui apparaît « physiquement » sur l’écran est toujours semblable : un assemblage de pixels
dont certains sont noirs, d’autres blancs, ce qui correspond sur l’écran à des pixels allumés ou éteints ( il
faudra nuancer ultérieurement ce concept « allumé / éteint » parce qu ‘en fait, les pixels peuvent être plus
ou moins allumés selon toute une large gamme de luminosités ; nous y reviendrons plus tard mais cela ne
change pas fondamentalement le principe de ce que nous expliquons ici ).
Corrélativement, il faut s’attendre à ce que les Bases de Données régissant les états « allumé » ou « éteint »
des pixels constituant l’écran physique selon une trame régulière soient constituées elles aussi de façon
assez similaire.
En fait, ces bases de données auront en effet de grandes similitudes si l’image du cercle dessiné sous
DesignCAD est enregistrée comme fichier « image » ( Fichier de type « .bmp » ) : c’est une façon de
faire mais c’est perdre alors le bénéfice du caractère vectoriel du dessin DesignCAD qui peut aussi être
enregistré sous la forme d’un ensemble d’informations consignant non plus le résultat du dessin comme une
vaste matrice de pixels, mais bien comme le codage des informations géométriques relatives à la
constitution des diverses entités géométriques constituant le dessin ( p.ex. un code indiquant qu’une entité
est un cercle, quelles sont les coordonnées de son centre et quelle est la valeur du rayon et non quels sont
les pixels allumés ou éteints qui constituent l’image approchée du cercle), ce qui présente l’avantage de
permettre, lors d’une réouverture du fichier, de pouvoir faire réapparaître ces caractéristiques géométriques
de l’entité et éventuellement de les modifier à nouveau, chose qui n’est absolument pas possible si le cercle
a été enregistré comme un simple ensemble de pixels c.à.d. sous la forme d’un fichier image « Bitmap »: les
caractéristiques géométriques de l’entité sont alors totalement perdues et il n’est plus possible de faire alors
réapparaître ces caractéristiques et de les modifier.
Pour mettre en évidence ce qui vient d’être expliqué, je vous montre, pour le tracé du cercle par
DesignCAD, 2 extraits des Bases de Données ( en Hexadécimal ) qui correspondent :
- pour la 1ère, à l’enregistrement du fichier image comme une matrice de pixels
( format « .bmp » )
- pour la seconde, à l’enregistrement du fichier « vectoriel » contenant les informations
géométriques ( format « .dc » )
Dans ce fichier « .bmp », on ne trouve qu’une très longue liste de « FF » qui correspondent au fond blanc
de l’image sur lequel les pixels du cercle apparaissent en noir auxquels correspondent, noyés au sein de la
grande masse de « FF », d’occasionnels « 00 » : il faut interpréter cette liste en la lisant de gauche à droite
et de haut en bas : cela revient à parcourir, les unes après les autres, les rangées horizontales de pixels qui,
toutes ensemble, constituent les lignes de la matrice rectangulaire des pixels « écran ».
Et de fait, si l’on scanne l’écran, dans chaque rangée horizontale de pixels, on ne trouvera que 2 pixels
noirs pour le cercle, les autres, correspondant au fond blanc de l’image, restant blancs et ceux-ci étant
évidemment beaucoup plus nombreux que les 2 pixels noirs.
Le fichier enregistré sous format « .dc » comportera des renseignements beaucoup plus variés: une entité
comme un cercle comporte en effet beaucoup de renseignements complémentaires à ceux d’ordre
strictement géométriques comme p.ex. le type de trait ( continu ou pointillés, … ), la couleur du trait,
l’épaisseur du trait,… soit ce qui est désigné par les « attributs » de l’entité :
Mais ce n’est pas parce que les renseignements consignés dans ce fichier vectoriel sont plus riches, plus
porteurs d’informations que ceux contenus dans le fichier rudimentaire « .bmp » que ce fichier vectoriel
occupera pour autant davantage d’espace en mémoire : c’est en fait tout le contraire parce que le fichier
vectoriel condense bien plus l’information à propos de l’entité en ne retenant que ses caractéristiques
géométriques et ses caractéristiques « Attributs » sans se préoccuper d’une pénible description de l’image
point par point, y compris d’ailleurs les points blancs de fond d’écran qui ne présentent en fait aucun intérêt
pour l’entité qui y a été dessinée.
Ainsi, procédez à l’expérience suivante : dessinez avec DesignCAD un ensemble de rectangles que vous
hachurerez d’un pochage intégral ( cf.p. suivante ) de telle sorte que l’image remplisse quasi tout l’écran :
cette fois, un très grand nombre de pixels de l’écran sont autres que des pixels blancs de fond d’écran et
sont donc en principe à décrire dans le fichier d’enregistrement, ce qui fait que l’on pourrait s’attendre à ce
que le fichier enregistré sous forme vectorielle occupe cette fois quasi autant de place en mémoire que le
fichier enregistré sous forme « image », de type « .bmp » donc.
Or, à l’expérience ( examen après leur enregistrement sous les 2 formats précités des 2 types de fichiers par
l’explorateur de Windows en y faisant apparaître les tailles des 2 fichiers ) , les tailles sont les suivantes :
- Fichier de type « .bmp »
:
- Fichier de type vectoriel « .dc » :
1.120.118 octets
62.464 octets
Remarquons au passage – et nous y reviendrons ultérieurement – que le fichier « image » pourrait aussi
être enregistré sous un format autre que le « .bmp » , soit sous un format « .jpg » qui est un format dit
« compressé » mais qui fait courir le risque d’une perte d’information « image » par rapport au fichier brut
de type « .bmp ». Sous ce format compressé, la taille mémoire serait réduit à 25.252 octets.
Voici donc, comme annoncé en page précédent, la copie d’écran du dessin des rectangles pochés généré
sous DesignCAD et qui a été enregistré sous les 3 formats précités :
Dans le fichier DesignCAD « .dc », le hachurage des rectangles est enregistré sous une forme synthétique,
exactement au même titre qu’un cercle est synthétisé par un petit nombre de renseignements d’ordre
géométrique : ces « synthèses » correspondent en fait à un ensemble de valeurs de paramètres intervenant
dans la définition algorithmique de l’entité : nous étudierons cela plus loin dans cet ouvrage lorsque nous
aborderons le § consacré aux algorithmes de création d’images géométriques.
De même, nous avons évoqué le concept de « compression d’images » : nous étudierons également cet
autre concept plus loin.
1.2. LES DONNEES NUMERIQUES DE LA BASE DE DONNEES DECRIVANT DE FAÇON
PROPREMENT DITE L’IMAGE
L’explication concernera un fichier d’image constitué pour afficher cette image sur un écran classique
« Raster-Scan CRT » de PC :
- « CRT » = « Cathodic Ray Tube » ;
- « Raster-Scan » = « utilisant une technologie consistant à produire en zone arrière du moniteur de
visualisation un faisceau fin d’électrons puis à le guider vers la face interne de l’écran pour lui faire
parcourir (c.à.d. « Scanner ») , ligne par ligne, la matrice ( « Raster » = « matrice » ) rectangulaire
des pixels « écran », c.à.d. les micro-zones contiguës couvrant la face interne de l’écran et pouvant
émettre un spot lumineux lorsqu’elles sont frappées par le faisceau d’électrons, spots perceptibles
alors par l’utilisateur qui observe l’écran et ainsi former une image globale constituée d’un
ensemble de points, « éteints » en zones foncées et « allumés avec plus ou moins d’intensité » dans
les zones plus claires.
En fait, sous sa forme la plus simple, c.à.d. pour un écran monochrome, le noyau principal d’un fichier
graphique destiné à l’affichage d’une image sur de tels écrans consigne, sous une forme numérique et selon
les conventions de codage et de structuration dont il a été question au §1.1, une matrice, dite « Bitmap »,
décrivant cet état actif ou passif à imposer pour chacun des « pixels » (Picture Elements ) ou « dots »
( « dot » = « Point » ) d’un écran CRT , c.à.d. l’état où ce pixel émet ou non un signal lumineux perceptible
par l’utilisateur : un tel type de moniteur est donc à considérer comme travaillant par « Tout ou Rien » au
niveau de l’affichage de chacun de ses pixels.
Sous cette forme très simple, considérons donc un écran monochrome ( pour notre exemple élémentaire :
écran affichant seulement 16 pixels par lignes et 12 pixels par colonne, en faisant remarquer immédiatement
que les écrans classiques réels présentent des affichages à nombre de pixels beaucoup plus importants, 1024
pixels par ligne et 768 pixels par colonne p.ex. ) où l’état des pixels ne peut être qu’« allumé » ou « éteint »,
sans nuances de gris et sans nuances de couleur.
Voici alors la constitution d’une Bitmap où le codage, élémentaire, consiste à introduire, dans une matrice
numérique, des nombres écrits en « base 2 », c.à.d. en « binaire », en correspondance avec chacun des
pixels et selon la même organisation structurelle.
Comme, en binaire, les chiffres – appelés « bits » - se réduisent aux seuls « 0 » et « 1 », le codage le plus
« intuitivement logique » consiste à attribuer le « 0 » comme code pour un pixel qui doit rester « éteint » et
le « 1 » pour un pixel qui doit être « allumé » :
ECRAN PHYSIQUE
PIXEL ALLUME
BITMAP
00 00 0
00 00 0
00 00 0
00 00 0
00 00 0
00 00 1
00 00 1
00 00 1
00 00 1
00 00 1
00 00 0
00 00 0
PIXEL ETEINT
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
0
0
1
0
0
0
0
0
0
0
0
0
1
1
1
1
1
0
0
1 PIXEL ALLUME
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0 PIXEL ETEINT
Bien entendu, plutôt que d’avoir affaire à un écran à fond noir où le caractère « H » apparaît blanc, comme
sur la Fig. ci-dessus, l’inverse pourrait être tout aussi bien réalisé, c.à.d. un fond blanc où le caractère
apparaît en noir, auquel cas le codage 0 / 1 des pixels serait tout simplement inversé aussi.
Le codage sera évidemment beaucoup plus complexe pour des images travaillant avec des moniteurs
« couleurs » : chacun des pixels doit alors être décrit de façon plus étendue que par un seul bit par pixel
parce que l’intensité d’émission lumineuse doit alors être modulée entre les 2 états « tout ou rien ».
De tels codages impliquent alors un descriptif à 8, 16, 24 ou 32 bits par pixel selon le nombre de couleurs
simultanément affichables à l’écran ( p.ex., 8 bits par pixel correspondent à une palette de 256 couleurs et
24 bits par pixel correspondent alors à 16 millions de couleurs affichables ).
Les « Propriétés » de l’image « Yosemite.jpg » telles que le logiciel IrfanView les a mises en évidence ( cf.
quelques pages auparavant ) correspondent ainsi à une image de 1024 x 768 pixels codés en 8 bits / pixel : il
s’agit en fait d’une image en « dégradé de gris », forme équivalente à un affichage « 256 couleurs », la
palette des couleurs classiques étant remplacée par une palette de gris.
Par opposition, une image « Noir et Blanc » codée en 1 bit / pixel ne saurait donner lieu à une palette de
dégradés de gris.
Pour mettre en évidence la différence entre une image en « dégradé de gris » ( 8 bits / pixel ) et
l’imagecorrespondante en strict « Noir et Blanc » ( 1 bit / pixel ), la petite manipulation suivante du
fichier« Yosemite.jpg » est fort intéressante :
- Dans le programme de dessin « Paint » de Windows ( Démarrer / Programmes / Accessoires /
Paint ), ouvrir le fichier «Yosemite.jpg » : l’image va apparaître en « dégradé de gris » dans la
fenêtre de travail « Paint » ;
- Enregistrer le fichier sous le nouveau nom « Yosemite Noir et Blanc.bmp » en précisant
dans la Boîte de dialogue « Enregistrer sous » que le codage doit être à 1 bit / pixel
( c.à.d. en format monochrome Noir et Blanc) :
Détail agrandi de la Boîte de dialogue :
Dès l’enregistrement validé en ce format monochrome « 1 bit / pixel », l’image change d’aspect et ne
présente plus aucun dégradé de gris mais uniquement, en fort contraste, du Noir et du Blanc:
Un détail agrandi permet une meilleure comparaison :
Image en dégradé de gris
Image Noir et Blanc : un seuil a été imposé pour sélectionner dans la palette
des gris de l’image d’origine le niveau à partir duquel le pixel doit être considéré
« éteint » ( Noir ) ou « allumé » ( Blanc ) dans la nouvelle image monochrome .
Pour de telles images codées à ( n bits / pixel ; n > 1 ), la représentation digitale ne correspond plus alors
à une simple Bitmap : le terme consacré est plutôt alors : « Pixmap » ( Pixel Map ).
La taille « mémoire » des fichiers « Pixmap » est évidemment 8,16,24 ou 32 fois plus importante que celle
d’un fichier « Bitmap » concernant le même nombre de pixels « écran ».
Pour un écran « 800 x 600 pixels », le fichier « Bitmap » occupera ( théoriquement ) 480.000 bits, soit
60.000 octets ( un octet = un groupe de 8 bits ), soit aussi 58,59 Ko ( Ko = Kilo-octet = 1.024 octets) .
Pour le même écran, le fichier « Pixmap » occupera ( théoriquement ), en 24 bits / pixel p.ex., 11.520.000
bits, soit 1.440.000 octets, soit 1.406 Ko, soit 1,37 Mo ( Mo = Mégaoctet = 1.024 Ko ).
Par un codage plus complexe, la structuration de la Pixmap peut cependant être modifiée pour occuper
moins d’espace « mémoire » : le format est alors dit « compressé » : un § ultérieur expliquera en quoi
consiste une « compression de fichier image ».
Pour vous permettre de bien comprendre la correspondance entre Bitmap numérique et pixels « écran »,
plaçons-nous dans la situation suivante : une image est enregistrée selon une bitmap de 1024 x 768 termes
( il existe donc dans cette Bitmap, un nombre N0 de « 0 » et un nombre N1 de « 1 » tels que N0 + N1 =
1024 x 768 = 786.432 termes ).
Supposons que cette image soit affichée sur un écran de 1024 x 768 pixels.
Elle va y apparaître « plein écran » : c’est pratiquement le cas de l’image « Yosémite Noir et Blanc.bmp »
observable dans la copie d’écran de IrfanView où elle a été importée : on constate d’ailleurs que le
descriptif général du codage apparaissant en bas de l’écran graphique « IrfanView » confirme le codage de
l’image « Yosemite Noir et Blanc.bmp » en 1024 x 768 termes à 1 bit / pixel :
Supposons alors que, pour en observer un détail, cette image soit agrandie p.ex. 8 fois, tout en
maintenant les mêmes limites physiques de la fenêtre d’affichage, c.à.d. le même nombre de pixels
physiques adressables ( en fait, rigoureusement, la fenêtre d’affichage ne contient pas tout à fait 1024 x
768 pixels parce qu’il existe des menus prédéfinis et des dessins de bordure de fenêtre qui consomment une
certaine fraction de ces 1024 x 768 pixels de l’écran complet : nous considérerons cependant, pour la
simplicité de l’exposé, que tout se passe comme si la fenêtre d’affichage de la photo comprenait bien 1024 x
768 pixels).
Il est clair que dans cette fenêtre physique « écran » et à la suite de l’agrandissement, l’image entière
ne saurait plus « tenir » mais que seul un huitième de cette image pourra encore être affichée.
Le nombre de pixels physiques « écran » adressables reste cependant toujours identique, 1024 x 768.
Par contre, la partie d’image qui va apparaître dans cette fenêtre « écran » suite à l’agrandissement ne va
plus concerner que ( 1024 / 8 = 128 ) x ( 768 / 8 = 96 ) termes de la Bitmap, soit 12.288 éléments qu’il faut
alors bien répartir entre les 786.432 pixels, sans distordre la forme générale du détail agrandi de l’image.
Le principe de l’agrandissement est alors d’attribuer l’information concernant chaque terme de la huitième
partie de Bitmap non plus à un seul pixel d’écran, mais bien à ( 8 x 8 = 64 ) pixels d’écran groupés en
carré, chacun des pixels « physiques » de tel carré recevant la même information d’affichage et information
correspondant à l’un des termes appartenant à cette huitième partie de bitmap.
En effet, la procédure d’agrandissement doit évidemment « se contenter » des informations consignées dans
la partie de bitmap correspondant à la portion d’image qui va remplir l’écran après agrandissement et ne
pourra pas « inventer » de nouvelles informations pour les besoins de cette portion d’image.
Procédez ainsi à ce type d’agrandissement pour l’image « Yosemite Noir et Blanc.bmp » dans
« IrfanView » en cliquant ( B.G.S. ) successivement sur l’icône de zoom ( la petite loupe avec un « + » ) : à
chaque clic, des carrés contigus de plus en plus grands forment l’image.
Chacun de ces carrés est en fait formé d’un nombre de plus en plus grand de pixels physiques « écran » au
fur et à mesure que le zoom progresse.
La partie de l’image apparaissant dans les agrandissements est relative au feuillage de l’arbre situé au bord
du plan d’eau , à gauche sur la photo, et dont l’arrière-plan est formé de hauts résineux sombres.
Pour que les carrés apparaissent de façon distincte, il faut procéder à de très grands agrandissements,
de l’ordre de 200 % au moins : les pixels physiques présentent en effet un diamètre très limité, de l’ordre
de 2.5 dixièmes de millimètres : il faut donc constituer des carrés d’un bon nombre de pixels pour qu’ils
deviennent bien apparents.
Vous pourrez d’ailleurs constater que si vous procédez à un agrandissement de 1000 % ( 990 % en fait, soit
le maximum admis par IrfanView ), soit +/- 10 fois, les carrés qui vont apparaître sur l’écran présenteront
bien une longueur de côté de l’ordre de 2.5 millimètres … faites l’expérience et mesurez !
Les 2 agrandissements de la page suivante concernent l’image monochrome Noir et Blanc.
La mise en évidence de l’attribution des caractéristiques d’un terme de la Bitmap à un nombre de pixels
physiques « écran » groupés en carrés est encore plus manifeste si l’on procède à l’agrandissement de
l’image « Yosemite.jpg » caractérisée par le dégradé de gris : les carrés de pixels font vraiment bien
apparaître l’attribution d’un même niveau de grisé pour tous les pixels constituant un carré et niveau de gris
qui correspond à celui du pixel de la Pixmap originale dont le carré est la représentation agrandie : 2
agrandissements de l’image en dégadé de gris sont ainsi montrés après les 2 qui concernent l’image
monchrome.
AGRANDISSEMENTS DE L’IMAGE MONOCHROME :
Agrandissement 300 %
AGRANDISSEMENTS DE L’IMAGE EN DEGRADE DE GRIS
Dans le même objectif pédagogique de vous faire « toucher du doigt » ce que sont les pixels d’un écran,
voici une autre application qui vous est tout à fait accessible sur votre propre PC, simplement en utilisant le
petit programme d’édition de Bitmaps : « Windows Paint » ( on y accède sur l’écran graphique classique
« Windows » par : Démarrer / Programmes / Accessoires / Paint ).
Dans la fenêtre qui remplit l’écran, on distingue une vaste zone grise qui est la partie d’écran réservée au
tracé et des zones latérales Bas / Haut / Gauche / Droite prédéfinies et contenant des menus, des icônes, …
Pour réaliser un tracé dans « Paint », il faut d’abord définir une zone active « de travail » dans la partie
grisée de l’écran en spécifiant sa largeur et sa hauteur en pixels dans la Boîte de dialogue
« Attributs »,appelable par Clic ( B.G.S. ) sur la commande « Image » puis sur « Attributs » dans le menu
déroulant associé à la commande « Image », p.ex. un rectangle de 200 x 150 pixels :
Cette zone de travail apparaît comme un rectangle blanc occupant une partie seulement de l’espace
disponible ( le plan gris ) pour une largeur de 200 pixels et une hauteur de 150 pixels:
200 x 150 Pixels
4262 octets
Modifions alors progressivement la taille de la zone de travail, toujours par appel à la Boîte de dialogue
« Attributs » en accroissant progressivement sa largeur et sa hauteur ( en pixels ) :
400 x 300 Pixels
800 x 600 Pixels
15662 octets
60062 octets
En enregistrant successivement chacune de ces images de rectangle blanc sous le format monochrome
Noir et Blanc ( 1 bit / pixel ) puis en appelant ( Clic sur commande « Image » puis Clic sur « Attributs »
dans le menu déroulant ) la Boîte d’affichage « Attributs », les dimensions des fichiers numériques
« Bitmap » associés à ces rectangles seront lisibles. Ces fichiers Bitmap codent l’état « blanc », c.à.d.
« allumé » ( Code « 1 » ) des pixels contenus dans ces rectangles
On peut ainsi constater les espaces « mémoire » suivants tels qu’ils sont occupés sur le disque dur ( taille
toujours un peu supérieure à la taille « réelle » du fichier proprement dit ) par les Bitmaps de valeurs
numériques codées pour les 3 cas :
-
Rectangle 200 x 150 pixels : 4.262 octets
Rectangle 400 x 300 pixels : 15.662 octets
Rectangle 800 x 600 pixels : 60.062 octets.
Comme le codage est en 1 bit / pixel non compressé, les blocs de données décrivant de façon proprement
dite les parties utiles des images ( les rectangles blancs ) au sein de ces fichiers occupent :
-
Rectangle 200 x 150 pixels : 30.000 bits, soit ( 30.000 / 8 ) = 3.750 octets
Rectangle 400 x 300 pixels : 120.000 bits, soit ( 120.000 / 8 ) = 15.000 octets
Rectangle 800 x 600 pixels : 480.000 bits, soit ( 480.000 / 8 ) = 60.000 octets.
Pour être bien convaincu que le codage dans la Bitmap représente bien 1 bit / pixel, que les pixels
soient « éteints » ( Noir ) ou « allumés » ( Blanc ), des tracés avec remplissages sont alors opérés
pour le cas du rectangle de 400 x 300 pixels, image enregistrée à nouveau en « monochrome » à 1
bit / pixel. La Boîte de dialogue « Attributs » permet de contrôler que la taille du fichier Bitmap est
restée strictement la même, c.à.d. 15.662 octets et ce, bien que l’image ait été sensiblement
modifiée quant à son contenu, mais non quant au nombre de pixels physiques « écran » concernés
par ce contenu, ni non plus quant à leur codage en 1 bit / pixel :
Comparons alors les fichiers Bitmap correspondant d’une part au rectangle blanc et d’autre part au
rectangle blanc avec les dessins d’ellipses et de rectangle remplis de noir :
CAS DU RECTANGLE BLANC
En hexadécimal, ( FF ) correspond à l’octet ( 1111 1111 ), soit 8 bits « 1 » correspondant à l’état
« allumé » de 8 pixels.
Chaque groupe ( 00 00 ) limite une nouvelle ligne de pixels du rectangle blanc sur l’écran.
Chaque ligne de pixels ( entre 2 groupes de « 00 00 » ) contient ainsi 50 (FF) successifs, soit 50 x 8 bits
de valeur « 1 », ce qui correspond bien aux 400 pixels de chacune des lignes du rectangle « Blanc »,
c.à.d. formé de pixels « éclairés ».
La toute 1ère colonne ( à gauche des « : » ) indique les adresses « mémoire » de ce codage.
Cette zone « mémoire » de la Bitmap est montrée ici parce qu’elle correspond à la zone ou un
rectangle noir est dessiné à l’intérieur du rectangle blanc pour le second dessin dont la Bitmap est
analysée en page suivante.
Pour cette autre Bitmap, il faut donc s’attendre à ce que des groupes de bits « 1 », allumés dans le 1er
dessin du rectangle blanc deviennent des groupes de bits « 0 » là où les pixels sont éteints pour former
le rectangle noir inclus dans le rectangle blanc.
CAS DU RECTANGLE BLANC AVEC ELLIPSES ET RECTANGLE REMPLIS DE NOIR
Chacune des lignes horizontales traversant le rectangle noir contient ceci ( à examiner entre 2 groupes de
« 00 00 » ) :
-
5 octets ( FF ) et un octet ( FE ), c.à.d. 5 octets ( 1111 1111 ) et un octet ( 1111 1110 ),
soit 47 pixels blancs « allumés » et 1 pixel noir « éteint » ;
-
25 octets ( 00 ), c.à.d. 25 octets ( 0000 0000 ) , soit 200 pixels noirs « éteints » ;
-
19 octets ( FF ) , c.à.d. 19 octets ( 1111 1111 ), soit 152 pixels blancs « allumés ».
Autrement dit, chaque ligne horizontale traversant le rectangle noir contient, de gauche à droite :
47 pixels blancs, puis 201 pixels noirs, puis 152 pixels blancs, soit en tout 400 pixels.
Il est particulièrement intéressant de contrôler ces valeurs en important le rectangle comme « image
Bitmap » dans DesignCAD et d’y procéder aux mesures des longueurs horizontales entre bord
gauche du rectangle blanc et bord gauche du rectangle noir ( on doit retrouver la longueur « 47 » )
puis entre bord gauche et bord droit du rectangle noir ( on doit retrouverla longueur « 201 » ) puis
entre bords droits du rectangle noir et du rectangle blanc ( on doit retrouver la longueur « 152 » ).
Bien entendu, pour appliquer valablement la cotation dynamique de DesignCAD entre points, il faut
d’abord y imposer qu’entre bords du grand rectangle blanc, la longueur est de 400 unités graphiques.
Voici le résultat de cette cotation dynamique réalisée après importation de l’image Bitmap dans
DesignCAD :
Cette cotation dynamique par DesignCAD confirme donc ce que l’analyse de la bitmap numérique
permettait d’interpréter en matière de nombre de pixels.
Une précision utile : le dessin original réalisé avec « Windows Paint » est vraiment du type « à main levée »
et dès lors, c’est « au hasard » que le positionnement et le dimensionnement du rectangle noir a été opéré,
ce qui motive la distribution très quelconque des 400 pixels horizontaux en valeurs non multiples de 10 ou
de 5 pixels p.ex..
Toujours dans ce programme Windows « Paint », nous allons montrer l’opération inverse de
l’agrandissement étudié précédemment ( en prenant comme exemple l’image « Yosemite.bmp » ) : cette
fois, nous partons d’un fond blanc correspondant à un rectangle blanc p.ex. de 800 x 600 pixels.
La 1ère opération est d’agrandir ce rectangle au maximum : dans le barre d’outils de « Paint », cliquer sur
« Affichage » puis, dans les menus en cascade, cliquer sur « zoom » puis sur « personnaliser ».
Dans la Boîte de dialogue « zoom personnalisé », choisir l’agrandissement « 800 % » puis « OK ».
Cliquer une seconde fois sur « Affichage » puis « zoom » puis « Afficher la grille » : une grille en grisé
apparaît sur l’écran, ainsi qu’un curseur.
Chacun des petits carrés délimités par le quadrillage contient évidemment un certain nombre de pixels
« écran » ( 64 = 8 x 8, en correspondance avec l’agrandissement « 800 % » = « 8 fois » ) mais est l’image
agrandie d’un seul pixel du rectangle initial à 800 x 600 pixels : chacun des 64 pixels d’un carré va alors
recevoir, lors du « Pointer / Cliquer » sur ce carré, un codage unique, soit « Noir ».
En cliquant ainsi à l’intérieur de l’un de ces petits carrés, on voit ce carré se noircir entièrement et il est
ainsi possible de dessiner avec toute « précision », « pixel agrandi » par « pixel agrandi », une
figure quelconque :
Le retour à la taille initiale 100 % par : « Affichage / Zoom / Personnaliser / 100 % » montre la même
figure, en taille plus réduite, et où, cette fois, chacun des pixels est à « sa taille normale écran » et présente
le même codage « Noir » que les 64 pixels du carré correspondant de l’image agrandie à 800 % :
A présent que les principes de base de la constitution des fichiers graphiques sont acquis, essayons
decomprendre, plus technologiquement, ce que sont les écrans Raster-Scan CRT et comment leurs pixels
sont activés par faisceaux d’électrons : ce sera l’objet du § 1.3.
1.3. LES PRINCIPES TECHNOLOGIQUES DE BASE DES ECRANS RASTER-SCAN CRT
1.3.1. NOTIONS DE BASE
Qu’ils soient « Noir et Blanc » ou « Couleurs », leur technologie de base est celle du « Tube à vide à
rayons cathodiques » qui s’est d’abord développée notamment pour les moniteurs TV classiques, les
écrans de contrôle ( de radars,… ) ainsi que pour les oscilloscopes et dont le principe général de
construction est expliqué ci-après pour un TRC monochrome .
L’inventeur (1897 ) de son « ancêtre », le « Tube de Braun » est le Prof. Karl Ferdinand BRAUN qui
enseigna la physique théorique à Malbourg, Tübingen et Strasbourg et reçu le Prix Nobel de Physique en
1909 à la fois pour cette invention et pour ses recherches théoriques sur les systèmes de transmission de
Guglielmo MARCONI ( Télégraphie Sans Fil ), celui-ci étant d’ailleurs le co-Titulaire du Prix Nobel
précité.
SCHEMA DE PRINCIPE D'UN TUBE A RAYONS CATHODIQUES
Dans l’ampoule de verre ( 0 ) où le vide a été assuré ( une rupture due à un choc accidentel provoque
d’ailleurs une « implosion » du tube, comme cela arrive parfois pour les T.V. domestiques reposant sur les
mêmes principes constructifs ) , un canon à électrons ( 1 ) émet un flux d’électrons qu’un dispositif de
focalisation ( ( 2 ), ( 3 ), ( 4 ) ) réduit à un faisceau très fin ( 7 ).
Ce faisceau subit ensuite l’action de 2 dispositifs déviateurs ( ( 5 ), ( 6 ) ) agissant selon 2 directions
orthogonales qui dévient de façon contrôlée la trajectoire du faisceau de façon à lui permettre de frapper, en
tout emplacement quelconque ( X, Y ) de l’écran la couche luminescente ( 8 ) recouvrant la face interne de
l’écran et y provoquer, par luminescence cathodique, l’apparition d’un spot visible alors par l’observateur
externe de l’écran.
- Le canon à électrons ( 1 ) produit le faisceau par émission thermo-ionique :
l’élément chauffant peut être un filament en spirale métallique bifilaire, placé à l’intérieur
d’une cathode de nickel en forme de « gobelet », le filament étant isolé de la cathode par de
la céramique.
Une couche émettrice (oxydes de baryum, de strontium et de calcium ) est placée sur la
cathode et produit par échauffement un nuage d’électrons.
- 3 électrodes ( 2 ), ( 3 ), ( 4 ) agissent ensuite en cascade sur le nuage d’électrons :
1°. La 1ère, de « modulation », appelée souvent « grille », agit sur l’intensité du
faisceau, c.à.d. en fait sur la quantité d’électrons constituant le faisceau
( ordre de grandeur de la différence de potentiel / cathode : quelques dizaines de
Volts ) .
Cette intensité modulera à son tour proportionnellement celle de l’émission de
lumière émise par le point frappé par le faisceau sur la couche luminescente
d’écran : celle-ci est en effet proportionnelle au nombre d’électrons qui la
bombardent.
Cette électrode de contrôle est pilotée par un dispositif amplificateur, lui-même
commandé par le circuit d’output du PC transmettant les indications utiles en
matière d’intensité souhaitée pour chaque emplacement des spots « écran ».
Cette partie du dispositif est donc de première importance pour l’affichage
graphique : le contrôle de la tension de grille contrôle l’intensité de lumière
du spot à l’écran et permet donc en particulier, pour les moniteurs
« couleur », des dégradés de couleurs.
2°. La 2ème, d’ « accélération », assure aux électrons la grande vitesse nécessaire
pour que leur frappe sur la couche luminescente ait l’énergie suffisante au
développement du phénomène souhaité d’excitation luminescente sur la couche
interne de l’écran.(ordre de grandeur de la différence de potentiel / cathode :
quelques centaines de Volts ).
3°. La 3ème, de « focalisation », réduit le diamètre faisceau à l’ordre de quelques
dixièmes de millimètre.( ordre de grandeur de la différence de potentiel /
cathode : 10.000 à 20.000 Volts ).
- 2 ensembles ( 5 ) et ( 6 ) de déviation du faisceau, travaillant l’un selon l’axe X, l’autre
l’axe Y ( en supposant que l’écran rectangulaire soit référencé selon un axe horizontal X
et selon un axe vertical Y ), ont pour rôle d’infléchir le faisceau sortant, selon la direction
Z, de l’ensemble (1) à (4) pour qu’il puisse atteindre n’importe quel point de l’écran.
Ces 2 ensembles ( 5 ) et ( 6 ) de déviation ont pour principe de développer un champ
variable, que ce champ soit de type électrostatique ( 2 plaques conductrices parallèles
soumises à une différence de potentiel, comme illustré sur le croquis ) électromagnétique
( 2 bobinages en opposition placés alors à l’extérieur du tube à vide et travaillant par
induction ).
Dans le premier type constructif, la déviation du faisceau est proportionnelle à la tension
appliquée entre plaques, tandis que dans le second, elle est proportionnelle au courant
appliqué aux bobines.
Dans les 2 cas, cette déviation du faisceau s’obtient ainsi en lui faisant traverser un
champ quasi uniforme ( du point de vue géométrique ) mais variable ( du point de vue
de son intensité ).
Dans le 1er cas, la déviation en millimètres sur l’écran qui correspond à une variation de
tension d’un Volt est appelée Sensibilité de déviation en tension du tube cathodique.
Dans le second cas, la déviation en millimètres sur l’écran qui correspond à une variation
de courant d’un mA est appelée Sensibilité de déviation en courant du tube
cathodique.
Pour les écrans « Raster-Scan CRT », ces déviations sont imposées selon un cycle
immuable qui conduit le faisceau à « balayer » l’écran ligne par ligne ( horizontale ) et
une fois toutes les lignes balayées pour un cycle, ce même cycle est réitéré et ainsi de
suite …Chacune des lignes est composée de pixels formant une « trame » régulière sur
l’écran : on parle donc aussi d’écrans à « balayage de trame » comme traduction
française de « Raster-Scan ».
ECRAN RASTER-SCAN CRT : Principe du BALAYAGE DE TRAME
Comme le montre le schéma de principe ci-dessus, un cycle complet se décompose en :
o Nh parcours de lignes ( Nh = nombre de lignes horizontales composant la trame )
opérés de gauche à droite sur chaque ligne ;
o ( Nh – 1 ) « retours de trace » pour passer d’une ligne horizontale à la suivante, de
l’extrémité droite de la 1ère à l’extrémité gauche de la suivante ;
o 1 retour diagonal de trace depuis l’extrémité droite de la dernière ligne vers l’extrémité
gauche de la 1ère.
Les signaux du contrôleur vidéo commandant le moniteur et traduisant de façon analogique
les informations digitales « Bitmap » vont d’une part obliger le faisceau d’électrons à des
déviations régulées pour parcourir l’écran de façon monotone régulière en suivant toujours
strictement les séquences de parcours expliquées ci-dessus et d’autre part, agir sur la
tension de grille régulant, pour chaque pixel visé par le faisceau, son intensité en fonction
des indications consignées dans la Bitmap.
Nous avons vu l’exemple du fichier Bitmap monochrome relatif au rectangle blanc de 400
x 300 pixels: il est entièrement composé ( à l’exception de l’en-tête) de 300 séquences
répétitives de 400 valeurs binaires « 1 » ( consignées chacune sous le format hexadécimal
de 50 séquences « FF » ) indiquant que la tension de grille maximum est à imposer pour
chacun des 400 pixels de chaque ligne.
Ces séquences relatives à chacune des lignes sont systématiquement séparées par des
séquences hexadécimales « 00 00 » : ces dernières correspondent à la tension de grille cette
fois nulle qu’il faut imposer au canon à électrons pour qu’il n’y ait pas d’électrons émis
pendant les retours de trace :
La fréquence selon laquelle le balayage complet de l’écran est opéré se mesure en
« hertz » ( Hz ), c.à.d. le nombre de cycles de balayage de tout l’écran opérés en une
seconde.
Cette fréquence est appelée « Fréquence de synchronisation verticale », le terme
« synchronisation » correspondant au fait que la carte graphique pilotant le moniteur lui
adresse un signal, un « Top de synchronisation », marquant le début et la fin d’un cycle.
De façon équivalente à la « Fréquence de trame », on parle aussi de «Fréquence de
rafraîchissement » ( « Refresh Rate » ) d’un écran : chaque fois qu’un pixel
(luminophore) est frappé par le faisceau lors d’un cycle de parcours de l’écran, ce pixel
émet très brièvement de la lumière et il est donc nécessaire pour qu’une image puisse être
observée par l’utilisateur que cette émission de lumière soit répétée avec une grande
fréquence pour que sa propre persistance rétinienne intègre les spots émis à courts
intervalles réguliers en une seule image de longue durée, d’où cette nécessité d’un balayage
répétitif à haute fréquence qui « rafraîchit » et entretient l’émission lumineuse des pixels à
courts intervalles réguliers : plus précisément encore, comme l’excitation est brève mais
répétée, il se produit un phénomène d’accumulation qui augmente rapidement le niveaucrête de luminance pour le porter au niveau d’entretien.
Même pour des écrans travaillant en haute résolution, c.à.d. à très grand nombre de pixels,
le matériel doit être susceptible d’un rafraîchissement suffisant pour éviter un phénomène
très gênant de « scintillement », c.à.d. un effet de battement du signal lumineux qui serait
associé à une fréquence de balayage trop faible et à des intervalles de temps trop longs
entre spots successifs ( U.S. : « Scintillement » = « Flicker » ).
La fréquence de rafraîchissement minimum au-delà duquel l’impression visuelle de
scintillement disparaît pour tout utilisateur ne présentant pas une pathologie visuelle est
appelé la « Fréquence Critique de fusion » ou « FCF » ( en anglais « Critical Fusion
Frequency » ou « « CFF » ), le terme « fusion » correspondant au concept d’intégration
d’images brèves répétées en une image d’apparence continue et stable.
Cette Fréquence critique de fusion dépend de la « luminance » du spot ( unité de
mesure : la Candela / m2 ) mais encore reste toutefois variable d’un individu à l’autre (
persistance rétinienne ) dans une fourchette de l’ordre de 20 Hz et si l’on veut assurer,
statistiquement, que 99% des utilisateurs courants ne perçoivent pas de scintillement, le
moniteur doit, idéalement, travailler avec un taux de rafraîchissement de 80 à 100 Hz et
60 hz reste un strict minimum.
Le prix d’un écran va donc dépendre en grande partie de son aptitude à supporter un taux
de rafraîchissement élevé même pour des résolutions élevées : lorsque vous achetez des
écrans pour votre entreprise, il faut donc que vous veilliez à cette caractéristique technique
essentielle, sachant que très généralement, les constructeurs ne garantissent une fréquence
élevée que pour la résolution « recommandée » de chaque type de moniteur, mais que si ce
moniteur est piloté pour réaliser une résolution plus élevée que la « recommandée », la
fréquence de rafraîchissement est plus faible.
Dans la gamme PHILIPS, il n’existe actuellement qu’un seul type de moniteur CRT chez
ce constructeur ( le « 22’’ Brillance 202P40 » ) qui assure à la fois une fréquence de
rafraîchissement de 104 Hz en résolution recommandée ( 1600 x 1200 ) pixels et 80 Hz en
résolution maximale possible de ( 2048 x 1536 ) pixels ; tous les autres moniteurs courants
chez PHILIPS redescendent à 60 Hz en résolution maximale ( sauf 2 autres modèles qui
n’atteignent cependant que 74 et 75 Hz ).
En général, il est recommandable de régler les moniteurs à une fréquence de
rafraîchissement ne descendant pas sous les 70 Hz, sachant par ailleurs que les moniteurs «
multifréquences » s’adaptent automatiquement aux fréquences des adaptateurs vidéo.
Voici, à titre d’exemples, une liste ( non exhaustive ) de standards de rafraîchissements
auxquels s’adaptent les moniteurs Multisynchrones : 60, 70, 72, 74, 80, 85, 91, 100, 104
Hz.
Via Windows, il est ainsi possible d’opérer le réglage utile selon la procédure software
suivante : « Poste de Travail / Panneau de configuration / Affichage / Propriétés d’affichage
/ Paramètres / Avancé / Carte … et régler dans la Boîte de dialogue le Taux de
rafraîchissement ».
La Fréquence critique de fusion n’a par ailleurs aucun rapport avec le risque de
destruction de l’écran par brûlage des cristaux qui en recouvrent la face interne : tous les
cristaux luminescents ont en effet une durée de vie limitée, fonction de l’intensité du
faisceau et de la durée d’exposition à ce faisceau.
Pour éviter de « brûler » les cristaux, il importe donc que les programmes de gestion des
écrans CRT tiennent compte de ce risque.
Vous avez ainsi p.ex. pu constater que la gestion d’écran propre à Microsoft Windows
prévoit un mode de passage automatique en « écran de veille » en cas de non réception
d’une action d’entrée endéans un délai que l’utilisateur peut d’ailleurs fixer justement pour
éviter qu’une image statique trop longtemps affichée ne brûle l’écran ( Procédure : Poste de
travail / Panneau de configuration / Affichage / Propriétés de l’affichage / Ecran de veille /
Attente … ?…minutes ).
De même qu’un « Top de synchronisation » doit marquer la fin d’une « page écran », de
même faut-il qu’un Top signale le début et la fin de chaque ligne horizontale lors du cycle
de parcours de l’ensemble des lignes horizontales de cette « page » : on définit ainsi une
« fréquence de synchronisation horizontale » qui correspond donc en fait au nombre de
lignes horizontales rafraîchies par seconde .
Les ordres de grandeur de cette fréquence horizontale doivent donc correspondre au
produit de la fréquence de rafraîchissement par le nombre de lignes affichées sur l’écran .
P.ex., soit un affichage 800 x 600 pixels ( et donc 600 lignes ) rafraîchit à 70 Hz : la
fréquence de synchronisation horizontale est de l’ordre de : 600 x 70 Hz = 42.000 Hz = 42
KHz .
Soit un autre affichage à 1600 x 1200 pixels ( et donc 1200 lignes ) rafraîchi à 91 Hz : la
fréquence de synchronisation horizontale est de l’ordre de : 1200 x 91 Hz = 109.200 Hz =
109 KHz .
Donc, de façon générale, ces fréquences de synchronisation horizontales s’expriment
en KHz , dépendent de la définition de l’affichage ( le nombre de lignes horizontales de
l’écran ) et sont comprises dans une fourchette ( avec les performances , fin 2002 ) de l’ordre
de 30 à 130 KHz ( « KHz » = « Kilo-Hertz ).
- La couche luminescente recouvrant la face interne de l’écran est constituée de
cristaux ( communément appelés « luminophores » ou « phosphores » mais il peut s’agir
p.ex. d’orthosilicates de zinc, sulfites de zinc, cadmium et calcium contenant des traces
de cuivre, de manganèse, d’argent, … ) présentant la propriété d’émettre de la lumière
dans le spectre visible lorsqu’ils sont frappés par le faisceau d’électrons libres.
Cette émission « immédiate » lors de la frappe par le faisceau d’électrons est appelée
« fluorescence », mais il existe toujours une rémanence de l’émission lumineuse après
l’impact par le faisceau, rémanence appelée « phosphorescence », tandis que la durée de
cette rémanence est appelée « persistance ».
Ce phénomène s’explique de la façon suivante : les électrons incidents sont animés d’une
grande énergie cinétique lorsqu’ils frappent un luminophore de la couche émissive
recouvrant la face interne de l’écran ; cette énergie se transfère, lors de l’impact, en partie
en énergie d’échauffement et en partie en élevant les niveaux quantiques des électrons
des atomes du luminophore : lors du retour des électrons des atomes ainsi excités aux
niveaux quantiques primitifs, une émission photonique se produit.
Il existe toutefois, parmi les niveaux quantiques auxquels les atomes sont portés, des
niveaux de plus ou moins grande stabilité des électrons.
La fluorescence – émission la plus immédiate de lumière – correspond au retour à l’état
non excité des électrons portés aux niveaux les plus instables.
La phosphorescence – émission différée de lumière – correspond au cas des électrons
portés aux états quantiques les plus stables.
La persistance est définie comme le temps s’écoulant entre impact du luminophore par le
faisceau d’électrons incidents et instant où la phosphorescence atteint un seuil inférieur
d’émission lumineuse correspondant à 10% de la lumière initialement émise.
Si la fluorescence est un phénomène de très brève durée ( une fraction de microseconde)
la persistance, due à la phosphorescence, est de nettement plus grande ampleur ( de
l’ordre de 10 à 60 micro-secondes ) : l’image se forme donc bien davantage grâce à la
propriété de phosphorescence des luminophores que par le biais de leur luminescence.
L’usage de luminophores à très longue persistance n’est pas indiqué pour des écrans
graphiques, a fortiori si des séquences animées s’y inscrivent : des phénomènes de
traînéesdes images s’y produiraient alors. A contrario, pour les écrans « radar » une
grande persistance est recherchée : des luminophores offrant des persistances allant
jusqu’à l’ordre de 10 secondes y sont couramment utilisés ( images à faible fréquence de
récurrence ).
1.3.2. LES PIXELS ET LA RESOLUTION D’UN ECRAN CRT
Ces concepts sont à étudier différemment selon que l’écran est du type « monochrome » ou « couleurs » :
bien que les écrans « monochrome » soient aujourd’hui supplantés par les écrans de type « couleurs » en
raison de la considérable diminution de prix de ces derniers, il reste toujours intéressant d’étudier les
monochromes parce que, pédagogiquement, ils sont plus simples que les « couleurs » et permettent donc
d’induire beaucoup de concepts en matière de résolution avant de les généraliser aux écrans « couleurs ».
Très intuitivement et globalement, la résolution d’un écran est relative au nombre de pixels qui peuvent y
être affichés et le pixel est lui-même imaginé comme une tache lumineuse ronde bien délimitée et centrée
sur une position ( x, y ) de la trame, ce qui n’est en fait qu’une modélisation théorique de la réalité
technologique où, selon le type de moniteur, les pixels voisins peuvent se superposer partiellement ou au
contraire être séparés par un espace qui peut d’ailleurs être lui-même différent dans le sens horizontal ou
vertical : jusqu’à présent dans ce cours, un pixel a été considéré comme une micro-entité indépendante de
ses voisines, comme si chacun des pixels était une micro-lampe de taille parfaitement définie bien distincte
de ses voisines.
Nous verrons cependant dans la suite que la résolution d’un écran n’est pas tout à fait ce qu’annoncé cidessus, qui doit plutôt s’appeler « définition d’écran »
De même, si cette façon d’envisager les pixels est assez proche de la réalité pour les écrans plats à matrice
active où chaque point de l’écran est commandé par un transistor dédicacé et où les pixels sont plutôt de
type « carrés non superposés », tout autre est le cas des écrans CRT où la taille du pixel est notamment
tributaire d’une part du diamètre du faisceau d’électrons bombardant la couche continue cristalline
luminescente recouvrant la face arrière du verre d’écran et d’autre part de la taille des cristaux constituant
cette couche.
Comme le faisceau d’électrons incidents est focalisé par des dispositifs à symétrie de révolution, la forme
générale du faisceau est cylindrique à section circulaire.
Toutefois, les dispositifs de focalisation ne réalisent jamais une répartition isotrope de la densité
d’électrons dans cette section : la répartition de densité est d’allure gaussienne.
Lorsque ce faisceau d’électrons frappe la couche luminescente à l’arrière du verre d’écran, un spot
lumineux est émis, mais l’intensité de lumière adopte, autour du point central d’impact, une même
distribution gaussienne directement corrélée avec celle de la densité d’électrons
Verre d'Ecran
Revêtement luminescent
Distance à l'Axe du faisceau d'électrons
Densité d'électrons
Intensité de la
Lumière émise
FAISCEAU D'ELECTRONS
Les répartitions gaussiennes corrélées de densité d'électrons et d'intensité de lumière émise
Autrement dit, comme le spot se caractérise par une lumière intense en son centre mais qui s’estompe
progressivement vers les bords, la définition de sa dimension caractéristique ne peut qu’être
conventionnelle : l’usage s’est imposé de considérer son diamètre comme celui où l’intensité de lumière
atteint les 50 % de l’intensité maximale centrale :
Verre d'Ecran
Revêtement luminescent
50%
50%
Intensité de la
Lumière émise
1 PIXEL
Axe du Faisceau
d'Electrons
Répartition Gaussienne
de la Lumière émise
Définition conventionnelle de la taille de Pixel
Pour les écrans monochromes graphiques à Très Haute Résolution, l’ordre de grandeur du diamètre de
pixel ou de la « Taille de Pixel » ( « Dot Size » ou « Spot Size » ) est : 0,125 mm
( 5 millièmes de pouce ).
On définit alors l’ « Adressabilité » d’un écran comme le nombre de pixels qui peuvent y être générés par
unité de longueur par le faisceau d’électrons et toute son électronique de commande : plus particulièrement,
cette notion d’adressabilité est liée à l’aptitude du système à pouvoir « allumer » ou « éteindre » un nombre
n de pixels distincts ( c.à.d. dont les pics d’intensité de lumière émise sont distincts, même si les taches de
lumière se « recouvrent » partiellement en leurs zones de moindre intensité ) lors du balayage sur une
longueur d’un pouce d’une ligne horizontale.
Ce concept d’adressabilité est également lié au concept classique d’ « adressage » des données dans les
mémoires de l’ordinateur : chacun des bits décrivant, dans une Bitmap monochrome, l’état allumé ou éteint
d’un pixel possède en effet une « adresse » bien spécifique, en corrélation avec la structure d’enregistrement
de ces données.
La « Distance entre Pixels » ( U.S. : « Interdot Distance » ) correspond à la distance entre pics de
lumière : cette distance est évidemment l’inverse de l’adressabilité.
Cette distance peut être un peu plus petite que le diamètre du pixel, afin de permettre une certaine « fusion »
visuelle entre 2 dots adjacents et ce, pour que les formes générées puissent être « adoucies ».
Evidemment aussi, plus la fusion est importante, moins le « détail » de l’image est visuellement
perceptible : l’ajustement de la distance entre pixels en fonction de la taille du pixel est ainsi une question
de compromis.
La définition de la « Résolution » d’un écran fait appel à vos souvenirs du cours de Physique « Optique » :
il s’agit en effet d’un concept étroitement lié à celui du « Pouvoir Séparateur » de l’œil, appelé aussi
« Pouvoir Résolvant » : deux points lumineux peuvent être distingués par l’œil si leurs images se forment
sur 2 cellules distinctes de la rétine.
Le Pouvoir Séparateur se mesure par l’angle AOB minimum selon lequel l’œil « O » est susceptible
d’encore pouvoir distinguer 2 points « A » et « B » :
A
1 minute d'arc
O
B
Pouvoir séparateur de l'oeil
A la distance usuelle d’observation d’un écran d’ordinateur, soit 65 cm, la distance entre A et B est de
l’ordre de 2 dixièmes de mm ( 0.1891 mm ).
Ainsi, en écartant 2 pixels de diamètre 0.125 mm de cette valeur minimun 0.189 mm, un recouvrement des
pixels n’existerait que pour leurs zones à moins de 50 % d’intensité lumineuse, pour autant que leurs
courbes de Gauss de répartition d’intensité soient suffisamment « étalées ».
Ce contexte « physiologique » de la définition du Pouvoir Résolvant implique alors, corrélativement, que la
« Résolution » d’un écran se mesure expérimentalement comme étant la limite supérieure du nombre de
lignes alternativement noires et blanches tracés par pouce de longueur ( verticale ou horizontale : les
résolutions peuvent différer dans les 2 directions ) sur écran qu’un observateur à 65 cm de l’écran est encore
susceptible de distinguer : les CRT monochromes graphiques qui ont existé sur le marché affichaient ainsi
couramment des résolutions de l’ordre de 120 lignes par pouce, c.à.d. que les rangées de pics
correspondant aux pixels de lignes étaient écartés ( distance inter-ligne ou, de façon équivalente,
« interdots » ), de 0.21 mm.
Expérimentalement, on utilise une grille de lignes parallèles dont l’interdistance entre lignes est modulée
via tension ( pour le cas des plaques ) ou via courant ( cas des bobinages ) du dispositif de déflexion du
faisceau d’électrons et on relève à partir de quel nombre de lignes, sur une largeur mesurée, ces lignes se
fondent en un grisé uniforme : il a été montré que cette fusion apparaissait lorsque l’interdistance entre 2
lignes noires valait le diamètre pour lequel l’intensité du spot vaut 60 % de l’intensité maximum de pic d’un
pixel.
Cette résolution est en fait typiquement une caractéristique « Hardware » de l’écran : les réseaux de lignes
sont en effet générés indépendamment d’une induction « Software » par Bitmap .
Vous pourrez simuler cette expérience avec DesignCAD : supposons que vous travaillez avec un écran à
1024 x 768 pixels : vous estimerez d’abord – éventuellement en vous aidant d’une latte - quelle proportion
de largeur occupe la partie utile de l’écran graphique par rapport aux parties occupées par les icônes de
menu.
Pour l’exemple traité ici, la largeur de plage utile est de l’ordre de 80 % de la largeur totale .
Précisez alors : « Cotation / Unité entre 2 Points / Poser 2 points +/- sur la même horizontale aux extrémités
Gauche et Droite de la zone utile de dessin / Indiquer comme nombre d’unités « écran » correspondant à la
distance entre les 2 points : « 800 ».
Tracez ensuite une verticale de haut en bas.
Tracez alors quelques parallèles à gauche et à droite à distance imposée : « 2 ».
La simulation consiste à se rapprocher et à s’éloigner de l’écran : pour un certain éloignement, vous
observerez de façon très caractéristique le phénomène de fusion des lignes en un rectangle grisé où les
lignes deviennent indiscernables ( v. p. suivante ).
Simulation en DesignCAD de la grille de mesure ( Shrinking Raster ) de résolution d’écran
Si la résolution verticale ( mesurée avec un réseau de lignes horizontales ) est principalement fonction
du diamètre du pixel, la résolution horizontale ( mesurée avec un réseau de lignes verticales ), par contre,
est non seulement tributaire de cette taille de pixel, mais encore de l’aptitude de l’électronique de
commande de tension de grille aux « Off / On » du faisceau d’électrons un nombre n / 2 de fois « On » et
n / 2 de fois « Off » pour « allumer » un pixel puis «éteindre » le pixel suivant immédiatement sur la ligne
horizontale composée de n pixels parcourue par le faisceau en un temps donné pour y générer les pixels
alternativement Blancs et Noirs composant les lignes du réseau vertical de mesure.
Cette aptitude à générer les « Off / On » avec une vitesse suffisante est en relation avec la « Bande
Passante » ( U.S. : « Bandwidth » ou «Video Dot Rate » ) du moniteur, comme expliqué ci-après :
Soit un moniteur où le rafraîchissement est de 60 Hz et soit un écran à 103 lignes ( hor. ) de 103 pixels :
-
106 pixels sont donc parcourus 60 fois par seconde par le faisceau
-
6 x 107 pixels sont donc parcourus par seconde
-
le temps de parcours par pixel vaut donc ( 10-7 / 6 ) = 0.167 x 10-7 = 17 x 10-9 seconde
= 17 nano-seconde
-
le calcul ci-dessus ne tient compte du retour de faisceau ni entre lignes ni en diagonale
en fin de chaque cycle de parcours d’écran, retours qui consomment en fait une fraction
non négligeable du temps et qui réduisent ainsi le temps de parcours dédicacé à chaque pixel :
le temps de parcours par pixel est en fait réduit à l’ordre de 11 nano-seconde
-
le temps nécessaire pour un « On / Off » est donc de 22 nano-seconde
-
la fréquence des « On / Off » vaut donc ( 1 / ( 22 x 10-9 )) = 45 x 106 Hz
= 45 Méga-Hertz = 45 MHz
-
cette fréquence minimale théorique doit encore être accrue en pratique pour « affiner »
l’impact du faisceau sur chaque pixel et donner lieu à des spots de lumière dont la répartition
gaussienne est plutôt en pic qu’étalée et qu’ainsi , les bords des pixels apparaissent plus nets, ce qui
est essentiel pour un moniteur graphique à haute résolution : dans cet objectif, la fréquence des
« Off / On » est au moins doublée par rapport au chiffre précédent et cette fréquence est alors ce
qu’on appelle la Bande Passante du moniteur, dont l’ordre de grandeur pour les moniteurs à haute
résolution N.B. est de l’ordre courant de 100 MHz.
La Bande passante est donc en fait une grandeur caractéristique de la qualité du tube et caractérise les
performances en fréquence du dispositif de modulation de l’intensité du faisceau d’électrons.
En pratique, on peut évaluer la Bande passante minimum admissible en multipliant le nombre de pixels
affichables dans la définition maximum de l’écran par la fréquence de rafraîchissement pour cette définition
et en accroissant la valeur obtenue de 20 % : p.ex., pour un moniteur de définition maximum 1920 x 1440
pixels pour laquelle la fréquence de rafraîchissement est de 74 Hz, l’évaluation de la bande passante
minimum admissible conduit à la valeur 205 MHz .
Pour le moniteur PHILIPS « Brillance 109P40 » de 19’’( prix fin 2002 : +/- 300 Euros ) présentant cette
définition et cette fréquence de rafraîchissement, le Constructeur annonce une bande passante de 261 MHz.
Pour son modèle « Brillance 109B40 » un peu moins coûteux ( +/- 200 Euros ) de même définition
maximum mais de fréquence de rafraîchissement moindre pour cette définition, la Bande passante annoncée
par le constructeur n’est plus que de 203 MHz.
Pour un écran « couleurs », la surface interne de l’écran est constituée d’une mosaïque de zones
élémentaires contiguës appelées « luminophores » susceptibles d’émettre chacune une lumière de l’une des
3 couleurs fondamentales R, G, B ( Red, Green, Blue ) lorsqu’elles sont frappées par l’un des 3 faisceaux
d’électrons émis par les 3 canons à électrons équipant les moniteurs couleur CRT.
Des études physiologiques sur la vision colorée ont en effet démontré que l’œil répondait aux stimuli avec
des maxima de sensibilité distincts se situant dans le Rouge, le Vert et le Bleu et qu’une couleur queconque
peut être constituée par un mélange de ces 3 couleurs.
Chaque triplet de luminophores est ainsi souvent disposé triangulairement et constitue un pixel ; la Fig. ciaprès schématise le modèle couramment mis en oeuvre pour les écrans de moniteurs vidéos informatiques
( l’invention en 1949 de ce type de tube est dû à la firme U.S. R.C.A. « Radio Corporation of America » ,
l’inventeur étant l’ingénieur David SARNOFF ; cette invention concernait, au départ, les premières
télévisions « couleurs » ) :
B
G
R
G
B
R
G
B
R
G
B
R
B
G
B
G
R
G
R
B
R
G
B
B
G
B
G
R
G
R
R
G
B
R
G
B
R
G
R
R
G
B
R
A noter que, des précautions particulières restant toutefois à prendre pour que chaque faisceau n’atteigne
que les luminophores de l’une des 3 couleurs R, G ou B, la solution technologique consiste à disposer, à
faible distance de l’écran, une plaque métallique perforée de petits trous, appelée « Masque » ( « Shadow
Mask CRT » ), à raison d’un trou par triplet de luminophores et vers lesquels convergent les faisceaux
issus des 3 canons.
Ces trous sont rigoureusement disposés à la fois par rapport aux triplets de luminophores et aux canons à
électrons pour garantir une focalisation telle que les luminophores d’un type de couleur R, G ou B ne soient
excités que par le faisceau provenant du tube à électrons correspondant, commandé en amont par contrôleur
vidéo pour donner lieu à cette couleur lorsque ses électrons frappent le luminophore susceptible de générer
cette couleur :
Blue
Green
Red
3 Faisceaux d'électrons
3 CANONS A ELECTRONS
R
G
B
MASQUE
ECRAN
PRINCIPE DU MONITEUR COULEUR CRT A MASQUE
En jouant avec l’intensité de chacune des 3 couleurs primaires R, G, B et compte tenu que les
luminophores constituant un triplet sont contigus et à très faible distance l’un de l’autre, l’œil ne les
discrimine pas et intègre les 3 éléments en un seul, le pixel, comme s’il s’agissait d’un seul et unique
point, dont la nuance de couleur résultera du mélange des 3 couleurs d’intensités diverses correspondant
aux 3 luminophores du pixel, mélange susceptible de donner lieu à une large palette de couleurs
perceptibles par l’œil.
Aux perforations de ce masque correspondent les triplets disposés en « delta » sur la face interne de l’écran
et donc les pixels affichés.
La grandeur qui caractérise le masque est ce qu’on appelle le « Pas de Masque » dit aussi « Pas de
Perforation du Masque » ( U.S. : « Pitch » ) : cette grandeur correspond à la distance séparant les centres
des perforations du masque métallique disposé contre et derrière l’écran proprement dit et donc aussi,
corrélativement, la distance séparant 2 points ( 2 triplets ) sur l’écran.
Il convient toutefois de distinguer ce pitch « vrai » du pitch « horizontal », le second étant souvent
annoncé dans les catalogues de fabricants de moniteurs parce que plus petit que le premier, dans une
proportion égale à sin 60°, soit 0.866 fois plus petit : à un pitch vrai de 0.28 mm correspond donc un pitch
horizontal de 0.24 mm, c.à.d. une valeur commercialement plus avantageuse :
ai h
r
V itc
P
Hauteur
R
R
B
G
B
G
R
Triangle équilatéral
G
B
R
G
B
Pitch
Horizontal
1 Pixel
Le nombre de perforations doit évidemment être égal au nombre maximum de pixels affichables sur l’écran,
ce nombre de pixels étant par ailleurs ce que l’on appelle la « définition d’écran » intrinsèque aux
performances du moniteur.
Pour des raisons technologiques, le nombre de perforations est toutefois toujours un peu supérieur à la
définition d’écran .
Très usuellement ( cf. catalogues technico-commerciaux des moniteurs ), cette définition d’écran est aussi
appelée, improprement, « résolution » et, actuellement, la grande majorité des écrans sont susceptibles
d’afficher toute une gamme de « résolutions » : chaque moniteur reste cependant optimisé pour une
« résolution recommandée » pour laquelle la fréquence de rafraîchissement est maximum, les résolutions
supérieures étant en général entachées d’une moindre fréquence de rafraîchissement.
Comme vous le savez certainement, outre leurs performances d’affichage, les écrans sont caractérisés par
leurs dimensions et il est d’usage de les caractériser par la dimension de la diagonale exprimée en
« pouces » ( 1 pouce = 1 inch = « ‘’ » = 25,4 mm ).
Les Standards sont 14’’, 15’’, 17’’, 19’’, 20’’, 21’’ et 22’’ ; leurs coûts ont d’ailleurs très sensiblement
décru au fil des années ( les « 17’’ » étaient encore vendus aux environs de 60 à 100.000 BEF en 1993,
tandis que fin 2002, ces « 17’’ » se trouvent aux environs des 200 à 300 Euros ; un « 21’’ » de qualité
s’acquiert fin 2002 à +/- 1000 Euros ).
Comme la technologie des moniteurs graphiques CRT est directement dérivée de celle des moniteurs TV,
les écrans graphiques pour PC ont respecté la norme TV, c.à.d. l’imposition de trames rectangulaires à
rapport constant « largeur / hauteur » = 4 / 3.
C’est pourquoi les Standards d’affichage ( type « 1024 x 768 » ) présentent toujours le rapport Nombre de
pixels par ligne / Nombre de pixels par colonne ( ou, de façon équivalente : Nombre de lignes ) = p.ex.
1024 / 768 = 4 / 3 .
Ces Standards sont définis par la « Video Electronics Standards Association » ( VESA ), consortium de
plus de 100 cosignataires de l’industrie informatique, dont évidemment INTEL et AMD et tous les grands
constructeurs de matériel, comme IBM.
IBM est d’ailleurs à l’origine de la résolution 1024 x 768 : en 1987, premiers moniteurs couleurs à cette
résolution en 16 couleurs affichables sur 262.144 : moniteur « 8514 » avec carte graphique « 8514/A ».
L’un des 1ers standards, le « VGA » ( «Video Graphic Array » ) est le fondement des modes graphiques
actuels : il permettait un affichage à 640 x 480 points en 16 couleurs et à 320 x 200 points en 256 couleurs,
chaque point étant codé en 8 bits, en mode dit « entrelacé ».
Ce mode, suranné, était utilisé pour permettre d’afficher des images à haute résolution malgré une bande
passante trop faible : ce système affiche alternativement les lignes paires et les impaires .
Ce mode a notamment été introduit par IBM en 1990 sur les PS/2 selon un Standard alors appelé « XGA »
pour permettre l’affichage de 1024 x 768 points en 256 couleurs en mode entrelacé.
Pour des questions ergonomiques de confort visuel ( le mode « entrelacé » provoque en effet une grande
fatigue visuelle ) est aujourd’hui abandonné au profit du mode « non entrelacé », tel que nous l’avons
d’ailleurs décrit dans les explications concernant le balayage d’écran ; l’évolution technologique qui permet
de plus grandes bandes passantes le permet actuellement.
Les « Résolutions » Standards actuelles sont :
-
800 x 600 ( SVGA )
1024 x 768
( XGA )
1152 x 864
1280 x 1024
( SXGA )
1600 x 1200
( UXGA )
1920 x 1080 ( QXGA )
1920 x 1440
2048 x 1536 ( QXGA )
Le pitch sera évidemment tributaire, à la fois de la dimension « physique » de l’écran ( à noter qu’une
partie de l’écran est toujours logée dans le capotage externe et, par conséquent, un écran de « 17’’ » ne
présentera en fait qu’une zone utile de « 16’’ », la différence étant toujours de +/- 1’’ pour les CRT , par
contre, ce n’est pas le cas des écrans plats LCD ) et de la résolution maximum qu’il est susceptible
d’afficher mais l’ordre de grandeur moyen du pitch vrai tourne autour des 0.25 mm.
Etant donné le pouvoir de résolution de l’œil ( 0.1891 mm à 65 cm ), il est en effet inutile de faire descendre
le pitch sous la barrière des 0.2 mm. Toutefois, plus le pitch est petit, plus « fin » sera le détail observable
sur l’écran et donc, inversement, il ne convient pas d’aller au-delà de 0.28 mm si l’on veut garder une
définition correcte de l’image.
La plupart des écrans graphiques CRT de qualité offrent un pitch vrai de 0.24 mm pour un diamètre de pixel
( « Dot Size » ) de 0.25 mm, c.à.d. qu’ils admettent un léger recouvrement des pixels.
Les écrans très spécialisés de grandes dimensions ( les « 22’’ » ) pour le graphique où la finesse du détail
est un élément déterminant ( p.ex. les analyses d’images satellites en G.I.S.- Systèmes d’Informations
Géographiques - ou la conception de circuits imprimés ou l’imagerie médicale) privilégient davantage le
piqué du détail : le pitch est alors un peu supérieur au diamètre du pixel, p.ex. 0.28 mm pour le pitch vrai et
0.24 mm pour le diamètre de pixel.
Le choix d’un écran graphique dépend du nombre de pixels des fichiers graphiques que vous comptez
y traiter .
Voici quelques recommandations à ce sujet :
-
images en 800 x 600 pixels : écrans 15’’
Si vous utilisez un écran trop grand pour la résolution affichée, les images y seront trop agrandies
( plusieurs pixels utilisés pour représenter un terme de bitmap ) et vous y perdrez en finesse du détail.
Pour vous en convaincre, réglez par software, dans Windows et si vous utilisez un écran à 1024 x 768 pixels
« physiques », la résolution à 640 x 480 pixels : ( « Poste de travail / Panneau de configuration / Affichage /
Propriétés de l’affichage / Paramètres ) puis réglez par curseur à 640 x 480 pixels .
Observez alors attentivement la nouvelle image dans cette définition :
Non seulement les fenêtres se chevauchent, mais surtout le piqué des détails s’est fortement dégradé par
rapport à l’affichage en 1024 x 768 pixels.
1.4. LES IMAGES ACHROMATIQUES ET LES IMAGES « COULEUR »
L’image « Yosemite.jpg » sur laquelle nous avons déjà travaillé est typiquement de type Noir et Blanc, avec
dégradé de gris : le logiciel IrfanView la décrit ( « Image / Information » ) comme suit :
Il s’agit d’une image codée à 8 bits par pixels, à 256 nuances allant du Blanc au Noir, avec 254 nuances de
gris intermédiaires.
Ceci signifie d’abord que l’image est achromatique, c.à.d. que l’œil qui la perçoit n’éprouve aucune
sensation de couleur.
Ensuite, chacun des 1024 x 768 pixels, au lieu de ne présenter que 2 états possibles d’intensité lumineuse,
c.à.d. de luminance comme c’est le cas des images strictement Noir et Blanc, présente au contraire toute
une gamme intermédiaire de luminances : 256 luminances en fait. Corrélativement, l’œil perçoit aussi 256
luminosités distinctes pour ces pixels.
Pourquoi alors 256 et non 255 ou 257 ?
Il a été montré par IrfanView que l’image était codée en 8 bits par pixel , c.à.d. en 1 octet / pixel.
Ces 8 bits peuvent, chacun, présenter la valeur 0 ou 1.
Il existe donc un grand nombre d’arrangements possibles pour un tel octet, p.ex :
( 10000000 ), ( 00110001 ), ( 10101010 ),…
Pour un codage à 1 bit / pixel , les arrangements seraient ( 0 ) ou ( 1 ), soit 21 arrangements
Pour un codage à 2 bits / pixel, les arrangements seraient ( 00 ), ( 01 ), ( 10 ), ( 11 ), soit 22 arrangements
Pour un codage à 3 bits / pixel, les arrangements seraient ( 000 ), ( 001 ), ( 010 ), ( 011 ),
( 100 ), ( 101 ), ( 110 ), ( 111 ), soit 23 arrangements
…
Et pour le codage à 8 bits / pixels, le nombre d’arrangements vaut 28, soit 256.
A chacun des arrangements correspond effectivement une nuance de gris dans une « palette » de 254
gris + le Noir profond et le Blanc pur ( en tout 256 nuances ), comme il est possible de le faire apparaître
dans IrfanView par « Image / Palette / Edit Palette » :
Par un pointer / cliquer ( B.G.S. ) sur l’un des petits carrés de cette palette, IrfanView fait apparaître des
valeurs « RGB », ce qui signifie qu’en fait, les grisés ont été obtenus par mélange des 3 couleurs primaires
Rouge, Vert et Bleu sur un écran « couleurs » avec des intensités « 151 » égales pour les 3 couleurs : nous
l’expliquerons davantage plus loin.
Considérons alors, théoriquement, une autre image, mais cette fois en 16 nuances de gris sur un moniteur
monochrome : comme 16 = 24, cette image est nécessairement codée en 4 bits / pixel .
Chacun des 16 arrangements possibles ( 0000 ), ( 0001 ), ( 0010), …, ( 1111) correspond à des codages
distincts donnant lieu à 16 nuances de gris ( allant du Blanc au Noir avec 14 gris intermédiaires ) qui
constituent une palette où chacune des couleurs porte un numéro d’ordre ( conversion binaire – décimal :
( 0000 ) = 0, ( 0001 ) = 1, ( 0010 ) = 2, ( 0011 ) = 3, …, ( 1111 ) = 15 [ 0, 1, 2, …, 15 = 16 nombres entiers
consécutifs ] ).
Ces nuances, sur un écran monochrome, sont obtenues en modulant l’intensité du faisceau d’électrons
depuis l’état intensité nulle ( pixel noir éteint ) jusqu’à l’état d’intensité maximum ( pixel de luminance
maximum = pixel blanc ) en passant par 14 intensités croissantes ( pixels de gris de plus en plus clair ).
Rappelons que cette modulation d’intensité du faisceau d’électrons correspond à des variations imposées à
la tension de grille du canon à électrons.
Un premier modèle d’architecture élémentaire peut être envisagé pour ce cas : il consiste à organiser la
mémoire vidéo en 4 plans-mémoire, chacun contenant, pour un pixel donné, un bit de codage ; pour chaque
pixel, les 4 bits de codage consignés dans ces 4 tables sont transmis à un convertisseur numérique /
analogique « N / A » ou « DAC » ( « Digital Analogic Converter » ) qui commande le réglage de la tension
de grille ( signal analogique ) en fonction de la valeur ( signal numérique ) transmise par les 4 bits :
4 PLANS MEMOIRE
1
CONVERTISSEUR DAC
Faisceau
Tension
de Grille
du CRT
0
1
1
PIXEL
ECRAN
Revenons alors aux 256 nuances de gris du tout 1er exemple de ce § : la différence est qu’elles sont générées
sur un écran couleur à 3 canons R, G, B.
Le modèle de couleurs RGB correspond à un système cartésien dont les 3 axes figurent les intensités des 3
couleurs primaires Red, Green, Blue, ces intensités allant chacune, par pas de 1, de la valeur 0 à la valeur
255 :
Bleu
255
Bleu
Cyan
Blanc
Magenta
Gris
0
Rouge
Rouge
255
Noir
Vert
Vert
255
Jaune
MODELE RGB
Chaque triplet, p.ex. ( Rouge = 28, Vert = 126, Bleu = 212 ) donne lieu à une couleur bien précise du
spectre visible par combinaison additive des 3 composantes primaires R, G, B et correspond à un point
du cube de la Fig. précédente., soit à l’intérieur de ce cube, soit sur ses faces ou arêtes.
Pour que vous l’expérimentiez, appelez le programme Windows « Paint » et double-cliquez ( B.G.S. sur
l’une des petites cases de couleur au bas à gauche de l’écran : une Boîte de dialogue « Modifier les
couleurs » apparaît sur l’écran :
Cliquez sur le bouton : « Définir les couleurs personnalisées », une nouvelle Boîte de dialogue apparaît :
Faites varier ( cf. rectangle et flèche ) les valeurs R, G, B entre 0 et 255 [ valeurs ENTIERES ! ] en écrivant
ces valeurs par clavier dans chacune des petites cases et observez dans le rectangle coloré « Couleur unie »
les résultats.
En particulier, observez les résultats suivants pour des triplets de valeurs particulières :
( 0, 0, 0 ) : Noir ( 255, 0, 0 ) : Rouge vif ( 0, 255, 0 ) : Vert vif ( 0, 0, 255 ) : Bleu vif
( 255, 255, 0 ) : Jaune vif ( 255, 0, 255 ) : Magenta ( 0, 255, 255 ) : Cyan
( 255, 255, 255 ) : Blanc pur
Puis composez des triplets dont les 3 termes sont égaux : ( 50, 50, 50 ), ( 100, 100, 100 ), … : vous
constaterez que vous obtenez alors diverses nuances de gris.
Comme les 3 termes des triplets sont strictement égaux pour la palette des nuances de gris, une seule valeur
peut donc caractériser les 3 termes ensemble et comme il existe seulement 256 valeurs différentes, soit 28
valeurs différentes, 8 tables ou « plans de mémoire » en binaire seraient suffisants : d’où un codage possible
en 8 bits/ pixel de l’image en dégradé de gris.
On pourrait ainsi, en principe et dans ce cas particulier d’image en dégradés de gris, transmettre, pour
chaque pixel, via convertisseur DAC, les 8 bits correspondants lus dans les 8 plans mémoire pour
commander de façon identique les 3 canons.
Mais supposons alors que, sur le moniteur couleur où se trouve affichée l’image « Yosemite.jpg » en
dégradés de gris, l’utilisateur souhaite modifier un certain ton de gris en le transformant en rouge vif.
Le problème qui se pose immédiatement est que cette fois, les 3 canons à électrons ne peuvent plus recevoir
les mêmes instructions, tout au moins pour les pixels qui doivent s’afficher en rouge puisqu’en effet, le
triplet de codage RGB est : 255 pour le Rouge, 0 pour le Vert et 0 pour le Bleu.
Il faudrait donc envisager 3 x 8 tables , chacun des groupes de 8 tables étant dédicacé à la commande de
l’un des canons à électrons, via DAC bien entendu et chacun de ces groupes de 8 tables donnerait ainsi lieu
à 256 possibilités pour chacune des valeurs R, G, B : la gamme de teintes possibles correspondant aux
arrangements des 3 valeurs sélectionnées parmi 256 donnerait donc lieu à 2563 = 16.777.216 nuances.
Une telle gestion de mémoire étant peu compatible avec les temps d’accès et de lecture des mémoires il y a
encore relativement peu de temps, une solution a été trouvée à l’époque ( avant +/- 1990 ) , mais solution
qui limite alors toujours, dans notre cas, l’affichage à 256 « couleurs », dont 255 nuances de gris et 1
Rouge : cette solution est de pré-coder une palette de 256 couleurs, comprenant donc les 255 nuances de
gris et 1 Rouge. Une telle solution se retrouve aujourd’hui encore dans beaucoup de logiciels graphiques,
comme d’ailleurs dans le petit logiciel « Paint » de Windows, qui date d’ailleurs de l’époque précitée.
Cette fois, les 256 valeurs correspondant aux 256 arrangements possibles des 8 bits ne correspondent plus
directement aux valeurs RGB, mais sont simplement des adresses dans la liste des teintes offertes par la
palette, chacune des teintes étant par ailleurs précodée dans cette palette via 3 valeurs RGB qui n’ont alors
plus aucun rapport avec leur adresse, même si le nombre d’adresses distinctes est aussi 256, comme le
nombre de valeurs possibles dans le codage RGB.
L’architecture d’un tel modèle est cette fois la suivante :
8 PLANS MEMOIRE
0
Adr.
1
R
0
G
1
1
0
1
1
B
Adresse
Valeur R
DAC
Valeur G
DAC
Valeur B
DAC
Palette des 256 couleurs
B
G
R
ECRAN
PRINCIPE DES TABLES DE COULEURS
Réfléchissons davantage à propos de cette palette et plus particulièrement à propos de ce que signifie le
nombre de couleurs évidemment différentes qui y figurent.
En fait, ce nombre peut prendre 2 significations distinctes
- d’une part, pour notre exemple, le nombre 256 signifie le nombre de couleurs distinctes adressables via le
codage en 8 plans mémoire pour chaque pixel ;
- mais cela signifie-t-il, d’autre part, qu’il n’existe alors que 256 couleurs possibles au plus ?
En fait, cela va dépendre du nombre de bits attribués dans les colonnes R, G et B de la table des couleurs
pour composer ces couleurs, comme expliqué ci-après .
Supposons que les codages figurant dans les colonnes R, G, B de la table des couleurs soient chacun à 4
bits, p.ex. ( 0101 ) pour R, ( 0011 ) pour G, ( 1010 ) pour B.
Les 16 arrangements possibles de chaque groupe de 4 bits valent, en décimal et par conversion Binaire /
Décimal :
( 0000 ) = 0
( 0100 ) = 4
( 1000 ) = 8
( 1100 ) = 12
( 0001 ) = 1
( 0101 ) = 5
( 1001 ) = 9
( 1101 ) = 13
( 0010 ) = 2
( 0110 ) = 6
( 1010 ) = 10
( 1110 ) = 14
( 0011 ) = 3
( 0101 ) = 7
( 1011 ) = 11
( 1111 ) = 15
Ceci sera converti par les 3 DAC des canons à électrons comme suit : un codage binaire( 0101 ) qui est
p.ex. égal à 5 en décimal va commander, via le DAC, une intensité du canon égale aux ( 5 / 15 ) de son
intensité maximum.
Comme chacun des 3 canons R, G ou B présente ainsi 16 possibilités d’intensité, la couleur résultante du
pixel résultant du mélange des couleurs R, G et B des 3 luminophores du pixel subissant l’impact simultané
des 3 faisceaux d’électrons issus des 3 canons, chacun agissant avec une certaine intensité, le nombre total
de couleurs possibles vaut 16 3, soit 4096 couleurs.
En tel cas de codage à 3 x 4 bits pour les R, G et B, les 256 couleurs pourront être choisies parmi 4096
couleurs. La table des couleurs contient dans ce cas 12 bits par entrée.
Considérons alors la possibilité d’un choix beaucoup plus vaste (toujours pour une table à 256 entrées) : soit
ainsi un codage des R, G, B dans la table à 3 x 8 bits, soit 3 octets.
En ce cas, chaque octet présente 256 arrangements possibles de bits, ce qui fait que chaque canon travaillera
selon 256 niveaux d’intensité et que, in fine, il existera 2563, soit 16.777.216 couleurs possibles pour les
pixels et que les 256 couleurs de la table des couleurs pourront donc être choisies dans un ensemble de
16.777.216 nuances. La table des couleurs contient dans ce cas 24 bits par entrée.
Il est clair que pour un logiciel DAO, l’usage d’un choix de couleurs aussi abondant n’est pas très utile :
ce qui est important pour un tel système est de pouvoir distinguer des traits ou des ensembles de traits de
type « vectoriel » : DesignCAD p.ex. met à disposition une palette de 64 entrées, soit 64 couleurs de dessin
,que l’utilisateur peut toutefois personnaliser à son gré parmi les 16 millions de couleurs disponibles ( s’il
travaille avec une carte graphique permettant de les obtenir ) : ces 64 entrées correspondent à un codage de
pixel ( pour l’adressage dans la table ) à 6 plans mémoire.
Voici la Boîte de dialogue « couleurs » de DesignCAD montrant cette palette à 64 entrées :
Palette de 64 couleurs à choisir par l’utilisateur parmi 16.777.216 et destinée à
remplacer les couleurs standard de base
Palette « Standard » de 64 couleurs
En illustration de cette architecture « par palette de couleurs », revenons à présent à l’image
« Yosemite.jpg » ouverte dans IrfanView.
Par pointer / cliquer ( B.G.S. ) sur « Image » puis, dans le menu déroulant sur « Palette » puis, dans le sousmenu de « Palette », sur « Edit Palette », la palette des 256 nuances de gris selon laquelle est construite
l’image photographique apparaît à l’écran :
Un double-clic sur l’une des cases va faire apparaître une Boîte de dialogue où l’utilisateur va pouvoir
changer la nuance de gris par une couleur quelconque de son choix, parmi 16.777.216 possibilités.
Choisissez un gris clair ( p.ex. 11ème ligne, 7ème colonne ) et remplacez cette couleur par une composition R
= 75, G = 20, B = 20, ce qui vous donnera un brun plutôt foncé :
Brun foncé
Nouvelles valeurs R, G, B
Voyons le résultat de l’application de cette nouvelle palette : un certains nombre de pixels – ceux qui
avaient primitivement la nuance du gris à laquelle on a substitué le brun – sont devenus bruns :
l’adresse dans la table de couleur n’a pas changé, seul ont changé les contenus des codages R, G, B
de la ligne de la table caractérisée par cette adresse.
Ce changement de teinte est spécialement visible dans le ciel et son reflet dans l’eau :
D’autres pixels de même gris, çà et là, sont aussi devenus bruns, comme le montre l’agrandissement de la
paroi rocheuse où des points foncés sont à présent bien visibles sur la paroi claire:
Contrairement au cas des dessins de type DAO « vectoriel », pour les photographies « couleurs » ou les
images de synthèse en « Rendu réaliste », le nombre de couleurs réellement affichées simultanément doit
impérieusement dépasser les 256 couleurs.
Dans l’observation visuelle d’un tel type d’image, des dégradés de couleurs à faible gradient participent
en effet très étroitement à notre perception des détails.
Pour vous en convaincre, ouvrez l’image « Cabane dans un champ » fournie par « Windows » dans
IrfanView : Il s’agit d’une image à 1024 x 768 pixels, en codage 3 x 8 bits, soit 24 bits ou 3 octets : la taillemémoire de la pixmap vaut donc ( 1024 x 768 x 3 ) = 2.359.296 octets, soit, en divisant par 1024 ( 1 Ko =
1024 octets ) : 2.304 Ko ou, en divisant encore par 1024 ( 1 Mo = 1024 Ko ) : 2.25 Mo.
Remarquez que cette valeur correspond à ce qu’IrfanView indique à gauche dans la barre sous l’image.
La question est : combien de couleurs sont-elles affichées, 256 ou beaucoup plus ?
Irfanview procède à tel comptage via commande « Image / Count Colors Used » : la Boîte d’information
qui apparaît sur l’écran en comptabilise 133.399 distinctes et simultanément affichées.
Nous allons à présent diminuer le nombre de couleurs et le réduire à 16 couleurs ( Commande
IrfanView : “Image / Decrease Color Depth” ) : si vous réalisez vous-même cet essai, vous constaterez que
le piqué des détails devient nettement moins bon : sur la reproduction « papier » de ce cours, cela
n’apparaîtrait toutefois pas très explicitement ; aussi nous vous proposons donc cette comparaison de
qualité dans le piqué des détails sur des agrandissements d’une même zone, d’abord pour l’image à 24 bits /
pixel, ensuite pour l’image à 4 bits / pixels ( cf. p. svte. ).
Image à 24 bits / pixel
Image à 4 bits par pixel
Agrandissons un détail pour rendre le phénomène encore plus explicite :
L’image transformée est donc codée en 4 bits / pixel, comme le confirme la barre d’IrfanView
apparaissant sous cette nouvelle image en 16 couleurs :
La taille-mémoire est simultanément passée à : ( 1024 x 768 x 8 ) / 1024 = 384 Ko ( = 384 KB = 384
« Kilo-Bytes » en U.S. ) .
Que signifient ces 4 bits / pixel ?
4 n’est pas un multiple de 3 comme les 24 bits / pixels et ce nombre « 4 » ne peut donc pas représenter 3 x
un certain nombre de bits codant chacune des intensités de couleurs R, V, B.
Tentons une autre expérience et réduisons cette fois le nombre de couleurs de l’image originale à 256
couleurs et examinons à nouveau le renseignement fourni par IrfanView à propos du codage pour cette
image transformée en 256 couleurs :
A nouveau, on retrouve un codage non multiple de 3 : ici 8 bits / pixel.
La différence fondamentale entre les 3 images codées à 24 bits / pixel, 4 bits / pixel et 8 bits par pixel est
que, dans les 2 derniers cas, l’architecture de pixmap est de type « palette », tandis que dans le premier, il
s’agit d’une organisation de pixmap où chaque pixel est codé en « Mode Couleur Direct ».
Ce Mode Couleur Direct ne passe plus par la définition d’une palette mais code directement le pixel par
un ensemble de 3 champs de 8 bits, un par intensité de couleur R, G ou B.
Ce mode se justifie par le fait que le très grand nombre de couleurs simultanément présentes dans une
image de type « photo » impliquerait la constitution d’une palette gigantesque, contrairement au cas des
images à faible nombre de couleurs ( 2 à 256 ) simultanément affichées.
Ceci signifie aussi que le nombre de bits / pixel annoncé pour ces divers types d’images ne recouvre pas la
même signification, bien que l’on parle indifféremment pour ce nombre de bits / pixel, quelle qu’en soit la
signification réelle, de « Profondeur de Couleurs » :
- pour les images Noir et Blanc , 1 bit / pixel caractérise la structure en simple bitmap ;
le Noir et Blanc est d’ailleurs fréquemment qualifié, au point de vue de sa « profondeur de
couleurs », d’image « Bitmap » ( dans le logiciel de retouche ADOBE PHOTOSHOP,
c’est ainsi que les images «Noir et Blanc sont désignées ) ;
- pour les images de 16 à 256 couleurs, le nombre n de bits / pixels concerne le nombre de plans
mémoire qui permettent le codage de l’adresse d’une couleur dans une palette pour
chacun des pixels : pour une image à 1024 x 768 pixels p.ex., en 16 couleurs définies par
une palette de 16 couleurs, il existera 4 plans de 1024 x 768 termes binaires.
La palette fonctionnant sur le principe de l’adressage de chacune des couleurs, c.à.d.selon la
définition d’un « Index » pour chacun des n descriptifs, on parle alors fréquemment de
« Couleurs Indexées ».
La palette elle-même et le nombre de bits qu’elle contient ne sont pas pris en considération pour la
désignation du « nombre de bits / pixel » dans ce mode « Couleurs indexées » : dans une
architecture classique d’ordinateur ( avec DAC ), cette palette est séparée de la mémoire d’image et
inscrite dans un espace-mémoire ( RAMDAC ) du DAC.
Selon la capacité de mémoire vive associée au DAC et en fonction des capacités de conversion
Numérique / analogique de ce DAC, chacune des couleurs primaires y est codée sur p.ex. 5, 6 ou 8
bits. Par ailleurs, une procédure permet à l’utilisateur de sélectionner lui-même les couleurs de cette
palette.
Ce mode « Couleurs indexées » est utilisé pour du graphisme vectoriel ne nécessitant que peu de
couleurs, comme en DAO / CAO (sauf en 3D avec rendus réalistes de haute qualité) ou pour de
petits programmes de dessin d’illustration ( « Paint » de Windows en est un exemple )
- pour les images contenant un nombre de couleurs supérieur à 256, le nombre n de bits par pixel
vaut en principe 3 x le nombre de bits de codage de chacune des couleurs, en série dans la mémoire
( « organisation en mémoire compacte » ) , ce qui évite le recours à une palette et à la méthode de
l’adressage dans cette palette.
Dans certains cas cependant, les 3 champs de bits ne sont pas de longueur égale et, p.ex.,
on peut coder une image à 65.536 couleurs sans palette ( « High-Color » ) par 5 bits pour R, 6 bits
pour G et 5 bits pour B : le codage est dans ce cas à « 16 bits / pixel ».
Comme les images à grand nombre de couleurs correspondent à un grand piqué des détails, comme
les photographies « couleurs », il est d’usage de les appeler « images en couleurs vraies » ou
« images en mode couleur direct ».
Ce mode de travail, dit aussi en « True Color » exige, en architecture classique d’ordinateur, que le
convertisseur numérique / analogique présente des performances suffisantes pour transmettre les
données binaires alors plus abondantes ( trains de 15, 16, 18 ou 24 bits ) sans transiter par la palette.
Remarquons que le codage en 32 bits n’est utile que pour certains logiciels ( type « Adobe
Photoshop ») qui utilisent les 8 bits excédant les 24 bits pour des effets de transparence et
d’opacité par masques appelés « Alpha-Channels ».
Ainsi, si vous essayez d’éditer une palette par IrfanView pour l’image à 24 bits / pixel, en mode « couleur
directe », l’opération sera impossible puisque le codage ne correspond pas au mode « palette ».
Par contre, pour la même image transformée en 4 bits / pixel, en 16 couleurs, il sera tout à fait possible
d’éditer la palette alors en usage, comme le montre la copie de la Boîte d’information et d’édition de
palette, correspondant à ce cas :
Tout ce qui vient d’être exposé peut être synthétisé par le schéma logique suivant qui met en évidence
les 2 modes de transfert de l’information « Pixmap » depuis la mémoire vidéo contenant la pixmap relative
à une image jusqu’à la sortie analogique vers le moniteur :
MEMOIRE
VIDEO
MODE
DIRECT
NON
< 256
COULEURS
OUI
MODE
PALETTE
ADRESSES
POUR
LA PALETTE
1 VALEUR
D'INTENSITE
POUR
LE ROUGE
SELECTION
PAR
PALETTE
1 VALEUR
D'INTENSITE
POUR
LE VERT
1 VALEUR
D'INTENSITE
POUR
LE ROUGE
1 VALEUR
D'INTENSITE
POUR
LE VERT
1 VALEUR
D'INTENSITE
POUR
LE BLEU
1 VALEUR
D'INTENSITE
POUR
LE BLEU
REPARTITION
n bits
n bits
n bits
CONVERTISSEUR
NUMERIQUE /
ANALOGIQUE
POUR LE
ROUGE
CONVERTISSEUR
NUMERIQUE /
ANALOGIQUE
POUR LE
VERT
CONVERTISSEUR
NUMERIQUE /
ANALOGIQUE
POUR LE
BLEU
Signaux analogiques
DAC
ECRAN CRT
SCHEMA LOGIQUE DES 2 MODES COULEURS
1.5. LES CARTES VIDEO
Les signaux analogiques commandant le moniteur CRT pour l’affichage graphique sont générés par un
ensemble de composants intégrés à la carte mère ou dans le chipset de l’ordinateur ( circuits vidéo intégrés )
ou, le plus souvent, sur une carte graphique spécialisée, dite « carte vidéo », installée dans un connecteur
d’extension de la carte mère.
Très globalement, cette carte reçoit des trains d’instructions digitales du processeur central, les traite
localement pour organiser cycliquement ( cf. fréquence de rafraîchissement ) le remplissage structuré
d’une mémoire vidéo spécialisée par le contenu digital de l’écran ( bitmap ou pixmap ) juste avant son
affichage, puis convertit le contenu digital de cette mémoire en signaux analogiques et le transmet en flux
cyclique continu au moniteur CRT.
Le traitement local a pour objectif principal de décharger le processeur central d’un ensemble de tâches
spécialisées, relatives en l’espèce aux opérations graphiques ( ce principe du « traitement local » est
d’ailleurs identique pour ce qui est p.ex. des cartes « son » ), en les déportant vers une unité spécialisée de
traitement, appelée « processeur vidéo ».
L’architecture logique d’une carte vidéo peut ainsi être schématisée comme suit :
SIGNAUX
DIGITAUX
CARTE VIDEO
BUS
AGP
Bus
Interne
PROCESSEUR
GRAPHIQUE
CONNECTEUR
AGP
SIGNAUX
ANALOGIQUES
Bus
Interne
MEMOIRE
VIDEO
CONVERTISSEUR
NUMERIQUE / ANALOGIQUE
CONNECTEUR
CRT
Il est important pour vous de situer cette carte vidéo dans l’architecture logique d’un PC, tout en précisant
qu’au niveau « Hardware », ces cartes se présentent vraiment sous la forme physique de cartes munies d’un
connecteur à n contacts mâles( 44 contacts pour une carte AGP ) qu’il faut glisser dans un connecteur
d’extension fixé à la carte mère du PC et muni des mêmes n contacts, mais femelles.
Au niveau logique, un PC est constitué d’une arborescence hiérarchique de divers périphériques ( dont la
carte vidéo ) qui sont tous reliés au noyau principal, le processeur central ( un Pentium d’Intel ou de type
comparable d’AMD ou Cyrix ) qui exécute une grande partie des calculs et qui coordonne en grande partie
le fonctionnement de l’ordinateur.
Ces liens logiques entre éléments sont ce qu’on appelle les bus, qu’il faut assimiler à des conduites
transférant les informations digitales d’un composant à un autre.
La gestion des circuits reliant les divers composants ( processeur central, mémoire vive, mémoire cache,
bus, … ) est dévolue au chipset ( p.ex. le chipset INTEL 440LX ou « AGPS » susceptible de gérer les
nouveaux bus graphiques AGP – « Accelerated Graphics Port » - à très haut débit ).
Voici ainsi un schéma qui synthétise l’architecture logique d’un PC multimédia « Haut de Gamme » :
MEMOIRE
RAM
BUS
SYSTEME
CONTROLEUR
MEMOIRE
BUS
CONTROLEUR
PCI
SYSTEME
PROCESSEUR
PENTIUM
CHIPSET
PCI / AGP
ECRAN CRT
PONT
AGP
SIGNAUX
DIGITAUX
SIGNAUX
ANALOGIQUES
CARTE VIDEO
Bus
Interne
BUS
AGP
BUS
PCI
PROCESSEUR
GRAPHIQUE
Bus
Interne
CONVERTISSEUR
NUMERIQUE / ANALOGIQUE
MEMOIRE
VIDEO
CONNECTEUR
CRT
CONNECTEUR
AGP
SIGNAUX
DIGITAUX
BUS
PCI
BUS
BUS
BUS
BUS
PCI
PCI
PCI
PCI
CONTROLEUR
USB
MODEM
CARTE
SON
CONTROLEUR
CONTROLEUR
IDE
1394
CONNEXIONS USB
CONNEXIONS
IDE
CLAVIER
SOURIS
SCANNER
TABLETTE
A DIGITALISER
BUS
PCI
CONNEXION
1394
CAMESCOPE
NUMERIQUE
IMPRIMANTE
DISQUE
DUR
CD / DVD-ROM
PLACE DE LA CARTE GRAPHIQUE DANS
LA STRUCTURE D'UN PC MULTIMEDIA
Y.DURAND 12.12.02
Un certain nombre d’explications s’imposent à propos du vocabulaire – et des concepts qui y sont associésutilisé en légendes des 2 figures précédentes ce sera l’objet des § suivants .
1.5.1. LA TRANSMISSION DES INFORMATIONS AU MONITEUR PAR LA CARTE VIDEO
Jusqu’à présent, nous avons parlé d’une conversion des signaux digitaux en signaux analogiques par le
circuit spécialisé, le Ramdac, figurant d’ailleurs comme 3ème composant essentiel sur le schéma de la carte
vidéo.
Ces signaux analogiques sont en fait des micro-tensions comprises entre 0 et 0,7 Volt appliquées aux grilles
de chaque canon à électrons, permettant en principe de générer un nombre infini de couleurs selon la
discrétisation adoptée entre ces 2 valeurs-limites.
Les normes de couleur postérieures au standard EGA défini en 1984 par IBM pour ses PC « AT »
( résolution 640 x 350 pixels en 16 couleurs dans une palette de 64 ), c.à.d. dès que le standard VGA
développé par IBM en 1987 ( 16 couleurs affichables parmi 262.144 en 640 x 480 pixels ou 256 couleurs en
basse résolution 320 x 200 pixels ) ont imposé l’abandon de la technologie dite « d’entrée ( c.à.d. entrée
dans le moniteur ) numérique TTL » ( Transistor Transistor Logic ) qui ne permettait pas un grand nombre
de couleurs ( limitation à 64 couleurs dont 16 affichables simultanément ) au bénéfice de l’entrée dite
« analogique » beaucoup plus modulable.
Cette technologie analogique présente toutefois encore 2 inconvénients : d’une part, des parasites au niveau
du Ramdac peuvent altérer la qualité de l’image et d’autre part, la nouvelle technologie des écrans plats,
typiquement numérique puisque ce sont des centaines de milliers de transistors qui y gèrent
individuellement les pixels ( LCD à matrice « active » ), impose une nouvelle conversion du signal
analogique délivré par le Ramdac numérique / analogique en signaux digitaux de commande de ces
transistors : tel est le cas si vous équipez un PC à écran CRT dont la carte graphique contient le Ramdac
classique d’un nouveau moniteur à écran plat en technologie TFT.
Ces inconvénients ont poussé les Majors de l’industrie informatique ( Intel, Compaq, Hewlett Packard, …)
à développer une nouvelle technologie d’entrée dite « DVI » ( Digital Visual Interface ) qui a commencé à
se commercialiser en 1998.
Cette technologie DVI s’impose actuellement pour tous les nouveaux moniteurs qui cependant, gardent en
général pour la plupart la possibilité d’être branchés aussi sur les cartes classiques à Ramdac de PC plus
anciens, proposant ainsi ( voyez les publicités des nouveaux écrans plats ) ce qui est couramment appelé
« l’affichage multistandard ( vidéo, VGA, DVI ) » qui permet donc leur connexion à la fois sur les cartes
classiques à Ramdac ( VGA ), sur les nouvelles cartes au standard DVI et sur les sorties proprement
« vidéo » ( séquences animées ).
IBM vient ainsi de présenter, fin 2002, un écran plat TFT exceptionnel ( le « T221 » - prix en 2002 de
l’ordre de 14.000 Euros ) de 22.2’’ de diagonale (vraie ) à définition 3840 x 2400 pixels en technologie
DVI : cet écran est couplé avec une carte MATROX G200 quadri-processeurs, le principe général étant que
chaque processeur gère l’affichage d’un quart d’écran .
D’autres fabricants japonais d’écrans ont adopté cette technologie IBM : IIYAMA, TOKOTU et
VIEWSONIC.
Cette entrée DVI exploite la technologie TMDS ( Transition Minimized Differential Signal ) qui se base sur
un algorithme de codage ayant pour objectif de minimiser les transmissions de signaux sur le câble reliant le
moniteur au PC, ce qui limite les interférences et améliore la qualité de transmission ( Bande passante de
1,65 Giga-Byte / seconde par lien TMDS entre DSP émetteurs et récepteurs)
Le processeur graphique et la mémoire vidéo transmettent les trains de 24 bits de la pixmap ainsi que des
trains de paquets de 6 bits de contrôle et des signaux de synchronisation à un Transmetteur composé de 3
processeurs DSP ( Digital Signal Processor ) qui les code selon l’algorithme TMDS, chacun pour l’une des
couleurs R, G, B. et les transmet par 3 groupes de 10 bits ( 8 bits de codage de couleur et 2 bits de contrôle )
à un décodeur-récepteur situé dans le moniteur et composé de 3 processeurs DSP qui pilotent le champ des
transistors « écran » régulant la couleur des pixels.
1.5.2. LA MEMOIRE DE LA CARTE VIDEO
Il est clair que le rôle de cette mémoire vidéo est d’abord de stocker, juste avant l’affichage ( dans des laps
de temps très courts cependant, compte tenu du contexte de rafraîchissement ) les informations digitales
relatives à la pixmap.
Dès lors, comme la taille de la pixmap est directement fonction de la résolution maximum affichable et de
la profondeur de couleur, la taille de la mémoire vidéo qui doit être susceptible d’emmagasiner cette pixmap
sera aussi directement fonction de cette résolution et de la profondeur de couleurs.
Voyons quelques valeurs significatives :
Taille des pixmaps en fonction de la résolution et de la profondeur de couleurs
Résolution
800 x 600
1024 x 768
1280 x 1024
1600 x 1200
1920 x 1440
2048 x 1536
Profondeur de couleur ( Nombre de couleurs simultanément affichables )
16
256
65.536
16.777.216
(+ alpha ch.)
4 bits/pixel
8 bits/pixel
16 bits/pixel
24 bits/pixel
32 bits/pixel
0.23 Mo
0.37 Mo
0.63 Mo
0.92 Mo
1.32 Mo
1.50 Mo
0.46 Mo
0.75 Mo
1.25 Mo
1.83 Mo
2.64 Mo
3.00 Mo
0.92 Mo
1.50 Mo
2.50 Mo
3.66 Mo
5.27 Mo
6.00 Mo
1.37 Mo
2.25 Mo
3.75 Mo
5.49 Mo
7.91 Mo
9.00 Mo
1.84 Mo
3.00 Mo
5.00 Mo
7.32 Mo
10.54 Mo
12.00 Mo
Ces valeurs ne sont pas directement celles commercialisées pour les cartes Vidéo dont la gamme travaille
avec des paliers multiples de 2 Mo : les valeurs les plus courantes sont 2, 4, 6, 8, 12, 16, 32, 64 et 128 Mo.
Certaines cartes de haut de gamme ( ATI Radéon 9500 et 9700 p.ex. ) proposent même, fin 2002, une
mémoire vidéo allant jusqu’à 256 Mo maximum.Fin 2206, des cartes Vidéo à 512 Mo commencent même à
équiper les stations de travail portables ( ex. le HP Compacq 9440 à carte graphique NVIDIA Quadro FX
1500M ).
Cette comparaison des volumes de mémoire strictement nécessaires en fonction des résolutions et des
profondeurs de couleurs et des volumes de mémoire des cartes actuellement commercialisées semble
vraiment mettre en évidence une disproportion notable : alors, cette apparente disproportion ne serait-elle
qu’un « argument commercial de vente » ou, au contraire, répond-elle à un réel besoin d’ordre technique ?
La réponse est à trouver dans l’évolution exponentielle des techniques de visualisation 3D et notamment
dans toutes les techniques de Rendu réaliste de scènes spatiales 3D par mise en œuvre de procédures de
constructions par nurbs et de rendus réalistes par illumination, ombrage, spécularité, texturage,… qui sont
intensivement utilisées dans les progiciels spécialisés de construction et d’animation de scènes réalistes 3D
comme Bryce, 3Dmax, Electricimage, Lightscape, Lightwave, Maya, Mental Ray, Photorealistic
RenderMan, Rhino, SolidThinking, Strata 3D, TrueSpace, … utilisés par les Infographistes des studios de
création cinématographique, publicitaire, … et par les bureaux d’études DAO/ CAO /CFAO qui souhaitent
visualiser les produits qu’ils créent ( cf. les spots publicitaires en images de synthèse des Citroën ou des
Renault ).
Ainsi, le progiciel Photorealistic RenderMan de Pixar a été utilisé pour les effets spéciaux de Toy Story et
de Jurassic Park ; Electricimage a été utilisé pour les effets spéciaux de La Guerre des Etoiles et de
Terminator 2 ; SolidThinking est spécialement intéressant pour la CFAO ( Conception et Fabrication
Assistées par Ordinateur ) parce que, au-delà de ses grandes qualités de Modeleur Nurbs, il dispose d’outils
de modélisation polygonale, d’outils de subdivision de surfaces, d’un historique de construction et d’outils
analytiques très utiles dans le domaine du Design Industriel et de la CFAO.
A titre d’exemples de rendu réaliste, voici 2 scènes 3D créées par DesignCAD qui, sans développer des
performances dans le rendu 3D comparables à celles des progiciels précités, permet néanmoins d’obtenir
déjà de fort bons résultats en ce domaine ( il est d’ailleurs possible d’importer les dessins DesignCAD dans
ces logiciels spécialisés pour leur appliquer leurs techniques « pointues » de rendu ).
Les 2 premières images correspondent à une scène formée de 3 solides éclairés d’abord par une seule source
de lumière ( 1ère image ), ensuite par 3 sources lumineuses ( 2ème image ), le rendu étant de type
« Gouraud » :
Les 2 images suivantes, créées par DesignCad encore, montrent le résultat de l’application d’une texture
sur la tuyauterie avant :
Pour bien comprendre en quoi la création d’images réalistes en 3D réclame des volumes énormes de
calcul, prenons le cas tout simple de la construction d’une sphère 3D : cette sphère est d’abord créée en « fil
de fer », c.à.d. que sa surface est discrétisée en n polygones qui forment une maquette-support sur laquelle
on « tend » ensuite une « peau » opaque qui peut d’ailleurs être une texture prédéfinie.
La qualité du rendu sera tributaire de la finesse de discrétisation comme le montre l’exemple de 4 sphères
dessinées avec 124 ( 1 ) , 576 ( 2 ) , 1296 ( 3 ) et 14.400 ( 4 ) facettes :
1
2
3
4
auxquelles on va appliquer ensuite un ombrage « Gouraud » à 4 sources de lumière, comme le montre la
figure de la page suivante : vous y constaterez les différences de qualité dans le rendu, le meilleur étant bien
entendu celui obtenu avec la discrétisation maximum.
En fait, les textures constituent elles-mêmes des images qui doivent être stockées dans la mémoire vidéo si
l’on veut qu’elles soient rapidement accessibles pour le processeur graphique de la carte vidéo dans le cas
surtout des jeux vidéos où les images se succèdent très rapidement sous la forme d’un dessin animé dont les
séquences sont à calculer au fur et à mesure et en fonction des réactions interactives du joueur via joystick
ou autres « manettes » de pilotage.
Pour vous montrer ce que sont ces fichiers de textures et en particulier qu’ils sont toujours contenus quelque
part en mémoire- et pas nécessairement d’ailleurs dans la mémoire vidéo -considérons le cas de
DesignCAD dont l’objectif N° 1 n’est pas de réaliser de rapides séquences animées bien qu’il puisse
néanmoins le faire : pour DesignCAD, le fichier de texture sera recherché dans la mémoire principale RAM
en précisant le chemin de recherche.
Supposons p.ex. qu’au cours d’une session de travail « DesignCAD », on ouvre simultanément le
programme windows « Paint » pour y définir une image .BMP, par exemple le mot « TEXTE » sur un
rectangle blanc de fond .
Cette image sera enregistrée en mémoire principale RAM via commande « Fichier / Enregistrer sous… »
selon un fichier appelé « Texte.bmp » dans le répertoire « C : \ Mes documents \ Mes images », tout à fait
indépendamment du répertoire « C : \ Program Files \ DesignCAD 3000 ».
Lors de l’appel par DesignCAD de la procédure « appliquer texture » en vue de faire appliquer à une
sphère « fil de fer » préalablement dessinée dans DesignCAD la texture définie par le fichier créé sous
« Paint » ( comme si on tendait sur la structure fil de fer de la sphère une toile où l’image créée sous
« Paint » est reproduite, une Boîte de dialogue va apparaître dans DesignCAD où il sera demandé de
préciser le chemin du fichier dans le répertoire :
Voici l’image correspondante créée sous « Paint » :
Et voici le résultat de l’application de cette texture dans DesignCAD :
En jouant sur le paramètre « échelle », cette texture peut d’ailleurs être modulée au gré de l’utilisateur :
Des photographies digitalisées peuvent ainsi être utilisées pour la texture , p.ex. celle fournie en standard
par Windows dans le répertoire « C : \ Mes images » sous le nom de fichier « Athlète.jpg » , c.à.d. la photo
suivante :
Et voici le résultat de l’application de cette « texture » à la sphère sous DesignCAD :
Ces textures permettent de faire apparaître des effets de matière pour l’objet en 3D, p.ex. donner à
l’observateur l’illusion que la sphère a été usinée dans du bois, auquel cas il faut aller rechercher dans les
fichiers préétablis par DesignCAD une photo de bois d’ébénisterie, ou prendre soi-même une photo
numérique d’une planche de bois et utiliser ce fichier pour le texturage.
Voici un texturage « Bois » pour notre sphère « fil de fer » créée sous DesignCAD :
Cette recherche du réalisme peut aussi conduire à vouloir donner des effets de flou ( effets de brouillard )
qui imposent alors de travailler en « couleurs 32 bits » pour bénéficier des 8 derniers bits de « canal alpha »,
d’ou la nécessité d’un accroissement de mémoire.
De plus, des techniques particulières de stockage en mémoire vidéo ont été développées pour accélérer les
processus d’affichage en Rendu réaliste 3D, comme le double ou le triple Buffering ( mémoires-tampons
équivalentes en occupations-mémoire à la mémoire de trame proprement dite et stockant 1 ou 2 images en
préparation en plus de l’image correspondant à la mémoire de trame, celle-ci prête à être envoyée à
l’affichage-écran) ou le Z-Buffering ( maintien dans une partie séparée de la mémoire d’un enregistrement
de toutes les coordonnées « z », permettant de savoir si un point se trouve devant ou derrière un autre
élément, ce qui en évite possiblement l’affichage si le point est « derrière » un autre élément d’avant-plan ).
Il devient ainsi évident que la mémoire vidéo devient de plus en plus un composant essentiel de la
logistique d’une carte vidéo qui assure, de façon décentralisée, via le coprocesseur graphique, une très
grande part des calculs et de la gestion des images au lieu de confier cette tâche, comme c’était le cas au
tout début de l’informatique graphique, au processeur central et à sa mémoire propre : il est clair alors
qu’outre la « mémoire d’image » proprement dite, dédicacée à l’affichage, les opérations de calcul
conduites par le processeur graphique feront appel à une mémoire dynamique la plus « physiquement »
proche possible, c.à.d. installée sur la carte vidéo plutôt que décentralisée sur la carte mère, dont le rôle est
tout à fait analogue vis à vis du processeur graphique à celui de la mémoire RAM classique enfichée sur la
carte-mère et qui échange en permanence des données avec le processeur central Pentium
Autrement dit, la mémoire « vidéo » est en fait divisée, d’un point de vue logique, en 2 zones principales,
l’une dédicacée à l’affichage proprement dit, l’autre à la gestion des calculs graphiques locaux, 2 zones
auxquelles il faut d’ailleurs aussi ajouter une zone de stockage des fichiers de textures et des zones de
mémoires-tampons.
Autrement dit encore, les cartes graphiques actuelles doivent être considérées comme une petite unité
centrale ( à processeur et mémoire ) adjointe à l’unité centrale ( à processeur et mémoire ).
Ce qui vient d’être expliqué motive le fait qu’il n’existe en fait aucune disproportion dans l’actuelle course
au volume de la mémoire vidéo qui ne peut absolument plus être considérée, comme c’était le cas à l’aube
de l’infographie, comme une simple mémoire-tampon d’affichage de trames entièrement calculées par le
duo ( processeur central-mémoire centrale RAM ) et qu’ainsi, les volumes de mémoire vidéo, loin de n’être
qu’un simple argument de vente, répondent au contraire à des objectifs précis dans le domaine de
l’infographie du rendu réaliste de scènes 3D en affichage rapide.
Corrélativement à ce concept de volume ( ou « capacité » ) nécessaire de mémoire qui devient à présent
mieux compréhensible, le concept intuitif de vitesse de la mémoire vidéo est, à l’évidence, d’une
importance au moins égale dès lors qu’il s’agit d’images animées en rendu réaliste.
Même d’ailleurs pour les applications en principe moins gourmandes en ressources que les jeux vidéo
interactifs comme la DAO / CAO ( encore qu’en CAO, il puisse être très utile d’animer les images pour se
rendre compte, p.ex., de la façon dont fonctionne un mécanisme-prototype ) , le contexte de vitesse n’est
pas à négliger, même s’il ne s’agit que de faire apparaître à l’écran un rendu réaliste hors tout contexte
d’animation en temps réel : le temps de calcul peut devenir difficilement acceptable et ralentir le travail de
l’utilisateur si les scènes 3D sont complexes et si la carte graphique n’est pas très performante.
Pour rédiger ce cours, j’utilise un portable TOSHIBA Satellite 2800-600 à Pentium III 1 GHz que j’ai
d’ailleurs acheté tout spécialement dans cet objectif en 2001 : à cette époque, une carte graphique de 16 Mo,
surtout pour un portable, était du « haut de gamme ». Celle qui équipe ce TOSHIBA est une carte réputée,
une NVIDIA GeForce2Go ainsi équipée de 16 Mo de mémoire.
L’affichage du rendu d’un objet 3D ( ici un petit engin chenillé dont le dessin a été établi par les
concepteurs de DesignCAD, relativement complexe en ce sens que le nombre de facettes utilisées pour ce
calcul du rendu est assez élevé comme le montrera le détail de l’objet en « fil de fer » ci-après ) va
consommer, sur mon portable, un temps non négligeable, soit expérimentalement de l’ordre de 15
secondes, mais ma carte graphique est loin d’atteindre les performances des cartes actuellement disponibles
sur stations fixes : il faut compter par rapport aux meilleures actuelles sur stations fixes un rapport des
débits de mémoire de l’ordre de 1 à 20 au moins. Il est probable par ailleurs que par un upgrade de la
quantité de RAM pour la faire passer des 256 Mo actuels à 512 Mo, un gain sensible de vitesse serait
obtenu.
A noter que pour les jeux Vidéo fonctionnant en « temps réel », c.à.d. à grande cadence d’affichage
( idéalement à plus de 40 fps ) l’astuce permettant de réduire drastiquement le temps de calcul et
d’affichage consiste à n’utiliser qu’un nombre très réduit de polygones et d’y plaquer des textures.
Voici, sous DesignCAD, le résultat du rendu en image réaliste calculé sur la base du grand nombre de
facettes défini par le dessin filaire de base:
La « vitesse » de la mémoire est donc très certainement un paramètre essentiel pour ces cartes graphiques.
Mais à quoi correspond ce critère intuitif de « vitesse » ?
Le temps nécessaire pour accéder en mémoire à l’information fait en réalité référence au temps mis pour
faire transiter un paquet de données ( 8 bits p.ex. ) de la mémoire au processeur en passant par le bus qui les
relie.
Elle se mesure en nano-secondes ( milliardièmes de seconde ) et se désigne généralement par le terme
« vitesse de mémoire ».
P.ex., un bus cadencé à 100 MHz ( = 108 MHz ) est susceptible de transmettre un paquet d’informations
toutes les 10-8 seconde ( cadence d’horloge ), soit toutes les 10 nano-secondes : une mémoire cadencée à 10
nano-secondes pourra donc fournir les informations au bus selon la même fréquence et sera donc
correctement adaptée.
Une autre caractéristique, décrivant de façon quasi équivalente la « vitesse de la mémoire » et qui tend à
remplacer de plus en plus le critère « temps d’accès », est la « Bande Passante » ( BP ) qui correspond au
produit de la largeur du bus-mémoire par la fréquence : p.ex., pour un bus mémoire de 64 bits et une
mémoire SDR travaillant en fréquence 250 MHz , la bande passante sera de 16 x 109 bits / s , soit
( 16 x 109 ) / 8 = 2 x 109 octets / s = 1.86 Go / s ( Giga-octets par seconde ).
Voici un petit tableau récapitulatif de quelques cartes vidéo couramment implantées en 2002 dans les PC
multimédia à hautes performances graphiques :
Série ATI RADEON « 8500 » : 64 ou 128 Mo, bus 1 x 128 bits, type DDR, BP = 8.0 à 8.8 Go/s
« 9500 » : 128 ou 256 Mo, bus 1 x 256 bits, type DDR, BP= 19.2 Go/s
MATROX PARHELLA : 128 Mo, bus 1 x 256 bits, type DDR, BP = 17.6 Go/s
Série NVIDIA GeFORCE4 « TI 4200 » : 128 Mo, bus 4 x 32 bits, type DDR, BP = 7.1 Go/s
« TI 4600 » : 128 Mo, bus 4 x 32 bits, type DDR, BP = 10.4 Go/s
Le petit tableau ci-dessus fait aussi apparaître une appellation « DDR » qui concerne la mémoire : il faut
d’abord savoir que le type général de mémoire vidéo est typiquement une « RAM » (Random Access
Memory ) ce qui signifie qu’il est possible d’accéder à n’importe quel emplacement de la mémoire sans
suivre un ordre particulier, simplement grâce aux adresses des mots ( groupes d’octets ) en mémoire ; ces
mémoires peuvent indifféremment être lues ou écrites.
Il existe un assez grand nombre de types particuliers de mémoire ( SRAM, DRAM, SDRAM, RDRAM,
DDR SDRAM, DRDRAM,… ) qui diffèrent par leur technologie, l’évolution visant à leur conférer les plus
grandes Bandes Passantes possibles. Il n’entre pas dans le cadre de ce cours de les étudier davantage.
De toutes façons, la meilleure façon d’évaluer les performances réelles d’un système reste d’utiliser des
programmes spécifiques de test , dits « Benchmarks » qui vous renseigneront en particulier sur les
performances réelles de votre carte Vidéo ( notamment en « Nombre de triangles tracés par seconde » ou en
« nombre d’affichages de trames / seconde » ).
Voici 2 sites Internet où vous pourrez trouver ce type de test :
Benchmarks Winstone de Ziff-Davis Benchmark Operations
Benchmarks 3Dmark2001 de MadOnion
:
:
www.zdbbop.com
www. madonion.com
Disons seulement que, fin 2002, les cartes vidéo utilisent le plus souvent de la mémoire des types suivants :
- SDRAM ( Synchronous Dynamic Random Access Memory ) , c.à.d. un type de
mémoirebasé sur le principe de l’échange synchrone de données avec le processeur, évitant
ainsi des états d’attente ( temps d’accès de l’ordre de 10 nano-seconde ) ;
RDRAM ( relativement peu répandues ) développées par la Sté RAMBUS, rapides
mais nécessitant des contrôleurs mémoire spécifiques permettant d’utiliser plusieurs canaux
en parallèle : ces mémoires sont plus rapides que les SDRAM classiques ( BP de 3.2 à 6.4
Go/s ) ;
DDR ( Double Data Rate ), variante de la SDRAM, doublant le traitement ( 2 blocs par
cycle d’horloge plutôt qu’un ) : les cartes les plus rapides les utilisent sous l’appellation
DDR-SDRAM ou SDRAM II.
1.5.3. LE PROCESSEUR GRAPHIQUE DE LA CARTE VIDEO
Au tout début de l’informatique graphique, les programmes d’applications graphiques n’étaient pas
interactifs mais procédaient par l’exécution d’un programme écrit par l’utilisateur lui-même :
o
soit – mais c’était la préhistoire du PC où l’on utilisait p.ex. en 1973 un
minuscule TRS80 de RADIO SHACK – en programmant l’affichage des
pixels, leur répartition étant calculée un pixel à la fois via programme écrit par
l’utilisateur en Basic ou Assembleur, traduisant un algorithme de tracé pixel
par pixel approchant p.ex. la forme d’un cercle, la seule routine
« bibliothèque » alors préprogrammée étant la transformation de l’affichage
calculé en X,Y mathématiques vers l’affichage « Hardware » sur l’écran ;
o
soit – et cela a été l’étape suivante – en faisant appel à une bibliothèque
graphique où les algorithmes de tracés de primitives p.ex. ( cercles, polygones,
… ) se trouvaient déjà préprogrammées, comme d’ailleurs les instructions de
tracé « hardware », sous la forme de routines appelables au sein d’un
programme écrit dans un langage « de haut niveau » comme le Fortran
( un peu comparable au C ou au C++ que vous utilisez aujourd’hui ),ce
programme et ces routines générant alors la bitmap.
L’intégralité des calculs puis la mise en mémoire de la bitmap s’opéraient alors exclusivement dans
l’unité centrale et dans la mémoire centrale RAM dont une partie était dédicacée à la mémoire
d’image selon le schéma logique général suivant :
UNITE
CENTRALE
Périphérique
( CPU )
( Clavier, imprimante, ... )
Bus Système
MEMOIRE
SYSTEME
MEMOIRE
IMAGE
RAM
CONTROLEUR
VIDEO
Signaux analogiques
MONITEUR
Ce schéma logique associé à tel contrôleur vidéo élémentaire des premiers PC graphiques est détaillé
davantage en page suivante pour mettre en évidence les fonctions exactes assurées par le contrôleur vidéo
d’alors ( ce schéma concerne un moniteur monochrome ).
UNITE
Périphériques
CENTRALE
Bus Système
Valeurs lues
Adr.
01001101
Adresse X,Y
successifs
MEMOIRE
SYSTEME
IMAGE
dans la mémoire
de 8 bits pour
8 pixels
MEMOIRE
Adresse
sur Ecran
Convertisseur
Générateur de
Numérique / Analogique balayage d'écran
RAM
Signaux analogiques
Signaux analogiques
sur les dispositifs
On / Off
déviateurs du
de tension de grille
pour 8 pixels
successivement balayés
faisceau d'électrons
du moniteur pour
atteindre la position X,Y
Y
Groupe des 8 Pixels
codés 01001101
ECRAN
X
SCHEMA LOGIQUE D'UNE CARTE VIDEO ELEMENTAIRE DES 1ers PC GRAPHIQUES
Y.DURAND 18.12.02
L’inconvénient majeur d’un tel système élémentaire réside dans le fait que quand la résolution et la
vitesse de rafraîchissement augmentent, le nombre d'accès à la mémoire RAM effectués par le contrôleur
vidéo s’accroît en proportion et diminue donc corrélativement le nombre de cycles d’accès possibles à cette
mémoire RAM par le microprocesseur central.
De tels systèmes ne pouvaient donc plus assurer des temps de réponse suffisamment réduits dès lors que les
développements du graphisme interactif 2D d’abord ( du type interface graphique de Windows où
l’utilisateur pointe et clique avec la souris sur des icônes de menu et attend une réaction quasi instantanée
du système ou du type « Dessin Assisté par Ordinateur 2D ou même 3D filaire » fonctionnant selon les
mêmes principes ) puis surtout ensuite interactif avec images animées en Rendu Réaliste 3D nécessitant à la
fois des puissances de calcul énormes et des temps de calculs extrêmement réduits ( de type simulateurs,
jeux vidéo, imagerie médicale,… ) ont répondu à une demande croissante de plus en plus exigeante du
marché de l’image.
L’industrie « Hardware » a donc répondu à cette attente en mettant au point des cartes graphiques dont le
rôle principal est de dérouter une grande partie des calculs et de la gestion des images vers un traitement
local effectué par des circuits spécialisés - assez analogues dans leur technologie et dans leur mode de
fonctionnement à ceux du microprocesseur central – appelés « processeurs graphiques » ou
« accélérateurs graphiques ».
Ce concept a été l’innovation qui a marqué le plus l’évolution des cartes graphiques depuis les toutes
premières dans les années 1980 jusqu’aux plus récentes. Il est d’ailleurs à prévoir, de notre avis, que, dans
un futur proche et compte tenu des constants progrès d’intégration ( LSI = « Large Scale Integration » ) des
circuits sur les puces, les fonctions déportées aujourd’hui sur des processeurs graphiques spécialisés se
retrouveront sans doute, un jour proche, directement câblées dans le processeur central, sur la carte mère ou
dans le chipset, comme c’est déjà le cas pour des circuits « son »: il est significatif de constater, à cet égard,
que l’excellent assembleur US DELL COMPUTER propose déjà, dans une offre de machines « standards »
du mois de novembre 2002 parue dans les publicités de la plupart des magasines de micro-informatiques
français, une machine « départ de gamme » à 599 € H.T., le Dell Dimension 2300, une mémoire vidéo
dynamique AGP intégrée, alors que toutes les autres machines de la même série « Dimension », dont les
prix s’étagent entre l’ordre de 900 € H.T. et 2700 € H.T. ( puissant PC Multimédia à PIV de 2.8 GHz, 512
Ko mémoire cache de sd niveau, 512 Mo RDRAM, disque dur 120 Go, carte Vidéo 128 Mo ATI Radeon
9700 Pro, CRT 19’’, carte son, modem, … ), c.à.d. des machines davantage orientées vers les applications
professionnelles plus exigeantes, maintiennent l’exigence – aujourd’hui encore incontournable pour
l’imagerie animée 3D en rendu réaliste – d’une carte Vidéo séparée à mémoire propre VRAM ( Video Ram
) : Dell installe aujourd’hui sur touts ses machines de la série « Dimension » , sauf le bas de gamme et le
tout haut de gamme ( cf. descriptif c-dessus ) , des cartes Vidéo à processeur Nvidia GeForce 4MX et à
mémoire Vidéo 64 Mo branchées sur bus AGP4X.
L’utilisation des bus ultra-rapides AGP ( 2X à 512 Mo/s, puis 4X et 8X doublant puis quadruplant la Bande
Passante par rapport à l’AGP2X ) liant directement la plupart des cartes graphiques les plus actuelles
( vérifier si la carte-mère comporte un bus AGP et si la carte graphique est enfichable sur connecteur AGP :
la carte Hercules 3D Prophet 4000 XT ne peut p.ex. qu’être connectée à un bus PCI, toutes les autres citées
plus loin dans ce § disposant d’une connexion AGP ) au processeur central et à la RAM principale non
vidéo au travers du chipset donne en effet déjà aujourd’hui la possibilité de manipuler et placer des images
« lourdes » 3D dans la mémoire RAM non vidéo en reportant donc une partie des opérations graphiques
vers l’Unité Centrale et sa mémoire centrale malgré la présence de puissantes cartes graphiques,
conformément déjà à cette tendance d’avenir.
Il faut d’ailleurs noter que ce bus AGP ( Accelerated Graphics Port ) a été défini en 1996 à l’initiative
d’Intel et Microsoft notamment pour résoudre le problème du branchement classique d’alors de la carte
Vidéo sur bus PCI qui posait des problèmes de Bande Passante vite saturables, comme en avaient posés les
premiers contrôleurs vidéo décrits en début de §, à une toute autre échelle toutefois bien entendu.
Ce problème du branchement sur bus PCI se posait en les termes suivants : en fait, « PCI » signifie :
« Peripheral Component Interconnect », c.à.d. qu’il s’agit d’un bus servant à assurer la liaison de l’unité
centrale ( Pentium et RAM ) via chipset avec la plupart des périphériques ( souris, clavier,… ) dont
éventuellement la carte vidéo.
Par suite, ce bus est essentiellement un bus partagé : le schéma logique d’un PC Multimédia « haut de
gamme » exposé précédemment montre d’ailleurs que le PCI reste néanmoins toujours d’actualité, mais
seulement pour le branchement de périphériques moins gourmands en Bande Passante que la carte vidéo.
Donc, malgré une bande passante relativement importante ( bus de largeur 32 bits, soit 4 octets à 33MHz )
de 132 Mops, ce bus partagé PCI pouvait constituer une source de ralentissement lors de l’utilisation
effective de la carte vidéo, très consommatrice de Bande Passante dès lors que les images sont animées en
temps réel et font appel aux techniques de rendu réaliste avec textures multiples comme dans les jeux vidéo.
Supposons p.ex. un dessin animé à 16 millions de couleurs en résolution 1024 x 768, soit un équivalent de
2.3 Mo par frame et avec un affichage requis de 25 fps ( Frames / s ), c.à.d. en mode « cinéma » ( 25
images / seconde ) .
La Bande Passante requise vaut, en ce cas, 60 Mops.
Pour autant que d’autres périphériques branchés sur le bus PCI utilisent aussi simultanément de la bande
passante, ce bus PCI est rapidement saturé, ce qui provoque d’importants ralentissements.
Compte tenu d’ailleurs du nombre de plus en plus important des périphériques que les utilisateurs
souhaitent brancher sur leurs PC, via notamment contrôleurs USBI ou USBII et FireWire ( IEEE 1394 ), les
nouvelles versions des spécifications PCI ( PCI 2.0 ) demandent des bus PCI à plus large Bande Passante de
528 Mops ( 8 octets- soit les 64 bits pour exploiter les Pentiums - à 66 MHz ).
Pour résoudre ce problème d’étranglement, le bus AGP a donc été développé au titre de bus exclusivement
dédié à la connexion entre l’Unité Centrale et la carte Vidéo, sans qu’aucun autre périphérique soit encore
autorisé à y être branché ( cf. le schéma logique de l’architecture d’un PC Multimédia pourvu d’un bus
AGP présenté quelques pages avant celle-ci ).
Ce bus doit être susceptible de taux de transferts importants : l’AGP1X travaille ainsi en 264 Mo/s ,
l’AGP2X en 528 Mo/s, l’AGP4X en 1056 Mo/s et l’AGP8X en 2 Go/s.
Ce caractère de bus « exclusif » à grande Bande Passante ainsi que sa proximité avec la RAM classique ( cf.
le schéma logique général d’un PC quelques pages auparavant ) ont permis à ses concepteurs d’imaginer
pouvoir faire bénéficier la carte vidéo d’un accès direct à des blocs de la mémoire centrale RAM, blocs
où sont notamment stockables un grand nombre de fichiers pour les nombreuses textures intensivement
utilisées dans les rendus réalistes, plutôt que de les stocker dans les mémoires vidéo relativement limitées en
capacité ( au regard de la mémoire RAM : actuellement, 128 Mo de mémoire Vidéo au maximum sur la
grande majorité des cartes graphiques de hautes performances contre 512 Mo à 1Go, voire même 2Go de
RAM ) et de prix sensiblement plus élevé que les RAM d’unités centrales.
Actuellement, le choix d’une carte possédant un processeur graphique dédicacé et une importante mémoire
vidéo locale, tout en étant à connexion AGP reste donc le meilleur choix pour assurer de grandes vitesses de
traitement d’images 3D complexes : les prix de telles cartes, fin 2002, sont compris dans une fourchette de
l’ordre de 100 € à 500 € ( le tout Haut de Gamme , ATI Radeon 9700 Pro, compatible AGP8X et DirectX 9
, cf. pour la signification de « DirectX 9 » le § suivant ).
Les processeurs graphiques sont des circuits spécialement conçus et câblés pour exécuter un ensemble
d’opérations arithmétiques, logiques et de transferts spécifiques au tracé graphique, p.ex. le « calcul »
de la meilleure répartition des pixels pour approcher un segment défini par les coordonnées de ses 2 points
d’extrémités selon un algorithme bien défini ou assumant les fonctionnalités de calcul 3D en rendu réaliste
de « T&L », c.à.d. « Transform and Lightning », c.à.d. encore les tâches de conversion d’une scène 3D du
« World Space » en une image 2D affichable sur écran ( « Screen Space » ) d’une part et d’éclairement de
l’objet 3D par plusieurs sources lumineuses d’autre part : nous reviendrons sur tout cela en l’expliquant
davantage dans le § 1.5.4. suivant.
Il est d’ailleurs intéressant de vous informer, à propos de ces câblages spécialisés, que dans les PC de
premières générations, le même problème se posait pour les calculs arithmétiques en virgule flottante, les
processeurs de l’époque ( < 1989 ) jusqu’à l’Intel 80386 ne pouvant travailler sur de tels nombre et devant,
en l’absence de coprocesseur mathématique spécialisé, péniblement et longuement simuler leur calcul par
des calculs sur entiers : là aussi, un coprocesseur spécialisé, dit alors « mathématique » ou « arithmétique »,
lui aussi spécialement câblé en vue de l’exécution des algorithmes de calculs arithmétiques en virgule
flottante, était à installer « à côté » du microprocesseur central comme c’est le cas aujourd’hui pour les
coprocesseurs graphiques .
Ce « coprocesseur mathématique »( Floating Processor Unit ) a été intégré pour la 1ère fois dans la famille
des processeurs Intel sur le 80486DX commercialisé en 1989 et est depuis lors câblé d’office sur les puces
ultérieures de type Pentium ( commercialisées depuis 1993 ) sans qu’il soit donc encore nécessaire de
l’acheter et l’installer séparément.
Des constructeurs spécialisés fabriquent ces processeurs graphiques ; on peut citer p.ex., parmi les
processeurs graphiques les plus répandus ( fin 2002 ) :
o
o
o
o
la série RADEON ( 7500, 8500, 9000, 9500, 9700 ) – Constructeur : ATI
la série NVIDIA GeForce2 (MX 200, 400, Pro, Ultra ), GeForce3 ( -, TI200,
TI500 ), Geforce4 ( MX440 et 460, Ti 4200, 4400 et 4600 ) – Constructeur :
NVidia
la série PowerVR Kyro I et II – Constructeur : STMicroelectronics
…
Il faut d’ailleurs distinguer l’appellation du processeur graphique proprement dit de celle de la carte ellemême, celle-ci en général assemblée par d’autres constructeurs en utilisant l’un des processeurs graphiques
précités.
Par exemple, les cartes « 3D Blaster » sont construites par la Sté CREATIVE LABS en utilisant les
processeurs graphiques de chez NVIDIA ( ex. : la 3D Blaster Titanium 4600 comporte un processeur
graphique NVIDIA GeForce TI 4600 ), les cartes « 3D Prophet » sont construites par la Sté HERCULES en
utilisant soit les processeurs graphiques de ATI ( ex. : la 3D Prophet FDX 8500LE comporte un processeur
graphique ATI Radeon 8500 ), soit les processeurs graphiques de la Sté STMicoelectronics ( ex. : la 3D
Prophet 4500XT comporte un processeur graphique STMicoelectronics PowerVR Kyro II ) ...
Comme le processeur central Pentium, AMD,… les coprocesseurs graphiques peuvent être caractérisés,
entre autres, par le nombre de transistors intégrés dans la puce : par comparaison, un Intel Pentium IV
comporte 42 millions de transistors en version cache L2 de 256 Ko et 55 millions de transistors en version
cache L2 de 512 Ko : les processeurs graphiques cités ci-dessus comportent de l’ordre de 25 à 110 millions
de transistors ( 25 millions pour le GeForce2 MX400 … jusqu’à 107 millions pour le Radeon 9700 Pro ) :
comme pour les microprocesseurs, un ventilateur de refroidissement est d’ailleurs à installer sur le
coprocesseur graphique.
A ce propos et en rapport direct avec les applications DAO , il faut savoir que ces circuits microscopiques
sont d’abord dessinés à très grande échelle ( 500 x ) grâce à un progiciel ( spécialisé ) de Conception
Assistée par Ordinateur fonctionnant selon des principes équivalents au progiciel DAO que vous utiliserez
au laboratoire : DesignCAD .
La différence est que ce dernier est de type « Dessin Assisté Généraliste » et ne comporte donc pas de
couches logicielles d’aides à la conception proprement dite spécifiquement dédicacées à l’élaboration de
circuits intégrés ; précisons cependant qu’au prix d’un effort préalable de programmation de « macros »,
DesignCAD pourrait être converti en un logiciel spécialisé de DAO et même, dans une certaine mesure, de
CAO, pour n’importe quel type d’application spécialisée.
Ce dessin à grande échelle, appelé « masque » est ensuite utilisé pour guider ( par ordinateur ) un faisceau
lumineux qui va impressionner une plaque photo appelée « réticule » reproduisant, à échelle 20 x plus
petite, le dessin précité. Après contrôle, ce réticule est ensuite réduit et reporté à la taille réelle
microscopique du circuit par un procédé photographique appelé photolythographie sur une fine tranche de
silicium.Par divers procédés chimiques et optiques, l’information graphique contenue dans ces masques
( +/- 20 pour un Pentium ) est enfin transformée en micro-circuits « hardware » résidents sur la puce.
Ce qui caractérise aussi un processeur graphique, comme d’ailleurs un microprocesseur de type Pentium
p.ex., est sa fréquence d’horloge.
Ainsi, tous le processeurs graphiques de la série ATI Radeon 7500 à 9700 sont cadencés à des fréquences
d’horloge comprises entre 275 et 325 MHz ( par comparaison, vous savez qu’actuellement les Pentium IV
dépassent les 2 GHz ).
A quoi correspondent ces fréquences ?
Tous les processeurs fonctionnent selon un schéma logique similaire :
ADRESSES
PROCESSEUR
UNITE DE RECHERCHE
HORLOGE
UNITE DE DECODAGE
CONTENU
CONTENU
X
Adresse
UNITE D'EXECUTION
MEMOIRE
RESULTAT
SCHEMA LOGIQUE DE FONCTIONNEMENT D'UN PROCESSEUR
1.
L’unité de recherche adresse une cellule de la mémoire pour lire son contenu ( 8 bits,
16 bits, … ) ;
2.
La mémoire transfère ce contenu en le dupliquant vers l’unité de décodage ;
3.
L’unité de décodage examine le ou les octets transmis et décide ce qu’il faut en faire
( p.ex. une addition ) ;
4.
L’unité de décodage transmet l’instruction à l’unité d’exécution qui exécute cette instruction ;
5.
L’unité d’exécution envoie le résultat à l’extérieur du processeur via bus de sortie ;
Ces 5 opérations élémentaires sont consécutivement et régulièrement menées au rythme imposé par des
impulsions périodiques provenant d’une horloge à quartz : la fréquence de ces impulsions impose ainsi le
rythme d’avancement des opérations : un processeur cadencé à 2 GHz est donc susceptible d’effectuer 2
milliards d’opérations par seconde.
1.5.4. LES INTERFACES DE PROGRAMMATION GRAPHIQUE ( DirectX , OpenGL, PHIGS, GKS )
Comme vous le savez, les microprocesseurs ( et, identiquement, les coprocesseurs graphiques )
présentent, par rapport aux circuits électroniques banals, la particularité d’avoir été conçus pour être
programmables.
Cette programmation revient à disséquer l’exécution d’une action souhaitée par l’utilisateur, p.ex. « ajouter
les valeurs de 2 variables », en une séquence de micro-instructions pas à pas en traduisant, selon un
vocabulaire et une syntaxe « humainement accessibles », les ensembles codés binaires ( suites de « 0 » ou
« 1 » ) selon lesquelles le processeur va physiquement réagir en fonction de son câblage pour manipuler des
données ( numériques ou alphanumériques ) en respectant des ordres d’instructions de types logique,
arithmétique ou de contrôle, selon un « code d’ordres » propre à chaque type de processeur selon son
câblage Hardware.
Très généralement, pour fixer les idées, il existe 6 grandes catégories d’instructions :
1. les instructions de transfert de données entre microprocesseur et organes périphériques
( clavier, mémoire, … ) ;
2. les instructions de transfert de données entre registres ( zones de mémorisation temporaire de
groupes significatifs de bits : p.ex. « registre tampon » permettant de stocker temporairement une
information entre un dispositif source et un dispositif destinataire non synchronisés ) ;
3. les instructions arithmétiques ( +, -, incrémentation, … ) ;
4. les instructions logiques ( « ET », « OU », « OU EXCLUSIF XOR », … ) ;
5. les instructions de décalage ( logiques, arithmétiques, … ) ;
6. les instructions de contrôle ( permettant l’exécution d’algorithmes conditionnels par tests et
branchements à des adresses quelconques en mémoire ).
Comme indiqué, il est clair que rédiger un programme qui ne serait qu’une très longue suite binaire
directement compréhensible par le processeur serait humainement ingérable et qu’ainsi, le problème de base
qui se pose est de pouvoir traduire de telles séquences d’instructions binaires en un langage symbolique
décrivant selon un vocabulaire codifié et une grammaire conventionnelle codifiée les instructions, les
données et les adresses des registres de façon plus directement accessible au programmeur.
Ceci est d’autant plus vrai aujourd’hui que la complexité des circuits et de leurs applications a suivi une
courbe exponentielle depuis le premier processeur à 8 bits introduit par Intel sur le marché en 1972 ( le
« 8008 » ) et que s’il s’était encore avéré envisageable, pour de tels systèmes élémentaires des origines de la
micro-informatique, de programmer en binaire, tel n’est assurément plus le cas aujourd’hui où, p.ex. la
Société Microsoft utilise à plein temps près de 6000 développeurs dans l’équipe R&D chargée de concevoir
le futur Operating System VISTA qui va remplacer Windows XP.
La complexité des logiciels s’accroît en effet sans cesse, au point que l’on parle de « modularité » d’un
langage, c.à.d. de son aptitude à être utilisé pour la rédaction de programmes très volumineux ( il est
fréquent de voir aujourd’hui des logiciels comprendre plusieurs centaines de milliers de lignes de code ) en
les divisant en « modules » plus faciles à tester qu’un ensemble, maîtrisables par des groupes indépendants
de développeurs responsables chacun de leurs parties du projet et interfaçables avec d’autres langages selon
lesquels certaines parties du projet sont établies ( le « C » et le « Java » sont ainsi typiquement des
langages modulaires , le « Pascal » beaucoup moins ) .
Le langage d’« Assemblage » est ainsi le langage symbolique de base permettant d’opérer cette
traduction au plus bas niveau, c.à.d. au niveau de la gestion des registres du processeur : l’utilisation d’un
tel langage nécessite une connaissance approfondie du fonctionnement interne du hardware et, plus
spécifiquement encore, du hardware spécifique aux divers types de processeurs, mémoires, gestionnaires de
périphériques, … auquel la rédaction du programme sera dédicacée : tout langage d’assemblage est
d’ailleurs propre à un type de processeur donné.
La « compilation » effectuée ensuite par un programme standard tiers « de service » dit « Assembleur »
permet alors de traduire, in fine, les instructions et données écrites en langage dit « source » ( c.à.d. le
programme écrit en langage d’« Assemblage » ) en langage « Machine » ( c.à.d. les chaînes de valeurs
binaires compréhensibles par la machine ).
Voici, p.ex., un tout petit segment de code en langage d’Assemblage destiné à ajouter le contenu du registre
C au contenu du registre A et ranger cette somme dans le registre A pour un microprocesseur de première
génération ( le Zilog Z80 qui équipait le Tandy-Radio Shack TRS80 en 1977 , à l’époque de l’Apple II
équipé du 6502 de MOS Technology ) :
“ ADD A,C ”
L’instruction “machine” en binaire correspondante s’établit, après compilation, selon l’octet :
«10000001»
L’avantage de ce langage d’Assemblage « de bas niveau » est qu’il définit chaque ligne d’instruction
en correspondance bi-univoque avec l’instruction « machine » correspondante : chaque instruction
du langage d’assemblage correspond exactement à une et une seule instruction machine.
Son désavantage est qu’il n’est pas très « explicite » ni au regard du langage « naturel » des utilisateurs,
ni au regard de leur mode de pensée scientifique habituel, bien que des mnémoniques et des adresses
symboliques facilitent la tâche du programmeur : p.ex., les instructions arithmétiques communes ( + , - ,
x , / ) s’écrivent « ADD, SUB, MUL, DIV » sans qu’il soit nécessaire de se rappeler des codes binaires
correspondants, tâche de conversion effectuée par après par l’Assembleur.
Voici un petit segment de code en langage d’assemblage pour Pentium qui vous confirmera ce caractère
un peu ésotérique du langage :
«
…
PUSH EBP
MOV EBP, ESP
CMP [EBP + 8], 1
JNE L1
MOV EAX, [EBP + 16]
PUSH EAX
MOV EAX, [EBP + 12]
PUSH EAX
PUSH OFFSET FLAT : format
CALL _printf
ADD ESP, 12
JMP Done ;
…
»
Aussi des langages, dits de « haut niveau », ont-ils été mis au point pour rendre encore plus accessible
aux utilisateurs la rédaction de programmes : le Basic, le Fortran, le Pascal, … en sont des
exemples.L’inconvénient de la plupart de ces langages de haut niveau est qu’ils forment un écran
« opaque » entre l’utilisateur et les séquences multiples « de bas niveau » en général nécessaires pour
exécuter peu d’opérations mathématiques ou logiques : là où 2 ou 3 instructions suffiront pour réaliser une
opération dans un programme de haut niveau, il en faudra beaucoup plus en langage d’Assemblage tout
simplement parce que le langage d’Assemblage « décortique » les séquences pas à pas, en suivant l’ordre
précis des diverses opérations successives dans les circuits, ce à quoi ne procèdent absolument pas ces
langages de haut niveau qui sont plutôt une traduction synthétique de la pensée mathématique et logique de
l’utilisateur lui-même qu’une traduction du mode réel de fonctionnement du système à microprocesseur.
Bien que « de haut niveau », le langage de type « C » ( ou sa variante étendue « C++ » ) pour lequel, je
crois, vous êtes formés actuellement à la FPMs reste fort proche d’un langage d’Assemblage, en ce sens
qu’il limite son noyau de base au traitement des caractères, des nombres et des adresses ( les « pointeurs » ),
combinés avec des opérateurs arithmétiques ou logiques, en dégageant ainsi « du lot » toutes les opérations
communes à la plupart des systèmes à microprocesseurs, ce qui en assure une grande portabilité.
Ce langage C a ainsi été utilisé au départ pour programmer de façon simple et compacte l’Operating System
« Unix », comme il l’est aujourd’hui pour programmer le système d’exploitation « Windows » ( dont les
versions NT, actualisées sous les appellations Windows « 2000 » puis « XP » sont d’ailleurs très semblables
à l’Unix, étant spécifiquement orientées vers l’exploitation de réseaux d’entreprises ) ou l’O.S. « Linux »,
lui aussi de type « Unix » .
Il est clair toutefois que, quel que soit le type d’Operating System envisagé, tout un ensemble de
procédures, davantage spécifiques à tel ou tel matériel, restent alors à adjoindre au plus bas niveau à celles,
plus généralistes, écrites en « C » et que ces procédures spécifiques sont alors dépendantes du matériel et
doivent être écrites en langage d’Assemblage, appelables comme routines ou fonctions préprogrammées au
sein du programme C sans que l’utilisateur doive se préoccuper de cette programmation particulière ( tel est
le cas p.ex. des fonctions de lecture ou d’écriture qui ne sont pas comprises d’ailleurs dans le noyau de base
du « C » mais restent spécifiques à la machine et, à ce titre, doivent être adaptées au matériel par le
constructeur et le fournisseur de l’O.S.).
B. Kernigham et D. Ritchie qui ont été les concepteurs à la fois du « C » et de l’Unix de l’Ordinateur
Digital DEC PDP11 ( qui était un « mini-ordinateur central multi-utilisateurs via réseau local » mis sur le
marché en 1976 et très répandu dans les milieux industriels, bancaires,… ) expliquent à ce sujet que leur
O.S. UNIX comportait 13.000 lignes de programmation dont seules 800 étaient écrites en Assembleur et
dédicacées à l’architecture et aux composants spécifiques du PDP11, les autres étant rédigées en « C » et
portables sur bien d’autre systèmes : il en est de même aujourd’hui pour l’O.S. Windows, majoritairement
rédigé en C et C++, partiellement en langage d’assemblage.
De même, il est évident que le compilateur qui opère la traduction en langage machine d’un programme
écrit en C sera propre à l’architecture spécifique de la machine utilisée et de ses composants Hardware : le
compilateur devra donc aussi être fourni avec la machine spécifique ( Stations Sun, IBM, Silicon Graphics,
…).
Bien entendu, une tendance affirmée de standardisation existe, notamment pour les micro-ordinateurs PC
« compatibles » , ce qui permet aussi pour tous ces PC une même standardisation du compilateur C, comme
de l’O.S. d’ailleurs, mais il faut alors remarquer qu’il existe, parallèlement, les Macs d’Apple dont les O.S.
( MacOS X ) et les compilateurs C diffèrent de ceux des PC, bien qu’il s’agisse dans les 2 cas de « microordinateurs ».
L’inconvénient d’un langage compilé reste donc toujours qu’il ne peut s’exécuter complètement sur
plusieurs types de processeurs que si le programme source est disponible et qu’il peut alors être compilé par
les compilateurs spécifiques à ces processeurs : il faudrait donc idéalement toujours veiller, lors de l’achat
d’un logiciel, à se faire fournir le code source et non exclusivement le code déjà compilé pour un type
donné de machine et de processeur, sous peine de devoir racheter complètement le même logiciel en cas de
changement de machine ( p.ex. si l’on passe d’un PC à un Mac ou réciproquement ) ou même en cas
d’upgrade d’O.S. pour une même machine ou d’une machine de même type mais plus récente.
Pour comprendre alors ce qu’est la « programmation » dans le cadre de l’utilisation de cartes graphiques,
il reste essentiel de comprendre en priorité ce qu’est cet Operating System dont il vient d’être question .
Tout d’abord, il faut distinguer le Système d’exploitation du « Bios » ( Basic Input / Output System) :
lorsque vous mettez votre ordinateur sous tension, le Bios est immédiatement activé en tant que tout
premier « logiciel en version exécutable » et d’ailleurs, avant que les tâches qu’il effectue soient terminées,
ce qui peut durer quelques minutes, vous n’avez pas accès à l’interface graphique du Système d’exploitation
Windows.
Le rôle du Bios est de mettre en place une interface entre le matériel et le Système d’exploitation : sa
première fonction est de tester et reconnaître les principaux organes du PC ( mémoires, disque dur, cartes
d’extension, contrôleurs de périphériques, … ) : il est d’ailleurs parfois nécessaire de télécharger une « mise
à niveau » du Bios chez le Constructeur de votre PC si vous comptez y adapter un matériel tout récent qui
n’existait pas lors de l’achat de votre machine, un lecteur DVD p.ex.
Sa seconde fonction, chronologiquement, est de charger l’Operating System en RAM ; une fois cette
tâche accomplie, l’O.S. est activé et vous voyez alors apparaître à l’écran l’interface graphique de
l’O.S.Windows à partir de laquelle vous allez pouvoir commencer à travailler.
Le rôle du Bios ne s’arrête cependant pas à l’amorçage du système et il sera à nouveau impliqué en cours
de travail, p.ex. lors des opérations de lecture ou d’écriture de fichiers sur le disque dur.
Une fois chargé par le Bios, l’O.S. va jouer le rôle – ESSENTIEL – d’interface entre le Hardware et
tout logiciel d’application que l’utilisateur va souhaiter mettre en œuvre pour exécuter une tâche, p.ex. la
rédaction d’un texte au moyen d’un traitement de texte ( Microsoft Word p.ex. ), la réalisation du dessin
d’un plan de bâtiment au moyen d’un progiciel D.A.O. ( AutoCAD, DesignCAd ou Cadkey p.ex. ), le calcul
des contraintes dans un élément d’assemblage sollicité en flexion et torsion au moyen d’un progiciel de
calcul par Eléments Finis ( Algor ou Cosmos p.ex. ) ou la réalisation des séquences d’un dessin animé par
un progiciel 3D d’animation ( Maya, 3Dmax ou LightWave p.ex. ).
Si vous rédigez vous-même un programme en C++, p.ex. pour réaliser des calculs matriciels, sa version
devenue « exécutable » ( « .exe » ) après compilation du code source que vous aurez écrit au moyen d’un
Editeur de texte va devenir elle aussi un logiciel d’application, au même titre que les versions « .exe » des
programmes de traitement de texte, de dessin, de calcul de contraintes ou de dessins animés 3D que vous
aurez acquis sur le marché du Software.
L’une des premières tâches de l’O.S. sera d’ailleurs d’aller rechercher cette version exécutable « .exe » sur
votre disque dur pour la placer en mémoire RAM après que vous aurez signifié à l’O.S. que vous souhaitez
l’ouverture d’une session de travail avec tel ou tel logiciel d’application en double-cliquant sur l’icône qui
le représente ( « raccouci » ) sur le « Bureau Windows ».
Ce « transport » vers la RAM permettra en effet l’exploitation du logiciel avec un accès infiniment plus
rapide que ce serait le cas si ledit logiciel restait résident sur le disque dur ( d’où d’ailleurs la nécessité pour
utiliser de puissants logiciels d’une RAM de grande capacité, ne serait-ce que pour y loger le logiciel
d’application lui-même ).
Pour DesignCAD p.ex., vous pouvez constater que la version exécutable « DesignCAD 3000.exe » est
un fichier de 6,52 Mo et qu’il s’agit bien d’une « Application » :
Ce qui a déjà été exposé jusqu’à présent vous permet très certainement d’avoir conscience de la haute
complexité de la gestion et de l’utilisation des ressources Hardware par l’O.S.
En fait, un O.S. comme Windows comporte des centaines de fichiers différents, imbriqués dans un
ensemble logique de couches à plusieurs niveaux d’abstraction.
Vous pouvez observer ( sauf les fichiers « cachés » si vous ne le spécifiez pas ) cette quantité de fichiers
en les faisant afficher à l’écran par « Poste de travail / Disque local C : / WINDOWS / System » :
Pour en appréhender le détail, je vous recommande vivement l’acquisition d’ouvrages spécialisés de la
série « Microsoft Press » intitulés « Kits de formation » ou « Kits de ressources techniques » ( ils existent en
français et peuvent facilement être commandés dans n’importe quelle librairie scientifique et pourraient
même, si vous le souhaitez, vous préparer à passer des examens chez Microsoft conduisant à la certification
« Microsoft Certified Professional », soit une qualification d’Expert reconnue sur le marché informatique )
qui contiennent toutes les informations utiles pour comprendre, exploiter et développer dans des
environnements « O.S. Microsoft Windows » .
Plus généralement, si vous êtes intéressés par les O.S., je vous recommande aussi la lecture de « Unix et les
Systèmes d’exploitation » par M.DIVAY ( DUNOD ), « Architectures logicielles et matérielles » par
P.AMBLARD ( DUNOD ) et « Les Systèmes d’exploitation » par A .TANENBAUM ( DUNOD ).
Remarquez simplement le grand nombre de fichiers munis des extensions « .exe » ( ce sont des programmes
compilés et exécutables, au même titre que les Applications proprement dites ) et « .DLL », p.ex. les 2
fichiers « GDI.exe » et « GDI32.DLL » qui sont des fichiers « Système » essentiels, notamment pour que
vous ayez à disposition l’ « écran graphique Windows » qui vous est familier : il s’agit en effet, comme leur
nom symbolique l’indique, de fichiers « Graphics Device Interface » qui gèrent l’affichage graphique
sous Windows.
Vous connaissez déjà la signification de « .exe », mais que représentent les fichiers « .DLL » ?
Toutes les versions de Windows permettent de faire de l’édition de liens dynamique en utilisant un format
de fichier spécifique DLL ( Dynamic Link Library ou Bibliothèque de liens dynamiques ) : en fait, la
plupart des programmes contiennent plus d’une procédure , mais généralement, les divers compilateurs et
assembleurs ne traduisent qu’une procédure à la fois : avant de faire exécuter le programme, il faut donc
d’abord lier toutes les procédures : cette seconde étape après compilation est réalisée par un éditeur de
liens ; après cette seconde étape, le programme peut seulement être exécuté et porte, sous Windows,
l’extension « .exe ».
L’édition de liens dynamique répond à la problématique que dans beaucoup de cas, les programmes ont des
procédures qui ne sont que très rarement utilisées ou qui peuvent être importées en provenance de sources
tierces : par suite, dans un souci d’efficacité et de souplesse, l’édition dynamique autorise l’appel et le lien à
de telles procédures au moment exact où elles doivent être appelées plutôt que de les lier indéfectiblement
au code principal « .exe ».
L’éditeur dynamique de liens construit ainsi les DLL à partir d’un ensemble de fichiers dont il est permis de
prévoir qu’ils seront utilisés à certains moments par plusieurs programmes.
L’utilisation des DLL permet ainsi de gagner de l’espace aussi bien sur disque qu’en RAM : si une
bibliothèque utilisable par plusieurs programmes était en effet systématiquement liée une fois pour toutes
statiquement à chacun des programmes qui l’utilise, les codes « .exe » deviendraient inutilement longs et
occuperaient inutilement de la mémoire.
La différence fondamentale entre un programme principal exécutable « .exe » et une DLL est que la DLL
est appelable par le programme « .exe », tandis que l’inverse n’est pas vrai : il est ainsi impossible de faire
exécuter une DLL seule.
Dans certains cas, les programmes principaux utilisent certaines des fonctions contenues dans les DLL,
dans d’autres cas, ces programmes ne font que gérer et coordonner les DLL, celles-ci effectuant alors les
opérations proprement dites, mais dans tous les cas, ces programmes doivent toujours faire appel à des DLL
du Système d’exploitation lui-même pour fournir des fonctions de bas niveau, comme l’affichage de boîtes
de dialogue sur l’écran.
Plus généralement encore, ces DLL peuvent contenir des procédures ou des données ou encore les 2 à la
fois.
Un très bon exemple concerne le progiciel graphique DesignCAD : DesignCAD.exe fait appel à un
ensemble de DLL où l’on retrouve à la fois des DLL du Système d’exploitation Windows, des DLL de
l’environnement de Développement Logiciel Microsoft DirectX et de l’environnement de Développement
Logiciel concurrent OpenGL, c.à.d. des 2 ensembles d’interfaces de bas niveau API intégrant de
multiples techniques pour le traitement d’images en 2 ou 3 dimensions et la reconnaissance de
périphériques divers ( souris, claviers, cartes graphiques, …) à partir desquels la plupart des progiciels DAO
et en particulier ceux assurant le Rendu 3D Temps Réel ( 3Dmax, Maya, Rhino, Lightwave, … ) sont écrits.
En utilisant p.ex. l’Utilitaire SiSoft Sandra Standard for Windows d’analyse du système ( ou Norton
Utilities de Symantec ), vous pouvez faire apparaître la liste des Librairies Partagées ou d’Extensions
d’Applications DLL utilisées par un programme en cours, p.ex., pour ce qui nous concerne, par
l’Application graphique DAO « DesignCAD 3000 » :
Voici ainsi le détail des modules utilisés par DesignCAD :
Comme dit précédemment, on y retrouve :
-
des DLL propres à Windows comme User32.DLL, OLE32.DLL, GDI32.DLL, …
-
des DLL propres à OpenGL comme OPENGL32.DLL, GLU32.DLL, …
-
des DLL propres à DirectX comme DDRAW.DLL, …
Il vient d’être indiqué que DirectX, p.ex., était une Interface de Bas Niveau « API » : ce type
d’interface concerne très directement l’objet de ce §, c.à.d. la programmation graphique.
Ces « API » sont d’abord à examiner dans le contexte plus général de la structure des Operating
Systems .
Nous induirons ce qu’il est nécessaire d’en comprendre par la considération préliminaire d’un schéma
logique global de structure d’O.S. qui n’entre pas dans les détails de l’explication de ses multiples
fonctionnalités :
LOGICIELS D'APPLICATION
API
NOYAU
PILOTES DE PERIPHERIQUES
OPERATING SYSTEM
HARDWARE
SCHEMA LOGIQUE GLOBAL D'UN OPERATING SYSTEM
Ce schéma global très simplifié divise l’O.S. en 3 couches logiques :
1° Les services fournis par l’O.S. aux Applications : les « API » (Application Programming Interface)
Les API sont des ensembles de codes préprogrammés et précompilés qui permettent aux développeurs de
connecter leurs propres programmes d’Applications ( p.ex. un progiciel de Dessin Assisté par Ordinateur
comme DesignCAD ) avec les fonctionnalités de l’O.S. sans qu’ils doivent nécessairement connaître le
détail de programmation de ces fonctionnalités, en leur fournissant une librairie de fonctions appelables au
sein de leurs propres programmes rédigés p.ex. en C++.
Les API peuvent être ainsi considérés comme des « Boîtes Noires » dont l’utilisateur peut utiliser les
fonctionnalités de façon simple en étant sûr que ces fonctions conduiront au résultat escompté, sans pour
autant savoir en détail comment ces fonctions ont été programmées par d’autres développeurs spécialisés
que lui-même.
Dans le domaine du graphique, ces API sont essentiellement GKS, PHIGS, OpenGL et DIRECTX .
Les services DirectX, développés par Microsoft, offrent l’avantage d’être directement fournis avec le
package Microsoft Windows, tandis que les autres doivent être acquis par le développeur en se le procurant
auprès d’une source tierce ( le Kit de développement SDK DirectX doit cependant être acquis séparément
chez Microsoft si vous souhaitez programmer des applications vous-même et ce, même si les DLL
utilisables par des applications qui ont utilisé ce Kit, comme – partiellement – DesignCAD, sont d’office
présentes sur votre PC s’il tourne sous Windows ).
Les 3 autres sont moins ciblés « Microsoft » et sont donc davantage universels ( pour le graphique ) et
sont d’ailleurs utilisés aussi bien dans le monde « UNIX » que dans le monde « Microsoft ».
Pour constater que DirectX est bien présent sur votre PC ( s’il fonctionne avec un O.S. Microsoft ), il vous
suffit de faire appel à l’ « outil de diagnostic DirectX » par doubles-clics successifs : « Poste de travail /
Disque local C : / Program Files / directX / Setup / DX Diag » puis en cliquant sur l’onglet « Fichiers
DirectX » dans la Boîte de dialogue « Outil de diagnostic DirectX » :
Comme vous le constatez, les fichiers fournissant les fonctionnalités DirectX et qui donnent aux
programmes d’Application comme DesignCAD l’accès aux services préprogrammés DirectX sont
essentiellement de type DLL.
En fait, DirectX n’est pas indéfectiblement intégré dans l’O.S. Microsoft Windows mais celui-ci, comme
les UNIX, est de type « ouvert », c.à.d. qu’il autorise des ajouts, sous la forme d’appels à des DLL
essentiellement.
Ce caractère « ouvert » explique d’ailleurs que des fichiers DLL d’origines autres que Microsoft DirectX,
comme OpenGL, Phigs ou GKS peuvent s’y substituer pour former des API devenant en quelque sorte
partie intégrante de la couche logicielle supérieure de l’O.S.ou, plus exactement, se substituent à cette
couche en offrant des outils spécialisés qui sont susceptibles, tout en coexistant harmonieusement avec cet
O.S., de bypasser en les remplaçant les fonctions insatisfaisantes des API standards de l’O.S., p.ex. celles
de l’ « élémentaire » GDI Windows qui gère l’affichage très simple mis en œuvre par Windows si vous
faites du traitement de texte sous Word ou du dessin basique sous « Paint »[ comme le confirme l’utilitaire
Sandra, cf. p. suivante ] mais qui devient insuffisant pour la réalisation de dessins 3D en Rendu réaliste à
grande Bande Passante .
L’utilitaire Sandra met en évidence qu’aucune des DLL de DirectX
n’intervient lors de l’exécution du petit programme de dessin « Paint » :
c’est par contre l’interface graphique GDI standard de Windows qui est utilisée.
Ceci est d’autant plus vrai que, plus généralement, la gestion du matériel ( graphique, sons, … ) par l’O.S.
Windows de base doit être considérée comme trop lente et insatisfaisante pour beaucoup d’applications
Multimédia ( images animées en rendu réaliste, son, vidéo, applications réseaux multiutilisateurs ), raison
pour laquelle Microsoft a développé les outils DirectX comme des outils de bas niveau permettant
d’accéder directement aux composants matériels de l’ordinateur et occultant ainsi le recours aux
fonctionnalités insatisfaisantes du Windows de base, comme ce qui concerne l’affichage standard
« Windows » ainsi que montré ci-dessus pour « Paint ».
DirectX, comme OpenGL, définit ainsi un ensemble de composants logiciels dédiés aux tâches de gestion
du matériel et capables de mettre en action leurs caractéristiques afin d’accélérer les traitements pour
garantir des performances optimales lors de l’exécution des applications Multimédias.
Nous verrons par après plus exactement comment un tel by-pass s’effectue.
DirectX, à la différence d’OpenGL, de Phigs et de GKS, s’adresse à tous les types d’applications
multimédias, non seulement pour ce qui est du graphique pur comme les 3 autres cités, mais encore pour ce
qui concerne la musique, la capture et la lecture de séquences vidéo sonorisées, l’utilisation de
périphériques d’entrée sophistiqués ( joysticks réactifs et manettes de jeux ), la participation à des forums
multi-utilisateurs, …
DirectX est ainsi formé d’un ensemble de composants logiciels dédicacés à tous les types d’applications
Multimédia :
-
la programmation graphique 2D et 3D : Module DirectX Graphics
la gestion des périphériques d’entrée / sortie ( joysticks, micros, … ) : Module Direct Input
la lecture et la capture de sons : Module DirectX Audio
la lecture et la capture de flux vidéo et audio ( MPEG, AVI, DVD, MP3, WAV ) :
Module Direct Show
l’écriture d’applications réseau ou de jeux massivement multi-joueurs : Module Direct Play
Ces composants logiciels ont notamment pour charge de détecter les matériels suivants en vue d’un
« paramétrage automatique » ( et transparent pour l’utilisateur ) des applications qui les utiliseront :
o
o
o
o
la carte graphique , sa résolution, le nombre de couleurs affichables, ses
capacités d’accélération 2D et 3D, son pilote ;
la carte son, son pilote et ses capacités d’accélération
les périphériques d’entrée et leurs caractéristiques ( p.ex. le nombre de boutons
équipant la souris, les capacités de « force feedback » d’un joystick, … )
les cartes réseaux et les modems.
Cette façon de reconnaître automatiquement le matériel Hardware rend ainsi ces API « transparentes » visà-vis du Hardware ( et en particulier vis-à-vis du type de carte graphique, pour autant que la carte graphique
soit câblée p.ex. pour être reconnue par OpenGL ou DirectX ) pour les utilisateurs qui vont en utiliser les
services en programmant leurs propres applications graphiques, sans qu’ils aient à se préoccuper davantage
des spécificités du Hardware qu’ils utilisent.
Remarquons à ce sujet qu’il reste toujours utile, avant d’acquérir une carte graphique, de vérifier qu’elle
supporte les fonctions accélératrices de ces API.
P.ex., la carte graphique Nvidia qui équipe mon portable « supporte » les fonctions accélératrices du
Module DirectX Graphics, soit les fonctions d’accélération graphique DirectDraw ( pour la gestion des
graphiques en 2 dimensions ) et Direct3D ( univers virtuels en 3D ), comme le montre l’outil de diagnostic
de DirectX dont il a déjà été question précédemment :
Remarquons à ce sujet que la nouvelle version DirectX 8.1 fusionne à présent les 2 modules précités sous
l’appellation DirectX Graphics.
Que ce soit pour DirectX, OpenGL, Phigs ou GKS, la façon d’intégrer les fonctions offertes par ces services
d’API dans un programme d’Application écrit par un développeur est toujours relativement identique, c.à.d.
grosso modo par appel à des routines au sein d’un programme écrit dans un langage de haut niveau, le plus
souvent en C ou en C++.
Voici, à titre d’exemple, un fragment de programme en C faisant appel à des fonctions des
Bibliothèques GL ( Graphics Library ) et GLUT ( GL Utility Toolkit ) d’OpenGL pour dessiner un carré
dont le centre de gravité correspond à l’emplacement pointé par un clic de souris, après avoir ouvert une
Window d’affichage :
glVertex2f ( x+size, y-size) ;
glEnd ( ) ;
“
# include <GL/gl.h>
# include <GL/glut.h>
Glsizei wh = 400, ww = 300; /* définit la taille de la fenêtre : height = 400, width = 300 */
Glfloat size = 30.0 /* définit la moitié de la longueur des côtés du carré */
/ *dessiner le carré */
void drawSquare( int x, int y )
{
y = wh – y ;
glColor3ub( (char) random( )%256, (char) random( )%256, (char) random( )%256 ) ;
glBegin(GL_POLYGON) ;
glVertex2f ( x+size, y+size) ;
glVertex2f ( x-size, y+size) ;
glVertex2f ( x-size, y-size) ;
glFlush ( ) ;
}
… etc … “
En fait, l’OpenGL est une bibliothèque de base qui contient un ensemble de routines de restitution ( tracé
de primitives, remplissage de polygones, gestion de la couleur, … ) et de commandes de requêtes de valeurs
de variables d’état ( globalement, des renseignements numériques à propos des dessins ) très puissante mais
volontairement limitée aux éléments de base du graphique.
Par exemple, la génération de surfaces « Nurbs » ( Non Uniform Relational B-Spline ) comme celles qui
sont le plus souvent mises en œuvre pour la construction de modèles infographiques complexes ( comme
ceux des dinosaures et autres animaux du Crétacé dans la série de la BBC de Tim Haines et Jasper James
sur les mondes disparus ) n’est pas incluse dans la bibliothèque de base ; OpenGL ne contient pas non plus
les routines de gestion des fenêtres à l’écran, qui dépendent du matériel Hardware et de l’O.S. utilisés.
Mais il existe un ensemble de bibliothèques complémentaires qui permettent de simplifier les tâches de
programmation, évitant ainsi de devoir tout reprogrammer : GLU ( OpenGL Utility Library ) contenant
notamment le traitement matriciel relatif à divers types de projections ( axono, perspectives, …) et la
génération de surfaces Nurbs ; bibliothèque de routines-gestionnaires de fenêtres ( GLX poux le XWindows d’Unix, WGL pour Microsoft Windows, PGL pour IBM OS/2, AGL pour Mac OS ) ; GLUT (
OpenGL Utility Toolkit de Marc Kilgard), kit d’outils indépendant du gestionnaire de fenêtres afin de
masquer la complexité des divers appels au gestionnaire de fenêtres ; FSG ( Farenheit Scene Graph ), kit
d’outils orienté-objet contenant des objets pré-définis et un modèle événementiel intégré pour les
interactions de l’utilisateur.
La programmation sous GKS ou PHIGS est très semblable à celle sous OpenGL, toutes relativement
faciles à apprendre et à pratiquer, d’autant qu’il s’agit d’API dédicacées « graphique pur » et non
«multimédia».
Par contre, la programmation sous DirectX est nettement plus complexe et nécessite du développeur qu’il se
spécialise notamment dans le maniement de la technologie originale « COM » ( Component Object Model
)spécialement développée par Microsoft pour établir les versions successives de l’API DirectX ( qui se
succèdent à un rythme très rapide et dont il faut encore prévoir de grandes évolutions, liées au
développement exponentiel des technologies Multimédias ) et qu’il soit rompu au C et C++ ainsi que, plus
généralement, à la programmation orientée « Objet ».
C’est d’ailleurs une spécialité que je vous conseillerai de suivre avec attention, dans le cas où
voussouhaiteriez entreprendre une carrière d’ingénieur informaticien dans le domaine passionnant du
multimédia.
Il faut noter aussi que beaucoup de progiciels DAO/CAO ou de Rendu 3D mettent à la disposition de leurs
utilisateurs, en parallèle avec le module graphique interactif ( fenêtre graphique avec menus et barres de
commande ) qui est l’outil principal proprement dit de ce type de progiciels, un module de
programmation pure dont les outils sont fort comparables à ceux offerts par les API précitées, ce qui offre
l’avantage de pouvoir travailler avec un seul package intégré où ne se pose aucun problème d’importations
dans l’univers graphique propre au progiciel interactif utilisé et où, dans la plupart des cas, les concepteurs
du module de programmation ont apporté un soin particulier pour faciliter l’apprentissage et le maniement
du langage propriétaire mis à la disposition des utilisateurs.
Si, pour utiliser efficacement DirectX p.ex., vous devez connaître parfaitement le C , le C++ et les
techniques orientées-objet avant de pouvoir utiliser les routines du package graphique de DirectX,, pour
utiliser par contre p.ex. le langage mis au point par Lightwave et la façon d’y gérer les routines graphiques,
il vous « suffit » de l’apprendre comme un tout autonome dont toute la documentation d’utilisation et
d’apprentissage est fournie de façon intégrée par la seule et même source.
Ainsi, AutoCAD est livré avec AutoLisp, version adaptée de Common Lisp, un langage dédicacé
« Intelligence Artificielle ».
DesignCAD est livré avec BasicCAD, version adaptée du langage Basic et offre aussi la
possibilitéd’appeler les routines graphiques à partir d’un programme écrit dans n’importe quel langage
permettant de créer un « OLE Automation Client », comme Visual Basic, Visual C++, Delphi, C++ Builder,
… nous y reviendrons ultérieurement.
Dans le domaine du Rendu Réaliste 3D, quelques « Majors » ont intégré un module de programmation dans
leur package comme 3DMax avec MaxScript, Maya avec MEL, Lightwave avec Lscript, dont un
exemple de programme est donné page suivante.
Au vu de ce qui précède, un constat s’impose : les bibliothèques graphiques et même les langages y associés
sont pour la plupart « propriétaires » : seuls, en fait, GKS et PHIGS y échappent.
Pour le rendu 3D réaliste, ce sont cependant de tels packages « propriétaires » qui tiennent aujourd’hui le
« haut du pavé », OpenGL étant au coude à coude avec DirectX : vous ne trouverez pas actuellement de
cartes graphiques à hautes performances qui ne soient pas câblées pour supporter ces 2 « ténors ».
A ce propos, si DirectX est typiquement Microsoft pour programmer les machines à base de processeurs
Intel, tout en autorisant aussi bien l’implantation sur machines de type « stations de travail » fonctionnant
avec processeurs Digital Alpha AXP, PowerPC, MIPS R4000, …, il faut savoir qu’OpenGL a comme
origine la Bibliothèque Graphique Propriétaire développée entre 1982 et 1992 pour des stations graphiques
très célèbres à cette époque pour leurs qualités infographiques: les Stations IRIS de SILICON GRAPHICS
fonctionnant sous UNIX.
Le choix d’un outil de programmation graphique doit donc être mûrement réfléchi, d’autant que, quel
qu’il soit, il vous réclamera un investissement « jour x homme » d’apprentissage très appréciable.
A cet égard, si votre objectif est simplement d’élargir les potentialités d’un progiciel graphique interactif et
que vous ne disposez pas des délais utiles pour acquérir les connaissances très étendues que réclamerait la
mise au point d’un logiciel en tous points original, le choix d’un package intégré à un progiciel existant,
comme Lscript de Lightwave p.ex., est certainement un très bon choix.
Voici, à titre d’exemple, comme prévu en page précédente, un tout petit fragment de code écrit sous Lscript
de Lightwave : il crée un triangle en 3D en stockant les coordonnées de ses sommets dans le tableau
« Point » :
«
main
{
editbegin ( ) ;
point[1] = addpoint ( 0, 0, 0 ) ;
point[2] = addpoint ( 0, 1, 0 ) ;
point[1] = addpoint ( 1, 0, 0 ) ;
polygon = addpolygon ( point ) ;
editend ( ) ;
}
»
Si vous avez déjà programmé en C, le décodage de ce petit fragment sera immédiat pour vous, Lscript étant
une version adaptée du C.
2° LeNoyau de l’O.S.
Le Noyau assure plusieurs fonctions essentielles au fonctionnement du système : la prise en charge des
interruptions et des déroutements, l’attribution de la puissance d’exécution aux programmes, la gestion de la
mémoire centrale, les mécanismes de synchronisation entre les exécutions de programmes et le cœur du
système de gestion des fichiers.
Dans les O.S. modernes ( chez Microsoft, le modèle initial en est Windows « NT », devenu « 2000 » puis
« XP » ), la taille du noyau est volontairement réduite au minimum et porte le nom de « micronoyau »,
toutes les autres fonctions ayant le statut de programmes d’application, ce qui permet, entre autres, de faire
coopérer plusieurs systèmes d’exploitation différents sur la même machine au-dessus du même micronoyau.
Dans une philosophie objet, ces modules deviennent autant d’objets munis d’un ensemble de méthodes
hiérarchiques et qui dialoguent en échangeant des messages.
Le schéma logique qui suit concerne l’architecture de machine virtuelle 32 bits de l’O.S. NT 4.0 et permet
de voir la place du micronoyau à l’intérieur du noyau dans cette structure hautement modulaire d’ensembles
rassemblés dans des couches qui coopèrent entre elles : chaque module réalise une fonction particulière et
disposes d’interfaces bien définies avec les autres modules :
Programme Win32
Sous-système Win32
Interface Système
MODE UTILISATEUR
MODE NOYAU
Services du système
Input / Output Manager
Cache
Manager
Manager
Objet
Manager
Sécurité
d'accès aux
ressources
Manager
Process
Drivers du
Système
de Fichiers
Local
Procedure
Call
Facility
Client /
Serveur
Drivers
Réseau
MICRONOYAU
Drivers de
Composants
Hardware
Manager
Mémoire
Virtuelle
WINDOW
MANAGER
WIN32K.SYS
DRIVERS
DE
COMPOSANT
GRAPHIQUE
HARDWARE ABSTRACTION LAYER ( HAL )
HARDWARE
NT 4.0 ( et ses successeurs récents ) est divisé en 2 sections principales dites « Mode Utilisateur » et
« Mode Noyau ».
Le Mode Noyau est un mode opératoire à « hauts privilèges » dans lequel le code a accès à l’ensemble du
Hardware et à l’ensemble de la mémoire, incluant les espaces d’adressage de tous les process du mode
utilisateur.
Le Mode Utilisateur ne dispose que de privilèges réduits sans accès directs avec le Hardware.
La Couche d’abstraction du matériel (HAL ) est une bibliothèque du noyau où se trouvent consignées
les routines d’activation des composants Hardware : cette couche logicielle se trouve au plus bas niveau du
noyau de l’O.S. et est située entre le Hardware et tous les autres modules de l’O.S.
Cette couche logicielle de bas niveau cache ou « abstrait » ( c.à.d. rend transparent ) les caractéristiques
hardware du matériel derrière des points d’entrée standards de sorte que n’importe quel hardware apparaisse
comme une boîte noire vis-à-vis de l’O.S.
Cette couche permet par exemple à l’O.S. de tourner sur différentes plateformes avec différents types de
processeurs ( Intel, Motorola, … ) et permet aussi aux pilotes ( drivers ) logiciels de haut niveau, comme les
pilotes de cartes graphiques, de formatter les données pour divers types de moniteurs.
Le Manager d’Input / Output prend en charge tous les process d’entrées / sorties et, plus
particulièrement, prend en charge les communications entre pilotes de composants Hardware et offre un
environnement approprié pour chacun d’eux.
Ce Manager I/O inclut une interface formelle et uniformisée à laquelle tous les types de pilotes peuvent
faire appel. Le modèle logique de ce Manager repose sur une architecture en couches qui permet aux divers
pilotes d’implémenter logiquement chacun une couche distincte dans ce modèle.
P.ex. des pilotes manipulent le hardware au plus bas niveau de ce modèle ; d’autres pilotes existent à plus
haut niveau et ces pilotes de haut niveau ignorent tous les détails du Hardware : avec l’aide du Manager I/O
comme interface, les pilotes de haut niveau transmettent simplement des requêtes logiques d’I/O aux pilotes
de bas niveau qui agissent directement sur le matériel.
Ces pilotes de composants Hardware, comme les pilotes de souris, de clavier, de cartes graphiques, sont
des logiciels généralement écrits en C, C++ ou en langage d’assemblage et accèdent aux registres Hardware
des périphériques au travers de points d’entrée dans les DLL du Noyau de l’O.S.
Le Window Manager est la partie du Noyau qui crée l’interface graphique Windows, avec ses fenêtres, ses
icônes, … qui vous est familière : il est composé de 2 modules fonctionnels : le Window Manager
( USER ) et le Graphics Device Interface ( GDI ).
Les Applications appellent les fonctions standards de l’USER pour créer des fenêtres et des boutons à
l’écran . Le Window Manager communique ces requêtes au GDI qui les transmet aux pilotes de composants
graphiques ( Graphics Display Drivers ) où elles sont formattées pour l’affichage.
Le GDI fournit un ensemble de fonctions standards qui permettent aux applications de communiquer avec
les composants graphiques sans rien connaître de ces composants.
Le schéma logique suivant montre l’intervention du Window Manager pour le traitement d’une
Application :
Applications
User32.DLL / GDI32.DLL
Mode Utilisateur
Mode Noyau
USER / GDI
Pilote de carte graphique
I/O Manager
Video Port
Carte Graphique
3° Les Pilotes de périphériques
Ces pilotes peuvent être considérés comme les derniers maillons d’une longue chaîne, débutant par le
logiciel d’application et se terminant par une action concrète comme le tracé d’un dessin à l’écran ou sur
une imprimante.
Les Pilotes appartiennent à une couche logicielle de l’O.S. : dans un ordinateur, beaucoup de composants
possèdent leur ou leurs propres pilotes selon qu’ils remplissent une ou plusieurs fonctions.
Chaque carte graphique possède ainsi son propre pilote.
Vous pouvez vérifier l’existence de ce pilote et surtout son N° de version soit à l’aide du gestionnaire
de périphérique de Windows, soit à l’aide de l’outil de diagnostic DirectX .
Dans beaucoup de cas, si vous rencontrez des problèmes d’affichage en utilisant un progiciel graphique
d’application récent sur une machine plus ancienne, la cause en est dans la non-réactualisation du pilote de
carte graphique: vous devez alors visiter le site WEB du constructeur de carte graphique, télécharger la
version la plus récente du pilote, la décompresser puis, si le pilote ne se charge pas « automatiquement »,
utiliser le gestionnaire de périphérique de Windows pour opérer la mise à jour . Dans certains cas ( cartes
anciennes notamment ), si vous ne trouvez pas sur le site du constructeur ce qui vous convient, voyez :
www.winfiles.com, www.driverzone.com, www.windrivers.com, www.conitech.com.
Voici comment se présentent les informations à propos du pilote de carte graphique selon qu’elles sont
obtenues à partir du gestionnaire de périphériques ou de l’outil de diagnostic DirectX :
Par le gestionnaire de périphérique, vous avez accès à l’emplacement des 3 fichiers principaux du pilote
dans le répertoire :
“ C: \ WINDOWS \ SYSTEM \ NVDISP.DRV ”.
“ C: \ WINDOWS \ SYSTEM \ NVMINI.VXD ”.
“ C: \ WINDOWS \ SYSTEM \ vmm32.vxd ( vdd.vxd ) ”.
Il est utile de pouvoir « décoder » la signification des termes particuliers utilisés pour la dénomination de
ces fichiers :
-
VMM32 signifie « Virtual Machine Manager 32 bits » et fait référence à la fonctionnalité
de Windows qui consiste à exécuter plusieurs applications en même temps ( Multitâche ) et
traite chacune de ces applications comme si elle s’exécutait séparément dans sa propre
machine virtuelle : tout se passe comme si Windows « trompait » chaque application en lui
faisant croire qu’elle a un accès complet aux ressources de la machine, même si celles-ci
sont partagées par d’autres applications ;
-
Afin de réaliser cela, Windows utilise les pilotes virtuels de périphérique ( extension
« .VXD » ) afin que chaque application puisse croire qu’elle est en liaison séparée avec
chacun des composants à l’intérieur de la machine virtuelle ;
-
Par exemple, un pilote d’écran virtuel ( « VDD » = Virtual Display Driver ) qui contrôle la
carte vidéo agit comme si plusieurs copies de ce pilote s’exécutaient en même temps et comme si
chacune communiquait de façon individuelle avec les applications : en réalité, une seule copie du
pilote est active mais ce dernier se comporte comme s’il existait plusieurs copies.
Il faut toutefois remarquer que les 3 fichiers précités ne forment pas, à eux seuls, le pilote : si vous
examinez “Windows / System”, vous y trouverez de multiples extensions d’application de type « .DLL »
qui interviennent aussi dans la constitution du pilote de la carte graphique.
1.5.5. ARCHITECTURE DE L’ INTERFACE DE PROGRAMMATION GRAPHIQUE Microsoft Direct3D
Le développeur d’une Application Direct3D peut faire appel aux services de l’API classique de Windows
( GDI ) ou court-circuiter cet intermédiaire pour attaquer directement la mémoire vidéo via les services de
Direct3D.
Toute application Direct3D doit en effet indiquer, dans le début du programme, comment elle compte
coopérer avec la gestion graphique de Windows.
L’API Direct3D comprend d’une part des couches logicielles d’émulation matérielle ( Hardware Emulation
Layer HEL ) et d’abstraction matérielle ( Hardware Abstraction Layer HAL ) proposant respectivement
l’accès aux implémentations logicielles et matérielles de leurs services.
Il est ainsi possible de procéder à des opérations de rendu 3D sans que la carte graphique ne soit équipée
d’un circuit d’accélération 3D via une émulation Hardware HEL, mais l’opération reste alors bien plus lente
que dans le cas de l’appel au HAL.
Comme déjà indiqué dans le § précédent, Microsoft offre une indépendance vis-à-vis des périphériques
Vidéo à travers la couche d’abstraction ( HAL ).
Cette HAL est une interface manipulant les caractéristiques spécifiques de chaque carte Vidéo.
Elle est fondée sur les pilotes compatibles Direct3D implémentés directement par les constructeurs de cartes
Vidéo ou de processeurs graphiques ( cf. l’exemple du § précédent pour la carte Nvidia ).
Direct3D exploite la couche HAL pour travailler directement avec le périphérique d’affichage, sans passer
par la filière Windows Manager et son GDI.
Les constructeurs de cartes Vidéo implémentent HAL dans un code 16 bits et 32 bits pour les systèmes
Windows 95/98, NT, 2000 et XP.
Hal peut être directement incluse dans le pilote d’affichage ou dans une DLL séparée du pilote et qui
communique avec le périphérique d’affichage via une interface privée définie par le constructeur de la
carte.
La HAL implémente exclusivement le code dépendant du périphérique et n’effectue aucune émulation.
Toutes les instructions ou les traitements passant par la HAL sont directement traitées par la carte
graphique, avec une accélération maximale.
Dans le cas où une instruction n’est pas supportée par la HAL, DirectX procède alors à une émulation
HEL, plus lente, qui laisse à la charge du système d’exploitation Windows le soin de la traiter : tous les
calculs sont alors effectués par voie logicielle standard et non par le câblage du matériel vidéo, d’où la chute
de performances.
Le schéma suivant synthétise ce qui vient d’être exposé :
Application Win32 Standard
Application Win32 Direct3D
Windows Manager / GDI
API Direct 3D
HEL
Device Driver Interface
Graphics Hardware
2. LES 2 CATEGORIES DE PROGICIELS D’APPLICATION CONDUISANT A LA CONSTITUTION
D’UNE BASE DE DONNEES GRAPHIQUES EN CREATION D’IMAGES DE SYNTHESE
2.1. INTRODUCTION : SITUER LES OBJECTIFS DE CE COURS DANS LE CONTEXTE
GENERAL DES APPLICATIONS INFOGRAPHIQUES
Dans le 1er chapitre de ce cours, nous avons développé le concept général de Base de Données Graphiques
mais d’une façon que nous qualifierons d’ « indifférenciée », c.à.d. qu’une grande partie des notions qui y
ont été étudiées pourraient concerner aussi bien des images « naturelles » qui auraient été capturées par une
caméra ou un scanner que les images de synthèse créées de toutes pièces par un progiciel d’application de
type DAO / CAO ou par un progiciel de création d’images numériques en Rendu Réaliste 3D.
La frontière entre ces 2 types d’images, les « naturelles capturées » ou les « images construites », reste de
toutes façons assez perméable ne serait-ce que parce que, dans les 2 cas, c’est la base de données
numériques qui permet l’affichage analogique d’une matrice de pixels ( ou son équivalent en cas
d’impression « papier » ) qui va caractériser ces 2 types d’images en finalité.
L’exemple vu dans ce 1er chapitre où un tracé vectoriel était superposé à un fond constitué d’une image de
type « naturelle capturée », le tout – c.à.d. le fond + le tracé vectoriel - pouvant d’ailleurs être enregistré
sous la forme fédérante d’un fichier « .bmp », montre d’ailleurs bien combien cette frontière est fragile.
Il existe encore un exemple plus frappant dans le domaine des progiciels de fabrication d’images de
synthèse en rendu réaliste ( de type « 3Dmax, Maya, … » ) : le progiciel « ImageModeler » se démarque
en effet des autres logiciels par le fait qu’il reconstitue une image de synthèse d’un objet 3D à partir de
plusieurs photographies de l’objet, prises sous différents angles ( il s’agit en fait d’un procédé dérivé de ce
que l’on appelle la technique photogrammétrique, utilisée depuis fort longtemps pour la digitalisation de
bâtiments, ouvrages d’art et sites archéologiques et où les procédés analogiques de restitution utilisés jusque
dans les années 1980 sont aujourd’hui supplantés par des procédés infographiques ) : on voit le bénéfice
qu’un tel procédé peut apporter pour la réalisation de films mettant en scène p.ex. des mammouths ou des
hommes du néolithique : il suffit de photographier des éléphants ou des personnages contemporains, d’en
former l’image de synthèse à l’aide de surfaces Nurbs puis, une fois ces modèles numériques acquis, de les
« retravailler » en modifiant les morphologies digitales et en ajoutant numériquement des poils et des
fourrures ( il existe d’ailleurs des plugs-in spécialisés pour ce faire ) pour obtenir, in fine, des images
numérisées très réalistes de ces « reconstitutions ».
Même dans un secteur industriel comme la Construction Automobile où l’on pourrait penser, en première
analyse, que les images de synthèse et notamment celles associées à la conception de plans par
DAO/CAO/CFAO ( Conception et Fabrication Assistées par Ordinateur ) prévalent sur les images
naturelles capturées qui, à première vue, pourraient sembler anecdotiques dans ce milieu, ces images
capturées ont en réalité une telle importance que RENAULT a développé une vaste application de
photothèque numérique à usage industriel, baptisée « CHEFREN » pour laquelle cette entreprise a consenti
de lourds investissements : cette photothèque industrielle, diffusée par Intranet dans les services de
l’Entreprise, avec évidemment toutes les restrictions d’accès utiles au niveau du serveur, concerne un fonds
roulant de 30.000 images en ligne, avec un renouvellement annuel de 100% : ces images naturelles
capturées concernent aussi bien les photos confidentielles des prototypes que celles réalisées sur les bancs
de test, que celles donnant le détail des pièces détachées, que celles concernant la vie de la Société ( images
de chantiers, … ) …
Il est alors significatif de constater que, dans la chaîne de constitution de cette photothèque dynamique chez
RENAULT, coexistent des matériels d’acquisition d’images naturelles ( scanners, appareils photos
numériques, caméras haute résolution ) et des stations informatiques de retouche d’images naturelles et de
création d’images de synthèse : voilà donc un exemple typique où, dans un milieu industriel pourtant très
orienté vers la production et où, à première vue, on penserait volontiers que la création de plans et d’images
de synthèse importe bien plus que l’acquisition d’images naturelles, la frontière entre ces 2 catégories
distinctes d’images devient évanescente.
Bien qu’il soit ainsi patent qu’il n’existe plus aujourd’hui de véritable frontière entre « image naturelle
capturée » et « image de synthèse », nous en établirons cependant une pour ce cours d’infographie, ne
serait-ce que parce qu’il n’est pas possible, dans le temps qui vous est imparti, de couvrir tous les domaines
de l’Infographie dont, plus généralement encore, la frontière avec le Multimédia devient de plus en plus
fragile : l’exemple du package des API Microsoft DirectX dédicacées tant aux images de synthèse qu’aux
sons et à la connectivité en réseau est un indicateur de première importance quant à l’évolution en ce
domaine.
Aborder le domaine de la capture des images naturelles supposerait en effet non seulement une incursion
dans les technologies numériques de prises de vues, mais encore dans le domaine complexe du traitement
de ces images numérisées, c.à.d. notamment l’étude des algorithmes de manipulation des images dans le
domaine des amplitudes et des fréquences : déplacement d’une portion d’image, calcul et égalisation de
l’histogramme d’une image, filtrage d’images, … c.à.d. les algorithmes mis en œuvre dans les progiciels
dits de « Retouche d’Image », comme les très connus et réputés ADOBE PHOTOSHOP ou PAINT SHOP
PRO ( www.jasc.com ) et dont le petit programme Kodak Imaging fourni en standard dans les accessoires
de Windows peut vous servir d’introduction quant aux services que peuvent rendre ces progiciels de
retouche.
En particulier, aborder ce domaine nécessite aussi une étude circonstanciée des algorithmes de
compression d’images : la définition d’une diapositive standard 24 x 36 est de 2000 x 3000 points ; en
codage à 24 bits/point ( 16 millions de couleurs ) , le fichier brut occuperait 18 Mo et un film de 36 vues
occuperait donc 0.63 Go. La transmission du fichier brut d’une seule diapositive par une ligne à 19.200
bits/s réclamerait 7500 secondes, soit un peu plus de 2 heures.
La nécessité d’une compression du fichier s’impose donc, à la fois pour le stockage en mémoires et pour la
transmission réseau, pour des images naturelles mais aussi pour les images de synthèse en rendu réaliste
dont les tailles de fichiers sont assez comparables : même en limitant ce cours aux images de synthèse,
l’étude de ces algorithmes de compression est donc incontournable ;
2.2. GENERALITES A PROPOS DES 2 CATEGORIES DE PROGICIELS D’APPLICATION
CONDUISANT A LA CONSTITUTION D’UNE BASE DE DONNEES GRAPHIQUES EN
Pour l’utilisateur, il existe, en fait et comme déjà évoqué précédemment, 2 façons très différentes de
constituer une base de données graphiques pour constituer une image de synthèse :
- La première procède par l’écriture d’un programme d’Application.
De tels programmes à destination graphique se composent d’un noyau « classique » écrit dans un
langage dit « de haut niveau », le « C » p.ex., et d’appels à une « librairie » graphique spécialisée
offrant à l’utilisateur une collection de « routines » graphiques pré-encodées
- La seconde consiste à utiliser un programme « tout fait », une « Boîte noire »,
offrant à l’utilisateur, de façon conviviale et interactive par le biais d’une interface graphique, un
ensemble de fonctionnalités graphiques paramétrées standards lui permettant de réaliser un dessin de
façon interactive même s’il ne possède aucune connaissance en programmation.
Ces 2 catégories distinctes d’approche seront développées dans ce cours, après en avoir exposé les grandes
lignes directrices dans ce 1er fascicule du cours consacré à l’Infographie.
2.3. INTRODUCTION GENERALE AU MODE « PROGRAMMATION »
Le premier mode d’approche consiste donc, pour l’utilisateur et comme déjà évoqué en page précédente, à
rédiger lui-même un programme dans un langage de type « C » par exemple et d’y faire appel à une
bibliothèque tierce de routines graphiques. La compilation et l’édition de liens pour ce programme
donnera lieu à la constitution d’un fichier en langage machine régulant, en exécution, l’affichage à l’écran.
Cette première approche possible pourrait être qualifiée d’essentiellement « statique » en ce sens que telle
démarche repose sur la constitution préliminaire du fichier avant tracé du dessin, sans même qu’une
intervention interactive de l’utilisateur lors de la phase d’exécution d’un tel programme ne soit nécessaire.
Ce serait p.ex. le cas du simple dessin d’une courbe à partir d’une équation.
Le programme serait alors établi pour faire apparaître ce dessin sur un périphérique graphique :
o
d’abord par programmation en « C » du calcul numérique d’un grand nombre
de points de cette courbe à partir de l’équation ( c’est la partie « classique » du
programme, analogue dans ses objectifs à ceux de tous les programmes que
vous avez déjà eu l’occasion de concevoir pour réaliser des calculs divers)
o
ensuite, en faisant appel à un ensemble de routines d’une librairie graphique,
routines où se trouvent précodées de petites unités de programmes régissant la
gestion du tracé graphique et réalisant ainsi le transfert de l’information vers le
périphérique afin d’y dessiner, dans une fenêtre ouverte par ce programme sur
l’écran et dont les dimensions sont à préciser comme arguments de la fonction
d’ouverture de cette fenêtre ( l’une des routines mises en œuvre par appel dans
le programme ), la couleur du fond étant également imposée par argument, une
chaîne de petits segments de couleur précisée via argument, approchant la
courbe « mathématique » lisse (discrétisation de la courbe en un grand nombre
de petits segments )
Toutes les opérations codées par ce programme sont finalisées par le programme lui-même sans aucune
intervention ultérieure nécessaire de l’utilisateur, sinon un simple ordre d’exécution de ce programme
exécutable après compilation ( et édition de liens ).
Cette carence d’interactivité est toutefois loin d’être une règle absolue pour ce type de programme : un
exemple très simple d’interactivité serait que l’utilisateur soit invité, en cours d’exécution du programme
précité, à préciser de façon interactive, via une instruction passée par la voie du clavier p.ex., l’épaisseur du
trait ou la couleur des segments.
Plus généralement, il est clair que la constitution d’un progiciel graphique interactif de type DAO / CAO
2D ou 3D s’opère par la voie d’une programmation de ce progiciel réalisée par les développeurs de la
Société qui commercialise de tels outils et que, dans ce cas, qui dit interactivité doit supposer que le
programme ainsi établi comportera de multiples possibilités d’enregistrer des actions en Input ( des pointer /
cliquer de souris sur icônes p.ex. ) et d’y réagir dynamiquement.
Comme le niveau d’interactivité reste toujours cependant un cas d’espèce, les routines graphiques des
librairies commercialisées ( type OpenGL, DirectX, … ) offrent en général une large gamme de fonctions et
procédures destinées à gérer de telles interactivités, outre les fonctionnalités de base de tracé proprement
dit.
Ces routines graphiques sont donc bien de petites unités de codage préétablies qui permettent à
l’utilisateur de se dispenser de devoir réécrire les lignes de code afférentes à l’exécution d’actions
graphiques « standard », aussi bien en Sortie ( p.ex. le tracé d’un segment ou d’un item alphanumérique
dans une fenêtre à l’écran) qu’en Entrée ( p.ex. capter les coordonnées d’un point désigné sur écran par un
curseur dont les déplacements sont commandés par glissements de souris, lorsqu’un Clic de Bouton Gauche
de souris est opéré pour finaliser la désignation du point ).
Nous avions déjà répertorié dans le 1er chapitre tout un ensemble de librairies graphiques (API ) comme
OpenGL, DirectX, …, certaines étant même intégrées dans le package du progiciel graphique interactif, le
plus souvent alors accompagnées d’un langage de haut niveau « propriétaire » et, en l’évoquant, nous
avions indiqué que nous en dirions davantage à propos de ce qu’offre DesignCAD en ce domaine, étant
entendu que ce progiciel sera celui avec lequel vous ferez vos premières armes.
DesignCAD, outre sa fonction principale d’outil interactif DAO classique, met ainsi à la disposition de
l’utilisateur une telle bibliothèque dont les routines sont appelables au sein de programmes rédigés en divers
langages, comme le Visual Basic, le Visual C++, Delphi, … afin que ses utilisateurs puissent étendre les
fonctionnalités offertes par l’outil interactif de base moyennant un effort complémentaire de
programmation : c’est ainsi p.ex. qu’un utilisateur de bon niveau sachant programmer peut rédiger luimême de petites routines dites « macros » destinées à automatiser l’exécution de séquences d’instructions
enchaînées.
DesignCAD a aussi développé, en parallèle, son propre langage de programmation propriétaire, le
BasicCAD, combinaison de fonctions issues d’un interpréteur Basic classique et de fonctions intrinsèques
graphiques propres à ce logiciel graphique.
BasicCAD offre l’avantage d’une relative simplicité dans la rédaction des programmes, ce qui en fait un
outil intéressant pour un premier apprentissage de l’utilisation d’une librairie graphique, notamment parce
que le vocabulaire de désignation des procédures est commun – moyennant traductions U.S. pour les
utilisateurs de la version française de DesignCAD – à l’usage de l’interface graphique interactive DAO de
DesignCAD et à l’usage des routines de la librairie graphique.
Il ne faut cependant pas s’attendre à pouvoir utiliser BasicCaD pour réaliser des programmes
infographiques hypersophistiqués, d’autres outils étant bien davantage à privilégier pour ce faire, comme
les librairies graphiques DirectX ou OpenGL, devenues des « Standards » aujourd’hui et sur base
desquelles les versions actuelles du progiciel DAO DesignCAD lui-même ont d’ailleurs été établies.
Cette simplicité n’empêche nullement qu’il peut présenter une efficacité professionnelle certaine dès lors
que l’application envisagée reste une simple extension du logiciel graphique interactif.
Un programme rédigé en BasicCAD est consigné aux 2 pages suivantes à titre d’exemple.
Il est destiné à faire afficher à l’écran un cube en représentation filaire, les arêtes étant de différentes
couleurs, sans autres interventions de l’utilisateur que l’écriture préliminaire d’un fichier de valeurs
numériques des coordonnées des sommets du cube sous la forme d’un fichier séquentiel, cette application
étant conçue aussi comme un exercice de lecture de fichier externe.
'COURS D'INFOGRAPHIE - Prof.Dr.ir. Y.DURAND
'PROGRAMME N°1 - DESSIN 3D DES ARETES D'UN CUBE
'Conception Y.D. - 05/06/02 - Répertoire : C:\mes documents\3DCUBE.BSC
'
'
' OBJECTIF :
' Dessiner les arêtes d'un cube de côté 10 et de sommet arrière inférieur gauche = origine
' Les arêtes du plan (z=0) auront la couleur rouge
' Les arêtes du plan (z=10) auront la couleur bleue
' Les arêtes parallèles à 0z auront la couleur verte
'
'
'MODE D'UTILISATION :
'1.Ecrire un fichier séquentiel (C:\mes documents\FICHNUM3.TXT) au moyen d'un éditeur
' de texte (Bloc-note,Wordpad,Word,...) de 10 lignes et 3 colonnes décrivant, ligne par ligne,
' les coordonnées x,y,z des sommets du cube : les 5 premières lignes correspondent aux 4
' sommets de la face(z=0), la 5e ligne reprenant les coordonnées du 1er sommet ( en effet,
' la 4e arête du cube joint le 4e sommet au premier) ; de même pour les 5 lignes suivantes
' qui correspondent aux sommets de la face (z=10).
' Ce fichier séquentiel sera appelé et lu au sein du programme BasicCAD décrit ci-après.
'
' 2.En exécution :
' a. Ouvrir le programme graphique DESIGNCAD en mode 3D
' b. Dans son menu de commande, cliquer sur "outil" et dans le menu déroulant associé,
'
choisir : "Exécuter Macro"
' PROGRAMME écrit en BasicCAD :
dim x(10),y(10),z(10)
'Dimensionne les vecteurs x(i),y(i),z(i) [coordonnées des sommets]
open "I",1,"c:\mes documents\FICHNUM3.TXT"
'Ouvre le fichier séquentiel FICHNUM3.TXT créé
'préalablement pour stocker les coordonnées des
'sommets.Puisque déjà créé, il sera lu ( "I" =
'Input ).Son accès dans l'arborescence est à
'définir ( p.ex. "c:\mes documents\FICHNUM3.TXT ).
'Il est référencé par un N°( p.ex.1 ) [ à noter que
'seuls 4 fichiers (1 à 4) peuvent être ouverts
'simultanément ].
for i = 1 to 10
input #1, x(i),y(i),z(i)
'boucle ( for...next )
'instruction de lecture séquentielle du fichier 1,
'c.à.d. de gauche à droite et de haut en bas et
'stockage des valeurs dans les vecteurs x, y et z
next i
close 1
Voir Suite p. suivante …
'après lecture, le fichier est à refermer
'TRACE DES SEGMENTS ( couleur rouge) DU PLAN (z=0)
'1° Définition de la couleur du trait (">customcolor" = commande Macro DESIGNCAD indiquant
' qu'une couleur est à imposer ; "<color [255,0,0]" précise les paramètres définissant
' la couleur, dans l'ordre des saturations RGB : "255" = saturation max de rouge, "0" =
' saturation min de vert( "G"=Green ) et "0"=saturation min de bleu).
>customcolor
{
<color [255,0,0]
}
'2° Tracé des segments (">line" = commande Macro DESIGNCAD de tracé de segment ;
' "pointxyz [x(i),y(i),z(i)] précise les paramètres définissant le point origine
' du segment et "pointxyz [x(i+1),y(i+1),z(i+1)]" ceux du point extrémité).
for i = 1 to 4
>line
{
<pointxyz [x(i),y(i),z(i)]
<pointxyz [x(i+1),y(i+1),z(i+1)]
}
next i
'TRACE DES SEGMENTS (couleur bleue) DU PLAN (z=10)
>customcolor
{
<color [0,0,255]
}
for i= 6 to 9
>line
{
}
next i
'TRACE DES SEGMENTS (couleur verte) PARALLELES A OZ
>customcolor
{
<color [0,255,0]
}
for i = 1 to 4
>line
{
}
next I
end
Le résultat graphique de l’exécution de ce programme en BasicCAD est le suivant :
De façon plus générale, de telles librairies graphiques mettent à la disposition des développeurs des
groupes d’outils prédéfinis et paramétrés qui ont pour objets principaux :
- les tracés graphiques de base ( tracés de points, de segments, de polylines, de
polygones, de courbes et d’arcs, de surfaces comme des plans, de volumes
comme des cônes, des cylindres, …, de hachures, de lettrages, … c.à.d. des
primitives, qu’elles soient curvilignes, surfaciques ou volumiques)
- la gestion des attributs de ces primitives ( type et épaisseur du trait, couleur,
forme et dimension du point, nombre de polygones discrétisant une surface, … )
- les transformations des primitives ou de groupes de primitives ( copies,
rotations, translations, effacements, opérations de mise à l’échelle, … ) c.à.d.
toutes les opérations groupées sous l’appellation « Edition des primitives »
- la gestion des structures hiérarchiques ( combinaisons booléennes de
primitives ou de groupes de primitives pour former des objets complexes )
- les opérations de visualisation : fenêtrages ( windows ) et clôtures ( viewports
), découpages ( clipping ), projections ( axonométries, perspectives,
projections de Monge )
- le rendu réaliste en 3D ( élimination des parties cachées, ombrages, textures,
matières, éclairages )
- la gestion des entrées / sorties depuis et vers les différents périphériques
( capter un Clic de souris et la localisation correspondante du curseur sur
l’écran graphique, identifier une primitive ou un groupe de primitives en les
désignant par le curseur et en validant cette désignation par un clic de bouton de
souris, … )
- la fourniture des informations sur les configurations « Hardware » (
résolutions d’écran, nombre de couleurs affichables, … )
- la gestion des erreurs
- …
Toutes ces routines sont sous-tendues par une structure algorithmique complexe, consistant en
applications de concepts de géométrie analytique et infinitésimale.
Cette complexité impose qu’un tome spécial ultérieur du cours y soit spécifiquement dédicacé : ce
tome à caractère « mathématique » développera les algorithmes relatifs :
-
aux tracés de primitives ( comment organiser les pixels pour représenter des objets
géométriques )
-
aux transformations ( algorithmes d’édition )
-
aux projections
-
au fenêtrage ( windows, viewports, clipping )
-
au rendu réaliste 3D ( surfaces Nurbs, vu et caché, ombrage, éclairage, textures,
…)
Le problème de base afférent à ces librairies graphiques reste toutefois leur portabilité, c.à.d. leur
indépendance vis-à-vis tant du langage utilisé que du Hardware.
Transposer facilement un programme d’une machine à l’autre ou d’un langage à un autre devrait être la
règle : il est cependant évident, en comparant p.ex. les modes de programmation de DesignCAD et
d’AutoCAD, que la portabilité réciproque de l’un à l’autre ne semble pas nécessairement immédiate, en
matière de programmation en tout cas, mais il s’agit de codages « propriétaires » dont l’objectif n’est pas la
portabilité.
Dans le monde UNIX, ce souci de portabilité s’est fait jour dès les années 80 : des Normes ont ainsi été
mises sur pied dans cet objectif précis : GKS 2D ( Graphical Kernel System ) puis GKS 3D d’abord,
adoptées par l’American National Standards ( ANSI 85b ) puis par l’International Standards Organisation (
ISO ), PHIGS ( Programmer’s Hierarchical Interactive Graphics System ) et PHIGS + ensuite et
actuellement considérés comme les Standards prédominants (ANSI 88 ) parce que notamment utilisés dans
l’industrie infographique des Images de Synthèse et de leur Animation . PEX doit aussi être cité pour les
images « Bitmap ».
OpenGL, bien que de type « propriétaire », est actuellement un standard de fait assurant une très grande
portabilité, aussi bien dans le monde UNIX que dans le monde Microsoft Windows.
Pour un Bureau d’Etudes qui utilise un progiciel D.A.O. comme AutoCAD ou DesignCAD et dont
l’objectif n’est pas de concevoir, commercialiser ou transmettre du logiciel, il reste de toutes façons très
efficace de savoir programmer avec l’outil offert par le Concepteur du progiciel interactif D.A.O. utilisé,
même s’il est spécifique, parce que cela constitue une bonne garantie de fonctionnement, sans problèmes de
portabilité interne, pour les besoins propres du Bureau d’Etudes.
2.4. INTRODUCTION GENERALE AU MODE « DESSIN INTERACTIF »
La seconde façon d’établir la base de données repose sur l’interactivité : en tel cas, cette base de
donnée est évolutive, se construit et se modifie au fur et à mesure de la progression du « dialogue »
instauré entre utilisateur et PC au cours duquel les opérations d’Entrée / Sortie sont signifiées et se
traduisent par des modifications lisibles sur un document conventionnel affiché à l’écran, dit
« Fenêtre graphique », organisé et structuré de façon à assurer l’ergonomie optimum du dialogue.
En fait, ce type de fenêtre graphique vous est familier, vous qui êtes de la génération d’Etudiantes et
Etudiants qui ont n’ont utilisé des PC que fonctionnant sous Système d’Exploitation « Microsoft
Windows » et dont le principe de base est justement d’offrir à l’utilisateur la possibilité de dialoguer avec le
PC via fenêtres graphiques où des Icônes, des Menus déroulants, des Boîtes de dialogue sont les interfaces
de ce dialogue.
Vous n’aurez donc aucune difficulté à vous adapter aux fenêtres graphiques des logiciels D.A.O. de tous les
Constructeurs dont les progiciels ont été conçus en symbiose avec ce concept d’interface graphique
interactive.
Le logiciel D.A.O. que vous serez amené à utiliser au laboratoire, DesignCAD de Upperspace Corporation,
repose sur ce principe. Vous reconnaîtrez immédiatement dans la fenêtre graphique qui s’affiche dès le
lancement de ce programme une structure d’affichage où coexistent des barres d’outils où sont rassemblées
des Icônes et des commandes alphanumériques, comme pour l’interface « Windows » :
L’ECRAN GRAPHIQUE « DesignCAD »
Comme pour l’interface graphique « Windows », l’utilisateur pointera et cliquera ( Bouton Gauche de
Souris = « BGS » ) une commande alphanumérique ou une icône sur cet écran graphique et, en réponse,
l’ordinateur fera apparaître p.ex. un menu déroulant dans lequel, en poursuite du dialogue, l’utilisateur
pointera une commande particulière qui provoquera l’exécution de cette commande :
POINTER / CLIQUER SUR LA COMMANDE « DESSIN »
DANS LE MENU DEROULANT, POINTER / CLIQUER
SUR LA COMMANDE « TEXTE »
Cette action va engager la poursuite du dialogue comme suit :
-
l’ordinateur va modifier la seconde ( à partir du haut) barre d’outils et y substituer
une Boîte de dialogue où l’utilisateur est invité à introduire le texte qu’il souhaite
insérer dans le dessin proprement dit .
Accessoirement, cette Boîte de dialogue contient des Boutons dont l’enfoncement
donne lieu à l’affichage d’autres Boîtes de dialogue permettent p.ex. de définir la taille
et le style du texte, comme montré dans la copie d’écran :
TEXTE INTRODUIT, VIA CLAVIER, DANS CETTE FENETRE
UN CLIC SUR LE BOUTON « T » PROVOQUE L’AFFICHAGE
D’UNE BOITE DE DIALOGUE
-
l’ordinateur va ensuite faire apparaître sur l’écran un rectangle déplaçable par glissement
de souris ( rectangle d’encerclement du texte à insérer ) et se placer en attente d’un Clic de Bouton
Gauche de Souris qui ancrera le texte à la position souhaitée par l’utilisateur :
3. LE MODE DE DESSIN DAO INTERACTIF : INTRODUCTION DETAILLEE
3.1. L’INTERET DU MODE « DESSIN INTERACTIF »
Comment définir l’intérêt de l’usage d’un tel mode de dialogue via écran graphique ?
Ce qui apparaît très clairement déjà à la lecture du petit programme consigné quelques pages auparavant à
propos du tracé d’un cube est qu’il nécessite des connaissances et un savoir-faire de base en
programmation ; si une exploitation plus poussée de ce mode d’approche du tracé graphique devait être
entreprise, il est clair que ces connaissances et ce savoir-faire devraient s’étendre aussi à l’algorithmique
propre à l’Infographie : un autre tome de ce cours sera d’ailleurs consacré à ces concepts algorithmiques et
aux Mathématiques qui les sous-tendent .
Pour un Bureau d’Etudes dont l’objectif est de produire rapidement des plans et où les dessinateurs ne sont
pas nécessairement rompus à la programmation ni à l’algorithmique infographique, une telle approche ne
saurait être envisagée.
Par ailleurs, il est clair aussi que ce mode d’approche « par programmation » n’est ni très commode, ni très
convivial et réclame de toutes façons un investissement important en temps de développement pour réaliser
le moindre tracé, même pour un spécialiste.
L’idée s’est donc fait jour, très rapidement d’ailleurs dès après le début de la commercialisation de masse
des ordinateurs, c.à..d. vers 1975, de substituer à telle approche très spécialisée « par programmation », une
approche ergonomique et interactive basée sur le principe de l’interface graphique mettant à disposition
de l’utilisateur des menus prédéfinis et automatiquement dessinés sur l’écran où les opérations
graphiques standards (p.ex. le tracé d’un segment entre 2 points) seraient symbolisées de façon simple par
de courts textes alphanumériques ( les premiers progiciels graphiques DAO / CAO fonctionnaient en
général ainsi, que ce soit sur de « gros ordinateurs » ou sur les premiers PC fonctionnant sous DOS
exclusivement où l’utilisateur était invité à « pointer » dans tel menu alphanumérique en s’y déplaçant au
moyen des flèches du clavier puis en appuyant sur la touche « ENTER » une fois le curseur en place sur la
commande adéquate ) ou, très rapidement ensuite, par des icônes symbolisant graphiquement ces
commandes.
La sélection via « Flèches » du clavier devait, elle aussi, en raison de son défaut de commodité, être
améliorée en développant des outils particuliers de pointage ( dits « Input Devices » en anglais ) .
Il en existe de 2 catégories, les analogiques ( Type «Souris» ) et les digitaux ( Type «Light Pen» ).
La plupart de ces outils travaillent dans le plan mais certains outils très spécialisés travaillent même dans
l’espace 3D et sont susceptibles de fournir une information en X , Y, Z quant à leur positionnement dans cet
espace 3D..
Au § suivant, nous examinerons 2 des outils intensivement utilisés en Informatique Graphique :
les Souris et les Tablettes « à digitaliser » ( dites aussi « Tables à digitaliser » ou «Digitaliseurs » ).
3.2. LES OUTILS CLASSIQUES DE POINTAGE EN MODE « DESSIN INTERACTIF » :
TABLETTES ET SOURIS
Divers dispositifs destinés à faciliter la sélection d’une commande alphanumérique ou d’une icône en
évitant le recours aux flèches du clavier ont donc rapidement été développés, notamment les
« Digitaliseurs » appelés aussi « Tablettes graphiques »,c.à.d. des tablettes planes et lisses, munies en
interne d’un système de reconnaissance du positionnement d’un dispositif externe de pointage mobile
glissant sur cette surface lisse, de type « souris » ou « stylet ».
La différence fondamentale avec la souris classique qui équipe aujourd’hui tous les PC est que, dans le cas
d’une tablette à digitaliser, celle-ci une fois configurée par software pour y établir les correspondances
utiles ( par pointés sur des points de référence choisis par l’utilisateur sur la tablette ) entre le dessin tracé
sur la zone réservée utile au tracé graphique sur digitaliseur et le dessin répercuté à l’écran, les coordonnées
d’un point de cette tablette resteront toujours les mêmes, que ce point soit pointé une fois ou plusieurs fois
de suite après avoir déplacé ( et notamment soulevé) le dispositif de pointage : on pourrait donc parler à cet
égard d’un dispositif reconnaissant les coordonnées « absolues » des points de la tablette.
Pour la souris classique a contrario, l’expérience de son usage avec l’interface graphique « Microsoft
Windows » vous a certainement montré que si vous soulevez ce dispositif de pointage du tapis de souris, le
curseur « écran » s’immobilise : dès remise en contact avec le tapis, même à un tout autre endroit du tapis,
puis glissement de la souris, le curseur reprend sa course sur l’écran, mais à partir exactement de
l’emplacement qu’il occupait lorsque la souris a été soulevée puis déplacée pour être à nouveau
positionnée ailleurs sur le tapis.
Pour préciser davantage les idées à propos de la souris, il faut aussi remarquer qu’un déplacement du
curseur de 10 cm sur l’écran est impulsé par un glissement de souris de quelques centimètres seulement sur
le tapis à partir de la position primitive du curseur et ce, quel que soit l’endroit où la souris est remise
en contact avec le tapis puis soumise à glissement.
On peut aussi observer « expérimentalement » que l’amplitude du déplacement du curseur sur écran, p.ex.
les 10 cm, sera obtenue à partir des mêmes amplitudes de déplacement de la souris, quelle que soit
l’orientation de la trajectoire de la souris.
Windows vous permet d’ailleurs d’ajuster la corrélation entre amplitude du déplacement de la souris sur le
tapis et amplitude du déplacement du curseur sur l’écran par la Procédure « Windows » suivante :
Démarrer / Paramètres / Panneau de Configuration / Ouvrir l’Icône « Souris » / Sélectionner le volet
« Mouvement » dans la Boîte de dialogue « Propriétés de Souris » / Agir sur le curseur d’ajustement de
« Vitesse du Pointeur.
Vous constaterez que si la vitesse est réglée sur « lente », il est nécessaire de faire parcourir un long trajet à
la souris sur le tapis pour n’obtenir qu’un déplacement très faible du curseur sur écran et réciproquement si
la vitesse est réglée sur « Rapide ».
En synthèse et en supposant, quod non, que le dispositif « souris » soit équipé d’une loupe avec pointeur, tel
dispositif pourrait donc être utilisé pour opérer une mesure de longueur via mesure « software » sur écran
et application d’un facteur correctif de proportionnalité, mais en aucun cas pour définir la position
« absolue » d’un point sur le tapis.
Par opposition, sur le digitaliseur une fois configuré, chaque fois que le dispositif de pointage ( le stylet
p.ex. ) est positionné à un endroit précis de la tablette, le curseur « écran » se positionnera toujours au
même endroit sur cet écran, ce qui n’est donc pas le cas pour la souris
.
Par contre, comme pour la souris, à un déplacement donné du stylet correspondra toujours un déplacement
du curseur « écran » toujours identique à lui-même sur cet écran.
Cet état de fait trouve son explication dans les partis technologiques mis en œuvre dans ces 2 types de
dispositifs : ils sont fondamentalement très différents :
Les Tables à digitaliser ( invention en 1964 par les ingénieurs M.R. DAVIS et T.D. EILLIS à la
RAND CORPORATION ( U.S. ) ) contiennent, sous leur revêtement plan et lisse, un réseau dense de fils
fins ( p.ex. 1024 fils en X et 1024 fils en Y pour une surface de l’ordre de 25 x 25 cm, ce qui confère au
pointé une précision théorique de l’ordre de 2.5 dixième de millimètres ).
Le Coût d’une table à digitaliser dépend d’ailleurs non seulement de ses dimensions utiles, mais encore de
son niveau de précision.
Chacun de ces fils transporte un signal propre codé digitalement que le dispositif mobile de pointage est
susceptible d’appréhender : le stylet, p.ex., contient en effet un capteur et un amplificateur de ces signaux,
distincts de fil à fil, signaux amplifiés transmis via câble coaxial à un dispositif logique de décodage qui
transmet l’information au PC qui la traite pour la transformer, in fine, en coordonnées « écran ».
Donc, chacun des points de la tablette est caractérisé par 2 signaux propres, l’un en X, l’autre en Y et ces
signaux sont distincts de ceux émis en un point voisin.
D’autres types de dispositifs existent pour les tablettes, mais qui tous sont basés sur le même principe
général de transmettre 2 informations ( en X et en Y ) distinctes selon le point considéré, comme les
tablettes fonctionnant par détection du potentiel en un point, une feuille conductrice incluse sous le plan de
travail étant soumise, à intervalles réguliers, à l’application d’un champ de tension selon X puis selon Y.
Il est par ailleurs d’usage de recouvrir cette tablette d’une feuille où le menu est imprimé, ce qui présente 2
avantages : d’abord libérer la surface d’écran de ce menu, ensuite de permettre à l’utilisateur, si la tablette
est suffisamment grande, d’y faire apparaître, le cas échéant, toutes les icônes symbolisant graphiquement
les commandes ou tous les textes courts décrivant ces commandes en les organisant à son gré ( il faut savoir
que DesignCAD en version 3000, met en jeu un ordre de 260 icônes : il serait impensable de les faire toutes
apparaître sur écran, même sur un 21’’ ).
L’aptitude du dispositif à reconnaître les coordonnées « absolues » d’un point sur la surface de tablette
permet en effet, par configuration de la tablette, de reconnaître aussi un pointé dans une petite zone carrée
où se trouve in concreto une case du menu puis d’y associer le contenu signifiant, c.à.d. la commande
symbolisée pat l’icône ou le court texte littéral qui s’y trouve consigné.
En effet, ce système est toujours en cours aujourd’hui, notamment parce qu’il permet, concurremment au
pointé sur les cases du menu, de pointer aussi, en zone « utile/ dessin » sur un document graphique existant,
p.ex. une carte topographique « papier » pour y repérer des coordonnées de points : le dispositif mobile de
pointage est ainsi souvent muni d’une loupe contenant un repère cruciforme autorisant des pointés avec une
précision de quelques dixièmes de mm .
Il existe des tablettes graphiques allant du format « A5 » ( 15 x 21 cm ) au format « A0 » (84 x 119 cm) ,
ces dernières étant particulièrement utilisées en Cartographie.
Ce type de matériel reste aussi très utilisé en Bureaux industriels de dessin, en raison de la possibilité déjà
évoquée d’y disposer un grand nombre d’icônes organisées et structurées selon les souhaits du dessinateur.
MENU
Pointeur avec loupe
Arrondir
Arc
Bord
3
Modifier
Parallèle
Longueur
Points
Déplacer
Parallèle
Point
Distance
Joindre
Cercle
Extrémités
1
Effacer
Tout
Cercle
Dernier
Rafraîchir
2
Boîte
Percer
Zone utile
Sphère
Quitter
Digitaliseur
Hemisphère
Refaire
Cylindre
Annuler
Détail agrandi du Menu
Cône
Les souris ( invention en 1965 par le Prof. D. ENGLEBART du STANDFORD INSTITUTE ( U.S.)
et popularisée par les souris équipant les ordinateurs APPLE de type LISA ou MACINTOSH à partir de
1983 puis à partir de 1987 sur les PC IBM de type « PS/2 ), comme vous pouvez le constater si vous en
opérez un démontage de plaque inférieure entourant la boule en contact avec le tapis, contiennent en général
2 arbres en rotation, entraînés dans cette rotation par frottement de la bille en caoutchouc, les axes de ces 2
arbres étant disposés orthogonalement ; une roulette disposée dans l’axe de la bissectrice de l’angle formé
par les 2 arbres précités assure la légère force d’appui nécessaire pour assurer un frottement suffisant pour
l’entraînement des 2 arbres par la bille, elle même mise en rotation par frottement sur le tapis pour tout
mouvement de glissement de cette souris.
Chacun de ces 2 arbres commande un capteur de rotation susceptible de développer une impulsion
électrique pour chaque micro-incrément de rotation : l’amplitude des rotations est donc mesurée par ces
capteurs via le nombre d’impulsions ; ces capteurs sont reliés à un circuit électronique qui transmet
l’information au PC.
D’aucune façon donc, un tel dispositif ne saurait, comme une table à digitaliser, fournir une information
relative à la position de la souris sur un plan : tout ce que la souris est susceptible de fournir est l’amplitude
d’un mouvement de glissement opéré entre un point quelconque et un autre point quelconque sur ce plan.
1.
2.
3.
4.
5.
Capteur de rotation
Arbre en rotation
Bille caoutchouc
Roue passive d'appui
Circuit électronique
CONSTITUTION SCHEMATIQUE INTERNE D'UNE SOURIS
3.3. LE MODELE LOGIQUE D’UN ENSEMBLE DAO INTERACTIF : LES RETROACTIONS
Comme les copies d’écrans graphiques « DesignCAD » et les quelques premières explications à leur propos
l’ont montré, l’un des principes essentiels présidant à l’exploitation de tels écrans, où les utilisateurs sont
amenés à définir des actions par le biais d’opérations « pointer / Cliquer ( B.G.S. ) » sur les icônes ou textes
des commandes, est le principe de Rétroaction ( « Feedback » en anglais ).
Des modifications ponctuelles mais significatives sur l’écran graphique y attestent en effet que les actions
engagées par l’utilisateur sont correctement enregistrées par le Système : tel est le cas lorsqu’un « Pointer /
Cliquer ( B.G.S. ) » sur une icône se traduit par un message graphique du système, soit l’ « enfoncement »
de cette icône, bien visible pour cet utilisateur.
De tels signaux graphiques « en retour » montrent à l’utilisateur que, non seulement son action a été
correctement enregistrée, mais qu’en outre, il peut poursuivre l’action au-delà.
Ainsi, si l’action entreprise concerne le dessin d’un segment entre 2 points à poser librement sur le plan
de travail, l’utilisateur opérera d’abord un « Pointer / Cliquer ( B.G.S. ) » sur l’icône symbolisant la
commande de tracé d’une polyline dans la Boîte à Outils Générale.
La rétroaction s’étagera dans ce cas en 3 volets :
o
d’une part, l’icône va s’enfoncer ;
o
d’autre part, le curseur, de « Flèche » qu’il est en « standard », va changer de
forme et se transformer en une « Croix » ;
o
enfin, un court texte d’aide rappelant la signification de l’icône cliquée
s’inscrit dans la « Barre d’Etat ».
Ces 3 Rétroactions successives vont signifier, dans l’ordre, que la commande a bien été enregistrée,
d’abord ; que l’utilisateur est invité, ensuite, à poser le 1er point d’extrémité du segment à l’emplacement
qu’il souhaite sur le plan de travail.
Détail de l’enfoncement de l’icône :
Détail du texte de Barre d’Etat :
Dès ce point posé par un Clic ( B.G.S. ), un nouveau « message » de Rétroaction du Système va être envoyé
à l’écran sous forme graphique : un « Segment élastique » va en effet apparaître, ancré à l’une de ses
extrémités sur le 1er point posé et s’étirant à partir de cette 1ère extrémité, cet étirage étant conduit par l’autre
extrémité où apparaît à nouveau le curseur sous la forme d’une croix, croix dont les déplacements sur le
plan de travail sont régulés par glissements de la souris : ce segment élastique et cette croix sont les 2
messages de Rétroaction indiquant à l’utilisateur qu’il est invité à poursuivre l’action dès après avoir posé le
1er point.
Le tracé du segment sera finalisé par un Clic ( B.G.S. )puis un appui sur la touche « ENTER » du clavier
dès que le point souhaité par l’utilisateur est atteint sur le plan de travail par le curseur « Croix » ; la
Rétroaction va se traduire, cette fois, en 5 volets : dès après le Clic ( B.G.S. ) ancrant la 2ème extrémité, le
segment se trace définitivement, les 2 croix d’extrémités disparaissent et le curseur réapparaît sous sa forme
standard « Flèche » , l’icône revient à son état inerte d’origine et le texte de barre d’Etat disparaît :
Détail du retour de l’icône à son état inerte :
Détail du texte de Barre d’Etat : le texte décrivant la commande de tracé a disparu
A l’évidence, de telles rétroactions sont à intégrer dans la structure du modèle logique régissant le
fonctionnement d’un Système informatique interactif DAO.
Sans ces Rétroactions, le modèle se réduirait au schéma simplifié suivant :
TRAITEMENT
des
SORTIES
HARDWARE
de
SORTIE
BASE
de
DONNEES
TRAITEMENT
des
ENTREES
HARDWARE
d'
ENTREE
Selon tel dispositif simplifié, caractérisé par une totale carence de Rétroactions, toute action d’Entrée de
l’utilisateur provoquerait, sans contrôle ni retour possible, une modification de la Base de Données,
modification qui, elle-même, se traduirait par une incontournable modification de l’affichage, en Sortie.
Un tel modèle logique ne peut se concevoir en application technologique que si, par destination, les actions
d’Entrée doivent être simplifiées au maximum et si, en outre, la réponse d’affichage doit être la plus rapide
possible : ce type de modèle trouve ses applications dans les jeux vidéos d’action « en temps réel » ou dans
les Simulateurs ( progiciels de type « Flight Simulator » ) embarqués sur consoles de jeux ( type
« PlayStation PS2 » de SONY ) ou sur PC.
En tels cas en effet, le périphérique d’Entrée se réduit le plus souvent à du matériel hautement dédicacé
essentiellement conçu pour reproduire le matériel qui, dans la réalité, conduit l’action .
Les plus significatifs à cet égard sont les « volants » ( Microsoft SideWinder Force Feedback Weel,
Thrustmaster Force GT Racing Wheel, Logitech Momo Force, …) , les « Joysticks » ( Microsoft Side
winder Force Feedback 2, Thrustmaster Top Gun Afterburner Thrustmaster HOTAS Cougar, …) pouvant
aller jusqu’à la reproduction exacte d’un manche à balai d’avion de combat F16 , les « Joypads »
( Thrustmaster Firestorm Dual Power Gamepad, Logitech Wingman Rumblepad, … ).
En matière de simplification des commandes exécutées par l’opérateur sur ce type de périphérique, il est
d’ailleurs significatif de relever les recherches menées par les constructeurs pour simplifier encore ces
commandes : Microsoft, p.ex., a récemment développé le « SideWinder Game Voice » qui transmet des
commandes vocales ; les armes de poing « digitales » développées pour les simulations de combats sont un
autre exemple d’extrême simplicité en « Hardware d’Entrée ».
Le contexte de la conception D.A.O. / C.A.O. est évidemment tout différent dans ses objectifs : il y est
d’abord impossible de concevoir un système où les opérations d’Entrée pourraient être réduites à de stricts
minima.
En effet et en premier lieu, ces opérations ressortissent essentiellement au prototypage, ce qui exige, par
essence-même, l’organisation de cycles « Réflexion / Action / Contrôle de l’Action / Eventuelle correction
de l’Action » : ce 1er critère impose déjà de la sophistication dans le dispositif d’Entrée.
En second lieu, tel prototypage implique la mise en œuvre de procédures multiples de modélisation
géométrique .
Or, ces procédures s’inscrivent de façon incontournable dans une arborescence complexe de Fonctions
d’Edition notamment : le Tome II de ce cours, consacré aux procédures d’Edition 2D, vous montrera ce
niveau de complexité.
Donc, le dessinateur / concepteur se trouve sans cesse face à des choix multiples et, plus particulièrement
encore, à des enchaînements de choix qui exigent à la fois des temps de réflexion, l’organisation de
procédures de contrôles et la possibilité de retours en arrière aisés.
Le Modèle Logique d’un Système D.A.O. / C.A.O. se doit, en conséquence, d’être adapté à ces exigences,
en instaurant une stratégie de Rétroactions.
En tels cas, cette stratégie se conçoit généralement en conformité avec la structure logique suivante :
HARDWARE
de
TRAITEMENT
SORTIE
des
SORTIES
3
BASE
HARDWARE
d'
de
TRAITEMENT
DONNEES
de
ENTREE
SELECTION
2
1
TRAITEMENT
INTERPRETATION
GESTIONNAIRE
des
des
du HARDWARE
ENTREES
COMMANDES
d'ENTREE
RETROACTIONS : 1. "CURSEUR" / 2. "COMMANDE" / 3. "SELECTION"
Ces dispositifs de Rétroaction concernent ainsi, dans un Modèle logique de Système D.A.O., depuis
l’Amont ( l’Entrée ) jusqu’à l’Aval ( la Sortie ) :
1. La Rétroaction la plus « immédiate » en suite de toute action au dispositif Hardware
d’Entrée : elle concerne la « Traçabilité » sur l’affichage de l’Input de positionnement
et déplacement du dispositif visant au guidage du Curseur ( Glissement de Souris sur
Tapis, déplacement de Stylet sur Tablette à digitaliser, appui sur une des Touches
« Flèches » du Clavier alphanumérique ) :
2. La Rétroaction suivante est relative à l’Interprétation des Commandes :
- si l’utilisateur pointe et clique sur une Icône de Menu, cette Icône va s’enfoncer,
manifestant ainsi, en retour, que la commande symbolisée par cette Icône est
correctement reçue :
Icône « Tracé d’un Cercle par Centre et Rayon » enfoncée suite
à un Pointer / Cliquer ( B.G.S. ) par l’utilisateur sur cette Icône
- Si l’utilisateur commet une erreur dans une commande, p.ex. , en 3D, s’il fait
appel à une commande de constitution d’un plan défini par les 4 sommets d’un
quadrilatère sans avoir préalablement et, comme il se doit, vérifié que ces 4
points sont coplanaires, un Message d’Erreur lui parvient en retour :
- Si l’exécution de la commande pointée nécessite un choix complémentaire, ces
choix apparaissent automatiquement sous la forme d’un Menu où ce choix sera
à opérer :
Menu apparaissant en suite d’un Pointer / Cliquer sur la
Commande « Option » de la Barre de Menu des Commandes
3. Un certain nombre de Commandes ne peuvent s’effectuer que si l’objet concernépar cette
Commande a été préalablement sélectionné : il en est ainsi de la plupart des Commandes
d’Edition ( Effacer, Copier, Tourner, … ).
Il est évidemment fondamental que l’utilisateur puisse se rendre compte, à l’écran, que la sélection
de l’objet est bien effective dès après que cet utilisateur a procédé à telle sélection et ce, avant
d’entreprendre sur l’objet ainsi sélectionné une quelconque opération d’Edition.
Dans le progiciel « DesignCAD », la sélection la plus élémentaire consiste à Pointer / Cliquer (
B.G.S. ) sur l’objet à sélectionner : la Rétroaction, permettant de constater que la sélection est bien
effective est relative d’abord à un changement automatique de couleur de l’entité ainsi
sélectionnée ( virage à la couleur « Magenta », communément appelée dans ce cours le « Violet » )
puis, simultanément, à l’apparition, au voisinage immédiat de l’entité, d’un gros point circulaire
bleu entouré d’un plus grand cercle bleu, rappelant l’emplacement où le Pointer / Cliquer a été
opéré en ce voisinage immédiat de l’entité pour la sélectionner :
DETAIL :
Dans les Boîtes de dialogue et comme dans le traitement de texte « Microsoft Word », il
s’impose souvent de sélectionner du texte : quand vous devez y sélectionner quelques lettres ou
quelques mots, vous Pointez / Cliquez au droit de la 1ère lettre puis, tout en maintenant le B.G.S.
enfoncé, vous déplacez un curseur ( « | » ) le long du texte à sélectionner : la Rétroaction consiste
ici à faire progresser le long du texte et selon l’avance du curseur un rectangle bleu entourant le
texte sélectionné où ce texte apparaît en sur-brillance :
Cet exemple de Rétroaction est particulièrement intéressant pour faire observer que les opérations
de rétroaction doivent généralement respecter un critère de vitesse dans l’affichage de
l’information transmise à l’utilisateur : lorsque l’utilisateur sélectionne du texte, il déplace en effet
le plus souvent le curseur à grande vitesse le long du texte à sélectionner et il est nécessaire qu’il
soit informé « en temps réel » de la progression de cette sélection.
C’est la raison pour laquelle l’information est transmise via cette inversion d’intensité des pixels
sur l’écran : les pixels du fond primitivement blanc deviennent foncés et, inversement, les pixels du
lettrage, de noirs qu’ils étaient, deviennent blancs : les dispositifs d’affichage « écran », notamment
pour les C.R.T. ( Cathodic Ray Tubes, le type le plus courant des écrans PC ) permettent
1/0);
en effet d’inverser à grande vitesse l’intensité de chaque pixel ( 0 / 1
le choix de ce type de Feedback résulte donc, en partie, de telle aptitude à la grande vitesse, ce
choix étant aussi opéré en raison de l’ergonomie du signal délivré, autre critère important pour les
choix constructifs des dispositifs dde conception des « écrans graphiques D.A.O. ».
Ce qui doit aussi être remarqué à propos des mécanismes de Rétroaction est leur place dans le Modèle
logique : si vous examinez ce modèle, vous constaterez que ces Rétroactions n’ont pas pour effet de
modifier la Base de Données.
Telle indépendance peut être facilement vérifiée lors de l’utilisation du progiciel DesignCAD, comme elle
pourrait d’ailleurs tout aussi bien être vérifiée pour d’autres progiciels D.A.O., aussi bien sous Windows
que sous UNIX : supposons en effet qu’au cours d’une session de travail où un fichier graphique a été
ouvert et dénommé « DESSIN 1.dc », une sélection soit opérée pour une figure, un polygone p.ex. en vue
de la transmettre, par Buffer « Copier / Coller » ( exactement comme vous avez coutume de le faire lorsque
vous transférez une partie de texte d’un fichier à l’autre en utilisant le traitement de texte « Microsoft
Word » ) à un autre fichier de dessin dénommé « DESSIN 2.dc ».
Lors de la sélection, le polygone change de couleur pour virer au violet, couleur caractéristique de la
sélection : une fois le transfert opéré dans le fichier « DESSIN 2.dc », on pourrait s’attendre, si la Base de
Données avait été modifiée pour y faire figurer le polygone avec, comme « Attribut », cette couleur
« violet », à ce que le polygone ainsi copié affiche encore cette couleur « violet », ce qui n’est pas du tout le
cas : vous constaterez que la couleur de ce polygone copié est restée la même que celle du polygone
original avant sa sélection .
Pour rendre l’opération encore plus parlante, essayez de telles copies après avoir modifié la couleur du
polygone d’origine dans le fichier « DESSIN 1.dc » AVANT sélection : ces changements de couleur seront
réalisés en utilisant ( cf. fascicules 2 et 3 ) une fonction d’Edition qui, elle et contrairement à l’opération de
sélection, va bien modifier la Base de données où figure la couleur de l’entité sous la forme d’un
« Attribut » de l’entité géométrique.
3.4. LES LIENS ENTRE PROGICIELS DAO INTERACTIFS ET LES BIBLIOTHEQUES GRAPHIQUES
DE TYPE PHIGS, OpenGL, …
Tout ce qui a été exposé précédemment ne peut conduire qu’à la conclusion que, pour mettre au point un
progiciel interactif DAO, il importe d’abord de le programmer et que cette programmation doit faire usage
de l’une des bibliothèques graphiques existantes, de type PHIGS, OpenGl, ….
Il a d’ailleurs été montré que DesignCAD faisait notamment usage d’OpenGL et Upperspace, son
concepteur, annonce d’ailleurs explicitement dans sa documentation en ligne que, pour la version 3000, les
aptitudes au Rendu réaliste en temps réel, c.à.d. la possibilité de déplacer rapidement sur l’écran un objet
ombré, sans qu’il soit nécessaire d’attendre, pour chaque nouvelle position occupée par l’objet, quelques
secondes de calcul pour rétablir l’ombrage comme c’était le cas des versions antérieures, reposent sur
l’utilisation toute récente de la bibliothèque graphique OpenGL :
Il est donc tout à fait naturel que la structure logique générale des progiciels DAO s’aligne sur celle
des bibliothèques graphiques :
1°. Ainsi, pour ce qui concerne les routines « dessin géométrique » proprement dites en 2D, une même
structure hiérarchique se retrouve aussi bien dans les bibliothèques que dans les progiciels DAO :
- au niveau le plus bas, le tracé des primitives de base :
- line : le segment élémentaire joignant 2 points
- polyline : ensemble ouvert ou fermé de segments jointifs en leurs extrémités
- polygones réguliers et rectangles:
- polymarkers : ensemble de symboles graphiques disposés de façon distincte
- arcs de courbes ( cercles, ellipses, Bézier, Splines )
- courbes fermées ( cercles, ellipses )
- Texte
CECI EST UN TEXTE
- Filled Areas : Surfaces hachurées limitées par entités fermées ( polygone, courbe )
Dans tous les cas, la construction de ces primitives s’opère « sous contraintes »,
c.à.d. que des conditions d’ordre géométrique sont à imposer pour cette construction
des primitives, p.ex. :
. Construire un segment en fixant ses 2 extrémités par points prédéfinis
ou par introduction interactive des coordonnées de ces points
. Construire un segment issu d’un point prédéfini et tangent à un cercle
prédéfini
. Construire un segment parallèle à un autre donné
. Construire un cercle tangent à 3 segments prédéfinis
- à ce niveau le plus bas des primitives de base, la définition d’Attributs pour ces
primitives :
- Attributs de ligne ( couleur, épaisseur du trait, type de ligne )
- Attributs de polymarkers ( forme, dimensions, couleur )
- Attributs de texte ( couleur, taille, police, épaisseur )
CECI EST UN TEXTE
CECI EST UN TEXTE
CECI EST UN TEXTE
- à ce niveau le plus bas des primitives de base encore, la recherche d’éléments
géométriques implicites, c.à.d. non créés explicitement :
il s’agit de fonctions dites d’accrochage, permettant p.ex. d’accrocher un nouveau segment
en un point particulier d’un autre segment déjà existant.
Exemples :
- accrochage d’un segment au point milieu d’un segment prédéfini:
- accrochage d’un segment au centre de gravité d’un polygone prédéfini :
- accrochage du centre d’un cercle à l’intersection de 2 segments prédéfinis
:
- au niveau supérieur, les fonctions et routines de gestion des structures de données
graphiques : en fait, la plupart des dessins sont à considérer comme des assemblages
structurés d’un certain nombre de primitives.
Pour réaliser de tels assemblages, il est nécessaire :
- de pouvoir d’abord faire subir aux primitives des transformations dites
d’ « Edition » :
COPIER
EFFACER
DEPLACER
TRANSFORMER
MODIFIER
LES ATTRIBUTS
Ex: Type de traits
- pour pouvoir faire subir aux primitives de telles transformations
d’Edition, il est nécessaire de pouvoir sélectionner préalablement une ou
plusieurs entités au sein de l’ensemble des primitives.
Pour permettre à l’utilisateur de reconnaître quelles sont ainsi les entités
sélectionnées, une fonction de mise en surbrillance ( ou de changement
de couleur ) des entités sélectionnées doit exister.
- les primitives doivent ensuite pouvoir être associées par agrégation en
tant que groupes auxquels des procédures d’édition pourront être appliquées
au même titre qu’elles l’étaient aux primitives individuelles .
Ces procédures d’agrégation doivent être susceptibles de réaliser un
groupe en cumulant par chaînage un certain nombre de primitives ( ou
de groupes déjà précédemment constitués ) ou en filtrant parmi toutes
les primitives présentes dans l’ensemble du dessin certains types seulement.
Par exemple, le progiciel DAO DesignCAD permettra de sélectionner parmi
un ensemble d’entités exclusivement les arcs de cercle et les cercles ainsi
que les items de texte pour en faire un groupe susceptible d’être copié et
déplacé en un autre endroit du dessin :
De tels groupes ( dessins d’écrous, de roulements, … ) peuvent
alors être rassemblés en fichiers ( bases de données ) dédicacés, p.ex.
comme c’est le cas pour ceux cités dans la parenthèse, en bibliothèques
de symboles mécaniques ( ou architecturaux ou électroniques,… )
importables dans tout dessin. La plupart des constructeurs de logiciels
DAO ( ou des sociétés tierces ) vendent d’ailleurs de telles bibliothèques.
L’intérêt de ces groupes du point de vue de la taille du fichier de dessin
où ils sont importés est que si un bloc est reproduit n fois dans le dessin, ce
n’est pas l’ensemble de l’information relative à ce bloc qui est reproduite
n fois dans le fichier du dessin, mais bien une simple référence à la base de
données propre à ce bloc.
- à un niveau supérieur encore, une forme particulière d’agrégation plus
globale encore est à pourvoir : elle consiste à éclater le dessin en couches
( ou « calques » ou « layers » ) comme dans l’exemple architectural
suivant où le plan d’ensemble sera établi comme réunion de 4 layers :
plan d’ensemble composé de la superposition des layers
layer 1 : uniquement des primitives « traits »
layer 2 : uniquement les hachures
layer 3 : uniquement les cotations
layer 4 : uniquement des symboles issus d’une bibliothèque de symboles
architecturaux ( fauteuils, lits, sanitaires, … )
Il est clair que, après avoir créé la couche principale 1 ( le plan-masse
de l’immeuble ) , la possibilité doit être offerte de pouvoir importer
p.ex. les symboles en les localisant par rapport au dessin de cette couche 1 :
ceci s’opère en superposant la couche 4 dédicacée au seul dessin de ces
symboles comme un calque transparent posé sur la couche 1.
Diverses opérations complémentaires doivent alors permettre de tirer un
plein profit de l’application de ce concept de couches empilées :
- activer ou désactiver l’une des couches et rendre ainsi manipulables
ou non les entités contenues dans cette couche
- déplacer ou copier le contenu d’une couche dans une autre couche
- sélectionner ou effacer toutes les entités d’une couche
En ce qui concerne les cotations, elles doivent être dynamiques, c.à.d.
qu’elles doivent s’adapter automatiquement à tout changement de géométrie de
l’objet coté imposé par l’utilisateur sans qu’il soit nécessaire pour cet utilisateur
de devoir effacer les cotes existant avant modification de l’objet et de devoir
recommencer toute la procédure de cotation après changement.
La structure hiérarchique générale d’un dessin géométrique peut ainsi être synthétisée comme suit :
Plan d'ensemble
Layer 1
Layer 2
Groupe
Layer 3
Layer 4
Groupe
Primitives
Groupe
Groupe
Groupe
Groupe
Groupe
2°. Au fur et à mesure de la construction du dessin, il est évident que la base de données s’enrichit
et se modifie : tant les bibliothèques graphiques que les progiciels DAO qui les appliquent doivent
permettre un accès permanent à cette base de données, en vue de contrôles ou de modifications.
P. ex., pour DesignCAD, il est tout à fait facile de connaître à tout moment toutes les caractéristiques tant
géométriques proprement dites que d’attributs d’une primitive, d’un groupe ou même d’une couche.
Pour les primitives ou les groupes, il suffit en effet d’un « Pointer / Double-Cliquer ( B.G.S. ) » sur la
primitive ou le groupe pour avoir accès aux données correspondantes du fichier : DesignCAD les organise
et les présente sous la forme d’une Boîte d’informations qui est en même temps une Boîte de dialogue
puisqu’en effet, il est y offert la possibilité pour l’utilisateur de modifier chacune des données apparaissant
dans les fenêtres de ces Boîtes :
Cet exemple concerne un segment dont la Boîte d’Information donne tous les renseignements utiles, dont le
type de trait, son échelle et son épaisseur :
Les coordonnées du 1er point extrémité apparaissent aussi et peuvent être modifiées ;
celles du second point sont appelables en appelant le « point N°2 » via liste déroulante qui apparaît par clic
sur la petite flèche puis clic sur « 2 » dans cette liste :
Clic ici sur « 2 »
Voici ainsi les coordonnées du point d’extrémité N°2 telles qu’elles vont apparaître après la procédure
précédente :
A un niveau hiérarchique supérieur de cette exploitation de la base de données, il est utile de
pouvoir y rechercher les renseignements nécessaires pour opérer des calculs d’analyse à propos des
entités dessinées.
DesignCAD fournit ainsi à l’utilisateur l’accès à une Boîte d’analyse :
3°. Tant les bibliothèques graphiques que les progiciels DAO qui les appliquent offrent une large
gamme de fonctions d’entrée ( INPUT ) :
- localisation sur écran via pointeur suivant les mouvements d’un périphérique externe de pointage
( souris, tablette de digitalisation, joystick, … ) et acquisition de coordonnées par clics de boutons
de ces périphériques
- introduction de chiffres ou de chaînes de caractères ( périphérique externe clavier )
- sélection d’un choix dans un menu par enfoncement de bouton poussoir
commandé par bouton de périphérique externe ( boutons de souris )
- identification de sélection d’une entité par pointer / cliquer au moyen d’un périphérique externe
( souris p.ex. ) et localisation automatique de cette entité au sein de la base de données
- …
4°. Tant les bibliothèques graphiques que les progiciels DAO qui les appliquent doivent être
susceptibles de gérer l’affichage ( OUTPUT ) .
L’affichage de l’image non distordue d’un objet 2D implique une mise en correspondance des
coordonnées de l’objet dans le monde de l’utilisateur avec celles du périphérique physique de sortie
( l’écran ou une imprimante ).
Cette opération s’opère par un enchaînement de 2 transformations dites « de visualisation »
( les explications qui suivent reposent en particulier sur le vocabulaire « PHIGS » mais les concepts sont
généralisables ) :
o
l’utilisateur définit les objets dans un système de coordonnées qui lui est
propre ( p.ex. coordonnées en mm pour le mécanicien, en cm pour l’architecte )
et qui est désigné comme « World Coordinate System » ( WCS )
o
une première transformation dite « de Normalisation » établit les
correspondances entre WCS et un système normé de coordonnées
( « Normalized Projection Coordinate » NPC ) où un « écran virtuel »
carré de dimensions unitaires ( 1 x 1 ) est ainsi défini : le monde concret est
ainsi transformé en un monde mathématique virtuel où des opérations de
transformation d’entités ( type « Edition ») ou de zoom ou encore de
découpage ( « clipping » ) pourront être réalisées selon un outillage
matriciel standardisé
o
une seconde transformation, dite « d’appareil » établit les
correspondances entre coordonnées normées NPC et coordonnées
« écran » ( Device Coordinate DC )
Ne vous inquiétez pas si cette introduction très rapide aux fonctions de visualisation vous paraît difficile :
ces concepts, pour être bien compris, doivent en fait faire l’objet des développements nettement plus
approfondis qui seront consignés dans le fascicule relatif à l’algorithmique et, mieux encore, faire l’objet
des applications pratiques qui en seront faites dans l’autre fascicule concernant les procédures d’édition des
primitives graphiques.
CE FASCICULE DE COURS EST DEDIE A LA MEMOIRE DU Prof. Dr. Edmond CARTON

fascicule i – partie i

Transcription

Documents pareils

Kit média - TAC.tvMC

Fiche technique DiMAGE Z1

Fiche technique DiMAGE Z5

CARRÉ MONTPARNASSE

Tarifs Numérique 2016 - France Télévisions Publicité

BRASIL

Ultra compacité dans un boîtier 5 Mpix zoom opt. 5x (2.8cm

Résolution - échantillonnage - Univ-lyon2

Compatibilité ProNotaire standard

caractéristiques techniques du gigashot série k série a