xcode - 什么会导致彩色 mac 应用程序图标显示为灰度？

Question

注:MCVE 末尾

我更新了我的 mac 应用程序的 AppIcon 和 Document 图标。图标已更改，但它们也显示为灰度。源文件 (PNG) 是彩色的。图标在 Xcode 中显示为彩色，但在上下文中(停靠栏中的 AppIcon 和 Finder 中的文档图标)是灰度的。我已经尝试过一些显而易见的事情，比如清理构建文件夹、重新启动 Xcode 和重新启动 Finder，但我不知道还能尝试什么。

这是图标在上下文中的显示方式:




这是图标在 Xcode 中的显示方式:



我所做的只是更新了一些 PNG!一切仍然正常运行。该应用程序仍会启动，双击文档可打开该应用程序。问题是图标是灰色的。

在更改图标的 git commit 中，唯一更改的是一些 PNG 和一些文档文件(自述文件中的链接、屏幕截图和其他一些内容)。如果我在更改图标之前检查提交，则一切正常。如果我 checkout 更改图标的提交，它们是灰色的。

我一直在查看 PNG 本身以试图解决这个问题。我正在使用 pngcheck检查文件。

旧(工作)16x16 图标:

chunk IHDR at offset 0x0000c, length 13
  16 x 16 image, 32-bit RGB+alpha, non-interlaced
chunk bKGD at offset 0x00025, length 6
  red = 0x00ff, green = 0x00ff, blue = 0x00ff
chunk IDAT at offset 0x00037, length 142
  zlib: deflated, 2K window, maximum compression
  row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (16 out of 16)
chunk IEND at offset 0x000d1, length 0

新的(损坏的)16x16 图标:

chunk IHDR at offset 0x0000c, length 13
  16 x 16 image, 32-bit RGB+alpha, non-interlaced
chunk IDAT at offset 0x00025, length 109
  zlib: deflated, 2K window, default compression
  row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
    0 1 1 1 2 2 4 1 1 4 2 2 1 1 0 0 (16 out of 16)
chunk IEND at offset 0x0009e, length 0

好的，也许是 bKGD块是必需的吗？不。我通过了图片 gm convert (不带参数)添加 bKGD并且还改变了压缩级别，它仍然以灰度显示。

gm 转换后的新(损坏)16x16 图标:

chunk IHDR at offset 0x0000c, length 13
  16 x 16 image, 32-bit RGB+alpha, non-interlaced
chunk bKGD at offset 0x00025, length 6
  red = 0x00ff, green = 0x00ff, blue = 0x00ff
chunk IDAT at offset 0x00037, length 106
  zlib: deflated, 2K window, maximum compression
  row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
    0 1 1 1 2 2 4 1 1 4 2 2 1 1 0 0 (16 out of 16)
chunk IEND at offset 0x000ad, length 0

所以现在看起来损坏的 PNG 和工作的 PNG 之间的唯一区别是行过滤器(当然还有图像数据本身)。为什么这会导致问题？!我不知道单独使用命令行设置行过滤器的方法。这甚至可能与libpng有关吗？每当我使用 libpng 时，我只是让库选择过滤器。我是否必须编写自己的 png 编码器来解决这个问题？

我觉得我一定在这里吠错了树，但是 唯一改变(影响构建)的是少数 PNG 文件 .疯了吧。

我又玩了一会儿，发现 128@2x 图标(不是 256 图标!)才是最重要的。用旧图标替换此图像会导致旧图标显示为彩色。用新图标替换此图像会使新图标以灰度显示。这两个 PNG 文件之间的差异是导致问题的原因。这是我遇到过的最可笑的问题。

我试图将这些图像更紧密地结合在一起，以尝试使新的工作或旧的工作中断，但我就是想不通。我通过我用来制作新图像的相同工具传递旧图像(恰好是此图标适用的应用程序!)并且它仍然以彩色显示!这是 pngcheck输出。

日本动漫后的旧(工作)128x128@2x 图标:

chunk IHDR at offset 0x0000c, length 13
  256 x 256 image, 32-bit RGB+alpha, non-interlaced
chunk IDAT at offset 0x00025, length 965
  zlib: deflated, 32K window, default compression
  row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
    1 2 2 2 2 2 2 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
    2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 1 2
    2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 2 2 2
    2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 4 2 2 2
    2 2 2 2 1 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 1 2 2 2 2
    2 2 2 4 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 4 2 2 2 2 2
    2 2 4 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
    2 2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
    1 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 0
    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
    0 0 0 0 0 0 (256 out of 256)
chunk IEND at offset 0x003f6, length 0

Animera 之后的新(损坏)128x128@2x 图标:

