Method and apparatus for concise encapsulation of images in a media file

Abstract

The present invention concerns A method of encapsulating an image into an ISOBMFF based media file, the method comprising, by a computing device, the steps of: generating parameters describing the image; generating a file level box comprising the parameters and image data; wherein the method further comprises: generating at least one indicator, each indicator being associated with a set of the parameters describing the image, each indicator indicating a coding mode for encoding the parameters of the associated set of parameters; and embedding the at least one indicator and the file level box in the media file.

Description

[0001] METHOD AND APPARATUS FOR CONCISE ENCAPSULATION OF IMAGES IN A MEDIA FILE

[0002] FIELD OF THE INVENTION

[0003] The present disclosure concerns a method and a device for encapsulating one or more images in a media file. It concerns more particularly the definition of a concise format of encapsulation of an image in an ISOBMFF based format. This concise format being particularly adapted for the encapsulation of small images.

[0004] BACKGROUND OF INVENTION

[0005] Images captured by a camera or processed by an image analysis service are stored on a storage device like a memory card, for example. The images are typically encoded to reduce the size of data on the storage device. Many encoding standards may be used, like JPEG, AV1, or the more recent HEVC or VVC standards.

[0006] The HEVC standard defines a profile for the encoding of still images and describes specific tools for compressing single still images or bursts of still images. An extension of the ISO Base Media File Format (ISOBMFF) used for such kind of image data has been proposed for inclusion into the ISO / IEC 23008 standard, in Part 12, under the name: “HEIF” or “High Efficiency Image File Format”.

[0007] HEIF (High Efficiency Image File Format) is a standard developed by the Moving Picture Experts Group (MPEG) for storage and sharing of images and image sequences.

[0008] The HEIF design is versatile and provides generic data structures or boxes, for the storage of image items and sequences with their properties in a codec-agnostic manner. It relies on the use of the ‘meta’ box with version=0 as top-level box and container box for all other boxes describing the images or image sequences. However, for specific use cases involving small images, i.e. when the size of the image payload is small compared to the HEIF structures, a reduced and optimized set of data structures may be used. These use cases can be for small images on the Web (icons, thumbnails...), for small images used in user interfaces, shared on social networks. For any other use cases, HEIF remains the container of choice for any type of images: derived images like grid or overlay, image collections, multiple images, large images or images with significant payload size compared to the size of the HEIF structure.

[0009] Indeed, the HEIF format is considered too verbose for small images. For example, a file may consist in more than 200 bytes of description for an image actually representing few bytes. The aim of the invention is to propose a method to generate a concise description in HEIF particularly adapted for encapsulation of small images, while ensuring a simple parsing and extraction of the item described with the concise description. For example, image files with concise description may be indicated by a specific brand (for example called ‘mif3’ in this disclosure, but may be any other four character code value not conflicting with an existing brand) to differentiate from the HEIF based on the ‘meta’ box with version=0 and use the ‘mini’ box as top-level box describing the images

[0010] SUMMARY OF THE INVENTION

[0011] The present invention has been devised to address one or more of the foregoing concerns.

[0012] According to a first aspect of the invention there is provided a method of encapsulating an image into an ISOBMFF based media file, the method comprising, by a computing device, the steps of:

[0013] - obtaining parameters describing the image;

[0014] - generating a file level box comprising the parameters and image data; wherein the method further comprises:

[0015] - generating at least one indicator, each indicator being associated with a set of the parameters describing the image, each indicator indicating a coding mode for encoding the parameters of the associated set of parameters; and

[0016] - embedding the at least one indicator and the file level box in the media file.

[0017] In some embodiments, the at least one indicator is a brand indication in the media file.

[0018] In some embodiments, the at least one indicator is provided among the parameters describing the image.

[0019] In some embodiments, the length of the parameters describing the image has a predefined value depending on the at least one indicator values. In some embodiments, the at least one indicator are three indicators associated with:

[0020] - a first set of parameters comprising parameters encoding the image dimensions;

[0021] - a second set of parameters comprising parameters specifying the length of configuration data associated with the image data; and

[0022] - a third set of parameters comprising parameters specifying the length of the image data.

[0023] In some embodiments, the file level box comprises metadata, and wherein the at least one indicator are four indicators associated with:

[0024] - a first set of parameters comprising parameters encoding the image dimensions;

[0025] - a second set of parameters comprising parameters specifying the length of configuration data associated with the image data;

[0026] - a third set of parameters comprising parameters specifying the length of the image data; and

[0027] - a fourth set of parameters comprising parameters specifying the length of the metadata.

[0028] In some embodiments, the file level box comprises metadata and alpha data, and wherein the at least one indicators are five indicators associated with:

[0029] - a first set of parameters comprising parameters encoding the image dimensions;

[0030] - a second set of parameters comprising parameters specifying the length of configuration data associated with the image data;

[0031] - a third set of parameters comprising parameters specifying the length of the image data; and

[0032] - a fourth set of parameters comprising parameters specifying the length of the metadata;

[0033] - a fifth set of parameters comprising parameters specifying the length of the alpha data.

[0034] In some embodiments, the parameters describing the image are embedded in a MinimizedlmageHeader data structure in the file level box. In some embodiments, the file level box may further comprise alpha data and may further comprise metadata; and wherein the image data, the alpha data if any, and the metadata if any, are embedded in respective MinimizedlmageData data structures in the file level box.

[0035] According to another aspect of the invention there is provided a method of obtaining an image from an ISOBMFF based media file, the method comprising, by a computing device, the steps of:

[0036] - obtaining a file level box from the media file comprising the image data and parameters describing the image;

[0037] - obtaining from the media file at least one indicator, each indicator being associated with a set of the parameters describing the image, each indicator indicating a coding mode for encoding the parameters of the associated set of parameters;

[0038] - decoding the parameters describing the image based on the at least one indicator value;

[0039] - obtaining the image based on the decoded parameters.

[0040] According to another aspect of the invention there is provided a computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for implementing a method according to the invention, when loaded into and executed by the programmable apparatus.

[0041] According to another aspect of the invention there is provided a computer- readable storage medium storing instructions of a computer program for implementing a method according to the invention.

[0042] According to another aspect of the invention there is provided a computer program which upon execution causes the method of the invention to be performed.

[0043] According to another aspect of the invention there is provided a device for encapsulating an image into an ISOBMFF based media file, the device comprising a processor configured for:

[0044] - obtaining parameters describing the image; - generating a file level box comprising the parameters and image data; wherein the method further comprises:

[0045] - generating at least one indicator, each indicator being associated with a set of the parameters describing the image, each indicator indicating a coding mode for encoding the parameters of the associated set of parameters; and

[0046] - embedding the at least one indicator and the file level box in the media file.

[0047] According to another aspect of the invention there is provided a device for obtaining an image from an ISOBMFF based media file, the device comprising a processor configured for:

[0048] - obtaining a file level box from the media file comprising the image data and parameters describing the image;

[0049] - obtaining from the media file at least one indicator, each indicator being associated with a set of the parameters describing the image, each indicator indicating a coding mode for encoding the parameters of the associated set of parameters;

[0050] - decoding the parameters describing the image based on the at least one indicator value;

[0051] - obtaining the image based on the decoded parameters.

[0052] At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.

[0053] Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible, non-transitory carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal.

[0054] BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which:

[0056] Figure 1 illustrates the main processing steps of an encapsulation method according to embodiments of present invention;

[0057] Figure 2 illustrates the main processing steps of a selection method of the condensed encapsulation in some embodiment of the invention;

[0058] Figure 3 illustrates the main steps of a process for generating the condensed encapsulation according to embodiments of the invention;

[0059] Figure 4 illustrates the main steps in a de-encapsulation process according to some embodiments of the invention;

[0060] Figure 5 is a schematic block diagram of a computing device for implementation of one or more embodiments of the invention.

[0061] DETAILED DESCRIPTION OF THE INVENTION

[0062] According to ISOBMFF and its extensions, a media file is constituted by boxes. Boxes, also called containers, are hierarchical data structures provided to describe the data in the files. Boxes are object-oriented building blocks defined by a unique type identifier, typically a four-character code, also noted FourCC or 4CC, and a length. All data in a file, media data and metadata describing the media data, is contained in boxes. There is no other data within the file. File-level boxes are boxes that are not contained in other boxes.

[0063] Figure 1 illustrates the main processing steps of an encapsulation method according to embodiments of present invention.

[0064] The encapsulation method consists in an iterative processing that applies successively to each image to be represented in an HEIF format file. The processing steps of the figure 1 represents the processing of one image. However, in particular cases more than one image may be represented in the same media file. Some images may also be derived from previously represented images and thus may introduce dependencies between image items. In another example, the input of the encapsulation may consist in a sequence of one or more images to represent an animation. In that case, the encapsulation process described in figure 1 is applied successively to each input image of the sequence. The encapsulation process would maintain in memory the previously generated media file and would update this previously generated media file instead of generated a new media file in the steps 103 to 106.

[0065] In a first step 100, the encapsulation method determines the image configuration. The image configuration is a set of parameters or properties associated to the images. For example, it may comprise parameters indicating the codec associated with profile, tier and / or level data information that is used to compress the image to be represented in HEIF file. The configuration parameters may also include a set of coded structures describing coding configuration that allows instantiating a decoder. This set of coded structures is also denoted in this document as configuration data.

[0066] Other parameters representing the configuration of the image comprise for example the dimension or resolution of the images. It may also comprise the number of components present in the image. A component is defined as a set of data having the same semantics that is associated to the image pixels. For example, the pixels values of an image form one image component. The alpha plane or alpha channel is another component when present in the coded image. Some images may be associated with metadata that can be described with EXIF or XMP metadata format. In this document, each set of metadata is considered as one component. It is to be noted that in monochrome format, the pixels values data may consist in a single channel but it is still considered as a component. In color formats, each pixel has several pixel values, for example a red value, a green value and a blue value. Each color forms a channel, all the color channels form a component. The configuration of the image may also comprise the length in bits or bytes of the configuration data for each component and / or the length in bits or bytes of the compressed data for each component.

[0067] The encapsulation processing continues with the check step 102 that confirm whether a condensed or slim or compact file format representation will be used to describe the media file. The condensed description of this invention aims at providing a minimal description of the image that allows a simplified parsing of the HEIF description and parallel processing of the image components. The benefit of the condensed description is also to have a compact description for compressed images that are represented with a small amount of data. The compactness of the compressed data may come either from an efficient compression (with possible loss of quality due to the compression) or from the small dimensions of the images resulting in a low definition.

[0068] The criteria that would enable such representation are manifold. They may rely for example on the necessity for an application to render rapidly low-definition images for the generation of a graphical user interface or for rendering interactive entity in a webpage such as clickable images. Other criteria related to the image configuration like the dimension, the number of components or the length in bits or bytes of the coded data, may prevent the image to be described with a condensed description. An example of the check process based on the previously mentioned criteria is described with reference to figure 2.

[0069] When the image does not meet the criteria as checked in step 102, the encapsulation process uses a regular or standard HEIF encapsulation by generating a media file header in step 103 and represents the image as an HEIF item using a MetaBox to describe the image data. The generation of the MetaBox information is illustrated by the step 104 in figure 1.

[0070] On the contrary, if the condensed description is selected in step 102, the steps 105 to 106 applies starting with the generation of HEIF media file header in 105. HEIF media file header starts by a Box, for example a FileTypeBox, that indicate a set of brands that applies to the media file. In particular, this box may indicate a set of one major brand, one or more minor brands or compatible brands. When condensed description is used, a specific brand may be indicated in the list of brands to indicate the presence of boxes specific to the condensed description. For example, these boxes may be generated in the step 106.

[0071] HEIF defines structural brands and codec-specific brands. There are currently two main structural brands defined in HEIF for image and image collection: ‘mifT and ‘mif2’.

[0072] The Annex I of the HEIF specification provides guidelines for specifying storage of image coding formats. In particular, section 1.5 states that “if the derived file format specifies new file format structures, it should also specify a new brand and register that with the MP4 Registration Authority’. Since the condensed description brings new file format structures, it may be specified using a new brand for example a structural brand.

[0073] To indicate the compatibility with legacy version of HEIF format, the brand for media file using condensed description may be compliant with the ‘mifT brand and the ‘mifT brand is thus provided in the list of compatible brands. A possible brand definition for condensed description may consist in using the ‘mif3’ brand to indicate one of the following file requirements: presence of MinimizedlmageBox box for example with ‘mini’ Box type as top-level box of the media file; or the presence of a MetaBox ‘meta’ box and its sub-boxes as for media file compatible with the ‘mifT brand (for backward compatibility). In other words, a file that contains a MinimizedlmageBox has major_brand of the FileTypeBox set to ‘mif3’.

[0074] A media file reader may be considered as supporting this ‘mif3’ brand when it is able to process MinimizedlmageBox box for example with ‘mini’ when provided as toplevel box of the media file. The reader has also to support reader requirements for ‘mifT brand. As a variant, the reader has also to support reader requirements for ‘mif2’ brand and support all reader features of 'mifT brand. The reader also has to support alpha item and color information, in particular the color spaces that may be indicated by colour information parameters in the ‘mini’ box. It also has to support EXIF and XMP. It may also have to support depth map.

[0075] Any reader conforming to the 'mif3' brand supports displaying of at least the image included in the main item provided that the reader supports the item type of that image.

[0076] In another embodiment, the encapsulation module may provide the ‘1 pic’ brand in the list of compatible brands to indicate that the condensed description is provided for a single image.

[0077] In step 106, the encapsulation generates the condensed image description for the image. The processing employed to generate the condensed image description is described with reference to figure 3.

[0078] The Annex C of HEIF defines the High efficiency image file MIME type registration as recorded at I ANA. In particular, it defines the MIME type to use for image and image collection. It also defines optional parameters (codecs, profiles, itemtypes...) that can be used to further describe the items present in an HEIF file. Moreover, ISOBMFF, Annex K informs about the use of IETF RFC 6381 for ISOBMFF files.

[0079] A media encapsulation device or de-encapsulation device provided with a processor configured for implementing methods described in embodiments of this disclosure may use the different parts or parameters of a MIME type to distinguish media file using condensed description from other HEIF file as currently specified by ISO / IEC 23008-12. The MIME type of a HEIF file using condensed description may be as follows: The type name is set to “image”; the subtype name can be “heif” or “heic”, depending on the brand(s) provided in the media file. The MIME subtype name may be 'heic' only if the media file conforms to the requirements of the 'heic', 'heix', 'heim', or 'heis' brand, and contains at least one of those brands as a compatible brand (i.e. HEVC or L-HEVC coded). The subtype name may be 'heif' only if the media file conforms to the requirements of the 'mifT brand, and contains that brand as a compatible brand. The media file using condensed description files has thus to conform to the 'mifT brand and have the 'mifT brand listed as a compatible brand. This may happen in particular when the box hierarchy of media file requires a mif1 brand (indicating the presence of a toplevel ‘meta’ box and its sub-boxes). As a result, it constrains that the condensed description is provided as a sub-box of the MetaBox potentially using a new version for this box.

