图片为什么变色：看懂 ICC、指定与转换

面向普通网页交付，先弄清源文件的色彩配置，必要时把交付副本转换到 sRGB，并保留配置文件。指定另一个配置文件是另一件事：它改变了原有 RGB 数字的含义。这些处理也不能保证所有屏幕看起来完全一样。

一张静物图里有红陶碗、蓝色亚麻和绿叶。导出后，构图没变，红色却突然浓了许多。先别急着降低饱和度，检查文件的色彩说明是否变了。否则，你可能是在修改作品，替交付过程中的错误作补偿。

这篇文章把文件、数字的解释方式和显示设备分开。下图是原创 AI 教学插图；另外还提供三份经过真实文件处理的样例，让你能检查“指定”和“转换”的区别，而不是只看一组调过颜色的前后对比。

先确定这次到底要交付什么

用一份假设需求贯穿练习：为网站提供一张 768 × 512 图片，保留已经选定的构图，交付嵌入 sRGB 配置的文件，原图另外保存。收件人需要一份说明明确的图像，而不是专门为你的显示器调整过的版本。假如还要做印刷版，就另外确认印刷所需的输出条件，不把两份用途混成同一个设置。

开始调整前，先做一张简短的接收记录：源文件名、像素尺寸、是否带配置、配置名称、目标用途，以及在哪个应用里第一次看到变化。原样保留收到的文件，再在副本上操作。“绿色杯子显得灰了”描述的是症状；“导出 PNG 的配置与工作文档不同”才是能够继续检查的差异。只有前一种描述时，不要急着把原因归给生成模型或屏幕。

本例收到的原图是 1536 × 1024，没有嵌入配置。这是文件检查结果，不是对生成系统内部色彩空间的推断。我们为练习主动选择 sRGB，才有了可追踪的起点。面对客户的无标签文件，应先补齐这项信息；不能因为图在自己电脑上看起来舒服，就把一种猜测写成“已经还原原始颜色”。

还有一个容易漏掉的环节：打开文件，本身也可能触发处理。编辑器可以根据色彩管理策略保留嵌入配置，也可以转换到工作空间。复现之前，先检查下载文件本身，再留意应用打开它时做了什么。如果程序自动把 P3 转成 sRGB，你随后检查的工作文档就已经不是未动过的 P3 下载件。Adobe 在缺失配置与配置不匹配策略中说明了这些选择。

保留一份没有经过打开后另存的下载件，并把自动转换写进记录。“下载文件没有配置”和“应用把它放进了 sRGB 工作文档”，可以是在不同阶段同时成立的两句话。前者描述收到的文件，后者描述软件处理后的文档。如果不注明阶段，就很容易误以为同一检查互相矛盾，或者把自动转换误认成图像原本自带的信息。

具体做法很简单：接收时先记文件状态；打开时记是否转换；导出后再记最终状态。不要拿最后一步看到的标签，倒推最初一步一定相同。这份按阶段分开的记录，也是以后向设计师或开发者说明问题时最有用的材料。

RGB 数字需要一份说明

一个 RGB 像素包含红、绿、蓝三个数值，但数字本身还不足以完整说明颜色。色彩空间定义这些数字的意义；嵌入的 ICC 配置文件让支持色彩管理的软件能够把这份说明带进后续流程。ICC 将配置文件描述为设备坐标与共同色彩参照之间的映射。ICC：色彩管理常见问题

图像配置和显示器配置分工不同。前者说明图像怎样编码；后者描述某一台显示器的特性，供软件调整显示。把图像的配置替换成自己显示器的配置，并不是通用的网页导出办法。

这里其实有三张不同的检查单。颜色模式告诉你文件使用 RGB 通道，还是 CMYK 等其他模式；色彩配置说明通道数字应当怎样理解；校准与观看环境涉及你用什么设备、在什么条件下判断结果。通过一项，并不等于通过另外两项。文件可以确实是 RGB，却缺少配置，或者带着错误配置；它也可以配置正确，却被放到特性不明的显示器上查看。把这些层次分开，才不会用改文件的办法去补偿显示环境的问题。

更广的色域，表示能描述的颜色范围更大，并不是一个画质等级。Display P3 能表示部分超出 sRGB 的颜色；换一个配置标签，却不会创造更好的光线、恢复已经丢失的高光，或修正不准确的商品颜色。W3C：预定义 RGB 色彩空间

指定改变含义，转换改变数字

想象一张纸上写着距离“12”。只更换单位，数字没变，含义却变了；真正换算单位，则需要改变数字，保留原来的距离。色彩处理更复杂，但这个区别有助于理解。

