Methods and devices for producing and processing representations of multimedia scenes

Abstract

The representation of content, in a scene representation, is enriched with a view to the adaptive use of the latter according to a set of common parameters. A sub-graph of the scene graph, which is susceptible to variable processing, is identified. For this purpose, two new types of scene element can be defined, one of which allows the identification of the sub-graph and the second enables application of the set of common parameters in relation to the sub-graph. An example of the first type is a node of so-called AdaptivityControl type which encompasses the entire sub-graph, a list of the nodes describing the set of common parameters and a group of fields for dynamic updating of the content of this node. An example of the second type is a node of so-called CompressedImageStrategy type which comprises information relating to the object to be coded and the coding parameters.

Claims

1. A process to produce an enriched representation of a multimedia scene, the multimedia scene being rendered by a terminal, the process comprising: a data-processing step to produce a scene graph representing said multimedia scene, a detecting step to detect at least one sub-graph, of said scene graph, that is suitable to undergo a subsequent variable coding process that varies as a function of a configuration of use conditions of the scene graph, wherein the configuration of use conditions of the scene graph comprises a set of use conditions selected from the group consisting of: at least one attribute of the terminal rendering the multimedia scene, at least one property of a transmission channel that transmits said scene graph to the terminal, and at least one parameter of a user profile of a user of the terminal rendering the multimedia scene, the sub-graph being generic to, but independent of, the different possible configurations of use conditions of the scene graph; a step of adding, to said scene graph, identification data of said sub-graph, the identification data being configured to indicate that the sub-graph is configured to subsequently be subjected to adaptation that depends on at least one of the at least one attribute, the at least one property, and the at least one parameter that applies to the scene graph; and a step during which strategy data defining at least one variable coding strategy of the sub-graph identified by the identification data is added to said scene graph, said at least one variable coding strategy representing in a unitary manner a plurality of different possible types of coding which are neither known nor listed during the scene creation and specifying how the type of coding to be used in said subsequent variable coding process is to be varied as a function of at least one of the at least one attribute, the at least one property, and the at least one parameter that applies to the scene graph.

2. The process according to claim 1, wherein the identification data of the sub-graph constitutes a first node of the scene graph, and wherein the step of adding comprises: creating a second node of a type indicating that a child node thereof is configured to subsequently be subjected to adaptation that depends on at least one of the at least one attribute, the at least one property, and the at least one parameter that applies to the scene graph; and adding said created second node to the scene graph as a parent node of the sub-graph detected in the detecting step.

3. The process according to claim 1, wherein said strategy data constitutes a node of the scene graph.

4. The process according to claim 1, further comprising embedding in said scene graph code necessary for executing the variable coding process.

5. A device for producing an enriched representation of a multimedia scene, the multimedia scene being rendered by a terminal, the device comprising: a processor configured to: process data to produce a scene graph representing said multimedia scene, detect at least one sub-graph, of said scene graph, that is suitable to undergo a subsequent variable coding process that varies as a function of a configuration of use conditions of the scene graph, wherein the configuration of use conditions of the scene graph comprises a set of use conditions selected from the group consisting of: at least one attribute of the terminal rendering the multimedia scene, at least one property of a transmission channel that transmits said scene graph to the terminal, and at least one parameter of a user profile of a user of the terminal rendering the multimedia scene, the sub-graph being generic to, but independent of, the different possible configurations of use conditions of the scene graph; add, to said scene graph, identification data of said sub-graph, the identification data being configured to indicate that the sub-graph is configured to subsequently be subjected to adaptation that depends on at least one of the at least one attribute, the at least one property, and the at least one parameter that applies to the scene graph; and add, to said scene graph, strategy data defining at least one variable coding strategy of the sub-graph identified by the identification data, said at least one variable coding strategy representing in a unitary manner a plurality of different possible types of coding which are neither known nor listed during the scene creation and specifying how the type of coding is to be used in said subsequent variable coding process is to be varied as a function of at least one of the at least one attribute, the at least one property, and the at least one parameter that applies to the scene graph.

6. The device according to claim 5, wherein said processor is configured to create a node of a type indicating that a child node thereof is configured to subsequently be subjected to adaptation that depends on at least one of the at least one attribute, the at least one property, and the at least one parameter that applies to the scene graph, and to introduce the created node into said scene graph as a parent node of the sub-graph detected in the detecting step.