[0080] In a variant a new subtype is defined for media file using the condensed description. For example, this new subtype name is “hif2”. When the MIME type of the media file uses this new subtype name “hif2” the media file may have the following properties: the ‘mifT brand or the new brand ‘mif3’ for condensed description are provided as compatible brands and therefore associated requirements for the brand shall be fulfilled. The semantics of the subtype ‘hif2’ indicate an High efficiency image file containing one image item possibly with alpha plane in any coding format. This subtype name may be ‘hif2’ only if the file conforms to the requirements of the ‘mif3’ brand.

[0081] The MIME parameter called codecs of the MIME type, defined in RFC 6381 , allows specifying which codecs to use to render the content of the container. Since it does not indicate a version or brand of the container, the client may not use this parameter to distinguish media files using condensed description from other media files.

[0082] The MIME parameter called profiles, also defined in RFC6381 , may be used to provide the HEIF brand in use; e.g. 'mifT for current HEIF or a new brand ‘mif3’ corresponding to media file using condensed description. The profiles parameter lists the major_brand followed by the compatible brands.

[0083] The MIME parameter called itemtypes, defined in HEIF, describes the items present in the media file container. This parameter may describe at least the primary item. The description of an item starts with the four-character item_type value of this item. In the case of media file using condensed description, the item_type value corresponds to a value also used for current HEIF. Therefore, a client may not use this parameter to distinguish media file using condensed description from other media file.

[0084] A media file generated according to the invention may use the following MIME type when condensed image description is not used: type= ' image / heic; codecs="hvcl . Al . 80 . L93 . BO" prof iles="mif 1" ' for an HEVC coded image type= ' image / heif ; codecs="avcl . Al . 80 . L93 . BO" prof iles="mif 1" ' for an image compliant with mifl brand only type= ' image / hif 2 ; codecs="avcl . Al . 80 . L93 . B0" prof iles="mif 1" ' for an image compliant with mifl brand and may use the following MIME type for media files using the condensed description: type= ' image / hif 2 ; codec s="hvcl . A1 . 80 . L93 . B0" prof iles="mif 3" '

[0085] The ‘hif2’ subtype provides a codec-agnostic MIME type and the distinction between legacy HEIF and HEIF using condensed description is determined from the profiles MIME type parameter.

[0086] As other examples, a condensed HEIF file for an image encoded in VVC and HEVC can respectively be described by the following MIME types:

[0087] Content-Type : image / hif2 ; codecs="wcl . 1 . L51 . CQA" ; prof iles="mif 3"

[0088] An image file with low-overhead HEIF container containing one VVC-coded image using Main 10 profile, Main Tier, Level 3.1.

[0089] Content-Type : image / hif2 ; codecs="hvcl . l . 80 . L93 . B0 " ; prof iles="mif 3"

[0090] An image file with low-overhead HEIF container containing one HEVC-coded image.

[0091] Moreover, to distinguish condensed HEIF from HEIF, a new file extension is suggested, for example ‘hlif’ for High Efficiency Low-overhead image format or a 3-letter code for compatibility with Design rules for Camera File System (DCF) like ‘hlf’.

[0092] Figure 2 illustrates an example of implementation of the step 102 in figure 1 in some embodiment of the invention. This step aims at selecting the encapsulation mode of the image, namely to select the regular HEIF encapsulation or a condensed encapsulation mode according to embodiments of the invention. This selection process starts by the determination of the image dimensions in a step 200. Since one criterion for enabling condensed description is the dimension of the image, it is checked in a step 201 if the image size or dimension or resolution i.e. the height or the width is greater than a threshold. For example, this threshold may be set to 4096 pixels. As a result, any picture with a greater dimension than 4096x4096 pixels is considered as invalid for the condensed description and the process ends in step 208 that indicates that the condensed description cannot be used. On the contrary, an image with a lower dimension e.g. 512x512 pixels is valid for a representation as condensed description at this step, the process continues with the examination of further criteria.

[0093] Following this first check criterion, the selection process continues with a processing loop controlled by the step 202. This processing loop applies the steps 203 to 206 successively to each component of the image.

[0094] The step 203 determines the type of the component. The types of the components are for example, pixel color values, alpha plane, Mask channel or depth plane, EXIF metadata, XMP metadata and User Defined metadata components. This example of component types is not limiting. The image component that may be described using a condensed description may be limited. For instance, in a first variant there is no limitation on the type of the component. In such a case, the step 204 always validates the component type. In another variant, the condensed description is limited for a subset of the possible image components. For instance, only components of the following types are valid: pixel color values, alpha plane, EXIF metadata, XMP metadata. Any other components types would return an invalid configuration for the condensed description and the process returns in step 208 indicating that the condensed description cannot be used.

[0095] Another criterion for the condensed description may be the length of the coded (possibly compressed) data representing the component that corresponds to the payload of the component. Indeed, the condensed description aims at targeting preferentially small images for which the size of the regular metadata description may be considered as too big compared to the size of the payload. In an alternative, an image may be considered as a small image when the image dimensions (width and / or height) or payload size are below a predefined threshold, for example 1024x1024 pixels, and / or when the image data has a size lower than 16kBytes. For this reason, after determining the size, meaning the length in bits or bytes of the component’s payload in a step 205 (i.e. the length of the pixel values if the component is pixel values, the length of the coded alpha plane for alpha component, or the length of the metadata for an EXIF or XMP metadata component) the encapsulation process validates whether it is below a maximal length threshold. The maximal length threshold may for example correspond to a multiple of the size saved with the condensed description. For example, the maximum value may be set to 10 times the size saved with condensed description. This size saving may be determined by performing two encapsulations of the bitstream and then comparing the size of the media file encapsulated with fully described MetaBox and with the condensed description. Alternatively, it can be observed that a general gain of 200 to 300 bytes is expected with condensed description. Thus, a predetermined value of maximum length equal to 4096 bytes can be used by default.

[0096] If the image fulfils all the tested criteria for all components, the process ends in step 207 indicating that the condensed encapsulation of the image is valid, and therefore selected. In summary, in this example, the condensed encapsulation is selected when the image dimensions are not too big, when all components have a component type compatible with the condensed encapsulation and when the data size of all the components are below a predefined threshold.

[0097] In another embodiment of this invention, the selection step 102 may use additional criteria related to the encapsulation options for condensed description. For example, the use of derived images, the use of grid items may be considered as invalid or not compatible with the condensed description.

[0098] Figure 3 illustrates the main steps of a process for generating the condensed encapsulation according to embodiments of the invention.

[0099] In a first step 300, a condensed image header or minimized image header is generated. This condensed image header comprises a reduced number of parameters describing the image configuration. This reduced number of parameters specifies the properties of the image.

[0100] The condensed image header may comprise a version number indicating a value that makes it possible to distinguish different versions of the condensed description syntax.

[0101] The condensed image header may comprise a parameter indicating the type of the colour profile configuration (e.g., sRGB, ICC profiles etc.).

[0102] The condensed image header may comprise the width and the height of the image described by the condensed description.

[0103] The condensed image header may comprise the number of bits used to represent the pixel values of the Image described by the condensed description.

[0104] The condensed image header may comprise an indication whether the pixel format uses float or integer representation. The condensed image header may comprise an indication of the range of the pixel values.

[0105] The condensed image header may comprise an indication whether the Image described by the condensed description is associated with an alpha plane.

[0106] The condensed image header may comprise an indication if the pixels values of the image described by the condensed description are pre-multiplied by the alpha plane.

[0107] The condensed image header may comprise an indication if the Image described by the condensed description data includes an explicit list of codec types.

[0108] In a step 301 , a data structure is generated comprising the compressed data corresponding to the pixel values component, namely the pixel values of the image. This data structure may also comprise optional configuration data as will be detailed below. The configuration data may contain the decoder (or codec) configuration box data that may be provided in SampleEntry of an ISOBMFF file. For example, for an HEVC item, the configuration data may correspond to the content of the HEVCConfigurationBox as per ISO / IEC 14496-15. Another example is VVCConfigurationBox or AVCConfigurationBox as defined in the same specification for a VVC or an AVC Item, respectively.

[0109] In a step 302, when the image comprises an alpha plane, another data structure is generated comprising the auxiliary component such as alpha channel or depth data. The data structure is the same as for the pixel components of the image described using condensed description.

[0110] The pixel and auxiliary data are both represented as coded items for which the data is provided in the data structure generated in steps 301 and 302. This data structure is denoted as Minimized Item data structure (also denoted Minimized Item Data data structure) and the items described in the condensed description of the image may be denoted as Minimized Item. A minimized item is an item that is described in the condensed description of an image. An item described in a legacy HEIF MetaBox based on ItemlnfoBox and ItemLocationBox is not a minimized item.

[0111] In a step 303, when the image is associated with metadata, such as EXIF orXMP metadata for example, this metadata is represented as a coded item using the same minimized item data structure.

[0112] In a step 304, information related to the color information such as the color primaries, the Transfer Characteristics and the Matrix coefficients are represented in a ColourData data structure. These data structures are not ISOBMFF boxes, they are all comprised in a single ISOBMFF box, the Minimized Image box. A Minimized Image may be defined as an Image described using condensed description. In an example of one embodiment of this disclosure, the condensed description of the image is described as a Minimized Image box that may have the following syntax:

[0113] Box Type: 'mini '

[0114] Container: File

[0115] Mandatory: No

[0116] Quantity: Zero or one aligned(8) class MinimizedlmageBox extends Box( ' mini ' ) { MinimizedlmageHeader header;

[0117] MinimizedltemData mainltem(header . has_explicit_codec_type) ;

[0118] MinimizedltemData alphaltem(0) ;

[0119] ColourData colourData(header . colour_type) ;

[0120] }

[0121] In this example, the header is the condensed image header (as generated in the step 300) of the Minimized Image, the mainltem is the Minimized Item data structure (as generated in the step 301) comprising the compressed data of the pixel values component, the alphaitem is the Minimized Item data structure (as generated in the step 302) comprising the alpha channel data, and the colourData is the colour information comprising the coding characteristics of the Color of the mainltem. In this example, the Minimized Item data structure of the metadata structure (as generated in the step 303) is not represented.

[0122] In some embodiments, the MinimizedlmageHeader data structure is omitted. In which case, the parameters describing the minimized image are directly included in the MinimizedlmageBox, for example at the beginning of the MinimizedlmageBox or prior to the coded data of the items described in the box, instead of being included in a dedicated data structure. This alternative for the storage of the parameters applies to all embodiments described in this document. This means that the different embodiments of the MinimizedlmageHeader, or MinimizedlmageProperties as it may also be named, can be implemented by inserting directly the content of the header at the beginning of the MinimizedlmageBox.

[0123] In a first embodiment, the notion of Minimized Image is described by an ISOBMFF Box or alternatively a Full Box. To ensure that the maximum size of the Minimized Image is limited, it may be defined as an extension of a new type of Box that has constraints on its maximum size. This may be achieved for example by limiting to 16 bits the field expressing the size of the box, this way we ensure that the size of a Minimized Image box cannot exceed 65 535 bytes.

[0124] This box describes a structure containing the parameters of the Minimized Image header, as generated in step 300. The Minimized Image box may also contain one or two Minimized Items. The first Minimized Item is the main Item that contains the pixel values data as generated in step 301. The second optional Minimized Item is an Alpha Item that contains the coded alpha plane or transparency data associated with the Main item. The presence of the alpha Item may be conditional to the value of a parameter coded in the Minimized Image Header. The presence of an Alpha Item in a Minimized Image box implies a dependency between the Image item and the Alpha Item.

[0125] When the media file contains a single Minimized Image, the main Item is inferred as the primary Item of the media and the ‘pitm’ box can be avoided which makes the signaling more compact. As a reminder, the ‘pitm’ box in an ISOBMFF file aims at indicating a so-called primary item for indicating to a parser the item intended to be rendered in priority in the media file.

[0126] The Minimized Image also contains an optional ColourData data structure (also denoted Colour Configuration data structure) that collects all the parameters describing the color characteristics used for the main Minimized Item of the Minimized Image.

[0127] The Minimized Image Box syntax is made so that the first syntax elements of each of the Minimized Image Header, the Minimized Items and the ColourData data structures are byte aligned. For fast and simplified parsing of the Minimized Image, the Minimized Image Header has a fixed length.

[0128] The first bits of the Minimized Items define the size of the Minimized Item to allow skipping coded data to find the first byte of the following coded structure in the Minimized Image box. This feature associated with the fixed length of the header allows the parser to directly access the different elements in the Minimized Image box.

[0129] Accordingly, a parallel treatment of these elements is made possible.

[0130] In addition, the signalling or encoding order of the items in the Minimized Image follows the processing order of minimized items for most of the applications. Indeed, the data corresponding to the main item is provided first followed by the item providing transparency or alpha information. The advantage of this approach is to allow a sequential processing of the data without having to store data for later processing and therefore reduces the buffering resources required to process the media file. The Minimized Image Header or Minimized Image Properties may have the following syntax: aligned (8) class MinimizedlmageHeader { / / (5 bytes) bit (2) version; bit (l) has_explicit_codec_types; bit (2) colour_type; bit (l) pixel_format; bit (4) pixel_precision bit (3) chroma_sampling_idc; bit (l) full_range; bit (l) has_alpha; bit (l) alpha_is_premultiplied; bit (12) width_minus_one; bit (12) height_minus_one;

[0131] }

[0132] The Minimized Imager Header is a condensed description of the image parameters or properties. It contains parameters which provide information on the structure of the Minimized Image Box. The MinimizedlmageHeader structure may also be named MinimizedlmageProperties.

[0133] The version parameter indicates the version of the syntax of the Minimized Image Box syntax. For example, it can be set to the value 0 and other values can be reserved for future version of the Minimized Image box.

[0134] The has_explicit_codec_types parameter equal to 1 indicates that both infe_type and codec_config_type are explicitly signalled in the Minimized Item Data. When equal to 0 their types are inferred from the major_brand of the FileTypeBox.

[0135] A second set of parameters is related to the pixel representation.

