用于在容器文件格式中以信号发送信息的装置和方法与流程

本解决方案总体涉及在容器文件格式中以信号发送信息。

背景技术：

许多媒体文件格式的语法基于带前缀的数据块或盒的类型和长度的分层列表，其中命名取决于所讨论的格式。在根据iso基本媒体文件格式(isobmff；iso/iec14496-12)的容器文件中，媒体数据和元数据被安排在各种类型的盒中。许多格式派生自isobmff，包括高效图像文件格式(heif，iso/iec23008-12)、mpeg-4文件格式(iso/iec14496-14，也称为mp4格式)、用于nal单元结构化视频的文件格式(iso/iec14496-15)和3gpp文件格式(3gppts26.244，也称为3gp格式)。这些格式使用相同的盒结构化基本结构。

高效视频编码(hevc)是一种高效的视频压缩标准，其也称为h.265和mpeg-h第2部分。高效图像文件格式(heif)基于hevc，并且是一种用于存储数字图像和图像序列的文件格式。

技术实现要素：

本实施例通过提供用于存储可以在例如社交图像应用和图像管理系统中使用的逻辑信息的机制来改进当前版本的heif。各方面包括方法、装置和包括存储在其中的计算机程序的计算机可读介质，其特征在于独立权利要求中所陈述的内容。在从属权利要求中公开了各种实施例。

根据第一方面，提供了一种方法，包括：从图像捕获部件接收视觉数据，所述视觉信息包括多个实体；处理该视觉数据以确定所述多个实体中的至少所选择的实体的一个或多个分组类型；将所述一个或多个分组类型存储为容器文件格式的元数据，所述一个或多个分组类型与所选择的所述实体相关联；以及将元数据与所述视觉数据相关联地包括到容器文件中。

根据第二方面，提供了一种装置，包括：用于从图像捕获部件接收视觉数据的部件，所述视觉信息包括多个实体；用于处理该视觉数据以确定所述多个实体中的至少所选择的实体的一个或多个分组类型的部件；用于将所述一个或多个分组类型存储为容器文件格式的元数据的部件，所述一个或多个分组类型与所选择的所述实体相关联；以及用于将元数据与所述视觉数据相关联地包括到容器文件中的部件。

根据第三方面，提供了一种装置，包括至少一个处理器和包括计算机程序代码的存储器，其中计算机程序代码包括指令，该指令当由处理器执行时，使该装置：从图像捕获部件接收视觉数据，所述视觉信息包括多个实体；处理该视觉数据以确定所述多个实体中的至少所选择的实体的一个或多个分组类型；将所述一个或多个分组类型存储为容器文件格式的元数据，所述一个或多个分组类型与所选择的所述实体相关联；以及将元数据与所述视觉数据相关联地包括到容器文件中。

根据第四方面，提供了一种包括计算机程序代码的计算机程序产品，该计算机程序代码被配置为，当在至少一个处理器上执行时，使装置或系统：从图像捕获部件接收视觉数据，所述视觉信息包括多个实体；处理该视觉数据以确定所述多个实体中的至少所选择的实体的一个或多个分组类型；将所述一个或多个分组类型存储为容器文件格式的元数据，所述一个或多个分组类型与所选择的所述实体相关联；以及将元数据与所述视觉数据相关联地包括到容器文件中。

根据实施例，多个实体包括突发图像、收藏夹、相册图像、图像集合、图像序列、视频轨道。

根据实施例，关于分组类型的信息被存储为容器文件的元数据。

根据实施例，与多个实体中已被确定为共享相同分组类型的一个或多个实体相关联的描述性信息被存储为容器文件的元数据。

根据实施例，容器文件格式是高效图像文件格式或高效图像文件兼容存储格式。

根据实施例，视觉数据与所述容器文件格式中的一个或多个分组类型一起被发送到能够解译所发送的视觉数据的呈现设备或媒体处理系统。

附图说明

下面将参照附图更详细地描述各种实施例，其中

