GIGE 协议摘录 —— GVSP 协议（三）

系列文章目录

GIGE 学习笔记
GIGE 协议摘录 —— 设备发现（一）
GIGE 协议摘录 —— GVCP 协议（二）
GIGE 协议摘录 —— GVSP 协议（三）
GIGE 协议摘录 —— 引导寄存器（四）
GIGE 协议摘录 —— 照相机的标准特征列表（五）
GIGE 协议 2.0 中文版

---

---

GVSP 摘要

    GVSP 是一种依赖于 UDP 传输层协议的应用层协议。它允许 GVSP 接收器从 GVSP 发射机接收图像数据、图像信息或其他信息。

    GVSP 数据包总是从 GVSP 发射器传输到接收器。

    该规范上的当前版本使用 UDP IPv4 作为传输层协议。由于 UDP 是不可靠的，GVSP 提供了机制来保证数据包传输的可靠性（通过 GVCP），并确保最小的流量控制。

UDP 可靠性和错误恢复

数据块

    该数据块被划分为多个元素，以向 GVSP 接收机提供解码该块所需的信息。

    对于图像，可以通过两种不同的方式提供来自同一帧的多个 ROIs ：

1. 在单个流信道上 —— 当它们在同一流信道上传输时，每个 ROI 必须以不同的块 ID 进行传输。在这种情况下，必须使用相同的时间戳来促进将 ROI 与给定的暴露口相匹配，如 [CR-253st] 所指定的那样。设备可以选择在同一流通道上发送所有 ROI ，以简化传输（只配置一个流通道）。

2. 在不同的流通道上 —— 当它们在不同的流通道上传输时（每个流通道有一个 ROI），那么 ROI 应该使用相同的块 ID 值，以方便匹配。在这种情况下，时间戳仍然可以用于方便将 ROI 与给定的曝光相匹配。设备可能选择使用不同的流通道，允许不同的 ROI 发送到不同的目的地。

数据块传输模式

    数据块放入包中，允许在流通道上传输。支持两种传输模式：标准和全传输模式。

• 标准传输模式
  在标准传输模式下，数据开始标记包、数据有效负载包和数据结束标记包以不同的数据包分开。这是自 GigE 愿景成立以来所支持的标准方法。开始标记包和结束标记包划定了数据的有效载荷，并在连续的数据块之间提供清晰的分离点。
  在标准传输模式下存在三种不同的数据包类型：
  1. 数据开始标记包
  2. 数据有效载荷包
  3. 数据结束标记包

    下图说明了在标准传输模式下的数据包的顺序。

• 全传输模式
      可选地，如果数据开始标记、数据有效载荷和数据结束标记可以装入单个数据包，那么 GVSP 发射器可以配置为重新分组它们。这是一种全能的传输模式，可用于减少拥有单独的数据开始标记和数据结束标记包的开销。应用程序必须验证是否支持此传输模式（SCCx 的第 29 位）并启用它（SCCFGx 的第 29 位），否则将使用标准传输模式。

数据块数据包头

    所有的 GVSP 数据包共享相同的基本报头。GVSP 协议报头不包括长度字段： GVSP 接收器使用 UDP 长度信息来确定数据包的大小。

标准传输模式数据包

    为标准传输模式定义了以下数据包。

数据开始标记数据包

• 数据开始标记包必须是块的第一个包。
• 数据引线包必须以单独的包发送，packet_id/packet_id32设置为0。它必须适合一个最多576字节的包（包括IP、UDP和GVSP头）。
• 数据开始标记包必须遵循图24-4的布局。

全传输模式包

块数据

    块是经过标记的数据块，可以在数据块中分组以发送元数据。数据块的例子是：

• 图像
• 从图像中提取数据
• AOI / 像素格式
• I/O 引脚的状态
• 曝光数

有效载荷类型（Image Payload Type）

    为了有效地传输信息，GVSP 定义了可以从 GVSP 发射机中流式传输的各种有效载荷类型。下表中列出了这些有效负载类型。

1、扩展块模式（Extended Chunk Mode）

2、图像有效载荷类型（Image Payload Type）

    此有效载荷类型用于传输未压缩的图像。

    如果支持图像有效负载，则使用图像有效负载类型的流必须以光栅扫描格式在每个数据有效负载数据包中放置数据。

这意味着图像在从左到右传输，然后从上到下传输之前，要在GVSP发射器存储器中重建。这是典型的单触头传感器。

2.1 Image Data Leader Packet（图像数据开始标记包）

2.2 Image Data Payload Packet（图像数据有效负载包）

2.3 Image Data Trailer Packet（图像数据结束标记包）

2.4 Image All-in Packet（图像全输入数据包）

3、原始数据有效载荷类型（Raw Data Payload Type）

    这种有效载荷类型用于将原始数据从 GVSP 发送器传输到 GVSP 接收器。例如，这可以用来发送采集统计信息。

3.1 Raw Data Leader Packet

3.2 Raw Data Payload Packet

3.3 Raw Data Trailer Packet

3.4 Raw All-in Packet

4、文件有效载荷类型（File Payload Type）

    这种有效负载类型用于传输可以直接保存到 GVSP 接收器硬盘上的文件。例如， GVSP 发射机可以使用 GIF 图像压缩将压缩文件发送到 GVSP接收器。