[0136] The colour_type specifies the colour encoding type. When set to 0, it may indicate that sRGB colour encoding is used. When set to 1 or 2, the colour information is provided in the CoulourData data structure. When set to 3 it indicates that an ICC Profile is provided in the CoulourData data structure. pixel_format parameter equal to 0 indicates that the pixel format uses an integer number representation. Pixel_format parameter equal to 1 indicates that the pixel format uses a floating-point number. pixel_precision plus one specifies the maximum number of bits used for the values of the pixels channels of the reconstructed items described in the Minimized Image, when pixel_format equals 0. When pixel_format equals 1 , pixel_precision specifies the format of floating-point numbers used for the pixel values as defined by IEEE 754-2008: if pixel_precision is equal to 0 the pixels use half-precision float (binary 16) format; if pixel_precision is equal to 1 the pixels use a single-precision float (binary32) format; if pixel_precision is equal to 2 the pixels use a double-precision float (binary64) format; other values may be reserved for a future version of specification. chroma_sampling_idc indicates the chroma sampling for the color component of the main item. When equals to 0, it indicates a 4:4:4 sampling. When equals to 1 , it indicates a 4:2:2: sampling. When equals to 2, it indicates 4:2:0 sampling and when equal to 3, it indicates a monochrome main item. Other values may be reserved for a future version of specification for instance to provide information on the chroma sampling location with respect to the luma samples. full_range corresponds to the value of video_full_range_flag as per ISO / IEC 23091-2.

[0137] A third set of parameters is related to the alpha Minimized Item. has_alpha equals to 1 indicates the presence of alpha information associated with the main image item. The alpha data may be coded as an alpha Item. has_alpha equal to 0 indicates that there is no alpha Item associated with the main item of the Minimized image. The main item image may be considered as opaque. alpha_is_premultiplied equal to 1 indicates that pixels values of the main item are pre-multiplied by the alpha values of the alpha Item. alpha_is_premultiplied equals to 0 indicates that the pixel values of the main item are not pre-multiplied.

[0138] A last set of parameters relates to the dimension of the items in the Minimized Image Box. width_minus_one plus one indicates the width of the main item, and of the alpha item when present, of the Minimized Image Box. height_minus_one plus one indicates the height of the main item, and of the alpha item when present, of the Minimized Image Box.

[0139] Advantageously, the dimensions of the items of the Minimized Image are limited by the maximum size allowed when checking if a condensed description is valid in step 201 of figure 2. The sum of the length in bits of the width_minus_one and height_minus_one syntax elements are constrained to be a multiple of 8 bits in order to ensure a simplified parsing and to ensure that the size of the Minimized Image Header is a multiple of 8 bits to guarantee that data of the main item is byte aligned.

[0140] In the example syntax described above, these parameters are coded using 24 bits. The maximum height and width of the minimized Image are thus 2A12+1 = 4097 pixels. In a variant the maximum height and width of the minimized Image is set to 512 and the width_minus_one and height_minus_one syntax elements are coded on 9 bits. In this variant, some parameters of Minimized Image Header such as the version syntax element coded on 2 bits is not present in order to ensure the Minimized Image header is coded using an integer number of complete bytes.

[0141] The order of the syntax elements is made such that the parameters describing properties of the image with the same semantic context are gathered consecutively. In addition, the parameters that may vary from one Minimized Image to another are provided at the end of the Minimized Header data structure. In the proposed example, the first two bytes of the Minimized Image Header contains parameters that can be used to initialize a decoder of Minimized Images. For example, these two bytes may be provided in a MIME type associated to one media file either in the codecs, profile or itemType parameters. Therefore, it is possible to initiate a decoder of a web-browser from the MIME type associated with the media data: a Picture HTML element may provide the two first bytes of Minimized Image Header in the MIME type of the “type” attribute of the element. In a variant, the full minimized image header may be provided in the MIME type which would allow determining the size of the main item from the MIME type.

[0142] The Minimized Item data structure may have the following syntax: aligned (8) class MinimizedItemData (bit (l) explicit_codec_type ) { bit (12) minimized_item_data_size; bit (12) minimized_config_size; if (explicit_codec_type) { unsigned int (32) infe_type; unsigned int (32) codec_config_type;

[0143] } if (minimized_config_size > 0) { unsigned int (8) config_data [minimized_config_size] ;

[0144] } if (minimized_item_data_size> 0) unsigned int (8) item_data [minimized_item_data_size] ;

[0145] }

[0146] The Minimized Item data structure comprises the data encoding one Minimized Item. When the minimized item is the main item, it corresponds to the encoded value of the pixel values of the minimized Image. When the minimized item is the alpha item, it corresponds to the coded alpha plane.

[0147] When explicit_codec_type equals to 1 , infe_type and codec_config_type parameters are present in the Minimized Item Data. When explicit_codec_type equals to 0, the infe_type and codec_config_type values are not present and are inferred from the major_brand of the FileTypeBox. infe_type indicates the item_type field of the version 2 of the ItemlnfoEntry box i.e. it is a 32-bit value, typically 4 printable characters, that is a defined valid item type indicator, such as 'mime'. codec_config_type indicates the codec configuration box type. For example, ‘hvcC’, ‘avcC’, ‘vvcC’. minimized_item_data_size provides the length in bytes of the coded data of the Minimized item. When equal to 0 it indicates that the Minimized item is not present in the Minimized Image box and should be ignored. The minimized_item_data_size of the main item in a Minimized Image Item may be constrained to be greater than 0 to guarantee that at least one coded image item is provided in a compact description of an image. When minimized_item_data_size equal to 0, the minimized_config_size and explicit_codec_type may be constrained to be equal to 0. minimized_config_size provides the size of the configuration data in the Minimized Item. When equal to 0, it means that no configuration data are provided.

[0148] The minimized_item_data_size and minimized_config_size syntax elements are coded using a fixed length coding to ensure byte alignment of the structure independently of the size of the Minimized item data. In addition, the length of both minimized_config_size and minimized_item_data_size in number of bits may be defined accordingly to the maximum allowed size for the condensed description as determined in step 201. For example, the minimized_item_data_size may be coded using 12 bits to ensure a maximum size of 4096 bytes for the Minimized image items.

[0149] In a variant, the minimized_item_data_size provides the length in bytes of the configuration data and the coded data of the minimized image item. The minimized_config_size corresponds to the length of the configuration data that may be present at the beginning of the item_data. The configuration data are coded in the N first bytes of the item_data array wherein N equals to minimized_config_size. In this variant, the syntax of the Minimized I tern Data may be the following: aligned (8) class MinimizedItemData (bit (l) explicit_codec_type ) { bit (12) minimized_item_data_size; bit (12) minimized_config_size; if (explicit_codec_type) { unsigned int (32) infe_type; unsigned int (32) codec_config_type;

[0150] } if (minimized_item_data_size> 0) unsigned int (8) item_data [minimized_item_data_size_] ;

[0151] } This variant ensures that the total size of the configuration data and the coded data of the item never exceeds the value of minimized_item_data_size.

[0152] The ColourData data structure contains the information related to the colour encoding of the main item. For example, the ColourData data structure may have the following syntax: struct ColourData (bit(2) colour_type) { if (colour_type == 0) { / / sRGB colour space colour_primaries = 1; transfer_characteristics = 13; matrix_coefficients = 6;

[0153] } else if (colour_type == 1) { bit(5) colour_primaries; bit(5) transfer_characteristics; bit(5) matrix_coefficients; bit(l) reserved; / / for byte alignment

[0154] } else if (colour_type == 2) { bit(8) colour_primaries; bit(8) transfer_characteristics; bit(8) matrix_coefficients;

[0155] } else { colour_primaries = 2; transfer_characteristics = 2; bit(8) matrix_coefficients; bit(16) icc_data_size_minus_one; unsigned int (8) icc_data[icc_data_size_minus_one + 1] ;

[0156] }

[0157] }

[0158] In this example, the semantics of the syntax elements of the Colour Data structure is the following:

[0159] The colour_type specifies the colour encoding type. When set to 0, it may indicate that sRGB colour encoding is used. The colour_primaries, transfer_ characteristics, and matrix_coefficient are not present and inferred to 1 , 13 and 6, respectively. When set to 1 or 2, the colour_primaries, transfer_characteristics, and matrix_coefficient are present. When set to 3, it indicates that colour_primaries, transfer_characteristics are not present and both inferred to 2; and also that matrix_coefficients and icc_data are provided in the CoulourData structure, colour_primaries specifies the ColourPrimaries value as defined in ISO / IEC 23091-2. transfer_characteristics specifies the Transfercharacteristics value as defined in ISO / IEC 23091-2. matrix_coefficients specifies the Matrixcoefficients value as defined in ISO / IEC 23091-2. icc_data_size_minus_one plus one specifies the length in bytes of the ICC profile data. icc_data specifies the ICC profile data.

[0160] In a variant the information related to the colour data provided in the Minimized

[0161] Image Header are moved to the ColourData structure. These fields are linked to the colour and may be advantageously gathered with the remaining colour information.

[0162] The new syntax according to this variant may be for example as follows: aligned (8) class MinimizedlmageHeader { bit (2) version; bit (l) has_explicit_codec_types; bit (3) chroma_sampling_idc; bit (l) has_alpha; bit (l) alpha_is_premultiplied; bit (12) width_minus_one; bit (12) height_minus_one;

[0163] } and: struct ColourData ( ) { bit (2) colour_type; bit (l) pixel_format; bit (4) pixel_precision bit (l) full_range; if (colour_type == 0) {

[0164] / / sRGB colour space colour_primaries = 1; transfer_characteristics = 13; matrix_coefficients = 6;

[0165] } else if (colour_type == 1) { bit ( 5) colour_primaries; bit ( 5) transfer_characteristics; bit ( 5) matrix_coefficients; bit (l) reserved; / / for byte alignment

[0166] } else if (colour_type == 2) { bit (8) colour_primaries; bit (8) transfer_characteristics; bit (8) matrix_coefficients;

[0167] } else { colour_primaries = 2; transfer_characteristics = 2; bit (8) matrix_coefficients; bit (16) icc_data_size_minus_one; unsigned int (8) icc_data [icc_data_size_minus_one + 1] ;

[0168] }

[0169] } In a second embodiment, the size of the Minimized Image box may be further reduced by predetermining the values of some parameters present in the Minimized Image header data structure or in the ColourData data structure based on the type (or 4CC) of the Minimized Image Box.

[0170] In a first example, the colour_type attribute of the Minimized Image Box and the presence of alpha item is inferred according to particular values of the MinimizedlmageBox type.

[0171] For example, the MinimizedlmageBox with type ‘mini’, ‘mini’, ‘min2’ and ‘min3’ may infer that the colour_type of the MinimizedlmageHeader (or ColourData) is equal to 0, 1 , 2 and 3 respectively. For example, the syntax of the Minimized image boxes may be the following: aligned(8) class MinimizedlmageBox extends Box( ' mini ' ) {

[0172] MinimizedlmageHeader header() ;

[0173] MinimizedltemData mainltem(header . has_explicit_codec_type) ;

[0174] II ColourData colourData(0) ;

[0175] } aligned(8) class MinimizedlmageBox extends Box(rminl ' ) { MinimizedlmageHeader header() ;

[0176] MinimizedltemData mainltem(header . has_explicit_codec_type) ;

[0177] ColourData colourData(l) ;

[0178] } aligned(8) class MinimizedlmageBox extends Box(rmin2 ' ) { MinimizedlmageHeader header() ;

[0179] MinimizedltemData mainltem(header . has_explicit_codec_type) ;

[0180] ColourData colourData(2) ;

[0181] } aligned(8) class MinimizedlmageBox extends Box(rmin3 ' ) { MinimizedlmageHeader header() ;

[0182] MinimizedltemData mainltem(header . has_explicit_codec_type) ;

[0183] ColourData colourData(3) ;

[0184] }

[0185] In addition, these values of 4CC for the MinimizedlmageBox may indicate the absence of alpha Item. The Minimized Image Header may thus be further simplified and the colour_type and has_alpha parameters are removed from the Minimized Image description.

[0186] The type of the Minimized Image Box may be used to indicate the presence of an alpha Item. For example, the 4CC for the MinimizedlmageBox may be for example ‘miai’ to indicate a Minimized Image with an alpha Item and a colour_type equal to 0. Similarly, the 4CC 'miaT, 'mia2', 'mia3' may indicate a Minimized Image with an alpha Item and a colour_type equal 1 , 2 and 3 respectively. In another variant, the 3rd character of the 4CC may indicate if the pixel values of the image item are pre-multiplied with the alpha value. For instance, an upper case 'A' for this character infers that alpha_is_premultiplied is set to 1 , while a lower case ‘a’ infers its value equals to 0.

[0187] In yet another variant, some parameters of the Minimized Image Header (except the width and the height of the Minimized Image) are coded in the 4CC of the Minimized Image Box. For example, the first bytes of the Minimized Image Header parameters (excluding the parameters specifying the dimension of the items) are coded in the 4CC and thus the corresponding parameter values are inferred from the 4CC value. In that case, the two first characters of the Minimized Image Header 4CC are ‘Ml’ and the two last characters correspond to the two digits of the hexadecimal representation of the first byte of the Minimized Image Header.

[0188] In a third embodiment, a Minimized Metadata Box further describes metadata, typically EXIF or XMP metadata, for an Image in a condensed manner. The Minimized Metadata box is a top-level box that follows the Minimized Image Box. The Minimized Metadata Box consists in a Minimized Metadata Header (or Minimized Metadata Properties) that collects properties or parameters applying to the one Minimized Item present in the Minimized Metadata box. The Minimized Metadata Header describes the version of the box and also the type of the metadata and is encoded using a fixed length to ensure a simple and fast parsing.

[0189] The Minimized Item includes the metadata payload. It reuses the same syntax as the MinimizedltemData data structure for Minimized Image data. This ensures that the metadata size is limited and is not exceeding the threshold for example as defined in step 201.

[0190] For example, the following syntax may be used for the MinimizedMetadataBox with ‘mind’ 4CC for the box type: aligned(8) class MinimizedMetadataBox extends Box( ‘'mind-’ ) {

[0191] MinimizedMetadataHeader header ( ) ;

[0192] MinimizedltemData metadataltem(header .metadata_type == 0) ;

[0193] } struct MinimizedMetadataHeader { bit(2) version; bit(2) metadata_type; 0 : coded explicitly in MinimizedltemData, 1 : exit, 2 : xmp bit(4) reserved; / / for byte alignment

[0194] } The semantics is for example the following: header is the header of the Minimized Metadata. metadataitem is data of the Metadata Minimized Item. metadata_type indicates the type of the metadata. For example, when equal to 0 it indicates that the type of the metadata is explicitly coded in the metadataitem, equal to 1 it indicates EXIF metadata and equal to 2 it indicates XMP metadata.

