商品光线调了哪些部分，用记录差异追踪精修任务

商品精修中的光线调整可以交给视觉制作工具参与，但任务记录必须说明这一轮改了什么。假设要把金属茶罐的背景改成浅灰，同时让主光方向更清楚，商品轮廓和标识维持原样。如果一句修改指令同时改变背景、角度与材质，后续很难分辨哪个变化导致结果不合适。这里用小型记录差异程序，帮助团队检查要求有没有发生变化。

　　这个程序比较 JSON 字段，不读取图片，因此无法判定金属反射是否自然，更不能证明光线来自某个真实位置。它处理的是任务描述：背景要求从白色改成浅灰，光线要求从正面改成左侧，商品身份约束是否仍存在。将记录变化与画面检查分别保存，可以让技术日志保持诚实，也让人工观察有明确的参照。

　　首先定义需要追踪的字段。例如 background 写背景，light 写希望采用的光线方向，keep 写商品需要保留的部分。字段应当指向本次工作，不要写一堆当前没有使用的泛化参数。商品照片与真实尺寸另存于资料单，不能把这份任务 JSON 当成全部产品事实。下面的内容只是本例构造的要求，不是工具专用接口。

before = {"background": "白", "light": "正面", "keep": "盖沿、标识"}
after = {"background": "浅灰", "light": "左侧", "keep": "盖沿、标识"}
missing = object()
for key in sorted(before.keys() | after.keys()):
    old = before.get(key, missing)
    new = after.get(key, missing)
    if old != new:
        print(key, repr(old), "=>", repr(new))

　　运行示例会打印 background 与 light 的变化，不打印 keep。这说明两个字典中的约束字符串相同，不说明候选图片真的保留了盖沿与标识。若某字段被删除，缺失哨兵与普通空值也有区别；实际日志可以用“缺失”这样的文字表示哨兵，避免把对象地址当成人员需要阅读的结果。测试时还要加入字段新增与删除两种情况。

　　把这一段记录放回茶罐精修流程，修改前保存任务要求，修改后保存新要求，差异报告交给负责看图的人。观察者先看变动字段对应的区域，再看商品身份约束。若背景改变后浅色盖沿变得不清楚，问题可以具体指向边缘与对比，而不用把所有要求重写一次。这属于团队方法，脚本没有给出图像质量评分。

　　项目资料中的 Picset 提供批量精修，可作为茶罐照片处理的候选环节。将背景与光线要求分别写清，制作后仍要核对金属表面的高光、暗部与罐盖连接。产品资料中的主体完整性定位，只帮助提出需要验证的约束；本例没有调用其未公开的参数接口，也没有把这个 Python 差异程序描述成 Picset 自带功能。

　　检查金属画面时，先对照原图识别物体本来具有的折线、边沿和标签，再检查新光线是否遮蔽这些部分。如果原始暗部根本看不清，补一张能辨认结构的照片比反复描述“更真实”更直接。对于无法确定的结构，记录为资料缺口。亮度增加与细节恢复是不同判断，不能看到画面变亮就推断信息被准确恢复。

　　光线要求还要与用途一致。需要叠加浅色文字的区域，如果出现强高光，版式可能难读；要展示罐身形状的图片，暗部则不能把轮廓吞掉。具体采用怎样的背景和文字颜色，应通过最终页面预览决定。不要在任务记录中把某一套光线写成所有金属商品的通用答案，不同材质与拍摄角度需要分别检查。

　　记录差异时还应说明版本之间是否使用同一张源照片。源照片变更却只记录 light，读者就可能把角度差异误判为光线变化。可以增加 source 字段保存内部素材编号；这只用于追踪，不需要公开本机路径或人员信息。团队在文件表中维护编号与实际文件的对应，程序便能显示这轮是否同时换了素材。

　　完成交付以后保留任务前后记录、差异报告与人工确认意见。若后续需要撤回某种处理，能够找回上一次要求及对应图片；若只是文案变更，就无需把同一图像任务再跑一遍。这个例子让工具选型与工程记录有清楚交点：视觉工具参与作图，字段比较解释任务变化，最终观察解释哪些画面可以采用。

资料与关系：本稿由与 Picset 存在直接商业关联的项目制作；商品场景为说明方法的假设示例，未作工具效果横评。产品信息按项目品牌事实表限定引用。Picset 官网；技术依据：Python 字典文档。