4.1 File Data Leader Packet

4.2 File Data Payload Packet

4.3 File Data Trailer Packet

4.4 File All-in Packet

5、块数据有效载荷类型（Chunk Data Payload Type）

    这种有效负载类型用于流数据块。这类似于扩展块模式，但没有主有效负载类型。因此，第一个块可以是任何东西。

5.1 Chunk Data Leader Packet

5.2 Chunk Data Payload Packet

5.3 Chunk Data Trailer Packet

5.4 Chunk All-in Packet

6、扩展块数据有效载荷类型（已弃用）（Extended Chunk Data Payload Type (deprecated)）

7、JPEG有效载荷类型（JPEG Payload Type）

    本节介绍 ITU Rec. T.81 的 GVSP 有效载荷类型，更著名的名称是 JPEG。这种 JPEG 有效载荷类型的灵感来自于 RFC2435 。

7.1 JPEG原则（JPEG Principles）

JPEG 图片格式详解
JPEG 文件格式详解

    JPEG 编码器用于对（即压缩）“原始” 图像进行编码，以生成符合 JPEG 标准的压缩数据流。数据流的格式由 JPEG 标准定义。

    下图显示了一个在 ITU Rec. T.81 中所描述的 JPEG 压缩数据流。JPEG 压缩数据流以图像开始（SOI）标记开始，包含一个压缩图像，并以图像结束（EOI）标记结束。

    帧以帧标题开始，并包含一个或多个扫描。扫描是对图像中的一个或多个组件的单次数据传递。帧报头之前可以带有 JPEG 标准中指定的一个或多个表规范或杂项标记段。

    扫描以一个扫描头开始，并包含一个或多个熵编码的数据段。每个扫描报头之前可以有一个或多个表规范或杂项标记段。如果没有启用重启，则只有一个熵编码的段（标记为 “最后” 的段），并且没有重启标记。如果启用重新启动，熵编码段的数量由图像的大小和定义的重启间隔定义。在这种情况下，除了最后一个标记外，每个熵编码的段后面都有一个重启标记。重新启动 JPEG 数据中的标记表示解码器应该重置其状态的一个点。

    熵编码段由一个最小熵编码单元的序列组成。

7.2 针对 GVSP 的 JPEG 实现（JPEG Implementation for GVSP）

    JPEG 压缩数据流包括解码和显示压缩图像所需的大部分信息。本规范定义了一种 GVSP 有效负载格式，使 GVSP 接收器能够在不知道视频编码器的特性的情况下解码和显示所编码的图像。在 JPEG 压缩数据流中编码的图像在单个 GVSP 数据块上传输。

    JPEG 有效载荷类型只有在 GVSP 视觉扩展 ID 模式下才支持 GigE 视觉扩展 ID 模式（即 GVSP 数据包的EI字段必须设置为 1）。

7.3 JPEG Data Leader Packet

7.4 JPEG Data Payload Packet

7.5 JPEG Data Trailer Packet

7.6 JPEG All-in Packet

8、JPEG 2000有效载荷类型（JPEG 2000 Payload Type）

    本节描述了 ITU-T Rec T.800 的 GVSP 有效负载类型。更著名的名称是 JPEG 2000 。这种 JPEG 2000 有效载荷类型的灵感来自于 RFC5371 。

8.1 JPEG 2000原则（JPEG 2000 Principles）

    一个 JPEG 2000 编码器用于编码（压缩）一个 “原始” 图像，以产生一个符合 JPEG 2000 标准的代码流。此代码流的格式由 JPEG 2000 标准定义。

    下图显示了一个 JPEG 2000 代码流。JPEG 2000 代码流从主报头开始构造，从代码流的开始（SOC）标记、一个或多个贴图和代码流的结束（EOC）标记开始，以表示代码流的结束。每个平铺由一个从开始瓷砖部分头（SOT）标记开始到开始数据（SOD）标记和位流（一系列 JPEG 2000 数据包）组成。

    需要注意的是，平铺被定义为一个分别进行转换和编码的图像的矩形区域。另外，我们也不应该将上面段落中引用的 JPEG 2000 数据包与用于通过以太网传输 JPEG 2000 码流的 IP 数据包相混淆。

8.2 针对 GVSP 的 JPEG 2000 实现（JPEG 2000 Implementation for GVSP）

    JPEG 2000 代码流包括解码和显示压缩图像所需的大部分信息。本规范定义了一种 GVSP 有效负载格式，使 GVSP 接收器能够在不知道视频编码器的特性的情况下解码和显示所编码的图像。换句话说，JPEG 2000 GVSP 有效载荷视频源包括解码和显示编码图像所需的所有信息。它不依赖于使用能力公告和提供/应答协议。在 GigE 视觉系统中，假设一个更高层次的管理实体负责配置系统，以便视频接收器能够解码相关视频源提供的视频。因此，缺乏对能力公告和提供/回答协议的支持并不被认为是一个问题，因为当前用于未压缩视频传输的 GigE 视觉系统级模型并不依赖于这种机制。然而，如果人们认为需要，本规范并不阻止人们使用这样的协议。

    包含一个压缩图像的数据的 JPEG 2000 编码流被作为一个 GVSP 数据块传输。

    JPEG 2000 有效负载类型只支持 GigE 视觉扩展 ID 模式（即 GVSP 数据包的 EI 字段必须设置为 1 ）。