[0195] The presence of one or more Minimized Metadata Boxes (for example with 'mind' 4CC) after a Minimized Image Box indicates that the Minimized metadata items present in the one or more boxes apply to the Minimized Image described in the MinimizedlmageBox that immediately precedes.

[0196] In a variant, the 4CC of the Minimized Metadata Box may indicate the type of the metadata. This approach may be used when the number of possible types for metadata is limited. For example, if the allowed metadata types in a condensed description are EXIF and XMP only, the 4CC ‘mexf’ may indicate an EXIF Minimized metadata and mxmp an XMP Minimized metadata. The main benefit is that the MinimizedMetadataHeader may be removed from the MinimizedMedataBox which is a more condensed description of the minimized image metadata.

[0197] In another variant, the metadataitem is stored in the Minimized Image box after the main item, the alpha Item and the color data, still using a MinimizedltemData coding structure. The type of the metadata may be provided as a parameter coded in the Minimized Image Header.

[0198] In a fourth embodiment, the presence of a regular or legacy ISOBMFF MetaBox following the Minimized items and Minimized metadata items is allowed. This MetaBox may further specify additional Items or Item properties for more advanced applications. In particular, the MetaBox may be used to specify large size metadata or any other large item that cannot be described as Minimized Metadata.

[0199] This MetaBox is a way to extend the information provided in the Minimized Image boxes. The flags of the MetaBox may be set to 1 when used as an extension of MinimizedMedialtem.

[0200] In a variant, the MetaBox version is set to 1 to indicate that the item represented in the data of the ItemDataBox are coded using Minimized Image Box representation. The ItemDataBox contains the data of items as per ISOBMFF. In a variant, the Minimized Image Box representation is stored in a new item data container instead of the ItemDataBox. This new item data container may be for example CondensedltemDataBox with ‘cdat’ Box type, for example. The syntax of this new CondensedltemDataBox may be for example the following:

[0201] Box Type : ' cdat '

[0202] Container: MetaBox

[0203] Mandatory: No

[0204] Quantity: Zero or one aligned(8) class CondensedltemDataBox extends Box( ' cdat ' )

[0205] {

[0206] MinimizedltemData data(l) ;

[0207] }

[0208] Wherein data contains the data of the coded item.

[0209] As a result, the encapsulation process may be simplified to generate condensed image description from an existing HEIF media file that uses Minimized Image Box representation of item described in a Metabox. The encapsulation process may consist in extraction of the MinimizedlmageBox provided in the CondensedltemDataBox for instance. For ItemDataBox, the extraction process consists thus mainly in extracting the byte range corresponding to the item from the ItemDataBox of the MetaBox with version equal to 1 and generating the appropriate FileTypeBox.

[0210] According to another embodiment, the Minimized Image Box may be defined as follows:

[0211] A MinimizedlmageBox provides a compact description of a Minimized Image that may comprise multiple items. A Minimized Image can be used to describe small image items that can be associated to an image representing one alpha plan carried as an item, colour coding characteristics parameters and one or more metadata items, for example EXIF orXMP metadata items. In other words, A MinimizedlmageBox provides a compact description of one master coded image item and optionally of associated auxiliary image and / or metadata items. The master coded image item is also denoted main item in this disclosure.

[0212] The dimensions of the small image or main item may be limited to 4096x4096 pixels. To ensure the compactness of the description compared to items described in MetaBox the coded data size of each item described in the Minimized Image may be limited to not exceed 16384 bytes. A Minimized Image is represented by five byte-aligned structures of parameters: a Minimizedl mageProperties structure that has a fixed length of 5 bytes and that contains the main parameters related to the minimized image items; a first MinimizedltemData structure that contains the data of the main image item; a second optional MinimizedltemData structure that contains the data of the alpha item when present; a third optional MinimizedltemData structure that contains the data of the metadata item when present; and, a ColourData structure that specifies the colour coding characteristics of the main image item.

[0213] The syntax of the MinimizedlmageBox structure may be for example the following: aligned(8) class MinimizedlmageBox extends Box('mini') {

[0214] MinimizedlmageProperties properties;

[0215] MinimizedltemData mainltem(properties.has_explicit_codec_type, 1);

[0216] MinimizedltemData alphaltem(properties.has_explicit_codec_type, properties. has_alpha);

[0217] MinimizedltemData metadataltem(1 , properties. has_metadata);

[0218] ColourData colourData(properties.colour_type);

[0219] }

[0220] The semantics of the parameters of the MinimizedlmageBox structure is the following: properties are a set of properties describing the minimized image. mainltem contains the data and the codec configuration of the main coded image item. alphaitem contains the data and the codec configuration of coded alpha Item associated to the main coded image item. When the value has_alpha property is equal to 0, the alphaitem is not present. metadataitem contains the data and the configuration of coded metadata Item associated to the main coded image item. When the value has_metadata property is equal to 0, the metadataitem is not present.

[0221] ColourData is the data representing the coding characteristics of the Colours of the main coded image Item

[0222] The MinimizedlmageProperties structure, sometimes called MinimizedlmageHeader, is a condensed description of the image main properties provided as a header at the beginning of the MinimizedlmageBox. It contains parameters which provide information on the coded items of the MinimizedlmageBox. This MinimizedlmageProperties may have the following syntax, for example: aligned(8) class MinimizedlmageProperties { / / (5 bytes) bit(2) version; bit(1) has_explicit_codec_types; bit(2) colour_type; bit(1) pixel_format; bit(4) pixel_precision; bit(2) chroma_sampling_idc; bit(1) full_range; bit(1) has_alpha; bit(1) alpha_is_premultiplied; bit(1) has_metadata; bit(12) width_minus_one; bit(12) height_minus_one;

[0223] } with the following semantics: version indicates the version of the syntax of the MinimizedlmageBox. It is set to 0. Other values are reserved for future versions of the MinimizedlmageBox. has_explicit_codec_types parameter equal to 1 indicates that both infe_type and codec_config_type are explicitly signalled in the MinimizedltemData. When equal to 0 their types are inferred from the major_brand of the FileTypeBox. colour_type specifies the colour encoding type. When set to 0, it indicates that sRGB colour encoding is used. When set to 1 or 2, the colour information is provided in the ColourData structure. When set to 3, it indicates that an ICC Profile is provided in the ColourData structure. pixel_format parameter equal to 0 indicates that the pixel format uses an integer number representation. pixel_format parameter equal to 1 indicates that the pixel format uses a floating-point number representation. pixel_precision specifies the pixel representation depending on the value of pixel_format.

[0224] When pixel_format equals 0, pixel_precision plus one specifies the maximum number of bits used for the values of the pixels channels of the reconstructed items described in the Minimized Image. When pixel_format equals 1 , pixel_precision specifies the format of floating-point numbers used for the pixel values as defined by IEEE 754-2008: when pixel_precision is equal to 0, the pixels use half-precision float (binary 16) format; when pixel_precision is equal to 1 , the pixels use a single-precision float (binary32) format; when pixel_precision is equal to 2, the pixels use a double-precision float (binary64) format. chroma_sampling_idc indicates the chroma sampling for the colour component of the main item. When equals to 0, it indicates a 4:4:4 sampling. When equals to 1 it indicates a 4:2:2: sampling, when equals to 2, it indicates 4:2:0 sampling and when equal to 3 it indicates a monochrome main item. full_range corresponds to the value of video_full_range_flag as per ISO / IEC 23091-2. has_alpha equal to 1 indicates the presence of alpha information associated with the main item. The alpha data is coded as an alpha item. has_alpha equal to 0 indicates that there is no alpha Item associated with the main item of the Minimized image. The main item image may be considered as opaque. alpha_is_premultiplied equal to 1 indicates that pixels values of the main item are pre-multiplied by the alpha values of the alpha item. alpha_is_premultiplied equals to 0 indicates that the pixel values of the main item are not pre-multiplied. has_metadata equal to 1 indicates the presence of metadata information associated with the main item. The metadata payload is coded as an item. has_ metadata equal to 0 indicates that there is no metadata Item associated with the main item of the Minimized image. width_minus_one plus one indicates the width of the main item and, when present, of the alpha item of the MinimizedlmageBox; height_minus_one plus one indicates the height of the main item and, when present, of the alpha item of the MinimizedlmageBox;

[0225] The MinimizedltemData structure contains the encoded data and optionally the configuration of an item. For the main item, it corresponds to the encoded value of the pixel’s values of the minimized Image. For an alpha item, it corresponds to the coded alpha plane. For a metadata item, it corresponds either to XMP or EXIF data. The syntax of the MinimizedltemData structure is for example the following: aligned(8) class MinimizedltemData(bit(1) explicit_codec_type, bit(1) present ) { if (present == 1) { bit(14) minimized_item_data_size ; bit(10) minimized_config_size; if (explicit_codec_type) { unsigned int(32) infe_type; unsigned int(32) codec_config_type;

[0226] } if (minimized_config_size > 0) unsigned int(8) config_data[minimized_config_size]; unsigned int(8) item_data[minimized_item_data_size];

[0227] }

[0228] }

[0229] One difference with previous embodiments is that the MinimizedltemData structure relies in the possibility that all the parameters of the MinimizedltemData may not be signalled conditionally to the value of a present parameter. The value of the present parameter is set for example accordingly to the values of parameters stored in the MinimizedlmageProperties structure such as the has_metadata or has_alpha parameters.

[0230] The semantics of the parameters of the MinimizedltemData are the following: minimized_item_data_size provides the length in bytes of the coded data of the minimized image item. When equal to 0 it indicates that the item is not present (i.e. has no data) and should be ignored. The minimized_item_data_size of the main item is greater or equal to 0. When minimized_item_data_size equal to 0, the minimized_config_size and explicit_codec_type are equal to 0. minimized_config_size corresponds to the length of the configuration that is coded in config_data. When equal to 0, it means that no configuration is provided.

[0231] When explicit_codec_type equals to 1 , the infe_type and codec_config_type parameters are present in the MinimizedltemData structure; When explicit_codec_type equals to 0, the infe_type and codec_config_type are not present and are inferred from the major_brand of the FileTypeBox. infe_type indicates the item_type field of the version 2 of the ItemlnfoEntry box. codec_config_type indicates the codec configuration box type as a 4CC. config_data is a byte array that contains the codec configuration when minimized_config_size is greater than 0. item_data is a byte array that contains the coded data of the item when minimized_item_data_size is greater than 0. For metadata Item, the infe_type and codec_config_type may be constrained to have the following values: for XMP metadata item, the value of infe_type is 'mime' and codec_config_type is 'xmpm' to indicate XMP metadata; for EXIF metadata item, the value of infe_type is 'Exit'. Moreover, the codec_config_type and item_data are respectively defined as exif_tiff_header_offset and exif_payload value as specified in Annex A of ISO / IEC 23008-12.

[0232] The ColourData structure contains the information related to the colour encoding of the main item and may have the following syntax: struct ColourData(bit(2) colour_type) { if (colour_type == 0) {

[0233] / / sRGB colour space colour_primaries = 1; transfer_characteristics = 13; matrix_coefficients = 6;

[0234] } else if (colour_type == 1) { bit(5) colour_primaries; bit(5) transfer_characteristics; bit(5) matrix_coefficients; bit(1) reserved; / / for byte alignment

[0235] } else if (colour_type == 2) { bit(8) colour_primaries; bit(8) transfer_characteristics; bit(8) matrix_coefficients;

[0236] } else { colour_primaries = 2; transfer_characteristics = 2; bit(8) matrix_coefficients; bit(16) icc_data_size_minus_one; unsigned int(8) icc_data[icc_data_size_minus_one + 1];

[0237] } }

[0238] With the following semantics for the parameters provided in this data structure: colour_type specifies the colour encoding type. When set to 0, it may indicate that sRGB colour encoding is used. The colour_primaries, transfer_characteristics, and matrix_coefficient are not present and are inferred to have the value 1 , 13 and 6, respectively. When set to 1 or 2, the colour_primaries, transfer_characteristics, and matrix_coefficient values are present. When set to 3, it indicates that colour_primaries, transfer_characteristics are not present and are both inferred to 2 and also that matrix_coefficients and icc_data are provided in the CoulourData structure. colour_primaries specifies the ColourPrimaries value as defined in ISO / IEC 23091-2. transfer_characteristics specifies the Transfercharacteristics value as defined in ISO / IEC 23091-2. matrix_coefficients specifies the Matrixcoefficients value as defined in ISO / IEC 23091-2. icc_data_size_minus_one plus one specifies the length in bytes of ICC profile data. icc_data specifies the ICC profile data.

[0239] In one embodiment, the content of the codec configuration data may be constrained to not include NAL units. Indeed, the configuration data and the item data are consecutive in memory of the MinimizedltemData. In that case providing NAL units in the configuration data increases unnecessarily the size of the MinimizedltemData since these NAL units are duplicates of the NAL units present in the item data that is stored just after the configuration data. This constraint may be enforced when the number of NAL units of the indicated type included in the configuration record for the stream to which this configuration record applies is set to 0. For example, it corresponds to numNalus is equal to 0 for HEVCDecoderConfigurationRecord or to numArrays is equal to 0 for VVCDecoderConfigurationRecord as per ISO / IEC 14496-15.

[0240] In another embodiment, the MinimizedltemData structure contains only configuration data. The actual coded data for the item (e.g. coded in the item_data array) are not coded in the MinimizedlmageBox but rather in another box that follows this box. This box may be for example a ‘mdat’ or an ‘idat’ box or ‘cdat’ for CondensedltemData box. The box is provided as top level of the media file box hierarchy after the MinimizedltemData box. The order of the item data stored in this box follows the order of the MinimizedlmageBox. As in previous embodiment, the signaling or encoding order of the items in the Minimized Image Box follows the processing order of minimized items for most of the applications. Indeed, the data corresponding to the main item is provided first and then followed by the items providing transparency or alpha information and the metadata information. The advantage of this approach is again to reduce the buffering resources required to process the media file. In a variant, the items may be reordered for specific application: in some applications the render needs to be initialized with transparency information before displaying any image item. In that case the alpha item may be provided prior to the main item.

[0241] In yet another embodiment, the alpha Item may be replaced by an auxiliary item to convey other types of auxiliary components such as depth item data. Since alpha and depth items may be used simultaneously, the MinimizedlmageBox may contain one or more auxiliary item. In that case, the number and the types of the auxiliary item may be specified as one or more properties of MinimizedlmageBox. Therefore, the presence of the auxiliary items may be conditional to the value of these parameters as coded in the MinimizedlmageProperties structure (using similar method as describe for alpha and metadata item in previous embodiments).

[0242] Figure 4 illustrates the main steps in a de-encapsulation process according to some embodiments of the invention.

