Images of 16x16, 32x32 and 128x128 are bad previewed

[aonez]

As you can see, the "_" prefixed icon was rendered with createicns while the non prefixed was created with iconutil.

Only affects 16x16 and 32x32 images (don't have a retina display so can't check @2x versions). I'm attaching the example with the iconset, so maybe you can test it: Test.zip

Thanks in advance!

[MaxPower85]

On a MBP Retina all icons look fine... I checked it out in Parallels too, to see how it would look on a non-Retina Mac and I see that there is that issue with that _7z.icns file you sent, but when I created the .icns file from the PNGs you included with createicns 7z.iconset, it doesn't seem to have that issue and the file size is different (the file size is similar to that of those PNGs), but your _7z.icns file size is double of what it should be if you created them from the same PNGs.

What exactly did you do?

[aonez]

Sorry I forgot to mention that you need to apply the icon to itself so it shows like it would in a app or in a file that uses that icon. So after creating 7z.icns, right click and Get Info and then just drop the file to the little preview on the top. That's why it weights double and this is a demo of how this icon will appear when an app uses it.

You can obviously apply the icon to any other folder or file and the result will be the same.

Icon not applied:

Icon applied:

[MaxPower85]

Yes, you are right... I tested it in Parallels now to see how it would appear on non-Retina Macs and icons created with createicns from PNG files show that issue when you do that... it seems to only affect non-Retina 16x16 and 32x32 icons.

I checked those PNGs with pngcheck before creating the .icns file and the PNGs appear to be OK... I also tried to open those PNGs in Preview and to save them again from it, but the same things happens when the .icns file is created with createicns...

Also... if you try to use iconutil -c iconset to extract those pngs from those the .icns file created by createicns, the non-Retina 16x16 and 32x32 pngs aren't there... but the readicns can extract them as PNGs.

And if you create an icon from those PNGs using iconutil -c icns, then readicns has issues extracting the 16x16 and 32x32 sizes as PNGs from it and some files like "icon_data_il32", "icon_data_info", "icon_data_is32", "icon_data_l8mk" and "icon_data_s8mk" appear in the .iconset folder instead of those PNGs.

But if after you create an icon with iconutil -c icns and extract the PNGs with readicns (although it extracts the 16x16 and 32x32 sizes as "icon_data_il32", "icon_data_info", "icon_data_is32", "icon_data_l8mk" and "icon_data_s8mk" instead of PNGs) and you just leave those "icon_data_il32", "icon_data_info", "icon_data_is32", "icon_data_l8mk" and "icon_data_s8mk" files in that folder... you can optimize the PNGs that were correctly extracted and create the icon again with createicns and then that icon doesn't seem to show this issue and the 16x16 and 32x32 sizes are there (it seems to recognize those "icon_data_il32", "icon_data_info", "icon_data_is32", "icon_data_l8mk" and "icon_data_s8mk" files and includes them in the .icns file without those issues).

[MaxPower85]

I've been reading more about the .icns format... il32 and l8mk are the 32x32 sizes in a format for Classic Mac OS 8.5 and is32 is 16x16 size in the format for Classic Mac OS 8.5...

It seems that when iconutil creates .icns files that it isn't using PNG format for 16x16 and 32x32 non-Retina sizes... it seems that it converts those sizes to a format compatible with Classic Mac OS 8.5... that would explain why readicns can't extract PNG data for those sizes when the .icns file is created with iconutil -c icns, if that's PackBits format and not PNG...

And when createicns makes icons only from PNG files, maybe the issue is that macOS is expecting the 16x16 and 32x32 non-Retina sizes to be in that PackBits format...

I guess that maybe the issue could be solved by using a PackBits encoder for those sizes.

[aonez]

So if it uses something similar to PackBits, it's using a TIFF image (https://en.wikipedia.org/wiki/PackBits). I'll try using a plain TIFF image instead of the PNG and, if it works, bring to implement the PackBits compression.

[aonez]

So right now @MaxPower85's workaround is the best way to go:

1. Convert the .iconset to an icns file using iconutil -c icns
2. Extract this icns file contents using readicns
3. Copy all the non PNG files inside, which are the 16, 32 and 128 versions to your original .iconset
4. Remove the original 16, 32 and 128 PNG before creating the icns file using createicns.

This only applies to @1x quality, @2x files (like [email protected]) do not have this issue.