8.3 JPEG 2000 Data Leader Packet

    数据引导包包括在 JPEG 2000 码流中不可获得的信息。

8.4 JPEG 2000 Data Payload Packet

8.5 JPEG 2000 Data Trailer Packet

8.6 JPEG 2000 All-in Packet

9、H.264有效载荷类型（H.264 Payload Type）

    本节描述了 ITU-T Rec H.264 的 GVSP 有效负载类型，也称为 MPEG-4 Part 10 / MPEG-4 AVC 。这种 H.264 有效载荷类型的灵感来自于 RFC3984 。

9.1 H.264原则（H.264 Principles）

    H.264 规范定义了两个概念层：视频编码层（VCL）和网络抽象层（NAL）。

    VCL 包含编解码器的信号处理功能。它定义了诸如变换、量化、运动补偿预测和循环滤波器等机制。它遵循大多数帧间视频编解码器的一般概念，即基于宏块的编码器，它使用图像间预测与运动补偿和剩余信号的转换编码。宏块是一个 16x16 的 luma 样本块和两个相应的色度样本块，或一个单色图像的样本块，或使用三个独立的颜色平面编码的图片。VCL 编码器输出切片：一个比特流，其中包含整数个宏块的宏块数据和片头的信息（包含切片中第一个宏块的空间地址、初始量化参数和类似信息）。切片中的宏块通常按扫描顺序排列，除非使用灵活的宏块排序（FMO）语法指定了不同的宏块分配。图内预测仅在一个切片中使用。

    网络抽象层（NAL）编码器将 VCL 编码器的片输出封装到网络抽象层单元（NAL 单元）中，这些单元适用于在包网络上传输或在面向包的多路复用环境中使用。

9.2 针对 GVSP 的 H.264 实现（H.264 Implementation for GVSP）

    此规范定义了数据块传输一个访问单元。这使得可以在一个块中传输多个 NAL 单元，以优化传输开销。GVSP 数据有效负载包可以携带单个 NAL 单元、多个 NAL 单元或一个 NAL 单元的片段。这样做是为了通过优化用于传输访问单元的 GVSP 数据有效载荷数据包的数量来最小化 GVSP 传输开销。该方案的分支是，并不是所有的 GVSP 数据有效负载包都可以携带相同量的数据。这与大多数其他有效负载类型不同，其中只有最后一个数据有效负载包可能更小。因此，一个 H.264 接收器必须能够容纳一个 NAL 单元后的间隙。这个间隙一直延伸到下一个数据包的开始阶段。接收方使用由 SCPSx 寄存器提供的默认数据包大小，知道在 NAL 单元结束后的下一个数据包的位置。它解析 NAL 数据并跳过这些间隙。

    本规范定义了一种让接收机解码和显示 H.264 编码的 GVSP 流的方法，而不需要了解编码器的功能。它不依赖于能力公告和提供/回答模型的实现。在 H.264 访问单元中不可用的信息被包含在 GVSP 数据块中。这可能会导致一些以太网带宽的浪费，因为额外的信息将在每个块中传递，而不是在流媒体会话启动之前进行自动协商。

    H.264 有效负载类型仅支持 GigE 视觉扩展 ID 模式（即，GVSP 数据包的 EI 字段必须设置为 1 ）。

9.3 H.264 Data Leader Packet

    数据先导包包括在 H.264 接入单元中不可用的信息。应该注意的是，时间戳不包括在内，因为它将包含在数据有效负载包中。

9.4 H.264 Data Payload Packet

    下图显示了根据 RFC3984 中提供的封装方法的 H.264 数据有效载荷包的数据字段的布局。有关更多详情，请参考本 RFC 和 H.264 标准。

9.5 H.264 Data Trailer Packet

9.6 H.264 All-in Packet

10、多区域图像有效载荷类型（Multi-zone Image Payload Type）

    如前所述，自本规范第 1.0 版以来可用的图像有效负载类型处理图像数据的光栅扫描传输。这是一个理想的适合相机，其中传感器输出数据在一个单一的点击。否则，照相机必须在传输前首先以光栅扫描格式重建图像。这可能会引入一些额外的延迟，并产生传输带宽的峰值。为了解决这种情况，GigEVision2.0 版本引入了可选的多区域图像有效载荷类型。

    多区域图像有效载荷类型的目的是通过将图像划分为水平波段来改善来自多个点击传感器的图像数据传输的延迟特性。每一个水平带都被称为 “区域” 。一旦一个区域的下一个数据包准备好了，发射机就可以开始从某一个区域传输数据。

    多区域图像对于支持传感器特别有用，它具有一些自上而下读取和一些自下而上读取的功能。

10.1 多区域图像原理（Multi-zone Image Principles）

    多区域图像有效载荷类型的主要目标是改善多点击传感器从图像内的不同垂直位置开始的支持。例如，一个 2 次点击的传感器可以从图像的顶部开始有一个点击，从底部开始有一个第二次点击。通过将图像划分为水平区域（见下面的图 25-43 ），相机能够更早地开始从这些区域的数据传输，减少总体延迟和内部图像缓冲。

11、设备特定有效载荷类型（Device-specific Payload Type）

    此有效载荷类型可用于传输特定于设备（自定义）的信息。

11.1 Device-specific Data Leader Packet

