是什么导致彩色Mac App图标显示为灰度？

117

印第安纳·克尼克（Indiana Kernick）：

注意：MCVE结尾

我为Mac应用程序更新了AppIcon和Document图标。图标已更改，但也显示为灰度。源文件（PNG）带有颜色。图标在Xcode内显示为彩色，但在上下文中（停靠处的AppIcon和Finder中的文档图标）为灰度。我已经尝试了一些明显的工作，例如清理构建文件夹，重新启动Xcode和重新启动Finder，但我不知道还能尝试什么。

图标在上下文中的显示方式如下：

图标在Xcode中的显示方式如下：

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

在更改图标的git commit中，唯一更改的是一些PNG和一些文档文件（自述文件中的链接，屏幕截图和其他内容）。如果我在更改图标之前签出提交，一切都很好。如果我签出更改图标的提交，则它们为灰色。

我一直在研究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输出。

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 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栏中并下载它们。

animera之后的旧（有效）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中修复。

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

斯蒂芬·施莱希特（Stephan Schlecht）：

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

缩小问题范围

资产目录（.xcassets）由Xcode编译为Asset.car文件。

要查看已编译的Asset.car甚至从中提取图像资源，您将需要其他工具，例如Asset Catalog Tinkerer。

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

brew cask install asset-catalog-tinkerer

使用该工具可以从Asset.car中提取图像。它的名称为[email protected]，是灰度图像。

可以通过视觉或通过命令行调用进行检查：

sips -g all [email protected]

该工具的输出为：

/Users/stephan/tmp/[email protected]
  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通道的灰度图像（请参见samplesPerPixel，hasAlpha和颜色空间属性）。

第一结果

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

内容分析一

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

那可能是图像的像素含量值吗？

下一步尝试：将图像编辑软件红色区域中的单个像素从＃0xff0000ff更改为＃0xff0100ff。因此，这是人眼无法看到的更改，但在这种情况下，您可以看到：图像不再是灰度，而是彩色的。

让我们进一步分析和分析颜色：4个通道中的每个值的值均为0x00或0xff，这给出了16种不同的组合。

创建随机图像

听起来很像领导。因此，下一个尝试：创建一个小程序，随机使用8种可能的不透明颜色（每个rgb通道0x00或0xff的所有组合，alpha = 0xff）。

结果是彩色图像。

内容分析II

让我们再次看一下图片。可能是颜色均匀分布了吗？

现在让我们用一个小程序进行分析，该程序计算RGBA值0xff出现的频率，结果是：

   R     G      B      A
212992 212992 212992 540672

实际上，值0xff的R，G和B出现的次数完全相同。

假设

为了进一步证实这一假设，现在可以以编程方式生成一种条纹图案，在该条纹图案中颜色会经常出现。

确实，通过此图像，我们在Dock和App Switcher中看到了灰度图像，在屏幕快照中看到了通过前台的CMD + TAB使用App Switcher时背景中的资产和灰度应用程序图标。

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

测试

每当更改图像时，在Xcode中要做的第一件事就是<Product / Clean Build Folder>（产品/清洁生成文件夹）（SHIFT-CMD-K）。

如果您想自己进行测试，请查看以下图片：

https://www.software7.biz/iertzzlmbkjdkjrk/256_randomWorking.png（工作->颜色）https://www.software7.biz/iertzzlmbkjdkjrk/256_brokenStripes.png（破碎->灰度）https：//www.software7。 biz / iertzzlmbkjdkjrk / 256_semiRandomBroken.png（无聊 ->灰度）

摘要

因此，这似乎不是macOS中的错误，而是在将资产编译/优化为Asset.car文件的过程中。当R，G，B值的数量等于0xff时，似乎会发生这种情况。可能还有其他情况。

一个简单的解决方法似乎是非常简单地更改一个像素的值。人眼看不到这一点。

本文收集自互联网，转载请注明来源。

如有侵权，请联系 [email protected] 删除。

编辑于 2020-04-12

我来说两句

0 条评论

登录后参与评论

TOP 榜单

文章

是什么导致彩色Mac App图标显示为灰度？

是什么导致彩色Mac App图标显示为灰度？

构建类似于Jarvis的本地语言应用程序

在 Avalonia 中是否有带有柱子的 TreeView 或类似的东西？

Qt Creator Windows 10 - “使用 jom 而不是 nmake”不起作用

SQL Server中的非确定性数据类型

使用next.js时出现服务器错误，错误：找不到react-redux上下文值；请确保组件包装在<Provider>中

Swift 2.1-对单个单元格使用UITableView

Hashchange事件侦听器在将事件处理程序附加到事件之前进行侦听

HttpClient中的角度变化检测

如何了解DFT结果

错误：找不到存根。请确保已调用spring-cloud-contract：convert

Embers js中的更改侦听器上的组合框

在Wagtail管理员中，如何禁用图像和文档的摘要项？

如何避免每次重新编译所有文件？

Java中的循环开关案例

ng升级性能注意事项

Swift中的指针替代品？

如何使用geoChoroplethChart和dc.js在Mapchart的路径上添加标签或自定义值？

使用分隔符将成对相邻的数组元素相互连接

在同一Pushwoosh应用程序上Pushwoosh多个捆绑ID

ggplot：对齐多个分面图-所有大小不同的分面

完全禁用暂停（在内核级别？-必须与使用的DE和登录状态无关！）