图1示出了根据实施例的装置；

图2示出了根据实施例的容器的示例，其中该容器包括不同逻辑组中的图像；

图3示出了容器文件格式的示例；

图4示出了根据容器文件格式的实施例的元数据盒的示例；

图5是示出根据实施例的方法的流程图。

具体实施方式

在下文中，将在iso基本媒体文件格式(isobmff)(诸如高效图像文件(heif)格式或高效图像文件兼容存储格式(例如，mpeg-4))的上下文中描述若干实施例。然而，应当认识到，本实施例的教导也可以应用于其他容器文件格式。

图1示出了根据实施例的适合用于数据处理的计算机系统。该计算机系统的通用结构将根据该系统的功能块来解释。可以利用单个物理设备执行若干功能，例如，如果需要，所有计算过程都可以在单个处理器中执行。根据图1的示例的装置的数据处理系统包括主处理单元100、存储器102、存储设备104、输入设备106、输出设备108和图形子系统110，它们都经由数据总线112彼此连接。

主处理单元100是被布置为处理数据处理系统内的数据的传统处理单元。主处理单元100可以包括或被实现为一个或多个处理器或处理器电路。存储器102、存储设备104、输入设备106和输出设备108可以包括如本领域技术人员所认识到的传统组件。存储器102和存储设备104存储数据处理系统100中的数据。计算机程序代码驻留在存储器102中。输入设备106将数据输入到该系统中，而输出设备108从数据处理系统接收数据，并将数据转发给例如显示器。数据总线112是传统数据总线，并且尽管被显示为单线，但它可以是以下各项的任意组合：处理器总线、pci总线、图形总线、isa总线。因此，本领域技术人员容易认识到，该装置可以是任何数据处理设备，诸如计算机设备、个人计算机、服务器计算机、移动电话、智能电话或因特网接入设备，例如因特网平板计算机。

需要理解的是，不同实施例允许在不同元件中执行不同的部分。例如，计算机系统的各种过程可以在一个或多个处理设备中执行；例如，完全在一个计算机设备中执行，或者在一个服务器设备中执行，或者跨多个用户设备执行。

下面描述isobmff的一些概念、结构和规范作为容器文件格式的示例，基于该容器文件格式可以实现实施例。如上所述，本发明的各方面不限于isobmff，而是针对一种可能的基础给出该描述，在该基础上可以部分或全部实现本改进方案。

isobmff是包含用于呈现的定时媒体信息的文件格式，即用于媒体数据的定时、结构和媒体信息。iso基本媒体文件格式中的基本构建块被称为盒。盒是由唯一标识符(例如，四字符代码(4cc))和长度定义的面向对象的构建块。每个盒都有报头和有效载荷。盒报头以字节指示盒的类型和盒的大小。盒可以包含其他盒，并且iso文件格式指定在特定类型的盒内允许哪些盒类型。此外，在每个文件中，一些盒的存在可以是强制性的，而其他盒的存在可以是可选的。此外，对于一些盒类型，在文件中出现多于一个盒可能是可允许的。因此，iso基本媒体文件格式可以被认为指定盒的分层结构。

根据iso文件格式系列，文件包括封装在盒中的媒体数据和元数据。

在符合iso基本媒体文件格式的文件中，媒体数据可以在mediadatabox‘mdat’中提供，并且moviebox‘moov’可以用来封入元数据。在一些情况下，为了使文件可操作，可能需要存在‘mdat’和‘moov’盒两者。电影‘moov’盒可以包括一个或多个轨道，并且每个轨道可以驻留在一个相应的trackbox‘trak’中。轨道可以是许多类型之一，包括指根据媒体压缩格式(及其对iso基本媒体文件格式的封装)格式化的样本的媒体轨道。

