WO2005104086A1 - Procede et systeme de construction volatile d’une image a afficher sur un systeme d’affichage a partir d’une pluralite d’objets - Google Patents

Procede et systeme de construction volatile d’une image a afficher sur un systeme d’affichage a partir d’une pluralite d’objets Download PDF

Info

Publication number
WO2005104086A1
WO2005104086A1 PCT/FR2005/000857 FR2005000857W WO2005104086A1 WO 2005104086 A1 WO2005104086 A1 WO 2005104086A1 FR 2005000857 W FR2005000857 W FR 2005000857W WO 2005104086 A1 WO2005104086 A1 WO 2005104086A1
Authority
WO
WIPO (PCT)
Prior art keywords
line
pixel
memory
objects
display system
Prior art date
Application number
PCT/FR2005/000857
Other languages
English (en)
Inventor
Philippe Hauttecoeur
Hervé Rostan
Original Assignee
Philippe Hauttecoeur
Rostan Herve
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Philippe Hauttecoeur, Rostan Herve filed Critical Philippe Hauttecoeur
Priority to EP05753728.4A priority Critical patent/EP1738349B1/fr
Priority to US11/547,812 priority patent/US20070211082A1/en
Publication of WO2005104086A1 publication Critical patent/WO2005104086A1/fr

Links

Classifications

    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
    • G09G5/42—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators characterised by the display of patterns using a display memory without fixed position correspondence between the display memory contents and the display position on the screen
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
    • G09G2340/00—Aspects of display data processing
    • G09G2340/02—Handling of images in compressed format, e.g. JPEG, MPEG

