Method and apparatus for compact image encapsulation with compressed accompanying non-pixel data

Abstract

A method for encapsulating an image in an ISOBMFF-based media file is described. The method comprises obtaining data of an image, obtaining property information data of a first property associated wit

Description

FIELD OF THE DISCLOSURE The present disclosure concerns methods and devices for encapsulating one or more images in an ISOBMFF-based media file, and associated methods and devices for parsing the media file. It concerns more particularly the definition of enhanced image encapsulation methods and enhanced encapsulation formats to reduce the size of the ISOBMFF-based media file. The present disclosure finds particular applications in the HEIF format, and more particularly in the low-overhead image file format of HEIF particularly adapted for the encapsulation of small images. BACKGROUND OF THE DISCLOSURE 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 - arrays of pixel values - are typically encoded to reduce the size of data on the storage device. Many encoding standards may be used, like JPEG, AV1, or the Moving Picture Experts Group (MPEG) video standards like AVC, HEVC or VVC. Some MPEG video standards define profiles for the encoding of still images and describe specific tools for compressing single still images or bursts or sequences of still images. An extension of the ISO Base Media File Format (ISOBMFF or ISO / IEC 14496-12) used for such kind of image data has been proposed as ISO / IEC 23008-12 standard, under the name: “HEIF” for “High Efficiency Image File Format”. HEIF is a standard image format developed by MPEG for storage and sharing of image items or image sequences. AVIF is another image format, developed by the Alliance for Open Media, that also relies on HEIF and ISOBMFF but for AV1-coded images. For example, images on the Web may be indicated as HEIF or AVIF images, depending on the actual codec in use. The pixel data or payload of the image (i.e., the pixels of the image or an encoded or compressed version of these pixels) is stored as one or more contiguous sets (or ranges) of bytes (known as “extents” or “data chunks” or “chunks”) in one or more dedicated media (or item) data boxes ‘mdat’ (for media data box) or ‘imda’ (for identified media data box) or ‘idat’ (for item data box). The image together with thumbnails are described using iteminfoEntry boxes in an iteminfoBox box within a top-level MetaBox box. Indeed, an image is considered as an “item” in the meaning of ISOBMFF, also denoted “image item” in HEIF, because it is made of data which does not require timed processing, as opposed to sample data. An image has often accompanying information or data that is associated with the image. Accompanying data include image or item properties describing the image item, e.g. width and height of the image, and transformations affecting the image, e.g. a rotation. An item property designates descriptive or transformative information about an item as stored in an item properties array. The item properties are described using item property boxes in an ItemPropertyContainerBox box (‘ipco’), the item property boxes being associated with the image item via an ItemPropertyAssociationBox box (‘ipma’). Both ItemPropertyContainerBox box and ItemPropertyAssociationBox box are embedded into an ItemPropertiesBox box (‘iprp’) within the top-level MetaBox box. Other types of accompanying data are made of pixel data. Accompanying pixel data are often pixel (or pixel-like) array data, and more particularly pixel array data that are spatially correlated with the pixel data of the image. This may include a pixel to pixel correspondence or a pixel to block correspondence. This is for example the case of auxiliary images (such as an alpha plane or depth map) or high dynamic range (HDR) images (such as a gain map or tone map) which complement the image, often at pixel level. Such accompanying pixel data are made of a 2D array of pixels (i.e., pixel matrix structured data whose dimensions are equal to or higher than 2x2) usually stored in the media data (‘mdat’, ‘imda’ or ‘idat’) box or boxes. Yet other types of accompanying data are made of non-pixel data (non-pixel-array data). These are often structured data, i.e., data that have a standardized format, e.g. based on tags. This is the case of image metadata, such as EXIF metadata, XMP metadata. These non-pixel data are mono-dimensional structured data. They may be stored in the media data (‘mdat’, ‘imda’ or ‘idat’) box or boxes. These exemplary accompanying data do not require timed processing. Items in the meaning of ISOBMFF can thus be used to describe respectively the various types of accompanying data. For example, auxiliary image items, image metadata items, and so on, can be used. A link between each item and its corresponding data in the media data (‘mdat’, ‘imda’ or ‘idat’) box or boxes is made via a box known as itemLocationBox box, located in the top-level MetaBox box. Other accompanying non-pixel data associated with the image are handled as properties attached to the image item. This is the case of decoder configuration information or colour information (e.g. colour depth, colour space, ICC profile) or high dynamic range (HDR) metadata, which are stored in item property boxes in the ItemPropertyContainerBox box. For some Web usages, the HEIF format is considered too verbose, especially for small images. For example, an encapsulated image file, as an HEIF or AVIF file, may consist in more than 200 bytes of description for an image actually representing few bytes, in terms of image data. That is why HEIF has recently introduced a low-overhead image file format which does not rely on the “item” boxes (iteminfoEntry in iteminfoBox) or on the item property boxes in the ItemPropertyContainerBox box but on a minimized image box known as MinimizedimageBox which provides a more compact representation of the MetaBox box and its hierarchy of boxes including the iteminfoEntry boxes and ItemPropertyContainerBox box for a subset of use cases. The low-overhead image file format is particularly adapted for the encapsulation of small and simple images where the full MetaBox box would result in considerable overhead compared to the image data payload. This low-overhead image file format may be referred below to as “slimHEIF” or “compactHEIF” for ease of description, to be opposed to the “regular HEIF” relying on the “item” boxes. SlimHEIF regroups, within the MinimizedimageBox box, the image data with accompanying (hence associated) data. Some accompanying data are provided in the MinimizedimageBox box as “chunks”, i.e., as contiguous sets (or ranges) of bytes. The pixel data (image data and auxiliary / HDR image data) can be compressed together, which common compression may be signalled through a dedicated flag within control flags, namely expiicit_codec_types_f lag or may be inferred (when expiicit_codec_types_f iag=o) from a specific brand, like the ‘mif3’ brand The present disclosure aims at further improving the compactness of the HEIF media files, being based on the regular HEIF format and the slimHEIF format. SUMMARY OF THE DISCLOSURE The present disclosure has been devised to address one or more of the foregoing concerns. In particular, the inventors have noticed that the known HEIF formats does not allow some accompanying non-pixel data to be compressed. In HEIF, the compression of the accompanying pixel data (e.g., alpha plane payload and the HDR (High Dynamic Range) gain map) is dependent on the compression of the image data: if the image data are compressed, the accompanying pixel data are also compressed to be included in the media file; if the image data are not compressed (but raw), the accompanying pixel data are also not compressed to be included in the media file. However, this is not the case for the accompanying non-pixel data such as the EXIF, XMP or some HDR or colour configuration information. As other accompanying non-pixel data, there may be image format metadata types as declared in ISO / IEC 23007-2 and contained as an SEI (Supplemental Enhancement Information) message in an image bitstream. Within this context, the present disclosure intends to extend the HEIF capability to allow more accompanying data to be compressed independently to the image data. Indeed, regular HEIF does not provide efficient signalling that accompanying data are compressed, beyond the compression of the image data and dependent accompanying pixel data and beyond the specific compressions of the ‘mime’ item and the EXIF metadata. Similarly, slimHEIF does not provide any signalling that a chunk (e.g. a byte range) corresponding to accompanying data is compressed, beyond the compression of the image data and dependent accompanying pixel data such as the alpha map and HDR gain map. In this respect, the disclosure proposes a method for encapsulating an image in an ISOBMFF-based media file, the method comprising in a processing device: obtaining data of an image; obtaining accompanying non-pixel data associated with the image that are compressed, and generating a single box that includes the obtained image data and the compressed accompanying non-pixel data. This box, typically a minimized image box such as MinimizedimageBox, can therefore be included in the ISOBMFF-based media file, typically a slimHEIF file. The obtaining of the compressed accompanying non-pixel data may include obtaining uncompressed non-pixel data and compressing them. By targeting the compression on non-pixel data independently to the image data compression, more accompanying data can be compressed in slimHEIF. This is particularly advantageous to reduce the size of the resulting slimHEIF file. The present disclosure also proposes a method for processing data, the method comprising in a processing device: obtaining an ISOBMFF-based media file encapsulating media data of an image, obtaining, from the ISOBMFF-based media file, a single box that includes data of the image and compressed accompanying non-pixel data associated with the image, and processing the compressed accompanying non-pixel data. Optional features are defined below with reference to methods, while they can be transposed into device features. Also, the features below that add signalling when encapsulating the media data can be used in the reverse way to parse the media file and decompress the payloads. In some embodiments, the image data and accompanying non-pixel data are obtained from an HEIF or ISOBMFF media file, wherein the accompanying non-pixel data are described by an item associated with an image item describing the image or are provided in an item property box associated with the image item. In this configuration, the accompanying non-pixel data are byte ranges or data chunks, or extents, forming the ‘mdat’ or ‘imda’ or ‘idat’ boxes in case of associated items or are payloads stored in ‘ipco’ boxes in case of associated properties. The above method can therefore allow a regular HEIF file to be converted into an enhanced slimHEIF file. In some embodiments, the single box includes a signalling that the accompanying non-pixel data are compressed. In some embodiments, the signalling includes at least one flag that takes a first value in a case where the accompanying non-pixel data are not compressed in the single box or a second value in a case where the accompanying non-pixel data are compressed in the single box. In some embodiments, the signalling includes one or more fields to indicate compression parameters used for compressing the accompanying non-pixel data. In some embodiments, one of the compression parameters indicate a compression scheme selected from a group of schemes that includes one or more of: a first scheme where uncompressed accompanying non-pixel data corresponding to two or more separate accompanying data elements are separately compressed, a second scheme where uncompressed accompanying non-pixel data corresponding to two or more separate accompanying data elements are combined and compressed as a single chunk (or payload or byte-range), a third scheme where uncompressed accompanying non-pixel data corresponding to accompanying data elements located before the image data in the single box are combined and compressed as a single first chunk, while uncompressed accompanying non-pixel data corresponding to accompanying data elements located after the image data in the single box are combined and compressed as a single second chunk, and a fourth scheme where uncompressed accompanying non-pixel data of an adjustable number of accompanying data elements are combined and compressed as a single payload. Two accompanying data elements may or not differ one from the other by a different type of accompanying data, e.g. EXIF vs. XMP. In some embodiments, the one or more compression parameters fields are included in the single box only if the signalling flag takes the second value indicating the accompanying non-pixel data are compressed. In some embodiments, a signalling is provided in the single box per each accompanying data element corresponding to accompanying non-pixel data provided in the single box. In some embodiments, a flag for signalling the compression of the accompanying non-pixel data is provided in the single box only if a presence flag of the accompanying non-pixel data is set to true. In some embodiments, the compression signalling flag and the presence flag of the accompanying non-pixel data belongs to the same binary field in the single box. In some embodiments, the compression signalling flag and the presence flag of the accompanying non-pixel data are two separate binary fields in the single box. In some embodiments, the signalling includes one compression signalling flag (e.g. one-bit flag) common to all types of accompanying data element corresponding to accompanying non-pixel data provided in the single box or to all types of a plurality of accompanying data elements corresponding to accompanying non-pixel data provided in the single box. In some embodiments, the signalling is provided within control flags of a MinimizedimageBox box in the meaning of ISO / IEC 23008-12:2024 / CDAM 2:2024. In some embodiments, the obtaining of the compressed accompanying non-pixel data includes obtaining uncompressed non-pixel data and compressing them. In some embodiments, the accompanying non-pixel data to compress are selected based on a predefined criterion, such as a predefined list of accompanying data element types or a size threshold to be compared to a hypothetical maximum size of the uncompressed non-pixel data given an accompanying data element type, or when the size of the uncompressed non-pixel data does not fit in the pre-defined number of bits to encode this non-pixel data size (e.g. the field “few_metadata_bytes_flag” in slimHEIF). This allows some accompanying data elements that are worth being compressed to save bits, to be known in advance by the processing device. Such accompanying data elements may be chosen based on the potential maximum size of their non-pixel data. In some embodiments, multiple accompanying data elements are associated with the image; uncompressed accompanying non-pixel data corresponding to each accompanying data element are compressed separately; and the single box includes a size indication of the size of each separately compressed non-pixel data of the multiple accompanying data elements. In some embodiments, multiple accompanying data elements are associated with the image; uncompressed accompanying non-pixel data corresponding to all the accompanying data elements are combined and compressed as a single payload; and the single box includes a size indication of the size of each uncompressed accompanying non-pixel data within the single payload (preferably in the same order as the combination order of uncompressed data into the single payload for compression). In some embodiments, the single box includes a first subset of one or more accompanying data elements located before the image data in the single box and a second subset of one or more accompanying data elements located after the image data in the single box; and uncompressed accompanying non-pixel data of the accompanying data elements of the first subset are combined and compressed as a single first payload while uncompressed accompanying non-pixel data of the accompanying data elements of the second subset are combined and compressed as a single second payload. In some embodiments, multiple accompanying data elements are associated with the image; a subset of the accompanying data elements is signalled in the single box; and uncompressed accompanying non-pixel data of the accompanying data elements of the subset are combined and compressed as a single payload. In some embodiments, the single box is a MinimizedimageBox box in the meaning of ISO / IEC 23008-12:2024 / CDAM 2:2024 (which is the standard of the slimHEIF format). In other aspects, the disclosure proposes a method for encapsulating an image in an ISOBMFF-based media file, the method comprising in a processing device: obtaining data of an image; obtaining accompanying non-pixel data associated with the image that are compressed, generating a multi-box structure to include the obtained image data and the compressed non-pixel data, wherein a first box of the multi-box structure declares a first item describing the image and a second and separate box that is associated with the first box describes an accompanying data element corresponding to the compressed accompanying non-pixel data, wherein the multi-box structure includes a signalling that the accompanying non-pixel data described by the second box are compressed, the signalling being performed via one of the following options: a compression configuration property in an item property box associated with the second box; an item_type equal to ‘uri ’ in the second box, combined with an item_uri_type in the second box set to a dedicated value signalling a compression of the accompanying non-pixel data; a dedicated item_type in the second box that signals compression of any type of data element corresponding to accompanying non-pixel data (e.g. any item type); signalling that the second box describes a derived item from a third box declaring a third item that also describes the accompanying non-pixel data, wherein the second box indicates, as derivation operation, a decompression scheme corresponding to a scheme used to compress the accompanying non-pixel data; the presence of the second box in a second list within a Container (e.g. iteminfoBox or itemPropertiesBox) box, wherein the Container box has a version value that defines the box as including a first list of boxes describing accompanying non-pixel data that are not compressed and the second list of boxes, as a separate list, describing accompanying non-pixel data that are compressed; including, within a link box that links the second box to the accompanying non-pixel data stored in a separate media data box (this is for instance the case of the itemLocationBox box), a compression field in association with the second box. By “Container box”, it is meant a box that contains and groups a set of related boxes or sub-boxes. The obtaining of the compressed accompanying non-pixel data may include obtaining uncompressed non-pixel data and compressing them. These various signalling options offer a large range of generic solutions to indicate that accompanying non-pixel data associated with the image item are compressed in the media data section (‘mdat’ or ‘imda’ or ‘idat’ boxes). This overcomes the current limitation of the regular HEIF format that does not offer the opportunity to compress a large list of accompanying data. The present disclosure also proposes a method for processing data, the method comprising in a processing device: obtaining an ISOBMFF-based media file having a multi-box structure encapsulating media data of an image and accompanying non-pixel data associated with the image, wherein a first box of the multi-box structure declares a first item describing the image and a second and separate box that is associated with the first box describes the accompanying non-pixel data, wherein the multi-box structure includes a signalling of a compression status of the accompanying non-pixel data from one of the following signalling options: a compression configuration property in an item property box associated with the second box; an item_type equal to ‘uri ’ in the second box, combined with an item_uri_type in the second box set to a dedicated value signalling a compression of the accompanying non-pixel data; a dedicated item_type in the second box that signals compression of any type of data element corresponding to accompanying non-pixel data (e.g. any item type); signalling that the second box describes a derived item from a third box declaring a third item that also describes the accompanying non-pixel data, wherein the second box indicates, as derivation operation, a decompression scheme corresponding to a scheme used to compress the accompanying non-pixel data; the presence of the second box in a second list within a Container (e.g. iteminfoBox or itemPropertiesBox) box, wherein the Container box has a version value that defines the box as including a first list of boxes describing accompanying non-pixel data that are not compressed and the second list of boxes, as a separate list, describing accompanying non-pixel data that are compressed; including, within a link box that links the second box to the accompanying non-pixel data stored in a separate media data box (this is for instance the case of the itemLocationBox box), a compression field in association with the second box, and processing the accompanying non-pixel data depending on the signalling. Optional features are defined below with reference to methods, while they can be transposed into device features. Also, the features below that add signalling when encapsulating the media data can be used in the reverse way to parse the media file and decompress the payloads. In other embodiments, the second box is an item box that is linked to a separate media data box (e.g., ‘mdat’ or ‘imda’ or ‘idat’ boxes) that stores the accompanying non-pixel data. In some embodiments, the image data and accompanying non-pixel data are obtained from an HEIF or ISOBMFF media file, wherein the accompanying non-pixel data are described by an item associated with an image item describing the image or are provided in an item property box associated with the image item. In this configuration, the accompanying non-pixel data are extents forming the ‘mdat’ or ‘imda’ or ‘idat’ boxes in case of associated items or are payloads stored in ‘ipco’ boxes in case of associated properties. Furthermore, the boxes for the multi-box structure can be directly retrieved from the HEIF or ISOBMFF media file. The above method can therefore allow a regular HEIF file to be converted into an enhanced “compressed” HEIF file. In some embodiments, the dedicated value for the item_uri_type is common to all item types corresponding to accompanying non-pixel data provided in the multi-box structure that are associated with the image. In some embodiments, the second box further includes a field to specify an item type of the accompanying non-pixel data. In some embodiments, the dedicated value for the item_uri_type further indicates an item type of the accompanying non-pixel data. It means various values may be used to distinguish between the items. This avoids additional signalling to identify the original type of the item. In some embodiments, the second box or the item property box or the link box further includes one or more fields to indicate compression parameters used for compressing the accompanying non-pixel data. In some scenarios, accompanying non-pixel data, such as property information data (e.g., colour information or ICC profiles), may reach tens or hundreds of kilobytes, even with the above compression. Such high amount of data in the metadata part of the media file is detrimental to fast start of reading of the media file. Indeed, getting initialization segment (for video) or image description (for still image) becomes more costly and thus creates delay on slow network connections. It may be advantageous not to store such property information data in the metadata part but rather in the data part so that the image description remains easy to fetch through a network for example. In this context, enhanced embodiments include a method for encapsulating an image in an ISOBMFF-based media file, the method comprising in a processing device: obtaining data of an image, obtaining property information data of a first property associated with the image, generating a multi-box structure to include the obtained image data and the property information data, wherein the multi-box structure includes a metadata box and a media data box, the metadata box includes a first item box describing the image and a first item property box (separate from the image item box) that is associated with the first item box to describe the first property of the image, the media data box includes the obtained image data, wherein, when a property attribute in the first item property box takes a first value signalling at least a part of the property information data is stored in the media data box, the metadata box comprises a second item box that is associated with the first item box to describe part of the first property of the image and that is linked to the part of property information data stored in the media data box. An item box belongs to so-called Item Information box whereas an item property box belongs to so-called Item Properties box (and more precisely an Item Property Container box therein). As a result, massive properties can be - at least partly - offloaded from the metadata part to the media data box, resulting in a lightened metadata part. Correspondingly, a method for processing data may comprise in a processing device: obtaining an ISOBMFF-based media file having a multi-box structure encapsulating media data of an image and property information data of a first property associated with the image, wherein the multi-box structure includes a metadata box and a media data box, the metadata box includes a first item box describing the image and a first item property box that is associated with the first item box to describe the first property of the image, retrieving the media data of the image from the media data box, retrieving a property attribute from the first item property box, in case the property attribute takes a first value signalling at least a part of the property information data is stored in the media data box, retrieving the part of the property information data from the media data box, using a second item box that is associated with the first item box to describe part of the first property in the metadata box and that is linked to the part of property information data stored in the media data box, processing the retrieved property information data together with the retrieved image data. In some embodiments, the property attribute is defined to take either the first value to signal at least a part of the property information data is stored in the media data box or a second value to signal the entire property information data are stored in the first item property box. A mechanism is therefore proposed that, depending on the property attribute as declared, the property information data are either stored fully as metadata or at least partly as media data. This provides flexibility in the encapsulation of media data. In particular embodiments, the first item property box is a colour information box, and the second value is ‘nclx’ or the second value is one of ‘nclx’ and ‘rICC’. The embodiments therefore offload the unrestricted (and optionally restricted) ICC profiles to the media data part. In some embodiments, the metadata box comprises an item location box linking the second item box with the part of property information data stored in the media data box. This allows the media player to easily retrieve the offloaded property information data from the media data box. In some embodiments, the part of property information data stored in the media data box is uncompressed. In variants, the part of property information data stored in the media data box is compressed. For example, it may be decided to offload compressed property data. In particular embodiments, the metadata box includes a signalling that the part of property information data is compressed, the signalling being performed via one of the following options: a presence of a compression configuration property in a second item property box and associated with the second item box; an item_type equal to ‘uri ’ in the second item box, combined with an item_uri_type in the second item box set to a dedicated value signalling a compression of the part of property information data; a dedicated item_type in the second item box that signals compression of any type of data element corresponding to the part of property information data; signalling that the second item box describes a derived item from a third box declaring a third item that also describes property information data, wherein the second item box indicates, as derivation operation, a decompression scheme corresponding to a scheme used to compress the part of property information data; the presence of the second item box in a second list within a Container box, wherein the Container box has a version value that defines the box as including a first list of boxes describing property information data that are not compressed and the second list of boxes, as a separate list, describing property information data that are compressed; including, within a link box that links the second item box to the part of property information data stored in the media data box, a compression field in association with the second item box. In some embodiments, the part of property information data includes colour information data. In particular, the part of property information data includes ICC profile data. The proposed method is well fitted to manage growing ICC profiles. In some embodiments, the first item box is associated with the second item box in an item reference box. This ensures the media player can retrieve the appropriate property information data for a given image. In some embodiments, the second item box includes an item type set to a unique type value to signal the first property of the image, whatever the property information data described by the second item box. A generic item type is therefore used. In some embodiments, the second item box includes an item type set to a first type value when the property information data described by the second item box relate to a first property attribute or to a second type value when the property information data described by the second item box relate to a second property attribute. This allows discriminating between various property attribute values for a given property when an item box or multiple item boxes for that property are associated with the same image item in the media file. In addition, this may provide indication on how to interpretate (or read or parse) the corresponding property information data as stored in the media data box. In some embodiments, the metadata box includes a second item property box that is associated with the first item box, has the same box type as the first item property box to describe a second property of the image, wherein all property information data defining the second property of the image are included in the second item property box whereas at least part of the property information data defining the first property of the image is included in the media data box. In these embodiments, two property boxes having the same box type therefore coexist for the same image, the payload of one of which being at least partly offloaded into the media data box whereas the payload of the other one is kept in a conventional manner within the item property box itself. In some embodiments, the first and second item property boxes are colour information boxes, wherein a colour type included in the second item property box is ‘nclx’ or is one of ‘nclx’ and ‘rICC’, whereas a colour type included in the first item property box is the first value. This particular implementation is well suited to growing ICC profiles. Still with respect to big ICC profiles or colour information, it may be worth avoiding property boxes in order to save signalling. In this respect, enhanced embodiments include a method for encapsulating an image in an ISOBMFF-based media file, the method comprising in a processing device: obtaining data of an image, obtaining colour information data associated with the image, generating a multi-box structure to include the obtained image data and the colour information data, wherein the multi-box structure includes a metadata box and a media data box, the metadata box includes a first item box describing the image and a second item box describing the colour information data, and the media data box comprises the obtained image data and the obtained colour information data. Note that an item location box may provide a link between the second item box and the colour information data stored in the media data box. In some embodiments, an item properties box in the metadata box is deprived of colour information box (separate from the item box) associated with the colour information data. In such embodiments, the colour information is defined as items and no longer as property. For example, colour information data includes ICC profile data. Correspondingly, a method for processing data may comprise in a processing device: obtaining an ISOBMFF-based media file having a multi-box structure encapsulating media data of an image and colour information data associated with the image, wherein the multi-box structure includes a metadata box and a media data box, the item information box in the metadata box includes a first item box describing the image and a second item box describing the colour information data, retrieving the media data of the image from the media data box, retrieving the colour information data from the media data box, using the second item box, typically via the above mentioned item information box, and processing the retrieved colour information data together with the retrieved media data. Correlatively, the disclosure also provides a processing device comprising a processing unit configured for carrying out each step of any method as described above. Another aspect of the disclosure relates to a computer program product for a programmable apparatus, the computer program product comprising instructions for carrying out each step of any method as described above. Yet another aspect of the disclosure relates to a non-transitory computer-readable storage medium storing instructions of a computer program for implementing any method as described above. 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. 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. BRIEF DESCRIPTION OF THE DRAWINGS Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which: Figure 1 illustrates a simplified syntax of the known iteminfoBox box and ItemlnfoEntry box; Figure 2 illustrates, in a simplified version, the syntax of the MinimizedimageBox box as defined in Annex O of ISO / IEC 23008-12:2024 / CDAM 2:2024; Figure 3 illustrates, using a flowchart, steps of an encapsulation method according to embodiments relying on an enhanced slimHEIF, i.e., a condensed or slim or compact file format representation; Figure 4a illustrates an example of an enhanced MinimizedimageBox box according to embodiments; Figure 4b illustrates another example of an enhanced MinimizedimageBox box according to embodiments; Figure 4c illustrates yet another example of an enhanced MinimizedimageBox box according to embodiments; Figure 5 illustrates, using a flowchart, steps of an de-encapsulation or parsing method according to embodiments relying on an enhanced slimHEIF; Figure 6 illustrates, using a flowchart, steps of an encapsulation method according to alternative embodiments relying on an enhanced HEIF; Figure 7 illustrates a ‘cmpC’ property according to embodiments; Figure 8 illustrates a modified iteminfoBox box according to embodiments; Figure 9 illustrates, using a flowchart, steps of a de-encapsulation or parsing method according to embodiments relying on enhanced HEIF. Figure 10 illustrates, using a flowchart, steps of an encapsulation method according to embodiments that involves the enhanced slimHEIF or the enhanced HEIF; Figure 11 illustrates, using a flowchart, steps of a de-encapsulation or parsing method according to embodiments that involves the enhanced slimHEIF orthe enhanced HEIF; Figure 12 illustrates an image file having example compressed accompanying non-pixel data according to embodiments; Figure 13 illustrates an image file with property offloading in the media part according to embodiments; and Figure 14 is a schematic block diagram of a computing device for implementation of one or more embodiments of the invention. DETAILED DESCRIPTION OF THE INVENTION For the sake of illustration, some embodiments of the disclosure are directed to the packaging, storage, or encapsulation of one or more media streams such as a still image or a sequence of images in an ISOBMFF-based file format, such as the regular HEIF defined in ISO / IEC 23008-12 and its low-overhead image file format as introduced in annex O of the last amendment, ISO / IEC 23008-12:2024 / CDAM 2:2024. The ISOBMFF-based media file may be later used for reading from a storage medium or may be used by a streaming server for adaptive streaming, for example over HTTP (with MPEG DASH, HTTP Live Streaming or Smooth Streaming). According to ISOBMFF and its extensions including HEIF, a media file is constituted by multiple boxes. Boxes, also called containers, are hierarchical data structures provided to describe the data in the media 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 size. All data in a file, media data and metadata describing the media data, are contained in boxes. There is no other data within the file. File-level, or top-level, boxes are boxes that are not contained in other boxes. At the opposite a sub-box is a box contained in another box. HEIF covers various ways for encapsulating still images into the file format. One way is based on ‘meta’ boxes, based on information items, instead of samples, providing less description tools. The media file comprises a top-level MetaBox box (4CC = ‘meta’) and one or more MediaDataBoxes (4CC = ‘mdat’) that contain the media data of the items described in the MetaBox box. The media data are stored as contiguous sets (or ranges) of bytes (known as “extent” or “chunks”) in the MediaDataBoxes. An ‘item’ refers to data which does not require timed processing, as opposed to sample data. An image, such as an array of pixels, is a type of item; it is below referred to “image item”. Other information or data accompany the image. Some are handled as image properties associated with the image item, while other are handled as items associated with the image item. The information or data accompanying the image may comprise indication of the codec associated with profile, tier and / or level data information that is used to compress the image to be represented in the image file. Configuration parameters may include a set of coded structures describing coding configuration that allows instantiating a decoder. This set of coded structures is also denoted as “configuration data”. Other accompanying data representing the configuration of the image comprise for example the dimension or resolution of the images. They 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. The configuration parameters may include an encoding format for the alpha plane or alpha channel. These accompanying data are pixel data correlated to the pixels of the image that is described. For example, a pixel in these accompanying data corresponds to one pixel in the image. Metadata associated with the image are also accompanying data that may be included in the image file, like for example EXIF orXMP metadata items. The metadata are non-pixel data because they do rely on a pixel to pixel matching or the like. The image configuration may also indicate whether the metadata items are included in uncompressed or compressed format. Each set of metadata may be 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 colour formats, each pixel has several pixel values, for example a red value, a green value and a blue value. Each colour forms a channel, all the colour 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, compression method or algorithm, compression format: for example, each item individually, group of items, all items as one compressed block. The configuration information or parameters may be provided by a user through a user interface, may be predefined according to application settings or can be computed from image characteristics and / or from characteristics of its associated metadata, like for example pixel dimensions or data size. Various types of accompanying data correspond to various accompanying data elements. For example, EXIF metadata are accompanying non-pixel data of a first type (EXIF) occurring through one accompanying data element (item), while the colour profile is accompanying non-pixel data of a second type (ICC) occurring through another accompanying data element (property). Some of the accompanying data - pixel or non-pixel - are processed as “items”: they are described by descriptive boxes and the accompanying data are stored in MediaDataBoxes. It is referred below to as “accompanying items” for ease of description. The MetaBox box includes an iteminfoBox box that includes an iteminfoEntry box per each item to be described in the media file, including the accompanying items. Hence, the iteminfoBox box lists all the items. The iteminfoEntry box describes a given item, including its parameters. A simplified syntax of these boxes is shown in Figure 1. As shown, the iteminfoBox box ‘iinf’ 100 is located in the MetaBox box and comprises entry_count (integer) boxes of the iteminfoEntry type. Each iteminf oEntry box ‘infe’ 110 indicates an identifier of the item (item_iD) followed by an indication of the type of item (item_type made of a 4CC) and a name for the item (item_name). Next, for the ‘mime’ and ‘uri ‘ types, specific additional information is provided. Any association between items described through iteminf oEntry boxes (e.g., between an accompanying data item and the image item) is defined in so-called ItemRef erenceBox box located in the MetaBox box. The itemLocationBox box located in the MetaBox box specifies the actual storage location (through byte offsets) of the accompanying data of each item within the MediaDataBoxes as well as the file size of each accompanying data. Some of the accompanying data are processed as “properties”: they are described by item property boxes and the accompanying data are stored in these boxes. It is referred below to as “accompanying properties” for ease of description. They are described using item property boxes in an ItemPropertyContainerBox box (‘ipco’), the item property boxes being associated with the image item via an ItemPropertyAssociationBox box (‘ipma’). Both ItemPropertyContainerBox box and ItemPropertyAssociationBox box are embedded into an itemPropertiesBox box (‘iprp’) within the top-level MetaBox box. Another way for encapsulating still images, known as low-overhead image file format, is based on a single minimized image box known as MinimizedimageBox which provides a more compact representation of the MetaBox for a subset of use cases, particularly adapted for the encapsulation of small and simple images. Figure 2 illustrates, in a simplified version, the syntax of the MinimizedimageBox box as defined in Annex O of ISO / IEC 23008-12:2024 / CDAM 2:2024. This is a compact description according the HEIF amendment for a low-overhead image file format. Description 200 defines the box as a top-level box in an image file; the box type indicated by a specific 4CC, here ‘mini’, with the indication that only one occurrence of this box is allowed. This means that a low-overhead image file format can embed only one image. In embodiments, the ‘mini’ box could be extended to multiple images, for example by duplicating in sequence the fields mentioned below for each of the images. The disclosure below could therefore be applied to each image: i.e., compressing or not the accompanying non-pixel data associated with an image, repeated for each image present in the file. The MinimizedimageBox box 201 first comprises a set of control flags 211 indicating the presence or absence of corresponding accompanying data elements; followed by a list of some accompanying data which are usually descriptive parameters 212; a list of chunks (or payloads or data chunks) sizes 213 that defines the size of each chunk in the next section 214; and at the end, the chunks 214 of the image and the accompanying data of the accompanying elements handled as chunks. Here, “chunk” means contiguous byte range. In slimHEIF, the following accompanying data elements are handled as chunks: alpha item codec config, gainmap item codec config, main item codec config, icc data, tmap icc data, gainmap metadata, alpha item data, gainmap item data,exif data and xmp data. It is to be noted that a specific chunk order is defined by the low-overhead image file format wherein some chunks are optional (signalled by the control flags). A first set of chunks 220 corresponds to non-pixel data of optional accompanying data elements such as decoder configuration information (aipha_item_codec_conf ig, gainmap item codec config, main item codec config). A second set of chunks 221 corresponds to non-pixel data of other optional accompanying data elements such as metadata and component associated with the image (icc_data, tmap_icc_data, gainmap_metadata). Then, a third set of chunks 222 includes the (mandatory) chunks for the image data (main_item_data) and the chunks of accompanying pixel data, such as the alpha plane payload and the hdr gainmap payload (aipha_item_data, gainmap_item_data) which are mandatorily compressed in the same way as the image data. If the image data are compressed, these accompanying pixel data are compressed. If the image data are not compressed, the accompanying pixel data are not compressed. At the end, a fourth set of chunks 223 includes non-pixel data of optional accompanying data elements such as EXIF and XMP metadata (exif data, xmp data). Chunks 220 and 221 are located before the image data 222 in the MinimizedimageBox box 201, while chunks 223 are located after the image data 222 in the MinimizedimageBox box 201. Whatever the regular HEIF of Figure 1 or the slimHEIF of Figure 2, the possibilities to have the data - that are important amounts of bits - be compressed are limited. Obviously, the image data and dependent accompanying pixel data can be compressed; however all together with the same compression scheme. For example, the explicit codec types flag in the MinimizedimageBox box 201 signals whether the image data and the accompanying pixel data are compressed or not. The other accompanying data cannot be compressed, except the ‘mime’ item (Figure 1 showing optional content_encoding) and the EXIF item in the regular HEIF. This is because the regular HEIF and slimHEIF fail to provide appropriate signalling. More generally, the regular HEIF suffers from a bad design for the declaration of items. The iteminfoBox box allows declaration of items, each item as an iteminfoEntry box. This box has different versions that do not systematically allow indication of compressed accompanying non-pixel data for the item (unless specific item type). There is therefore a need for a generic solution to allow other accompanying data elements made of non-pixel data to be included in a compressed form (with their data compressed in a lossless fashion). Hence, enhanced HEIF and slimHEIF that reduce the size of the ISOBMFF-based media files are sought. Any media such as still images could therefore be stored in such enhanced HEIF and slimHEIF formats at reduced costs, or transmitted with less communication resources. This could happen with data coming from applications or when converting a media file from the regular HEIF or slimHEIF into one of the enhanced HEIF and enhanced slimHEIF. As apparent from the disclosure below, the reverse - transcoding from one enhanced format into the regular HEIF or slimHEIF format - is also possible. Figure 3 illustrates, using a flowchart, steps of an encapsulation method according to embodiments relying on an enhanced slimHEIF, i.e., a condensed or slim or compact file format representation. This method, in a processing device, comprises: obtaining data of an image; obtaining accompanying non-pixel data associated with the image that are compressed, and generating a single box that includes the obtained image data and the compressed accompanying non-pixel data. The encapsulation method consists in an iterative processing that applies successively to each image and associated / accompanying data to be represented in an image file. The steps shown in the Figure represent the processing of one image in which uncompressed non-pixel data are first being obtained before they are compressed. 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 the Figure is applied successively to each input image of the sequence. The encapsulation process may maintain in memory the previously generated media file and may update this previously generated media file instead of generated a new media file at the end. The first step 300 consists in obtaining image data of an image. For example, this can be captured by a camera, a smartphone or calculated by a computer. As mentioned above, a source file such as a media file in HEIF or slimHEIF may be retrieved in variants, which file can be transcoded, for example to produce a more compact version of the file before a transmission or before publishing on a Web page. The image data may already be compressed; alternatively, they may be uncompressed; in variants, after being retrieved uncompressed, they are compressed. The image data are compressed with associated accompanying pixel data such as the alpha map or the HDR (High Dynamic Range) gain map. At step 301, along with the image data, accompanying data elements (e.g. metadata) associated with the image may also be generated by the capture device or be retrieved from the source file (for example through accompanying metadata or as part of an Image format metadata SEI message in the image bitstream) or generated for example through image analysis. The accompanying data elements include non-pixel data. They may be obtained in an uncompressed form or in a compressed one. In the scenario below, they have been obtained in an uncompressed form, hence a compression thereof is implemented. When they are obtained in a compressed form, the steps below to decide on a compression or not and to compress the data can be omitted. At step 302, the method determines the image configuration. The image configuration is a set of parameters or properties associated with the image or images, as described above. At optional step 303, decision may be taken to compress one or more of the uncompressed accompanying non-pixel data (the image data and accompanying pixel data are handled in a conventional way). Criteria to decide which type of accompanying non-pixel data (i.e., which accompanying data element or elements) is to be compressed is out of the scope of the present disclosure. Any criteria may be applied. Step 303 also includes the compression of such uncompressed accompanying non-pixel data. To illustrate, the EXIF metadata of the EXIF element (item) are compressed. In embodiments, the compression parameters (algorithm, scheme, etc.) are predefined. For example, a default compression with the deflate() algorithm defined in IETF RFC 1951 is assumed (avoiding signalling of a compression algorithm). In variants, they are stored when selected to perform the compression, in order to further signal them in the media file. Next, the generation of a compact description starts. It aims at generating a single box that includes the obtained image data and the compressed non-pixel data. For example, the generation of an enhanced MinimizedimageBox box is made. As an example, it focuses on reducing the size of accompanying or metadata chunks associated to the main image, for example EXIF or XMP payloads At step 304, the compact description is filled in with descriptive metadata, such as a list of control flags indicating the presence or absence of some accompanying data elements - e.g., image, alpha or depth component, properties like sizes or HDR (High Dynamic Range) or colour information, metadata associated with the image or alpha or depth, and parameters describing these items. This compact description may be declared in a top-level box, for compliance with ISOBMFF. At step 305, the sizes of the data to be embedded as chunks (or data chunks) in the box are signalled. This is the size of the data image and accompanying data as obtained at step 300 and 301 if not compressed afterwards, or the size of the compressed accompanying non-pixel data once compressed at step 303. For compactness of the description, there is one expected order for the sizes of the data embedded as chunks in the box, thus avoiding indexing data for the different items, as usually required by HEIF based on MetaBox box. Another top-level box may be present, for example a FileTypeBox, to indicate a set of brands that apply to the media file to implicitly define the order of the data embedded as chunks in the box. In particular, the box may indicate a set of one major brand, one or more minor brands or compatible brands; a specific brand may be indicated in the list of brands to indicate the presence of the proposed enhanced low-overhead image file box. 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’. A new brand may be defined for the amendment to HEIF fora low overhead image format: ‘mif3’. Media files having the enhanced format according to the disclosure may reuse this brand or may use another, dedicated, brand for low overhead image format with further compression (for metadata items), for example ‘mif4’. This brand would require players to support the additional signalling related to the indication of compressed payloads for metadata associated to image item. As well, if the regular HEIF is extended with compression features for metadata items, a new brand may be considered to mandate support of possible new boxes allowing this indication. At step 306, the image data, the accompanying pixel data and the accompanying non-pixel data (compressed at step 303 or still uncompressed) are stored at the end of the box, according to the expected order, for example the one of Annex 0.3 of ISO / IEC 23008-12:2024 / CDAM 2:2024 as shown in Figure 2. At step 307, the ISOBMFF-based media file containing the enhanced low-overhead image file box is generated. As mentioned previously, the types of accompanying data elements whose nonpixel data is compressed according to the disclosure may be predefined in advance, such that the processing device systematically (automatically) applies the compression for those predefined types of accompanying data (when not obtained in a compressed form in 301). The compression parameters for the compression may also be predefined. In these embodiments, the accompanying non-pixel data to compress are selected based on a predefined criterion. In that way, the low-overhead image file format is defined in a way such that the accompanying non-pixel data (e.g., metadata associated with the image) or a pre defined subset thereof are implicitly described in an image file in a compressed version. By doing so, there is no need for specific signalling. For example, a predefined list of accompanying data elements concerned by the compression may be defined, indicating which types of accompanying data must be systematically compressed. In variants or in combination, a size threshold (e.g., of several kilobytes or hundreds of bytes) to be compared to a hypothetical maximum size of the uncompressed non-pixel data given a type of the accompanying data may be defined and used to select the accompanying data elements to compress. The selected accompanying data elements may then be individually compressed, meaning the non-pixel data of each one is separately compressed using the predefined compression parameters. Their chunk sizes then correspond to the size of the compressed non-pixel data. The data order remains unchanged. The accompanying data element (or type) not meeting the criterion (not in the list or whose theoretical maximal size is below the threshold) may not be compressed by default (for example some configuration information). As a consequence of these implicit compression rules, the flags defined to specify two pre-defined number of bits to encode some chunk sizes or parameters may be reconsidered or adjusted, for example the few_metadata_bytes_flag corresponding to the EXIF and XMP chunk and possibly to colour information like icc_data or tmap_icc_data. In variant to this “automatic” approach, a signalling may be added to the enhanced low-overhead image file box or to another top-level box such as the ‘ftyp’ box to signal that the accompanying non-pixel data are compressed. Usually, the signalling may be a flag or a bit that takes a first value (e.g. 0) in a case where the accompanying non-pixel data are not compressed in the box or a second value (e.g. 1) in a case where the accompanying non-pixel data are compressed in the box. Figure 4a illustrates an example of an enhanced MinimizedimageBox box 401 from the HEIF amendment for a low-overhead image file format that is extended with an additional control flag indicating compression for accompanying non-pixel data associated with the image. In the example, a single control flag 410 is added to the set 411 of conventional control flags to indicate that all non-pixel data embedded as chunks are compressed with a widely supported lossless compression algorithm. In other words, a common or shared signalling is provided that is applicable to all uncompressed non-pixel data: the signalling includes one compression signalling flag (e.g. one-bit flag) common to all types of accompanying data element corresponding to accompanying non-pixel data provided in the box or to all types of a plurality of accompanying data element corresponding to accompanying non-pixel data provided in the box. In some embodiments, the non-pixel data of each accompanying data element is individually or separately compressed. As the uncompressed accompanying non-pixel data corresponding to each accompanying data element are compressed separately; the box includes a size indication of the size of each separately compressed non-pixel data of the accompanying data elements. In other words, the chunk sizes 413 now refer to the size of the compressed non-pixel data, when this control flag 410 is set to 1, or to the size of the uncompressed non-pixel data, when the control flag 410 is 0. This is to allow the parser to quickly skip among the chunks to reach only the ones required for the application or user needs. Individual or separate compression preserves the chunk order as specified in the MinimizedimageBox box as defined in Annex O of ISO / IEC 23008-12:2024 / CDAM 2:2024. In variants, the payloads are combined before compression: uncompressed accompanying non-pixel data corresponding to all the accompanying data elements are combined to be compressed as a single payload. This advantageously reduces the processing time and may improve compression efficiency. In that case, the box includes a size indication of the size of each uncompressed accompanying non-pixel data, for the parser to be able to quickly skip among the uncompressed non-pixel data after decompression, to reach only the ones required for the application or user needs. In some embodiments, the compression parameters to be used are predefined, e.g. a Deflate algorithm is systematically used. In a variant, they may be signalled: the signalling in the box includes one or more fields to indicate compression parameters for compressing the accompanying non-pixel data of one or more accompanying data elements. Preferably (however not mandatory), the compression parameters fields are included in the box only if the control flag 410 takes the second value (1) indicating the accompanying non-pixel data are compressed. In other words, the control flag 410, when set (1), indicates the presence of the compression parameters 411, e.g. compression “algorithm” (or “method”) and / or compression “granularity” (or “mode”). For example, a first field dedicated to the compression algorithm may take values to indicate well-known and widely supported lossless compression algorithm like Deflate, bzip, Izma, zlib, Brotli, JPEG-XL.....Deflate being the compression algorithm by default. For example, a first field dedicated to the compression mode may take values to indicate how to the data are (individually or collectively) compressed. It indicates a compression scheme selected from a group of schemes that includes one or more of: - a first scheme where uncompressed accompanying non-pixel data corresponding to two or more separate accompanying data elements are combined to be compressed as a single chunk. For example, value 0 for the compression mode may be used to indicate a single compression, i.e., all metadata or the like associated with the image are compressed as one single compressed payload. This requires changing the description of chunk sizes and the data organization: for example image data first, followed by the single compressed payload (chunk). The chunk sizes would then give uncompressed sizes, to allow parser to navigate through the accompanying data resulting from decompression; - a second scheme where uncompressed accompanying non-pixel data corresponding to two or more separate accompanying data elements are separately compressed. For example, value 1 for the compression mode may be used to indicate individual compression. This does not require changing the data order, while the chunk sizes indicate the compressed sizes; - a third scheme where uncompressed accompanying non-pixel data corresponding to accompanying data elements located before the image data in the single box are combined to be compressed as a single first chunk, while uncompressed accompanying non-pixel data corresponding to accompanying data elements located after the image data in the single box are combined to be compressed as a single second chunk. For example, value 2 may be used to indicate this “two-runs” compression mode: a first compression run is conducted for the consecutive accompanying data elements (for example 221, or 220 plus 221) preceding the image data and pixel data 222 (often already compressed) in the box, and / or a second compression run for consecutive accompanying data elements (e.g. metadata 223) following the image data and dependent pixel data (at least 222) in the box. This does not require any change of the data order. However, additional size indication may be provided for the two resulting compressed payloads / chunks, for the parser to be able to locate and process each compressed payload separately, while the chunk sizes indicating the sizes of the uncompressed accompanying non-pixel data within each set are also provided for the parser to be able to navigate through the accompanying data elements resulting from decompression. - a fourth scheme where uncompressed accompanying non-pixel data of an adjustable number of accompanying data elements are combined to be compressed as a single payload. For example, value 3 may be used to allow a variable number of items or properties to be jointly compressed in a compressed block. Additional description of the compressed block, such as the number of accompanying data elements considered, which ones, the block size, can be provided in the box. The chunk sizes remain the sizes of the uncompressed non-pixel data composing the compressed payload for ease of navigation.- a fifth scheme may extend one of the third or fourth scheme with a possibility to include in the first compressed block the descriptive parameters like 211 and 212. Only the indication of compressed or not may remain out of the compressed block. Figure 4b illustrates another example of an enhanced MinimizedimageBox box 401 from the HEIF amendment for a low-overhead image file format that is extended with additional control flags per respective accompanying data element to provide more flexibility in the signalling of the accompanying non-pixel data that are compressed or not. In the example, a signalling is provided in the box per each accompanying data element (e.g. each type) corresponding to accompanying non-pixel data provided in the box, using the existing presence flags 421 (within the control flags) that are extended by one or more bits to signal the compression. To save signalling costs, the additional bit or bits for signalling the compression of the accompanying non-pixel data are provided only if a presence flag of the accompanying non-pixel data is set to true. To illustrate, the exif_flag corresponding to the EXIF element 223 is extended from one bit (initially a presence flag) to two bits to have the signalling of the compression or not of the EXIF payload. In a cost saving approach, the second bit is present only if the first (presence flag) bit is set to 1. In this example, the compression signalling flag and the presence flag of the accompanying non-pixel data belongs to the same binary field in the box. In more details, this embodiment allows individually indicating which accompanying non-pixel data are compressed. The existing “presence” flags (221 in Figure 2) are reused and extended to two bits instead of one bit. For example the “presence flags” 221 may be renamed into: bit(2) hdr_presence bit(2) icc_presence; bit(2) exif_presence; bit(2) xmp_presence; It is to be noted that for HDR related “presence” flag, a finer description may use two specific presence flags instead of the hdr_presence parameter: bit(2) gainmap_presence and bit(2) tmap_icc_presence The so-modified presence flags would have the following semantics: - the first bit still indicates the presence or absence of the accompanying data element (i.e., item or property such as HDR, XMP or EXIF, and so on.), - the second bit or “compression signalling bit” indicates the “compressed” (value 1) or “not compressed” (value 0) nature of the non-pixel data of the corresponding accompanying data element. It results for example that the following values can be used for these “extended” flags: value 00 in case where the corresponding accompanying data element is not present, value 01 in case where it is present (second bit set to 1), but its non-pixel data are not compressed (first bit set to 0), value 10 is reserved, value 11 in case where it is present and its non-pixel data are compressed. As for the embodiments of Figure 4a, the second bit may be used only if the first bit is set to 1, meaning for example that the following values are used: value 0 in case where the corresponding accompanying data element is not present, value 10 in case where it is present (first bit set to 1), but its non-pixel data are not compressed (second bit set to 0), value 11 in case where it is present and its non-pixel data are compressed. In a variant, instead of bit masking values, values 0, 1,2 may be used to indicate absence of the parameter, presence in uncompressed form and presence in compressed form respectively. Value 3 would be unused. As for the embodiments of Figure 4a, in some embodiments, the compression parameters to be used are predefined, e.g. a Deflate algorithm is used. In a variant, the compression parameters may be signalled: the signalling in the box includes one or more fields to indicate compression parameters for compressing the accompanying non-pixel data of one or more accompanying data elements. Preferably (however not mandatory), the compression parameters fields 411 are included in the box only if the control flag 410 takes the second value (1) indicating the accompanying non-pixel data are compressed. For example, an additional field when the compression signalling bit is equal to 1 indicates the compression algorithm in use, for example from a pre-determined list, Deflate being the one to use by default when no indication is given. In variants, the existing “presence” flags may be further extended (i.e., with more than one additional bit) to have additional bit or bits to signal the compression (e.g., algorithm and / or mode as described above). Applied to slimHEIF, the semantics for the so-extended “presence” flags could be expressed as follows: icc_presence indicates the presence of ICC profile as defined in ISO 15076-1 or ICC.1 and whether the information is compressed or not. When set to 0, no ICC profile information is present in the file. When set to 1, ICC profile is present and the corresponding data chunk is uncompressed. When set to 2, ICC profile information is present and the corresponding data chunk is compressed. Value 3 is reserved. exif_presence: indicates the presence of Exif metadata and whether the corresponding data chunk is compressed or not. When set to 0, no Exif metadata is present in the file. When set to 1, Exif metadata is present and the corresponding data chunk is uncompressed. When set to 2, Exif metadata is present and the corresponding data chunk is compressed. Value 3 is reserved. xmp_presence: indicates the presence of XMP metadata and whether the corresponding data chunk is compressed or not. When set to 0, no XMP metadata is present in the file. When set to 1, XMP metadata is present and the corresponding data chunk is uncompressed. When set to 2, XMP metadata is present and the corresponding data chunk is compressed. Value 3 is reserved. gainmap_presence: indicates whether the file has a tone-mapped image and an associated HDR-related ISO 21496-1 gain map or not and whether the related metadata is compressed or not. When equal to 0, it specifies that the file has no tonemapped image and no associated HDR-related ISO 21496-1 gain map. When equal to 1, the file has a tone-mapped image and a gain map with related metadata that is uncompressed. When equal to 2, has a tone-mapped image and a gain map with related metadata that is compressed. It is set to 0 if hdr_flag is 0. Value 3 is reserved. tmap_icc_presence: indicates the presence of ICC profile as defined in ISO 15076-1 or ICC.1 associated to the tone-map image and whether the corresponding information is compressed or not. When set to 0, there is no ICC profile associated to the tone-map image. When set to 1, there is an ICC profile associated to the tone-map image and the corresponding information is not compressed. When set to 2, there is an ICC profile associated to the tone-map image and the corresponding information is compressed. Value 3 is reserved. It is equal to 0 when gainmap_presence is 0 or 3. icc_data_size_minusl: carries the size minus one in bytes of the ICC profile as defined in ISO 15076-1 or ICC.1, associated with the main image, when icc_presence is 1. It carries the size minus one in bytes of the compressed ICC profile as defined in ISO 15076-1 or ICC.1, associated with the main image, when icc presence is 2. It is undefined if icc presence is 0 or 3. tmap_icc_data_size_minusl: carries the size minus one in bytes of the ICC profile as defined in ISO 15076-1 or ICC.1, associated with the tone-mapped image, when tmap_icc_presence is 1. It carries the size minus one in bytes of the compressed ICC profile as defined in ISO 15076-1 or ICC.1, associated with the tonemapped image, when tmap_icc_presence is 2. It is undefined if tmap icc presence is 0 or 3. gainmap_metadata_size: carries the size of the gain map metadata if gainmap_presence is 1. It carries the size of the compressed gain map metadata if gainmap presence is 2. It is 0 if gainmap presence is 0 or 3. exif_data_size_minus1: specifies the size minus one of the Exif metadata in bytes if exif_presence equals 1. It specifies the size minus one of the compressed Exif metadata in bytes if exif_presence equals 2. It is set to -1 otherwise (exif presence equals 0 or 3). xmp_data_size_minusi: specifies the size minus one of the XMP metadata in bytes if xmp_presence equals 1. It specifies the size minus one of the compressed XMP metadata in bytes if xmp_presence equals 2. It is set to -1 otherwise (xmp presence equals 0 or 3). The semantics for the other fields of the Minimized Image Box would remain unchanged. In case, HDR related information relies on one “hdr_presence” or “hdr_flag” as in 421 instead Of two tmap icc presence and gainmap presence "presence" flags, the semantics for the “hdr_flag”, or “hdr_presence” semantics may be updated as follows: hdr_presence: when set to 0 specifies that the image is SDR and has no associated HDR-related signaling. If set to 1, the image is either SDR with a SDR-to-HDR gain map, or HDR with an optional HDR-to-SDR gain map and the related (chunk 222) colour information and gain map metadata are provided as uncompressed chunks. When set to 2, the image is either SDR with a SDR-to-HDR gain map, or HDR with an optional HDR-to-SDR gain map and the related (chunk 222) colour information and gain map metadata are provided as compressed chunks. Figure 4c illustrates yet another example of an enhanced MinimizedimageBox box 401 from the HEIF amendment for a low-overhead image file format that is extended with additional control flags per respective accompanying data element to provide more flexibility in the signalling of the accompanying non-pixel data to compress. Compared to Figure 4b, this example provides that the compression signalling bit / flag 431 and the corresponding presence bit / flag 221 of the accompanying non-pixel data are two separate binary fields in the box. In this example, new additional flags 431 are defined (instead of modifying the existing presence flags). As shown, it consists in bit(1) f ieid_compressed; provided only when the corresponding field_flag=1 (field identifying the accompanying data element concerned). In variants, the additional flag 431 may be present regardless of the value of the presence flag 221. The other features described above for Figure 4b also apply to the embodiments of Figure 4c. In any of the above variants of Figure 4b and Figure 4c, the accompanying non-pixel data are preferably compressed separately one from each other (i.e., per each accompanying data element), to have independent chunks that are easily accessible by the parser. The value of the chunk sizes therefore depends on the value of the additional field or bit 431: when field 431 indicates a compression (value 1), the chunk size of the chunk concerned corresponds to the size of the compressed data; otherwise (value 0), it indicates the size of the uncompressed data. These variants remain compact in description, easy to parse and offer flexibility for an editor of the image file. Indeed, the author or writer can decide what (accompanying data elements) is compressed, and what is not. In some embodiments, non-pixel data aipha_item_codec_config, gainmap item codec config, main item codec config are not compressed; non-pixel data icc data, tmap icc data, gainmap metadata are compressed; pixel data alpha item data, gainmap item data may be not compressed but are most often compressed; and non-pixel data exif_data and xmp_data are compressed. Figure 5 illustrates, using a flowchart, steps of a de-encapsulation or parsing method according to embodiments relying on an enhanced slimHEIF. This method, in a processing device, comprises: obtaining an ISOBMFF-based media file encapsulating media data of an image, obtaining, from the ISOBMFF-based media file, a single box that includes data of the image and compressed accompanying non-pixel data associated with the image, and processing the compressed accompanying non-pixel data. Of course, accompanying pixel data may also be processed in parallel, using conventional techniques. The method can be performed on a capture device to render a recorded image or on any device capable of rendering images, for example onto a screen (TV, PC, smartphone, tablet...). First, the media file is obtained at step 501. This is for example a file having a compact description as generated through the process of Figure 3, e.g. comprising any enhanced MinimizedimageBox box 401 described above. At step 502, the processing device accesses and start parsing I reading the compact description from the media file. It consists in reading parameters in the box, including the control flags, as defined in the amendment to HEIF for low-overhead image format and e.g. as extended or supplemented as described above with reference to Figures 4a to 4c. Next, at step 503, the parser looks for indications in the compact description about compressed non-pixel data for accompanying data elements associated with the image item (the image data and optional pixel data, possibly compressed, are handled in a conventional way). When test 503 is true - meaning there are one or more accompanying data elements with its non-pixel data compressed -, the parser obtains information about each compression at step 504, e.g. individual or combined compressing (i.e., single or multiple payloads), compression algorithm, compression mode, chunk sizes. As mentioned above, the compression parameters may be predefined (implicit signalling) or may be retrieved from specific signalling in the box. The steps after step 504 are performed for each chunk having compressed data, as described below. In some embodiments, each and every compressed non-pixel data is decompressed in 511, in which case steps 510 and 513 can be omitted. However, in alternative embodiments, depending on the application, the parser may decide to decompress or not a given compressed accompanying data element at step 510. For example, a compressed accompanying data element useful for an application or for rendering the image or supported by the player can be decompressed. Otherwise, the compressed element may not be decompressed. For instance, a player not supporting the High Dynamic Range may skip processing of HDR-related information contained in the file. Similarly, a player not understanding the XMP format may skip XMP information possibly included in the file. It is to be noted that decompressing or not the element from a compact description may also consider some application requirements, user choice or pre-defined settings like reconstructing a regular HEIF (at step 512) or a compressed HEIF (at step 513). In case the accompanying data element is to be decompressed (test 510 true), the corresponding chunk made of compressed non-pixel data is retrieved (possibly thanks to the chunk sizes) and its decompression is performed at step 511 to obtain the decompressed non-pixel data corresponding to the accompanying data element. The decompression is performed using the compression parameters as obtained I gathered at step 504. The resulting decompressed non-pixel data may be used to build a regular HEIF media file, for example in a transcoding application or to provide the media file to a regular HEIF player. The parser then re-maps the decompressed non-pixel data and corresponding description from the box, to an HEIF structure of boxes at step 512. A remapping between the fields of the slimHEIF and the fields of the regular HEIF is for example specified in Annex 0.4 of ISO / IEC 23008-12:2024 / CDAM 2:2024. An HEIF-based player may use the regular HEIF media file to display an image at step 550. In variants, the resulting decompressed non-pixel data may be directly used by a player to display an image at step 550. Of course, the image data and other accompanying data are retrieved (and decompressed if needed) by the player to successfully display the image. In case the compressed non-pixel data are not to be decompressed at step 510, the parser maps the still-compressed non-pixel data from the low-overhead image format to “compressed items” in HEIF at step 513. “compressed items” refers to the enhanced or compressed HEIF as described below with reference to Figures 6 to 8, in which enhanced signalling is provided to allow additional accompanying data elements (compared to regular HEIF) to be compressed, hence stored in compressed form. At step 513, a compact description may be mapped to a compressed version of HEIF and no more necessarily to the regular HEIF as in step 512. For example, depending on user choice, application needs or settings, some accompanying data elements (items or properties) associated with an image may be kept in their compressed form when remapped to a box-based organization as required by “regular” HEIF. Parser may decide to keep all compressed elements in their compressed form or may keep only a subset of those, for example based on a payload size criterion. The detection of candidate compressed items can be done by inspecting the compact description and in particular the indications for compressed accompanying data. The items that are kept compressed can be represented in the HEIF by any signalling means as described below with reference to Figures 6 to 8. An example of mapping from the single MinimizedimageBox to the set HEIF boxes under a top-level MetaBox, using the extension of presence flags 421, can be expressed as follows: The equivalent MetaBox can have an iteminfoBox containing the following entries: • iteminfoEntry of version 2 with flags set to 0, item_iD set to 1 and item_type set to inf e_type. All other fields are set to null or 0 as appropriate. • If alpha item data size is not 0, IteminfoEntry of version 2 with flags set to 1, item_iD set to 2 and item_type set to infe_type. All other fields are set to null or 0 as appropriate. • If gainmap presence is 1 or 2, Iteminf oEntry of version 2 with flags set to 0, item_iD set to 3 and item_type set to ' tmap’. All other fields are set to null or 0 as appropriate. • If gainmap item data size is not 0, Iteminf oEntry of version 2 with flags set to 1, item_iD set to 4 and item_type set to infe_type. All other fields are set to null or 0 as appropriate. • If exif presence is 1, ItemlnfoEntry of version 2 with flags set to 1, item ID set to 6 and item type set to 'Exif'. If exif presence is 2, itemlnfoEntry of version 2 with flags set to 1, item_iD set to 6 and item_type set to ' dExf'” to indicate that the EXIF metadata is compressed and needs to be decoded before interpreted. All other fields are set to null or 0 as appropriate. o NOTE: when exif presence is 2, an ItemlnfoEntry of version 2 with flags set to 1, item_iD set to 6 and item_type set to ' Exif'” may be created instead of item_type=’dExf’, if the EXIF chunk is decompressed before being stored in the data part of the file and being mapped to MetaBox and its sub boxes. • If xmp presence is 1 or 2, Itemlnf oEntry of version 2 with flags set to 1, item ID set to 7 and item type set to 'mime' and content type set to 'application / rdf+xml'. If xmp presence is 2, the content encoding is set to “deflate” to indicate that the XMP metadata is compressed and needs to be decoded before interpreted. All other fields are set to null or 0 as appropriate. o NOTE: when xmp presence is 2, an Itemlnf oEntry Of version 2 with flags set to 1, item_ID set to 7 and item_type set to 'mime' and content type set to 'application / rdf+xml' may be created with an empty value in the content_encoding field, if the XMP chunk is decompressed before being stored in the data part of the file and being mapped to MetaBox and its sub boxes. The itemRef erenceBox can be populated with the following entries: • If iteminfoBox has an entry for item_iD 2: Item type reference with referenceType set to 'auxl', from item ID set to 2, ref erence count set to 1 and to_item_iD set to 1. • If ItemlnfoBox has an entry for item ID 2 and alpha is premultiplied is set to 1: Item type reference with referenceType set to 'prem', from item ID set to 1, reference count set to 1 and to item ID set to 2. • If gainmap presence is 1 or 2 and ItemlnfoBox has an entry for item ID 4: item type reference with ref erenceType set to 'dimg', from item id set to 3, reference_count set to 2 and the following to_item_iD entries: 1,4. • If gainmap presence is 1 or 2 and ItemlnfoBox has zero entry for item ID 4: item type reference with ref erenceType set to ' dimg', from item id set to 3, reference count set to 1 and to item IDSettol. • If ItemlnfoBox has an entry for item_iD 6: item type reference with ref erenceType set to ' cdsc ', from item ID set to 6, ref erence count set to 1 and to_item_iD set to 1. • If ItemlnfoBox has an entry for item_iD 7: item type reference with ref erenceType set to ' cdsc ', from item ID set to 7, ref erence count set to 1 and to_item_iD set to 1. If the resulting itemReferenceBox contains at least one entry, it may be added to the equivalent MetaBox. An empty ItemReferenceBox may be ignored. If gainmap presence is 1 or 2, the equivalent MetaBox may have a GroupsListBox containing a single sub-box. That sub-box is an EntityToGroupBox with grouping_type set to ' altr ', version set 0, flags set to 0, group_id set to 5, num entities in group set to 2 and the following entity id entries: 3, 1. The equivalent MetaBox can have an itemPropertiesBox containing an ItemPropertyContainerBox and an ItemPropertyAssociationBox. The ItemPropertyContainerBox may have 32 entries as described in the amendment to HEIF with the following modifications: icc presence is 1 or 2 Colourlnf ormationBox with the colour type set to 'prof' and with icc_prof ile contents being icc_data, when icc presence is 1 or content of icc data after decompression when icc_presence is 2. 1 gainmap presence is 1 or2 ImageSpatialExtentsProperty equal to entry 2 if orientation is 0, 1, 2, 3 and with image width set to height minusl + 1 and image height setto width minusl + 1 for any Other orientation. 2 gainmap presence is 1 or2 and (tmap explicit cicp fl ag is 1 or tmap icc presence is 0) ColourlnformationBox with colour type set to ’nclx' and colour primaries, transfer characteristics, matrix coefficients and full range flag set to tmap colour primaries, tmap transfer characteristics, tmap matrix coefficients and tmap full range flag, respectively. 3 gainmap presence is 1 or2 and tmap icc presence is 1 or 2 Colourlnf ormationBox with the colour type set to 'prof' and with ICC profile contents being tmap icc data when tmap icc presence is 1 or content of tmap_icc_data after decompression when tmap icc presence is 2. Concerning property association in ‘ipma’ box, the following parts can be updated: • If gainmap_presence is 1 or 2, item 3 may be associated with ItemPropertyContainerBox entries: 5 o 21, non-essential o 22, essential o 23, essential • If hdr_f lag is 1 and gainmap_presence is 1 or 2, item 3 may be associated with ItemPropertyContainerBox entries: 10 o 24, non-essential o 25, non-essential o 26, non-essential o 27, non-essential o 28, non-essential 15 o 29, non-essential Concerning the HDR related information: If gainmap presence is not 0, the PixellnformationProperty associated with the gain map image item is reconstructed as described in section 0.4.7.1 of the HEIF amendment with the arguments specified in section 0.4.7.4. If gainmap presence is 1, tmap item data is defined as a data chunk of tmap_item_data_size bytes, being gainmap_metadata_size+1 bytes, containing the ToneMapimage metadata as defined in section 6.6.2.4.2, with the following: • version set to 0 • GainMapMetadata set to gainmap metadata If gainmap presence is 2, tmap item data is defined as a data chunk of tmap_item_data_size bytes, being the size obtained after decompression of the gainmap_metadata chunk and containing the ToneMapimage metadata as defined in section 6.6.2.4.2, with the following: • version set to 0 • GainMapMetadata set to gainmap metadata after decompression If gainmap presence is 0, tmap item data is defined as an empty chunk and tmap item data size as 0 byte. The ItemLocationBox can be constructed as described in annex 0.4.9 in the HEIF amendment when computing tmap_item_data_size as updated above and storing EXIF as dExf item when compressed and indicating when XMP is compressed in the ItemlnfoEntry with item_iD=7. Concerning the storage of the data for images and associated metadata, the equivalent MetaBox can have an itemDataBox or a MediaDataBox containing the non-empty chunks among alpha item data, tmap item data, gainmap item data, main item data, exif data and xmp data, concatenated in that order. The data chunks for EXIF and XMP may be compressed chunks, when exif presence =2 and xmp presence =2 respectively. Whatever the indications in use in the media file (presence flags 421, single flag 410, new flags 431 or their variants), the mapping process would follow the same principles, only the names of the parameters indicating a compression or not may be updated. After the mapping to compressed HEIF has been done for each compressed nonpixel data to be kept and the decompression of the other non-pixel data has been done, the player can use the image at step 550 (e.g., for display). When test 503 is false, the parser applies the parsing of the conventional low-overhead image file format (slimHEIF) at step 520, possibly with a re-mapping to an HEIF structure of boxes at step 512. Turning now to an enhanced or compressed HEIF, Figure 6 illustrates, using a flowchart, steps of an encapsulation method according to embodiments. This method, in a processing device, comprises: obtaining data of an image, obtaining accompanying non-pixel data associated with the image that are compressed. The obtaining of the compressed accompanying non-pixel data may include obtaining uncompressed non-pixel data and compressing them, generating a multi-box structure (complying with HEIF) to include the obtained image data and the compressed non-pixel data, wherein a first box of the multi-box structure declares a first item describing the image (typically the image item) and a second and separate box that is associated with the first box describes an accompanying data element corresponding to the compressed accompanying non-pixel data. Depending on the embodiments, the second box may be an item property box (itemproperty or itemFuiiProperty box) that includes the accompanying non-pixel data, or it may be an item box - iteminfoEntry - that is linked to the accompanying non-pixel data stored in a separate media data box ‘mdat’ or ‘imda’ or ‘idat’ via the itemLocationBox box. Both item and item property boxes are associated to the first box - an image item in a dedicated iteminfoEntry box - via the ItemRef erenceBox box and the ItemPropertyAssociationBox box. The proposed enhancement of HEIF comes from the fact that the multi-box structure includes a signalling that the accompanying data element has its payload (non-pixel data) compressed (or not), the signalling being performed via one of the following options: a compression configuration property in an item property box associated with the second box; an item_type equal to ‘uri ’ in the second box, combined with an item_uri_type in the second box set to a dedicated value signalling a compression of the accompanying non-pixel data; a dedicated item_type in the second box that signals compression of any type of data element corresponding to accompanying non-pixel data (e.g. any item type, including box type for item property boxes); signalling that the second box describes a derived item from a third box declaring a third item that also describes the accompanying non-pixel data, wherein the second box indicates, as derivation operation, a decompression scheme corresponding to a scheme used to compress the accompanying non-pixel data; the presence of the second box in a second list within a Container (e.g. iteminfoBox or itemPropertiesBox) box, wherein the Container box has a version value that defines the box as including a first list of boxes describing accompanying non-pixel data that are not compressed and the second list of boxes, as a separate list, describing accompanying non-pixel data that are compressed; including, within a link box that links the second box to the accompanying non-pixel data stored in a separate media data box (this is for instance the case of the itemLocationBox box), a compression field in association with the second box. These various options are described below. First steps are steps 300-302 already described, to obtain image data and accompanying data associated with the image or images, as well as the image configuration. Next, the encapsulation process uses an encapsulation based on a box structure at step 610, relying on above-mentioned iteminfoBox and iteminfoEntry boxes, and ItemPropertyContainerBox box. It may first start by creating the top-level MetaBox box and the IteminfoBox and ItemPropertyContainerBox boxes. Next, a test is performed at step 611 to check whether some accompanying non-pixel data are to be stored in a compressed format or not (the image data and accompanying pixel data are handled in a conventional way). If not (test 611 false), the encapsulation module embeds (620) the image as a conventional image item in a iteminfoEntry box to describe the image and its properties and embeds (620) any associated accompanying data elements as associated items in iteminfoEntry boxes (possibly with their properties) within the iteminfoBox box and or as associated properties in the ItemPropertyContainerBox box. The corresponding accompanying data are also stored in appropriate box or boxes (MediaDataBox box ‘mdat’ or itemDataBox box ‘idat’ boxes) or directly in the item property boxes in the itemPropertyContainerBox box. Next, at step 621, the locations of the accompanying data are stored in the itemLocationBox box for the accompanying data elements handled as items (“accompanying items”). Finally, the regular HEIF media file containing the accompanying items and associated accompanying data is generated at step 622. If there are some accompanying items to be stored in a compressed format (test 611 true), the process has to indicate or signal (step 612) the elements with compressed non-pixel data and those without compressed non-pixel data. When a specific item type is already defined for an accompanying item with compressed payload (such as for a ‘mime’ item or the EXIF element through the ‘dEXf’ item), the encapsulation module can use this 4CC and declare the item as an ItemlnfoEntry box in the ItemlnfoBox box. When there is no 4CC for the item type with compressed non-pixel data, for example for an XMP metadata item, then the encapsulation module adds a specific indication in the media file that the data are compressed. The description hereafter provides some details on exemplary indications that can be used. Some embodiments rely on a specific signalling in the itemlnfoEntry box. In first embodiments, a compression configuration property in an item property box associated with the concerned itemlnf oEntry box may be used. In other words, a compression configuration property is associated with compressed items (through the itemPropertiesBox box), for example by using the ‘cmpC’ property 700 as depicted in Figure 7, or a simplified version thereof. An example of simplification can be to keep only the first field indicating the compression type as a 4CC. Possibly the second field is also kept to indicate whether compression is applied to all non-pixel data or to each separately. The last field may be omitted. A variant of ‘cmpC’ may be used, encoding the compression type and indication of individual compression using 8 bits. The compression type may be a value, coded on 7 bits, in a predefined list of compression algorithms (e.g. like Deflate, bzip, Izma, zlib, Brotli, or JPEG-XL for icc_data since the JPEG XL core coding specification has a special purpose encoding for ICC profiles) and the second field still be a flag (1 bit). The conventional item_types (as in HEIF) can be kept, only the presence of this property with accompanying items means that the non-pixel data of the accompanying items are compressed. Of course, the item size given in the item location (itemLocationBox box) is adjusted to the compressed size. Note that this property 700 may be adjusted (in terms of fields) to convey all compression parameters needed if necessary (i.e., not implicit). A variant of property 700 may be as follows: aligned(8) class CompressionConfigurationBox extends FullBox('cmpC', version=0, flags=0) { unsigned int(32) compression type; unsigned int(8) compressed unit type; } In second embodiments, a dedicated item_type in the second iteminfoEntry box may be used. For example, an item_type equal to ‘uri ’ in the concerned iteminf oEntry box is combined with an item_uri_type set to a dedicated value to signal a compression of the accompanying non-pixel data. The reserved value for the item_uri_type parameter may indicate “compressed_item” or the like, in a generic form. In this example, the reserved value is common to all item types associated with the image. There is a need for an additional signalling of the item type handling the accompanying item. Therefore, the iteminfoEntry box may further include an additional field to specify the original type of the accompanying item concerned. The conventional 4CC may be used in this additional field. In variants, the reserved value used may be specific to the type of the accompanying item for compression signalling, while signalling the original type of the item. In other words, the dedicated value for the item_uri_type further indicates an item type of the accompanying non-pixel data. This means for example that various values are used to signal different types of accompanying items in a compressed form, e.g., hdr_compressed for HDR accompanying data, icc_compressed, exif_compressed, xmp_compressed, and so on. Alternatively, the conventional 4CC for the item types can be used in the item_uri_type field. In another example of the second embodiments, the dedicated item_type in the iteminfoEntry box takes a specific value that signals compression of any item type of accompanying non-pixel data. This is no longer the item_uri_type that indicates the compression but the item_type itself. A generic 4CC is used for compressed items type, e.g. ‘cmpi’. This overcomes the limitations of using 4CC dedicated to specific items, such as ‘dEXf’ for the EXIF element. An associated compression property (additional field in the box) may be used to indicate the original item type. In the second embodiments, the iteminfoEntry box may further include one or more fields to indicate compression parameters for compressing the accompanying non-pixel data, if not implicit. In third embodiments, the compressed accompanying item may be defined as a derived item, from a compression operation. As an example, the item_type may be set to ‘cmpi' for “compressed item” which derives from a “normal” item that describes the accompanying non-pixel data concerned. The derivation operation may provide the associated decompression method. In other words, the iteminfoEntry box describes a derived item from another iteminfoEntry box which describes the accompanying non-pixel data. And the iteminfoEntry box indicates, as derivation operation, a decompression scheme corresponding to a scheme used to compress the accompanying non-pixel data. In that way, when the parser traverses the iteminfoEntry box, it obtains the compressed non-pixel data and all useful information (compression parameters) using the other iteminfoEntry box that describes the accompanying item. Next, thanks to the decompression scheme indication, the parser can trigger the decompression of the compressed non-pixel data when needed. Other embodiments rely on an extension of an existing item box such as the ItemlnfoBox box. Thanks to a dedicated indication to the extended box, the latter may embed two sublists of boxes, a first list of boxes describing accompanying non-pixel data that are not compressed and a second and separate list of boxes describing accompanying non-pixel data that are compressed. The presence of an accompanying data element in the second list means that its non-pixel data are compressed. The two-list variant of the extended box may be implemented through a reserved version value of the box. It results that the parser I decoder identifying the reserved version value can readily distinguish between the compressed accompanying items (second list) and the uncompressed accompanying items (first list). These embodiments, define compressed accompanying non-pixel data in a generic way in HEIF. As illustrated on Figure 8 as reference 800, a new box for compressed items, for example as a sub-box of iteminf oBox box, can be used. The iteminfoBox box may have a new version in which two lists of items are declared: the first list of items declared using the existing iteminf oEntry ‘infe’ boxes and the second list of items declared using either existing iteminfoEntry ‘infe’ boxes or - preferably - a new kind of iteminfoEntry boxes, providing similar information than the ‘infe’ box but assuming an item with a compressed payload (nonpixel data). A content-encoding parameter may be available to indicate the compression parameters (if not implicit or by default). An example of a new kind of iteminfoEntry box is illustrated on Figure 8 as 850, under the 4CC ‘cife’ (for Compressed Item inFo Entry and for illustrative purposes only). It includes the item iD of the accompanying item, its item_type and optional compression parameters. In other embodiments, an indication of the compression of the accompanying items may be provided when making the link between the item and its non-pixel data in the media data or item data boxes. To do so, the compression signalling for a given accompanying item may be included, within the link box (ItemLocationBox box) that links the iteminfoEntry box describing the element to its accompanying non-pixel data stored in the media data or item data box. The compression signalling is provided in association with the iteminfoEntry box. The ItemLocationBox may be extended to allow indicating that some accompanying items have their payload (non-pixel data) stored in a compressed form (without changing their item type). For example, a flags value is defined for the ItemLocationBox: The flags field of ItemLocationBox with version greater than or equal to 1 is specified as follows: ■ (flags &1) equal to 1 indicates that this box provides a directory of resources in this or other files, by locating their container, their offset within that container, and their length, where the length can be the actual length of the item payload or the length of the item payload after a generic lossless compression like deflate() algorithm. ■ (flags &1) equal to 0 indicates that this box provides a directory of resources in this or other files, by locating their container, their offset within that container, and their length, where the length is the actual payload length. In a first variant, when the flags value is set, the ItemLocationBox provides an indication after each item_iD, for example as a flag called “compressed_extents”, that its extents correspond to the actual payload size (when set to 0) or that the extent_iength of the item’s payload after a generic lossless compression. This would imply that the item would need decompression before being used by a decoder or reader. When the flags value is not set, the value is assumed to be 0, i.e. the extent_iength is the actual one, not a compressed one. There may be additional indication for distinguishing whether all the extents of an item have been compressed together or individually. When individually compressed, the flag “compressed_extents" is renamed into “compressed_extent” and placed in the inner loop on extents instead of following the indication of the item_ID. The two flags “compressed_extents" and “compressed_extent" may be combined, the first one indicating at least one extent being compressed and each extent then being indicated as compressed or not. When compressed extents is 0, the compressed extent is assumed to be 0 and does not to be indicated. These are indications to players or readers to decompress items payloads as one block for all extents or decompress items payloads each individually. It is to be noted that the extent_of fset takes into account the extent_iength after compression when set. In a second variant, when the flags value is set, the ItemLocationBox declares one or two directories of resources in this or other files, by locating their container, their offset within that container, and their length. The first directory (actually a first loop on item_iD) correspond to items having their length corresponding to their actual payload size and a second directory (as a second loop on other items_iDs) where their length correspond to the length of the item payload after a generic lossless compression. The use of this extended itemLocation may be combined with the compression property associated to the item, in order to indicate another compression algorithm than the default deflate algorithm. These embodiments ease the processing by the parser, because it obtains the indication on whether accompanying non-pixel data are compressed or not, when it specifically tries to access them (since it is using the ItemLocationBox box). Back to Figure 6, after the compressed accompanying items are signalled in the multi-box structure, the concerned accompanying non-pixel data are compressed and stored in appropriate box or boxes, at step 613 similar to step 620 (but with compressed data). Next, at step 614, the locations of the compressed non-pixel data are stored in the ItemLocationBox box if needed. Note that the item sizes given in the item location (itemLocationBox box) are adjusted to the compressed sizes. Finally, the compressed HEIF media file containing the accompanying items and associated compressed data is generated at step 615. Figure 9 illustrates, using a flowchart, steps of a de-encapsulation or parsing method according to embodiments relying on enhanced or compressed HEIF. This method, in a processing device, comprises: obtaining an ISOBMFF-based media file having a multi-box structure encapsulating media data of an image and accompanying non-pixel data associated with the image, wherein a first box (e.g. an image item box, i.e., an item box the associated data of which is an image) of the multi-box structure declares a first item describing the image and a second and separate box (e.g. iteminfoEntry box or an item property box) that is associated with the first box describes the accompanying non-pixel data, wherein the multi-box structure includes a signalling of a compression status of the accompanying non-pixel data from one of the above signalling options, and processing the accompanying non-pixel data depending on the signalling. The decoded data can be combined with decoded image data and accompanying pixel data to generate an image to display. The method can be performed on a capture device to render a recorded image or on any device capable of rendering images, for example onto a screen (TV, PC, smartphone, tablet...). First, the media file is obtained at step 501. This is for example a file in compressed HEIF as generated through the process of Figure 6. At step 902, the box-based description is parsed, meaning the various MetaBox box, iteminfoBox box, iteminfoEntry boxes and item property boxes are traversed. Next, the parser, at step 903 looks for any indications in the box-based description about compressed non-pixel data for accompanying items associated with the image item. This may be indicated by an associated property, a dedicated item_type, a dedicated item_uri_type in case of ‘uri ‘ item in the iteminfoEntry boxes, or a dedicated version value of a Container box, or an indication in a link box. When there is no indication of compressed non-pixel data for any accompanying item associated with the image item (test 903 false), then the parser processes (step 910) the image file as a regular HEIF and can render the image at step 550, possibly with accompanying non-pixel data. When the non-pixel data of one or more accompanying items are compressed as identified by any indication (test 903) true, each compressed non-pixel data of interest is retrieved (possibly thanks to the chunk sizes) and the decompression of the non-pixel data is performed at step 904. The decompression is performed using the compression parameters as obtained I gathered when parsing the boxes at step 902. In some embodiments, each and every compressed non-pixel data is decompressed. In alternative embodiments, depending on the application, the parser may decide to decompress or not a given compressed non-pixel data at step 904. For example, compressed non-pixel data useful for an application or for rendering the image or supported by the player can be decompressed. On the other hand, the compressed non-pixel data may not be decompressed if of no interest for the application or the like. For instance, a player not supporting the High Dynamic Range may skip processing of HDR-related information contained in the file. Similarly, a player not understanding the XMP format may skip XMP information possibly included in the file. Once decompressed at step 904, the accompanying non-pixel data can be used with the reconstructed image from step 905 in the final step 550. It is to be noted that steps 902 to 550 of this Figure may apply to a regular HEIF file media obtained after the mapping 512 from a compact image file format to regular HEIF. Figure 10 illustrates, using a flowchart, steps of an encapsulation method according to embodiments that may involve the enhanced slimHEIF or the enhanced HEIF. The method includes steps already described above; hence they have the same reference number and are not repeated here. After having obtained image data and accompanying data associated with the image or images, as well as the image configuration (steps 300-302), the processing device continues with test 1000 to determine whether it is worth using a compact representation or not, to describe the media file. The choice of the representation format may be indicated during the configuration step 302 or, when not indicated, may be a decision based on image size or on the set of information to be described, for example just one image versus an image with associated accompanying data or multiple images. A compact description aims at providing a minimal description of the image and its associated accompanying data elements that allows a simplified parsing of the image file description and possibly parallel or partial processing of the image components and of its associated accompanying data. Partial processing means, for an image reader or a media player, to identify parts of the file to process and other parts not to process, depending on the user or application needs and / or on the capabilities of the reader or player. The benefit of the compact description is also to have a compactness for compressed images and / or for associated accompanying data that are represented with a small amount of data, for example for the image file to download or to be exchanged faster. 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. Various criteria to enable such compact representation may be contemplated. For example, they may rely 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. In other examples, they are related to the image configuration like the dimension, the number of components or the length in bits or bytes of the coded data. In another example, the encapsulation module when trying to generate a compact format, after test 1000=true, checks whether some payloads fit in the number of bits specified to encode their corresponding chunk size (for example from parameter like the f ew_metadata_bytes_f lag). If the payload is too big, the encapsulation module may decide to compress non-pixel data via step 303 and if still not compliant may finally decide to use a box-based structure via step 610. When the image does not meet the criteria or when the configuration does not require a compact format (test 1000 false), the encapsulation process uses an encapsulation based on a box structure as in Figure 6; otherwise, an encapsulation based on e.g. slimHEIF may be conducted as in Figure 3. Figure 11 illustrates, using a flowchart, steps of a de-encapsulation or parsing method according to embodiments that may involve the enhanced slimHEIF or the enhanced or compressed HEIF. The method includes steps already described above; hence they have the same reference number and are not repeated here. After obtaining the media file at step 501, the parser determines at step 1100 the presence of a compact description or a multiple-box description in the media file. For example, this may be indicated by a specific brand in the FileTypeBox or by the type of the main container box. For example, for the compact description, a ‘mini’ box is used, while for a multi-box HEIF description, a ‘meta’ box is used instead. When it is determined at step 1100 that a compact description is used, the deencapsulation process continues as in Figure 5, whereas if a multi-box description is used, the de-encapsulation process continues as in Figure 9. Figure 12 illustrates an image file having example compressed accompanying non-pixel data according to embodiments. The image file is mainly structured as a MetaBox box 12100 and a data box 12200. For example, in HEIF or ISOBMFF-derived image file formats, the MetaBox box may be a ‘meta’ box and the data box may be an ‘mdat’, ‘idat’ or ‘imda’ box. For illustrative purposes only, the example accompanying non-pixel data are image properties provided in item property boxes, in particular colour properties in so-called ‘coir’ boxes. Colour properties specify how the pixel values of the image should be interpreted in terms of colour. Of course, other item property boxes - in addition or in variant - may be compressed. Similarly, item boxes - in addition or in variant to item property boxes - may be compressed. The example image file contains two image items 12111 and 12112 declared in an item information box 12110 (e.g., iteminfoBox ‘iinf’ box in ISOBMFF or HEIF). These image items are associated with item properties, declared in a property container box 12130 (e.g., ItemPropertyContainerBox ‘ipco’ box in ISOBMFF or HEIF) via the property association box 12140 (e.g., itemPropertyAssociationBox ‘ipco’ box in ISOBMFF or HEIF). For example, the first image item 12111 is associated with a first colour property (1) defined by box 12131 and with a second colour property (2) defined by box 12132, as signalled in the property association box 12140. Also, the second image item 12112 is associated with a colour property (3) defined by box 12133, as signalled in the property association box 12140. It is to be noted that not all the properties are listed in the container box 12130 for clarity (for example the mandatory image spatial extent property). The pixel data 12201 and 12202 of the image items 12111 and 12112 are stored in the data box 12200 and can be identified and retrieved by looking at the item location box 12150, that provides their byte ranges. Due to illustrative purposes only, the data blocks 12201 and 12202 could be in any order, not necessarily in the order of item declaration in the item information box 12110. In the proposed scenario of Figure 12, the first colour property box 12131 is compressed to save space, and signalling of such compression is provided through a dedicated box type, here ‘ccol’ (standing for compressed colour, however any other 4CC could be used) compared to legacy ‘coir’ as defined the standard. The use of the dedicated box type is one signalling option from amongst various signalling options defined above. Any of these alternative options can be used instead, in the scenario of Figure 12. For example, a compression configuration property box may be used that is associated with the colour box 12131 to signal it includes colour information in a compressed form. It happens that accompanying non-pixel data reach tens or hundreds of kilobytes, even with the above compression. For example, some ICC profiles (as accompanying non-pixel data) may represent significant size for some media files, especially to embed per-file optimized HDR to SDR tone-mapping curves. Even with compression, they may represent tens of kilo bytes. In some scenarios, the colour information may even reach or exceed the image data size (amount of pixel data stored in the data box). Having these ICC profiles within the ‘coir’ box (i.e. in the metadata part of the media file) means that getting initialization segment (for video) or image description (for still image) will become more costly and may create delay on slow network connections. File Format faced similar issues when designing the carriage of Neural Network-based post filter SEI messages. Therefore, it may be advantageous not to store all or part of such data (e.g., ICC profiles) in the metadata part of the media file but rather in the data part (e.g., ‘mdat’, ‘idat’ or ‘imda’ box), so that the image description remains easy to fetch through a network for example. In particular, where the ‘coir’ box indicates a “large” ICC profile, this “large” ICC profile can be stored in a media data box. With this approach, there is no penalty in getting the initialization segment or image description. In this particular example of the colour information, enhanced embodiments propose to extend the colour box (‘coir’) to support compressed ICC profiles, e.g., to further specify this extension as JPEG-XL compressed ICC profiles within the ‘coir’ box. Preferably not all accompanying non-pixel data are concerned, but those representing a significant payload size. In embodiments, a significant payload size may be when the payload size is greater than a pre-defined threshold (for example more than 2048 bytes) or when reaching a given ratio of the image data size (e.g. 50% for small images or 25% for big images). Of course, any other criterion can be used to select which accompanying non-pixel data (e.g., item property item) can have all or part of its payload stored in the data part as described below rather than in the metadata part. In this context, it is proposed to offload at least part of the property information data from the metadata part (namely an item property box that is associated with an image item) to the data part of the media file. This is achieved by signaling, in the corresponding property box, the offloading, and then storing the offloaded part of property information data in the media data box using a dedicated item box (to link the offloaded data to the image while enabling their retrieval from the data part). In other words, a property attribute in the item property box takes a first value to signal at least part of the property information data of the property considered is stored in the media data box. Furthermore, the metadata box (12100 above) comprises a second item box associated with the image item box (i.e., the box describing the image item). The second item box is used to describe the first property too. The second item box is linked to the part of property information data that is stored in the media data box, typically through the Item Location box (12150 above). A preferred application of this approach is directed at the offloading of colour information. ICC profiles can be offloaded in which case the offloading is performed when the property attribute (here colour type) in the colour box ‘coir’ is not ‘nclx’. Alternatively, unrestricted ICC profiles can be offloaded in which case the offloading is performed when the property attribute (here colour type) in the colour box is not one of ‘nclx’ and ‘rICC’. On the contrary, those values signal that the colour information data are stored in the colour box itself, and not in the data part. As illustrated below, the colour type may be ‘extc’ to signal the colour information data are at least partly stored in the media data box. This example shows the ‘coir’ box is extended with a new colour_type ‘extc’ indicating an “external” colour, meaning that the colour information is not within the ‘coir’ box itself but rather in a data box. In a variant to the colour property, the same offloading mechanism may apply to decoder configuration properties. When the configuration information represented a significant size compared to an image payload, the encapsulation module may decide to offload the configuration information from the metadata part to the data part, and create a configuration item associated with the image item. The decoder configuration property may however keep its box type unchanged, indicating the coding type (e.g. ‘avcC’ or ‘hvcC’ or ‘vvcC’....) but the item property box may have a dedicated field or a flags value indicating that the payload is external to the property box (i.e., offloaded), for example the decoder configuration record. The same mechanism may also apply to an image coming from a compressed bitstream containing SEI messages with post-filtering, for example a Neural-network post-filter characteristics (NNPFC) SEI message. There may be a property associated with the image item, for example a post-filter item property that sometimes contains the description of the NNPFC and sometimes contains the description of the NNPFC plus a compressed representation of the neural network model. This compressed representation may be offloaded in the data part by declaring an item with an item type indicating a NNR item and by linking this NNR item to the image item the same way as explained above. Figure 13 illustrates an image file with property offloading in the media part according to embodiments. As for Figure 12, the illustrative example offloads colour information data, whereas other property information data associated with the image can be offloaded in association with or in variant to the colour information offloading. Boxes similar to those of Figure 12 have the same properties as described above, unless specified below. In this example of the Figure, the image file provides an alternative way of storing colour information with a significant payload size. Still, the first image item 13111 is associated with a first colour property (1) defined by box 13131 and with a second colour property (2) defined by box 13132, as signalled in the property association box 13140. Also, the second image item 13112 is associated with a colour property (3) defined by box 13133, as signalled in the property association box 13140. Second and third colour properties (2) (3) have a significant payload size (i.e., a high amount of colour information data). It is therefore decided to offload them (entirely or partly) in the media data box 13200. On the contrary the first colour property (1) of colour box 13131 has a reasonable payload size, meaning it is not offloaded: the colour box ‘coir’ 13131 includes for example a colour_type equal to ‘nclx’ and it is fully stored in the ‘coir’ box 13131. To achieve the colour information data offload, the image file contains two colour items 13113 and 13114 corresponding to both second and third colour boxes 13132 and 13133 respectively. It means that all or part of the colour information data are stored as items. A specific item type can be used to identify such colour item boxes 13113 and 13114. In embodiments, the colour item box includes an item type set to a unique type value to signal the colour property of the image whatever the colour information data described by that colour item box. A generic item type is therefore used. For example, ICC profiles are described as items with a new item_type, for example ‘iccp’. Of course, any other 4CC not conflicting with existing ones can be used. The new item_type ‘iccp’ is defined to indicate that the metadata item represents an ICC profile. Alternatively, in order to distinguish between two colour item boxes associated with the same image item, the colour item box may include an item type set to a first type value when the colour information data described by that colour item box relate to a first colour type (more generally a property attribute) or to a second type value when the colour information data described by the colour item box relate to a second colour type. As an example, distinction can be made between restricted ICC profiles and unrestricted ICC profiles. To that end, the first type value can be ‘rICC’ whereas the second type value can be ‘prof’. This reuses the 4CCs used for the colour_type value of the conventional colour boxes ‘coir’. There may be other 4CCs (not corresponding to a colour_type value) like ‘jpxl’ for JPEG-XL compressed ICC profile, or ‘ciic’ for “compressed ICC” profile. While the former indicates the compression in use, the latter would require additional property (e.g. 13134 described below) to indicate the compression algorithm or type in use. To ensure appropriate link to the corresponding image, the colour item box includes a reference to the associated image item box. In the example, Colour 2 item box 13113 includes a reference to Image 1 item box 13111 whereas Colour 3 item box 13114 includes a reference to Image 2 item box 13112. In embodiments, the reference is made through an item reference type ‘iccr’ (or any other not conflicting 4CC) targeting the image item box. In other words, the ICC profile item is linked to the image item via an item reference type of type ‘iccr’. The offloaded colour information data are stored in the media data box 13200 as 13203 for the second colour property (2) and as 13204 for the third colour property (3). To ensure proper retrieval of the colour information data based on the corresponding colour item boxes 13113 and 13114, the metadata box comprises the item location box 13150 linking each colour item box 13113 / 13114 with the corresponding colour information data 13203 / 13204 in the media data box 13200. Therefore, when an image item is associated to a ‘coir’ box with an ‘extc’ colour_type, this image item references via an item reference type ‘iccr’ the corresponding ICC profile item. The payload of the ICC profile item can therefore be found from the I tern Location Box 13150. In some embodiments, the colour information data (all or part) in the media data box are stored uncompressed. This is for example the case of Colour 2 data 13203. In some embodiments, the colour information data (all or part) in the media data box are stored as compressed. This is for example the case of Colour 3 data 13204. Any signalling of the data compression as described above can be used. For example, a compression configuration property box ‘cmpC’ 13134 (e.g., 700 in Figure 7 or any variant thereof) associated with the colour item can be added to the property container box 13130. In the example, the property association box 13140 links item 4 in the item information box 13110 (here Colour 3 item 13114) to property box 4 in the property container box 13130 (here ‘cmpC’ box 13134). The media player is therefore able to detect, through the ‘cmpC’ box 13134 and the association in box 13140, the Colour 3 data 13204 are compressed. The above shows that an ICC profile item may be compressed or not depending on the presence or absence of “compression property” associated with this item. As shown in the scenario of Figure 13, there may be multiple ICC profile items, one per ‘coir’ box associated with an image item. To summarize the above with respect to the colour information associated with an image, the ‘coir’ box syntax is extended with a new colour type ‘extc’ indicating an “external” colour (or any 4CC not conflicting with existing ones). For example, the colour properties 13132 and 13133 have their colour_type field set to ‘extc’, meaning that all or part of the payloads of these colour information, for example ICC profiles, are not within the ‘coir’ box itself but rather in a media data box like 13200, as illustrated by the data blocks 13203 and 13204. The colour items 13113 and 13114, for example ICC profiles, are described as items with a new item_type, for example ‘iccp’ (or any 4CC not conflicting with existing ones). An ICC profile item may be compressed in the media data box or not, depending for example on the presence or absence of “compression property” (any variants of box 700) associated with this item. For example, the colour item 13114 (the 4th one in the item information box) is associated with a compression configuration property 13134 in the property association box 13140, meaning that its payload 13204 is compressed. In contrast, the colour item 13113 has a payload 13203 that is not compressed because item 13113 is not associated with any compression configuration property (or any other signalling of compression). A new item_type ‘iccp’ is therefore defined to indicate that a metadata item represents an ICC profile. When the payload of this item is stored as compressed, it is associated with a compression configuration property ‘cmpC’ (defined in AMD2 of uncompressed file format or as illustrated by 700 in Figure 7). In embodiments, a modified syntax for the colour box ‘coir’ can be as follows: class ColourlnformationBox extends Box('coir') { unsigned int(32) colour type; if (colour type == 'nclx') / * on-screen colours * / unsigned int i (16) colour primaries; unsigned int i (16) transfer characteristics; unsigned int i (16) matrix coefficients; unsigned int i ID full range flag; unsigned int i (7) reserved = 0; } else if (colour type == 'rICC') { ICC profile; / / restricted ICC profile } ---else—if—(colour typo ——'prof' ) ------F ------ICC profile;-- / / unrestricted ICC profile else if (colour type == 'extc') / / (external colour) { / / empty payload } } With the same semantics as defined in ISOBMFF, the unrestricted ICC profiles, identified by the colour_type=‘prof’, are now offloaded, i.e., stored in the media data part. In some embodiments, rather than having an empty payload in the case where coiour_type == ' extc', the item_ID (an item identifier of an item declared in the information box, for example item_ID for 13113 or 13114) is indicated in the box. As a result, the payload can be retrieved by checking the item location box 13150 for this item_ID. Furthermore, the colour item 13113 or 13114 may no longer need to be linked to its respective image item 13111 or 13112, as the image item gets linked through the item_ID provided in the ‘coir’ box with the external colour type indication (‘extc’). In variants, the ‘coir’ box still allows unrestricted profiles to offer flexibility for image writers, especially when the ICC profile is considered small. It means the colour_type ‘prof’ is kept to include such small unrestricted ICC profiles directly within the ‘coir’ box, and the colour_type ‘extc’ is used to offload bigger unrestricted ICC profiles. In yet other variants, the ‘coir’ box only keeps ‘nclx’ information in the box and stores systematically the ICC profiles (unrestricted, restricted, compressed) in the media data part 13200, thus allowing the syntax to be simplified as follows: class ColourlnformationBox extends Box('coir') { unsigned int(32) colour type; if (colour type == 'nclx') / * on-screen colours * / { unsigned int(16) colour primaries; unsigned int(16) transfer characteristics; unsigned int(16) matrix coefficients; unsigned int(l) full range flag; unsigned int(7) reserved = 0; } else if (colour type == 'extc') / / (external colour) { / / empty payload } } The proposed modified ‘coir’ box applies to still images. It may also apply to video tracks having one or more ‘coir’ boxes declared in a sample entry. The colour_type may be set to ‘extc’ to offload colour information data to the media data part. Colour items such as 13113 and 13114 are used to ensure the link between the image and the offloaded colour information data. Since the video track is made of multiple samples, one or more samples can be linked to one or other items (hence to corresponding colour information data) through a sample-to-item (‘stmi’) sample group. The ‘stmi’ box may have a meta_box_handler_type set to ‘meta’ (for metadata) or directly to ‘extc’ for external colour or to the item type ‘iccp’ for ICC profile. The item_id in the box may be an identifier (item_ID) of an item with item_type=’iccp’, i.e., indicating an ICC profile. When only one ICC profile applies to all the samples of a track, static and default sample group can be used. In a variant, when the colour information applies to all samples of a track, the track itself (instead of samples) may be linked to an item with item_type=’iccp’ through a track reference type, for example ‘iccr’, for “ICC reference”. This requires the media file to have a ‘unif’ brand that is declared in the list of compatible brands, to indicate unified handling of identifiers, for example across tracks, track groups, entity groups, and file level MetaBoxes (declaring the item IDs). The modified ‘coir’ box and / or the colour items (e.g., 13113, 13114) may be used in the mapping process of steps 513 or 512 of Figure 5. For example, when icc_data are compressed in a compact image file format, they may be converted into a compressed HEIF as a colour property item (‘coir’ box 13132 or 13133) with colour_type set to ‘extc’. In that case, the compressed icc_data payload is put in the media data part (box 13200) of the HEIF file and a colour item (13113 or 13114) with item_type = ‘iccp’ is created to link the colour item to the image item to which it applies. A compression configuration property ‘cmpC’ box (e.g., 13134) is created with an indication of the compression type in use in the compact image file format in the compression_type value. If icc_data in the compact image format is not compressed, the compression configuration property is not needed. Depending on the ‘coir’ box variant and on the size of the icc_data, the payload may be stored within the ‘coir’ box (13132 or 13133) or in the media data box (13200) and declared as an ‘iccp’ (uncompressed) item. As more generally described in the above embodiments, alternatives to the use of the compression configuration box can be used for the colour items, for example distinct item types for compressed and uncompressed items, declaration in distinct item info entry types, etc... In the example of Figure 13, two colour item property boxes 13131 and 13132 are associated with the same image item box 13111. The first property box 13131 has all its property information data included in the box itself. The second property box 13132 has some property information data offloaded into the media data part 13200. The proposed mechanism may therefore coexist with the conventional storage of colour information data in the ‘coir’ box itself, for colour information data related to the same image item. Although the above offload mechanisms keep a ‘coir’ box with no or few colour information data, variants may remove the ‘coir’ box from the property container box 13130 and only provide a corresponding colour item (13113, 13114) with the colour information data offloaded in the media data part 13200. There may be more than one colour item associated with an image item and depending on the type of the colour item (either as a box type or as a dedicated field in the item description), precedence rules may be defined with a colour item acting as a default or fallback and with one or more colour items providing advanced colour information. This allows players not supporting an advanced colour information, like a specific ICC profile, to apply the default colour item and render a version of the image described by an image item. These colour items may be placed in order in the item information box starting with the most accurate (and potentially the most difficult to process), in progression to the least. In the scenario of ‘coir’ box removal, an encapsulation of an image in an ISOBMFF-based media file may comprise obtaining data of an image, obtaining colour information data associated with the image, and generating a multi-box structure to include the obtained image data and the colour information data. The multi-box structure includes a metadata box (having an item information box and an item properties box) and a media data box. The metadata box (the item information box therein) includes an image item box describing the image and a second item box (e.g., colour item) describing the colour information data. Finally, the media data box comprises the obtained image data and the obtained colour information data. Figure 14 is a schematic block diagram of a computing device 1400 for implementation of one or more embodiments of the invention. The computing device 1400 may be a device such as a micro-computer, a workstation or a light portable device. The computing device 1400 comprises a communication bus connected to: - a central processing unit 1401, such as a microprocessor, denoted CPU; - a random access memory 1402, 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; - a read only memory 1403, denoted ROM, for storing computer programs for implementing embodiments of the invention; - a network interface 1404 is typically connected to a communication network over which digital data to be processed are transmitted or received. The network interface 1404 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 1401; - a graphical user interface 1405 may be used for receiving inputs from a user or to display information to a user; - a hard disk 1406 denoted HD may be provided as a mass storage device; - an I / O module 1407 may be used for receiving / sending data from / to external devices such as a video source or display. The executable code may be stored either in read only memory 1403, on the hard disk 1406 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 1404, in order to be stored in one of the storage means of the communication device 1400, such as the hard disk 1406, before being executed. The central processing unit 1401 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 1401 is capable of executing instructions from main RAM memory 1402 relating to a software application after those instructions have been loaded from the program ROM 1403 or the hard-disc (HD) 1406 for example. Such a software application, when executed by the CPU 1401, causes the steps of the flowcharts of the invention to be performed. 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”). 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. 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