[0243] First, the media file is parsed in a step 401 to determine in the step 402 the presence of condensed description in the media file. For example, this may be indicated by a specific brand in the FileTypeBox or by the presence of Minimized Image Box.

[0244] When it is determined in step 402 that condensed description is not present, the legacy processing of the MetaBox is performed in a step 409. Otherwise, the processing applies successively each step 403 to 405.

[0245] When the media file comprises condensed description, it means that at least one Minimized Image Box is present in the media file. This Minimized Image Box is parsed in step 403. The parsing of the Minimized Image Header consists in extracting a predetermined number of bytes that correspond to the fix-length size of the Minimized Image Header. Thanks to the optimized encoding of the Minimized Image Header, the values of the parameters describing the image configuration can be determined using solely bit masking and bit shifting operations in step 403. In addition, the data corresponding to the main item can be easily retrieved since it always starts at the same offset position (6thbyte of the box). The de-encapsulation process may also process in parallel each Minimized Item present in the Minimized Image. Indeed, the byte range of each Minimized Item present in the Minimized Image can be determined from the size of the coded data as specified in the different MinimizedltemData structures. When the size is determined equal to 0 or when it is marked as skipped or not present, it indicates that the Minimized Item is not present in the Minimized Image and should be ignored.

[0246] Finally, the de-encapsulation module reconstructs the Minimized Items selected by the application in step 405 by extracting the Minimized Item Data provided in the byte ranges as determined in 403. The decoder of the Minimized Item Data data structure can be initialized by the configuration data provided in the Minimized Item Data data structure when present or inferred from the major_brand of the FileTypeBox according to the explicit_codec_type parameter. Data of each item described by the condensed description may then be provided to a decoder for generating the decoded version of the item data.

[0247] In another embodiment, the encapsulation process generates a condensed description not only for small images but also for larger images. Indeed, even though the condensed description provides better compression ratio for small images (i.e. with a relatively low number of pixels or low coded data (or payload) size), it is still profitable for large images since it reduces the storage space needed for the file.

[0248] The generated condensed description consists in describing in a box representing or describing a Minimized Image (e.g. a Minimized Image Box according to an embodiment of this disclosure, or any box representing a condensed description of an image item), a set of parameters or fields permitting to characterize the dimensions e.g. in pixels, and the size, or payload size, e.g. in bytes, of the image items and also the size, or payload size, e.g. in bytes, of an associated codec configuration. This characterization permits to use a compact coding representation based on a low number of bits for these image attributes. This compact coding representation targets small images and may not be relevant to encode image attributes for larger images, in part due to the size, meaning the number of bits used to encode the values of the parameters or fields dedicated to encode the size of the image. On the contrary, a less compact coding representation is selected when the image and / or codec configuration parameter values correspond to larger images. This less compact coding representation requires a higher number of bits that is not compact enough for small images. The encoding is then based on distinct pre-defined fixed lengths encoding for the image dimensions, for example for the length of the codec configuration, for the length of items or for the length of extended metadata. For example, it allows to handle both small and large images: depending on indicator value for image dimensions, the image width or height may be up to 256 or 16384 pixels.

[0249] The image attributes (e.g. coded size and dimensions) and / or codec configuration attributes may be constrained to be coded on a predetermined number of bits for small images. Upon activation of an extended encoding mode for the image size and dimension, and / or codec configuration size, the number of bits used for encoding these attributes is increased, for example, to a predetermined maximum value. One advantage of this embodiment is that it ensures to select an optimal coding representation for small images and also for larger images.

[0250] In other words, at least two coding modes are defined. Each coding mode defines a coding representation of at least one parameter in the MinimizedlmageBox. The coding representation corresponds to a size in bits allocated for encoding the parameters. Some of the parameters used to describe an image have typically larger values for large images and smaller values for small images. This may be the case for parameters related to the size of the image, typically width, height or data size of the image. Adopting an adapted coding mode, meaning a size in bits of the field used to encode the parameter, allows optimizing the size of the media files based on some characteristics of the encapsulated images. Some other parameters have values in the same range for small and large images. Depending on these characteristics of encapsulated images, some parameters may have values in a range normally associated with a small image while other parameters may have values in a range normally associated with a large image. Accordingly, it may be advantageous to consider different sets of parameters by adopting a coding representation adapted to small images for some set of parameters and another one for another set of parameters.

[0251] Accordingly, different indicators may be defined. Each indicator is associated with a set of parameters. Each indicator indicates a coding mode for the parameters of the associated set (for example a number of bits onto which the value of a parameter is encoded). This does not mean that all the parameters of the set are encoded on the same number of bits. This means that all the parameters of the set are encoded on a number of bits adapted to the indicated coding mode. In other words, the coding mode defines the number of bits to be used for encoding the value of the parameter for each parameter of the associated set of parameters. These indicators may be simple one bit flag if only two coding modes (e.g. pre-defined fixed length bits) are used. If more coding modes are used, the indicators may be encoded using more than one bit. For example, an indicator coded on two bits may be used for indicating one coding mode among four different coding modes (or four different fixed length bits).

[0252] The indicators are provided in the MinimizedlmageBox. According to embodiments, the indicators may be present in the MinimizedlmageHeader structure or in the MinimizedlmageProperties structure, or directly in the MinimizedlmageBox, typically at the beginning of the MinimizedlmageBox.

[0253] As a result, the condensed description of the image provides parameters that allows the file parser determining that extended processing resources are required to process the image file. The parser therefore can allocate the appropriate resources in advance by determining if the condensed description applies for a small or a larger image.

[0254] For this embodiment, the encapsulation step 102, which determines whether condensed description is used, is modified to allow using a condensed description for images that may be considered as invalid in other embodiments. The processing is modified to describe either small or large images while maintaining a condensed description for the image.

[0255] The steps 200 to 206 include additional processing steps that consist in determining whether the image dimensions or the lengths of the image components can be represented using a first predetermined number of bits. This first predetermined number of bits is used by default and is mainly targeting small images. When the image is larger than a first predetermined threshold and lower than a second predetermined threshold, a second predetermined number of bits is used. This second number is greater than the first number. When the image exceeds the second threshold, the condensed description cannot be used and is considered as invalid (step 208).

[0256] For the image dimension parameters, it is checked if the width and height of the images minus one can be encoded using a first predetermined number of bits, for example equal to 8 bits. When either width or / and height value requires more bits than this predetermined number, an extended coding representation based on a second predetermined number of bits, for example 28 bits, is selected. When either the width or / and the height value cannot be encoded using this second predetermined number of bits, the image or picture is considered as invalid for a condensed description in step 201, and a classical encapsulation as an image item according to HEIF (High Efficiency Image File Format) standard may be considered. Otherwise, the process continues with the processing loop applied for each component of image as in previous embodiments.

[0257] In this processing loop, the step 205 is changed to determine the appropriate coding representation for the parameters related to the component signalled in the Minimized Image Box or any box representing a condensed description of an image item. They may correspond to the parameters encoded in the Minimized Item Data such as the length of the configuration data and / or of the item data. As for the image dimensions, it is determined for each parameter value whether a compact representation, which is based on a first predetermined number of bits, can be used to encode the value or if a second predetermined number of bits corresponding to an extended representation bit is required. If the parameter value cannot be represented using the compact or the extended coding representation the image component cannot be represented using condensed description and thus is marked as invalid in a step 206 and a classical encapsulation as an image item according to HEIF (High Efficiency Image File Format) standard may be considered.

[0258] Based on this determination, the step 106 of generating the condensed description in the encapsulation process is modified to signal the coding representation determined during the checking step 102. As a result, the Minimized Image Box or any box representing a condensed description of an image item, includes parameters permitting to determine the coding representation (e.g., compact or extended coding representation) used for the parameter values encoding the image dimension, and the lengths of data coded for each minimized item and its associated codec configuration.

[0259] The parsing process or the de-encapsulation process depicted in figure 4 is modified and includes a determination step of the coding representation for the parameters indicating the image dimensions and lengths of coded data associated with a minimized item and its codec configuration in step 403. The media file parser may use the indication of the coding representation to allocate the processing resources necessary to process the media file. In particular, the information indicating the coding representation for each of the parameter indicating the image dimension and the length of the coded data in an image item permits to determine whether the image is small or large.

[0260] The coding representation is determined from the indicators or fields or control flags provided in the Minimized Image box, or the box representing a condensed description of an image item. In one embodiment, the encapsulation process may indicate that the media file contains a small image by providing the brand ‘miac’ in the compatible_brands of the media file. The presence of this brand mandates the presence of a MinimizedlmageBox, or a box representing a condensed description of an image item, with constraint that the coding representations used in the box for the image and / or codec configuration attributes are compact coding representation. To use the most compact representation of an image with the MinimizedlmageBox, it is recommended that the corresponding indicator values are set to 0, especially for small images.

[0261] As a result, when this brand (for example ‘miac’), is present in the media file all the images described by the condensed description have constraints that limit the image dimension and the lengths of the data coded in the MinimizedlmageBox or in the box representing a condensed description of an image item. In condensed HEIF, items are alternatively represented as a set of parameters describing these items and a payload, both in the MinimizedlmageBox (e.g. ‘mini’) box instead of being described in a ItemlnfoEntry and having their payload in a media data box and another box to associate the item to a data part.

[0262] All the described embodiments are based on the described MinimizedlmageBox, it must be clear that these embodiments apply more generally to any box representing a condensed description of an image item (whatever its name or 4CC used as the box type).

[0263] In one embodiment, the MinimizedlmageBox (or any box representing a condensed description of an image item) comprises three indicators indicating the coding mode characteristics of three sets of parameters values. The first set of parameters contains the parameters encoding the image dimensions such as the parameters specifying the width and the height of the image. The second set of parameters contains the parameters specifying the length of the configuration data (e.g. codec configuration data) of the image components. For example, it includes the configuration data of the main item and of the alpha item.

[0264] The third set of parameters may contain the parameters encoding the length of the data coded in the condensed image description (payload size). For example, the data coded includes the data of the main item, the data of the alpha item, the data of the color data profile (e.g. ICC data), the data of the metadata items (EXIF or XMP) and the data of the additional boxes (provided in the extended_meta parameters) associated with the image signalled using condensed image description. The Minimized Image Box may specify one coding mode indicator for each of the three sets of parameters. The indicator may take for example two values. The length in bits used to code parameters in each set is determined accordingly to the value of the parameter. For example, when the indicator equals to 0, it indicates that a compact coding mode is used for the parameters of the sets and the length in bits for coding the parameters is set equal to a first predetermined number of bits. On the contrary when the indicator equals to 1 , it indicates an extended coding mode and the length in bits for coding the parameters is set equal to a second predetermined number of bits. The second predetermined number of bits is greater than the first one in order to represent larger images.

[0265] The following function, for example called “f”, permits to determine the coding representation, meaning the number of bits of the field used to code the coded parameters according to the value of the indicator associated with each set of parameters. unsigned int(8) function f(bit(1) extended_flag, unsigned int(8) def, unsigned int(8) max) { if (extended_flag == 1) return max return def

[0266] }

[0267] The function takes three parameters as input and returns the length in bits of the coding representation used for the coded parameter. The first input parameter named extended_flag is a binary value that corresponds to the indicator associated with the sets of parameters. The parameter “def” is the first predetermined number of bits for the compact coding representation. The parameter “max” is the second predetermined number of bits for the extended coding representation. The parameter “def” may also be considered as a default number of bits to encode a parameter or field of the minimized image box.

[0268] The syntax of the MinimizedlmageBox or the MinimizelmageProperties or any box representing a condensed description of an image item, may include the following indicators or parameters for example: aligned(S) class MinimizedlmageBox extends Box('mini') { bit(1) extension = 0; bit(1) extended_dim; / / 1stindicator bit(1) extendedjtem; / / 2ndindicator bit(1) extended_conf; 113rdindicator unsigned int(f(extended_dim, 8, 14)) width_minus_one; unsigned int(f(extended_dim, 8, 14)) height_minus_one;

[0269] [...] / / other parameters not represented unsigned int(f(extended_item, 10, 28)) icc_data_size_minus_one;

[0270] [...] / / other parameters not represented unsigned int(f(extended_conf, 4, 10)) main_item_codec_config_size; unsigned int(f(extended_item, 10, 28)) main_item_data_size_minus_one;

[0271] [...] / / other parameters not represented unsigned int(f(extended_conf, 4, 10)) alpha_item_codec_config_size; unsigned int(f(extended_item, 10, 28)) alpha_item_data_size; unsigned int(f(extended_item, 10, 28)) extended_meta_size_minus_one; unsigned int(f(extended_item, 10, 28)) exif_data_size_minus_one; unsigned int(f(extended_item, 10, 28)) xmp_data_size_minus_one; trailing_bits();

[0272] / / coded data

[0273] }

[0274] With the following semantics: extension indicates the version of the syntax of the MinimizedlmageBox. It is set to 0. Other values are reserved for future versions of the MinimizedlmageBox. extended_dim is an indicator indicating the coding representation used for the image width and height parameters. These parameters correspond to the first set of parameters. When extended_dim equals to 0, it indicates a compact coding representation and that width_minus_one and height_minus_one are coded using fixed length coding on a default number of bits for example equal to 8 bits. When extended_dim equals to 1 it indicates an extended coding representation and that width_minus_one and height_minus_one are coded using fixed length coding on an extended number of bits for example equal to 14 bits. extendedjtem is an indicator indicating the coding representation used for specifying the size of coded data corresponding to the ICC profile data, the main item data, the alpha item data if present, the metadata payload (e.g. EXIF and XMP coded metadata payload) if present and the size of additional boxes associated with the condensed image. These parameters correspond to the third set of parameters. When extendedjtem equals to 0, it indicates a compact coding representation and that icc_data_size_minus_one, mainjtem_data_size_minus_one, alphajtem_data_size, exif_data_size_minus_one, xmp_data_size_minus_one and extended_meta_size_minus_one are coded using fixed length coding on a default number of bits for example equal to 10 bits. When extendedjtem equals to 1 it indicates an extended coding representation and that icc_data_size_minus_one, mainjtem_data_size_minus_one, alphajtem_data_size, exif_data_size_minus_one, xmp_data_size_minus_one and extended_meta_size_minus_one are coded using fixed length coding on an extended number of bits for example equal to 28 bits. extended_conf is an indicator indicating the coding representation used for the codec configuration parameters. These parameters correspond to the second set of parameters. When extended_conf equals to 0, it indicates a compact coding representation and that mainjtem_codec_config_size, alphajtem_codec_config_size_one are coded using fixed length coding on a default number of bits for example equal to 4 bits. When extended_conf equals to 1 it indicates an extended coding representation and that mainjtem_codec_config_size, alphajtem_codec_config_size, when present, are coded using fixed length coding on an extended number of bits for example equal to 10 bits.