Definitions

  • the present invention relates to a method for constructing an image to be displayed on a display system. , such as a screen from a plurality of objects.
  • An object is a graphic element that can be displayed on the screen. It can be video, bitmap or vector, for example. If the "object” approach is a widespread concept at the application level, current display mechanisms are traditionally satisfied with going to look for the image already built somewhere in memory, in a predefined area which is generally the size of a video frame, hence its name “frame memory” or "frame buffer” in English.
  • an object copying module is commonly used allowing an object to be retrieved in any area and to be written to the frame memory.
  • the graphics and video systems according to the prior art use frame memories in which the images are produced from graphic and video primitives and from objects copied in these areas.
  • these are generally recombined at the time of display using mechanisms of multiplexing, inlay ("chroma-keying" in English) or fusion by transparency ("alpha-blending "in English). This approach is very demanding on memory space, especially for systems wishing to offer very good visual quality, and which therefore require multiple memory plans.
  • the present invention aims to remedy the aforementioned drawbacks by proposing an image construction method in which the useful memory for this construction and the useful power of the system are reduced compared to the systems of the prior art.
  • the above object is achieved with a method for constructing an image capable of being displayed on a display system from a plurality of objects.
  • the image is constructed line by line directly from the objects by carrying out the following steps: - for each line of the display system, this line is constructed on the fly by retrieving and storing, in real time, in at least one line memory, all pixels relating to the objects intended to be displayed on said line, and these pixels are sent to the display system according to a series of pixels, so that the the image is formed only on said display system; and in that the line construction mechanism is synchronized in line and in the frame with the plug system.
  • the present invention makes it possible to display objects directly on a display system such as a screen.
  • the object is at the heart of the image construction mechanism.
  • the construction of the image is volatile since its mechanism does not use a frame memory and that the image does not exist anywhere else except on the display system.
  • the image is first constructed From the objects, we store this image in a frame memory, then we display the already formed image.
  • display system is meant a system comprising one or more screens synchronized online and in a frame, and controlled by a single controller generating screen timing signals, this controller being placed in the accelerator. For example, from the accelerator point of view, two screens side by side can be considered as a single screen of double definition.
  • the display system can include a display memory capable of receiving the pixels forming the image. The image is then formed within this display memory rather than directly on a screen.
  • the present invention has a definite advantage over standard systems since it requires little memory (absence of frame memory), therefore a lower cost price.
  • the image is constructed directly, the operation of preparing the frame in a frame memory is avoided, hence a reduction in the necessary bandwidth at the memory level. Having fewer operations to display an image on the screen, the entire system can be less powerful, therefore less energy consuming, less disturbing, which is essential for an on-board system for example.
  • the present invention therefore makes it possible to produce images of very high visual quality from low-power components.
  • dynamic image is meant an image composed of 2D objects which can evolve over time, move, transform, change state, ...
  • two are used. line memories performing, offset, each successively a construction step then a display step so that when a first line memory displays pixels on the current line, pixels are constructed and stored in the second line memory to be displayed on the next line.
  • each object to be present on this line is independently identified according to a set variables specific to each object; a useful area corresponding to the line considered is detected in each object thus identified; and the raw data from said useful area is converted into pixels compatible with the display format.
  • the memory where the objects are stored is accessed from electronic mechanisms and the raw data from the useful areas is temporarily stored in storage means.
  • transformations and effects which are in fact digital processing, can for example be a partial display or "clipping" in English, resizing or “resizing” in English, transparency, thresholding, anamorphism, filters, ...
  • each object is therefore independently configurable and we can change the parameters of an object without affecting the other objects.
  • the realization of an HMI is therefore extremely simplified.
  • the position of this pixel in the line considered it is first possible to determine the position of this pixel in the line considered, then further to determine the value of the pixel already present in this line at the same position. Furthermore, when writing a pixel in a line memory, this pixel being intended to be displayed at a given position on a line of the display system, it is possible to apply a mixer between this first pixel and a second pixel currently stored in the line memory at said same given position, the mixer being applied in a manner proportional to the level of transparency of said first pixel.
  • the video frame comprising two distinct time zones which are a vertical dead zone, called “vertical blanking interval VBI" in English and a vertical active zone, called “vertical active interval VAI "in the English language, corresponding respectively to the interval between the two active frames and to the duration of display of an active frame
  • the stages of construction and display are carried out on the fly during each vertical active zone, and we carry out, during the vertical dead zone, any preparation necessary for the construction process.
  • Said “necessary preparation” can be any action for preparing the frame to come.
  • said "necessary preparation” is preferably any action of preparation or anticipation of construction of the line to come.
  • This preparation may include determining or updating (when the variables have already been determined) a set of variables specific to each object. These variables can be extracted from each hardware descriptor associated with each object, then stored within the accelerator.
  • a hardware descriptor is the set of graphic and display parameters defining the corresponding object.
  • the objects can be of different natures. We can have video, vector, bitmap, or other objects. Thanks to the descriptor, we can manage heterogeneous objects in the same way.
  • Said preparation can also include sorting the objects in order of depth, for example decreasing or increasing so as to prioritize the order with which the objects will be superimposed on the screen.
  • Sorting can be carried out by scanning all the objects for the first time to determine the most buried object, then by restarting the scanning of the objects without taking into account the objects already sorted, until all the objects are sorted.
  • sorting can be done during construction.
  • the volatile construction mechanism according to the invention makes it possible to take into account for each object a level of depth for the final display, making it possible to simplify the management of the recoveries of objects and windows from an application point of view, by delegating in "hardware" this complex and tedious work from a software point of view.
  • the invention does not impose from a theoretical point of view a maximum number of managed levels.
  • the present invention makes it possible to manage a very large number of graphic layers without being penalizing or sizing, both in terms of "hardware" resources, CPU power, and amount of memory. We can therefore easily produce complex transparencies: several transparent objects one above / below the other.
  • the construction of the image is managed by a hardware accelerator by means of electronic mechanisms, that is to say a hardware management, an electrical management by state machines.
  • This hardware accelerator is capable of generating the video frame of the display system. However, it can also synchronize and lock onto this video frame of the display system from synchronization information supplied by the display system itself.
  • a system is proposed for constructing an image capable of being displayed on a display system from a plurality of objects notably stored in random access memory.
  • the system comprises a processing unit such as a microprocessor associated with a hardware accelerator: to construct the image, line by line, directly from the objects, by retrieving and storing, in real time, in a line memory, all pixels relating to objects intended to be displayed on each active line of each video frame of the display system, to display these pixels by sending them to the display system according to a series of pixels at the pixel frequency, so that the image is formed as on said display system, and to synchronize the line construction mechanism, in line and in frame, with the display system.
  • a processing unit such as a microprocessor associated with a hardware accelerator: to construct the image, line by line, directly from the objects, by retrieving and storing, in real time, in a line memory, all pixels relating to objects intended to be displayed on each active line of each video frame of the display system, to display these pixels by sending them to the display system according to a series of pixels at the pixel frequency, so that the image is formed as on said display system, and to synchronize the line construction mechanism, in line
  • the hardware accelerator comprises the following elements: an object manager for activating and characterizing treatments linked to the objects, a memory for storing the parameters and variables of each object, - a hardware module of the DMA ("Direct Memory Access") type. "in English) controlled by the accelerator (and not by the processing unit) capable of recovering data from objects from a memory, a buffer memory for temporarily storing the data coming from the DMA hardware module, a decompression module and for converting raw data from the buffer into pixels, a multiplexer for selecting the pixel to be displayed between that from the decompression and conversion module and that from an external source, provided that the external source, the accelerator and screen are synchronized, a mixer to mix the pixel from the multiplexer and a pixel currently displayed checked as a function of the transparency of the pixel coming from the multiplexer, and two line memories ensuring successively in turn the display on the current line of the display system of pixels previously stored, and the storage of pixels coming from the mixer and which will be displayed on the next line.
  • DMA Direct Memory Access
  • FIG. 1 is a simplified schematic view of a process construction and display of an image according to the prior art
  • FIG. 2 is a simplified schematic view of a process for constructing and displaying an image line by line in real time according to the present invention
  • FIG. 3 is a diagram illustrating two time zones of a video frame according to the invention
  • - Figure 4 is a diagram illustrating how two line memories are used for the construction and display of image line by line according to the invention
  • Figure 5 is a simplified schematic view of a hardware accelerator implementing the method according to the present invention.
  • a module 4 for copying objects constructs said image which is then stored in a frame memory 5
  • the latter is generally the size of a video frame.
  • a display module 6 is then content to fetch the image already constructed in the frame memory 5 and to display it on the screen 1 for the duration of a video frame.
  • the present invention implements a completely different process.
  • a hardware processor or "hardware" in English, otherwise called graphic hardware accelerator for constructing said image on the fly and in real time from objects 2.
  • This accelerator in particular shown in FIG. 5, performs various operations during the video frame and repeats them with each new frame. So, during a frame, for each active line of the frame, the system according to the invention constructs in real time the pixels to be displayed on this line from objects
  • the hardware accelerator includes a module
  • VBI vertical blanking interval
  • VAI vertical active interval
  • the volatile construction For each active line of the screen, the volatile construction consists in filling a line memory with the line segments of the objects which are active in the line considered. The content of the line memory is then sent to the screen at the rate of the pixel frequency.
  • the present invention allows that when a line (L1) is displayed, during this time, the next line (L) is under construction.
  • the H synchro corresponds to the line synchronization (Horizontal)
  • the V synchro corresponds to the frame synchronization (Vertical).
  • the first step can be to decode a hardware descriptor in order to develop variables that will be used during the construction of the lines during the VAI zone.
  • a hardware descriptor is associated with each object.
  • "Material descriptor” means a coherent set of data, created and generally initialized by an application process. This descriptor contains all the information so that the hardware accelerator can display the object associated with it. This information, in particular stored in registers or memories, includes graphic parameters describing the nature of the object and display parameters. These can be separated into essential parameters (position, display attributes such as transparency level, etc.) and transformation parameters (partial display or "clipping", resizing or “resizing”, rotation, anamorphism, filters ).
  • Each object can be of a different nature in that it belongs to a given class (vector, video, bitmap, ...) or includes a given color organization (palette, black and white mode, colors in 16, 24, 32 bits, with transparency or not, ).
  • the descriptor can be local to the hardware accelerator or in an external memory. In the latter case, it is first necessary to recover the descriptor before starting decoding. Decoding the descriptor consists in extracting all the variables that will be used during the volatile construction. The decoding of the descriptor will be more or less long, more or less complex, depending on the capabilities of the hardware accelerator to perform advanced and complex functions (filters, "resizing”, anamorphism, "clipping", displacements, ...) .
  • Decoding certain information from the descriptor may even be useless if the parameters supplied already correspond to the variables useful for volatile construction.
  • the idea is to delegate the pre-processing of the raw data at the hardware level, so that it can guarantee real time and be synchronized in the frame with the volatile construction.
  • This also makes it possible to store in the descriptor advanced parameters which will be directly (or almost) transmitted by an application called API ("Application Program Interface" in English) object oriented.
  • API Application Program Interface
  • the hardware accelerator is associated with a microprocessor which is programmed to so as to offer a set of predefined functions accessible via this API.
  • Its descriptor then contains: the address where the image data in memory begins; the size of the image; the position of the object on the screen; the color organization of the bitmap image as it is stored in memory; the overall level of transparency of the object; ...
  • the coordinates of the object are slightly negative compared to the origin of the screen. Only the visible part of the object will have to be processed to be displayed, the rest being clipped. This means that the actual position of the object will have to be determined, that the address of the object in memory will have to be updated to point directly to the first visible pixel.
  • the size of the line segment useful for the volatile construction of a line must also be determined as a function of "clipping", but also as a function of the color organization of the pixels in memory.
  • the decoding of the descriptor leads to a series of working variables which will be exploited by the hardware accelerator during the volatile construction.
  • the useful variables will advantageously be stored locally at the hardware accelerator for reasons of accessibility. Some of these variables will undergo modifications as the line processes progress. For example, at the end of descriptor decoding, the address pointer points to the first active line segment of the object stored in memory. But the address pointer must point as the line processes progressively to the new active line segments.
  • a second step can be to sort the objects in decreasing order of depth. This process allows you to prioritize the order in which the objects will be superimposed on the screen.
  • Sorting can be done, for example, by scanning all the objects for the first time to determine the most buried object, then by restarting the scanning of the objects without taking into account the objects already sorted, until all the objects are sorted.
  • each object could for example contain in one of its registers, the index of the next object in an order of decreasing depth, so that the process of line construction of the image can pass simply from from one object to another, and in the order required by complex transparency.
  • Complex transparency is only obtained by the inventive principle of volatile construction according to the invention and described below
  • the volatile image building mechanism is a line process, which means that it executes again for each active line of the screen, i.e. for each line of the VAI (see figure 3).
  • Line process The line construction mechanism is synchronized with the display mechanism, which simply consists in sending a series of pixels at the pixel frequency to the screen. To do this, we can very well use only one line memory for these two mechanisms, knowing that the construction mechanism must then be timed so as not to update pixels which have not yet been sent to the screen. Two or more line memories can also be used. In this case, some so-called “off screen” used to build the following lines, while a so-called “on screen” is sent to the screen to fill the current line.
  • retrieving the useful segment requires, among other things, to determine: the memory address where the first pixel of the object segment is located; - the number of pixels contained in the segment of the object; the law of horizontal and vertical variation between two pixels. The determination of these variables is not enough to recover the useful segment of the object.
  • the following object parameters must also be considered: the width of the object stored in memory (in bytes); the color organization of the pixels; the compression law, if the object is stored in a compressed way.
  • a process is carried out successively allowing for each object: a) to calculate the variables necessary for the recovery of the useful segment; b) retrieve the necessary object parameters; c) to update the variables in the registers in anticipation of the next lines, for example the memory address pointer.
  • We also execute a process allowing access to the memory where the objects are stored, from hardware commands.
  • DMA hardware Direct Memory Access
  • the volatile construction "hardware" mechanism according to the invention can advantageously be implemented in an FPGA which makes it possible to integrate all the modules and processes necessary for implementing the method according to the invention.
  • a hardware accelerator 21 can be architecture on such an FPGA.
  • a memory 20 SDRAM, DDRAM, etc.
  • This memory 20 is a random access memory external to the accelerator 21.
  • An object manager 14 carrying out the activation and characterization of the processing operations specific to the object t (intra-object) as well as management between objects (inter-objects).
  • a register 15 for storing the working parameters and variables for each object.
  • a "DMA hardware” module 12 controlled by the object manager 14 and capable of retrieving the data (for example bitmap images) in the external memory 20.
  • a buffer memory 13 for temporarily storing the raw data from DMA 12, when DMA processes and a decompression / conversion pipeline 16 are not synchronized.
  • the object segment is retrieved by the DMA, it is a question of converting the raw data originating from the DMA into pixels in the output format selected so that it can be stored in the line memory.
  • this requires knowing: the color organization of the pixels; the law of horizontal variation between two pixels; and - the compression law, if the image is stored in a compressed manner.
  • This pipeline also includes means for transforming the pixels. Once the raw data has been converted into pixels, it is possible to apply digital processing, such as for example filters or effects on these pixels.
  • chroma-keying the pixel becomes transparent if its value is equal to a reference value which one calls the value of "chroma-key”
  • - thresholding by luminance the pixel becomes transparent if the value of its luminance level is less than a reference value which is called threshold value
  • color filters modification of the chrominance of the pixel
  • low-pass, high-pass filters influence of neighboring pixels to the current pixel by a suitable pipeline
  • a pixel mixer 18 ("blending") according to the transparency of the pixel considered.
  • Writing pixels to line memory is the last step in the line process of volatile construction. The writing of a pixel in the memory requires knowing: the position of the pixel in the line: coordinate "x" relative to the origin equal to the first pixel of the screen; and - the value of the pixel already present in the line at the same position, in particular when the object is semi-transparent.
  • a multiplexer 17 selects either the pixel from the main video stream (video_in), or the pixel from the stream from the DMA 12. This mechanism requires that the timing of the accelerator be synchronized and locked on the video source.
  • the operating frequency of the pipeline is several times the pixel frequency of the screen, and the multiplexer selects the video pixel at the rate of once per pixel period (at the pixel frequency). The rest of the time, the multiplexer manages the stream from DMA 12. When there is no main video stream, it is replaced by a background color.
  • This architecture example also makes it possible to perform a video merge with the background color in proportion to a level of video transparency (alpha_video_in) without implementing a second merge module.
  • the image construction method according to the invention makes it possible to manage the level of depth between graphic and video objects without limiting the maximum number of layers.
  • This number of layers is not scalable in terms of the hardware resources of the accelerator.
  • This method also makes it possible to manage the transparency between the graphic and video objects as a function of the positioning of the objects on the z axis regardless of the number of graphic layers which is not dimensioned to obtain the overall complex transparency.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Controls And Circuits For Display Device (AREA)
  • Image Generation (AREA)
  • Digital Computer Display Output (AREA)
  • Processing Or Creating Images (AREA)