1. A method for encapsulating an image in an ISOBMFF-based media file, the method comprising in a processing device:obtaining data of an image,obtaining property information data of a first property associated with the image, generating a multi-box structure to include the obtained image data and the property information data, wherein the multi-box structure includes a metadata box and a media data box, the metadata box includes a first item box describing the image and a first item property box that is associated with the first item box to describe the first property of the image, the media data box includes the obtained image data,wherein, when a property attribute in the first item property box takes a first value signalling at least a part of the property information data is stored in the media data box, the metadata box comprises a second item box that is associated with the first item box to describe part of the first property of the image and that is linked to the part of property information data stored in the media data box.

2. The method of Claim 1, wherein the property attribute is defined to take either the first value to signal at least a part of the property information data is stored in the media data box or a second value to signal the entire property information data are stored in the first item property box.

3. The method of Claim 2, wherein the first item property box is a colour information box, and the second value is ‘nclx’ or the second value is one of ‘nclx’ and ‘rICC’.

4. The method of Claim 1, wherein the metadata box comprises an item location box linking the second item box with the part of property information data stored in the media data box.

5. The method of Claim 1, wherein the part of property information data stored in the media data box is uncompressed.

6. The method of Claim 1, wherein the part of property information data stored in the media data box is compressed.

7. The method of Claim 6, wherein the metadata box includes a signalling that the part of property information data is compressed, the signalling being performed via one of the following options:a presence of a compression configuration property in a second item property box and associated with the second item box;an item_type equal to ‘uri ’ in the second item box, combined with an item_uri_type in the second item box set to a dedicated value signalling a compression of the part of property information data;a dedicated item_type in the second item box that signals compression of any type of data element corresponding to the part of property information data;signalling that the second item box describes a derived item from a third box declaring a third item that also describes property information data, wherein the second item box indicates, as derivation operation, a decompression scheme corresponding to a scheme used to compress the property information data;the presence of the second item box in a second list within a Container box, wherein the Container box has a version value that defines the box as including a first list of boxes describing property information data that are not compressed and the second list of boxes, as a separate list, describing property information data that are compressed;including, within a link box that links the second item box to the part of property information data stored in the media data box, a compression field in association with the second item box.