指定配置文件（Assign），是告诉软件用哪份说明来理解现有数值。它适合处理你确实知道原始编码、但没有标签的文件，或纠正已经确认写错的标签。不要把它当成饱和度滑杆。

转换配置文件（Convert），是计算目标色彩空间需要的数值，尽量保留原来的观感。它需要先有可信的源解释。目标色域容纳不下的颜色，以及有限的数值精度，都可能让完全一致变得不可能。Adobe 的文档配置说明也明确区分了这两种操作。

来看一个可以下载检查的练习。生成的原图没有嵌入 ICC 配置。我们明确选择 sRGB 作为本练习的起始解释，将它缩小一次到 768 × 512，再制作了三份文件：

坐标从左上角的零开始计数。指定 P3 的文件逐字节保留了起始文件中压缩的像素数据块，只替换嵌入的配置。转换 P3 的文件则真正经过 ICC 色彩管理计算。数值发生变化是预期结果，不等于画面遭到破坏。

下载 sRGB 起始文件、指定 P3 的文件和转换 P3 的文件。文件记录列出了尺寸、哈希、采样坐标和处理过程。用能够显示嵌入配置的编辑器分别打开，保留文件名以便对照。忽略配置的预览工具可能把前两份显示得相似，这并不代表两者具有相同的色彩含义。

先读文件证据，再判断预览

把三个下载文件作为独立文档打开，不要为了比较，先粘进同一个工作文档：粘贴过程可能引入另一次转换。先读配置名称，再以相同缩放倍率观察碗、布料和叶片。指定版本应显示为 P3，但它保存的 RGB 数值与 sRGB 文件相同；转换版本也带 P3 配置，数值却不同。只看最终配置名称，无法知道文件之前经历的是哪一种操作。

如果想获得可以复核的数字，下载文件检查脚本。它读取配置和文件中保存的 RGB，不先把采样点转换成显示颜色。在一份独立的本地文件夹中，放入脚本和三份 PNG；电脑具备 Node.js 后，依次运行：

npm init -y
npm install sharp@0.35.5
node inspect-color.mjs still-life-srgb.png still-life-assigned-p3.png still-life-converted-p3.png

脚本不是必需条件；能够报告文档配置和原始采样值的编辑器，也能完成同一检查。输出包含尺寸、是否存在配置的标志、配置哈希，以及原始像素哈希。hasProfile: true 只说明找到了配置，不说明它一定适合这张图。没有找到配置，也不意味着文件损坏或没有颜色。Sharp：图像元数据字段

对照本例文件，你会得到两组很有意义的关系：起始版与指定版的原始像素哈希相同，配置哈希不同；指定版与转换版的配置哈希相同，原始像素哈希不同。这比“左图看着更艳”更能解释发生了什么，因为它不依赖你此刻的屏幕把红色显示得有多浓。

哈希在这里是比较同一类数据的工具，不是画质评分。比较原始像素哈希时，先确认两张图的尺寸、通道顺序和读取方式相同；直接比较整份 PNG 的文件哈希，只能发现文件有变化，不能指出变化发生在配置还是画面。我们的脚本把配置与像素分开列出，正是为了避免把两件事混为一谈。

再看采样点的数字：红通道 141 − 154 = −13，绿通道增加 12，蓝通道增加 17。这是编码值的变化，不是实测“红色减少了多少”，也不是画质损失百分比。本例每个 8 位通道有 256 个整数取值；转换不必保留某个通道的数值，也不要求全图所有像素都按同一幅度改变。把这些差值当作饱和度滑杆的刻度，会再次混淆数值与解释。

现在亲手做一遍：从 sRGB 起始版各复制一份。在支持色彩配置的编辑器里，把第一份转换到 Display P3，并保留目标配置；对第二份执行指定 Display P3。分别保存，再检查它们的配置和样本值，而不只是预览是否“差不多”。不同色彩引擎或转换设置可能带来略有不同的整数结果，表中的精确数值属于我们记录的这组文件与设置，不是所有软件必须得到的唯一答案。

不靠猜测准备网页副本

面向常规网页交付，sRGB 是实用的默认选择。Adobe 的在线显示指南介绍了转换到 sRGB 的流程。如果双方已经约定并验证了广色域工作流，目标也可以不同。

从原始导出开始，保留编辑母版。在支持色彩管理的编辑器中查看文件的嵌入配置，不要凭文件名、截图或“在我手机上挺好看”来判断。没有标签时，先查来源工具的导出说明，或询问创作者。逐个尝试配置直到选中一个讨喜的效果，是一次创作调整，不是找回已知的原始编码。

源配置明确、目标是 sRGB 时，对副本进行转换。在 Photoshop 的官方桌面流程中，对应 Edit → Convert to Profile（编辑 → 转换为配置文件），目标选择 sRGB。提交前预览饱和颜色和柔和渐变。这是 Adobe 文档里的菜单路径，不是我们声称在 LocalBanana 中观察到的控件。