Abstract

L'invention concerne un procédé pour construire une image à afficher sur un écran (1) à partir d'une pluralité d'objets (2) stockés en mémoire (3). Selon l'invention, pour chaque trame vidéo de l'écran (1), on construit (7) l'image ligne par ligne directement depuis les objets (2) en réalisant les étapes suivantes : pour chaque ligne de l'écran, on construit à -la volée cette ligne en récupérant et en stockant, en temps réel, dans une mémoire ligne (8), tous pixels relatifs aux objets destinés à être affichés sur ladite ligne, et on affiche (9) ces pixels en les envoyant à l'écran selon une suite de pixels à la fréquence pixel, de sorte que l'image n'est formée que sur ledit écran (1).

Description

" Procédé et système de construction volatile d'une image à afficher sur un système d'affichage à partir d'une pluralité d'objets . " La présente invention se rapporte à un procédé pour construire une image à afficher sur un système d'affichage, tel qu'un écran à partir d'une pluralité d'objets. Un objet est un élément graphique qui peut être affiché à l'écran. Il peut être de type vidéo, bitmap ou vectoriel par exemple. Si l'approche "objet" est une notion répandue au niveau applicatif, les mécanismes d'affichage actuels se contentent traditionnellement d'aller chercher l'image déjà construite quelque part en mémoire, dans une zone prédéfinie qui fait généralement la taille d'une trame vidéo, d'où son nom de "mémoire de trame" ou "frame buffer" en langue anglaise. Entre un module applicatif gérant des objets, et un module d'affichage exploitant une mémoire trame, un module de copie d'objets est communément utilisé permettant de récupérer un objet dans une zone quelconque et de venir l'écrire dans la mémoire trame. Les systèmes graphiques et vidéo selon l'art antérieur utilisent des mémoires de trame dans lesquelles les images sont fabriquées à partir de primitives graphiques et vidéo et d'objets copiés dans ces zones. Lorsqu'il existe plusieurs plans mémoire, ceux-ci sont généralement recombinés au moment de l'affichage en utilisant des mécanismes de multiplexage, d'incrustation ("chroma-keying" en langue anglaise) ou de fusion par transparence ("alpha-blending" en langue anglaise) . Cette approche est très gourmande en espace mémoire, surtout pour les systèmes désireux d'offrir une très bonne qualité visuelle, et qui requièrent alors de multiples plans mémoire. Par ailleurs, à chaque fois qu'un objet graphique est remplacé par un autre, supprimé ou déplacé, il y a reconstruction totale de la mémoire trame dans laquelle il se trouve, d'où une perte en fluidité. Pour les systèmes standards, le dynamisme et la qualité visuelle que l'on veut apporter à une Interface Homme-Machine sont complètement dimensionnant pour le cœur processeur du système (matériel et/ou logiciel, "hardware" et/ou "software" en langue anglaise) et pour la quantité de mémoire. Ainsi : plus le processeur sera puissant, plus il pourra réaliser un grand nombre d'opérations lors de la préparation des plans images et gérer des modifications importantes de contenu d'une trame à la suivante, et plus il pourra manipuler un grand nombre de plans mémoire; plus il y a de plans mémoire, plus le nombre de niveaux graphiques est important, ce qui accroît les possibilités en terme de transparence complexe dans l'image finale. La présente invention vise à remédier aux inconvénients précités en proposant un procédé de construction d'image dans lequel la mémoire utile à cette construction et la puissance utile du système sont réduites par rapport aux systèmes de l'art antérieur. On atteint le but précité avec un procédé pour construire une image apte à être affichée sur un système d'affichage à partir d'une pluralité d'objets. Selon l'invention, pour chaque trame vidéo du système d'affichage, on construit l'image ligne par ligne directement depuis les objets en réalisant les étapes suivantes : - pour chaque ligne du système d'affichage, on construit à la volée cette ligne en récupérant et en stockant, en temps réel, dans au moins une mémoire ligne, tous pixels relatifs aux objets destinés à être affichés sur ladite ligne, et on envoie ces pixels au système d'affichage selon une suite de pixels, de sorte que l'image n'est formée que sur ledit système d'affichage; et en ce que le mécanisme de construction de la ligne est synchronisé en ligne et en trame avec le système d' ffichage. Contrairement aux systèmes de l'art antérieur, la présente invention permet d'afficher directement des objets sur un système d'affichage tel qu'un écran. L'objet est au cœur du mécanisme de construction de l'image. On dit que la construction de l'image est volatile puisque son mécanisme n'a pas recours à une mémoire trame et que l'image n'existe nulle par ailleurs que sur le système d'affichage. En d'autres termes, on construit l'image ligne par ligne en temps réel depuis les lieux où sont disséminés les objets jusqu'au système d'affichage. Alors que dans les systèmes de l'art antérieur, on construit d'abord l'image à partir des objets, on stocke cette image dans une mémoire trame, puis on affiche l'image déjà formée. Par système d'affichage, on entend un système comprenant un ou plusieurs écrans synchronisés en ligne et en trame, et pilotés par un contrôleur unique générant des signaux de cadencement des écrans, ce contrôleur étant disposé dans l'accélérateur. Par exemple, du point de vue de l'accélérateur, deux écrans côte à côte peuvent être considérés comme un seul écran de définition double. D'autre part, le système d'affichage peut comprendre une mémoire d'affichage apte à recevoir les pixels formant l'image. L'image est alors formée au sein de cette mémoire d'affichage plutôt que directement sur un écran. Par ailleurs, lorsque les objets graphiques ou vidéo sont stockés en mémoires sous forme compressée, la présente invention présente un avantage certain par rapport aux systèmes standards puisqu'elle nécessite peu de mémoire (absence de mémoire trame), donc un coût de revient inférieur. En outre, puisque l'image est construite directement, 1 ' opération de préparation de la trame dans une mémoire trame est évitée, d'où une diminution de la bande-passante nécessaire au niveau de la mémoire. Ayant moins d'opérations à effectuer pour afficher une image à l'écran, le système tout entier peut être moins puissant, donc moins consommateur d'énergie, moins perturbant, ce qui est primordial pour un système embarqué par exemple. La présente invention permet donc de réaliser des images d'une très grande qualité visuelle à partir de composants faible puissance. Puisque l'image que voit un observateur n'existe que sur l'écran et n'est pas stockée, l'image doit être reconstruite à chaque nouvelle trame vidéo. En conséquence, la réalisation de séquences d'images complexes avec des objets dynamiques ne nécessite aucune puissance supplémentaire par rapport à ce qui est nécessaire pour afficher toujours la même image. En revanche, les systèmes standards sont rarement capables de mettre du dynamisme dans leur Interface Homme-Machine (IHM) ou bien le font au détriment de l'aspect temps réel puisque le nombre important d'opérations nécessaires à la préparation de l'image dans la mémoire trame peut dépasser la durée de la trame vidéo de l'écran. Pour un coprocesseur graphique standard, l'aspect dynamique d'une image (d'une IHM) est dimensionnant . Avec la présente invention, une image dynamique peut être obtenue sans re-dimensionnement puisque le nombre d'opérations à réaliser dans le temps trame sera le même. On entend par image dynamique, une image composée d'objets 2D pouvant évoluer au fil du temps, se déplacer, se transformer, changer d'état, ... Selon une mode de mise en œuvre avantageux de l'invention, on utilise deux mémoires lignes réalisant, de façon décalée, chacune successivement une étape de construction puis une étape d'affichage de telle sorte que lorsqu'une première mémoire ligne affiche des pixels sur la ligne courante, on construit et stocke dans la seconde mémoire ligne des pixels destinés à être affichés sur la ligne suivante. D'une façon générale, au cours de l'étape de construction de l'image, on réalise les étapes suivantes pour chaque ligne du système d'affichage : on identifie indépendamment chaque objet devant être présent sur cette ligne en fonction d'un ensemble de variables propres à chaque objet; on détecte dans chaque objet ainsi identifié, une zone utile correspondant à la ligne considérée; et on convertit les données brutes issues de ladite zone utile en pixels compatibles avec le format d'affichage. De préférence, au cours de l'étape de détection on accède à la mémoire où sont stockés les objets à partir de mécanismes électroniques et on stocke temporairement les données brutes issues des zones utiles dans des moyens de stockage. Avantageusement, une fois les données brutes converties en pixels, on peut appliquer des transformations et des effets à ces pixels. Ces transformations et effets, qui sont en fait des traitements numériques, peuvent par exemple être un affichage partiel ou "clipping" en langue anglaise, re-dimensionnement ou "resizing" en langue anglaise, transparence, seuillage, anamorphisme, filtres,... L'objet étant au cœur du mécanisme, chaque objet est donc indépendamment paramétrable et on peut changer les paramètres d'un objet sans affecter les autres objets. La réalisation d'une IHM est donc extrêmement simplifiée. Selon l'invention, pour écrire un pixel dans une mémoire ligne, on peut d'abord déterminer la position de ce pixel dans la ligne considérée, puis déterminer en outre la valeur du pixel déjà présent dans cette ligne à la même position. Par ailleurs, lors de l'écriture d'un pixel dans une mémoire ligne, ce pixel étant destiné à s'afficher sur une position donnée sur une ligne du système d'affichage, on peut appliquer un mélangeur entre ce premier pixel et un second pixel actuellement stocké dans la mémoire ligne à ladite même position donnée, le mélangeur étant appliqué de manière proportionnelle au niveau de transparence dudit premier pixel. Selon un mode de mise en œuvre avantageux de l'invention, la trame vidéo comprenant deux zones temporelles distinctes que sont une zone morte verticale, dite "verticale blanking intervalle VBI" en langue anglaise et une zone active verticale, dite "verticale active intervalle VAI" en langue anglaise, correspondant respectivement à l'intervalle entre les deux trames actives et à la durée d'affichage d'une trame active, on réalise les étapes de construction et d'affichage à la volée au cours de chaque zone active verticale, et on réalise, au cours de la zone morte verticale, toute préparation nécessaire au déroulement de la construction. Ladite "préparation nécessaire" peut être toute action de préparation de la trame à venir. Alternativement, on peut réaliser au cours de chaque zone active verticale, toute préparation nécessaire au déroulement de la construction, les étapes de construction et d'affichage à la volée. Dans ce cas, ladite "préparation nécessaire" est de préférence toute action de préparation ou d'anticipation de construction de la ligne à venir. Cette préparation peut comprendre la détermination ou la mise à jour (lorsque les variables sont déjà déterminées) d'un ensemble de variables propres à chaque objet. Ces variables peuvent être extraites de chaque descripteur matériel associé à chaque objet, puis stockées au sein de l'accélérateur. Un descripteur matériel est l'ensemble des paramètres graphiques et d'affichage définissant l'objet correspondant. Les objets peuvent être de natures différentes. On peut avoir des objets vidéo, vectoriels, bitmap, ou autre. Grâce au descripteur, on peut gérer de la même manière des objets hétérogènes. Ladite préparation peut également comprendre un tri des objets par ordre de profondeur par exemple décroissante ou croissante de façon à hiérarchiser l'ordre avec lequel les objets seront superposés à l'écran. On peut réaliser le tri en balayant une première fois tous les objets pour déterminer l'objet le plus enfoui, puis en recommençant le balayage des objets sans tenir compte des objets déjà triés, jusqu'à ce que tous les objets soient triés. Toutefois, le tri peut être fait pendant la construction. Le mécanisme de construction volatile selon l'invention permet de prendre en compte pour chaque objet un niveau de profondeur pour l'affichage final, permettant de simplifier la gestion des recouvrements d'objets et de fenêtres d'un point de vue applicatif, en déléguant au "hardware" ce travail complexe et fastidieux d'un point de vue logiciel. L'invention n'impose pas d'un point de vue théorique un nombre maximal de niveaux gérés. En outre, la présente invention permet de gérer un très grand nombre de couches graphiques sans que ce ne soit ni pénalisant ni dimensionnant, à la fois en terme de ressources "hardware", de puissance CPU, et de quantité de mémoire. On peut donc réaliser aisément des transparences complexes : plusieurs objets transparents les uns au dessus/au dessous des autres. Avantageusement, la construction de l'image est gérée par un accélérateur matériel au moyen de mécanismes électroniques, c'est à dire une gestion matérielle, une gestion électrique par des machines d'états. Cet accélérateur matériel est apte à générer la trame vidéo du système d'affichage. Mais, il peut aussi se synchroniser et se verrouiller sur cette trame vidéo du système d'affichage à partir d'une information de synchronisation fournie par le système d'affichage même. Suivant un autre aspect de l'invention, il est proposé un système pour construire une image apte à être affichée sur un système d'affichage à partir d'une pluralité d'objets notamment stockés en mémoire vive. Selon l'invention, le système comprend une unité de traitement tel qu'un microprocesseur associé à un accélérateur matériel : pour construire l'image, ligne par ligne, directement depuis les objets, en récupérant et en stockant, en temps réel, dans une mémoire ligne, tous les pixels relatifs aux objets destinés à être affichés sur chaque ligne active de chaque trame vidéo du système d'affichage, pour afficher ces pixels en les envoyant au système d'affichage selon une suite de pixels à la fréquence pixel, de sorte que l'image n'est formée que sur ledit système d'affichage, et pour synchroniser le mécanisme de construction de la ligne, en ligne et en trame, avec le système d'affichage. Avantageusement, l'accélérateur matériel comprend les éléments suivants : un gestionnaire d'objets pour activer et caractériser des traitements liés aux objets, une mémoire de stockage des paramètres et variables de chaque objet, - un module matériel de type DMA ("Direct Memory Access" en langue anglaise) contrôlé par l'accélérateur (et non par l'unité de traitement) apte à récupérer des données des objets depuis une mémoire, une mémoire tampon pour stocker temporairement les données provenant du module matériel DMA, un module de décompression et de conversion de données brutes provenant de la mémoire tampon en pixels, un multiplexeur pour sélectionner le pixel à afficher entre celui provenant du module de décompression et de conversion et celui provenant d'une source externe, à la condition que la source externe, l'accélérateur et l'écran soient synchronisés, un mélangeur pour mélanger le pixel provenant du multiplexeur et un pixel actuellement affiché en fonction de la transparence du pixel provenant du multiplexeur, et deux mémoires ligne assurant successivement à tour de rôle l'affichage sur la ligne courante du système d'affichage de pixels préalablement stockés, et le stockage de pixels provenant du mélangeur et qui sera affiché à la ligne suivante. A la façon d'un OSD (On Screen Display) , le présent système comprend des moyens pour insérer/incruster des informations graphiques dans un flux vidéo principal. A la différence de celui-ci, les informations insérées sont des objets hétérogènes et paramétriques. D'autres avantages et caractéristiques de l'invention apparaîtront à l'examen de la description détaillée d'un mode de mise en œuvre nullement limitatif, et des dessins annexés, sur lesquels : La figure 1 est une vue schématique simplifiée d'un processus de construction et d'affichage d'une image selon l'art antérieur; - La figure 2 est une vue schématique simplifiée d'un processus de construction et d'affichage d'une image ligne par ligne en temps réel selon la présente invention; La figure 3 est un schéma illustrant deux zones temporelles d'une trame vidéo selon l'invention; - La figure 4 est un schéma illustrant la façon dont deux mémoires ligne sont utilisées pour la construction et l'affichage d'image ligne par ligne selon l'invention; et La figure 5 est une vue schématique simplifiée d'un accélérateur matériel mettant en œuvre le procédé selon la présente invention. Sur la figure 1, on désire réaliser et afficher sur un écran
1 une image à partir d'une pluralité d'objets 2 contenus dans une mémoire vive 3. Pour ce faire, selon l'art antérieur, un module 4 de copie d'objets construit ladite image qui est ensuite stockée dans une mémoire trame 5. Cette dernière fait généralement la taille d'une trame vidéo. Un module d'affichage 6 se contente alors d'aller chercher l'image déjà construite dans la mémoire trame 5 et de l'afficher sur l'écran 1 pendant la durée d'une trame vidéo. La présente invention met en œuvre un procédé complètement différent. Sur la figure 2, on désire également afficher une image sur l'écran 1 à partir d'une pluralité d'objets 2 stockés en mémoire vive 3. Pour ce faire, on utilise un processeur matériel ou "hardware" en langue anglaise, autrement appelé accélérateur matériel graphique, pour construire à la volée et en temps réel ladite image à partir des objets 2. Cet accélérateur, notamment représenté sur la figure 5, réalise différentes opérations au cours de la trame vidéo et les répète à chaque nouvelle trame. Ainsi, durant une trame, pour chaque ligne active de la trame, le système selon l'invention construit en temps réel les pixels devant s'afficher sur cette ligne à partir des objets
2. En d'autres termes, l'accélérateur matériel comprend un module
7 pour construire les pixels d'une ligne courante de l'image à afficher, au moins une mémoire ligne 8 pour stocker temporairement les pixels ainsi construits, et un module d'affichage ligne 9 sur l'écran 1. D'une façon générale, dans la trame vidéo qu'il génère ou sur laquelle il se synchronise et se verrouille, l'accélérateur matériel identifie alors, conformément à la figure 3, deux zones temporelles distinctes qui sont : la zone morte verticale (dite "vertical blanking intervalle", VBI) la zone active verticale (dite "vertical active intervalle", VAI ) Le mécanisme de construction volatile selon l'invention s'appuie sur ces intervalles de temps pour réaliser l'affichage d'une image composée d'objets à l'écran et stables le temps d'une trame. Macroscopiquement, on distingue le VBI et le VAI. On profite du VBI de la période trame pour réaliser toute la préparation nécessaire au bon déroulement de la construction volatile qui se déroulera dans le VAI par un processus ligne.
Pour chaque ligne active de l'écran, la construction volatile consiste à remplir une mémoire de ligne avec les segments de ligne des objets qui sont actifs dans la ligne considérée. Le contenu de la mémoire de ligne est ensuite envoyé à l'écran au rythme de la fréquence pixel. Comme on le verra ci-dessous avec la figure 4, la présente invention permet à ce que lorsqu'on affiche une ligne (L-l) , pendant ce temps là, la ligne suivante (L) est en cours de construction. Sur la figure 3, la synchro H correspond à la synchronisation ligne (Horizontale) , et la synchro V correspond à la synchronisation trame (Verticale) . On va maintenant décrire le processus réalisé dans la zone morte verticale VBI pour préparer la construction volatile de la zone active verticale VAI. La première étape peut consister à décoder un descripteur matériel afin d'élaborer des variables qui seront utilisées lors de la construction des lignes pendant la zone VAI . Un descripteur matériel est associé à chaque objet. On entend par "descripteur matériel" un ensemble cohérent de données, créé et initialisé généralement par un processus applicatif. Ce descripteur contient toutes les informations pour que l'accélérateur matériel puisse afficher l'objet qui lui est associé. Ces informations, notamment stockées dans des registres ou mémoires, comportent des paramètres graphiques décrivant la nature de l'objet et des paramètres d'affichage. Ces derniers peuvent être dissociés en paramètres indispensables (position, attributs d'affichage tel que niveau de transparence,...) et paramètres de transformations (affichage partiel ou "clipping", re-dimensionnement ou "resizing", rotation, anamorphisme, filtres,...). Chaque objet peut être de nature différente en ce qu'il appartient à une classe donnée (vectoriel, vidéo, bitmap, ...) ou comporte une organisation de couleur donnée (mode palette, noir et blanc, couleurs en 16, 24, 32 bits, avec transparence ou non, ...) . Le descripteur peut être local à l'accélérateur matériel ou dans une mémoire externe. Dans ce dernier cas, il convient d'abord de récupérer le descripteur avant d'entamer le décodage. Le décodage du descripteur consiste à en extraire toutes les variables qui vont servir lors de la construction volatile. Le décodage du descripteur sera plus ou moins long, plus ou moins complexe, en fonction des capacités de l'accélérateur matériel à réaliser des fonctions évoluées et complexes (filtres, "resizing", anamorphisme, "clipping", déplacements,...). Le décodage de certaines informations du descripteur peut même être inutile si les paramètres fournis correspondent déjà aux variables utiles à la construction volatile. Néanmoins, l'idée consiste à déléguer au niveau du matériel, "hardware", le prétraitement des données brutes pour qu'il puisse garantir le temps réel et être synchronisé dans la trame avec la construction volatile. Cela permet aussi de stocker dans le descripteur des paramètres évolués qui seront directement (ou presque) transmis par une application dite API ("Application Program Interface" en langue anglaise) orientée objet. En effet, l'accélérateur matériel est associé à un microprocesseur qui est programmé de manière à offrir un ensemble de fonctions prédéfinies accessibles par l'intermédiaire de cette API. Pour illustrer le rôle du décodage, pour un objet composé par exemple d'une image bitmap stockée quelque part en mémoire. Son descripteur contient alors : l'adresse où commence la donnée image en mémoire; la taille de l'image; la position de l'objet à l'écran; l'organisation de couleur de l'image bitmap telle qu'elle est stockée en mémoire; le niveau de transparence global de l'objet; ... Imaginons que les coordonnées de l'objet soient légèrement négatives par rapport à l'origine de l'écran. Seule la partie visible de l'objet devra être traitée pour être affichée, le reste étant rogné ("clipping") . Cela signifie que la position réelle de l'objet devra être déterminée, que l'adresse de l'objet en mémoire devra être mise à jour pour pointer directement sur le premier pixel visible. La taille du segment de ligne utile à la construction volatile d'une ligne doit aussi être déterminée en fonction du "clipping", mais aussi en fonction de l'organisation de couleur des pixels en mémoire. Ainsi, pour chaque objet, le décodage du descripteur aboutit à une série de variables de travail qui sera exploitée par l'accélérateur matériel lors de la construction volatile. Si les descripteurs peuvent être stockés dans une mémoire externe, les variables utiles seront avantageusement stockées localement à l'accélérateur hardware pour des raisons d'accessibilité. Certaines de ces variables subiront des modifications au fur et à mesure des processus ligne. Par exemple, à la fin du décodage de descripteur, le pointeur d'adresse pointe sur le premier segment de ligne actif de l'objet stocké en mémoire. Mais le pointeur d'adresse devra pointer au fur et à mesure des processus ligne sur les nouveaux segments de ligne actifs. Une seconde étape peut être le tri des objets par ordre de profondeur décroissante. Ce processus permet de hiérarchiser l'ordre avec lequel les objets seront superposés à l'écran. Il prend tout son intérêt lorsque la transparence globale des objets est gérée par l'accélérateur matériel puisqu'il permet alors de restituer fidèlement la transparence complexe entre les objets. Cela signifie qu'un objet A placé derrière un objet B sera vu proportionnellement à la transparence de l'objet B qui se trouve devant lui. Le tri pourra se faire, par exemple, en balayant une première fois tous les objets pour déterminer l'objet le plus enfoui, puis en recommençant le balayage des objets sans tenir compte des objets déjà triés, jusqu'à ce que tous les objets soient triés. A l'issue de ce balayage, chaque objet pourra par exemple contenir dans un de ses registres, l'index de l'objet suivant dans un ordre de profondeur décroissante, afin que le processus ligne de construction de l'image puisse passer simplement d'un objet à un autre, et dans l'ordre exigé par la transparence complexe. La transparence complexe n'est obtenue que par le principe inventif de construction volatile selon l'invention et décrit ci- dessous
On va maintenant décrire le processus réalisé dans la zone active verticale VAI. Le mécanisme de construction volatile d'image est un processus ligne, ce qui veut dire qu'il s'exécute de nouveau pour chaque ligne active de l'écran, c'est-à-dire pour chaque ligne de la VAI (voir figure 3) . Processus ligne : Le mécanisme de construction d'une ligne est synchronisé avec le mécanisme d'affichage qui consiste simplement à envoyer à l'écran une suite de pixels à la fréquence pixel. Pour ce faire, on peut très bien n'utiliser qu'une seule mémoire de ligne pour ces deux mécanismes, sachant que le mécanisme de construction doit alors être temporisé pour ne pas mettre à jour des pixels qui n'ont pas encore été envoyés à l'écran. On peut également utiliser deux ou plusieurs mémoires de ligne. Dans ce cas, certaines dites "off screen" servant à construire les lignes suivantes, pendant que une dite "on screen" est envoyée à l'écran pour remplir la ligne courante. A la fréquence ligne, par exemple au moment du top de synchro ligne, les processus sont inversés. La mémoire "off screen" devient la mémoire "on screen" et vice et versa. La figure 4 illustre ce mécanisme sur deux lignes successives Ligne n et Ligne n+1 où l'on remarque l'inversion des rôles entre les deux mémoires 10 et 11. Construction de la ligne : Pour une ligne de l'écran donnée, il s'agit de récupérer tous les segments des objets qui doivent se trouver dans cette ligne. Pour savoir si un objet se trouve dans la ligne, on exécute un processus permettant successivement pour chaque objet d'identifier si oui ou non l'objet est présent dans la ligne d'écran considéré. Le fait qu'un objet soit présent ou non dans une ligne de l'écran dépend de plusieurs paramètres qui sont propres à chaque objet. Dans le cas d'un objet bitmap rectangulaire stocké comme tel et affiché comme tel, on peut citer : la hauteur de l'objet (en nombre de pixels); la coordonnée "y" de l'objet (en nombre de pixels par rapport à une origine conventionnelle) . Si l ' obj et est affecté d' une zone de "clipping" , on tiendra compte également des paramètres de cette zone. Si l'objet doit subir un "resizing" vertical, on tiendra compte de la taille finale de l'objet, c'est-à-dire à l'écran, pour déterminer si un morceau de cet objet se trouve dans la ligne d'écran considérée. Lorsque l'on sait qu'un objet est présent dans la ligne active, il faut encore déterminer quelle est la zone utile de cet objet dans la ligne considérée, savoir où et comment récupérer cette zone, et savoir à quel endroit la placer dans la mémoire de ligne. Par exemple, dans le cas d'un objet bitmap rectangulaire stocké en mémoire et affiché anamorphose à l'écran, la récupération du segment utile oblige entre autre à déterminer : l'adresse mémoire où se trouve le premier pixel du segment d'objet; - le nombre de pixels contenu dans le segment de l'objet; la loi de variation horizontale et verticale entre deux pixels . La détermination de ces variables ne suffit pas à récupérer le segment utile de l'objet. Il faut également considérer les paramètres objet suivants : la largeur de l'objet stocké en mémoire (en octets); l'organisation de couleur des pixels; la loi de compression, si l'objet est stocké de façon compressée. Du point de vue des actions à effectuer : on exécute un processus permettant successivement pour chaque objet : a) de calculer les variables nécessaires à la récupération du segment utile; b) de récupérer les paramètres objet nécessaires; c) de mettre à jour les variables dans les registres en anticipation des prochaines lignes, par exemple le pointeur d'adresse mémoire. On exécute également un processus permettant d'accéder à la mémoire où sont stockés les objets, à partir de commandes matérielles. On peut par exemple parler de "DMA hardware", pour "Direct Memory Access" en langue anglaise, géré par l'accélérateur matériel, par comparaison avec un DMA traditionnellement géré par un microprocesseur. On exécute aussi un processus permettant de commander et de surveiller le DMA. Le mécanisme "hardware" de construction volatile selon l'invention peut avantageusement être implémenté dans un FPGA qui permet d'intégrer la totalité des modules et processus nécessaires à la mise en œuvre du procédé selon l'invention. Sur la figure 5, on voit la manière dont un accélérateur matériel 21 peut être architecture sur un tel FPGA. Pour le stockage des objets graphiques, on utilise avantageusement une mémoire 20 (SDRAM, DDRAM...) dont la bande- passante est suffisamment importante pour permettre au mécanisme de construction volatile de récupérer suffisamment d'informations (données utiles des objets actifs) lors du processus ligne. Cette mémoire 20 est une mémoire vive externe à l'accélérateur 21. Sur la figure 5, on distingue : a) Un gestionnaire d'objet 14 réalisant l'activation et la caractérisation des traitements propres à l'objet t (intra-objet) ainsi que la gestion entre les objets (inter-objets) . b) Un registre 15 de stockage des paramètres et variables de travail pour chaque objet. c) Un module "DMA hardware" 12 contrôlé par le gestionnaire d'objet 14 et capable d'aller rechercher les données (par exemple des images bitmap) dans la mémoire externe 20. d) Une mémoire tampon 13 pour stocker temporairement les données brutes en provenance du DMA 12, lorsque les processus DMA et un pipeline 16 de décompression/conversion ne sont pas synchronisés . e) Deux mémoires de ligne 19 ou "line buffers" en langue anglaise, (l'une "off screen" et l'autre "on screen" conformément à la figure 4. f) Le pipeline 16 de décompression/conversion des données brutes en pixels. Plus précisément, Une fois que le segment d'objet est récupéré par le DMA, il s'agit de convertir les données brutes issues du DMA en pixels dans le format de sortie retenu pour pouvoir être stockés dans la mémoire de ligne. Dans le cas d'un objet de type image bitmap, cela nécessite de connaître : l'organisation de couleur des pixels; la loi de variation horizontale entre deux pixels; et - la loi de compression, si l'image est stockée de façon compressée. Ce pipeline comprend également des moyens pour transformer les pixels. Une fois les données brutes converties en pixels, il est possible d'appliquer des traitements numériques, tels que par exemple des filtres ou des effets sur ces pixels. On peut par exemple citer : "chroma-keying" : le pixel devient transparent si sa valeur est égale à une valeur de référence qu'on appelle la valeur de "chroma-key"; - seuillage par luminance : le pixel devient transparent si la valeur de son niveau de luminance est inférieure à une valeur de référence qu'on appelle valeur de seuil; seuillage par chrominance; niveau de transparence : on modifie le niveau de transparence du pixel dit "alpha" en appliquant la formule alpha_pixel = alpha_global_objet x alpha_pixel_source; filtres de couleur : modification de la chrominance du pixel; filtres passe-bas, passe-haut : influence des pixels voisins au pixel courant par un pipeline adapté; - Etc. g) Un mélangeur de pixel 18 ("blending") suivant la transparence du pixel considéré. L'écriture des pixels en mémoire ligne représente la dernière étape dans le processus ligne de la construction volatile. L'écriture d'un pixel dans la mémoire nécessite de connaître : la position du pixel dans la ligne : coordonnée "x" par rapport à l'origine égale au premier pixel de l'écran; et - la valeur du pixel déjà présent dans la ligne à la même position, en particulier lorsque l'objet est semi-transparent. h) Un multiplexeur 17 sélectionne soit le pixel issu du flux vidéo principal (vidéo_in) , soit le pixel issu du flux provenant du DMA 12. Ce mécanisme impose que le cadencement de l'accélérateur soit synchronisé et verrouillé sur la source vidéo. La fréquence de fonctionnement du pipeline est égale à plusieurs fois la fréquence pixel de l'écran, et le multiplexeur sélectionne le pixel vidéo à la cadence d'une fois par période pixel (à la fréquence pixel) . Le reste du temps, le multiplexeur gère le flux issu du DMA 12. Lorsqu'il n'y a pas de flux vidéo principal, celui-ci est remplacé par une couleur de fond ("background") . Cet exemple d'architecture permet aussi de réaliser une fusion de la vidéo avec la couleur de fond proportionnellement à un niveau de transparence vidéo ( alpha_vidéo_in) sans implémenter un deuxième module de fusion.
Ainsi, le procédé de construction d'image selon l'invention rend possible la gestion de niveau de profondeur entre objets graphiques et vidéo sans limite du nombre maximal de couches. Ce nombre de couches n'est pas dimensionnant au niveau des ressources matérielles de l'accélérateur. Ce procédé rend également possible une gestion de la transparence entre les objets graphiques et vidéo en fonction du positionnement des objets sur l'axe des z quel que soit le nombre de couches graphiques qui n'est pas dimensionnant pour obtenir la transparence complexe globale.
Bien sûr, l'invention n'est pas limitée aux exemples qui viennent d'être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l'invention.