8. The method of Claim 1, wherein the part of property information data includes colour information data.

9. The method of Claim 1, wherein the part of property information data includes ICC profile data.

10. The method of Claim 1, wherein the first item box is associated with the second item box in an item reference box.

11. The method of Claim 1, wherein the second item box includes an item type set to a unique type value to signal the first property of the image, whatever the property information data described by the second item box.

12. The method of Claim 1, wherein the second item box includes an item type set to a first type value when the property information data described by the second item box relate to a first property attribute or to a second type value when the property information data described by the second item box relate to a second property attribute.

13. The method of Claim 1, wherein the metadata box includes a second item property box that is associated with the first item box, has the same box type as the first item property box to describe a second property of the image, wherein all propertyinformation data defining the second property of the image are included in the second item property box whereas at least part of the property information data defining the first property of the image is included in the media data box.

14. The method of Claim 13, wherein the first and second item property boxes are colour information boxes, wherein a colour type included in the second item property box is ‘nclx’ or is one of ‘nclx’ and ‘rICC’, whereas a colour type included in the first item property box is the first value.

15. A method for processing data comprising in a processing device:obtaining an ISOBMFF-based media file having a multi-box structure encapsulating media data of an image and property information data of a first property associated with the image, wherein the multi-box structure includes a metadata box and a media data box, the metadata box includes a first item box describing the image and a first item property box that is associated with the first item box to describe the first property of the image,retrieving the media data of the image from the media data box, retrieving a property attribute from the first item property box, in case the property attribute takes a first value signalling at least a part of the property information data is stored in the media data box, retrieving the part of the property information data from the media data box, using a second item box that is associated with the first item box to describe part of the first property in the metadata box and that is linked to the part of property information data stored in the media data box,processing the retrieved property information data together with the retrieved image data.