11.2 Device-specific Data Payload Packet

11.3 Device-specific Data Trailer Packet

11.4 Device-specific All-in Packet

像素布局（Pixel Layouts）

    本节描述了 GigE Vision 所支持的各种像素和图像布局。在 GigE 视觉 2.0 版本中，这些布局是基于 GenICam 像素格式命名约定的。

    注意：本节中的图形使用小端模式，即 位0 在右边。这与像素格式命名约定相一致。因此，msb（位 7）在每个字节的左侧，而 lsb（位 0）在右边。

    选择像素深度和格式的机制在 XML 设备描述文件中提供。

1、像素对齐（Pixel Alignment）

    为了最小化GVSP接收端的像素处理时间，在有效载荷数据包中使用多字节的像素数据在默认情况下必须是小端化的。

    GVSP 发射机可以实现一个转换器，将像素从小端转换为大端。当受支持时，可以使用 SCPSx 引导寄存器（pixel_endianess 字段）激活此转换器。SCCx 寄存器的 big_and_little_endian_supported 字段表示是否支持此转换器。

    在下面的图中，字节 0 首先在数据线上发送，然后是字节 1 ，以此类推。

2、线和图像边界（Line and Image Boundaries）

    GigE 视觉使用在像素格式命名约定中定义的图像填充。图像填充要求在直线的末尾不插入人工填充。

    因此，对于某些分组和打包的像素格式，来自不同行的像素可能被组合在相同的字节中。例如，想象一个奇宽的图像（例如：宽度= 641像素）。如果像素成对组合（由于填充），那么第一行的最后一个像素将与第二行的第一个像素组合，如下所示。

    另一个例子是当使用 Mono1p 时，图像宽度不是 8 像素的倍数。使用这种像素格式填充一个字节需要 8 个像素，因此一行的最后一个像素可能不会与字节边界对齐。

3、像素格式（Pixel Formats）

    本节说明了GVSP本地支持的各种像素格式。这些像素格式基于像素格式命名约定文档，其中每个像素格式由5个特征定义：

1. 组件和位置（Components and Location）
2. #位（# bits）
3. 标志指示灯（可选）（Sign indicator）
4. 包装方式（可选）（Packing Style）
5. 特定于接口的（可选的）（Interface-specific）

    上述像素在一个名为 “GigE Vision appendix – Pixel Format” 的单独文档中详细说明。请参考本文档，特别是对于表 26-1 中列出的不符合 PFNC 要求的像素格式。

    GenICam PFNC 文档解释了如何创建新的像素格式。GenICam 委员会维护了一份文档，其中列出了分配给每个像素格式的 32 位值。请注意，由 GenICam 像素格式值文档定义的其他像素格式，以及自定义像素格式，也可以由 GVSP 发射机或 GVSP 接收器使用。它不受上表中列表的限制。

    对于 32 位像素格式 ID 值，可以按照 GenICam 像素格式文档 GenICam 像素格式值文档中列出的规则来实现自定义像素格式。这是通过将 pixel_format 的最重要位设置为1，并使用剩余的 31 位作为特定于制造商来实现的。自定义像素格式只能在不存在标准像素格式时使用，因为它们阻止了互操作性。

3.1 Mono1p

    这种像素格式定义了一个 1 位单色、无符号、8 个像素打包的一个字节格式。有关其他信息，请参阅像素格式命名约定。必须将总图像有效载荷的最后一个数据字节填充到最近的 8 位边界。因此，如果图像宽度不是 8 个像素的倍数，则在图像的每一行的末尾不添加填充物。

#define MV_GVSP_PIX_MONO                                0x01000000
#define MV_GVSP_PIX_OCCUPY1BIT                          0x00010000

#define MV_GVSP_PIX_MONO1P  (MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY1BIT | 0x0037)

3.2 Mono2p

    这种像素格式定义了一个 2 位单色、无符号、4 个像素打包的一个字节格式。有关其他信息，请参阅像素格式命名约定。总图像有效负载的最后一个数据字节必须填充到最近的 8 位。因此，如果图像宽度不是 4 个像素的倍数，则在图像的每一行的末尾不添加填充物。

#define MV_GVSP_PIX_MONO                                0x01000000
#define MV_GVSP_PIX_OCCUPY2BIT                          0x00020000

#define MV_GVSP_PIX_MONO2P	(MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY2BIT | 0x0038)

3.3 Mono4p

    这种像素格式定义了一个 4 位单色、无符号、2 个像素打包的一个字节格式。有关其他信息，请参阅像素格式命名约定。总图像有效负载的最后一个数据字节必须填充到最近的 8 位。因此，如果图像宽度不是 2 个像素的倍数，则在图像的每一行的末尾不添加填充物。

#define MV_GVSP_PIX_MONO                                0x01000000
#define MV_GVSP_PIX_OCCUPY4BIT                          0x00040000

#define MV_GVSP_PIX_MONO4P	(MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY4BIT | 0x0039)

3.4 Mono8

    此像素格式定义了一个 8 位单色、无符号、非打包的格式。有关其他信息，请参阅像素格式命名约定。

#define MV_GVSP_PIX_MONO                                0x01000000
#define MV_GVSP_PIX_OCCUPY8BIT                          0x00080000

#define MV_GVSP_PIX_MONO8	(MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY8BIT | 0x0001)

