macOS上的sRGB colorPixelFormat给出了奇怪的结果

Question

背景：我正在尝试在iTerm2中解决这个问题：https://gitlab.com/gnachman/iterm2/issues/6703#note_71933498

iTerm2对其所有纹理使用MTLPixelFormatBGRA8Unorm的默认像素格式，包括MTKView的drawable。在我的机器上，如果我的纹理函数返回颜色 C ，则“在sRGB中显示”中的数字颜色计应用程序将显示屏幕颜色为 C 。我不知道为什么会这样！它应该将原始颜色值从我的纹理函数转换为sRGB，导致它们发生变化，对吗？例如，这是我的片段函数返回(0, 0.16, 0.20, 1)窗口背景颜色时看到的内容：

这很奇怪，但我可以忍受它，直到有人抱怨它在他们的机器上不起作用（参见上面链接的问题）。对于他们来说，我的片段函数返回的值将通过Generic - ＆gt; sRGb转换并且看起来不对。这是一个hackintosh，所以它可能是一个驱动程序错误或其他什么，但它促使我更多地研究它。

如果我将像素格式更改为MTLPixelFormatBGRA8Unorm_sRGB，那么我会得到无法解释的颜色：

片段函数保持不变，返回(0, 0.16, 0.2, 1)。它渲染到我使用MTLPixelFormatBGRA8Unorm_sRGB像素格式创建的纹理（不是drawable，如果它很重要，尽管drawable具有相同的像素格式），我可以在GPU调试器中看到这个纹理也分配了 - 你在上面看到的明亮价值。在此屏幕截图中，数字色度计显示“中间纹理”缩略图的颜色：

这是片段函数（为了调试目的而修改）：

fragment float4 iTermBackgroundColorFragmentShader(iTermBackgroundColorVertexFunctionOutput in [[stage_in]]) { return float4(0, 0.16, 0.20, 1); }

我还尝试攻击Apple的sample app（MetalTexturedMesh）以使用sRGB像素格式并从其片段着色器返回相同的颜色，我得到了相同的结果。 Here is the change I made to it。我只能得出结论，我不明白金属如何定义像素格式，我找不到任何合理的解释来给出我所看到的行为。