例如，当将内容记录到iso文件时，电影片段可以被使用，例如，以便在记录应用崩溃、存储器空间耗尽或发生一些其他事件时避免丢失数据。在没有电影片段的情况下，可能发生数据丢失，因为文件格式可能要求所有元数据(例如，电影盒)被写入文件的一个连续区域中。此外，当记录文件时，可能没有足够的存储空间量(例如，随机存取存储器ram)来针对可用存储的大小来缓冲电影盒，并且当电影被关闭时重新计算电影盒的内容可能太慢。此外，电影片段可以使用常规iso文件解析器来支持文件的同时记录和回放。此外，对于快进下载可能需要较小的初始缓冲持续时间，例如当电影片断被使用时同时接收和回放文件，并且与具有相同媒体内容但不以电影片断结构化的文件相比，初始电影盒更小。

电影片段功能可以实现将元数据拆分成多个片，否则这些元数据可能驻留在电影盒中。每个片可以对应于轨道的特定时间段。换言之，电影片段功能可以实现文件元数据和媒体数据的交织。因此，电影盒的大小可以被限制，并且上述用例可以被实现。

在一些示例中，如果电影片断的媒体样本与‘moov’盒在同一文件中，则电影片断的媒体样本可以驻留在‘mdat’盒中。然而，对于电影片断的元数据，可以提供‘moof’盒。‘moof’盒可以包括先前已经在‘moov’盒中的重放时间的特定持续时间的信息。‘moov’盒本身仍然可以表示有效的电影，但是除此之外，它还可以包括‘mvex’盒，其指示电影片段将跟随在同一文件中。电影片断可以在时间上扩展与‘moov’盒相关联的呈现。

在电影片断内可以存在一组轨道片断，根据轨道包括从零到多个的任何数量。轨道片段转而可以包括从零到多个轨道串，每个文档是该轨道的一串连续样本。在这些结构内，许多字段是可选的，并且可以缺省设置。可以包括在‘moof’盒中的元数据可以被限制为可以包括在‘moov’盒中的元数据的子集，并且在一些情况下可以被不同地编码。关于可以包括在‘moof’盒中的盒的详细信息可以从iso基本媒体文件格式规范中找到。自包含的电影片段可以被定义为包括‘moof’盒和‘mdat’盒，其按照文件顺序上是连续的，并且其中‘mdat’盒包含电影片段的样本(‘moof’盒为其提供元数据)，并且不包含任何其他电影片段的样本(即，任何其他‘moof’盒)。

轨道引用机制可用于将轨道彼此关联。trackreferencebox包括(多个)盒，每个盒提供从包含轨道到一组其他轨道的引用。这些引用通过所包含的(多个)盒的盒类型(即，盒的四字符代码)进行标记。语法可以被指定如下：

track_ids可以被指定为提供所引用轨道的轨道标识符或所引用轨道组的track_group_id值的整数数组。track_ids[i]的每个值(其中i是track_ids[]数组的有效索引)是整数，它提供从包含轨道到track_id等于track_ids[i]的轨道或到track_group_id等于track_ids[i]并且trackgrouptypebox的标志字段的特定位(例如，最低有效位)等于1的轨道组的引用。当track_group_id值被引用时，轨道引用单独应用于所引用轨道组的每个轨道，除非在特定轨道引用类型的语义中另有说明。可以不允许存在值0。

轨道分组机制实现了对轨道组的指示，其中每个组共享特定特性或者组内的轨道具有特定关系。trackgroupbox可以被包含在trackbox中。trackgroupbox包含从trackgrouptypebox得到的零个或多个盒。特定的特性或关系由所包含的盒的盒类型来指示。所包含的盒包括标识符，该标识符可用于推断属于相同的轨道组的轨道。在trackgroupbox内包含相同类型的所包含盒并且在这些所包含盒内具有相同标识符值的轨道属于相同的轨道组。

iso基本媒体文件格式包含用于可与特定样本相关联的定时元数据的三种机制。术语“样本”指的是文件中具有单个时间戳的任何数据，例如视频的单独帧、解码顺序中的一系列视频帧、解码顺序中的音频的压缩段。这些机制包括：样本组、定时元数据轨道和样本辅助信息。派生的规范可以利用这三种机制中的一种或多种来提供类似的功能。

