我现在试图了解 JPEG 编码是如何工作的，除了颜色转换部分外，一切似乎都很好。
在尝试在 DCT 算法中执行 JPEG 之前，图像被转换为 YCbCr 颜色空间。对我来说，这本质上意味着我们只是(与初始 RGB 图像相比)获取一大块颜色信息并在应用 RGB -> YCbCr 转换时处理它。
所以，我们的编码步骤通常看起来像 RGB -> YCbCr -> DCT -> Huffman 。解码意味着反转这个过程。
我的问题是 - 为什么图像(例如，创建并导出到 JPEG )在颜色方面保持不变，尽管我们必须进行逆 YCbCr -> RGB 变换。颜色信息的处理部分来自哪里或如何处理？
最佳答案
转换本身不会处理任何信息。这种变换在数学意义上是可逆的。例如。如果您将颜色转换为 YCbCr 并将结果转换回 RGB，您将获得相同的颜色。毕竟在一个完美的世界里。
在实践中存在信息丢失。假设您从 RGB 中的三个字节开始。如果转换为 YCbCr，则会得到三个值，其中两个值，即 Cb 和 Cr 不再适合 8 位。从技术上讲，RGB 和 YUV 的两种表示具有不同的色域 ( http://en.wikipedia.org/wiki/Gamut )
幸运的是，这种信息丢失很少见。重要的侧节点:这个色域是一个不需要的副作用，与首先选择使用 YCbCr 无关。
使用 YCbCr 的要点是，存储在 Y 中的数据是最重要的。它是亮度，或灰度值。 Cb和Cr中的数据可以说是减去亮度的颜色信息。
现在我们的眼睛不太擅长挑选颜色的细微差异，但它们对强度的阴影很敏感。为了在 jpeg 中使用它，只存储 Cb 和 Cr 的低分辨率图像，而 Y 以全分辨率存储。有不同的方法可以做到这一点，最常见的方法是从 x 和 y 中的 Cb 和 Cr 中删除所有其他像素。这将 Cb 和 Cr 的空间需求减少了四倍。
它不会神奇地回来。信息永远丢失。但是，由于信息一开始并不那么重要，因此我们看不到太多伪影。
在 jpeg 中，Cb 和 Cr Pane 的遗漏像素通过再次放大 Cb 和 Cr 平面来近似。一些解码器只是通过选择一个邻居来复制丢失的像素，其他解码器进行线性插值。
关于c++ - 色彩空间 - RGB 和 YCbCr 问题，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/2892189/