16. A method for encapsulating an image in an ISOBMFF-based media file, the method comprising in a processing device:obtaining data of an image;obtaining accompanying non-pixel data associated with the image that are compressed, andgenerating a single box that includes the obtained image data and the compressed non-pixel data.

17. The method of Claim 16, wherein the single box includes a signalling that the accompanying non-pixel data are compressed.

18. The method of Claim 17, wherein the signalling includes at least one flag that takes a first value in a case where the accompanying non-pixel data are notcompressed in the single box or a second value in a case where the accompanying nonpixel data are compressed in the single box.

19. The method of Claim 17, wherein a signalling is provided in the single box per each accompanying data element corresponding to accompanying non-pixel data provided in the single box.

20. The method of Claim 19, wherein a flag for signalling the compression of the accompanying non-pixel data is provided in the single box only if a presence flag of the accompanying non-pixel data is set to true.

21. The method of Claim 20, wherein the compression signalling flag and the presence flag of the accompanying non-pixel data are two separate binary fields in the single box.

22. The method of Claim 17, wherein the signalling includes one compression signalling flag common to all types of accompanying data element corresponding to accompanying non-pixel data provided in the single box or to all types of a plurality of accompanying data elements corresponding to accompanying non-pixel data provided in the single box.

23. The method of Claim 17, wherein the signalling is provided within control flags of a MinimizedimageBox box in the meaning of ISO / IEC 23008-12:2024 / CDAM 2:2024.