基于分组准则，iso基本媒体文件格式及其派生物的样本分组可以被定义为将轨道中的每个样本分配给一个采样组的成员。样本分组中的样本组不限于连续的样本，并且可以包含不相邻的样本。由于针对轨道中的样本可能存在多于一个的样本分组，因此每个样本分组可以具有指示分组类型的类型字段。样本分组可以由两个相链接的数据结构来表示：(1)sampletogroupbox(‘sbgp’)表示将样本分配给样本组；以及(2)samplegroupdescriptionbox(‘sgpd’)包含用于描述组的属性的每个样本组的样本组条目。基于不同的分组准则，可能存在sampletogroupbox和samplegroupdescriptionbox的多个实例。这些可以通过用于指示分组类型的类型字段来区分。sampletogroupbox可以包括可用于例如指示分组的子类型的grouping_type_parameter字段。

高效图像文件格式(heif)包括构建在广泛使用的iso基本媒体文件格式(isobmff)之上的丰富特征集合，使heif在特征方面优于其他图像文件格式。在本公开中，术语“heif”、“isobmff”和“文件格式”可以互换使用。

在heif的设计中，很大程度上使用了isobmff结构和特征。针对heif的基本设计包括静止图像被存储为项目，并且图像序列被存储为轨道。heif实现在同一容器文件中存储多个图像和图像序列。

在heif的上下文中，以下盒可以被包含在根级‘meta’盒中，并且可以如下所述来使用(另见图4以用于说明)。在heif中，‘meta’盒的handlerbox(‘hdlr’)的处理程序值是‘pict’。包含经编码的媒体数据的资源(无论是在同一文件内，还是在由统一资源标识符标识的外部文件中)通过datainformationbox(‘dinf’)被解析，，而itemlocationbox(‘iloc’)存储所引用文件内的每个项目的位置和大小。itemreferencebox(‘iref’)使用类型化引用来记录项目之间的关系。如果在项目集合当中存在以某种方式被认为是与其他项目相比最重要的项目，则该项目由primaryitembox(‘pitm’)发信号通知。除了这里提到的盒外，‘meta’盒还可以灵活地包括描述项目可能需要的其他盒。

任意数量的图像项目可以被包含在同一文件中。给定通过使用‘meta’盒方法存储的集合图像，可能需要限定图像之间的某些关系。这些关系的示例包括指示针对集合的封面图像、针对集合中的一些或所有图像提供缩略图像、以及将集合中的一些或所有图像与诸如阿尔法平面的辅助图像相关联。图像集合当中的封面图像是使用‘pitm’盒指示的。缩略图像或辅助图像分别使用类型‘thmb’或‘auxl’的项目引用来链接到主图像项目。

itempropertiesbox(‘iprp’)实现将任何项目与一组有序的项目属性相关联。项目属性是较小的数据记录。itempropertiesbox(‘iprp’)包括两部分：itempropertycontainerbox‘ipco’，它包含项目属性的隐式索引列表，以及一个或多个itempropertyassociationbox(‘ipma’)，它将项目与项目属性相关联。项目属性格式化为盒。

描述性项目属性可以被定义为描述而不是变换相关联的项目的项目属性。变换性项目属性可以被定义为变换图像项目内容的重构表示的项目属性。

在heif规范中，术语“实体”用于指代图像项目或媒体轨道。这种实体可以通过使用entitytogroup盒来进行分组。此盒实现对图像、图像序列和视频轨道的分组。实体组在groupslistbox中被指示。例如，在电影级metabox的groupslistbox中指定的实体组是指电影级项目，而在文件级metabox的groupslistbox中指定的实体组是指轨道或文件级项目。

groupslistbox包含(多个)entitytogroupbox，每个指定针对文件指定的一个实体组。

groupslistbox的定义包括：

盒类型：‘grpl’

容器：未被包含在additionalmetadatacontainerbox中的metabox(‘meta’)

