直到最近 gcm 都是使用 Graeme Gill 的 Argyll 色彩管理系统来实现和 ColorMunki， Colorvision Spyder 之类测量设备的交流。接着您明显的开始做原生的驱动了，也对 Argyll 打补丁以便满足需求。Argyll 的问题在哪里，当前它是怎么工作的，将来有什么计划吗？ 好多问题！给那些非色彩 Geeks 解释下，Argyll 是一组从色彩传感器获取数据、处理制表直至生成一个完整的色彩特性文件的程序。对于这些， Argyll 非常棒，胜过所有其它我们现有的工具。不幸的是，Argyll 有几个缺点：它被设计成许多在交互式控制台中运行的小程序，要求用户必须了解其中发生的所有事情。 这和 GCM，colord 的 “Just Works” 哲学不吻合，因此我们不得对与 Argyll 进行交互的部分做些改进。对于 3.0 和 3.2而言，是通过一个 VTE 部件来运行Argyll，然后通过屏幕截图抓取输出结果。这个方式不是很好。我请求Graeme（Argyll作者）做个终端那样的选项，他在最新的版本中弄好了。不幸的是我没法在 Fedora 中搭载最新的版本（因为需要一个修改过的内置的 libusb1 的版本，它在等待 libusb1 项目上游通过），我们还是要用不太理想的抓屏方式。
将来依然会在特性文件创建过程中使用 Argyll，没有人比 Graeme 更了解如何创建漂亮的特性文件。我想剥离出来的是的设备锁定和测量，这是我正在给 colord 添加的东西。现在已经有了原生的 Huey 硬件驱动，Colorunki 的驱动也已经完成了一半。 这样子我们就可以在屏幕上获取色样，还能实现一些常规化操作，比如取消校准，以及指示完成进度的进度条。colord 用来完成那些耗时较长的工作，之后把结果输入到 Argyll 里的某个工具中生成特性文件。通过这种方式，我们既可以收益于由 Graeme 维护并检测过的算法，又可以实现由 colord 带来的硬件异步。 在进行 colord 处理硬件方面的研究时，发现我们忽略了一个在 Glib 中实现“ USB 异步可取消传输”的简便的方法，于是我又发起了一个 GUsb 项目。我希望它能很快公开发布，并在 colord 中采用。GUsb 也被用在其他项目中了，比如 SPICE。 最近在 GNOME 开发者的列表里，有个话题是有关全屏色彩管理（FSCM）的。您能解释解释 FSCM 对最终用户意味着什么吗？ 对自由桌面的色彩管理而言，下一步很自然的需要实现的全屏色彩管理，就像现在 OSX 上实现的那样。我们也已经有一种的全屏效果，是在会话启动时将 ICC 特性文件里的 VCGT（视频卡色域表，在校准时产生的）发送到 X Server 。Windows 和 OSX 很就以前就这样加载线性校准状态了，而且允许你做更准确的硬件校准。比如可以把 Tinkpad LCD 屏幕调得没那么“蓝”，是个相当有用的功能。 可是，从某种角度来说，VCGT 也只是起到辅助作用而已，它只能通过单独对红、绿和蓝通道作重映射的方式进行屏幕校准。这会限制您去作些更巧妙的事情，比如互相切换绿和蓝通道等尽管看起来像小把戏，但对于进行模拟某些色盲却非常有用的操作。而且明显的是，它也没有在源特性文件和目标特性文件之间做任何的色域映射。 全屏色彩管理的真正用途是自动化的完成从一个特性文件到另一个特性文件的色彩映射过程。实际应用中，我们可以自动的把色彩从一个已知的色彩空间转换到显示器的色彩空间中去。常见的比如文档编辑器、工具集按钮、窗体边框等全都假设是在 sRGB 空间里的，它们没有特别的标识。但是有些应用程序比如 Firefox ，它有可能正在显示来自 Flickr 的图片，而该图片可能内嵌了指明获取设备的色彩空间的特性文件。
当下，那些没有被标识的内容是不经过任何色彩管理就被传输到显示器上的，这就是为何人们对宽色域的 LED 感到头痛的原因。了解色彩管理的应用程序像 GIMP（还有 Firefox，如果您不怕麻烦把它设好）会借助特性文件，通过类似 lcms2 的程序库在 CPU上把源色彩转换为目标显示器的色彩。 这样的过程可以保证图像本身在屏幕上的正确显示，但意味着每个像素都要经过 CPU 的处理，若是几 MB 的文件就会消耗不少时间。 那么我们怎么做？我们想对要同时上传到显示屏幕上的众多图像做大规模的并行操作。幸好现在大多数机器都具备专为此项功能设计 GPU 。告诉 GPU 对一张放在在显存中 50MB RGBA 的二维纹理中的每个像素按照 16x16x16 的矩阵做三线插值，它完成的速度比把图像加载到系统 RAM 中还要快。 这样操作并不是一个新的观念，几年前 Kai-Uwe 已经用 Oyranos Compiz 插件演示过，还有最近 Gabriel Ebner 在 compiz-cms 项目上所做的。后者甚至是用 colord 来获得正确的特性文件的。因此，对于 Compiz 用户已经现成的解决方案，前提是能告诉所有应用程序使用 sRGB 空间进行渲染。
GNOME 3 用的是 Mutter 混合管理器，不像在我们在 Compiz 上的一个完整窗口中处理 Assembly Shader 那么简单，我们必须使用 Clutter 和 cogl 来实现正确的渲染和透明度。这也增加了在定义输入选择和输出选择区域时的复杂度。比如像 Blender 之类程序想完整控制窗口的程序，并不想让混成器去处理颜色；或者 Firefox，它已经用 CPU 完成了转换，我们不想再做“多余”的图像色彩矫正。我还在和 Mutter 和 X 的开发者讨论，看在 GNOME 3.4 中这个要怎么处理才是最稳妥的。目前看来 Mutter， Gtk+，cogl 甚至其他一些应用程序都要做些改动。 我考虑过使用 Kai-Uwe 的 net-color 规范，但我觉得规范里很多是错的，像加入网络透明这样的东西，这会给我们带来大量我们并不想要支持的问题。我还想把 FSCM 中输入选择或输出选择控件 （和窗口）做的超级容易。可是，除非手动定义对于现代工具集中移动、尺寸改变和形状改变支持不佳的输出选择区域，否则 net-color 规范并没有让事情变得容易。清楚的是，无论要怎么做，我们都要尽量减少对额外依赖造成的影响，还有 UI 延迟，电力消耗也必须考虑的。此刻，各种不同的的想法都是有可能的。 我知道在读者只是想要个简短的答案，但是我无法潦潦几句就把这问题说全。在 GNOME 3.4 之后，我确信会有个专门的 FSCM 文章来详细描述其体系结构。 |