Claims

REVENDICATIONS
1. Procédé pour construire une image apte à être affichée sur un système d'affichage à partir d'une pluralité d'objets, pour chaque trame vidéo du système d'affichage, on construit l'image ligne par ligne directement depuis les objets en réalisant les étapes suivantes : pour chaque ligne du système d'affichage, on construit à la volée cette ligne en récupérant et en stockant, en temps réel, dans au moins une mémoire ligne, tous pixels relatifs aux objets destinés à être affichés sur ladite ligne, on envoie ces pixels au système d'affichage selon une suite de pixels, de sorte que l'image n'est formée que sur ledit système d'affichage ; le mécanisme de construction de la ligne étant synchronisé en ligne et en trame avec le système d'affichage ; caractérisé en ce que lors de l'écriture d'un pixel dans' une mémoire ligne, ce pixel étant destiné à s'afficher sur une position donnée sur une ligne du système d'affichage, on détermine d'abord la position de ce pixel dans la ligne considérée, et on applique un mélangeur entre ce premier pixel et un second pixel actuellement stocké dans la mémoire ligne à ladite même position donnée, le mélangeur étant appliqué de manière proportionnelle au niveau de transparence dudit premier pixel de façon à réaliser de la transparence complexe.
2. Procédé selon la revendication 1, caractérisé en ce qu'on utilise deux mémoires lignes réalisant, de façon décalée, chacune successivement une étape de construction puis une étape d'affichage de telle sorte que lorsqu'une première mémoire ligne affiche des pixels sur la ligne courante, on construit et stocke dans la seconde mémoire ligne des pixels destinés à être affichés sur la ligne suivante.
3. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'au cours de l'étape de construction de l'image, on réalise les étapes suivantes pour chaque ligne du système d'affichage : on identifie indépendamment chaque objet devant être présent sur cette ligne en fonction d'un ensemble de variables propres à chaque objet ; on détecte dans chaque objet ainsi identifié, une zone utile correspondant à la ligne considérée ; et on convertit les données brutes issues de ladite zone utile en pixels compatibles avec le format d'affichage.
4. Procédé selon la revendication 3, caractérisé en ce qu'au cours de l'étape de détection on accède à la mémoire où sont stockés les objets à partir de mécanismes électroniques et on stocke temporairement les données brutes issues des zones utiles dans des moyens de stockage.
5. Procédé selon la revendication 3 ou 4, caractérisé en ce qu'une fois les données brutes converties en pixels, on applique des transformations et des effets à ces pixels.
6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que lors de l'écriture d'un pixel dans une mémoire ligne, on détermine en outre la valeur du pixel déjà présent dans cette ligne à la même position.
7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la trame vidéo comprenant deux zones temporelles distinctes que sont une zone morte verticale, dite "verticale blanking intervalle VBI" en langue anglaise et une zone active verticale, dite "verticale active intervalle VAI" en langue anglaise, correspondant respectivement à l'intervalle entre les deux trames actives et à la durée d'affichage d'une trame active; on réalise les étapes de construction et d'affichage à la volée au cours de chaque zone active verticale, et on réalise, au cours de la zone morte verticale, toute préparation nécessaire au déroulement de la construction.
8. Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que la trame vidéo comprenant deux zones temporelles distinctes que sont une zone morte verticale, dite "verticale blanking intervalle VBI" en langue anglaise et une zone active verticale, dite "verticale active intervalle VAI" en langue anglaise, correspondant respectivement à l'intervalle entre les deux trames actives et à la durée d'affichage d'une trame active ; on réalise au cours de chaque zone active verticale, toute préparation nécessaire au déroulement de la construction, les étapes de construction et d'affichage à la volée.
9. Procédé selon la revendication 7 ou 8, caractérisé en ce que ladite préparation comprend la détermination d'un ensemble de variables propres à chaque objet.
10. Procédé selon la revendication 9, caractérisé en ce que les variables sont extraites de chaque descripteur matériel associé à chaque objet, puis stockées au sein de l'accélérateur ; un descripteur matériel étant l'ensemble des paramètres graphiques et d'affichage définissant l'objet correspondant.
11. Procédé selon l'une quelconque des revendications 8 à 10, caractérisé en ce que ladite préparation comprend en outre un tri des objets par ordre de profondeur de façon à hiérarchiser l'ordre avec lequel lesdits objets seront superposés sur le système d'affichage.
12. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la construction de l'image est gérée par un accélérateur matériel au moyen de mécanismes électroniques .
13. Procédé selon la revendication 12, caractérisé en ce que l'accélérateur matériel est apte à générer la trame vidéo du système d'affichage.
14. Procédé selon la revendication 12, caractérisé en ce que l'accélérateur matériel est apte à se synchroniser et se verrouiller sur la trame vidéo du système d'affichage à partir d'une information de synchronisation.
15. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le système d'affichage comprend plusieurs écrans synchronisés.
16. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le système d'affichage comprend une mémoire d'affichage apte à recevoir les pixels formant 1 ' image .
17. Système pour construire une image apte à être affichée sur un système d'affichage à partir d'une pluralité d'objets, ce système comprenant une unité de traitement associé à un accélérateur matériel : pour construire l'image, ligne par ligne, directement depuis les objets, en récupérant et en stockant, en temps réel, dans une mémoire ligne, tous pixels relatifs aux objets destinés à être affichés sur chaque ligne active de chaque trame vidéo du système d'affichage, pour afficher ces pixels en les envoyant au système d'affichage selon une suite de pixels, de sorte que l'image n'est formée que sur ledit système d'affichage ; et pour synchroniser le mécanisme de construction de la ligne, en ligne et en trame, avec le système d'affichage; caractérisé en ce que, lors de l'écriture d'un pixel dans une mémoire ligne, ce pixel étant destiné à s'afficher sur une position donnée sur une ligne du système d'affichage, ledit système pour construire une image comprend des moyens pour d'abord déterminer la position de ce pixel dans la ligne considérée, et pour appliquer un mélangeur entre ce premier pixel et un second pixel actuellement stocké dans la mémoire ligne à ladite même position donnée, le mélangeur étant appliqué de manière proportionnelle au niveau de transparence dudit premier pixel de façon à réaliser de la transparence complexe.
18. Système selon la revendication 17, caractérisé en ce que l'accélérateur matériel comprend les éléments suivants : un gestionnaire d'objets pour activer et caractériser des traitements liés aux objets, une mémoire de stockage des paramètres et variables de chaque objet, - un module matériel de type DMA ("Direct Memory Access" en langue anglaise) contrôlé par l'accélérateur et apte à récupérer des données des objets depuis une mémoire, une mémoire tampon pour stocker temporairement les données provenant du module matériel DMA, un module de décompression et de transformation de données brutes provenant de la mémoire tampon en pixels, un multiplexeur pour sélectionner le pixel à afficher entre celui provenant du module de décompression et de transformation et celui provenant d'une source externe, un mélangeur pour mélanger le pixel provenant du multiplexeur et un pixel actuellement affiché en fonction de la transparence du pixel provenant du multiplexeur, et deux mémoires ligne assurant successivement à tour de rôle l'affichage sur la ligne courante du système d'affichage de pixels préalablement stockés, et le stockage de pixels provenant du mélangeur et qui seront affichés à la ligne suivante.
19. Système selon la revendication 17 ou 18, caractérisé en ce qu'il comprend des moyens pour se synchroniser sur une source vidéo et insérer des informations graphiques dans un flux vidéo de ladite source vidéo, non stocké en mémoire.
PCT/FR2005/000857 2004-04-08 2005-04-08 Procede et systeme de construction volatile d’une image a afficher sur un systeme d’affichage a partir d’une pluralite d’objets WO2005104086A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP05753728.4A EP1738349B1 (fr) 2004-04-08 2005-04-08 Procede et systeme de construction volatile d'une image a afficher sur un systeme d'affichage a partir d'une pluralite d'objets
US11/547,812 US20070211082A1 (en) 2004-04-08 2005-04-08 Method and System for Volatile Construction of an Image to be Displayed on a Display System from a Plurality of Objects

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0403721 2004-04-08
FR0403721A FR2868865B1 (fr) 2004-04-08 2004-04-08 Procede et systeme de construction volatile d'une image a afficher sur un systeme d'affichage a partir d'une pluralite d'objets

