正常情况，应该是在target前面有个如下图所示的符号：
本帖最后由 tomding1968 于 2018-11-13 20:16 编辑

Chrome,现在的版本，出了个状况，
好像出了色域的地方给了溢出警告，
有谁知道，怎么把警告关了吗？ 本帖最后由 何不同 于 2018-11-13 17:47 编辑

正确的颜色管理可以使你看到的效果，以最接近的方式在对方的硬件环境再现。接近到什么程度取决于对方硬件设备的状况。一般地说，在正确的色彩管理下，你的aRGB图片，到一个普通的正常sRGB的显示器，基本上可以保持95%的效果，而不正确的色彩管理，或者无色彩管理效果可以说是变了质的，效果能剩下60-70%？双方都做了正确的颜色管理，还原度可以在99%以上甚至更高。这里给的数字是形象的说法，是个人主观感受。

本帖最后由 何不同 于 2018-11-13 16:02 编辑

很多年不用acdsee了。如果不支持色彩管理，没理由在广色域环境中使用的
本帖由IOS客户端发布

刚才回错了，看看下面几张，用你的图转到我的显示器的icc

能说说具体操作步骤吗？见下图，Native是我校色得到的。本来在这个名字前面有个符号的，表示配置生效。
被我Export Target后再Import target回来,那个符号就没了。这时候，原来校准好的icc，应该没用上吧？
这个事情有点烦。刚校色好的配置，因为重装os，必须再重新校色一次。

本帖最后由 tomding1968 于 2018-11-13 14:26 编辑

CG自带的校色仪就是蜘蛛，软件校色虽然丢色阶，但在一般8bit显示器上不会有明显问题，只在某些极端的画面下会显露出来。
但不影响后期编辑的完整性，只是看上去有点瑕疵。
但低端的硬件LUT校色（明基、呆鹅那种）就没啥意义，ΔE太高了，反而不如软件校色看上去准确舒服。
硬件校色目前也有问题需要解决，适合快速校色和超脱软件束缚的场合。
速度和精度毕竟是无法两全的，要想都能解决，请准备好你的钱包。

你也可以试一下不用硬件校色，用软件校色来伺候CG，看看两种方案有什么不同。 本帖最后由 chncwk 于 2018-11-13 13:18 编辑

哦，你的是硬件校色，难怪与我的不一样。
一般软件校色是修改显卡的LUT表来实现色彩转换的，但缺点是必然损失灰阶和色阶层次（有断层）
硬件校色是跳过显卡，软件直接控制显示器的硬件LUT表来做色彩转换，优点是灰阶和色阶都不损，但色彩ΔE值比软件校色略差些（高端专业型号或许可以忽略不计，但整体趋势是这样）。
硬件校色优点是可以无视操作系统和软件的色彩管理短板，直接映射出正确的结果，不知道你用过后有无这种感受？ 本帖最后由 chncwk 于 2018-11-13 12:50 编辑

tomding1968 发表于 2016-8-23 19:44
感谢楼主答疑。
我是这样理解的：我在修图时，是依赖我自己电脑的显示器ICC进行的。因此，如果想要别人看到跟我修图时一样的效果，最好是嵌入我修图时用的显示器ICC，这样，别人才有可能看到跟我修图时一样的效果。

关于这个可能，我测试过。win7的图片查看器，不仅能管理图片内嵌入的ICC，还能同时管理显示器的ICC。现在很多看图软件，都能查看图片内嵌入的ICC，但能同时管理显示器ICC的不多。IE内核就不能管理显示器ICC，但从IE9开始，就能管理嵌入的ICC了。因此，直接嵌入我修图时显示器的ICC，应该比较理想。

我理解色彩管理的一个基础想法，是在图片流转的任何环节，只要有合理的色彩管理，色彩的准确再现，就是可行的。我传递出去的图片，应该包含我修图时看到的效果信息，即图片内各个像素的RGB信息（用词可能不当）和显示器ICC（应该理解为一个调校函数吧）。因此，我觉得应该嵌入修图时用的显示器ICC。总之，我企图传递出我最准确的修图效果信息。

我这样理解是否正确，请指正。

首先确定一点就是当你修图的时候， 在自己的显示器上如果想要看到相对准确的色彩，只能完全依赖校色和色彩管理。他人或下一个工作流程看图的时候，在他的显示器上如果想要看到相对准确的色彩，仍然只能完全依赖校色和色彩管理。