强制性：否

数量：0或1

entitytogroupbox的定义包括：

盒类型：如下文指定的，具有针对entitytogroupbox的grouping_type值

容器：groupslistbox

强制性：否

数量：0或无

entitytogroupbox指定实体组。盒类型(grouping_type)指示实体组的分组类型。每个grouping_type代码都与描述分组的语义相关联。

以下grouping_type值在heif或isobmff中指定：

-‘altr’：映射到此分组的项目和轨道互为备选，并且仅其中之一

应通过其他手段播放或处理；

-‘ster’：图像项目的输出图像形成适于在立体显示器上显示的立体对。

尽管项目属性和实体分组最初是在heif中指定的，但它们随后也被包括在isobmff中。

统一资源标识符(uri)可以被定义为用于标识资源名称的字符串。这样的标识实现通过网络使用特定协议与资源的表示进行交互。uri是通过为uri指定具体语法和相关联的协议的方案来定义的。uri包括方案部分(标识例如针对uri的协议)和标识资源的分层部分，并且这两个部分由冒号字符分隔。uri可以可选性地包括查询部分(由字符‘？’分隔)和/或片段部分(由字符‘#’分隔)。统一资源定位符(url)和统一资源名称(urn)是uri的形式。url可以被定义为标识web资源并指定对该资源进行操作或获得该资源的表示的手段的uri，从而指定其主要访问机制和网络位置两者。urn可以被定义为通过特定名称空间中的名称标识资源的uri。urn可用于标识资源，而无需暗示其位置或如何访问它。

url片段标识符(也可以称为url形式)可以针对特定内容类型被指定，以访问由url的基本部分(无需片段标识符)指示的资源(诸如文件)的一部分。url片段标识符可以例如通过url内的散列(‘#’)字符来标识。对于isobmff，可以指定url片段“#x”指的是track_id等于x的轨道，“#item_id＝”且“#item_name＝”指的是文件级(多个)metabox，“#/item_id＝”且“#/item_name＝”指的是moviebox中的(多个)元盒，并且“#track_id＝x/item_id＝”且“#track_id＝x/item_name＝”指的是track_id等于x的轨道中的metabox，包括在电影片段中可能发现的metabox。

当前版本的heif缺乏以逻辑方式将实体分组在一起以及支持例如以下广泛使用的特征的存储和信令的手段：

1)由多个图像和视频轨道组成的相册；

2)图像标签；

3)收藏夹。

当与现有的社交图像应用和图像管理系统相比时，缺少存储这种逻辑信息的机制会对heif格式的可用性产生负面影响。

本实施例实现了在一个容器中对关于这种分组的信息进行逻辑分组和以信号发送。根据一些实施例，定义了提供所需语义的新分组类型和规则，以便正确地解译、显示和呈现内容或相应地提供用户交互。根据一些实施例，新的描述性项目属性携带元数据以指示图像和图像序列如何彼此在逻辑上相关。本实施例加强了heif将关于图像、(多个)图像序列和/或(多个)媒体轨道的所有相关信息保存在同一容器中的承诺，因为作为该解决方案的结果，无需以某种其他形式在文件格式之外携带这类信息。

针对heif文件格式的新定义和约束旨在存储图像和图像序列。

对于以下方法中的每一种都呈现了单独的实施例：

1.逻辑实体到组盒；

2.逻辑组属性；

3.标签属性；

4.用于逻辑组和/或标签的url(统一资源定位符)片段方案；

5.用于逻辑组和/或标签的url查询字符串。

下面参照特定语法呈现实施例。需要理解的是，所呈现的语法仅是实现本发明的示例，并且实施例可以类似地通过备选语法来形成。例如，在以下语法和类似实施例中，关于分组类型的信息可以包括但不限于以下一个或多个：

-枚举的逻辑分组类型值；

-组名称的文本字符串；

-组描述的文本字符串；

-描述组的零个或多个文本标签；