chunk IHDR at offset 0x0000c, length 13
  256 x 256 image, 32-bit RGB+alpha, non-interlaced
chunk IDAT at offset 0x00025, length 830
  zlib: deflated, 32K window, default compression
  row filters (0 none, 1 sub, 2 up, 3 avg, 4 paeth):
    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 2 2 2 2 2 2 2
    2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 2
    2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
    2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 4 2 2 2
    2 2 2 2 2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 2 2 2 2 2
    2 2 2 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 4 2 2 2 2 2
    2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
    2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2
    2 2 2 2 2 2 2 2 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 0
    0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
    0 0 0 0 0 0 (256 out of 256)
chunk IEND at offset 0x0036f, length 0

这是荒唐的!我开始怀疑我是否在 macOS 中发现了一个非常奇怪的错误。

如果您想自己检查图像，这些是上一节中的两个图像。我认为 imgur 重新编码图像，所以我将它们转换为数据 URI，以便您可以将它们粘贴到 URL 栏中并下载它们。

日本动漫后的旧(工作)128x128@2x 图标:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAQAAAAEACAYAAABccqhmAAADxUlEQVR4nO3dQW6kMBRAQRjl/ldmbgALx7KdV7XNIg7debL0DdzPdd3Xi/u6nrefA+f6t3oBwDoCAGECAGECAGECAGECAGECAAAAAAAAAAAAAAAAAAAAAAAbeX0nAOs9h7+X4fYd25onAkGYAECYAECYAECYAECYAECYAECYGe1kp8/xV3OOYC47AAgTAAgTAAgTAAgTAAgTAAgTAAgzYx1kzr+WcwJj7AAgTAAgTAAgTAAgTAAgTAAgTAAgzAz1gzn/2ZwTeGcHAGECAGECAGECAGECAGECAGECAGECAGECAGECAGECAGECAGECAGECAGECAGH5e6Xd799Wf16AHQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCECQCE/axewHTP9axewpDj316//eX/WOB9/Cfwxg4AwgQAwgQAwgQAwgQAwgQAwgQAwvafcU6e428/pR41/An/7Ss0/x9g73MEdgAQJgAQJgAQJgAQJgAQJgAQJgAQtn5Gufn9+lsv7jfcf/svXP8F/7L2nIAdAIQJAIQJAIQJAIQJAIQJAIQJAITNn0FuPuf/cvTir+sa/gv2H6S/Onz51+xzAnYAECYAECYAECYAECYAECYAECYAEPazegG7+xrCnn9O4Gznz/nXsgOAMAGAMAGAMAGAMAGAMAGAMAGAsPEx6uH3+882/+IsvvyTB/Hm/F/GnhdgBwBhAgBhAgBhAgBhAgBhAgBhAgBhngcw2egc+/RDFub4e7MDgDABgDABgDABgDABgDABgDABgDDnADZnjs5MdgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQNv/188/1TP8dvBi8/PO/Iby6p34CdgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQJgAQtv5ub88LWOt2+deae7//FzsACBMACBMACBMACBMACBMACBMACFt/DuCLcwJj7tHP+HH9h6yd83+xA4AwAYAwAYAwAYAwAYAwAYAwAYCwrWeUv+L0cwTDc/zVTj9HsPccf5QdAIQJAIQJAIQJAIQJAIQJAIQJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvPgPQZExnSU6E9oAAAAASUVORK5CYII=

Animera 之后的新(损坏)128x128@2x 图标:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAQAAAAEACAYAAABccqhmAAADPklEQVR4nO3cwZEDIQwAQbhy/injDO7DQ6amOwJ5dz3FR6wFAAAAAAAAAAAAAAAAAAAA/Jo9PUDdWetMzzBp+wZH/U0PAMwRAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAizi32pvs8/zX0Cd5wAIEwAIEwAIEwAIEwAIEwAIEwAIEwAIEwAIEwAIEwAIEwAIEwAIEwAIEwAICy/S22fv61+n4ATAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIQJAIR9pge4dtaZHmHUnh7g+cd/+QP2+Bu44QQAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYfO7zI/v8z89/Fpr7bd/wfwHfGv2PgEnAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAgTAAi730V+fJ9/2v3DG378l1/Q+/v80+7uE3ACgDABgDABgDABgDABgDABgDABgDABgDABgDABgDABgDABgDABgDABgDABgLDP9AB19uGZ5AQAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYQIAYXt6gHXWmR4hbXv8s/bof9AJAMIEAMIEAMIEAMIEAMIEAMIEAMIEAMIEAMIEAMIEAMIEAMIEAMIEAMIEAMLm7wO4Vb9PYE+/w9N+/sP7/LecACBMACBMACBMACBMACBMACBMACBMACBMACBMACBMACBMACBMACBMACBMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4B9fjX8anopwslQAAAAASUVORK5CYII=