24. The method of Claim 16, wherein the obtaining of the compressed accompanying non-pixel data includes obtaining uncompressed non-pixel data and compressing them.

25. The method of Claim 24, wherein the accompanying non-pixel data to compress are selected based on a predefined criterion.

26. The method of Claim 16, wherein multiple accompanying data elements are associated with the image; uncompressed accompanying non-pixel data corresponding to each accompanying data element are compressed separately; and the single box includes a size indication of the size of each separately compressed non-pixel data of the multiple accompanying data elements.

27. The method of Claim 16, wherein the single box is a MinimizedimageBox box in the meaning of ISO / IEC 23008-12:2024 / CDAM 2:2024.

28. The method of Claim 16, wherein the image data and accompanying non-pixel data are obtained from an HEIF or ISOBMFF media file, wherein the accompanying non-pixel data are described by an item associated with an image item describing the image or are provided in an item property box associated with the image item.

29. A method for processing data, the method comprising in a processing device:obtaining an ISOBMFF-based media file encapsulating media data of an image, obtaining, from the ISOBMFF-based media file, a single box to retrieve data of the image and compressed accompanying non-pixel data associated with the image, andprocessing the compressed accompanying non-pixel data.

30. A method for encapsulating an image in an ISOBMFF-based media file, the method comprising in a processing device:obtaining data of an image;obtaining accompanying non-pixel data associated with the image that are compressed,generating a multi-box structure to include the obtained image data and the compressed non-pixel data, wherein a first box of the multi-box structure declares a first item describing the image and a second and separate box that is associated with the first box describes an accompanying data element corresponding to the compressed accompanying non-pixel data,wherein the multi-box structure includes a signalling that the accompanying non-pixel data described by the second box are compressed, the signalling being performed via one of the following options:a compression configuration property in an item property box associated with the second box;an item_type equal to ‘uri ’ in the second box, combined with an item_uri_type in the second box set to a dedicated value signalling a compression of the accompanying non-pixel data;a dedicated item_type in the second box that signals compression of any type of data element corresponding to accompanying non-pixel data;signalling that the second box describes a derived item from a third box declaring a third item that also describes the accompanying non-pixel data, wherein the second box indicates, as derivation operation, a decompression scheme corresponding to a scheme used to compress the accompanying non-pixel data;the presence of the second box in a second list within a Container box, wherein the Container box has a version value that defines the box as including a first list of boxes describing accompanying non-pixel data that arenot compressed and the second list of boxes, as a separate list, describing accompanying non-pixel data that are compressed;including, within a link box that links the second box to the accompanying non-pixel data stored in a separate media data box, a compression field in association with the second box.