Publications (1)

Publication Number Publication Date
WO2005104086A1 true WO2005104086A1 (fr) 2005-11-03

Family

ID=34944750

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2005/000857 WO2005104086A1 (fr) 2004-04-08 2005-04-08 Procede et systeme de construction volatile d’une image a afficher sur un systeme d’affichage a partir d’une pluralite d’objets

Country Status (4)

Country Link
US (1) US20070211082A1 (fr)
EP (1) EP1738349B1 (fr)
FR (1) FR2868865B1 (fr)
WO (1) WO2005104086A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111568648B (zh) * 2020-05-25 2022-05-17 常利军 一种混合电气动悬浮担架

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB1503362A (en) * 1974-06-11 1978-03-08 Ibm Digital raster display system
US5699076A (en) * 1993-10-25 1997-12-16 Kabushiki Kaisha Toshiba Display control method and apparatus for performing high-quality display free from noise lines
EP0955625A1 (fr) * 1997-01-23 1999-11-10 Sharp Kabushiki Kaisha Unite d'affichage programmable

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4398189A (en) * 1981-08-20 1983-08-09 Bally Manufacturing Corporation Line buffer system for displaying multiple images in a video game
US4679038A (en) * 1983-07-18 1987-07-07 International Business Machines Corporation Band buffer display system
US5706478A (en) * 1994-05-23 1998-01-06 Cirrus Logic, Inc. Display list processor for operating in processor and coprocessor modes
US5745095A (en) * 1995-12-13 1998-04-28 Microsoft Corporation Compositing digital information on a display screen based on screen descriptor
JP3227086B2 (ja) * 1996-02-01 2001-11-12 基弘 栗須 テレビオンスクリーン表示装置
JP3169848B2 (ja) * 1997-02-12 2001-05-28 日本電気アイシーマイコンシステム株式会社 図形表示装置および図形表示方法
US6181300B1 (en) * 1998-09-09 2001-01-30 Ati Technologies Display format conversion circuit with resynchronization of multiple display screens
US6608630B1 (en) * 1998-11-09 2003-08-19 Broadcom Corporation Graphics display system with line buffer control scheme
US6943783B1 (en) * 2001-12-05 2005-09-13 Etron Technology Inc. LCD controller which supports a no-scaling image without a frame buffer

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB1503362A (en) * 1974-06-11 1978-03-08 Ibm Digital raster display system
US5699076A (en) * 1993-10-25 1997-12-16 Kabushiki Kaisha Toshiba Display control method and apparatus for performing high-quality display free from noise lines
EP0955625A1 (fr) * 1997-01-23 1999-11-10 Sharp Kabushiki Kaisha Unite d'affichage programmable