[0275] The trailing_bits() function is a function that provides up to 7 trailing bits equal to 0 to ensure that the coded data that follows the parameters coded at the beginning of the MinimizedlmageBox (or after the MinimizedlmageProperties structure) are byte aligned.

[0276] The semantics of extension, extended_dim, extendedjtem, extended_conf or trailing_bits() may apply to any box representing a condensed description of an image item and including an alternative between compact coding representation and extended coding representation of the parameters. In a variant of this embodiment, the indicator indicating the coding representation used for the image width and height parameters is replaced by two independent indicators: one is used for the coding of the image width parameter and the second indicator is used for the height parameter. The advantage of this variant is that it allows optimizing the signaling of the image dimension when the image dimensions is bigger in one direction (e.g. width) and shorter in another direction (e.g. height).

[0277] In another embodiment, the MinimizedlmageBox or any box representing a condensed description of an image item, comprises four indicators indicating the coding representation characteristics of four sets of parameters values instead of three sets. The first set of parameters contains the parameters encoding the image dimension such as the parameters specifying the width and the height of the image. The second set of parameters may contain the parameters specifying the length of the configuration data (e.g. codec configuration data) of the image components.

[0278] The third set of parameters may contain the parameters encoding the length of the data coded in the image item except the metadata payload (e.g. for EXIF or XMP data). For example, the data of a main item, an alpha item or the color data profile described in the box.

[0279] The fourth set of parameters may contain the parameters encoding the length of the data coded in the metadata item. The advantage of this embodiment is to allow having different coding representations for image data (e.g., main and alpha items) and for metadata payload. It applies, for example, when the length of the main item is compact (forexample when highly compressed or when the image dimensions are small) and when the associated metadata are verbose (e.g. using lengthy XMP description). Compared to the previous embodiment, the parameters encoding the length of the data coded in the metadata item are excluded from the third set to constitute a fourth set of parameters.

[0280] For example, the syntax of the MinimizedlmageBox may include the following parameters: aligned(8) class MinimizedlmageBox extends Box('mini') { bit(1) extension = 0; bit(1) extended_dim; / / 1stindicator bit(1) extendedjtem; / / 2ndindicator bit(1) extended_conf; 113rdindicator bit(1) extended_metadata; 114thindicator unsigned int(f(extended_dim, 8, 14)) width_minus_one; unsigned int(f(extended_dim, 8, 14)) height_minus_one; unsigned int(f(extended_item, 10, 28)) icc_data_size_minus_one; unsigned int(f(extended_conf, 4, 10)) main_item_codec_config_size; unsigned int(f(extended_item, 10, 28)) main_item_data_size_minus_one; unsigned int(f(extended_conf, 4, 10)) alpha_item_codec_config_size; unsigned int(f(extended_item, 10, 28)) alpha_item_data_size; unsigned int(f(extended_item, 10, 28)) extended_meta_size_minus_one; if (has_exif or has_xmp) { unsigned int(f(extended_metadata, 10, 28)) exif_data_size_minus_one; unsigned int(f(extended_metadata, 10, 28)) xmp_data_size_minus_one;

[0281] } trailing_bits();

[0282] }

[0283] The semantics of the parameters may be changed as follows compared to the previous embodiment: extended_item is an indicator indicating the coding representation used for specifying the size of coded data corresponds to the ICC profile data, the main item data, the alpha item data, corresponding to the third set of parameters. When equal to 0, it indicates a compact coding representation and that icc_data_size_minus_one, main_item_data_size_minus_one, alpha_item_data_size, and extended_meta_size_minus_one are coded using fixed length coding on a default number of bits for example equal to 10 bits. When equal to 1 it indicates an extended coding representation and that icc_data_size_minus_one, main_item_data_size_minus_one, alpha_item_data_size and extended_meta_size_minus_one are coded using fixed length coding on an extended number of bits for example equal to 28 bits. extended_metadata is an indicator indicating the coding representation used to specify the size of coded data corresponding the metadata payload (e.g., EXIF and XMP coded metadata payload) corresponding to the fourth set of parameters. When equal to 0, it indicates a compact coding representation and that exif_data_size_minus_one and xmp_data_size_minus_one are coded using fixed length coding on a default number of bits for example equal to 10 bits. When equal to 1 it indicates an extended coding representation and that exif_data_size_minus_one and xmp_data_size_minus_one are coded using fixed length coding on an extended number of bits for example equal to 28 bits.

[0284] In a variant, the presence of the extended_metadata is conditional to the presence of a metadata item (e.g. EXIF or XMP metadata). The signaling of the extended_metadata may be present when has_metadata is set equal to 1 only. In that case, the has_metadata parameter is signalled before extended_metadata.

[0285] The semantics of extension, extended_dim, extendedjtem, extended_conf or extended_metadata may apply to any box representing a condensed description of an image item and including an alternative between compact coding representation and extended coding representation of the parameters.

[0286] In another embodiment, the MinimizedlmageBox, or any box representing a condensed description of an image item, comprises five indicators indicating the coding representation characteristics of five sets of parameters values instead of four sets. The first set of parameters contains the parameters encoding the image dimension such as the parameters specifying the width and the height of the image. The second set of parameters may contain the parameters specifying the length of the configuration data (e.g. codec configuration data) of the image components except the metadata payload (e.g. for EXIF or XMP data).

[0287] The third set of parameters may contain the parameters encoding the length of the data coded in a main item described by the box.

[0288] The fourth set of parameters may contain the parameter encoding the length of the data coded in a metadata item(s) described by the box.

[0289] The fifth set of parameters may contain the parameter encoding the length of the data coded in an alpha item described by the box. The advantage of this embodiment is to allow having different coding representations for the main item, the alpha item and for metadata payload. It applies for example when the length of the main item is compact (for example when highly compressed or when the image dimensions are small), and when the alpha item or the associated metadata are less compact.

[0290] In a variant, the presence of the extended_alpha, extended_metadata and extended_meta may be conditional to the presence of corresponding coded data in the box.

[0291] The syntax of the MinimizedlmageBox, or any box representing a condensed description of an image item, may become the following for example: aligned(8) class MinimizedlmageBox extends Box('mini') { bit(1) extension = 0; bit(1) has_alpha bit(1) has_xmp bit(1) has_exif bit(1) extended_dim; / / first indicator bit(1) extendedjtem; 11 second indicator bit(1) extended_conf; / / third indicator if (has_xmp || has_exif) { bit(1) extended_metadata; / / fourth indicator

[0292] } if (has_alpha) { bit(1) extended_alpha; / / fifth indicator

[0293] } unsigned int(f(extended_dim, 8, 14)) width_minus_one; unsigned int(f(extended_dim, 8, 14)) height_minus_one; unsigned int(f(extended_item, 10, 28)) icc_data_size_minus_one; unsigned int(f(extended_conf, 4, 10)) main_item_codec_config_size; unsigned int(f(extended_item, 10, 28)) main_item_data_size_minus_one; if (has_alpha) { unsigned int(f(extended_conf, 4, 10)) alpha_item_codec_config_size; unsigned int(f(extended_alpha, 10, 28)) alpha_item_data_size;

[0294] } unsigned int(f(extended_item, 10, 28)) extended_meta_size_minus_one; if (has_exif) { unsigned int(f(extended_metadata, 10, 28)) exif_data_size_minus_one;

[0295] } if (has_xmp) { unsigned int(f(extended_metadata, 10, 28)) xmp_data_size_minus_one;

[0296] } trailing_bits();

[0297] }

[0298] The semantics of the parameters may be changed as follows compared to the previous embodiment: extended tem is an indicator indicating the coding representation used to specify the size of coded data corresponding to the ICC profile data and the main item data. When equal to 0, it indicates a compact coding representation and that icc_data_size_minus_one, main_item_data_size_minus_one, and extended_meta_size_minus_one are coded using fixed length coding on a default number of bits for example equal to 10 bits. When equal to 1 it indicates an extended coding representation and that icc_data_size_minus_one, main_item_data_size_minus_one, and extended_meta_size_minus_one are coded using fixed length coding on an extended number of bits for example equal to 28 bits. extended_alpha is an indicator indicating the coding representation used to specify the size of coded data corresponding to the alpha item data. When equal to 0, it indicates a compact coding representation and that alpha_item_data_size_minus_one is coded using fixed length coding on a default number of bits for example equal to 10 bits. When equal to 1 it indicates an extended coding representation and that alpha_item_data_size_minus_one is coded using fixed length coding on an extended number of bits for example equal to 28 bits.

[0299] The semantics of extension, extended_dim, extendedjtem, extended_conf, extended_metadata or extended_alpha may apply to any box representing a condensed description of an image item and including an alternative between compact coding representation and extended coding representation of the parameters.

[0300] In another embodiment, the number of sets and therefore of indicators may be increased in order that one additional set provides coding representation indication for color profile data different than the set specifying the size of the coded data of a main item. The presence of the parameters associated to this set may be conditional to the presence of ICC profile data accordingly to the value of the color_type parameter provided in the MinimizedlmageBox.

[0301] In yet another embodiment, the number of sets and therefore of indicators may be increased in order that one additional set provides coding representation indication for the size of coded boxes coded in the extended_meta structure different than the set specifying the size of the coded data of the main item. Similarly, to the previous embodiment, the presence of the parameters associated to this set may be conditional to the presence of the extended meta structure. The extended meta structure is present when has_extended_meta parameter is equal to 1.

[0302] For example, a MinimizedlmageBox, or any box representing a condensed description of an image item with the following syntax may be a combination of the two previous embodiments: aligned(8) class MinimizedlmageBox extends Box('mini') { bit(1) extension = 0; bit(1) has_alpha; bit(1) has_xmp; bit(1) has_exif; bit(1) has_extended_meta; bit(1) extended_dim; / / first indicator bit(1) extendedjtem; / / 2nd indicator bit(1) extended_conf; 113rd indicator if (colour_type >= 3) { bit(1) extended_icc_data; / / 4th indicator

[0303] } if (has_xmp || has_exif) { bit(1) extended_metadata; / / 5thindicator } if (has_alpha) { bit(1) extended_alpha; / / 6th indicator

[0304] } if (has_extended_meta) { bit(1) extended_ext_meta; / / 7th indicator } unsigned int(f(extended_dim, 8, 14)) width_minus_one; unsigned int(f(extended_dim, 8, 14)) height_minus_one; unsigned int(f(extended_icc_data, 10, 28)) icc_data_size_minus_one; unsigned int(f(extended_conf, 4, 10)) main_item_codec_config_size; unsigned int(f(extended_item, 10, 28)) main_item_data_size_minus_one; unsigned int(f(extended_conf, 4, 10)) alpha_item_codec_config_size; if (has_alpha) { unsigned int(f(extended_alpha, 10, 28)) alpha_item_data_size; } if (has_extended_meta) { unsigned int(f(extended_ext_meta, 10, 28)) extended_meta_size_minus_one;

[0305] } if (has_exif) { unsigned int(f(extended_metadata, 10, 28)) exif_data_size_minus_one; } if (has_xmp) { unsigned int(f(extended_metadata, 10, 28)) xmp_data_size_minus_one;

[0306] } trailing_bits(); } The semantics of the parameters may be changed as follows compared to the previous embodiment: extended_item is an indicator indicating the coding representation used to specify the size of coded data corresponding to the main item data. When equal to 0, it indicates a compact coding representation and main_item_data_size_minus_one is coded using fixed length coding on a default number of bits for example equal to 10 bits. When equal to 1 it indicates an extended coding representation and that main_item_data_size_minus_one, is coded using fixed length coding on an extended number of bits for example equal to 28 bits. extended_icc_data is an indicator indicating the coding representation used to specify the size of coded data corresponding to the ICC profile data. When equal to 0, it indicates a compact coding representation and that icc_data_size_minus_one is coded using fixed length coding on a default number of bits for example equal to 10 bits. When equal to 1 it indicates an extended coding representation and that icc_data_size_minus_one is coded using fixed length coding on an extended number of bits for example equal to 28 bits. extended_ext_meta is an indicator indicating the coding representation used to specify the size of coded data in the extended_meta structure. When equal to 0, it indicates a compact coding representation and that extended_meta_size_minus_one is coded using fixed length coding on a default number of bits for example equal to 10 bits. When equal to 1 it indicates an extended coding representation and that extended_meta_size_minus_one is coded using fixed length coding on an extended number of bits for example equal to 28 bits.

[0307] The semantics of extension, extended_dim, extended tem, extended_conf, extended_metadata, extended_alpha, extended_icc_data or extended_ext_meta may apply to any box representing a condensed description of an image item and including an alternative between compact coding representation and extended coding representation of the parameters.