7. The device according to claim 5, wherein said processor is configured to introduce, into said scene graph, a node representative of said strategy data defining at least one variable coding strategy.

8. The device according to claim 5, wherein said processor is configured to embed, in said scene graph, code for executing said variable coding process.

9. A method of adapting a representation of a multimedia scene represented by a scene graph to the conditions of use thereof, the method comprising: an extraction step of extracting, from said representation, identification data and strategy data associated with a sub-graph of said scene graph, wherein the identification data indicates that the sub-graph is configured to subsequently be subjected to adaptation that depends on at least one condition of use that applies to the scene graph, said at least one condition of use being selected from the group consisting of: at least one attribute of a terminal rendering the multimedia scene, at least one property of a transmission channel that transmits said scene graph to the terminal, and at least one parameter of a user profile of a user of the terminal rendering the multimedia scene, and the strategy data defines at least one variable coding strategy of the sub-graph identified by the identification data, said at least one variable coding strategy representing in an unitary manner a plurality of different possible types of coding and specifying how the type of coding to be used in said subsequent variable coding process is to be varied as a function of at least one of the at least one attribute, the at least one property, and the at least one parameter that applies to the scene graph; an identification step to identify a sub-graph of said scene graph, from the identification data extracted from said representation, said sub-graph corresponding to at least one scene element destined to undergo a variable coding process that varies as a function of a configuration of use conditions of the scene graph, wherein the configuration of use conditions of the scene graph comprises a set of use conditions selected in the group consisting of: at least one attribute of a terminal rendering the multimedia scene, at least one property of a transmission channel that transmits said scene graph to the terminal, and at least one parameter of a user profile of a user of the terminal rendering the multimedia scene, the sub-graph being generic to, but independent of, the different possible configurations of use conditions of the scene graph; a step for determining a value of at least one of the at least one attribute, the at least one property, and the at least one parameter that applies to the scene graph; and a coding step of said sub-graph by application of at least one coding process taking into account the value of at least one of the at least one attribute, the at least one property, and the at least one parameter, in accordance with said strategy data.

10. The method according to claim 9, further comprising extracting information necessary for executing said coding step from said scene graph.

11. The method according to claim 9, further comprising: reconstituting said multimedia scene from said scene graph.

12. A device to adapt a representation of a multimedia scene represented by a scene graph to conditions of use thereof, the device comprising a processor configured to: extract, from said representation, identification data and strategy data associated with a sub-graph of said scene graph, wherein the identification data indicates that the sub-graph is configured to be subjected, at a time of use of the scene graph, to adaptation that depends on at least one condition of use that applies to the scene graph, said at least one condition of use being selected from the group consisting of: at least one attribute of a terminal rendering the multimedia scene, at least one property of a transmission channel that transmits said scene graph to the terminal, and at least one parameter of a user profile of a user of the terminal rendering the multimedia scene, and the strategy data defines at least one variable coding strategy of the sub-graph identified by the identification data, said at least one variable coding strategy representing in an unitary manner a plurality of different possible types of coding and specifying how the type of coding to be used in said subsequent variable coding process is to be varied as a function of at least one of the at least one attribute, the at least one property, and the at least one parameter that applies to the scene graph; identify said sub-graph of said scene graph, from the identification data extracted from said representation, said sub-graph corresponding to at least one scene element destined to undergo a variable coding process that varies as a function of a configuration of use conditions of the scene graph, wherein the configuration of use conditions of the scene graph comprises a set of use conditions selected in the group consisting of: at least one attribute of a terminal rendering the multimedia scene, at least one property of a transmission channel that transmits said scene graph to the terminal, and at least one parameter of a user profile of a user of the terminal rendering the multimedia scene, the sub-graph being generic to, but independent of, the different possible configurations of use conditions of the scene graph; determine a value of at least one of the at least one attribute, the at least one property, and the at least one parameter that applies to the scene graph; and code said sub-graph by application of at least one coding process taking into account the value of at least one of the at least one attribute, the at least one property, and the at least one parameter, in accordance with said strategy data.

13. The device according to claim 12, wherein said processor is configured to code said sub-graph based on code extracted from said scene graph.

14. The device according to claim 12, further comprising: a rendering engine capable of reconstituting said multimedia scene.

15. The process according to claim 1, further comprising a step of outputting, as said enriched representation of the multimedia scene, said scene graph modified by addition of said identification data and data strategy.

