专利名称：对部分文档图像的标准化网络访问的制作方法
技术领域：
本发明涉及处理图像数据的领域；更具体讲，本发明涉及经由网络访问图像文件的某些部分。
背景技术：
JPEG 2000是众所周知的压缩标准。该标准有多个部分，并且每个部分具有多个附件。
JPEG 2000第6部分，官方称作ISO/IEC 15444-62003，信息技术-JPEG2000图像编码系统-第6部分复合图像文件格式，在本文中称为JPM标准。该标准描述了JPM文件的内容和使用。JPM标准的附件E的标题为“用于为JPM文件构建URL的指南”。JPM标准和文件格式设计成用于存储文档图像，并允许经由JPEG 2000和其它方法进行压缩，尤其是允许由G4、JBIG2和JBIG方法进行压缩，这些方法比JPEG 2000更适于压缩包括文本的二进制图像。
JPM标准列出了可能对JPM文件中的访问有用的信息，但仅仅通过举例定义了语法。更具体讲，没有定义诸如“page=43”之类的请求的返回类型。它可以指以JPEG 2000格式呈现(rendered)的页面，一个已解析的仅包括页面43的JPM文件，或者指没有任何JPM文件等级框(level boxes)的JPM文件中的与页面43相关联的框。
JPEG 2000第6部分附件E列出了请求URL的例子。JPM标准附件E中的请求URL的例子包括下列项目(以BNF形式定义，其中UINT是无符号整数，TOKEN是一个具有某些限制的字符串)page=UINT /"thumb"obj=UINTtype="meta" /"img" /"thumb"index=UINTmtype="text" /"xml"label=string
coll="main" /TOKENoffset=UINTlen=UINTJPEG 2000第9部分，官方称作ITU-T Recommendation T.808|ISO/IEC15444-92004，信息技术-JPEG 2000图像编码系统-第9部分交互工具，API及协议，(JPIP)，通常地且在本文称之为JPIP标准，是一种语法的定义，并且是一种用于通过网络交互地传递JPEG 2000图像的协议。JPIP小节C.4.7代码流上下文(JPIP Section C.4.7 Codestream Context)设计成一种使用适用于特定文件类型的高级术语来访问一个或多个代码流的机制。该小节包括用于访问JPX文件的不同组合层的语法，其定义于JPEG 2000第2部分中，并且具有用于根据一些组合指令来修改视窗的指令。使用这种具有JPIP的语法可能看起来像“context=jpxl<0-4:2>[s5i2]”，其将请求组合层0，2和4，并利用第6指令集框的第3条指令来重新绘制帧尺寸和图像区域。JPIP中的同一小节也解释了如何从MJ2文件中得到和不同轨道相关联的代码流，其定义于JPEG 2000第3部分和JPEG 2000第12部分。
还存在其它文档传递技术。例如，线性化PDF是一种以PDF格式传递文档图像的技术。这种技术依赖于利用存储在文件开头的索引信息，以特殊的格式写入PDF。这种交互完全由客户机控制。在Rowe，Edward R.，Priyadarshan，Eswar，Taft，Edward A.，McQuarrie所著的“Methods and Apparatusfor Reading multi-page electronic documents”中描述了一个例子，该文出版于1998年的Adobe Systems中。
NEC有一个称作文档跳跃者(Document Skipper)的软件产品，其是用于提供交互访问文档图像的服务器软件。文档跳跃者从具有JPEG格式中的MEAP的Canon Multifunction装置中接收图像，但为了提供多分辨分析和空间访问，把该图像转换到JPEG 2000。
发明内容
本发明的总的目的是提供一种改进并且有用的方法、装置、以及记录介质，在其中消除了上述所提到问题。
本发明更特定的目的是提供一种用于网络访问部分文档图像的方法、装置、以及记录介质。
根据本发明的一个方面，提供一种方法，特征在于接收对文档的页面的区域的请求，该请求是从客户机发起的；确定和该页面的区域相交的源文件中的一个或多个对象，该源文件具有两个或多个代码流；以及发送具有文件中的信息的子集的响应。
当结合附图阅读本发明时，本发明的其它目的、特征和优点将可以从下面的详细描述中变得更为显而易见。
图1为客户机-服务器网络的一个实施例的方框图；图2示出了JPM文件的内容和在服务器和客户机上的表示；图3示出了JPM文档的一个实施例的内容；图4为使用了纲要文档的处理过程的流程图；图5为作为JPM文件的纲要文档的例子；图6为具有本地代码流分段的纲要文档的例子；图7描述了包含PDF文件的JPM文件的例子；图8为包含一个或多个JPM文件的PDF文件的例子；图9为引用PDF文件的JPM文件的例子；以及图10为计算机系统的一个实施例的方框图。
具体实施例方式
描述了一种用于通过网络传递文档图像的方法和装置。在一个实施例中，本文所描述的技术为存储在JPM文件中的文档图像提供JPIP的交互能力。公开了支持这种传递的语法的例子，以及由客户机与服务器用来处理文档图像传递的方法。
还描述了特定的服务器实现技术、特定的客户机实现技术、以及联合PDF/JPM交互。这些包括JPIP-JPM的特定实现细节(例如，占位符框(placeholder box)的使用、偏好标记的使用、用于高速缓冲存储器(cache)文件中的URL的机制，以及客户机控制的JPIP-JPM)和PDF/JPM交互(例如，通过JPIP-JPM提供包含JPEG 2000和其它的压缩流的PDF文件服务，提供包含JPM文件的PDF文件的服务，JPM文件包含完全有效的PDF文件，提供包含PDF的JPM文件作为JPM或完全PDF文件的服务，以及用极小的额外空间来提供JPM或者PDF的服务)。此外，本文所描述的技术使用了具有PDF文件格式的JPIP标准。本文也描述了用于不必重复代码流而有效存储文档的PDF和JPM版本的技术。
在下面的描述中，阐述多个细节来提供本发明更充分的解释。然而，对一个本领域技术人员来说，显然没有这些特定细节也可以实现本发明。在其它实例中，为了避免模糊本发明，以方框图形式而不是以罗列细节的形式示出了众所周知的结构和设备。
用算法和在计算机存储器内数据位操作的符号表示的方式介绍下面详细描述的部分内容。这些算法性的描述和表示是数据处理领域技术人员惯用的手段，以便于更有效地把他们工作的实质传递给其他本领域技术人员。算法在此往往被构造成前后一致的可以导致期望的结果的步骤序列。这些步骤是要求进行物理量的物理操作的步骤。通常，虽然不是必须的，这些量表现为能够被存储、传递、合并、比较以及其它操作的电或磁信号的形式。已经证明，有时，主要是为了通常的用法的原因，把这些信号定义为位、值、元素、符号、字符、术语、数字或其它类似物是方便的。
然而应牢记，所有这些以及类似术语应和适当的物理量关联在一起，它们只是应用于这些量的方便标记。除非明确地声明，否则从下面的论述中可以显而易见，充分意识到的是，贯穿整个描述，利用诸如“处理”或“运算”或“计算”或“确定”或“显示”或类似用语的论述，指的是计算机系统或者类似的电子计算设备的动作和过程，该计算机系统将该计算机系统的寄存器和存储器内表示成物理(电子)量的数据，操作和转换为该计算机系统存储器或寄存器或其它这样的信息存储、传递或显示设备内的其它类似表示成物理量的数据。
本发明也涉及用于执行本文操作的装置。可以根据需要特别构建该装置，或者可以由一个通用计算机组成，该通用计算机由存储在计算机内的计算机程序选择性地激活或重新配置。这样的计算机程序可以存储在计算机可读存储介质内，诸如，但并不限于，任意类型的盘，包括软盘、光盘、CD-ROM、和磁光盘、只读存储器(ROM)、随机存取存储器(RAM)、EPROM、EEPROM、磁或光卡，或者适用于存储电子指令的任意类型的介质，每种存储介质都耦合到计算机系统总线上。
本文提出的算法和显示并不固有地涉及任何具体计算机或其它装置。各种通用系统可以用于根据本文的教导的程序，或者构建更专用的装置来执行所需要的方法步骤也可以证明是方便的。用于各种这类系统所需要的结构将从下面的描述中看出。另外，本发明没有参照任何具体的编程语言进行描述。应该了解，本文所描述发明的教导可以用各种编程语言来实现。
机器可读介质包括任意用于以机器(例如，计算机)可读形式存储或传递信息的机制。例如，机器可读介质包括只读存储器(‘ROM’)；随机存取存储器(‘RAM’)；磁盘存储介质；光存储介质；闪存装置；电、光、声或其它形式的传播信号(例如，载波，红外信号，数字信号等)；等等。
JPIP访问JPM文件JPIP可以用于提供JPM文件的服务。公开了通过网络使用建立在JPIP上的请求和响应通信的语法传送JPM(文档图像)文件的一部分的技术。这样做，可以实现对页的区域以及特定对象的访问。JPIP中定义的元数据仓用来为呈现期望窗口需要的对象返回的全部或部分的代码流。JPM软件提供JPM文件的增量解码，并提供JPIP服务器提供JPM文件访问所需要的索引信息。对在访问JPM文件的过程中均涉及的客户机的例子和服务器的例子也进行了描述。
图1是通过网络连接的客户机及服务器的一个实施例的方框图。参照图1，网络连接客户机100和服务器101。客户机100产生一个对JPM文件中的页面的区域的请求110。该请求可以响应于用户使用用户接口而产生。例如，客户机100可以在屏幕上向左滚动、向右滚动、向上滚动、向下滚动、放大、和/或缩小。另外，用户能够利用用户界面(或用户接口)上的按钮或其它用户接口元件调用页面向前、页面向后、以及转到页面选项上。所述请求可以包括页面编号。
服务器101接收请求110，并且，响应于该请求，确定JPM文件120中与所请求的区域相交的布局对象。服务器101发送回该文件的概要。由于该文件概要不是来自像素的压缩采样数据，所以即使该文件概要可能包括解码该文件所必须的数据，JPIP标准还是将其作为元数据仓(metadata bin)。在一个实施例中，在元数据仓中发送元数据(例如，“元数据仓0(metadata bin0)”)。概要包括一些直接从JPM文件120复制的框，以及代替许多框的占位符框(尤其是较大的框包含代码流，典型地是这些框是媒体数据框(mdat)或连续代码流框)。除了“元数据仓0”之外，服务器101发送回客户机100呈现所期望的区域所需的其它框的部分(例如，代码流)。服务器101利用客户机高速缓冲存储器模型(client cache model)130追踪发送到客户机100的信息，以便于当客户机100额外请求该JPM文件的部分时，不必重新发送信息。
客户机100接收对请求110的响应111并将其存储于高速缓冲存储器(cache)150中。利用JPM解码器160，客户机100从高速缓冲存储器150解压缩对显示该区域所必须的代码流，组合该代码流以及任何来自该文件的不变的彩色对象(color object)，并且显示所呈现的图像170。
基于用户输入(或主动地)，客户机100可以随后产生对JPM文件的不同区域、或不同比例尺、或不同页面的新的请求(未示出)。服务器101检查该新的请求，可能会中断当前响应，选择适合于该新响应的数据，以及发送适合于该新响应但之前未发送的数据。
元数据仓及占位符框概览数据仓(Databins)由JPIP服务器返回的数据被作为消息发送。这些消息是来自一个特定数据仓的字节的集合。在一个实施例中，每条消息包含一个报头，该报头识别出该消息的内容所来自的数据仓的类型以及这种类型的数据仓的编号，本文指的是“in class id”。在一个实施例中，有四种类型的数据仓元数据、主报头、标题、和区域(precinct)。元数据和主报头数据仓由基于标题(JPT-stream)和基于区域(JPP-stream)的JPIP服务器使用。标题类型的数据仓包含用于JPT-stream会话的JPEG 2000代码流的部分。区域类型的数据仓包含用于JPP-stream会话的JPEG 2000代码流的部分。该文件格式信息由元数据仓提供，该文件格式信息是文件中的所有非代码流数据。服务器101可以决定如何把一文件划分成仅受一些限制的元数据仓。在JPIP标准的第A.3小节中描述了这些限制。
在一个实施例中，在文件等级上的每个框在元数据仓0中，或者在元数据仓0中有用于该框的占位符框。下面所描述的占位符框指示用于任何不包括在元数据仓0中的框的元数据仓。
占位符框在JPIP标准的第A.3.6.3小节中定义了占位符框。当通过网络发送占位符框并将其存储在客户机上时，该占位符框代替来自原始文件的框。由于占位符框是框，因此占位符框开始于以长度和类型，该类型是‘plhd’。该占位符框也包含原始框长度和类型。因而，接收占位符框的客户机100知道被取代信息的类型。该占位符框还包含用于该原始框的内容的元数据仓编号。该元数据仓可以对客户机100无效。事实上，在许多情况下，客户机100并没有获得该原始框的内容，从而节约了带宽。典型地，如果元数据仓与请求相关，则服务器101发送该元数据仓的内容。
在一个实施例中，该占位符框包含额外的信息。一条可选的信息是代码流ID编号。该编号被JPIP用来利用JPT-stream或JPP-stream(因此为标题数据仓或区域数据仓)代替使用元数据仓来传送代码流数据。
用于请求和响应的JPIP/JPM协议元件请求元件在一个实施例中，针对页面区域的典型请求看起来像GET/two_page.jpm fsiz=370,218&rsiz=370,218&cid=16807&context=jpmp<2>HTTP/1.1Host:www.example.com注意上面两行格式由http和JPIP协议使用；然而，更通常的做法是把请求表示成单行统一资源定位符URL，并且本申请其余部分将采用这种做法。浏览器自动地把来自用户输入或html链接的一行URL翻译成用于通过信道进行传输的多行请求。上述请求有等同的URLhttp://www.example.com/two_page.jpm fsiz=370,218&rsiz=3770,218&cid=16807&context=jpmp<2>
除了用于指示期望页面编号的“context=jpmp<2>”之外，该请求的所有元件都和普通JPIP相同。在JPIP标准中定义了“context=”请求字段并定义该字段用来支持JPX和MJ2。对JPIP标准的Amendment 1(修正1)扩展了用于JPM文件的context字段的使用。
除了页面编号之外，还支持请求特定布局对象和掩码(mask)或图像区域的能力。在一个实施例中，利用请求中指定的信息实现这种能力。以BNF方式给出了该请求语法的一种实施例jpm-context="jpmp""<"jpm-pages">"[jpm-objects]jpm-pages=[jpm-page-collection":"]jpm-sampled-rangejpm-objects="["jpm-object-range"]"jpm-page-collection=object-idjpm-sampled-range=page-object-range[":"sampling-factor]page-object-range=1#(object-id["-"[object-id]])jpm-object-range=UINT-RANGE":"jpm-object-type/UINT-RANGE/":"jpm-object-typejpm-object-type="mask"/"image"/"nostrm"object-id=UINT/DQUOTE TOKEN DQUOTEDQUOTE=％x22在这种语法中，请求掩码对象的一个例子是context=jpmp<0>[1-3:mask]在这种情况下，服务器被请求返回对应于第一页面上前三个布局对象中的掩码对象的所有数据，其在上述语法中编号为“0”。该请求包括呈现所期望的区域所必须的所有的框，例如页面框、布局对象框、以及由这些对象所引用的任意代码流。
因而，没有视窗的请求可能看起来像jpip://www.example.com/file.jpm context=jpmp<"figures":2-3>[1-:mask]其将请求“figures”页面集合的第2和3页上的所有掩码对象。
一个更典型且简单的请求可能就是来自主页面集合的第2页http://www.example.com/file.jpm context=jpmp<2>
对于修正JPIP的最简单的使用，允许做出对于呈现一单页所需要的所有项目的请求。更复杂的使用仅允许请求一些布局对象或一种类型的对象。在一个实施例中，jpm-context包含用于特定页面的请求；它可能也包含用于页面集合、布局对象列表以及对象类型的说明。
如果未提供页面集合，则假定为来自JPM文件的主页面集合。如果指定一个字符串，则该字符串对应于目标JPM文件中的页面集合框的标号。
页面范围是jpm-context的所需部分。页面范围可能是“0-，其将指定页面集合中的所有页面。在一个实施例中，通过对页面集合和JPM文件中的页面进行深度优先搜索，并将编号0分配给到达的第一页面，1分配给下一页面，依此类推，对页面进行编号。
如果jpm-context没有jpm-object-range项目，则认为其是对应于除了缩略图之外的页面上所有对象的“1-”。jpm-object-range指示请求jpm-page-range的所有页面上的哪个布局对象。
如果jpm-context没有jpm-object，则除了理解掩码及图像的定位和组合所必须的其它框之外，还须请求掩码和图像。如果jpm-object-type是“mask”，则仅掩码对象是该请求所感兴趣的。如果jpm-object类型是“image”，则仅图像对象是感兴趣的。如果jpm-object-type是“nostrm”，则仅未包含代码流的框是感兴趣的。
如果jpm-context参数出现在没有帧尺寸请求(fsiz)的请求中，则帧尺寸值fx和fy设置成页面宽度和页面高度。如果jpm-context参数出现在没有区域尺寸请求(rsiz)的请求中，则区域尺寸值rx和ry设置成帧尺寸值fx和fy(如果必须的话，在fx和fy已被设置为页面宽度和高度之后)。
确定请求的代码流当使用jpm-context参数时，请求对应于独立应用于每个页面的视窗。帧尺寸值fx和fy映射到如由JPM标准的页面报头框的Pwidth和Pheight元件所指定的页面宽度和高度。
在一个实施例中，当且仅当下列所有都为真时，页面内的布局对象视为请求的一部分ox′＜=LHoff+LWidthox′+sx′＞=LHoffoy′＜=LVoff+LHeightoy′+sy′＞=Lvoff其中ox′=ox*Pwidth/fxoy′=oy*Pheight/fysx′=sx*Pwidth/fxsy′=sy*Pheight/fy并且fx、fy、ox、oy、sx和sy由视窗请求给定，LHoff、LVoff、LHeight和LWidth来自JPM标准的布局对象报头框。
在一个实施例中，为页面的缩略像保留布局对象0，当且仅当0包括在jpm-object-range中时，将不管视窗而将该布局对象视为请求的一部分。
确定代码流视窗参数客户机被视为已请求和与视窗相交的掩码和图像相关联的任意代码流。换句话说，在这种情况下，服务器认为那些对象是客户机正请求的。如果没有用JPEG 2000压缩该代码流，则请求是用于整个代码流的。如果用JPEG2000压缩代码流，则可以通过如下的方式将页面上的请求窗映射到对象上的请求窗，为特定的代码流确定等价的视窗fx′=fx*Lwidth/Pwidthfy′=fy*Lheight/Pheightox′=MAX(ox-LHoff*fx/Pwidth，0)oy′=MAX(oy-LVoff*fy/Pheight，0)sx′=MIN(ox+sx-LHoff*fx/Pwidth，Lwidth*fx/Pwidth)-ox′sy′=MIN(oy+sy-LVoff*fy/Pheght，Lheight*fy/Pheight)-oy′因此，服务器把JPM文件上的一个请求映射到JPEG 2000代码流上的一个或多个请求。在一个实施例中，JPEG 2000代码流上的请求具有JPIP语法，类似于File.jp2 fsiz=fx′,fy′&roff=ox′,oy′&rsiz=sx′,xy′其中初始值，例如ox′，用整数ascii表示法代替。
注意，如果JPEG 2000文件包含分辨率高于该页面的数据，则为了获得全分辨率JPEG 2000代码流，必须发出具有比该页面的宽度和高度大的值的帧尺寸请求。替代地，客户机可以确定代码流的编号，并用适当选定的视窗直接发出对该代码流的请求。
响应元件在一个实施例中，服务器以如JPIP标准的第A.3.6小节中定义的元数据仓进行响应。该文件的顶级出现在元数据仓0中。一些框，尤其是包含代码流的大框用占位符框代替。对于除了JPEG 2000的代码流来说，如果请求需要该代码流，则发送整个代码流。可以像其它代码流一样通过简单地从文件复制，或者通过使用用于JPP-stream或JPT-stream的数据仓(占位符框指示以这种方式提供的每个代码流的代码流编号)，发送所需的JPEG 2000代码流。
注意，如果JPM服务器修改了context请求(典型地是通过将其减小到一较低尺寸)，则该JPM服务器包括“http”报头行。JPM服务器也使用该报头行来指示和该context-range相关联的代码流编号。
JPM服务器操作在一个实施例中，为了通过JPM服务器提供JPM文件服务，可以创建一辅助布局对象信息文件，并将其存储到和该JPM文件相同的目录中。在下列段落中称其为“JPM信息文件”。该文件包含该JPM文件中的全部布局对象的清单。对每个对象来说，存储页面编号、x-偏移、y-偏移和高度以及宽度，并将其用于确定该对象是否和请求相交。页面尺寸也包括在该JPM信息文件中。另外，存储用于每个布局对象的代码流在JPM文件中的偏移。
图2描述了JPM文件和JPM信息文件，以及用于特定JPM文件的JPM服务器内容。参照图2，JPM文件服务器使用的表示法包括JPM框类型201、JPM框尺寸202、元数据仓0203、以及可选地用于每个不同框的其它元数据仓，例如204。一个用于采样JPM文件的信息文件210的例子示于图2的下半部分。该例子文件的字段是页面编号(本例中页面编号从1而不是0开始)、页面宽度、页面高度、布局对象编号、对象类型(掩码，图像，或者组合的掩码图像)、非代码流、数据引用编号、文件中代码流的偏移、LHoff、LVoff、LWidth和LHeight。
服务器利用文件中的对象列表来找出JPM文件中与客户机请求中指定的区域相交的对象。在一个实施例中，如果所请求的缩放区域以任意方式和该对象相交，则服务器使用缩放视图至页面尺寸的函数并返回1。该确定需要页面尺寸、对象位置、以及来自该对象列表文件的对象的内容。
接着，服务器使用该对象列表来确定JPM文件的必须被发送以使客户机能够呈现指定区域的框。在一个实施例中，服务器通过使用该对象的数据引用编号以及进入该文件的偏移来实现该操作。在一个实施例中，JPM服务器仅返回与产生请求所基于的文件相同的文件范围内的代码流(即，仅那些数据引用编号为0的代码流)，并且客户机提交一单独的请求来接收来自于JPM文件之外的数据。
对于在JPM文件上的请求，服务器扫描所请求的文件，并为了内部使用产生所有框及其位置的列表。任何连续代码流都有为其创建的占位符框。对于元数据仓和占位符框的细节，参见JPIP标准的第A.3.6小节。
JPM服务器对于任意文件的第一请求返回元数据仓0。该字节流或者包含所有的框，或者包含用于文件中每个顶级框的占位符框。在一个实施例中，JPM服务器仅用占位符框代替连续代码流框。在另一个实施例中，用元数据仓代替其它框。例如，所有大于一阈值尺寸的框可以被元数据仓代替。当大量元数据存储在JPM文件中时，可能出现这种情况。
图2在左上方也示出了JPM文件的每个顶级框以及该框的尺寸。到该JPM文件的右边，示出了元数据仓0的内容。在一个实施例中，JPM服务器并未完全在盘上或在存储器中创建元数据仓0。当作为响应的一部分发送是元数据仓0的一部分的框时，从原始JPM文件中复制这些框。在存储器中为每个代码流创建占位符框，并将其作为响应的一部分进行发送。
在图2中也示出了用于JPM文件的JPM信息文件的内容。在这种情况下的最大编号是进入原始JPM文件的对象偏移。为了发送页面1，JPM服务器找到页面1上的所有对象，并为每个对象确定所需要的代码流。由于从元数据仓0中排除了代码流，因此，JPM服务器为每个所需要的代码流发送适当的元数据仓。在图2的例子中，需要元数据仓1和3。
在一个实施例中，当接收到在该服务器上没有可用的JPM信息文件的JPM文件请求时，JPM服务器自动地产生该JPM信息文件。可替代的是，当将一JPM文件添加到该服务器上时，可以产生该JPM信息文件。替代地，服务器根本不必保存JPM信息文件，该信息可以集成到用于提供JPM文件服务的服务器代码上。在这种情况下，当打开每个文件时，服务器确定对象列表。有时候，信息文件已经可用比解析一个大的JPM文件更为迅速。
在一个实施例中，由于JPM服务器追踪所有所发送的元数据仓的字节范围，即使不同的布局对象使用相同的代码流，也将仅发送一次数据。这是图2中情况，其中多次使用了在偏移16229和1383处的代码流。一些布局对象没有代码流(就JPM信息文件中的第6入口而言)。JPM服务器没有对这些布局对象采取行动，在该布局对象内提供了来自于这些布局对象所需的一切。如果服务器把页面框分成多个数据仓，则JPM信息文件可以用于确定哪些元数据仓也应被发送。
在一个实施例中，JPM服务器基于图像改进的数量按顺序发送对象。如上所述，JPM服务器确定和所请求的视窗相交的所有对象，并按其在文件中出现的顺序返回这些对象。计算重叠的数量，并按和所请求的图像最大重叠的顺序返回这些对象。
在一个实施例中，JPM服务器提供元数据仓之外的JPEG 2000代码流。由于客户机和服务器都支持局部JPEG 2000代码流的传输，因此，以标题数据仓或者区域数据仓，而不是元数据仓来发送这些代码流。
JPM客户机操作JPM客户机管理用户接口。在一个实施例中，接口包括允许访问多页JPM文件的上一页和下一页的按钮。也可以包括用于摇摄(pan)和缩放操作的按钮以及其它用户接口元件。
当请求除了第一页面之外的页面时，客户机将“context=jpmp<n>”添加到查询字符串中。客户机将所有接收到的元数据仓存储到具有原始文件名称的高速缓冲存储器目录中，+“.cache.j2c”+“mc”+元数据仓的类+“.bin”+元数据仓的类内部id编号。JPIP标准的附件A指出了所有data bin类。元数据仓是类8，并且JPM服务器按连续代码流出现在文件中的顺序对bin进行编号。因而，在接收到用于“two_page.jpm”的第一页的所有数据之后，JPM客户机拥有具有下列文件的高速缓冲存储器-rw-r--r-- 1gormish wheel 1623 21 Feb 10:37two_page.jpm.cache.j2c.mc8.bin0-rw-r--r-- 1gormish wheel 8804 21 Feb 10:37two_page.jpm.cache.j2c.mc8.bin1-rw-r--r-- 1gormish wheel 223 21 Feb 10:37two_page.jpm.cache.j2c.mc8.bin3这在图3中图示出。由于元数据仓0包含有效的JPM框，因此文件的开头是JPM文件；然而，由于该JPM服务器用占位符框代替了一些框，因此，JPM页面框中的文件偏移及其它文件偏移未指向文件中的正确位置。由于占位符框小于所代替的框，因此偏移将可能指向元数据仓的外面，将不会指向正确的位置。并非所有由占位符框指向的元数据仓都在客户机上可用。
在一个实施例中，由于元数据仓0中的框具有不正确的偏移，因此该JPM客户机创建一新的伪JPM文件。为了创建该文件，复制来自元数据仓0的正常的框，而用从JPM服务器接收的适当的元数据仓的内容代替占位符框。当元数据仓不可用或仅接收到部分元数据仓时，客户机用所需长度的0字节(或一些其它值)来填充该伪JPM文件。注意，从元数据仓0中的占位符中可知该框的正确类型和长度。现在，该伪JPM文件具有用于所出现的框的正确的偏移，但由于一些jp2c框未包含合法的代码流，因此该伪JPM文件并不是一个“合法”的JPM文件。
假设该JPM服务器正确地发送所请求视窗所需要的全部代码流，那么客户机能够解码应用于该页所请求区域的所有位，并能显示相同的信息，如同整个文件在JPM客户机上处于可用状态一样。
如上所述，在一个实施例中，对于第一个请求返回除了连续代码流之外的所有数据。如果元数据变得非常大，则除了元数据被请求时否则不返回元数据。
在一个实施例中，JPM解码器处理丢失的数据，并可能直接读取占位符框。在这种情况下，并非必须为解码形成一个大的“伪JPM”文件。服务器仍可以按相同顺序传递项目和元数据仓集合，但JPM解码器必须计算出原始文件中偏移的位置，并转换成元数据仓中的位置。
在一个实施例中，JPM客户机通过使用元数据仓的外部引用重写JPM文件的方式来处理丢失的数据，而不管他们是否已被接收到。可以解码已接收到的数据仓。这将需要写一不同于元数据仓0的文件，但该文件充分地小于一个零填充文件。使用外部引用允许解码器检测外部文件上的时戳，以决定是否已更新代码流，以及决定是否应重新解码代码流。
在一个实施例中，除了页面编号之外，JPM客户机和JPM服务器还支持请求。例如，这些请求可以是用于页面集合、页面编号、布局对象、以及掩码及图像。
在一个实施例中，JPM客户机和服务器支持分段表。如果使用了分段表，并且该分段表指定了内部偏移，例如在‘mdat’框中，则JPIP服务器仅服务用于‘mdat’框的元数据仓的一部分，该‘mdat’框包含代码流，并且当客户机仅接收这些条时，客户机能够解码。
JPM解码器及使用在一个实施例中，JPM客户机把接收到的元数据仓存储到独立的文件中，这是十分有效的，并且这也允许删除不必要的数据。然而，如果JPM解码器无法理解由JPIP使用的占位符框，则每次解码的时候，复制所有接收到的数据，另外，将0字节存储到用于未接收到的数据的伪文件中。因而，客户机可能使用两倍于存储在服务器上的原始文件尺寸的文件。
在一个实施例中，JPM解码器和JPIP客户机集成在一起。在这种情况下，它读取占位符框，并使用该信息来纠正JPM文件中所有位置里的偏移。
在一个使用了独立于JPIP的JPM解码器的实施例中，任意元数据仓的任意新信息导致要重新解码所有需要的代码流。由于给了JPM解码器一个完全新的文件，并且无法区分出新、旧部分，因此，这是不可避免的。在一个实施例中，JPM解码器直接使用占位符框和元数据仓，进而探测具有新信息的元数据仓，以及需要重新解码和组合的代码流。
文档纲要在一个实施例中，利用纲要文件，调整正跨越相对较慢的电子链接进行传送的材料的数量，对其处理方式类似于对文档的处理方式，但其包含指针而不是代码流。该纲要文件可以是一JPM文件。
JPM格式包括代码流分段的概念。代码流是页面的某部分的压缩图像数据。分段是代码流的连续小节，其可以在文件内在固定字节范围内找到。提供一页面需要的代码流分段可以被存储到报头相同的文件中，或者存储到另一仅在横跨某些网络时可用的文件中。通过参照称作数据引用框的引用表中的入口，识别出必须的代码流分段，文件中的偏移和分段的长度存储在分段表框中。在一个实施例中，该JPM特性用于创建纲要文档。这样的文档是完全有效的JPM文件，但仅具有需要提供本地文件中全部页面的代码流的一个小子集。不包括纲要文件中的大部分或全部代码流，文件中仅包含引用。通过复制不具有任何所包括的代码流的文档结构，可以创建一纲要文件。为了从一完整的文档中创建一纲要文档，处理逻辑为源文档中的每个代码流创建分段表框(ftbl)和分段列表框(flst)。通过逻辑实现该处理，逻辑可能包括硬件(电路，专用逻辑，等等)、软件(例如运行在通用计算机系统或专用机上的)、或者二者的组合。在一个实施例中，为代码流选择适当的块尺寸，并产生一分段列表，其被预分割成块。该尺寸可能是便于进行网络传输的固定数目的字节，或者它可以涉及代码流的内容，例如，对应于JPEG 2000代码流的标题部分。
图4是由客户机或具有纲要文档的用户应用可能采取的动作的流程图。图5是一个文档纲要的例子。参照图5，文档纲要包括两个分段表框(ftbl)501和502，每个分段表框包含具有两个入口的单一分段列表框。两个入口指向源文件中的代码流数据。
参照图4，该处理开始于接收或获得一纲要文档(处理块401)，例如图5。当读取该纲要文档时，可以访问分段表框中的指针，并接收新代码流数据的一个分段。通过在媒体数据框(mdat)中的文件末尾附加字节，可以把该额外的代码流数据移入本地文件(处理块402)。处理逻辑更新该分段列表入口(例如参见块501)，以指向新的位置(处理逻辑403)。在一个实施例中，分段列表入口具有更改为本地文件中位置的偏移，并且数据引用入口也变成指示本地文件。当分段列表入口尺寸固定时，可以不必重新复制现有内容而适当重写该文件。当代码流分段附加到一个或多个媒体数据框中的文件上时，处理逻辑也立即越过所附加数据的末尾，写入分段列表入口的原始内容(处理块404)。可以多次重复处理块402、403和404，以按任意顺序把数据传送到文件中。如果为文件中的所有外部分段重复这些操作，则将获取包含所有需要的代码流的文件，并且不需要访问源文件以提供任意部分。如果应用程序希望恢复存储器或盘空间，则通过重新存储来自该位置的原始分段表入口以及删除本地代码分段，存储在mdat框中的原始分段列表入口可以用于从文件中移除数据。
由于所有数据都附加到媒体数据框中的纲要文档的末尾，并且分段列表入口是固定尺寸的，因此可以这么作，而不必重写该文件的开头部分。重要的是，可以多次更新原始纲要文件，而不必重写除了定长分段列表入口之外的任意数据。在处理逻辑(404)完成之后的每个点处，一有效文件在本地是可用的。由于长度不改变，因此可以在有限的存储器中迅速处理这些更新。写一个完全新的文件和删除旧的文件的惯例是不必要的。
在传送了足够的代码流之后，有效的JPM文件和大都指向本地文件的可读初始页一起出现。在一个实施例中，成像第一页，即使没有网络连通性，也允许评价其首页(cover sheet)。在图6中示出了具有一些存储在本地的数据和一些仍存储在源文件中的数据的JPM文件的例子。
在一个实施例中，图5中的源文件是抽取出纲要文件的JPM文件。在另一个实施例中，代码流可以在单独的文件中，或者他们也可以包含在其它文件中，尤其是他们可以是PDF、或SVG、SMIL、或FlashPaper文件的一部分。
考虑如何最好地分段代码流是有用的。一种方法是使用简单的固定尺寸分块，其将进行如JPEG和JBIG的相对简单的媒体编码。然而，基于标题尺寸和分辨率，JPEG 2000代码流可能产生一指定的分段。通过选择适当的分段以及仅移动和所需要的区域相关联的那些代码流分段，这样的分段允许指定页面、页面区域、以及要装载的分辨率。
本文所描述的纲要文档具有下面几个方面的优点。第一，他们是有效的JPM文档。而且，他们远小于一个完整的文档，并能迅速传送。他们可以用作文档本地拷贝的高速缓冲存储器，使部分代码流保留在本地，以防网络不可用。可以用新的代码流附加到文档中，而不必完全重写，这一点在存储装置的容量有限时可能很重要。可以为了有效地复制具有指定分辨率的完整的页面分析代码流分段。可以容易地确定为了以特定分辨率显示是否有足够的信息在本地缓冲，并且可以产生所需要信息的最小集合的请求。当纲要文档通过通信信道流出时，具有许多缓冲代码流的文档可以迅速削减成纲要。可以移除并替代文档的缓冲代码流数据，允许有效且适当地管理高速缓冲存储器。
客户机缓冲当客户机接收到部分JPM文件时，可以完整地接收一些代码流，可以完全不接收一些代码流，以及可以部分地接收一些代码流。在部分接收JPEG2000代码流的情况下，所接收到的数据可能对提供文件非常有用。例如，如果低分辨率数据用于创建显示图像，则已接收用于JPM文件的低分辨率信息，并正在低分辨率显示装置上提供JPM文件的客户机，不会在最终图像中看到任何变化。
如果客户机需要图像的更高分辨率版本，可能由于图像将在更高分辨率装置上显示，像打印机，或由于用户希望在图像的一个区域上放大，则客户机提交一个新的请求给服务器以获取数据。由于其涉及和服务器的JPIP事务及其访问在那些事务中接收到消息报头，因此客户机知道需要更多的数据。然而，在某点，客户机和服务器之间的连接可能关闭，并且服务器可能丢弃来自于和客户机一起的事务的状态信息；在这种情况下，服务器将不再具有客户机-高速缓冲存储器模型。
以类似于保留用于多日的高速缓冲存储器或直到达到某种存储器极限的web客户机的方式，客户机可以把所有和与服务器一起的事务相关联的文件保留到其高速缓冲存储器中。保留数据允许用户使用前面看过的数据。
然而，客户机可能也希望以对“普通”解码器有用的形式存储接收到的图像数据，即不访问客户机的事务性存储器的解码器，或知道如何处理像元数据仓那样的特定JPIP构造的解码器。
在一个实施例中，为了以对其它应用程序有用的格式存储JPIP-JPM高速缓冲存储器文件，也为了允许客户机恢复和服务器的交互而不必存储额外的状态信息，客户机使用特定的JPM文件。该文件包含JPM文件的结构，如以页面集合框、页面框和布局对象框所表示的。一些或全部代码流存储在外部，在JPM文件的数据引用框中指定位置。这是用于JPM纲要文件的一般情形。然而，通常来讲，纲要文件或者包括对盘上的本地文件或服务器上文件的引用，或者包括某些组合。
为了获取存储和互用性的益处，数据引用框中的值可以包含关于存储在本地的JPEG 2000文件的部分，以及通过使用引用中的JPIP高速缓冲存储器模型语法存储在服务器上的部分的信息。
例如，假设服务器example.com提供了JPM文件document.jpm，其包含或使用了称为image1.j2k的JPEG 2000代码流，并且客户机已经由JPIP接收了该文件的一部分并将其存储在本地文件image1_cache.j2k中。客户机可以用该格式的数据引用框中的引用来存储其document.jpm版本jpip://example.com/image1.j2k fsiz=1024,1024&rsiz=1024,1024&model=t*r0-2:L4在‘ ’之后的部分是JPIP语法；开始于‘model=’的JPIP语法的部分指示客户机具有用于请求窗口中的所有标题(t*)的分辨率级别0、1和2(r0-2)的前4个质量层(L4)。因而，当检查该文件时，解码器知道已经接收了文件的一部分，即由高速缓冲存储器模型语句所指示的部分。解码器将在可能存储来自服务器example.com的“image1.j2k”的位置寻找该文件的本地部分(正如如果产生为该图像的新请求时它将做的一样)。通过检查模型说明来确定数据是否是当前的模型语句，解码器将确定是否需要文件的更多内容(这要比检查整个文件更迅速)。如果解码器需要更多来自JPEG 2000代码流的数据(也许由于其要进行打印)，则该引用可以用作一个对服务器的请求，以获取该数据。
这种引用类型对基于标题部分的JPT-stream尤其有用。在这种情况下，高速缓冲存储器文件可以是从服务器接收到的数据的串联，并且也可以附加任何来自跟随请求(follow up request)的额外数据。引用除了使用了“tpmodel”而不是“model”之外看起来是相同的。例如，像jpip://example.com/image1.j2k fsiz=1024,1024&rsiz=1024,1024&tpmodel=0.0-5.1这样的数据引用入口指示了在高速缓冲存储器文件中出现了来自前6个标题的标题部分0和1。出于包括“tpneed”和“need”的类似目的的考虑，可以使用其它高速缓冲存储器模型JPIP语法。
另一种可能是使用数据引用来指示高速缓冲存储器中的文件。下面是一个例子file:/my_browser_cache/image1_cache.j2k fsiz=1024,1024&rsiz=1024,1024&tpmodel=0.0-5.1在本实施例中，到原始服务器的链接已丢失。然而，这可能对一个没有计划产生额外请求并且不知道用于所缓冲文件的默认位置的解码器是有用的。在另一个实施例中，URL用于本地文件，但使用JPIP目标字段来指定服务器上的位置。例如，file:/tmp/cache1.jpm target=www.example.com/server_dir/original_file.jpm&fsiz=1024,1024&rsiz=1024,1024&tpmodel=0.0-5.1当传送文件时，JPM尤其有用。例如，当客户机装置获取一文件并告诉JPM解码器其是特定尺寸时，JPM解码器将解码文件。客户机装置可以决定不去执行任何网络访问，并仅用其具有的信息呈现文件。然而，如果客户机决定传送其所具有的文件到另一个客户机，则该客户机可以进行网络访问，并仅请求其所具有的文件拷贝中仍没有的信息。
PDF/JPM操作在一个实施例中，JPM文件可以包含一个或多个PDF文件。图7示出了一种这样的例子。参照图7，示出的JPM文件700具有多个框，这些框通常对一个JPM文件从开始包括，签名框(jp)、文件类型框(ftyp)、复合图像标题框(mhdr)，页面框(页面)、页面集合框(pcol)701。替代连续代码流框(jp2c)，该JPM文件使用包含分段列表框(flst)的分段表框(ftbl)，其包含对代码流的偏移。JPM阅读器将读取文件到媒体数据框(mdat)702，并使用来自分段列表框的偏移来访问代码流。然而，媒体数据框实际上包含一个完整的PDF文件703。该PDF文件包含包括JPEG 2000代码流704和JBIG2代码流705的PDF对象。在这种安排下，PDF文件703是一个合法的PDF文件。即，如果移除JPM文件700的其它部分，则可以利用诸如Adobe Acrobat之类的PDF阅读器读取及打开PDF文件703。然而，JPM文件本身按照和其它JPM文件相同的方式进行操作，允许使用信息和JPM标题以及页面信息701来访问JPEG 2000代码流704和JBIG代码流705。没有JPEG 2000和JBIG代码流的副本。注意，JPM文件中框的特定顺序只是一个例子，许多其它顺序也是可以的。尤其是，MDAT框可以出现在更接近文件的开头，当访问作为PDF文件的文件时，这允许服务器能更迅速地跳过JPM部分。为了保留合法的JPM文件，在顺序上有一些限制，例如，文件类型框必须紧跟JPEG 2000签名框。
PDF文件可以包含一个或多个JPM文件。图8描述了包含一JPM文件的PDF文件的例子。参照图8，PDF文件801包括JPEG 2000代码流802，JBIG2代码流803和PDF附件804。PDF附件804包括不包含任何代码流的JPM“纲要”文件。可替代的是，JPM文件包含提供PDF文件的名称的数据引用框‘dtbl’。JPM文件也包含具有分段列表框的分段表框。分段列表框包含JPEG 2000和JBIG2代码流的PDF文件范围内的偏移。在PDF文件800中，JPM标题和页面信息805出现在PDF文件的末尾，但项目可能依赖于PDF文件的定义而存储在不同位置。如果JPM文件拷贝自PDF文件，但数据引用框内的引用仍指向PDF文件，则独立的JPM文件可以定位并使用PDF文件范围内的代码流。虽然在图中示出JPM文件占去大量空间，但是没有代码流的JPM文件的实际文件尺寸一般远小于代码流。
在一个实施例中，服务器提供对来自一个文件的两种格式的访问。因此，响应接收来自于一装置的请求，经由请求中的信息或通过先前和客户机交换的信息，服务器了解客户机装置的容量，可以利用单一文件来给客户机装置提供所需要的信息，从而使客户机装置显示和/或处理文档。例如，如果智能服务器了解客户机装置具有Acrobat Reader，但却不能处理JPM信息，则该智能服务器可以访问诸如JPM文件700之类的文件，并丢弃那些与JPM报头相关的部分，从而留下可以提供给客户机装置的PDF文件703。类似地，如果由客户机请求的文件是诸如PDF文件800之类的PDF文件，并且智能服务器知道请求该文件的客户机装置无法接受PDF文件，则智能服务器可以提供包括JPM报头和页面信息805、JPEG 2000代码流802和JBIG代码流803的JPM文件信息给客户机装置。
图9示出了PDF文件901，以及一独立的JPM文件902。这种环境可以用在服务器上，以保持随时准备提供PDF文件和JPM文件这两者的服务，而这时仅把代码流保持在PDF文件中。当如图8中所示，从PDF文件拷贝出JPM文件时，可能出现这种情况。当客户机已通过网络接收到JPM纲要文件，但PDF文件仍在服务器上时，也可能出现这种情况。
如果客户机能够接收JPM文件和JPIP数据仓，则服务器可以响应对局部文档内容的请求。使用JPM文件报头和各个框，服务器可以选择需要的页面和代码流，并把这些封装进元数据仓、标题数据仓和区域数据仓中。客户机不必知道服务器上的格式实际上是PDF文件，还是包含PDF文件的JPM文件。
如果服务器上的格式是包含PDF文件的JPM文件，则该文件的PDF部分可以作为元数据传递给客户机。然后客户机可以从接收到的JPM数据仓中重建PDF文件。客户机上的文件可以重新扮演双重角色，PDF和JPM阅读器都可以使用。
示例性计算机系统图10是一个示例性计算机系统的方框图，该系统可以实现本文所描述的一个或多个操作。参照图10，计算机系统1000可以包括一个示例性客户机或服务器计算机系统。计算机系统可以是一多功能外设(MFP)的一部分，其充当用于上面所描述的JPIP/JPM文件的服务器，或者一个充当客户机的MFP。
计算机系统1000包括用于传送信息的通信机构或总线1011，以及为了处理信息而和总线1011耦合的处理器1012。处理器1012包括微处理器，但不限定于微处理器，例如，PentiumTM、PowerPCTM，AlphaTM，等等。
系统1000进一步包括随机访问存储器(RAM)，或其它动态存储装置1004(称为主存储器)，其为了存储由处理器1012执行的信息和指令，耦合到总线1011上。主存储器1004也可以用于存储在处理器1012执行指令期间产生的临时变量或其它中间信息。
计算机系统1000还包括耦合到总线1011上的只读存储器(ROM)和/或其它静态存储装置1006，用于存储用于处理器1012的静态信息和指令，以及一种诸如磁盘或光盘及其对应的磁盘驱动器的数据存储装置1007。数据存储装置1007耦合到总线1011上，用于存储信息和指令。
计算机系统1000可以进一步耦合到显示装置1021上，例如阴极射线管(CRT)或液晶显示器(LCD)，其耦合到总线1011上，用于对计算机用户显示信息。一个包括字母数字及其它键的字母数字输入装置1022也可以耦合到总线1011上，以用于和处理器1022进行通信信息及命令选择。附加的用户输入装置为光标控制器1023，诸如鼠标、轨迹球、轨迹板、笔或光标方向键，其耦合到总线1011上，以用于和处理器1012通信方向信息以及命令选择，也为了在显示器1021上控制指针移动。
另一种可以耦合到总线1011的装置是硬拷贝装置1024，其可以用于在诸如纸、胶片之类的介质上或类似类型的介质上标记信息。另一种可以耦合到总线1011上的装置是与电话或手持palm装置通信的有线/无线通信能力装置1025。
需要注意的是，系统1000的任意组件或全部组件以及相关联的硬件可以用于本发明。应该了解，计算机系统的其它配置方式可以包括该装置的一些或全部部分。
在阅读前面的描述之后，本发明的许多替换和修改对本领域普通技术人员来说无疑是显而易见的，应理解通过图示方式示出和描述的任意特定实施例决不会被认为是对本发明的限定。因此，参照各种实施例的细节也不是用于限定权利要求的保护范围，权利要求本身仅叙述那些被认为是本发明所必须的特征。
本发明不限定于具体公开的实施例，可以对本发明做出变化和修改，而不会脱离本发明的范围。
权利要求
1.一种方法，其特征在于接收对文档的页面的区域的请求，该请求是从客户机发起的；确定和所述页面的区域相交的源文件中的一个或多个对象，该源文件具有两个或多个代码流；以及发送具有文件中的信息的子集的响应。
2.如权利要求1中所定义的方法，其中所述源文件是JPM文件。
3.如权利要求1中所定义的方法，其中所述请求使用JPIP语法。
4.如权利要求1中所定义的方法，进一步包括访问辅助信息文件，该辅助信息文件包含所述源文件中的至少一个对象的位置信息。
5.如权利要求4中所定义的方法，其中所述辅助信息文件包含所述源文件中的至少一个对象的页面信息、页面上的空间位置信息、以及文件中的数据位置信息。
6.如权利要求5中所定义的方法，其中所述信息来自于JPM文件中的至少两个不同的框。
7.如权利要求4中所定义的方法，其中访问所述辅助信息文件中的信息包括确定与所请求的所述页面的区域相交的所述源文件中的一个或多个布局对象。
8.如权利要求1中所定义的方法，其中所述源文件包含用于多种文件类型的结构化信息，并且进一步包括基于所述请求发送该多种类型中的一种类型的结构化信息。
9.如权利要求1中所定义的方法，进一步包括提供对所述文件的JPM部分和所述文件的PDF部分这两者的访问。
10.如权利要求1中所定义的方法，其中所述源文件是包含有效PDF文件的JPM文件。
11.如权利要求1中所定义的方法，其中所述源文件是包含JPM文件的PDF文件。
12.如权利要求1中所定义的方法，其中所述源文件是包含允许客户机开始JPIP交互的URL的PDF文件。
13.一种服务器，其特征在于网络接口，用于接收对文档的页面的区域的请求，该请求是从客户机发起的；以及处理器，用于确定与所述页面的区域相交的源文件中的一个或多个对象，其中该源文件具有两个或多个代码流，所述服务器产生要通过网络接口发送的响应，该响应具有文件中的信息的子集。
14.一种计算机系统，其特征在于服务器，包括接收对文档的页面的区域的请求，该请求是从客户机发起的；确定与所述页面的区域相交的源文件中的一个或多个对象，该源文件具有两个或多个代码流；以及发送具有文件中的信息的子集的响应。
全文摘要
公开的本发明的方法包括接收对文档的页面的区域的请求，该请求是从客户机发起的；确定与该页面的区域相交的源文件中的一个或多个对象，该源文件具有两个或多个代码流；以及发送具有文件中的信息的子集的响应。
文档编号H04N1/21GK101031013SQ20071009233
公开日2007年9月5日 申请日期2007年2月28日 优先权日2006年2月28日
发明者迈克尔·戈尔米什, 爱德华·施瓦茨, 库尔特·皮索尔 申请人:株式会社理光