3.5 Mono8s

    此像素格式定义了一个 8 位单色、有符号、非压缩的格式。有关其他信息，请参阅像素格式命名约定。

#define MV_GVSP_PIX_MONO                                0x01000000
#define MV_GVSP_PIX_OCCUPY8BIT                          0x00080000

#define MV_GVSP_PIX_MONO8_SIGNED  (MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY8BIT  | 0x0002)

3.6 Mono10

    此像素格式定义了一个 10 位单色、无符号、非打包的格式。有关其他信息，请参阅像素格式命名约定。

#define MV_GVSP_PIX_MONO                                0x01000000
#define MV_GVSP_PIX_OCCUPY16BIT                         0x00100000

#define MV_GVSP_PIX_MONO10   (MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY16BIT | 0x0003)

3.7 Mono10Packed

    这种像素格式定义了一种 10 位单色、无符号、GigE 视觉特定的打包格式。

    注意：此像素格式不尊重像素格式命名约定，因为该格式是在 GigE Vision 1.0 中引入的（在创建像素格式命名约定之前）。

    使用这种 GigE Vision 打包风格，两个 10 位像素被打包成 24 位，如下图所示（小端布局）。与像素格式命名约定的分组样式的主要区别在于字节的排序（分组字节是像素格式命名约定的最后一个字节）。

#define MV_GVSP_PIX_MONO                                0x01000000
#define MV_GVSP_PIX_OCCUPY12BIT                         0x000C0000

#define MV_GVSP_PIX_MONO10_PACKED  (MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY12BIT | 0x0004)

3.8 Mono12

    此像素格式定义了一个 12 位单色、无符号、非打包的格式。有关其他信息，请参阅像素格式命名约定。

#define MV_GVSP_PIX_MONO                                0x01000000
#define MV_GVSP_PIX_OCCUPY16BIT                         0x00100000

#define MV_GVSP_PIX_MONO12	(MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY16BIT | 0x0005)

3.9 Mono12Packed

    这种像素格式定义了一种 12 位单色、无符号、GigE 视觉特定的打包格式。

    注意：此像素格式不尊重像素格式命名约定，因为该格式是在 GigE Vision 1.0 中引入的（在创建像素格式命名约定之前）。

    使用这种 GigE Vision 打包风格，两个 12 位像素被打包成 24 位，如下图所示（小端布局）。与像素格式命名约定的分组样式的主要区别在于字节的排序（分组字节是像素格式命名约定的最后一个字节）。

#define MV_GVSP_PIX_MONO                                0x01000000
#define MV_GVSP_PIX_OCCUPY12BIT                         0x000C0000

#define MV_GVSP_PIX_MONO12_PACKED  (MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY12BIT | 0x0006)

    请注意，当图像宽度包含奇数数的像素时，第二行的第一个像素将不会在 3 字节的边界上开始对齐。

3.10 Mono14

    此像素格式定义了一种 14 位单色、无符号、非打包的格式。有关其他信息，请参阅像素格式命名约定。

#define MV_GVSP_PIX_MONO                                0x01000000
#define MV_GVSP_PIX_OCCUPY16BIT                         0x00100000

#define MV_GVSP_PIX_MONO14  (MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY16BIT | 0x0025)

3.11 Mono16

    此像素格式定义了一个 16 位单色、无符号、解打包的格式。有关其他信息，请参阅像素格式命名约定。

#define MV_GVSP_PIX_MONO                                0x01000000
#define MV_GVSP_PIX_OCCUPY16BIT                         0x00100000

#define MV_GVSP_PIX_MONO16	(MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY16BIT | 0x0007)

3.12 BayerGR8

    这种像素格式定义了一个 8 位的 GRBG（绿-红-蓝-绿）拜耳模式，无符号，解打包格式。有关其他信息，请参阅像素格式命名约定。

    所有的拜耳像素格式（像素格式功能）必须代表完整图像的拜耳模式（没有 ROI )。

    GVSP 数据引线（ data leader ）的 pixel_format 字段包含完整图像的实际拜耳像素格式。当 ROI 被激活时，接收器可以查看 offset_x 和 offset_y 字段，以确定它是否需要相对于其左上角调整拜耳瓷砖（Bayer tile）进行解码。

    注意：GVSP 数据必须自描述，以便使任何接收器能够解码图像流。因此，以需要使用不同的像素格式进行解码的方式修改原始图像数据的特征必须确保像素格式字段和像素格式特性被相应地设置。

    为了使像素格式（PixelFormat）特性与图像数据引线（Data Leader）的像素格式字段相匹配，建议将任何感兴趣区域的偏移量与拜耳贴图的大小对齐（In order for the PixelFormat feature to match the pixel_format field of the Image Data Leader, it is recommended to align the offset of any area of interest to the size of the Bayer tile.）。这通常是通过在 GenICamTM 标准特性命名约定的OffsetX和OffsetY特性上增加2个像素来实现的。

    此外，当实现图像翻转时（GenICam 标准特征命名约定的 ReverseY 功能），设备内部应该通过在翻转方向上将图像捕获移动 1 像素来补偿在拜耳瓷砖上发生的镜像效应。（Additionally, when implementing image flip (ReverseX and ReverseY features of the GenICam Standard Features Naming Convention), the device should internally compensate for the mirror effect taking place on the Bayer tile by shifting image capture by 1 pixel in the direction of the flip.）

    上述原则也适用于任何颜色滤光器阵列（CFA）图案。