[0308] In a variant with an increased number of indicators, the syntax is defined as follows: unsigned int(8) function f(bit(1) extended_flag, unsigned int(8) def, unsigned int(8) max) { if (extended_flag == 1) return max return def

[0309] } aligned(8) class MinimizedlmageBox extends Box('mini') { bit(1) extension = 0; bit(1) extended_dim; / / first indicator bit(1) extendedjtem; 11 second indicator bit(1) extended_conf; / / third indicator int bit_num_dimension = f(extended_dim, 8, 14); int bit_num_main_item = f(extended_item, 10, 28); int bit_num_config = f(extended_conf, 4, 10); bit(1) has_extended_meta; bit(1) has_exif; bit(1) has_xmp; bit(1) has_alpha; bit(2) colour_type; if (colour_type >= 3) { bit(1) extended_icc_data; 11 fourth indicator int bit_num_icc_data = f(extended_icc_data, 10, 28);

[0310] } if (has_xmp || has_exif) { bit(1) extended_metadata; / / fifth indicator int bit_num_metadata = f(extended_metadata, 10, 28);

[0311] } if (has_alpha) { bit(1) extended_alpha; / / sixth indicator int bit_num_alpha_item = f(extended_alpha, 10, 28);

[0312] } if (has_extended_meta) { bit(1) extended_ext_meta; / / seventh indicator int bit_num_meta = f(extended_ext_meta, 10, 28); } unsigned int(bit_num_dimension) width_minus_one; unsigned int(bit_num_dimension) height_minus_one;

[0313] / / Colour and bit-depth bit(1) is_float; if (is_float) { bit(2) float_precision;

[0314] } else { bit(4) bit_depth_minus_one;

[0315] } bit(2) subsampling; if (subsampling >= 2) { bit(1) is_centered;

[0316] } bit(1) full_range; if (colour_type == 0) { colour_primaries = 1; transfer_characteristics = 13; if (subsampling > 0) { matrix_coefficients = 6;

[0317] } else { matrix_coefficients = 2;

[0318] }

[0319] } else if (colour_type == 1) { bit(5) colour_primaries; bit(5) transfer_characteristics; if (subsampling > 0) { bit(5) matrix_coefficients; } else { matrix_coefficients = 2;

[0320] }

[0321] } else if (colour_type == 2) { bit(8) colour_primaries; bit(8) transfer_characteristics; if (subsampling > 0) { bit(8) matrix_coefficients;

[0322] } else { matrix_coefficients = 2;

[0323] }

[0324] } else { colour_primaries = 2; transfer_characteristics = 2; if (subsampling > 0) { bit(8) matrix_coefficients;

[0325] } else { matrix_coefficients = 2;

[0326] } unsigned int(bit_num_icc_data) icc_data_size_minus_one;

[0327] }

[0328] / / Item metadata bit(1) has_explicit_codec_types; if (has_explicit_codec_types) { unsigned int(32) infe_type; unsigned int(32) codec_config_type;

[0329] } unsigned int(bit_num_config) main_item_codec_config_size; unsigned int(bit_num_main_item) main_item_data_size_minus_one; / / Other items if (has_alpha) { bit(1) alpha_is_premultiplied; unsigned int(bit_num_config) alpha_item_codec_config_size; unsigned int(bit_num_alpha_item) alpha_item_data_size;

[0330] } boolean has_separate_alpha_item=has_alpha && alpha_item_data_size>0; if (has_extended_meta) { unsigned int(bit_num_meta) extended_meta_size_minus_one;

[0331] } bit(1) has_exif; if (has_exif) { unsigned int(bit_num_metadata) exif_data_size_minus_one;

[0332] } bit(1) has_xmp; if (has_xmp) { unsigned int(bit_num_metadata) xmp_data_size_minus_one;

[0333] }

[0334] / / Pad bits until byte-aligned trailing_bits();

[0335] / / Payload data

[0336] / / Codec config body data for alpha and main if (has_alpha && alpha_item_codec_config_size > 0) { unsigned int(8) alpha_item_codec_config[alpha_item_codec_config_size];

[0337] } unsigned int(8) main_item_codec_config[main_item_codec_config_size];

[0338] / / Extended 'meta' box if (has_extended_meta) { unsigned int(8) extended_meta[extended_meta_size_minus_one + 1];

[0339] }

[0340] / / ICC profile data if (colour_type == 3) { unsigned int(8) icc_data[icc_data_size_minus_one + 1];

[0341] }

[0342] / / Alpha and main elementary stream payloads if (has_separate_alpha_item) { unsigned int(8) alpha_data[alpha_item_data_size];

[0343] } unsigned int(8) main_data[main_item_data_size_minus_one + 1];

[0344] / / Metadata payloads if (has_exif) { unsigned int(8) exif_data[exif_data_size_minus_one + 1];

[0345] } if (has_xmp) { unsigned int(8) xmp_data[xmp_data_size_minus_one + 1];

[0346] }

[0347] }

[0348] And the semantics is defined as follows: extension indicates the version of the MinimizedlmageBox. The current version is set to 0. Other values are reserved for future extension of the MinimizedlmageBox. extended_dim specifies the number of bits used to encode the image dimensions: width and height parameters. When equal to 0, it indicates that width_minus_one and height_minus_one are coded using fixed length coding on a compact number of bits equal to 8 bits. When equal to 1, it indicates that width_minus_one and height_minus_one are coded using fixed length coding on an extended number of bits equal to 14 bits. extended_item specifies the number of bits used to encode the size, in bytes, of the coded data corresponding to the main item data (in other words the size of the image payload). When equal to 0, it indicates that main_item_data_size_minus_one is coded using fixed length coding on a compact number of bits equal to 10 bits. When equal to 1, it indicates that main_item_data_size_minus_one is coded using fixed length coding on an extended number of bits equal to 28 bits. extended_conf specifies the number of bits used to encode the size, in bytes, of the codec configuration parameters. When equal to 0, it indicates that main_item_codec_config_size and, alpha_item_codec_config_size_one, when alpha plane is present, are coded using fixed length coding on a compact number of bits equal to 4 bits. When equal to 1 , it indicates that main_item_codec_config_size and alpha_item_codec_config_size, when alpha plane is present, are coded using fixed length coding on an extended number of bits equal to 10 bits. extended_icc_data specifies the number of bits to encode the size, in bytes, of the coded data corresponding to the ICC profile data. When equal to 0, it indicates that icc_data_size_minus_one is coded using fixed length coding on a compact number of bits equal to 10 bits. When equal to 1 , it indicates that icc_data_size_minus_one is coded using fixed length coding on an extended number of bits equal to 28 bits. When not present, extended_icc_data is inferred equal to 0. extended_metadata specifies the number of bits to encode the size, in bytes, of the coded data corresponding to metadata (e.g., the size of the EXIF and / or XMP payload) associated to the image item. When equal to 0, it indicates that exif_data_size_minus_one and xmp_data_size_minus_one are coded using fixed length coding on a compact number of bits equal to 10 bits. When equal to 1 , it indicates that exif_data_size_minus_one and xmp_data_size_minus_one are coded using fixed length coding on an extended number of bits equal to 28 bits. When not present, extended_metadata is inferred equal to 0. extended_alpha specifies the number of bits to encode the size, in bytes, of the coded data corresponding to the alpha data (in other words the payload size of the alpha item). When equal to 0, it indicates that alpha_item_data_size is coded using fixed length coding on a compact number of bits equal to 10 bits. When equal to 1 , it indicates that alpha_item_data_size is coded using fixed length coding on an extended number of bits equal to 28 bits. When not present, alpha_item_data_size is inferred equal to 0. extended_ext_meta specifies the number of bits to encode the size, in bytes, of coded data in the extended_meta field. When equal to 0, it indicates that extended_meta_size_minus_one is coded using fixed length coding on a compact number of bits equal to 10 bits. When equal to 1 , it indicates that extended_meta_size_minus_one is coded using fixed length coding on an extended number of bits equal to 28 bits. When not present, extended_ext_meta is inferred equal to 0. width_minus_one specifies the width minus one of the reconstructed image in pixels, as specified in lmageSpatialExtentsProperty.height_minus_one specifies the height minus one of the reconstructed image in pixels, as specified in ImageSpatialExtentsProperty. is_float specifies whether float_precision or bit_depth_minus_one is signalled. If is_float is set to 1 , it indicates that the float_precision is signalled, otherwise bit_depth_minus_one is signalled. float_precision specifies the format of floating-point numbers used for the pixel values as defined by IEEE 754-2008. The values 0, 1 , and 2 correspond to half-precision float (binary16), single-precision float (binary32), and double-precision float (binary64) formats, respectively. Other values are reserved for a future specification. When is_float is set to 0, the value is undefined. bit_depth_minus_one indicates the number of bits, minus one, per channel for the pixels of the reconstructed main and alpha image items, as specified in PixellnformationProperty. subsampling when set to 0, indicates that there is exactly one channel of coded colour samples, as specified by the num_channels field of the PixellnformationProperty. When set to a non-zero value it indicates that there are exactly three channels of coded colour samples. A value of 1 indicates that there is no subsampling of chroma (i.e. 4:4:4). A value of 2 indicates that chroma is subsampled by a factor 2 horizontally (i.e. 4:2:2). A value of 3 indicates that chroma is subsampled both horizontally and vertically by a factor 2 (i.e. 4:2:0). If has_alpha is 1 and alpha_item_codec_config_size is 0, the number of channels will be two and four respectively. is_centered 0 indicates that the chroma samples are co-located with the luma samples. A value of 1 indicates that the chroma samples are centered between the luma samples. full_range carries a VideoFullRangeFlag value as defined in ISO / IEC 23091-2 colour_type specifies the colour encoding type. When set to 0 it indicates the default values of MIAF (1 / 13 / 6). When set to 1 or 2 it implies the on-screen colours as signalled in ColourlnformationBox with colour_type='nclx'. When set to 3 it indicates that an ICC Profile and matrix coefficients are present. colour_primaries carries a ColourPrimaries value as defined in ISO / IEC 23091-2 transfer_characteristics: carries a Transfercharacteristics value as defined in ISO / IEC 23091-2 matrix_coefficients carries a Matrixcoefficients value as defined in ISO / IEC 23091-2 icc_data_size_minus_one: specifies the size of ICC profile data minus one when the colour_type field indicates it is present in bytes. Undefined if the value of colour_type is not equal to 3. has_explicit_codec_types when set to 1 indicates that both infe_type and codec_config_type are explicitly signalled, otherwise their types are implied from the major_brand of the FileTypeBox. It is set to 1 if major_brand does not explicitly specify their default values. infe_type corresponds to the item_type field of the version 2 of the ItemlnfoEntry box. Defined by the major brand if has_explicit_codec_types is set to 0. codec_config_type corresponds to the codec configuration box type. Defined by the major brand if has_explicit_codec_types is set to 0. main_item_codec_config_size specifies the size of the configuration for the main image item. main_item_data_size_minus_one specifies the size minus one of the data for the main image item in bytes. has_alpha when set to 0 indicates that the image is opaque, otherwise the image has an alpha layer, whether the codec has native translucency support, or an auxiliary image item is used. alpha_is_premultiplied when set to 1 indicates that main values are pre-multiplied by alpha, otherwise main values are not pre-multiplied. alpha_item_codec_config_size specifies the size of the configuration for the alpha image item in bytes. When set to 0 indicates that the codec does not need any configuration data for alpha or can reuse the one from the main image. The value is set to 0 if has_alpha is 0. alpha_item_data_size specifies the size of the data for the alpha image item in bytes. If has_alpha is set to 1 , the value 0 indicates that the codec has native translucency support and that the alpha samples are coded alongside the colour samples in the main_data chunk. Zero if has_alpha is not set to 1. has_extended_meta when set to 1 indicates the presence of extended metadata within the Minimized! mageBox, otherwise it indicates the absence of it. extended_meta_size_minus_one specifies the size minus one of the extended metadata in bytes. Undefined if has_extended_meta is not set to 1 . has_exif when set to 1 indicates the presence of an Exit metadata chunk, otherwise it indicates the absence of it. exif_data_size_minus_one specifies the size minus one of the Exif metadata in bytes. -1 if has_exif is not set to 1 . has_xmp when set to 1 indicates the presence of an XMP metadata chunk, otherwise it indicates the absence of it. xmp_data_size_minus_one specifies the size minus one of the XMP metadata in bytes. -1 if has_xmp is not set to 1. trail ing_bits padding bits to ensure payloads are 8-bit aligned. Shall be 0. alpha_item_codec_config specifies the optional alpha image codec configuration data. When has_alpha is set to 0 or alpha_item_codec_config_size is 0, alpha_item_codec_config is not present. main_item_codec_config specifies the main image item codec configuration data. When main_item_codec_config_size is 0, main_item_codec_config is not present. extended_meta specifies the optional extended metadata. When has_extended_meta is set to 0 extended_meta is not present. icc_data specifies the optional ICC profile data. When colour_type is not set to 3 icc_data is not present. alpha_data specifies the optional alpha image data. When has_alpha is set to 0 or alpha_item_data_size is 0, alpha_data is not present. main_data specifies the main image data. exif_data specifies the optional Exif metadata. When has_exif is set to 0 exif_data is not present. xmp_data specifies the optional XMP metadata. When has_xmp is set to 0 xmp_data is not present.

[0349] It is to be noted that in this variant, as well as in the different embodiments, the predefined fixed lengths, as a minimum and maximum number of bits and their use, controlled by the indicator are examples. Different ranges may be used. For example, the values (10, 28) for the extended_meta indicator could also be (8, 24). Ideally, the combination of the ranges in use for the different indicators should be determined so that the cumulated bits minimizes the number of trailing bits (ideally 0 to avoid wasting bits).

[0350] In another embodiment, instead of indicating only two possible coding modes (i.e. compact and extended coding representation) for each set of parameters, the encapsulation process specifies an index of coding mode with an array of predetermined number of bits. As a result, several possible coding modes that correspond to different coding representations may be used to encode the set of parameters.

[0351] For example, the function “f” that permits to determine the length of the coded parameters according to the value of the indicator associated with each set of parameters may be changed to the following: unsigned int(8) function f(bit(2) coding_rep_index, unsigned int(8) bit_num[])

[0352] { return bit_num[coding_rep_index];

[0353] }

[0354] The function takes two parameters as input and returns the length in bits of the coding representation used for the coded parameter. The first input parameter is the indicator named coding_rep_index, which has an integer value that corresponds to the coding representation value associated with each set of parameters. The parameter “bit_num” parameter is an array of predetermined number of bits for the coding representation.

[0355] As a result, the Minimized I mageBox, or any box representing a condensed description of an image item, may contain the following syntax to specify the dimensions of the image. In this example, the possible coding representation for the image dimensions are either 6-bit, 8-bit, 11 -bit or 14-bit length coding representation.

[0356] Same principle can be used for the other parameters described in previous embodiment. aligned(8) class MinimizedlmageBox extends Box('mini') { bit(1) extension = 0; bit(2) coding_rep_dim;

[0357] [...] / / other parameters not represented unsigned int(f(coding_rep_dim, [6, 8, 11 , 14])) width_minus_one; unsigned int(f(coding_rep_dim, [6, 8, 11 , 14])) height_minus_one;

[0358] [...] / / other parameters not represented }

[0359] In another embodiment the predetermined number of bits for the coding representation is predefined accordingly to the compatible brand specified in the media file. For example, the syntax of a Minimized Image Box, or any box representing a condensed description of an image item, may be the following: aligned(S) class MinimizedlmageBox extends Box('mini') {

[0360] [...] / / other parameters not represented unsigned int(f(extended_dim, dim_min, dim_max)) width_minus_one; unsigned int(f(extended_dim, dim_min, dim_max)) height_minus_one; unsigned int(f(extended_icc_data, icc_min, icc_max)) icc_data_size_minus_one; unsigned int(f(extended_conf, conf_min, conf_max)) main_item_codec_config_size; unsigned int(f(extended_item, item_min, item_max)) main_item_data_size_minus_one; bit(1) has_alpha; if (has_alpha) { unsigned int(f(extended_conf, conf_min, conf_max)) alpha_item_codec_config_size; unsigned int(f(extended_alpha, alpha_min, alpha_max)) alpha_item_data_size;

[0361] } bit(1) has_extended_meta; if (has_extended_meta) unsigned int(f(extended_ext_meta, meta_min, meta_max)) extended_meta_size_minus_one; bit(1) has_exif; if (has_exif) unsigned int(f(extended_metadata, metadata_min, metadata_max)) exif_data_size_minus_one; bit(1) has_xmp; if (has_xmp) unsigned int(f(extended_metadata, metadata_min, metadata_max)) xmp_data_size_minus_one; trailing_bits();

[0362] }