下面都是在这个前提下进行讨论。

以Photoshop为例，如果已经执行并部署了正确的校色，那么它在视口里对色彩的直接显示是不以图片实际嵌入的色彩配置为唯一依据的。这个表述可能不太准确因为情况相对复杂，下面举个例子说一下。

比如有一张图片，直接从相机得到，那么他通常会被从RAW渲染为标准色彩空间比如sRGB或Adobe RGB或ProPhoto RGB。

先假设以sRGB渲染导入Photoshop或从ACR直接生成新工程，然后经过初步的调整，得到了一个比较合适的调色结果。这时候PS和工程的工作状态如下：

1. 正确地执行校色后，PS充分了解到显示器特性，可以自行读取到系统加载的ICC中关于显示器色域特性以及白点座标的信息（此行为对用户完全透明）。

2. 工程自身携带的色彩空间配置为sRGB。所有像素的色彩座标未发生变化，所有像素的RGB值未发生变化。

3. PS在视口中自动将工程中每个像素的色彩座标（lab或xy值）向校色得到的显示器特性中的色域和白点进行映射（先不谈着色意图），得到RGB值（用户不可见，但保存于帧缓存中可以被截取分析）。然后通过GDI、WPF或OpenGL发送给显卡显示，显卡根据校色后得到的gamma表或曲线进行最终修正，发送给显示器。最后是显示器的内部处理，通常还有一个硬件LUT进行转换。最终得到修图者在显示器中看到相对正确的色彩。

接下来尝试改动以上工作状态中的配置或参数：

----------------------------- A 场景 ---------------------------

动作：从操作系统中移除已加载的校色，或加载一个错误的校色。

结果：

1. PS未能了解显示器性，将执行系统默认特性，有时为sRGB。但实际上大部分显示器在接入win7以后的操作系统时，都会自动下载或直接使用内置的对应的显示器描述，这些配置文件会根据显示器大致情况标定一个色域范围，白点大多数会定在D50。这种情况实际上和装载了错误的配置文件差不多，PS获得了错误的显示器特性。

2. 工程自身携带的色彩空间配置为sRGB。所有像素的色彩座标未发生变化，所有像素的RGB值未发生变化。

3. PS在视口中自动将工程中每个像素在sRGB下的色彩座标向错误的显示器特性中的色域和白点进行映射（或者向sRGB），得到错误的RGB值，然后通过GDI、WPF或OpenGL发送给显卡显示，显卡根据错误的gamma表或曲线进行最终修正，发送给显示器（如果没有校准曲线或CMS被接管将直接发送给显卡）。最后一步是显示器的内部处理，通常还有一个硬件LUT进行转换。最终修图者在显示器中看到错误的色彩。

----------------------------- B 场景 ---------------------------

动作：变更工程的配置文件，从sRGB 变更为  显示器校准配置，仅变更，不执行色彩转换。

结果：

1. 正确地执行校色后，PS充分了解到显示器特性，可以自行读取到系统加载的ICC中关于显示器色域特性以及白点座标的信息。

2. 工程自身携带的色彩空间配置变更为 显示器校准配置，不执行色彩转换。所有像素的RGB值保持不变，几乎所有像素的Lab或xy座标都发生了变化。

3. PS在视口中自动将工程中每个像素在 显示器配置文件下的错误的色彩座标向校色得到的显示器特性中的色域和白点进行映射，得到错误的RGB值。如果不考虑着色意图、黑位压缩以及运算精度等等因素的话，显然这是个多余的动作，帧缓冲中的RGB值和工程中像素实际的RGB值差异不大。然后通过GDI、WPF或OpenGL发送给显卡显示，显卡根据校色后得到的gamma表或曲线进行最终修正，发送给显示器。最后是显示器的内部处理，通常还有一个硬件LUT进行转换。最终得到修图者在显示器中看到错误的色彩。

----------------------------- C 场景 ---------------------------

动作：变更工程的配置文件，从sRGB 变更为  显示器校准配置，并执行色彩转换。

结果：

1. 正确地执行校色后，PS充分了解到显示器特性，可以自行读取到系统加载的ICC中关于显示器色域特性以及白点座标的信息。

