注: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 发送了错误报告。我仍然想要一种解决方法,因为我找不到。
最佳答案
该问题可以在 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 中做的第一件事是
如果你想自己测试一下,这里是图片:
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 的数量相同时,似乎会发生这种情况。可能还有其他情况。
一个简单的解决方法似乎是简单地稍微改变一个像素的值。这是人眼无法看到的。
关于xcode - 什么会导致彩色 mac 应用程序图标显示为灰度?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/60896739/