6、缓存
如果某个实现对每个写操作支持范围、实现和可用状态的检查，通常会触发一系列对相机的读操作。大多数用于有效性检查的数值很少或不会发生变化，所以可以放入缓存。相机描述文件包含所有必需的定义以确保缓存的一致性。
图 8：感兴趣的区域
为说明这一点，需要用到更复杂的例子。图 8 显示了相机图像上的 AOI 。相机只需要发送 AOI 内的图像，图中的 AOI 是由 Top、Left、Width 和 Height 四个参数给出的矩形。
图 9：控制感兴趣的区域
如图 9 所示，这四个参数都从寄存器中取出。当然，这种简单的方式不能很好地处理，因为这四个参数的取值范围都不是无限的。假定像素坐标从 0 开始，有下面的限制：
0 ≤ Left ≤ ImagerWidth −Width
0 ≤ Top ≤ ImagerHeight − Height
1 ≤ Width ≤ ImagerWidth − Left
1 ≤ Height ≤ ImagerHeight − Top
为了处理这些限制，每个参数的最大值都必须用 SwissKnife 节点计算；最小值是固定的。结果 GenApi 节点图如图 10 所示。注意，这里加入了第二层的 Integer 节点并且最大值由 IntSwissKnife 节点处理。
图 10 在考虑限制的同时控制感兴趣的区域
假定图像处理器有 VGA 模式（640 x 480），TopMax 节点的 XML 代码看起来可能是这个样子的：
<IntSwissKnife Name="TopMax"> <pVariable Name="CURHEIGHT">HeightReg</pVariable> <Formula>480-CURHEIGHT</Formula> </IntSwissKnife>
让我们再回到缓存的话题，你应该不会希望每次设置 Left 属性的时候都去读一次 HeightReg 或者判断一次 TopMax 节点。这的确是不必要的，当（且仅当）你确定 HeightReg 只在 GenApi 自身写了一个新的值到这个寄存器的情况下才发生改变。这种情况下，你可以把 HeightReg 和 TopMax 的值放入缓存。
如果用户写了一个新的值到 HeightReg ，HeightReg 缓存的值可以立即发生变化，并且需要令 TopMax 缓存无效。当下一次有人要访问 Left 节点的时候，会去读 TopMax ，因此为 TopMax 创建一个新的缓存入口。
规则：当一个节点的内容发生变化的时候，要通知其所有的客户端，以便客户端可以令缓存无效。
通常，相机描述文件中结点间的连接包含了所有需要的信息，以便实现程序能处理缓存而不需要用户操心。不过，在有些情况下，相对于节点直接描述的，相机本身包含更多的依存关系。
某些相机包含一个叫做 Binning（装箱） 的属性，当 Binning 被置为 ON，相邻像素的值（charge）被合并，实现较好的效果，但代价是分辨率较低。假设一个 VGA 分辨率的图像卡，典型的配置如下：
无 Binning (640 x 480)
水平 Binning (320 x 480)
垂直 Binning (640 x 240)
全 Binning (320 x 240)
在 GenICam 中，这个属性要用一个含有四个值的枚举型来描述（见图 11）。改变 binning 就意味着改变图像卡尺寸——不是实际的物理图像卡，而是用来表示 AOI 参数的限制的逻辑图像卡尺寸。
图 11 通过考虑到装箱情况来控制感兴趣的区域（Controlling the Area of Interest taking binning into account）
我们假定相机通过寄存器提供有关当前（逻辑）图像卡尺寸的信息。如图 11 所示，我们引入了两个新的节点：ImagerHeightReg 和 ImagerWidthReg 。TopMax 的 XML 代码看起来像这个样子：
<IntSwissKnife Name="TopMax"> <pVariable Name="CURHEIGHT">HeightReg</pVariable> <pVariable Name="IMAGERHEIGHT">ImagerHeightReg</pVariable> <Formula>IMAGERHEIGHT-CURHEIGHT</Formula> </IntSwissKnife>
正如我们所见，如果用户改变 Binning 属性，ImagerHeightReg 的值将会改变。然而这两个节点间没有数据流。为确保在 BinningReg 节点的内容变化的时候，ImagerHeightReg 节点的缓存无效，必须在两个节点间引入一个连接。这个连接的唯一用途是，说明这两个属性间隐藏的依存关系，以及确保缓存总是一致的。
7、识别并判断相机描述文件的版本
Identifying and Versioning a Camera Description File
必须能够通过一种统一的方式，来识别一个相机描述文件，及其所描述的相机。另外，随着时间的推移，相机描述文件也要相应地扩展，例如，当相应的相机产品增加了属性的时候。这就产生了对版本机制的需求。GenApi 语法本身也要与时俱进，例如，当加入了新的节点类型的时候，所以也要求对规范提供版本机制。
在 <RegisterDescription> 元素的属性列表中可以发现必要的方法，这个元素是 XML 文件最外层的框。下面来看一个例子：
<RegisterDescription ModelName="Example01" VendorName="Test" ToolTip="Example 01 from the GenApi standard" StandardNameSpace="None" SchemaMajorVersion="1" SchemaMinorVersion="1" SchemaSubMinorVersion="0" MajorVersion="1" MinorVersion="0" SubMinorVersion="0" ProductGuid="1F3C6A72-7842-4edd-9130-E2E90A2058BA" VersionGuid="7645D2A1-A41E-4ac6-B486-1531FB7BECE6" xmlns="http://www.genicam.org/GenApi/Version_1_1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.genicam.org/GenApi/Version_1_1 ../GenApiSchema_Version_1_1.xsd">
所描述的相机由 VendorName: / ModelName 对来标识。因为有商标保护，我们可以假定 VendorName 是唯一的。ToolTip 属性用来提供设备的附加信息，并且可以显示给用户，例如，用总线上设备的选择列表的方式。
相机描述文件内的名称可能来自不同的命名空间，关于这一点在第 8.1 节有更详细的说明。在一个给定的相机描述文件中，名称要么来自自定义的命名空间，要么来自标准命名空间。属性 StandardNameSpace 表示文件中所使用的标准命名空间。
一个相机描述文件中不同项目的版本信息遵循共通的规则，并使用一个由三部分组成的版本号（version number）：
<Major>.<Minor>.<SubMinor>
例如，“1.4.2”
兼容性规则（compatibility rules）如下：
Major 版本号高的文件不向下兼容
Minor 版本号高的文件向下兼容
改变 SubMinor 仅仅表示修复了问题；总是应该使用 SubMinor 最高的文件
例：版本 1.3.0 兼容版本 1.1.*，1.2.* 和 1.3.* （星号表示不关心）。它不兼容版本 2.*.* 。如果版本 1.3.2 可用，则应该用它来代替 1.3.0 。
7.1. 格式的版本
Versioning the Schema
属性 SchemaMajorVersion 、SchemaMinorVersion 和 SchemaSubMinorVersion 描述 XML 文件用的 GenApi 格式的版本。这些属性是强制的，目的是提供信息。另外，格式的 Major 和 Minor 版本号也反映在命名空间（参见 xmlns 入口）和格式的文件名（参见 xsi:schemaLocation 入口）。
在这个例子中，命名空间是 “http://www.genicam.org/GenApi/Version_1_0” 。需要用到这个格式文件的程序既可以根据 URL 通过互联网来得到它，也可以通过由 schemaLocation 的第二部分给出的路径来找到这个文件，这个路径是可选的，在这个例子中是 “…/…/GenApi/GenApiSchema_Version_1_0.xsd” ，并假定 XML 文件存放在 GenICam 参考实现的目录结构中。
xmlns:xsi 入口的 “http://www.w3.org/2001/XMLSchema-instance” 描述了格式语言自身的命名空间。
注意，如果一个实现支持，例如版本 1.3.* 的格式，则必须提供 3 个格式文件：版本 1.0.*、1.2.* 和 1.3.*，这是向下兼容的要求，因为旧的 XML 文件带有旧的命名空间，需要旧的格式文件；另一方面，这个实现不支持使用新版本格式文件的 XML 文件，例如 1.4.* 要被拒绝。因此，有必要把版本号反映到格式的命名空间。
7.2. 相机描述文件的版本
Versioning the Camera Description File
属性 MajorVersion、MinorVersion 和 SubMinorVersion 描述 XML 文件自身的版本。相机的制造商有责任遵守兼容性规则。
相机描述文件的向下兼容是什么意思呢。假设一个相机，其版本 1.0 仅仅实现了一个属性。现在假定这个相机为另一个属性扩展了 firmware 。有两个方法可以在相机描述文件中处理这个情况。如果仅仅把这个属性添加到 XML 文件，就是暗示这个属性已经存在了。因为对旧版的相机来说情况并非如此，所以新的文件不是向下兼容的，结果其版本号必须是 2.0 。
另一个更智能的解决办法是，在相机中（！）引入一个查询寄存器，用户可以检查这个寄存器以判断这个新的属性是否已经实现。现在可以加入这个新的属性，并允许用户通过属性的访问模式来判断属性是否实现。这样这个新的文件就是向下兼容的，其版本可以是 1.1。当然，只有在一开始相机就提供这个查询机制的情况下，这个方法才是可行的。采用第二种方法的优点是，对于这个相机的整个家族，只需要维护一个相机描述文件。
注意，这里的兼容性（compatibility）指的仅仅是属性节点（feature nodes）及其功能，而不是实现节点（implementation nodes，参见 8.2 节以获得详细信息）。
7.3. 识别并缓存相机描述文件
Identifying and Caching the Camera Description File
加载一个相机描述文件可能包含一个或多个预处理步骤。为加快处理速度，预处理过的 XML 文件可以被放入缓存。在缓存中，需要一个 key 来唯一标识相机描述文件。把元素 <RegisterDescription> 的属性 VendorName、ModelName、MajorVersion、MinorVersion 和 SubMinorVersion 合并起来是足够了，但是用起来有点不方便。
为简化缓存，引入了 VersionGuid 属性，属性 VersionGuid 含有一个 GUID ，每当属性 VendorName、ModelName、MajorVersion、MinorVersion 或 SubMinorVersion 中任何一个发生变化的时候，都必须要改变这个 GUID 。VersionGuid 唯一地标识一个相机描述文件的某个版本，和文件名。
不必把所有不同的相机描述文件都放入缓存，可以只放最新的文件，最新的文件通过向下兼容的方式包含了所有其它的。对于每个 VendorName、ModelName 和 MajorVersion 号，都有一个这样的文件。这种文件的缓存 key 是 ProductGuid，ProductGuid 也有一个 GUID ，每当 VendorName、ModelName 或 MajorVersion 发生改变的时候必须改变。