16. The device according to claim 5, wherein the processor is further configured to output, as said enriched representation of the multimedia scene, said scene graph modified by addition of said identification data and strategy data.

17. The method according to claim 9, wherein the extraction step comprises extracting from said representation a parent node indicating that a child thereof is susceptible to undergo a subsequent variable coding process that varies as a function of the configuration of use conditions of the scene graph.

18. The device according to claim 12, wherein the processor is configured to extract said identification information from said representation by extracting from said representation a parent node indicating that a child thereof is susceptible to undergo a subsequent variable coding process that varies as a function of the configuration of use conditions of the scene graph.

19. The process according to claim 1, further comprising applying a constraint to the scene graph, wherein the constraint is a function that is dependent on time, and wherein the constraint is linked to a bandwidth of a network to ensure adaptive compression or is linked to the profile of the user during installation of a multimedia companion for a handicapped person.

Description

(1) The advantages and the characteristics indicated hereinabove, as well as others, will emerge more clearly from the following description of some embodiments of the invention, given by way of illustrative though non-limiting examples, and illustrated in reference to the attached diagrams, in which:

(2) FIG. 1 illustrates an example of a system using a static coding model;

(3) FIG. 2 illustrates examples of systems for creation and distribution of scene graphs according to coding models which take into account all possible configurations (terminals/networks), in which:

(4) FIG. 2(a) illustrates a system according to which each user terminal elects the scene graph appropriate to itself, and

(5) FIG. 2(b) illustrates a system according to which the scene graph appropriate to the client is selected prior to transmission;

(6) FIG. 3 illustrates an example of use of a switch node, according to the second approach mentioned hereinabove, to enable adaptation of a scene to the capabilities of its destination terminal, in which:

(7) FIG. 3(a) illustrates a system employing the node Switch, and

(8) FIG. 3(b) illustrates an example of the node Switch, this example being expressed in BT format (a text format of BiFS);

(9) FIG. 4 illustrates an example of a system for creation and distribution of scene graphs according to a coding model as per the third approach mentioned hereinabove;

(10) FIG. 5 illustrates, in the form of a flow diagram, the main steps of a known process (for example, based on the node switch) for production of scene representation data adapted to different constraints imposed by the environment (for example the properties of the transmission path);

(11) FIG. 6 illustrates, in the form of a flow diagram, the main steps of a process for production of a representation of a multimedia scene in keeping with a particular embodiment of the invention and the main steps of a process for processing a representation of a multimedia scene in keeping with a particular embodiment of the invention;

(12) FIG. 7 illustrates, in the form of a flow diagram, the main steps of processes for production and processing of multimedia scene representations in a particular embodiment of the invention comprising an extension of the BiFS standard;

(13) FIG. 8 is a diagram serving to illustrate a scene tree structure shared by two devices, before and after application of adaptive processing at the node 1 according to the embodiment of FIG. 7;

(14) FIG. 9 illustrates an example of use of the invention in the context of the embodiment of FIG. 7, this example being expressed in BT format and taking advantage of the use of new node types AdaptivityControl and ImageCompressionStrategy;

(15) FIG. 10 illustrates another example of the use of the invention in the context of the embodiment of FIG. 7, this example being expressed in SVG format (cf. LASeR standard) and taking advantage of the use of a new type of AdaptivityControl node;

(16) FIG. 11 illustrates an embodiment according to which the condition of the adaptivity control changes dynamically as a function of an external factor such as a network manager or the client; and

(17) FIG. 12 illustrates schematically the components of a device for creation of an enriched scene graph in keeping with an embodiment of the invention.

(18) Before some embodiments of the invention are described, it is appropriate to present the theoretical bases of the invention, especially by explaining how the steps of a process according to the invention differ from the steps of a known process according to which scene representation data are produced to take into account a certain number of constraints.

(19) First of all, the steps of a known process will be explained in relation to the flow diagram of FIG. 5.

(20) Step S11: known techniques are applied to process a multimedia scene to produce a scene graph (GS), comprising a set of nodes (S) and relations (E) which associate the nodes to each other, these relations involving some parameters ().