选择合适的格式并保留色彩配置，导出后重新打开文件，再检查它的配置。工作文档设置正确，不代表最终编码器一定保留了标签。如果还要经过其他图片处理服务，也要检查服务输出的实际文件。

根据你已知的事实，选择修复动作

第一种情况，文件没有配置，但来源已经确认是 sRGB。先用 sRGB 解释它；如果交付目标也是 sRGB，就没有必要先改成 P3，再转换回来。多一次转换不会自动增加可信度。

第二种情况，文件正确标记为 P3，网站明确要求 sRGB。对副本转换到 sRGB，然后检查输出文件。你是在换一种编码方式保留已有观感，不是在给图像“补上更高级的颜色”。

第三种情况，已经确认像素本来按 sRGB 编码，却被误标为 P3。先纠正源解释，再做后续交付转换。为什么不能直接转换到 sRGB？因为转换器会相信错误的 P3 说明，并把它当作起点计算。它可能输出一份格式合法、配置也写着 sRGB 的文件，但里面描述的已经是错误颜色。

最后一种情况，来源暂时无法确认。保留原件，向提供者索要认可的参考或导出要求。双方也可以明确约定一种新解释，但要记录这是编辑决定。产品目录尤其需要这条界限：你觉得舒服的绿色，并不一定是客户认可的釉色。反复试配置、调饱和度、再转换，并不能替代缺失的来源事实。

找出颜色在哪一步变了

每次只检查一个文件，尽量保持观看环境稳定。目的是定位变化，而不是宣布某台设备能代表所有人的屏幕。

校准，是把显示器调整到选定条件；建立显示器配置，是描述它的表现。给图像嵌入一个配置文件，不会完成这两件事。对颜色有严格要求时，应使用适合的实测显示流程，而不是凭眼睛替每次导出补偿。Adobe：校准显示器并建立配置

截图还会经过自己的截取与显示流程，因此不能可靠地告诉你原文件使用了什么配置。请别人排查色差时，保留并提供原始附件。

用一份可验收的交付结束练习

回到网站需求，交付件应包括选定的 sRGB 图片，以及一条短说明：像素尺寸、配置、使用哪份源文件、是否做过转换。母版继续留在工作目录里。收件人不该靠一个带“P3”的文件名猜测：这到底是内嵌配置，还是某个人原本想这样导出。

先在同一个受管理的编辑器里重新打开最终文件，与认可的起始观感比较；再放进实际接收端检查。如果平台会生成处理后的图片，下载那份真正被提供给读者的文件，另做一次检查。排查期间同时保留上传版和下载版。整文件哈希不同，只能证明文件改变过；到底改的是像素、配置，还是其他元数据，需要进一步分开看。

验收不必写成很长的报告，但要能回答具体问题：尺寸是否仍为 768 × 512？导出后是否仍带预期配置？杯子、碗和布料有没有出现未经认可的色彩改变？你检查的是完整下载文件，还是聊天软件重新生成的预览？每一项都对应实际证据，比一句“颜色正常”更容易在下一次交接中复核。

用下面三个小问题检验自己是否真正掌握了区别。先独立作答，再读答案；不需要凭肉眼猜哪张更准确。

1. 两份文件的 RGB 样本相同、配置不同，颜色就一定相同吗？ 不一定。配置改变的是解释方式。本例起始版与指定版就是这种情况；把它们的数字逐个抄成相同，也不能消除解释差异。
2. 转换版的数字变了，是否应该把原数字填回去，恢复“准确”？ 不应该。那会撤销部分转换结果，却没有恢复完整的原解释。判断应当围绕源配置、目标配置和认可的观感，而不是追求数字始终不变。
3. 无标签文件在一个应用里看起来正常，够不够证明源空间？ 不够。你看到了该应用的显示结果，并没有找回缺失的说明。下一步是检查来源，或者把新假设明确记录下来，而不是把猜测改成事实。

完成练习的标准，是能说清起始解释、实际操作和最终内嵌配置这三件事。它不要求你保证全世界屏幕都一致。如果某一项仍不确定，就把不确定性留在交接说明里，不用另一次饱和度调整把它掩盖过去。

对 LocalBanana 生成的图，也从下载文件和交付要求开始。这篇文章没有为所有生成下载宣称统一的配置，也没有假设产品里存在导出配置开关。接下来若要减小上传体积，可以看图片压缩指南，把色彩处理和像素、编码的取舍分开。准备印刷时，则应在确认成品尺寸与出血的同时，取得印厂要求的色彩流程。