2. 工程自身携带的色彩空间配置变更为 显示器校准配置，并执行色彩转换。大部分像素lab或xy座标都发生了微小变化（暂不考虑转换意图及目标需求，仅举例），几乎所有像素的RGB值都发生了变化。

3. PS在视口中自动将工程中每个像素在 显示器配置文件下的 （相对正确的）色彩座标向校色得到的显示器特性中的色域和白点进行映射得到RGB值。然后通过GDI、WPF或OpenGL发送给显卡显示，显卡根据校色后得到的gamma表或曲线进行最终修正，发送给显示器。最后是显示器的内部处理，通常还有一个硬件LUT进行转换。最终得到修图者在显示器中看到相对正确的色彩。

--------------------------------------------------------------------

那么我们向下一工作流传递时，如果要求保持相对准确的色彩，就可以有两个选择，一是保持例子中的原状态不变，二是执行C场景的动作。

鉴于我们把这个讨论建立在正确校色的框架之下，那么其实情况就大大简单化了，目标就是要维持所有像素相对准确的色彩座标（Lab或xy值）基本不变，就可以另下一流程在已校准的显示器上相对准确地还原色彩。

但是色彩座标的保持目前还是个难题，因为常用的图像格式并不直接存储色彩的绝对座标，大多数情况下，只能结合像素的RGB值和正确的配置文件两者，才能得到色彩相对准确的绝对座标。

这并不是个容易的事情。

执行场景C的话可能会遇到以下问题：

如果下一流程无法解析配置文件怎么办？ 如果传递过程中配置文件丢失了怎么办？丢失了，是否可以单独传送一份配置文件给下一流程？现在传送的配置文件是否是工程当年所使用的显示器特性？如何语义化及约定这些配置？这些都是困难。

相对的，如果保持原状态，那么就轻松很多，甚至无需真的携带配置文件。甚至我只要在文件名里加上“_sRGB”、“_aRGB”这些文字，下一工作流就可以自行添加配置文件，同样可以得到相对准确的色彩。

某些特定的应用场景下，也许必须采用场景C中的方法。比如我的显示器红色方向的纯度特别高，甚至超出Adobe RGB不少（GB-LED广色域上很容易实现），而我又恰好需要在这超出的纯度范围内在直接监视的情况下进行阶调控制，那么直接使用ProPhoto RGB确实不太合理，因为其他方向上的阶调控制粒度被增大，性能被减弱了（90%可用变成40%可用，大概这样，仅是举例）。那么就可以利用场景C的方法，也是非常合理的。

然后也许可以比较容易地理解为何广色域显示器使用起来如此麻烦，以及几乎正好是sRGB的显示器使用起来为何比较简单。

本帖最后由 dual 于 2016-8-24 18:00 编辑

-------------------------------------------------------------

https://forum.xitek.com/forum.php?mod=viewthread&tid=1141746&page=7&ordertype=1#pid67940046

所以，基本上私人icc大部分情况下是可行的，有些个别例子会有问题。。。
我的显示器硬件校色仪比较老旧，反而兼容性高，所以到处都没出问题。专用的spider比较高级，做的icc反而可能有曲高和寡的问题

你的icc好像有东西Chrome 不认。
我之前是在多台显示器上试了windows photo viewer 和ps, 以及IE（sRGB下）但是没试Chrome.
Chrome下确实有问题，既然广色域下，FF, ps, windows photo viewer 都OK，不知是不是Chrome的bug。
个人认为是Chrome的软件与你的icc有冲突。需要ps内转一下，可能你的icc比较新潮，有新的版本新格式之类。

P3好像早就有，跟sRGB接近，不会取代aRGB的，是为显示而不是打印倒是也许逐步替代sRGB,也许。

现实是， 我们可以一直坚持为sRGB设备的用户准备作品，即便是到了没有完善色彩管理的P3设备上，表达也不会有大的偏差

相反，以P3为目标准备作品，到了sRGB设备上，也会“自动”尽sRGB所能进行表现

还是很好的

应该是可以不用再专门考虑Adobe RGB了

没必要追求那个v4版吧，有什么用？如果不过多折腾显示器的icc, 基本不会碰到，也少了好多麻烦。
做icc时，搞太新版本，都没人用的，那确实可能没法发给别人。。。。 本帖最后由 何不同 于 2018-11-13 00:56 编辑

70.0.3538.77，
那个截屏上有，有趣的是edge 也被认为是Chrome 只是版本老了。