31. The method of Claim 30, wherein the second box or the item property box or the link box further includes one or more fields to indicate compression parameters used for compressing the accompanying non-pixel data.

32. A method for processing data, the method comprising in a processing device:obtaining an ISOBMFF-based media file having a multi-box structure encapsulating media data of an image and accompanying non-pixel data associated with the image, wherein a first box of the multi-box structure declares a first item describing the image and a second and separate box that is associated with the first box describes the accompanying non-pixel data, wherein the multi-box structure includes a signalling of a compression status of the accompanying non-pixel data from one of the following options:a compression configuration property in an item property box associated with the second box;an item_type equal to ‘uri ’ in the second box, combined with an item_uri_type in the second box set to a dedicated value signalling a compression of the accompanying non-pixel data;a dedicated item_type in the second box that signals compression of any type of data element corresponding to accompanying non-pixel data;signalling that the second box describes a derived item from a third box declaring a third item that also describes the accompanying non-pixel data, wherein the second box indicates, as derivation operation, a decompression scheme corresponding to a scheme used to compress the accompanying non-pixel data;the presence of the second box in a second list within a Container box, wherein the Container box has a version value that defines the box as including a first list of boxes describing accompanying non-pixel data that are not compressed and the second list of boxes, as a separate list, describing accompanying non-pixel data that are compressed;including, within a link box that links the second box to the accompanying non-pixel data stored in a separate media data box, a compression field in association with the second box, andprocessing the accompanying non-pixel data depending on the signalling.5 33. A processing device comprising a processing unit configured for carryingout each step of any method of Claims 1 to 32.

34. A computer program product for a programmable apparatus, the computer program product comprising instructions for carrying out each step of any method of Claims 1 to 32.10 35. A non-transitory computer-readable storage medium storing instructionsof a computer program for implementing any method of Claims 1 to 32.A

Images