-对于以上一个或多个项目，算法或信息提供者的标识符(例如，urn或通用唯一标识符，uuid)。

下面将以更详细的方式讨论针对新定义和约束的每个先前呈现的实施例。该详细讨论提供了有关每个盒的定义、语法和语义的信息。

1.逻辑实体到组盒：

定义：

盒类型：‘lgrp’

容器：groupslistbox

强制性(根据项目)：否

数量(根据项目)：零个或多个

语法：

logicalentitytogroupbox扩展entitytogroupbox，以便提供附加元数据来用于分组多个实体。

logical_group_type是指示分组类型的无符号整数。逻辑分组类型可以包括但不限于以下各项：

0：未定义

1：相册

2：收藏夹

3：<其他附加类型>

group_name是以null结尾的字符串，其包含针对实体逻辑组的人类可读名称。

group_description是以null结尾的字符串，其包含实体逻辑组的人类可读描述。

group_tags是以null结尾的字符串，其包含关于可能是格式良好的有效载荷的逻辑组的任何附加信息。

在盒内部列出的项目和轨道在所定义的logical_group_type之下被逻辑链接在一起。可能存在相同logical_group_type的多个实例。例如，同一图像可能属于多个相册。

参照具有id为：image_1、image_2、image_3、image_4的图像项目的heif文件，呈现了使用的示例。在此示例中，存在两个相册定义和一个收藏夹图像定义：

logicalentitytogroupbox(‘lgrp’){item_ids＝(image_1，image_2)，logical_group_type＝1，group_name＝”day1”，group_description＝”mountainphotosoftheday”，group_tags＝”mountain，sunrise，birds，lake”}

logicalentitytogroupbox(‘lgrp’){item_ids＝(image_3，image_4)，logical_group_type＝1，group_name＝”day2”，group_description＝”seasidephotosoftheday”，group_tags＝”sea，coast，ship，swimming”}