#define MV_GVSP_PIX_MONO                                0x01000000
#define MV_GVSP_PIX_OCCUPY8BIT                          0x00080000

#define MV_GVSP_PIX_BAYGR8	(MV_GVSP_PIX_MONO | MV_GVSP_PIX_OCCUPY8BIT | 0x0008)

3.13 BayerRG8

    这种像素格式定义了一个 8 位 RGGB（红绿-绿蓝）拜耳模式，无符号，未打包格式。有关其他信息，请参阅像素格式命名约定。

3.14 BayerGB8

3.16 BayerGR10

    这种像素格式定义了一个 10 位的 GRBG（绿-红-蓝-绿）拜耳模式，无符号的，未打包的格式。有关其他信息，请参阅像素格式命名约定。

3.20 BayerGR12

    这种像素格式定义了一个 12 位 GRBG（绿-红-蓝绿色）拜耳模式，无符号，解打包格式。有关其他信息，请参阅像素格式命名约定。

3.24 BayerGR10Packed

    这种像素格式定义了一个 10 位的 GRBG（绿-红-蓝-绿）拜耳模式，无符号，GigE 视觉特定的打包格式。

    注意：此像素格式不尊重像素格式命名约定，因为该格式是在 GigE Vision 1.0 中引入的（在创建像素格式命名约定之前）。

    使用这种 GigE Vision 包装风格，两个 10 位的颜色组件（ C1 和 C2 ）被打包成 24 位，如下图所示（小端布局）。与像素格式命名约定的分组样式的主要区别在于字节的排序（分组字节是像素格式命名约定的最后一个字节）。

    上面的打包方式与 **Mono10Packed ** 相同。

3.28 BayerGR12Packed

    这种像素格式定义了一个 12 位的 GRBG（绿-红-蓝-绿）拜耳模式，无符号，GigE 视觉特定的打包格式。

    注意：此像素格式不尊重像素格式命名约定，因为该格式是在 GigE Vision 1.0 中引入的（在创建像素格式命名约定之前）。

    使用这种 GigE Vision 打包风格，两个 12 位的颜色组件（C1和C2）被打包成 24 位，如下图所示（小端布局）。与像素格式命名约定的分组样式的主要区别在于字节的排序（分组字节是像素格式命名约定的最后一个字节）。

    上面的打包方式与 Mono12Packed 相同。

3.32 BayerGR16

    这种像素格式定义了一个 16 位的 GRBG（绿-红-蓝-绿）拜耳模式，无符号，解打包格式。有关其他信息，请参阅像素格式命名约定。

3.36 RGB8

    此像素格式定义了一个 8 位 RGB（红-绿-蓝）、无符号、解压缩格式。有关其他信息，请参阅像素格式命名约定。

#define MV_GVSP_PIX_COLOR                               0x02000000
#define MV_GVSP_PIX_OCCUPY24BIT                         0x00180000

#define MV_GVSP_PIX_RGB8_PACKED  (MV_GVSP_PIX_COLOR | MV_GVSP_PIX_OCCUPY24BIT | 0x0014)

3.37 BGR8

    此像素格式定义了一个 8 位 BGR（蓝绿-红色）、无符号、解打包的格式。有关其他信息，请参阅像素格式命名约定。

3.38 RGBa8

    此像素格式定义了一个 8 位RGBa（红-绿-蓝-透明通道）、无符号、解压缩格式。有关其他信息，请参阅像素格式命名约定。alpha 组件的内容是特定于制造商的。

3.39 BGRa8

    此像素格式定义了一种 8 位 BGRa（蓝-绿-红-阿尔法）、无符号、解压缩格式。请参阅像素格式命名约定以获取更多信息。alpha 组件的内容为特定于制造商。

3.40 RGB10

    此像素格式定义了一个 10 位 RGB（红-绿-蓝）、无符号、解压缩格式。有关其他信息，请参阅像素格式命名约定。

3.41 BGR10

    这种像素格式定义了一个 10 位 BGR（蓝绿-红色）、无符号、解压缩格式。有关其他信息，请参阅像素格式命名约定。

3.42 RGB12

    此像素格式定义了一个 12 位 RGB（红-绿-蓝）、无符号、解压缩格式。有关其他信息，请参阅像素格式命名约定。

3.43 BGR12

    这种像素格式定义了一个 12 位 BGR（蓝绿-红色）、无符号、解压缩格式。有关其他信息，请参阅像素格式命名约定。

3.44 RGB16

    此像素格式定义了 16 位 RGB（红绿-蓝）、无符号、解压缩格式。有关其他信息，请参阅像素格式命名约定。

3.45 RGB10V1Packed

    这种像素格式定义了一个 10 位 RGB（红-绿-蓝）、无符号、GigE 视觉特定的打包格式。

    使用这种 GigE Vision 包装风格，三个 10 位的颜色组件被组合成 32 位，如下所示（小端布局）。与像素格式命名约定的分组样式的主要区别是字节的顺序。

3.50 YUV411_8_UYYVYY

    此像素格式定义了一个 8 位 YUV 4：1：1、无符号、解打包的格式。有关其他信息，请参阅像素格式命名约定。