(21) Step S12: when the aim is to be able to adapt the processing in dependence on the capabilities of the data's destination device (or, more generally, as a function of any constraint originating from the environment or even from other components of the scene), it is appropriate to consider a space defined by all the possible constraints which will be applied to the scene graph. According to the first and second approaches mentioned hereinabove, the space of these constraints must be known a priori. Even though the constraints originating from the environment are defined in the form of functions (t) dependent on time, they are found at the creation of the scene via their specific instantiations. In practice (real application), these constraints can be linked to different factors, such as for example the bandwidth of the network to ensure adaptive compression or the profile of the user during the installation of a multimedia companion for handicapped people.

(22) Step S13: So that the constraints can be applied to the graph, the scene parameters are fixed, at the scene production device, as a function of some strategies. Referring again to the earlier examples, these strategies can refer to selection of a certain compression algorithm (such as png or jpg) or to cancellation of the audio component for the hard of hearing. Encrypting by unique keys for each user, parental control, etc. can also be considered here. All the possible values of the functions ((t)) should be considered.

(23) Step S14: To be prepared for any configuration that is susceptible to occur, it is necessary to create as many scene graphs ((S.sub.1,E.sub.1), (S.sub.2,E.sub.2), . . . ) (or sub-graphs) as possible configurations in the constraint space. According to the application, the notion of constraint space covers different realities. For example, in a compression application, this space comprises all possible combinations between the bandwidths of the networks via which the content can be transmitted, the terminals on which the content can be rendered and the types of content which various users are authorised to access.

(24) Step S15: According to the constraints which apply in practice (for example the value of the bandwidth of the transmission path utilised to transmit the scene representation data, once coded, or the properties of the restoration device), the scene graph which best corresponds to these constraints is selected, this choice being made either at the client terminal (FIG. 2(a)) or prior to transmission of the data (FIG. 2(b)). This corresponds to the measurement of the current value of the (t.sub.i) and the selection of the corresponding data-pair (S.sub.i, E.sub.i).

(25) Step S16: the scene is restored by the restoration device based on the received adapted scene graph (S.sub.i, E.sub.i).

(26) The steps of the processes for production and processing according to the invention will now be explained in an example in relation to the flow diagram of FIG. 6.

(27) Step S21: known techniques are applied to process a multimedia scene to produce an initial scene graph (GSI), as in step S11.

(28) Step S22: the elements of the scene which could be subjected to variable processing (for example for reasons of adaptation to constraints) and those which should undergo fixed processing are identified. For example, when the aim is to process a www page of YouTube type, often it is desired to use a single type of coding in relation to the text which forms part of a multimedia scene without considering the properties of the transmission path and/or the scene destination device, whereas variable treatment in relation to images/video in the scene makes it possible to produce images/video of the best possible resolution at the time of rendering. Still by way of example, if rendering on a thin terminal (mobile telephone) is now considered the tools for haptic navigation can be deactivated, whereas the use thereof on an intelligent terminal significantly increases the comfort of the user. The element (or the elements) that it is desired to be able to subject to variable treatment is (are) selected. This corresponds to the selection of a sub-graph of the scene graph.

(29) The scene sub-graph is defined in the form of a function :SS which identifies a subset of S, the restriction of E to this subset, as well as the subset of parameters |.sub.(E|(S)),(S) of the initial set . This is therefore a unitary and general representation, independent of the various specific configurations which can be found during processing of the scene.

(30) It should be remembered that a sub-graph can correspond to the whole of the initial scene graph.

(31) Step S23: The space of all possible constraints is considered. The constraints are defined in the form of functions (t) of time. According to the invention, at the time of creation of the scene this step does not require knowledge of the specific processing conditions.

(32) Steps S24 and S25: To apply the constraints to the sub-graph, some functions are used to modify the parameters of the scene, these functions mathematically describing the modification strategies. This calculation step can be implemented by the scene production apparatus, by the equipment transmitting the scene, by the equipment receiving the scene or else by network equipment (more generally somewhere between production of the enriched scene representation and rendering of the latter), according to the specific application. The functions [(t)] are calculated, as well as the corresponding adapted scene graph.

(33) Step S26: The multimedia scene is restored at the receiver equipment based on the adapted scene graph.

(34) In relation to FIGS. 7, 8, 9 and 11, an embodiment of the invention will now be described according to which an extension of BiFS is made to define two new types of node which will serve for enrichment of the scene representation. A new type of node, which will be called AdaptivityControl (that is adaptivity control), identifies the sub-graph susceptible of being subjected to variable (adaptation, dynamic) processing. The second new type of node, here designated by StrategyNode (that is, strategy node) defines the details of the (variable) processing to be undertaken. It should be noted that adaptation of this embodiment to protocols/formats/languages other than BiFS falls within the scope of the capabilities of the skilled person, as shown for example by the adaptation to LASeR format illustrated in FIG. 10.

