Red Hat Bugzilla – Bug 481290
png2icns does not write large icons properly
Last modified: 2009-02-16 10:08:33 EST
Description of problem:
I created an ICNS file from 16x16, 32x32, 48x48, 128x128, 256x256, and
512x512 4-channel PNGs using png2icns. On Mac OS X, the 256x256 and 512x512
sizes are present but unreadable in the ICNS file. As a result, Mac OS X
scales up smaller icons are scaled up for these two sizes, and apparently that
causes transparency to be lost, which looks terrible and makes ICNS files
produced this way unusable.
ICNS creation appears to work correctly:
[uckelman@scylla 3.1]$ png2icns VASSAL.icns VASSAL_*
DBG: 512 x 128 128 x 32
Using icns type 'it32', mask 't8mk' for 'VASSAL_128x128x32.png'
DBG: 64 x 16 16 x 32
Using icns type 'is32', mask 's8mk' for 'VASSAL_16x16x32.png'
DBG: 1024 x 256 256 x 32
Using icns type 'ic08', mask '' for 'VASSAL_256x256x32.png'
DBG: 128 x 32 32 x 32
Using icns type 'il32', mask 'l8mk' for 'VASSAL_32x32x32.png'
DBG: 192 x 48 48 x 32
Using icns type 'ih32', mask 'h8mk' for 'VASSAL_48x48x32.png'
DBG: 2048 x 512 512 x 32
Using icns type 'ic09', mask '' for 'VASSAL_512x512x32.png'
Saved icns file to VASSAL.icns
[uckelman@scylla 3.1]$ icns2png -l VASSAL.icns
Reading icns family from VASSAL.icns...
Icon family type is 'icns'
Icon family size is 187191 bytes
Listing icon elements...
'it32' 128x128 32-bit icon (65536 bytes compressed to 18266)
't8mk' 128x128 8-bit mask (16384 bytes)
'is32' 16x16 32-bit icon (1024 bytes compressed to 719)
's8mk' 16x16 8-bit mask (256 bytes)
'ic08' 256x256 32-bit icon (262144 bytes compressed to 41481)
'il32' 32x32 32-bit icon (4096 bytes compressed to 2236)
'l8mk' 32x32 8-bit mask (1024 bytes)
'ih32' 48x48 32-bit icon (9216 bytes compressed to 3674)
'h8mk' 48x48 8-bit mask (2304 bytes)
'ic09' 512x512 32-bit icon (1048576 bytes compressed to 100759)
10 elements total in VASSAL.icns.
I have no problem getting back the original PNGs using icns2png, so the
problem appears to be that png2icns and Mac OS X aren't agreeing about what
the ICNS file format looks like.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. png2icns VASSAL.icns VASSAL_*
2. Try VASSAL.icns on Mac OS X.
The 256x256 and 512x512 sizes aren't read properly on Mac OS X.
The 256x256 and 512x512 sizes should be read properly on Mac OS X.
(http://www.vassalengine.org/forums/viewtopic.php?t=1556&start=0&postdays=0&postorder=asc&highlight=) from our forum contains our discussion of the problem, as well as some screenshots from Mac OS X demonstrating what's wrong.
Also, this problem is possibly related to another libicns bug I reported, Bug
481284, which deals with extracting large icons from ICNS files created on Mac
OS X. These together indicate to me that libicns doesn't have the ICNS file
format quite right.
Created attachment 329821 [details]
Created attachment 329822 [details]
Created attachment 329823 [details]
Created attachment 329824 [details]
Created attachment 329825 [details]
Created attachment 329826 [details]
Created attachment 329827 [details]
test PNGs for creating the ICNS file
I have opened an upstream bug for this: SF 2531240
I am upstream author for libicns and icnsutils.
Several bugs were fixed with png2icns in 0.6.1 - can you try those versions?
Hi Mathew, we ship v0.6.1 in Fedora.
(In reply to comment #9)
> Several bugs were fixed with png2icns in 0.6.1 - can you try those versions?
My bug report was about 0.6.1.
Okay, just wanting to double-check that you're working with 0.6.1 as it was only released recently, and several (successful) test cases were done for compatibility with OS X 10.5 at that time.
Thank you for attaching the PNGs used to reproduce the problem. I currently have only limited access to machines OS X 10.5, but will try to get this taken care of within the next week or two.
(In reply to comment #12)
> Thank you for attaching the PNGs used to reproduce the problem. I currently
> have only limited access to machines OS X 10.5, but will try to get this taken
> care of within the next week or two.
Thanks for looking into this. You're in a better state w/r/t testing on OS X than I am---I only have access second-hand, via one of my users who has an OS X machine.
I may have a possible interim solution:
Can you try creating the icon with the parameters in ascending order, i.e.:
png2icns VASSAL.icns VASSAL-16.png VASSAL-32.png VASSAL-64.png VASSAL-128.png ...
Please let me know if this generates a readable icon.
I built a new icon like so
png2icns VASSAL.icns VASSAL-16.png VASSAL-32.png VASSAL-128.png VASSAL-256.png VASSAL-512.png
and my Mac guy told me this about it:
> > Would you have a look at this ICNS file in IconComposer? Do the
> > large sizes show up properly for you now?
> No. They still have the black background.
So, no improvement that way.
I read that there were two separate problems:
1) Large icons were not showing up in the Dock
2) Backgrounds were black (i.e. alpha channel not properly encoded)
The interim solutions should have had an impact on #1 - can you check that for me?
Created attachment 330198 [details]
VASSAL.icns generated from patched libicns
I have made some more changes to libicns in the jp2 coding, and they appear to work in my test cases on OS X 10.5. Please have your test the attached icon, and if it looks successful, I will clean the fix up and merge it with the next release of libicns.
I am interested in knowing both the functionality of the icon in the dock, and the appearance of the clear background.
(In reply to comment #16)
> I read that there were two separate problems:
> 1) Large icons were not showing up in the Dock
> 2) Backgrounds were black (i.e. alpha channel not properly encoded)
> The interim solutions should have had an impact on #1 - can you check that for
Here's my most recent conversation with my tester. The '> >' is me, '>' him.
> > I created a test ICNS file containing icons which consist of nothing
> > but
> > a number matching the icon's dimensions against a transparent
> > background.
> > So, the 256x256 icon is a lime green "256". You should be able to
> > see by
> > inspection which icons are being used where now. Here's a special
> > build
> > containing the test icon:
> > http://www.nomic.net/~uckelman/tmp/vassal/VASSAL-3.1.0-svn4990-icontest-macos
> Ah, an excellent test platform.
> So, the icon used for the general view of the file while it sits on
> disk is the "128" icon.
> When the application launches, it also uses the 128 icon in the dock.
> When the player is launched, it uses the 512 icon with black background.
> So, it seems that the java launcher is using a different method for
> picking the dock icon than the standard Mac application launcher. The
> latter, I guess, uses the largest icon that it can validate. The java
> launcher just uses the large icon, even if it isn't fully valid.
> Now, when I look at the .icns file using IconComposer, only the icons
> up to size 128 show up.
> Looking at it in Preview, I see all of them, but the 256 and 512 have
> black backgrounds.
So it looks like we're only having the alpha channel problem now.
We're setting the dock icon two different ways for two different parts of our app. The part launched from the app bundle is set from the Info.plist in the app bundle. The part launched directly using java has its dock icon set by using the -Xdock:icon flag. The difference we see in behavior between the two might be caused by the missing alpha channel in the large icons, or it might be caused by something else---we won't be able to tell until the alpha channel problem is fixed, which is itself a libicns problem.
(In reply to comment #17)
> Created an attachment (id=330198) [details]
> VASSAL.icns generated from patched libicns
> I have made some more changes to libicns in the jp2 coding, and they appear to
> work in my test cases on OS X 10.5. Please have your test the attached icon,
> and if it looks successful, I will clean the fix up and merge it with the next
> release of libicns.
> I am interested in knowing both the functionality of the icon in the dock, and
> the appearance of the clear background.
> -Mathew Eis
Thanks. My tester has it now. I'll let you know as soon as I hear back from him.
Success! The last ICNS file you attached worked perfectly.
Excellent. Expect a new upstream release of libicns within a week or two with the necessary fixes.
I have released version 0.6.2 upstream, with the fixes that generated the successful test icns file. Others have tested it as working under 10.5.X. Please let me know if it works for you.
I have just released v0.6.2 in rawhide. Releases for F-10 and F-9 will follow. Please test them and report here if the problem still persists.
Looks good. Thanks.