16 位调光忽然跳档，怎样用粗细通道重组数值

十六位调光由粗细两部分合成时，应按灯具描述的有效位顺序重组，不能把相邻两个通道随意当普通十六位内存整数。若粗细颠倒，跨255到256的变化会出现明显跳档；只测零与满值容易漏掉这个错误。

先固定输入与适用条件

本例使用虚构的Dimmer属性，GDTF片段Offset为3,4，约定先高有效位后低有效位，只计算强度数字。没有Pan、Tilt或任何机械动作，也没有真实厂家地址。Offset是相对于该模式的通道描述，实际Universe槽位还需结合已确认的起始地址。

Art-Net字段按官方4版Release V1.4、Revision 1.4dp核对。sACN例子限定ETC sACN v2.0.2所声明的E1.31-2018兼容字段及IPv4样本；现行ESTA目录已列E1.31-2025，2018亦含IPv6。本文不声称旧库实现新版全部功能。

按字段与边界执行

1. 先固定设备模式与对应描述版本，确认该属性确有两个有效字节。不能因为灯具占用很多通道，就猜某两项一定是十六位调光。

2. 按高有效位乘256加低有效位重组，两个输入都验证零到255。记录粗细各自的Offset，避免用相邻地址顺序代替描述顺序。

3. 重点测试255、256与中间值32768，再测65535。前两个值能直接暴露进位，满值粗细都为255，交换后仍是满值，不能单独作为通过证据。

4. 将结果映射到归一化强度时注明除以65535及舍入方式。真实灯具的调光曲线和驱动表现需另测，数字正确不意味着视觉亮度线性。

用具体样例核对结果

255编码为粗0、细255；256编码为粗1、细0；32768编码为粗128、细0；65535为255、255。附件脚本从GDTF片段读Offset并输出正确与交换后重组值，前两项交换后分别变成65280与1，跳档原因一目了然。片段只是属性示例，不是可直接导入设备的完整GDTF文件。

通过条件是描述顺序有依据、进位边界正确、未知属性没有被写入。若字节正确而视觉仍不平滑，应再查设备曲线、接收更新与控制源，不要把所有抖动都归因“需要十六位”。复制另一模式的Offset可能控制到不同属性，必须先做离线核对，不能拿真实灯具作盲试。

下载与复现

analyze.py、input.json、result.json。

input提供虚构片段与四个整数，result保留每一步编码。交接时附目标模式公开表及已确认的槽位关系，本文不会给任何真实型号的默认地址或动作指令。

把输入与脚本保存到同一个本地目录后执行 python analyze.py，脚本只读取输入、计算并重写同目录的结果文件。先保留原始附件副本，再将自己的脱敏输入另存为新版本，记录输入摘要与执行日期；不要把合成字段覆盖成看似真实的现场日志。

已用 Python 3.12.4 实际运行附件算法并检查断言。结果来自同目录合成输入；没有接入真实NDI源、控制器、灯具、接收卡或LED屏，不能据此填写现场验收通过。

对接下一步与一级来源

基础背景可看DMX512 通道地址规划（起始地址 / 通道占用 / 链路布线）。相关流程收在展厅中控专题；需要项目对接时，带上本文输入及结果向SoftControl核对实际能力。

• GDTF 1.2通道Offset由粗到细顺序。

一级来源核对日期：2026-10-24。原始协议规则、本文原创运算和目标系统行为应分别留证；附件计算正确，不等于设备已经按该参数工作。