(35) According to the present embodiment, a node of AdaptivityControl type is itself the parent of the selected sub-graph and it contains an ordered list of nodes which give the strategies for the variable treatment.

(36) The list of strategies can be updated by modification, addition or deletion, in a dynamic manner, by employing conventional scene updates. Each strategy has its own node; the logic of the strategy is determined by the type of the node. The fields of each of these nodes give the parameters of the variable processing.

(37) When an AdaptivityControl node is processed by a coder, its strategies are applied to the relevant sub-graph recursively. A decoder of a thin terminal can take into account the existence of an AdaptivityControl node to process the content of the scene adaptively.

(38) As an example of a possible strategy one can cite adaptive processing which serves to compress an image. The corresponding node will be called ImageCompressionStrategy; it serves to provide a list of preferred compression types in relation to compression parameters specific to each of these types. Among the types of compression, an auto type can be defined which serves to code an image adaptively by performing compression adapted for each of the clients. The group of permitted types can be expanded.

(39) It is possible to define other strategies, for example strategies associated with specific types of content (video, 3D, sound) or strategies associated with complex treatments. Apart from the examples already cited (encryption, parental control, haptic control and navigation, multimedia companion for handicapped people), modifications caused in the scene as a function of various environmental conditions of the terminal, such as average luminosity, temperature or its orientation, can also be mentioned here.

(40) The use of these new types of node to enrich a scene adds to the processing phase a degree of flexibility that has been unknown to date.

(41) Because of this flexibility, advantages (in terms of transmission, sharing and reuse of multimedia content) are obtained relative to current techniques, such as: adaptive coding of a single tree structure for different clients, as a function of the capabilities (hardware/software) of the client and/or as a function of the profile of the client and/or as a function of the properties of the link serving for transmission of the data to the client; a single decompression of compressed data (for example, images) is enough during reuse on the receiver side; management of the scene is simplified because when multiple codings are necessary multiplication of the nodes is avoided; there is just one control point for executing updating of a complex scene; the processing parameters can be updated dynamically; and this increased flexibility is achieved without increasing the complexity at the client side.

(42) The flow diagram of FIG. 7 comprises the following steps showing how the invention can be exploited in relation to a scene;

(43) S10: creation of a new AdaptivityControl node and placing the latter in the scene graph;

(44) S20: creation of at least one strategy node according to the behaviour that it is desired to obtain during processing, this node being specified as a strategy relating to the AdaptivityControl node;

(45) S30: creation of the sub-graph which should be processed according to the strategies, and placement of the sub-graph as child of the AdaptivityControl node;

(46) S40: the sub-graph is processed by an adaptive coding as per the strategies forming part of the list of strategies. The adaptive processing can code a simple node appropriately as a function of the capabilities of the client, of the current state of the network and/or as a function of any other constraint relevant to the application (type of subscription, state of battery consumption, user profile, etc);

(47) S50: the content is subjected to a decoding process complementary to the applied coding, and the corresponding sub-graph is produced;

(48) S60: the rendering of the sub-graph is performed and the corresponding displaying occurs in association with reproduction of any appropriate audio.

(49) An example of adaptive processing of a scene according to a strategy is explained in relation to FIG. 8. In this example two nodes are processed differently. The processing of Node1 (which corresponds, for example, to a high-resolution image) depends on the strategy defined in relation to the AdaptivityControl node: in this example Client 1 and Client 2 will receive data coded differently as a function of their capabilities. The processing of Node2 (for example a node which comprises text) is not concerned by the strategy and undergoes conventional processing.

(50) The nodes will be described in more detail hereinbelow. The following descriptions are in conformity with the specification of the BiFS standard. The skilled person can immediately derive corresponding descriptions according to other technologies.

(51) AdaptivityControl

(52) This node is represented in annex 1; it corresponds to an example of a way of specifying and identifying the parts of a scene (node, sub-graph, graph) which are intended to be subjected to adaptive processing, and a way of indicating the strategies which will be applied to perform processing of these parts. The first of these functions is performed by the Node (node) field of SFNode type, whereas the second is performed by the Strategies (strategies) field of MFNode type.