logicalentitytogroupbox(‘lgrp’){item_ids＝(image_1，image_4)，logical_group_type＝2，group_name＝”day2”，group_description＝”favoritepicsofthe2daytrip”，group_tags＝”sea，mountain，swimming”

从上面的示例可以看出，图像项可以存在于多个逻辑组中。

2.逻辑组属性：

作为实体分组的备选方案，还可以定义逻辑组属性并将其链接到适当的项目。

定义：

盒类型：‘lgrp’

属性类型：描述性项目属性

容器：itempropertycontainerbox

强制性(根据项目)：否

数量(根据项目)：零个或多个

语法：

字段的语义与logicalentitytogroupbox中的相同：

group_name是以null结尾的字符串，其包含针对实体逻辑组的人类可读名称。

group_description是以null结尾的字符串，其包含实体逻辑组的人类可读描述。

group_tags是以null结尾的字符串，其包含关于可能是格式良好的有效载荷的逻辑组的任何附加信息。

logicalgroupproperty可以通过利用itempropertyassociationbox被关联到相关图像项目，其语法呈现如下：

应当注意，当该机制被利用时，轨道可能无法被链接到逻辑组，除非扩展heif规范，使得itempropertyassociation可以既具有item_id也具有轨道id。这可以通过定义新版本的itempropertyassociationbox来实现，其中item_id被entity_id替换，并且如entitytogroupbox中所定义那样来定义entity_id。然而，由于文件向后兼容性，这可能不是优选的方法。因此，利用logicalentitytogroupbox更为有利。

3.标签属性

以上呈现的实施例(1)和(2)也可以在没有group_tags语法元素的情况下实现。本节中的实施例可以与以上任一实施例一起使用(特别是如果不存在group_tags的话)，或者独立于以上实施例使用。在该实施例中指定了标签“描述性项目属性”。与同一标签项目属性相关联的图像项目可以被视为属于由该标签表征的逻辑组。

定义：

盒类型：‘ttag’

属性类型：描述性项目属性

容器：itempropertycontainerbox

强制性(根据项目)：否

数量(根据项目)：零个或多个

语法：

textual_tag指定表征(多个)关联图像项目的单个文本标签。tagproperty可以通过利用itempropertyassociationbox与相关图像项目相关联，其语法在第(2)节“逻辑组属性”中描述。

由于项目属性特定于图像项目，因此对具有等效的logicalgroupproperty和/或tagproperty的特定于轨道的机制可能很有用。在实施例中，特定于轨道的盒包括与logicalgroupproperty和/或tagproperty中包含的信息类似的信息。例如，可以指定类型为‘lgrp’和/或‘ttag’的轨道组，并且可以扩展针对这些4cc的trackgrouptypebox以包括分别类似于logicalgroupproperty和/或tagproperty的有效载荷的语法元素。

4.用于逻辑组和/或标签的url分段方案

在实施例中，(多个)url片段方案被指定用于标识特定逻辑组和/或特定标签的图像项目。

下面给出了这样的url片段方案的示例：

-#item_group＝<group_name>

其标识具有给定组名称的实体。

-#item_tag＝<textual_tag>

其标识具有给定文本标签的实体。

-#item_property＝<property_4cc>.<base64_encoding_of_property_content>

其标识与给定的四字符代码的属性相关联的项目以及与针对该属性的给定内容相关联的项目，其中内容被base64编码到url片段中。

-#textual_item_property＝<property_4cc>.<utf8_string_of_property_content>

其标识与给定的四字符代码的属性相关联的项目以及与针对该属性的给定内容相关联的项目，其中内容是url片段中的utf8字符串。

当这样的(多个)url片段标识符与标识heif文件的url一起使用时，该url应当被解析为heif文件中与针对片段标识符给出的(多个)值相匹配的那些项目。

5.用于逻辑组和/或标签的url查询字符串

在实施例中，(多个)url片段方案被指定用于标识特定逻辑组和/或特定标签的图像项目。

这样的url查询字符串的示例包括以下各项：

-？item_group＝<group_name>

-？item_tag＝<textual_tag>

-？item_property＝<property_4cc>.<base64_encoding_of_property_content>

-？textual_item_property＝<property_4cc>.<utf8_string_of_property_content>

语义以类似于上面描述各个url片段方案的方式进行指定。

当这样的(多个)url查询字符串与所请求的url一起使用时，url应以如下方式来解析：包含与(多个)查询字符串中给出的(多个)值相匹配的(多个)图像项目的heif文件被包含在对请求的(多个)响应中。

在实施例中，文件解析器等具有接口，由此关于分组类型的信息可以被传递给文件解析器等。文件解析器等通过处理与给定信息相匹配的那些实体来处理关于分组类型的信息。例如，文件解析器可以仅解码和/或返回与关于分组类型的给定信息相匹配的那些实体。在实施例中，该接口包括url片段和/或url查询字符串，例如，如在以上实施例中所指定的。

图2示出了图像容器文件210的示例，其中图像220如在第(1)节“逻辑实体到组盒”中定义的不同逻辑组中。图像220包括id＝1、id＝2、id＝3和id＝4的图像项目。相册分组1将id＝1、id＝2的图像分组在一起，相册分组2将id＝3、id＝4的图像分组在一起，并且收藏夹分组将id＝1、id＝4的图像分组在一起。

图3是用于存储视觉数据的容器文件300的简化图示。在图3中示出并在本段中描述的容器文件300的盒形成容器文件的一个示例。因此，应当理解，在实际实现中，盒的数量和类型可能变化。该示例的容器文件300包括用于描述文件类型的filetypebox“ftyp”。容器文件300的metabox“meta”包括关于元数据、单个图像和派生图像的信息。moviebox“moov”包括具有多个trackbox“trak”的图像序列。容器文件300还可以包括用于存储有效载荷图像数据的多个mediadatabox“mdat”。在本实施例中讨论的分组定义被存储在参照图4进一步讨论的metabox“meta”310中。

图4示出了包括如本说明书前面所讨论的盒‘hdlr’、‘dinf’、‘iloc’、‘iref’、‘pim’的metabox“meta”310的示例。此外，metabox310包括本实施例涉及的groupslistbox‘grpl’和itempropertiesbox‘iprp’。根据本实施例的groupslistbox包括存储关于诸如图像的实体的逻辑分组的信息的logicalentitytogroupbox‘lgrp’420。作为groupslistbox的‘lgrp’420的备选或补充，逻辑分组可以被定义为到作为logicalentitytogroupbox‘lgrp’430的itempropertycontainerbox‘ipco’中的适当实体的链接。根据本实施例的项目propertycontainerbox‘ipco’还可以包括用于指示与标签相关联的分组实体的共享文本标签的descriptiveitempropertybox‘ttag’440。

图5是示出根据实施例的方法的流程图。该实施例的方法包括：从图像捕获部件接收510视觉数据，所述视觉数据包括多个实体；处理520视觉数据以确定所述多个实体中的至少所选择的实体的一个或多个分组类型；将所述一个或多个分组类型存储530为容器文件格式的元数据，所述一个或多个分组类型与所选择的所述实体相关联；以及将元数据与所述视觉数据相关联地包括540到容器文件中。

在实施例中，不是从图像捕获部件接收视觉数据，而是视觉数据可以由其他部件接收，诸如从通信链路和/或图像共享服务接收。

在实施例中，不是或除了处理视觉数据以确定一个或多个分组类型，至少分组类型的子集可以由其他部件来接收，这些其他部件包括但不限于用户输入和从通信链路和/或图像共享服务接收分组类型。

根据实施例的装置包括：用于从图像捕获部件接收视觉数据的部件，所述视觉数据包括多个实体；用于处理视觉数据以确定所述多个实体中的至少所选择的实体的一个或多个分组类型的部件；用于将所述一个或多个分组类型存储为容器文件格式的元数据的部件，所述一个或多个分组类型与所述所选择的所述实体相关联；以及用于将元数据与所述视觉数据相关联地包括到容器文件中的部件。

各种实施例可以借助于驻留在存储器中并使相关装置执行方法的计算机程序代码来实现。例如，设备可以包括用于处理、接收和发送数据的电路和电子设备、存储器中的计算机程序代码、以及当运行计算机程序代码时使设备实现实施例的特征的处理器。此外，像服务器这样的网络设备可以包括用于处理、接收和发送数据的电路和电子设备、存储器中的计算机程序代码，以及当运行计算机程序代码时使网络设备实现实施例的特征的处理器。该计算机程序代码包括一个或多个操作特性。所述操作特性是由所述计算机基于所述处理器的类型通过配置来定义的，其中系统可通过总线连接到所述处理器，其中该系统的可编程操作特性包括从图像捕获部件接收视觉数据，所述视觉数据包括多个实体；处理视觉数据以确定所述多个实体的至少所选择的实体的一个或多个分组类型；将所述一个或多个分组类型存储为容器文件格式的元数据，所述一个或多个分组类型与所述所选择的实体相关联；以及将元数据与所述视觉数据相关联地包括到容器文件中。

如果需要，这里讨论的不同功能可以以不同的顺序和/或与其他功能同时执行。此外，如果需要，上述功能和实施例中的一个或多个可以是可选的或可以组合。

本实施例具有优点。例如，这些实施例实现了对图像和视频轨道进行分组。通过利用实体分组机制，可以创建项目的逻辑组。这样的组可以很容易地生成和修改，只需对文件本身进行最小程度的干预。

尽管在独立权利要求中陈述了实施例的各个方面，但是其他方面包括来自所描述实施例和/或从属权利要求的特征与独立权利要求的特征的其他组合，而不仅仅是权利要求中明确陈述的组合。

这里还应注意，尽管上文描述了示例实施例，但这些描述不应以限制意义来看待。相反，存在若干变型和修改，可以在不脱离所附权利要求书中定义的本公开的范围的情况下进行这些变型和修改。