我真的希望有人能解决这个问题!

我已经创建了这个问题的 MCVE (在 github 上)。我创建了一个新的 mac 应用程序。我所做的只是设置了 128@2x 图标，我能够重现这个问题。 “工作”图标是彩色的。 “损坏的”图标是灰色的(请参阅上一节中的数据 URI)。您可以在 Contents.json 中编辑文件名。文件(随后是干净的构建)以在它们之间切换。我开始好像在 macOS 中发现了一个错误!虽然，如果它是一个错误，那么它可能不会在 Mojave 中修复。

我向 Apple 发送了错误报告。我仍然想要一种解决方法，因为我找不到。

Answer 1

该问题可以在 macOS Catalina 上使用 Xcode 11.3.1 重现。

缩小问题范围

Assets 目录 (.xcassets) 由 Xcode 编译为 Asset.car 文件。

要查看编​​译后的 Asset.car 甚至从中提取图像资源，您需要一个额外的工具，例如 Assets 目录修补程序。

可以通过以下方式安装此工具:

brew cask install asset-catalog-tinkerer 

使用该工具可以从 Asset.car 中提取图像。它被命名为 256_broken_Normal@2x.png，它是一个灰度图像。

可以直观地或使用命令行调用来检查这一点:

sips -g all 256_broken_Normal@2x.png    

该工具的输出是:

/Users/stephan/tmp/256_broken_Normal@2x.png
  pixelWidth: 256
  pixelHeight: 256
  typeIdentifier: public.png
  format: png
  formatOptions: default
  dpiWidth: 72.000
  dpiHeight: 72.000
  samplesPerPixel: 2
  bitsPerSample: 8
  hasAlpha: yes
  space: Gray
  profile: Generic Gray Gamma 2.2 Profile

所以你可以看到它不再是 RGBA32 而是带有 alpha channel 的灰度图像(参见 samplesPerPixel、hasAlpha 和颜色空间属性)。

第一个结果

所以这可能不是 macOS 中的错误，而是 Asset.car 文件的创建。

内容分析一

有趣的是，您无法通过删除和重新添加颜色配置文件来解决问题，也无法通过将图像加载到图像处理器中并重新编写它来解决问题。

那么它可能是图像的像素内容值吗？

下一次尝试:将图像编辑软件红色区域中的单个像素从#0xff0000ff 更改为#0xff0100ff。所以这是人眼在视觉上不应该看到的变化，但在这种情况下你可以看到它:图像不再是灰度的，而是彩色的。

让我们进一步分析颜色，有趣的是:4 个 channel 中的每个值都具有值 0x00 或 0xff，这给出了 16 种不同的组合。

创建随机图像

这听起来像一个领先。所以接下来尝试:创建一个小程序，随机使用 8 种可能的不透明颜色之一(每个 rgb channel 0x00 或 0xff 的所有组合，alpha = 0xff)。

结果是彩色图像。

内容分析二

让我们再看一下图片。会不会是颜色分布均匀？

现在让我们用一个小程序来分析一下 R G B A 值 0xff 出现的频率，结果是:

   R     G      B      A
212992 212992 212992 540672

确实存在值为 0xff 的 R、G 和 B 以完全相同的数量出现的情况。

假设

为了进一步证实这一假设，现在可以以编程方式生成一种条纹图案，其中颜色的出现频率相同。

事实上，通过这张图片，我们在 Dock 和 App Switcher 中看到了一个灰度图像，在屏幕截图中看到了后台的 Assets 和在前台通过 CMD+TAB 使用 App Switcher 时的灰度应用程序图标。



现在我们再次尝试使用相同颜色的小方块的半随机分布。同样，在 Xcode 中使用该图像时，我们会得到一个灰度应用程序图标，请参见屏幕截图。



测试

每当更改图像时，您必须在 Xcode 中做的第一件事是 (SHIFT-CMD-K)。

如果你想自己测试一下，这里是图片:

https://www.software7.biz/iertzzlmbkjdkjrk/256_randomWorking.png (工作 -> 颜色)
https://www.software7.biz/iertzzlmbkjdkjrk/256_brokenStripes.png ( splinter -> 灰度)
https://www.software7.biz/iertzzlmbkjdkjrk/256_semiRandomBroken.png (borken -> 灰度)

摘要

所以它似乎不是 macOS 中的错误，而是在将 Assets 编译/优化到 Asset.car 文件期间。当 R、G、B 值等于 0xff 的数量相同时，似乎会发生这种情况。可能还有其他情况。

一个简单的解决方法似乎是简单地稍微改变一个像素的值。这是人眼无法看到的。