(53) The Node (node) field comprises the upper node of the sub-graph which will be treated adaptively. The Strategies (strategies) field contains a list of all the strategy nodes that should be applied to the sub-graph. The addStrategy (add strategy) and removeStrategy (remove strategy) fields, of MFNode type, are employed to add nodes to the list of strategies and to remove them employing known methods used during grouping of nodes such as Group or OrderedGroup.

(54) ImageCompressionStrategy

(55) This type of node is represented in annex 2; it describes the parameters of a specific example of strategy employed to effect adaptive processing (that is, transmission of compressed images), and is to be inserted into a list of strategies of an AdaptivityControl node (or other node of this kind).

(56) This particular strategy modifies the way in which the images are coded by specifying a list of possible compression types along with their associated parameters.

(57) The compressionType field is a list of chains of data. Each element is a possible compression strategy which could be used for coding the (image) content of part of the scene. The content by default of this list is auto: in this way the coder can select a type of appropriate compression as a function of the constraints measured at a certain moment.

(58) In relation to each type of compression an element of the list compressionParams is defined; it contains the list of possible parameters which will be employed in relation to this type of particular compression. The auto type has no need of parameters.

(59) Example of Use

(60) From the multimedia viewpoint, FIG. 9 illustrates a way of integrating the two types of nodes into BiFS to achieve adaptive coding of image-type content in a particular PixelTexture node.

(61) After the creation of an AdaptivityControl node, there follows a conventional hierarchy of nodes (Shape, Appearance, Material2D, PixelTexture nodes) necessary for placing an image on the scene. A new ImagecompressionStrategy node is created in the list of strategies of the AdaptivityControl node. The PixelTexture node, as an element of the sub-graph controlled by the AdaptivityControl node, is affected by the strategy that is applied for compression processing of image data.

(62) From the functional viewpoint, three mechanisms implement the dynamic adaptive coding. First, the same scene content should be perceived by two different clients which have different computer/display resources, the node being processed differently/adaptively in relation to each user. Second, the computer/display resources of the same user can vary over time (for example a second application is launched on this client, reducing the available resources of the processor). Finally, it is probable that modifications of conditions applying to the network will take place during perception of the content by the user. These three mechanisms will be converted into a set of parameters controlling the adaptation.

(63) As can be seen from FIG. 9, relative to the solution illustrated in FIG. 3(b) the invention enables a scene to be made consistent with the various terminals/networks without substantial change to the structure or complexity of the scene graph. According to this example it is evident, in particular, that it is not necessary to send each client all the different possible versions of the image.

(64) Even though this example exploits the already-existing PixelTexture type of node, the invention can relate to any other BiFS node. Also, as indicated hereinabove, the application of the invention is not limited to the BiFS standard; it can be applied in relation to other standards as well as with non-standard approaches.

(65) Still by way of illustration, FIG. 10 shows the way in which part of an image can be compressed adaptively and dynamically in LASeR. Within the group identified by the example id, the AdaptivityControl node is defined. This node contains an ImageCompression strategy dedicated to coding of images. Three types of coding are possible: auto, png, jpg. These coding algorithms can be applied with different parameters described by png-level or jpeg-quality. The image which forms the object of this processing is referenced by the image node that already exists in LASeR and which specifies the id of the image (the xlink:href field) as well as the scene coordinates (the x, y, width and high fields) where the image must be rendered.

(66) The rendering on the client side which enables viewing (or interaction with) the representations produced according to the embodiments of the present invention can be of various natures: for example, a plugin in a navigator, specific software for processing representations, a module which forms part of the operating system, a special adaptation of the equipment (hardware). The invention is not limited relative to the nature of the rendering means.

(67) FIG. 11 schematically shows an embodiment of a system according to the invention in which a server provides data representing a scene to its clients, via a network. According to this embodiment, at the server a scene generator 10 generates a scene representation enriched according to the invention and an adaptive control unit 12 implements the required variable processing as a function of the information received from the client-side rendering device 16, and from a network manager 14. Of course, as indicated hereinabove, the invention is not limited to the case where adaptation is done at the server.

(68) FIG. 12 schematically shows an embodiment of the scene generator 10 of FIG. 11.