3.54 YCbCr8_CbYCr

    此像素格式定义了一个 8 位 YCbCr 4：4：4，无符号、解打包格式。此像素格式为每个组件使用 256 个值的全部范围。有关其他信息和颜色空间转换，请参阅像素格式命名约定。请注意在像素格式名称的末尾明确列出的组件顺序。

3.66 RGB8_Planar

    这个像素格式定义了一个 8 位 RGB（红绿蓝）、无符号、未压缩、平面格式，其中每个颜色平面在不同的流通道上传输。

    这种像素格式需要 3 个连续的流通道。

• 红色平面（流通道 N）（Red plane (stream channel N)）：

• 绿色平面（流通道 N+1)（Green plane (stream channel N+1)）：

• 蓝色平面（流通道 N+2)（Blue plane (stream channel N+2)）：

3.69 RGB16_Planar

    这个像素格式定义了一个 16 位 RGB（红绿蓝）、无符号、未压缩的平面格式，其中每个颜色平面在不同的流通道上传输。

    这种像素格式需要 3 个连续的流通道。

像素格式定义（Pixel Format Defines）

    下面为 GVSP 支持的各种像素格式提供了 #define 定义。每个像素格式都用一个 32 位的值来表示。上面的 8 位表示该颜色。第二个上 8 位表示一个像素所占用的位数（包括任何填充）。这可用于快速计算使用此像素格式存储图像所需的内存量。

//===================================================
// PIXEL FORMATS
//===================================================
// Indicate if pixel is monochrome or RGB
#define GVSP_PIX_MONO 0x01000000
#define GVSP_PIX_RGB 0x02000000 // deprecated in version 1.1
#define GVSP_PIX_COLOR 0x02000000
#define GVSP_PIX_CUSTOM 0x80000000
#define GVSP_PIX_COLOR_MASK 0xFF000000
// Indicate effective number of bits occupied by the pixel (including padding).
// This can be used to compute amount of memory required to store an image.
#define GVSP_PIX_OCCUPY1BIT 0x00010000
#define GVSP_PIX_OCCUPY2BIT 0x00020000
#define GVSP_PIX_OCCUPY4BIT 0x00040000
#define GVSP_PIX_OCCUPY8BIT 0x00080000
#define GVSP_PIX_OCCUPY12BIT 0x000C0000
#define GVSP_PIX_OCCUPY16BIT 0x00100000
#define GVSP_PIX_OCCUPY24BIT 0x00180000
#define GVSP_PIX_OCCUPY32BIT 0x00200000
#define GVSP_PIX_OCCUPY36BIT 0x00240000
#define GVSP_PIX_OCCUPY48BIT 0x00300000
#define GVSP_PIX_EFFECTIVE_PIXEL_SIZE_MASK 0x00FF0000
#define GVSP_PIX_EFFECTIVE_PIXEL_SIZE_SHIFT 16
// Pixel ID: lower 16-bit of the pixel formats
#define GVSP_PIX_ID_MASK 0x0000FFFF
#define GVSP_PIX_COUNT 0x46 // next Pixel ID available

1、单个缓冲区格式定义（Mono buffer format defines）

#define GVSP_PIX_MONO1P (GVSP_PIX_MONO | GVSP_PIX_OCCUPY1BIT | 0x0037)
#define GVSP_PIX_MONO2P (GVSP_PIX_MONO | GVSP_PIX_OCCUPY2BIT | 0x0038)
#define GVSP_PIX_MONO4P (GVSP_PIX_MONO | GVSP_PIX_OCCUPY4BIT | 0x0039)
#define GVSP_PIX_MONO8 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY8BIT | 0x0001)
#define GVSP_PIX_MONO8S (GVSP_PIX_MONO | GVSP_PIX_OCCUPY8BIT | 0x0002)
#define GVSP_PIX_MONO10 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY16BIT | 0x0003)
#define GVSP_PIX_MONO10_PACKED (GVSP_PIX_MONO | GVSP_PIX_OCCUPY12BIT | 0x0004)
#define GVSP_PIX_MONO12 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY16BIT | 0x0005)
#define GVSP_PIX_MONO12_PACKED (GVSP_PIX_MONO | GVSP_PIX_OCCUPY12BIT | 0x0006)
#define GVSP_PIX_MONO14 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY16BIT | 0x0025)
#define GVSP_PIX_MONO16 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY16BIT | 0x0007)

2、Bayer buffer format defines

