Bug 481290

Summary: png2icns does not write large icons properly
Product: [Fedora] Fedora Reporter: Joel Uckelman <uckelman>
Component: libicnsAssignee: Andrea Musuruane <musuruan>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 10CC: mathew, musuruan
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-02-07 07:27:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
16x16 icon
none
32x32 icon
none
48x48 icon
none
128x128 icon
none
256x256 icon
none
512x512 icon
none
test PNGs for creating the ICNS file
none
VASSAL.icns generated from patched libicns none

Description Joel Uckelman 2009-01-23 13:10:49 UTC
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: RGB+A
DBG: 512 x 128  128 x 32
Using icns type 'it32', mask 't8mk' for 'VASSAL_128x128x32.png'
DBG: RGB+A
DBG: 64 x 16  16 x 32
Using icns type 'is32', mask 's8mk' for 'VASSAL_16x16x32.png'
DBG: RGB+A
DBG: 1024 x 256  256 x 32
Using icns type 'ic08', mask '' for 'VASSAL_256x256x32.png'
DBG: RGB+A
DBG: 128 x 32  32 x 32
Using icns type 'il32', mask 'l8mk' for 'VASSAL_32x32x32.png'
DBG: RGB+A
DBG: 192 x 48  48 x 32
Using icns type 'ih32', mask 'h8mk' for 'VASSAL_48x48x32.png'
DBG: RGB+A
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):

libicns-0.6.1-1.fc10.x86_64
libicns-utils-0.6.1-1.fc10.x86_64


How reproducible:

Always.

Steps to Reproduce:
1. png2icns VASSAL.icns VASSAL_*
2. Try VASSAL.icns on Mac OS X.
  
Actual results:

The 256x256 and 512x512 sizes aren't read properly on Mac OS X.

Expected results:

The 256x256 and 512x512 sizes should be read properly on Mac OS X.

Additional info:

This thread
(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.

Comment 1 Joel Uckelman 2009-01-23 13:11:17 UTC
Created attachment 329821 [details]
16x16 icon

Comment 2 Joel Uckelman 2009-01-23 13:11:43 UTC
Created attachment 329822 [details]
32x32 icon

Comment 3 Joel Uckelman 2009-01-23 13:12:24 UTC
Created attachment 329823 [details]
48x48 icon

Comment 4 Joel Uckelman 2009-01-23 13:12:45 UTC
Created attachment 329824 [details]
128x128 icon

Comment 5 Joel Uckelman 2009-01-23 13:13:15 UTC
Created attachment 329825 [details]
256x256 icon

Comment 6 Joel Uckelman 2009-01-23 13:13:40 UTC
Created attachment 329826 [details]
512x512 icon

Comment 7 Joel Uckelman 2009-01-23 13:16:55 UTC
Created attachment 329827 [details]
test PNGs for creating the ICNS file

Comment 8 Andrea Musuruane 2009-01-23 15:41:01 UTC
I have opened an upstream bug for this: SF 2531240

https://sourceforge.net/tracker/index.php?func=detail&aid=2531240&group_id=174339&atid=868840

Comment 9 Mathew Eis 2009-01-25 03:50:53 UTC
Hi,

I am upstream author for libicns and icnsutils.

Several bugs were fixed with png2icns in 0.6.1 - can you try those versions?

Thank you,

-Mathew Eis

Comment 10 Andrea Musuruane 2009-01-25 09:33:09 UTC
Hi Mathew, we ship v0.6.1 in Fedora.

Comment 11 Joel Uckelman 2009-01-25 15:25:01 UTC
(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.

Comment 12 Mathew Eis 2009-01-25 17:52:38 UTC
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.

Comment 13 Joel Uckelman 2009-01-25 18:03:32 UTC
(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.

Comment 14 Mathew Eis 2009-01-27 05:05:25 UTC
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.

Thank you,

-Mathew Eis

Comment 15 Joel Uckelman 2009-01-27 19:15:36 UTC
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.

Comment 16 Mathew Eis 2009-01-27 20:26:47 UTC
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?

Comment 17 Mathew Eis 2009-01-28 07:01:01 UTC
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.

-Mathew Eis

Comment 18 Joel Uckelman 2009-01-28 10:58:21 UTC
(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
> me?


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
> x.dmg
> 
> 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.

Comment 19 Joel Uckelman 2009-01-28 11:15:08 UTC
(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.

Comment 20 Joel Uckelman 2009-01-28 18:47:38 UTC
Success! The last ICNS file you attached worked perfectly.

Comment 21 Mathew Eis 2009-01-28 19:12:57 UTC
Excellent. Expect a new upstream release of libicns within a week or two with the necessary fixes.

-Mathew Eis

Comment 22 Joel Uckelman 2009-01-28 20:41:24 UTC
Thanks much.

Comment 23 Mathew Eis 2009-02-06 01:44:57 UTC
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.

-Mathew Eis

Comment 24 Andrea Musuruane 2009-02-07 07:27:32 UTC
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.

Comment 25 Joel Uckelman 2009-02-16 15:08:33 UTC
Looks good. Thanks.