(69) A scene graph generator module 20 processes the data originating from an application to define an initial scene graph. Various conventional processes are used in this field to define a scene graph to represent data originating from an application and the invention is not particularly limited with regard to the processes which the scene graph generator 20 can employ. However, unlike known scene graph generator devices, the module 20 is configured to detect the parts of the scene graph which could, optionally, undergo variable processing during coding (for example as a function of the profile of a client).

(70) This detection function is based on criteria which often are defined in advance and which depend for example on the choices of the designer. For example, when the aim is to allow coding of video data using a variable number of bits according to the profile of a client, the scene graph generator module 20 applies a rule which serves to detect those parts of the graph (for example, nodes) which correspond to video data streams. Another example relating to performing an encrypting function according to which some data forming part of the scene is encrypted as a function of different keys involves application by the scene graph generator module 20 of a rule which serves to define which data is concerned by this variable encryption.

(71) There are various ways of informing the scene graph generator module 20 of the criteria to be applied during execution of the detection function mentioned hereinabove: for example, the data defining the appropriate criteria can be stored inside this module 20 or stored in a memory 60 which is external to the latter (hence the arrow in dotted lines in FIG. 12), or a dynamic configuration can be provided according to which when the initial scene graph is created the scene graph generator module 20 obtains the criteria necessary for this detection step (for example, from a human or computer controller).

(72) Naturally, a single scene graph can comprise several elements which are susceptible to variable processing treatments and which are recognised by the scene graph generator module 20 by applying different criteria.

(73) The scene graph generator module 20 produces information I.sub.1 which serves to identify the parts of the initial scene graph which are susceptible of undergoing variable processing. This information I.sub.1 indicates not only the elements of the initial scene graph which can undergo variable processing but also identifies the relevant respective processing (for example, by using predefined identifiers). The format of the information I.sub.1 is not particularly limited: there can be provided a single block of data which comprises all the information necessary in relation to the initial scene graph, a respective block of data for each scene element which can undergo variable treatment, or any other suitable format.

(74) The scene graph generator module 20 associates the information I.sub.1 with the initial scene graph and the resulting data is output. At the output of the scene graph generator 20, the elements of the initial scene graph which are candidates for transformation are detected by a module 30 based on the information I.sub.1, for inputting into a block 40 which makes the link to the strategies which are predefined in relation to the relevant variable processing treatment(s).

(75) There are several ways of providing the block 40 with the details of the strategies which relate to the different provided variable processing treatments: for example, these details can be stored in the memory 60 during a preliminary configuration phase of the device 10, or a dynamic configuration can be provided according to which the block 40 obtains details of the strategies (for example, from a human or computer controller) at the moment of associating the strategies to the elements of the scene graph.

(76) As a function of these strategies, the corresponding nodes of AdaptivityControl type are instantiated by a block 50. In fact, the block 50 performs calculations for executing the decisions made by the block 40. The information necessary for operation of this block 50 is obtained in the same way as that necessary for the block 40. The final enriched graph is obtained at the output from a graph-enrichment device 75 which combines the AdaptivityControl instances and the selected strategies with the elements of the initial scene graph which will not undergo variable processing. This integration can be done by replacing in the initial scene graph GSI (produced by the module 20) the elements susceptible to variable processing by their adapted versions output from the block 50. This approach ensures backward compatibility with known coding devices and client terminals.

(77) The memory 60 for controlling operations of blocks 30 to 50 (and optionally of block 20) receives its information from the configuration devices (whether manual or automated).

(78) The configuration of the scene generator 10 according to the example described hereinabove corresponds to one of the different possible ways to distribute the functions destined to produce an enriched scene graph in keeping with the invention. The skilled person knows that the abovementioned functions can be carried out by using modules different in number and/or nature to those of FIG. 12. For example, the function of detecting the parts of the scene which correspond to elements which can undergo variable processing, performed by module 20 of FIG. 12, can be accomplished by module 30. In this case, this module must have additional information supplied by the memory 60 (cf. the arrow in dotted lines).

(79) Even though particular embodiments of the present invention have been described hereinabove, the skilled person will understand that various modifications and adaptations can be made to the latter without departing from the scope of the present invention.

(80) TABLE-US-00001 ANNEX 1 AdaptivityControl { eventIn MFNode addStrategy eventIn MFNode removeStrategy exposedField MFNode Strategies [ ] Field SFNode Node }

(81) TABLE-US-00002 ANNEX 2 ImageCompressionStrategy { Field MFString compressionType [auto] Field MFString compressionParams [ ] }