#define GVSP_PIX_BAYGR8 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY8BIT | 0x0008)
#define GVSP_PIX_BAYRG8 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY8BIT | 0x0009)
#define GVSP_PIX_BAYGB8 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY8BIT | 0x000A)
#define GVSP_PIX_BAYBG8 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY8BIT | 0x000B)
#define GVSP_PIX_BAYGR10 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY16BIT | 0x000C)
#define GVSP_PIX_BAYRG10 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY16BIT | 0x000D)
#define GVSP_PIX_BAYGB10 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY16BIT | 0x000E)
#define GVSP_PIX_BAYBG10 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY16BIT | 0x000F)
#define GVSP_PIX_BAYGR12 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY16BIT | 0x0010)
#define GVSP_PIX_BAYRG12 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY16BIT | 0x0011)
#define GVSP_PIX_BAYGB12 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY16BIT | 0x0012)
#define GVSP_PIX_BAYBG12 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY16BIT | 0x0013)
#define GVSP_PIX_BAYGR10_PACKED (GVSP_PIX_MONO | GVSP_PIX_OCCUPY12BIT | 0x0026)
#define GVSP_PIX_BAYRG10_PACKED (GVSP_PIX_MONO | GVSP_PIX_OCCUPY12BIT | 0x0027)
#define GVSP_PIX_BAYGB10_PACKED (GVSP_PIX_MONO | GVSP_PIX_OCCUPY12BIT | 0x0028)
#define GVSP_PIX_BAYBG10_PACKED (GVSP_PIX_MONO | GVSP_PIX_OCCUPY12BIT | 0x0029)
#define GVSP_PIX_BAYGR12_PACKED (GVSP_PIX_MONO | GVSP_PIX_OCCUPY12BIT | 0x002A)
#define GVSP_PIX_BAYRG12_PACKED (GVSP_PIX_MONO | GVSP_PIX_OCCUPY12BIT | 0x002B)
#define GVSP_PIX_BAYGB12_PACKED (GVSP_PIX_MONO | GVSP_PIX_OCCUPY12BIT | 0x002C)
#define GVSP_PIX_BAYBG12_PACKED (GVSP_PIX_MONO | GVSP_PIX_OCCUPY12BIT | 0x002D)
#define GVSP_PIX_BAYGR16 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY16BIT | 0x002E)
#define GVSP_PIX_BAYRG16 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY16BIT | 0x002F)
#define GVSP_PIX_BAYGB16 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY16BIT | 0x0030)
#define GVSP_PIX_BAYBG16 (GVSP_PIX_MONO | GVSP_PIX_OCCUPY16BIT | 0x0031)

3、RGB打包的缓冲区格式定义（RGB Packed buffer format defines）

#define GVSP_PIX_RGB8 (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY24BIT | 0x0014)
#define GVSP_PIX_BGR8 (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY24BIT | 0x0015)
#define GVSP_PIX_RGBA8 (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY32BIT | 0x0016)
#define GVSP_PIX_BGRA8 (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY32BIT | 0x0017)
#define GVSP_PIX_RGB10 (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY48BIT | 0x0018)
#define GVSP_PIX_BGR10 (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY48BIT | 0x0019)
#define GVSP_PIX_RGB12 (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY48BIT | 0x001A)
#define GVSP_PIX_BGR12 (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY48BIT | 0x001B)
#define GVSP_PIX_RGB16 (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY48BIT | 0x0033)
#define GVSP_PIX_RGB10V1_PACKED (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY32BIT | 0x001C)
#define GVSP_PIX_RGB10P32 (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY32BIT | 0x001D)
#define GVSP_PIX_RGB12V1_PACKED (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY36BIT | 0X0034)
#define GVSP_PIX_RGB565P (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY16BIT | 0x0035)
#define GVSP_PIX_BGR565P (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY16BIT | 0X0036)

4、YUV和YCbCr打包缓冲区格式定义（YUV and YCbCr Packed buffer format defines）

#define GVSP_PIX_YUV411_8_UYYVYY (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY12BIT | 0x001E)
#define GVSP_PIX_YUV422_8_UYVY (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY16BIT | 0x001F)
#define GVSP_PIX_YUV422_8 (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY16BIT | 0x0032)
#define GVSP_PIX_YUV8_UYV (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY24BIT | 0x0020)
#define GVSP_PIX_YCBCR8_CBYCR (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY24BIT | 0x003A)
#define GVSP_PIX_YCBCR422_8 (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY16BIT | 0x003B)
#define GVSP_PIX_YCBCR422_8_CBYCRY (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY16BIT | 0x0043)
#define GVSP_PIX_YCBCR411_8_CBYYCRYY (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY12BIT | 0x003C)
#define GVSP_PIX_YCBCR601_8_CBYCR (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY24BIT | 0x003D)
#define GVSP_PIX_YCBCR601_422_8 (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY16BIT | 0x003E)
#define GVSP_PIX_YCBCR601_422_8_CBYCRY (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY16BIT | 0x0044)
#define GVSP_PIX_YCBCR601_411_8_CBYYCRYY (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY12BIT | 0x003F)
#define GVSP_PIX_YCBCR709_8_CBYCR (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY24BIT | 0x0040)
#define GVSP_PIX_YCBCR709_422_8 (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY16BIT | 0x0041)
#define GVSP_PIX_YCBCR709_422_8_CBYCRY (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY16BIT | 0x0045)
#define GVSP_PIX_YCBCR709_411_8_CBYYCRYY (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY12BIT | 0x0042)

5、RGB平面缓冲区格式定义（RGB Planar buffer format defines）

#define GVSP_PIX_RGB8_PLANAR (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY24BIT | 0x0021)
#define GVSP_PIX_RGB10_PLANAR (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY48BIT | 0x0022)
#define GVSP_PIX_RGB12_PLANAR (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY48BIT | 0x0023)
#define GVSP_PIX_RGB16_PLANAR (GVSP_PIX_COLOR | GVSP_PIX_OCCUPY48BIT | 0x0024)

   
 

☆