[0363] The values of dim_min, dim_max, icc_min, icc_max, conf_min, conf_max, item_min, item_max, alpha_min, alpha_max, meta_min, meta_max, metadata_min and metadata_max are constrained to predetermined value accordingly to the brand provided in the compatible brand. For example, when the compatible brands include the ‘mid’ brand, dim_min is equal to 8, dim_max is equal to 14; icc_min, item_min, alpha_min, metadata_min and meta_min are equal to 10 and icc_max, item_max, alpha_max, metadata_max, and meta_max are equal to 28; conf_min is equal to 4 and conf_max is equal to 10.

[0364] The values for the different parameters can be pre-determined to ensure that median or average values for the parameters can be represented with the compact representation coding representation, and that larger images under a pred-determined threshold are represented using the extended coding representation.

[0365] In another embodiment, the presence of the ‘miac’ brand in the compatible brands may enforce the use of compact coding representation in the Minimized Image Box of the media file for one or more indicators. For example, one target of the condensed image description is small images for example in terms of byte length. As a result, the presence of the ‘miac’ brand may constrain that the value of extendedjtem is equal to 0 indicating a small image requiring minimal amount of resources for parsing process. This ensures that main item image has a small size. As a first example, the constraint may apply to all indicators representing the coding representation of size in bits or bytes. For example, the constraint may be that the value of extendedjtem, extended_metadata, extended_ext_meta and extended_alpha are constrained to be equal to 0 indicating a small image requiring minimal amount of resources for parsing process. In yet another example, the presence of the ‘miac’ brand constrains that the extendedjtem, extended_metadata, extended_ext_meta and extended_alpha, extended _dim and extended_conf are set equal to 0. In this embodiment, the presence of the brand is the indicator of the coding mode, which is provided in the ISOBMFF based media file instead of directly in the Minimized Image box.

[0366] In another embodiment the MinimizedltemData structure of a MinimizedlmageBox contains the encoded data and optionally the configuration of an item without any information indicating their sizes.

[0367] One difference with previous embodiments is that the MinimizedltemData structure relies on the MinimizedlmageProperties of the MinimizedlmageBox to determine the sizes of encoded data and configuration data. The sizes can be equal to 0 to indicate the absence of either of the data set. In addition, the MinimizedltemData provides the possibility that all the parameters of the MinimizedltemData may not be signalled conditionally to the value of a present parameter. The value of the present parameter is set for example accordingly to the values of parameters stored in the MinimizedlmageProperties data structure constituting the header of the MinimizedlmageBox. It is reminded that the MinimizedlmageProperties may also be named MinimizedlmageHeader.

[0368] The syntax of the MinimizedltemData may be the following for example: aligned(8) class MinimizedltemData(bit(1) present, unsigned int(8) config_size, unsigned int(8) data_size)

[0369] { if (present == 1) { if (config_size > 0) unsigned int(8) config_data[config_size]; if (data_size > 0) unsigned int(8) item_data[data_size];

[0370] }

[0371] }

[0372] The syntax of the MinimizelmageProperties may be the following with the same semantics as described in previous embodiments. aligned(8) class MinimizedlmageProperties { bit(1) extension = 0; bit(1) extended_dim; bit(1) extendedjtem; bit(1) extended_conf; int bit_num_dimension = f(extended_dim, 8, 14); int bit_num_main_item = f( extendedjtem, 10, 28); int bit_num_config = f(extended_conf, 4, 10); bit(1) has_extended_meta; bit(1) has_exif; bit(1) has_xmp; bit(1) has_alpha; if (colour_type >= 3) { bit(1) extended_icc_data; int bit_num_icc_data = f(extended_icc_data, 10, 28);

[0373] } if (has_xmp || has_exif) { bit(1) extended_metadata; int bit_num_metadata = f(extended_metadata, 10, 28);

[0374] } if (has_alpha) { bit(1) extended_alpha; int bit_num_alpha_item = f(extended_alpha, 10, 28);

[0375] } if (has_extended_meta) { bit(1) extended_ext_meta; int bit_num_meta = f(extended_ext_meta, 10, 28);

[0376] } unsigned int(bit_num_dimension) width_minus_one; unsigned int(bit_num_dimension) height_minus_one;

[0377] / / Colour and bit-depth bit(1) is_float; if (is_float) { bit(2) float_precision;

[0378] } else { bit(4) bit_depth_minus_one;

[0379] } bit(2) subsampling; if (subsampling >= 2) { bit(1) is_centered;

[0380] } bit(1) full_range; bit(2) colour_type; / / Item metadata bit(1) has_explicit_codec_types; if (has_explicit_codec_types) { unsigned int(32) infe_type; unsigned int(32) codec_config_type;

[0381] } unsigned int(bit_num_config) main_item_codec_config_size; unsigned int(bit_num_main_item) main_item_data_size_minus_one;

[0382] / / Other items if (has_alpha) { bit(1) alpha_is_premultiplied; unsigned int(bit_num_config) alpha_item_codec_config_size; unsigned int(bit_num_alpha_item) alpha_item_data_size;

[0383] } if (has_extended_meta) { unsigned int(bit_num_meta) extended_meta_size_minus_one;

[0384] } if (has_exif) { unsigned int(bit_num_metadata) exif_data_size_minus_one;

[0385] } if (has_xmp) { unsigned int(bit_num_metadata) xmp_data_size_minus_one;

[0386] }

[0387] / / Pad bits until byte-aligned trailing_bits();

[0388] }

[0389] The syntax of the MinimizedlmageBox may be for example the following with the same semantics as in previous embodiments: aligned(8) class MinimizedlmageBox extends Box('mini') { MinimizedlmageProperties properties;

[0390] ColourData colourData(properties.colour_type);

[0391] MinimizedltemData alphaltem(properties.has_alpha, properties. alpha_item_codec_config_size, properties. alpha_item_data_size);

[0392] MinimizedltemData mainltem(0, properties. main_item_codec_config_size, properties. main_item_data_size_minus_one+1);

[0393] MinimizedltemData extMeta(properties.has_extended_meta,

[0394] 0, properties. extended_meta_size_minus_one+1);

[0395] MinimizedltemData exifltem(properties.has_exif,

[0396] 0, properties. exif_data_size_minus_one+1);

[0397] MinimizedltemData xmpltem(properties.has_exif,

[0398] 0, properties. xmp_data_size_minus_one);

[0399] }

[0400] It is to be noted that from the above embodiments, since the proposed indicators are independent, any selection or combination can also be described in the condensed image description. For example, a condensed image description may only contain the indicator for the parameters encoding the length of the data coded in the image items. There may be from one indicator controlling the coding mode for the whole set of parameters up to one indicator per parameter for which the coding mode is controlled. Also to be noted, even if some examples indicate first, second, ... indicator, the declaration order may be different than one used in the different examples.

[0401] In another embodiment, alternative signalling order for the minimized image items coded in a Minimized! mageBox , or any box representing a condensed description of an image item and its associated items (e.g. alpha image item, metadata item...), is signalled at the beginning of the box (e.g. in a header part, at the beginning of the payload part or in a MinimizedlmageProperties structure. The signalled parameter is for example an integer or a flag. The value of the parameter indicates a predetermined order for the items described by the box or the structures after the MinimizedlmageProperties. For example, when the parameter is equal to 0, the order of the items is the following: color data, alpha item, main image item, and when present extended meta item, exif metadata and finally xmp metadata; when the parameter is equal to 1 , the order of the item is main image item, and when present alpha item, extended meta item, exif metadata, xmp metadata and finally color data. Defining the order of the items in the box may permit indicating the expected processing order for the media parser file. For example, in some applications, processing the alpha item first allows initializing the rendering area of the decoded images. On the contrary, some application may need the content of the main item to start the rendering. This embodiment can be combined with any of the prior embodiments.

[0402] In a variant, the parameter signalling the order indicates only two possible arrangements for the items. For example, the first arrangement provides the alpha item prior to the main item; the second arrangement provides the main item prior to the alpha item. In that case the parameter may be a flag that when equal to 0 indicates that the first arrangement is used; when equal to 1 it indicates that the second arrangement is used. In another variant, using an integer parameter, more than two possible arrangements are authorized.

[0403] Figure 5 is a schematic block diagram of a computing device 500 for implementation of one or more embodiments of the invention. The computing device 500 may be a device such as a micro-computer, a workstation or a light portable device. The computing device 500 comprises a communication bus connected to:

[0404] - a central processing unit 501 , such as a microprocessor, denoted CPU;

[0405] - a random access memory 502, denoted RAM, for storing the executable code of the method of embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the method according to embodiments of the invention, the memory capacity thereof can be expanded by an optional RAM connected to an expansion port for example;

[0406] - a read only memory 503, denoted ROM, for storing computer programs for implementing embodiments of the invention;

[0407] - a network interface 504 is typically connected to a communication network over which digital data to be processed are transmitted or received. The network interface 504 can be a single network interface, or composed of a set of different network interfaces (for instance wired and wireless interfaces, or different kinds of wired or wireless interfaces). Data packets are written to the network interface for transmission or are read from the network interface for reception under the control of the software application running in the CPU 501 ;

[0408] - a graphical user interface 505 may be used for receiving inputs from a user or to display information to a user;

[0409] - a hard disk 506 denoted HD may be provided as a mass storage device;

[0410] - an I / O module 507 may be used for receiving / sending data from / to external devices such as a video source or display.

[0411] The executable code may be stored either in read only memory 503, on the hard disk 506 or on a removable digital medium such as for example a disk. According to a variant, the executable code of the programs can be received by means of a communication network, via the network interface 504, in order to be stored in one of the storage means of the communication device 500, such as the hard disk 506, before being executed.

[0412] The central processing unit 501 is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to embodiments of the invention, which instructions are stored in one of the aforementioned storage means. After powering on, the CPU 501 is capable of executing instructions from main RAM memory 502 relating to a software application after those instructions have been loaded from the program ROM 503 or the hard-disc (HD) 506 for example. Such a software application, when executed by the CPU 501 , causes the steps of the flowcharts of the invention to be performed.

[0413] Any step of the algorithms of the invention may be implemented in software by execution of a set of instructions or program by a programmable computing machine, such as a PC (“Personal Computer”), a DSP (“Digital Signal Processor”) or a microcontroller; or else implemented in hardware by a machine or a dedicated component, such as an FPGA (“Field-Programmable Gate Array”) or an ASIC (“Application-Specific Integrated Circuit”).

[0414] Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a skilled person in the art which lie within the scope of the present invention. Many further modifications and variations will suggest themselves to those versed in the art upon making reference to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention, that being determined solely by the appended claims. In particular the different features from different embodiments may be interchanged, where appropriate.

[0415] Each of the embodiments of the invention described above can be implemented solely or as a combination of a plurality of the embodiments. Also, features from different embodiments can be combined where necessary or where the combination of elements or features from individual embodiments in a single embodiment is beneficial. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.

Claims

CLAIMS1. A method of encapsulating an image into an ISOBMFF based media file, the method comprising, by a computing device, the steps of:- obtaining parameters describing the image;- generating a file level box comprising the parameters and image data; wherein the method further comprises:- generating at least one indicator, each indicator being associated with a set of the parameters describing the image, each indicator indicating a coding mode for encoding the parameters of the associated set of parameters; and embedding the at least one indicator and the file level box in the media file.

2. The method of claim 1 , wherein the at least one indicator is a brand indication in the media file.

3. The method of claim 1, wherein the at least one indicator is provided among the parameters describing the image.

4. The method of claim 1, wherein the length of the parameters describing the image has a predefined value depending on the at least one indicator values.

5. The method of claim 1, wherein the at least one indicator are three indicators associated with:- a first set of parameters comprising parameters encoding the image dimensions;- a second set of parameters comprising parameters specifying the length of configuration data associated with the image data; and- a third set of parameters comprising parameters specifying the length of the image data.

6. The method of claim 1, wherein the file level box comprises metadata, and wherein the at least one indicator are four indicators associated with:- a first set of parameters comprising parameters encoding the image dimensions;- a second set of parameters comprising parameters specifying the length of configuration data associated with the image data;- a third set of parameters comprising parameters specifying the length of the image data; and- a fourth set of parameters comprising parameters specifying the length of the metadata.

7. The method of claim 1, wherein the file level box comprises metadata and alpha data, and wherein the at least one indicator are five indicators associated with:- a first set of parameters comprising parameters encoding the image dimensions;- a second set of parameters comprising parameters specifying the length of configuration data associated with the image data;- a third set of parameters comprising parameters specifying the length of the image data; and- a fourth set of parameters comprising parameters specifying the length of the metadata;- a fifth set of parameters comprising parameters specifying the length of the alpha data.

8. The method of claim 1, wherein the parameters describing the image are embedded in a MinimizedlmageHeader data structure in the file level box.

9. The method of claim 1, wherein the file level box may further comprise alpha data and may further comprise metadata; and wherein the image data, the alpha data if any, and the metadata if any, are embedded in respective MinimizedlmageData data structures in the file level box.

10. A method of obtaining an image from an ISOBMFF based media file, the method comprising, by a computing device, the steps of:- obtaining a file level box from the media file comprising the image data and parameters describing the image;- obtaining from the media file at least one indicator, each indicator being associated with a set of the parameters describing the image, each indicator indicating a coding mode for encoding the parameters of the associated set of parameters;- decoding the parameters describing the image based on the at least one indicator value;- obtaining the image based on the decoded parameters.

11. A computer program product for a programmable apparatus, the computer program product comprising a sequence of instructions for implementing a method according to any one of claims 1 to 10, when loaded into and executed by the programmable apparatus.

12. A computer-readable storage medium storing instructions of a computer program for implementing a method according to any one of claims 1 to 10.

13. A computer program which upon execution causes the method of any one of claims 1 to 10 to be performed.

14. A device for encapsulating an image into an ISOBMFF based media file, the device comprising a processor configured for:- obtaining parameters describing the image;- generating a file level box comprising the parameters and image data; wherein the method further comprises:- generating at least one indicator, each indicator being associated with a set of the parameters describing the image, each indicator indicating a coding mode for encoding the parameters of the associated set of parameters; and- embedding the at least one indicator and the file level box in the media file.

15. A device for obtaining an image from an ISOBMFF based media file, the device comprising a processor configured for:- obtaining a file level box from the media file comprising the image data and parameters describing the image;- obtaining from the media file at least one indicator, each indicator being associated with a set of the parameters describing the image, each indicator indicating a coding mode for encoding the parameters of the associated set of parameters; - decoding the parameters describing the image based on the at least one indicator value;- obtaining the image based on the decoded parameters.

Images