上周帮朋友看一批电商图。40 多张产品图，PS 里调完导出，传到店铺后台，再从手机端打开——包装盒那个亮橘红，变成了发闷的砖红。
他第一反应是自己调色出了问题，重做了三遍曲线，越调越偏，最后差点把 psd 覆盖掉。我让他停手，把 PS 里的图和手机截图放在同一块屏幕上并排看。不是比颜色，是比“到底哪个环节开始变”。
结论很简单：他“存储为”的时候色域选了 Adobe RGB，而那个后台会重新编码一遍图片，顺手把 ICC 描述文件丢了。浏览器拿不到色彩描述，就默认按 sRGB 去解释一份本来是 Adobe RGB 的数据。颜色当然闷。
这事让我改了个老说法。以前我总跟人说“图片处理就三步：调色、尺寸、导出”，现在我觉得应该反过来讲：大部分人的图片问题根本不在调色，在搬运。你调得再准，只要在导出和传输这两个环节丢一次信息，前面全白干。
第一个坑：色域不是越宽越好
先说个大概的量级，我记得不一定准：sRGB 大概能覆盖 CIE 1931 色度图的三成多，Adobe RGB 能到五成左右，Display P3 比 sRGB 宽大约四分之一。重点是——色域宽不意味着好看，它只意味着“能表示的颜色更多”。一旦接收端不认识这个色域，多出来的部分不是被压缩，是被误解。P3 里的纯红，扔进 sRGB 环境解释，要么变得更闷，要么直接被切掉，边缘还会出现断层。
所以判断标准我总结成一个很土的问题：这张图最后是被谁看的？
- 电商后台、公众号、朋友圈、绝大多数网页：老老实实 sRGB。
- 只发给 iPhone 用户、走 macOS 生态、做 App 素材：可以上 Display P3。
- 要印刷：Adobe RGB 或 CMYK，但那是另一套逻辑，印刷的色彩管理我到现在也只懂个皮毛。
这里有个特别容易搞混的地方。PS 里有两个动作长得像，作用完全相反：编辑 > 转换为配置文件 是真的把像素数值换算过去；而“存储为”对话框底部的那个颜色配置，只是往文件头贴个标签，像素一个没动。很多人以为勾上“嵌入颜色配置文件”就等于转换了，不是的。顺序也不能错：先转配置文件，再存。
顺带一提，PS 的“存储为”JPEG 品质滑块是 0 到 12，默认 8；而“导出为”那套是 0 到 7，默认 7，还默认勾选“转换为 sRGB”。同一个软件两套导出，参数口径都不一样，这本身就够坑的。
第二个坑：DPI 基本是个安慰剂
72 DPI 和 300 DPI，在屏幕上没有任何区别。
因为 DPI 只是写在文件头里的一段元数据，它告诉打印机“一英寸塞多少个像素”，它对显示器什么都没说。显示器只认像素总数。一张 4000×4000 的图，标 72 还是标 300，你在手机上看，一模一样。
但这个东西确实会误事。有次我给一个平台传图，对方要求“300 DPI 以上”，我传了一张 4000×4000、72 DPI 的，被退回；把 DPI 改成 300、像素一个没动，通过。就这么荒诞。
所以正确的顺序是：先按像素定尺寸，等真的要交付打印排版了，再回头补 DPI。做电商主图常见的规格是长边 800 或 1000 像素起，详情页那套老规格是宽度 750 或 790 像素，各家后台都不太一样，以对方文档为准，别信我。
第三个坑：重采样和锐化，比压缩质量更影响观感
缩图用的算法不同，结果差得挺明显。PS 的“图像大小”里，缩小照片优先试试“两次立方（较锐利）”，也就是 Bicubic Sharper；放大就别用锐利那个了，会放大噪点，老实选两次立方。Lanczos 在 ImageMagick 和很多开源工具里是默认，边缘更干净，但也更容易在细密纹理上出振铃，比如毛衣、草地、建筑上的细格栅。
缩完记得补一点锐化，但别多。我常用的起点是：USM 半径 0.8 像素、数量 80%、阈值 0，然后拿 100% 视图盯着看。半径超过 1.5 像素基本就出白边了。
还有一个很少人注意的参数：色度抽样。JPEG 的 4:2:0 会让每 2×2 个像素共用一组色度信息，也就是色度分辨率只剩四分之一。人眼对亮度敏感、对色度迟钝，所以大部分照片看不出问题；但如果你图里有红色小字、彩色细线、或者纯色 logo 边缘，4:2:0 会让它糊成一团，甚至边缘泛出杂色。这种图改成 4:4:4，文件大一点，但值。
批量处理：三条命令，别顺序写错
几十张图手动导，出错概率比你想的高。命令行或者批处理工具更稳。ImageMagick 我用了好几年，最常用的就这一条：
magick mogrify -path ./out -resize "1600x1600>" -profile sRGB.icc -strip -quality 84 -sampling-factor 4:2:0 *.jpg几个参数得说清楚。1600x1600> 里那个大于号是“只缩不放”，尺寸比它小的图原样保留。-quality 84 是我想推的一个甜点区，一般 80 到 88 之间，再往上文件涨得比画质快得多。-strip 会把所有元数据清掉，包括 ICC，所以转色彩空间那一步必须写在它前面，顺序反了就等于白干。
还有，-colorspace sRGB 和 -profile sRGB.icc 不是一回事。前者改的是通道运算方式，后者才是基于 ICC 的真实转换。要准就用后者。
Windows 的 cmd 里 > 是重定向符号，直接写会报错，得加引号或者写成 ^>。我第一次踩这个坑的时候盯着报错看了二十分钟。
不想碰命令行的，XnConvert 和 FastStone Photo Resizer 都能批量做这件事，XnConvert 支持挂 ICC 转换，界面也还算清楚。再往工程方向走，Node 里用 sharp，底层是 libvips，比用 GraphicsMagick 快不少，尤其是几百张往上的时候。网页端现在一般先出 WebP 兜底，再考虑 AVIF，同质量下 WebP 通常比 JPEG 小四分之一到三分之一，AVIF 还能再省一截，但编码慢，兼容性也得自己测。
最后
别把图片处理当纯审美课来学。审美当然重要，但它排在后面。先把色彩空间、像素尺寸、重采样、压缩这四件事的因果关系理顺，你会发现你原来觉得“我调色不行”的那些图，很多其实是搬运环节出的错。
写到这有点跑偏了，本来想聊聊网页 LCP 和 AVIF 的取舍，Google 那个 2.5 秒的阈值挺值得单开一篇，结果色域占了这么大篇幅。下次吧。