INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Le dispositif de commande peut être électronique ba sé sur le programme d'utilisation du matériel aboutissant à la commande incorporée (27) ; ce dispositif et le variateur intégré au système peuvent être de quelque nature que ce soit produisant le même type de résultats ; ils peuvent aussi permettre pour certaines applications une régulation de la vitesse de sortie, l'ensemble demeurant très compact.
Il va sans dire que le variateur, objet de l'invention, peut s'appliquer à de nombreux domaines dans l'industrie, en particulier pour la trac tion des véhicules (véhicules de tourisme et de transport, bateaux, tracteurs, etc..) ou pour l'actionnement de machines (machines-outils, motoculteurs, escalators, ascen seurs, etc..) ei en général à tout dispositif requérant l'utilisation d'une force motrice.
L'invention concerne un feu de signalisation pour véhicule automobile, comportant un module de lumière qui émet un faisceau de lumière; des moyens pour répartir le faisceau; une paroi opaque comportant une fenêtre destinée à permettre le passage du faisceau.
On cherche actuellement à réaliser des feux de signalisation, en particulier des feux stop complémentaires, appelés également troisièmes feux, de très faible hauteur. Ces feux peuvent être placés soit à l'intérieur du véhicule, par exemple derrière la lunette arrière, soit montés à l'extérieur du véhicule sur la tôle de carrosserie. Ils comportent un voyant, généralement muni d'un billage qui diffuse la lumière dans toutes les directions. Lorsque le feu est monté à l'extérieur du véhicule, il apparaît directement à un observateur. Lorsqu'il est placé derrière une vitre du véhicule, il peut être masqué partiellement par un cache appliqué sur cette vitre. Ce cache comporte une fenêtre qui permet le passage du faisceau lumineux émis par le feu. La hauteur de la fenêtre ne peut être inférieure à la hauteur du voyant. Cette dernière, à son tour, dépend directement du type de sources lumineuses utilisé et du système optique qui leur est associé. Pour réaliser un feu de faible hauteur, il faut utiliser des sources de faibles dimensions, telles que des diodes électro-luminescentes, des lampes T5 ou des tubes néons. De telles sources présentent des inconvénients. Soit elles sont chères unitairement, comme par exemple les tubes néons. Soit elles émettent un flux lumineux faible, ce qui oblige à en utiliser un grand nombre pour satisfaire aux exigences réglementaires en matière de photométrie. De plus, en raison des faibles dimensions du feu, les sources lumineuses sont confinées dans un faible volume, ce qui pose des problèmes d'échauffement et de tenue en température.
La présente invention a précisément pour objet un feu de signalisation qui remédie à ces inconvénients. Il est caractérisé par le fait que les moyens pour répartir le faisceau comprennent des moyens pour collimater et des moyens pour focaliser le faisceau selon une direction donnée en un segment focal qui est situé dans la fenêtre
Grâce à cette caractéristique, la fenêtre peut avoir une très faible hauteur Ainsi, lorsque le feu est éteint, il n'est quasiment pas visible de l'extérieur du véhicule. Et lorsqu'il est allumé, ses performances photométriques sont conformes aux exigences réglementaires.
Z> En outre, la hauteur apparente du feu, donnée par la hauteur de la fenêtre, est indépendante des dimensions de la (ou des) sources lumineuses utilisées. On peut ainsi choisir la nature de la source sans avoir à se préoccuper de questions d'encombrement et utiliser des sources lumineuses à la fois peu coûteuses et de foi-te intensité. Le coût de fabrication du feu s'en trouve abaissé.
description IDL tel qu'indiqué dans l'annexe 1B à la présente demande, qui fait partie de la description et à appliquer le fichier à un générateur 52 pour obtenir une partie dudit module, Pour la réalisation du générateur 52, on connaît plusieurs algorithmes de conversion, notamment les algorithmes d'administration inter-domaine et connus sous le nom JIDM (Joint-Inter-Domain Management) issus du groupement OMG. Cependant, ils ne suffisent pas pour obtenir une version complète et exploitable en langage GDMO. Cette insuffisance est due au fait que des notions conceptuelles pouvant être décrites en langage GDMO ne peuvent pas l'être en langage IDL. Ces notions sont notamment : - la définition des attributs de nommage, - des règles de construction d'arbres connus sous le nom de liens de nommage et plus ordinairement name-binding, - l'allocation d'identifieurs d'objets, et - l'utilisation d'une même description d'attribut dans des interfaces différentes.
La solution à ce problème consiste à ajouter au fichier de description IDL de l'annexe 1B des commentaires pour la conversion, tels que ceux illustrés dans l'annexe 1A. Selon l'exemple de l'annexe 1, les commentaires de l'annexe 1A sont contenus dans une zone de commentaires solidaire du fichier de description IDL de l'annexe 1B, la zone de commentaires pouvant précéder ou suivre la description IDL. Dans ce cas, la zone se distingue des autres commentaires de la description IDL (annexe 1B) par une marque, en l'occurrence la marque GEN. Selon une variante possible, les commentaires de l'annexe 1A pourraient être contenus dans un fichier similaire à la zone illustrée mais indépendant du fichier de description IDL.
Dans ce cas, il suffit d'appeler le fichier de commentaires pour compléter la description IDL. Ainsi, la description IDL peut toujours être passée au travers du compilateur IDL 95, avec les mêmes résultats, puisque la syntaxe du langage n'est pas modifiée.
La figure 5 illustre schématiquement le procédé. Le bloc 100 comprend le fichier constitué du fichier de description IDL 101 illustré dans l'annexe 1A et la zone de commentaires 102 illustré dans l'annexe 1B. Le fichier 100 est appliqué à l'entrée du premier générateur 52 pour générer le module 19 de base MIB. Le module 19 est donc un fichier de description en langage GDMO. Le module 19 est ensuite intégré dans la base MIB. En pratique, dans l'exemple illustré, l'intégration du module 19 dans la base MIB est faite par compilation du module 19. La compilation est faite ici par le compilateur GDMO 55 illustré dans la figure 2. Le module 19 est directement assimilable par le compilateur 55. Le compilateur 55 a pour nom gdmoc dans le produit OpenMaster de l'exemple considéré. Il prend la description GDMO du module 19 en entrée, en vérifie la syntaxe et entre cette description dans la base MISS 42 de la figure 2 pour rendre disponible la description aux services 40 et aux applications 31 de la plate-forme 20.
La figure 5 illustre aussi un procédé en résultant pour la génération automatique de l'intégrateur 51. Cet intégrateur tel qu'illustré sert à la conversion du langage IDL en protocole CMIP. Un agent intégrateur CORBA 17b de la figure 2 est formé selon la technique antérieure, qui consiste à appliquer le fichier de description IDL 101de l'annexe 1B à l'entrée du compilateur IDL 95. Une première partie 51a de l'intégrateur 51 est faite aussi à partir du compilateur 95. En fait, le compilateur 95 fournit une partie dite "skeleton" à l'agent CORBA et une partie dite "stub" à l'intégrateur 51 pour en constituer la première partie 51a. Une seconde partie 51b de l'intégrateur 51 est aussi faite selon la technique antérieure, qui consiste à appliquer le module 19 de description GDMO au second générateur 53, adapté à la générattion automatique d'intégrateur d'agent à partir d'une description GDMO, cet outil étant appelé OPAL/ADK dans le produit OpenMaster. À noter toutefois que dans la technique antérieure, le module GDMO était celui complété manuellement alors que dans l'invention, il est généré en entier automatiquement. Selon l'invention, une troisième partie 55c de l'intégrateur 51 est faite simplement et automatiquement à partir du
fichier 100 au moyen du troisième générateur 54. Le générateur 54 convertit le langage IDL du fichier 100 en un langage, par exemple C et/ou C++ qui sert à faire un lien entre la partie 56a générée à partir du langage IDL et la partie 56b générée à partir du langage GDMO.
Les commentaires illustrés en annexe 1A sont donnés à titre indicatif et vont maintenant être commentés. On a vu que la marque GEN est ajoutée au début d'un commentaire pour être interprétée par les générateurs 52 et 54 comme début de commentaire. Les commentaires se composent de clauses ayant chacune leur signification pour le générateur 52. Une clause se compose d'au moins un mot clé s'appliquant à au moins un attribut qui le suit. Les clauses illustrées en annexe sont classées en plusieurs types qui ont été numérotés par les lettres A-E en italique et entre parenthèses dans le seul but de faciliter leur présentation. Cette présentation est faite aussi en référence à l'annexe 2 à la présente description et en en faisant partie.
L'annexe 2 donne simplement une liste explicative des types des clauses utilisées, ici A-H.
Dans l'annexe 1A, la clause de type A se compose du mot clé METHOD~TO~ATTRIBUTE suivi d'une méthode, ici get~label, et d'un attribut, ici label. Selon l'annexe 2, cette clause indique aux générateurs 52 et 54 de convertir la méthode get~label en l'attribut label. On notera que le convertisseur 52 de services CMIS ne générera aucun service M-ACTION mais que les générateur 52 généreront l'attribut spécifié. En d'autres termes, un clause du type (A) comprend un mot clé (METHOD~TO~ATTRIBUTE), une première caractéristique représentative du nom d'une méthode et une seconde caractéristique représentative d'un attribut, le mot clé indiquant au générateur de convertir ladite méthode en ledit attribut.
Dans l'annexe 1A, la clause de type B a le mot clé MULTIPLE~DECLARE, qui signifie aux générateurs 52 et 54 qu'ils vont trouver une première interface incluant l'attribut qui le suit, ici "hostname" et une seconde interface incluant aussi cet attribut. Il est à noter qu'en langage GDMO il est possible d'utiliser la même définition d'attribut dans des
classes différentes d'objets gérés (classes MOC). Ainsi, quand les générateurs trouvent la première interface, ils génèrent une première classe MOC à partir de cette première interface et, de même, quand les générateurs trouvent la seconde interface, ils génèrent une seconde classe MOC à partir de cette seconde interface. Ils utilisent donc le même attribut, ici "hostname" dans le langage GDMO. En bref, clause du second type B comprend un mot clé (MULTIPLE~DECLARE) et un attribut, le mot clé indiquant au générateur de générer des classes d'objets à partir dudit attribut.
Dans les commentaires de l'annexe 1A, la clause de type C a le mot clé IGNORE, qui signifie aux générateur de ne pas traduire le terme IDL qui le suit. Le terme peut être notamment un nom d'interface, un nom d'exception, un nom d'attribut et un nom de méthode. Dans l'exemple illustré, le terme est un attribut nommé "ActualAttributeValue~t". En d'autres termes, les générateurs ne modifient pas le langage IDL pour la conversion. Ce mot clé offre l'avantage de ne pas générer des choses inutiles dans la description GDMO, cela sans toucher au fichier de description IDL.
La clause de type D a le mot clé TYPEDEF, qui indique aux générateurs 52 et 54 qu'il faut remplacer le premier mot qui le suit, représentatif d'un type du langage GDMO, ici "InterfaceDef", par le second mot représentatif d'un type du langage IDL, ici "Object", normalement défini par une partie code dans le fichier de description de l'annexe 1B, cette partie de code commençant ici par un terme nommé "include" et référencé par le caractère "#". Cette clause permet de faire des synonymes entre les deux langages correspondants. En fait, cette clause est un moyen de définir un type de données utilisé en langage IDL à partir du type de base. Cette définition est normalement faite par le verbe "typedef' du langage IDL et est importée dans le fichier de description à l'aide des termes "include". Cette clause s'explique par l'incapacité des générateurs de l'exemple illustré, pour des raisons de limitations imposées par la réalisation de ces générateurs, de chercher les termes "include" dans le fichier de description IDL. Comme la version courante des générateurs utilisés dans l'exemple choisi ne gère pas
les clauses de précompilation qui commencent par le caractère "#" dans le fichier de description IDL de l'annexe 1B, il a été ajouté au fichier de l'annexe 1A du code qui est présent avec les termes "include" et nécessaire à la conversion au début du fichier de description de l'annexe 1B. En outre, dans le fichier de description de l'annexe 1B, il est ajouté une première marque suivi d'un terme non défini, ici "#ifdef FOR~GENERATOR~TIME" et une seconde marque "#endif' (non illustrée). Ainsi, le compilateur 55 de la figure 2 ignore ce qui est entre ces deux marques puisque le terme "FOR~GENERATOR~TIME " n'est pas défini. Dans le compilateur, le préprocesseur (non illustré), qui génère du code C++ à partir du fichier de description, éjecte la partie entre les deux marques alors que les deux générateurs 54 et 55 vont les prendre en compte. En d'autres termes, on peut dire que si les générateurs 52 et 54 ne gèrent pas des clauses de précompilation, une clause de troisième type (D) inclut un mot clé (TYPEDEF) et deux mots, le mot clé indiquant aux générateurs 52 et 54 qu'il faut remplacer l'un (InterfaceDef) des deux mots, représentatif d'un type dudit module, par l'autre mot (Object) représentatif d'un type du langage donné IDL normalement défini par une partie de code (sous #include) dans le fichier de description.
Les clauses de type E dans les commentaires de l'annexe 1A sont relatives aux liens de nommage, appelés name-binding. Ces clauses sont dues au fait qu'il n'y a pas de liens de nommage entre classes en langage IDL mais qu'il en existe en GDMO. Cette clause permet ainsi d'introduire des liens de nommage name-binding dans une définition. Les clauses de type E comprennent trois mots clés SUPER, SUBORD et NAME, suivis respectivement de mots (caractéristiques d'objets, attributs, etc. ). Le mots clés SUPER et SUBORD désignent respectivement les classes supérieures et subordonnées d'objets et le mot clé NAME désigne l'attribut de nommage de la classe subordonnée. Par exemple, la clause "SUPER orb SUBORD AgentSystem NAME hostname" indique qu'une instance de la classe "AgentSystem" peut se trouver sous, ou être contenue dans, une instance de
la classe "orb" et qu'elle est nommée, en tant qu'attribut utilisé pour le nom RDN, avec l'attribut "hostname" qui appartient à la classe "AgentSystem". En d'autres termes, une clause de quatrième type (E) comprend trois mots clés (SUPER, SUBORD, NAME correspondant respectivement à trois caractéristiques (orb, AgentSystem, hostname), deux des mots clés désignant par leurs caractéristiques correspondantes deux instances de classes respectivement supérieure et inférieure et le troisième mot clé désignant par la troisième caractéristique l'attribut de nommage de la classe subordonnée.
* De Kochko, A Beachy, R N.
Fauquet, C Isolation and expression in transgenic tobacco and rice plants of the Cassava Vein Mosaic Virus (CsVMV) promoter Plant Mol Biol 31 1129-1139 1996 EMBL U59751 2 ccagaaggta attatccaag atgtagcatc aagaatccaa tgtttacggg aaaaactatg 60 gaagtattat gtgagctcag caagaagcag atcaatatgc ggcacatatg caacctatgt 120 tcaaaaatga agaatgtaca gatacaagat cctatactgc cagaatacga agaagaatac 180 gtagaaattg aaaaagaaga accaggcgaa gaaaagaatc ttgaagacgt aagcactgac 240 gacaacaatg aaaagaagaa gataaggtcg gtgattgtga aagagacata gaggacacat 300 gtaaggtgga aaatgtaagg gcggaaagta accttatcac aaaggaatct tatcccccac 360 tacttatcct tttatatttt tccgtgtcat ttttgccctt gagttttcct atataaggaa 420 ccaagttcgg catttgtgaa aacaagaaaa aatttggtgt aagctatttt ctttgaagta 480 ctgaggatac aacttcagag aaatttgtaa gtttg 515 3 317 ADN Artificial Sequence Promoteur MPrI 116
promoter (1) (317) 3 aagcttgcat gctgcagact agtatccgcc gtcatcaatg acatcatcac agtactgagg 60 agatgaatag ctagccatga cactctgtgc gaatattgaa gacgtaagca ctgacgacaa 120 caatgaaaag aagaagataa ggtcggtgat tgtgaaagag acatagagga cacatgtaag 180 gtggaaaatg taagggcgga aagtaacctt atgcatttgt aacttggtta cccggtatgc 240 cggttcccaa gctttatttc cttatttaag cacttgtgta gtagcttaga aaaccaacac 300 aacaacctag aggatcc 317 4 348 ADN Artificial Sequence Promoteur MPr1117 promoter (1) (348) 4 aagcttgcat gcctgcagac tagtatccgc cgtcatcaat gacatcatca gactagtatc 60 cgccgtcatc aatgacatca tcacagtact gaggagatga atagctagcc atgacactct 120 gtgcgaatat tgaagacgta agcactgacg acaacaatga aaagaagaag ataaggtcgg 180 tgattgtgaa gagacataga ggacacatgt aaggtggaaa atgtaagggc ggaaagtaac 240 cttatgcatt tgtaacttgg ttacccggta tgctggttcc caagctttat ttccttattt 300 aaacttgtgt agtagcttag aaaaccaaca caacaaccta gaggatcc 348 5 371 ADN Artificial Sequence Promoteur MPr1146 promoter (1). (371) 5 aagcttgcat gctgcagact agtatccgcc gtcatcaatg acatcatcac agtactgagg 60 agatgaatag ctagtgattg atgtgatatc aagattgatg tgatatctcc actgacgtaa 120 gggatgacgc atgccactct gtgcgaatat tgaagacgta agcactgacg acaacaatga 180 aaagaagaag ataaggtcgg tgattgtgaa agagacatag aggacacatg taaggtggaa 240
aatgtaaggg cggaaagtaa ccttatgcat ttgtaacttg gttacccggt atgccggttc 300 ccaagcttta tttccttatt taagcacttg tgtagtagct tagaaaacca acacaacaac 360 ctagaggatc c 371 6 398 ADN Artificial Sequence Promoteur MPrl 147 promoter (1) (398) 6 aagcttgcat gcctgcagac tagtatccgc cgtcatcaat gacatcatca gactagtatc 60 cgccgtcatc aatgacatca tcacagtact gaggagatga atagctagcc tgcagactag 120 tggattgatg tgatatctcc actgacgtaa gggatgacgc atgccactct gtgcgaatat 180 tgaagacgta agcactgacg acaacaatga aaagaagaag ataaggtcgg tgattgtgaa 240 gagacataga ggacacatgt aaggtggaaa atgtaagggc ggaaagtaac cttatgcatt 300 tgtaacttgg ttacccggta tgctggttcc caagctttat ttccttattt aaacttgtgt 360 agtagcttag aaaaccaaca caacaaccta gaggatcc 398 7 301 ADN Artificial Sequence Promoteur MPrl 154 promoter (1) (301) 7 aagcttgcat gcctgcagac tagtggattg atgtgatatc tccactgacg taagggatga 60 cgcatgccac tctgtgcgaa tattgaagac gtaagcactg acgacaacaa tgaaaagaag 120 aagataaggt cggtgattgt gaagagacat agaggacaca tgtaaggtgg aaaatgtaag 180 ggcggaaagt aaccttatgc atttgtaact tggttacccg gtatgctggt tcccaagctt 240 tatttcctta tttaaacttg tgtagtagct tagaaaacca acacaacaac ctagaggatc 300 c 301 8 65 ADN Artificial Sequence
Motifd,soxynucl,otidique de construction "sens" SI 8 catgctgcag actagtatcc gccgtcatca atgacatcat cacagtactg aggagatgaa 60 tagct 65 9 60 ADN Artificial Sequence Motifd,soxynucl,otidique de construction "sens" S2 9 agccatgaca ctctgtgcga atattgaaga cgtaagcact gacgacaaca atgaaaagaa 60 10 62 ADN Artificial Sequence Motif d,soxynucl,otidique de construction "sens" S3 10 gaagataagg tcggtgattg tgaaagagac atagaggaca catgtaaggt ggaaaatgta 60 ag 62 11 63 ADN Artificial Sequence Motifd,soxynucl,otidique de construction "sens" S4 11 ggcggaaagt aaccttatgc atttgtaact tggttacccg gtatgccggt tcccaagctt 60 tat 63 12 63
ADN Artificial Sequence Motifd,soxynucl,otidique de construction "sens" S5 12 ttccttattt aagcacttgt gtagtagctt agaaaaccaa cacaacaacc tagaggatcc 60 ccg 63 13 63 ADN Artificial Sequence Motif d,soxynucl,otidique de construction "sens" S6 13 catgctgcag actagtggat tgatgtgata tctccactga cgtaagggat gacgcatgcc 60 act 63 14 79 ADN Artificial Sequence Motif d,soxynucl,otidique de construction "sens" S7 14 catgctgcag actagtgatt gatgtgatat caagattgat gtgatatctc cactgacgta 60 agggatgacg catgccact 79 15 34 ADN Artificial Sequence Motif de guidage d,soxynucl,otidique de construction G1 15 gactcctcta cttatcgatc ggtactgtga gaca 34
16 33 ADN Artificial Sequence 16 gctgttgttacttttcttct tctattccagcca 33 17 31 ADN Artificial Sequence Motifdeguidage d,soxynucl,otidiquede constructionG3 17 attccacctt ttacattcccgcctttcattg 31 18 32 ADN Artificial Sequence Motifdeguidaged,soxynucl,otidiquede construction G4 18 caagggttcgaaataaaggaataaattcgtga 32
La présente demande est liée à la demande de brevet des Etats Unis également en attente N de série 08/892 734 déposée le 15 juillet 1997 (Bordereau de mandataire 65.0265), la demande de brevet des Etats Unis N de série 08/782 740 déposée le 13 janvier 1997 (Bordereau de mandataire 65.255), la demande de brevet des Etats Unis N de série 09/012 227 déposée le 23 janvier 1998 (Bordereau de mandataire 65.0255P1), la demande de brevet des Etats Unis N de série ............ déposée la même date que cette demande (Bordereau de mandataire 65. 0287) et la demande de brevet des Etats Unis N de série ........... déposée à la même date que cette demande (Bordereau de mandataire 65.0293), dont les contenus sont incorporés ici par référence.
Une partie de l'exposé du présent document de brevet contient des éléments qui sont soumis à protection de droits d'auteur. Le propriétaire des droits d'auteur n'émet aucune objection à la reproduction par facsimile de l'un quelconque des éléments exposés dans le brevet, tels qu'ils apparaissent dans les fichiers ou enregistrements du Bureau des brevets et des marques, mais se réserve par ailleurs tous droits d'auteur, quels qu'ils soient. 37 CFR1.71.
La présente invention concerne la détection de défauts dans des substrats configurés, par exemple des tranches semi-conductrices, en particulier sur la base de particularités qui apparaissent dans des images de contraste de tension.
La fabrication de dispositifs semi-conducteurs implique de nombreuses étapes de processus d'où résultent des configurations sur un substrat. Si les
configurations d'un étage intermédiaire de production sont défectueuses, il peut en résulter une microplaquette défectueuse, ce qui réduit les rendements. On connaît des procédés et appareils d'inspection des configurations sur des tranches semiconductrices à des étapes intermédiaires de production, ce que l'on appelle l'inspection "en cours". Ces procédés et appareils incluent des systèmes et des procédés basés sur l'identification. de défauts de configuration visibles dans des images optiques de la tranche. Au moins l'une des approches est basée sur des images de contraste de tension de la tranche, acquises en utilisant un microscope à balayage électronique, ou SEM selon les initiales du terme anglo-saxon Scanning electron beam, ainsi que décrit dans les brevets des Etats Unis N 5 502 366 et 5 578 821 et mis en application dans le système SEMSpec, commercialisé par KLA-TENCOR Corp.
Un procédé antérieur de détection de défauts à partir d'images de contraste de tension est basé sur un calcul de la différence des valeurs d'intensité de pixels, pixels par pixels, entre une image de la configuration à inspecter et une image de référence.
Dans ce procédé, deux images de contraste de tension, ou deux régions d'une seule image de contraste de tension, sont comparées. Pour extraire des défauts, les deux images ou les deux régions de l'image sont corrigées en premier lieu quant à des différences de brillance et de contraste, et sont alignées l'une avec l'autre. Puis, la différence des valeurs d'intensités de pixels est calculée, pixel par pixel, pour produire une image de différence. Un effet de seuil est appliqué à l'image de différence résultante afin de produire une image de défauts dans laquelle les valeurs de pixels sont binaires. Des particularités de l'image de défaut qui satisfont à certaines
conditions, par exemple de dimension ou de configuration, ou d'intensité, minimales, sont considérées comme des défauts. Des statistiques des défauts des images sont ensuite calculées et un compte rendu est effectué. Par exemple, le défaut le plus grand et le nombre total de défauts peuvent être fournis pour chaque image. Puis, les images sont visualisées sur la base de statistiques de façon que les défauts les plus significatifs soient d'abord traités et analysés, ce qui réduit considérablement le temps de visualisation.
Une force de ce procédé est qu'il n'exige que peu de connaissances des particularités ou des structures électriques des images de contraste de tension, et qu'il suffit de savoir qu'elles sont de la même dimension approximative dans les deux images ou régions de l'image, et qu'un alignement et une normalisation d'image corrige les différences d'ensemble dans les images ou dans les régions de l'image. Ce procédé permet de détecter des défauts de contraste de tension sans exiger de connaître d'abord quelles configurations électriques sont en cours d'inspection.
formules mentionnées précédemment (70) à (72) est exprimé selon les formules (75) à (77) indiquées ci-dessous.