在 GNOME 3.2 即将到来之际，Libre Graphic World 的朋友对 GNOME Color Manager 及 colord 的作者 Richard Hughes 进行了专访。
过去， 只有不怕死的折腾鬼才敢做 Linux 下的色彩管理。在两年前，Richard Hughes 领导下的 GNOME Color Manager 项目，借助 Argyll 色彩管理系统的帮助，一劳永逸的改变了这个状态，现在普通用户也能完成色彩管理工作了。在离 GNOME 3.2 临近之时，我们决定打扰下 Richard，直截了当地询问一些色彩管理方面的问题。
Richard，您是红帽的全职员工。有 Linux 发行商来支持您所喜爱的工作是否很有帮助呢？ 会有帮助，但这并不是根本的。红帽是众多超酷的开源公司之一，只要和他们要您做的事情多少拉得上点关系的，它就会允许您去尝试。对 Linux 桌面，我一直关注那些用户想要的功能，看能不能找出“缺漏”的地方，并尝试把它们填补上。有可能是给已有的项目写点代码，也有可能是创建全新的框架。我喜欢这个。 对于专业的设计师，印前工程师和摄影师而言，掌握色彩管理都是必须的，所以不必向他们多解释。但是对于那些还在犹豫着是否花一百美元左右买个 Pantone Huey 仪器（这还是当今最便宜的）的人，GNOME Color Manager 是如何让他们明白这笔开销是物有所值的？ 噢，有两个方法： 让他们去找那些有色彩矫正设备的人，拜托抽空帮忙校准下他们的屏幕。在很多会议上我都会这样 ：找个设计师，帮他把校准下屏幕，然后就会看到他张大嘴巴那副吃惊的样子：原来之前创作的作品都是有色彩问题的。
另外，当用户看到新的色彩控制中心面板时，很容易就会注意到一个 “了解更多...” 的按钮，它会引导用户来到一个大型帮助文件，里面有诸如 “为何校准是重要的”，“支持校准设备有哪些”，甚至一些简单的诸如 “什么是一个色彩特性文件” 的主题。它既能让新用户明白色彩管理是重要的，又能告诉有一定基础的用户如何检测自己的流程并保证色彩是准确的。 GNOME Color Manager 从 2.30 起便内置到 GNOME 里面了，很多人因此对它或多或少有些了解，知道它可以用来创建诸如显示器和打印机这些设备的 ICC 特性文件，从而以保证色彩还原的一致性。但是 colord 却是个新东西，请您简单说说，colord 是什么，为什么 GNOME Color Manager 会需要它呢？ GNOME Color Manager（缩写为 g-c-m）的确是在 GNOME 2.30 时加入的，之后在 2.32 和 3.0 之间经历了一个快速的发展周期。在这段时间里，g-c-m 从一系列相对独立的程序变成一个设计上有些仓促的框架，供其它程序使用。但是下面几个原因，导致它难以被接受：
下来要做的事情就很明显了：拆分 GNOME Color Manager 的框架部分，使它变成一个简单的系统级别的部件，这样能被系统上下文中的其他部分所用；再将 g-c-m 精简为一个用来配置和应用 colord 策略的会话前端。这样也会简化在 KDE 或者 LXDE 环境下与 colord 交互前端的开发工作。
如果觉得这个听着耳熟，没错，这的确很像 PackageKit 和 UPower。不要惊讶，因为我也在维护这些上游项目。 在 GNOME 3.2 中， GNOME Color Manager 将第一次全面使用 colord 以及彻底修改后的打印堆栈。这对最终用户到底意味着什么？ 嗯，这意味着我们不仅完成所有的基础设计和构建，并且还实现了默认安装，这点非常重要。Colord 是 GNOME 3.2 的一个强制依赖，它是被包含在发行版的 LiveCD 里的。这是说它“Just Works”，不用再安装任何软件包，也无需做任何配置。显示设备会通过 gnome-settings-daemon 在 colord 中进行自动注册，打印设备则会通过 CUPS 注册到 colord 中去。 史上首次，用户可以简单的告诉系统 “在这个设备用这个特性文件”，工作就会魔术般自动完成。这意味着我们在针对一个打印机生成特性文件（或者下载供应商提供的特性文件）之后，就可以保证打印出来的东西没有色彩问题。为了达成这个目的，我们要修改很多底层的东西（CUPS，Ghostscript，foomatic 和 Gtk+），但这对用户而言这就是 "Just Works”。他们再也不用学习如何编写 XML 文件或者挑选策略文件。 在做 colord 的时候，您对第三方的工具打了很多补丁，所以我猜您对全局会有个了解。您对当前 Linux 上的数码图像和打印堆栈有什么看法？它们还跟得上时代吗？用在专业的环境里可靠吗？需要做些大的更改吗？ CUPS 和 Ghostscript 是两个存在了很长时间的项目，它们有稳定的 API。稳定意味着它们已经用了很长一段时间了，当然对我而言，若是有新的 GLib 和 DBus 绑定会让我的工作轻松许多。Linux 上的打印堆栈是非常错综复杂的，希望将来在流程中剔除 PS 而迁移到 PDF 之后事情会变得简单一些。对专业使用者来说，最重要的事情是稳定，有文档。 在处理和设备关系时与 SANE 项目打交道是个令人比较沮丧的过程。SANE 是个古老的程序库，您可以请求它做类似列出已连接的扫描仪，扫描图像之类的工作。主库 libsane 调用按设备制造商划分的 “后端”。后端的质量非常的参差不齐。有些后端，比如惠普的，没什么问题，但有一些却不时的崩溃。就算可以安装私有的后端也没什么改善，而且这些私有后端的质量甚至更令人担忧。因为 colord 的过程中需要使用到 libsane ，上面这些情况会造成守护程序的崩溃。我估计通过 Fedora 提交到 colord 的 bug 中，90% 将是 sane 后端引起的。这也是为何我们在 colord.conf 配置文件设了 EnableSane=false 选项的原因。长远考虑，我希望把大多数的设备探测的工作都移入 udev 中去，就像其他子系统做的那样，但是如果没有得到来自 SANE 社区的支持，这很难实现。
在设计 colord 时，我试着故意忽略了 flipping pixel values。Colord 是个非常高阶的守护进程，它可以对类似 Krita 或 GIMP 程序说 “这个设备用这个特性文件”，而不是为它们提供140MB 的内存缓冲和操作列表。这意味着对某些程序，我们可以在 CPU 上用 lcms2 做转换，而对其他使用了 3D 的就在 GPU 上用 Shader 做转换。选择不封装 lcms ，使得我们留给应用程序去决定在某个恰当的层用恰当的方法做像素转换。 这样的缺点是不得不给应用程序打补丁让它们做出正确的决定。我们可以很容易的对 Clutter 和 Cairo 做一些框架上的修改实现这个目的。但是迟早应用程序都必须要在某种程度上涉及色彩管理。上面这些是我准备在 GNOME 3.4 期间关注的主要方面；现在所有的框架都安装并运行着，我们可以对应用程序作者说 “已经默认安装好了，不用担心额外的依赖，接受我的补丁就可以了”。 说到打印，在打印全彩的图像时，得到正确输出的唯一途径是要针对打印机，油墨和纸张三者的特定组合创建特性文件。即使是在一个固定的流程中也会有多个 ICC 特性文件存在的情形。目前能支持吗？ 我想多数人的打印机都是只有一个特性文件的，但是我同意支持一个设备对应多个特性文件合乎逻辑的。实际上照相机也有同样的问题，您可能既要 “工作室里照明下的特性文件”， 有要 “户外阳光下的特性文件” Colord 事实上和 OSX 的 ColorSync 一样，当应用程序（本例中是 CUPS）为设备请求色彩描述文件时，它其实是依据限定条件来请求描述文件的。通常，按下“文件->打印”之后 CUPS 以 600dpi 的分辨率，用彩墨打印到一个普通纸上。CUPS 是对 colord 请求的是一个“RGB.Plain.600dpi”限定语的特性文件。如果要打印在光面纸上（光面纸有个范围更广的色域，可以打印更多的色彩）时，您的确需要一个不同的特性文件。这需要您使用光面纸重新校准打印机，得到一个不同的特性文件。于是当在打印对话框中选择“光面纸”选项进行光面纸打印时，CUPS 就会请求 “RGB.Glossy.600dpi”，colord 返回一个正确的特性文件。当然如果您没有光面的特性文件，那么它回退普通纸张的特性文件，因为这样比完全没有特性文件要好。 对那些不是通过 GCM 产生的特性文件，目前我们还没法标识“这是个彩墨，光面纸，1200dpi的特性文件”。当然，在用GCM内置校准工具产生的特性文件时是包含，该元数据的。如果您对 UI 上有任何主意和想法，请到 #gnome-design 和那些设计师们讨论，我会把它加到 GNOME 3.4 的。 现在有多少应用程序已知使用了 colord 的 D-Bus 接口，目前它稳定性么？ 我不确定有多少项目使用了colord，因为即使使用了他们也不是一定要通知的嘛。目前，据我所知的有 CUPS，GTK+，foomatic，simple-scan，compiz-cms，当然少不了 gnome-color-manager。Alex Fiestas 也有计划实现一个 KDE 前端。 colord 的公共 Dbus API 非常的稳定。我们只有去年发生过影响 API 的兼容性，并且那次的变动也只是影响了会话策略代理，对应用程序并没有影响。我们目标是保持 API 的稳定和和对它的支持，当我们觉得需要更多的功能时，再添加更多的属性和方法进去。我并不是说即使是要修复重大的bug，我们都不会打破 API。就目前而言，我看没有看到这样做的必要；colord 只是影响范围有限的简单后台守护程序。 直到最近 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 文章来详细描述其体系结构。 您有看过 Wayland 吗？它能提供一些和色彩管理相关的便利吗？ Wayland 是个很酷的项目，参与的都是非常聪明的家伙。但真的，Wayland 只是个混合器(compositor)和客户端之间的通信协议。对于 FSCM 而言，我们想要客户端和混成器所进行的沟通，和现有的协议，如已经上传到服务器的 ICCPROFILEINX 原子操作，是并不相关的。目前来说，Wayland 还不像某些疯狂的网站所说的那样可以“替换掉X Server”。但是在设计 FSCM 时，值得注意我们并不会永远都有可以用来存储一些随机数据的 X Server 。 所以，我觉得 Wayland 在色彩管理方面并没给我们带来什么，尽管它让所有的速度都变快了。 对于要让 95% 的用户开心和要满足其余 5% 的用户对弹性策略流程的要求好像一直就存在争议，在现阶段有没有让 colord 和 Oyranos 互相兼容的方法？ 我很想说“有"，但是我想基本上不可能既让事情“ Just Works” 而还能给予用户控制每个策略微妙差别的自由。我一向强调我们应该让 95% 的人完成他们想要的 99% 的事情，对于其余 5% 的用户，他们已经有自定的流程。在做过很多用户调查研究之后，发现大多数人都只是想让色彩管理来做恰当的事情，而不想被艰涩技术问题烦着。对于那些确实有需要的的人而言，他们知道如何编辑类似 colord.conf 配置文件，知道如何阅读 man页面了。
另外，我不觉的 colord 和 Oyranos 项目之间以后会有很多交叉，并不是意识形态的问题，而是这两个项目的交叉点非常少。Colord 的目标非常有限，那就是默认安装和让色彩管理变得 ”Just Works“。Oyranos 有非常宏大的目标，它包裹了很多其它的程序库，试图介入色彩流程的方方面面。和 colord 比较的话，它们像是两个垂直的坐标，这就是我选择开始一个新项目而不是尝试修补 Oyranos 的主要原因。 当初您开始 GNOME Color Manager 是源于兴趣，想解决两个显示器之间色彩输出不一致的问题。两年之后，有了一些基础性项目，colord 和 GUsb，还有对 CUPS 的补丁等等，您现在还觉得有兴趣吗？ 非常有趣。（任何色彩专家也会这样说）随着对色彩管理了解的越多，就会越觉得其实对色彩管理知道的很少！自从决定 colord 开始要和硬件直接交流后（为了大大提升校准时的用户体验），对于我这样的电子 Geek 来说它变得非常的底层及有趣。我也一直从 GNOME UI 设计师那里得到很多帮助，最明显的是在 GNOME 3.2 中，校准及偏好设定的 UI 变得更加完美了，最终用户会觉得我们的产品更易用。 我想主要的动力还是大家都还在关注我的工作，给予我帮助。在网上有各式各样很酷的提供人帮助，也可以不停的从他们那学东西，几乎不可能会产生厌倦而扭头去干别的的。色彩非常有趣，相信我会长久做下去的。 英文原文（授权为 CC BY SA 3.0） 感谢 jcome 翻译来稿 |