Also Published As

Publication number Publication date
US20070211082A1 (en) 2007-09-13
FR2868865B1 (fr) 2007-01-19
FR2868865A1 (fr) 2005-10-14
EP1738349B1 (fr) 2016-06-29
EP1738349A1 (fr) 2007-01-03

Similar Documents

Publication Publication Date Title
EP1292921B1 (fr) Raffinement d'un maillage triangulaire en trois dimensions
FR2750231A1 (fr) Appareil et procede pour rechercher et retrouver une information d'image mobile
FR2599873A1 (fr) Systeme d'affichage video
FR2594241A1 (fr) Processeur d'affichage de donnees sur un ecran d'affichage et procede d'affichage de donnees mettant en oeuvre ce dispositif
FR2554256A1 (fr) Appareil et procede de regeneration d'un tampon de trames fonctionnant a grande vitesse
FR2964236A1 (fr) Dispositif et procede de generation d'images multifenetres a priorite variable
EP1738349B1 (fr) Procede et systeme de construction volatile d'une image a afficher sur un systeme d'affichage a partir d'une pluralite d'objets
CN104918044B (zh) 图像处理方法及装置
JP2007102462A (ja) 画像合成方法、システム、端末、および画像合成プログラム
EP2297705A1 (fr) Procede de composition temps reel d'une video
EP2022009A2 (fr) Procede de codage et systeme d'affichage sur un ecran d'une maquette numerique d'un objet sous forme d'une image de synthese
WO2020012139A2 (fr) Procede de visualisation d'elements graphiques issus d'un flux video composite encode
EP1515566B1 (fr) Dispositif et procédé de traitement de données vidéo et graphiques
EP2987319A1 (fr) Procede de generation d'un flux video de sortie a partir d'un flux video large champ
EP3239826A1 (fr) Procede de copie d'ecran
WO2021214395A1 (fr) Procédés et dispositifs de codage et de décodage d'une séquence vidéo multi-vues
FR2971611A1 (fr) Procede d'affichage d'une mosaique video personnalisee et recepteur audiovisuel correspondant
EP0973145A1 (fr) Procédé et système d'élaboration d'images numériques résultant d'éléments graphiques auxiliaires incrustés dans des images principales
EP1383336B1 (fr) Procédé de décompression et de restitution d'un flux de données multimédia numériques compressées comprenant une pluralité d'entités encodées. Dispositif, système et signal correspondants
EP1762068B1 (fr) Procede d'edition de pages multimedia aupres d'un terminal,avec pre-memorisation de parametres d'objets intervenant dans les scenes
CN116248912B (zh) 一种对直播流画面实时批注的方法、系统及存储介质
CN112752131B (zh) 弹幕信息的显示方法和装置、存储介质及电子装置
Liu A review for tone-mapping operators on wide dynamic range image
JP2004511863A (ja) 画像の解像度非依存型レンダリングのための手法
EP3792866A1 (fr) Processeur graphique et procédé associé d'affichage d'un ensemble de pixel(s), plateforme et système avionique associés

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 11547812

Country of ref document: US

Ref document number: 2007211082

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Ref document number: DE

WWE Wipo information: entry into national phase

Ref document number: 2005753728

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2005753728

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11547812

Country of ref document: US