Talk:Apple Icon Image format

This is the talk page for discussing improvements to the Apple Icon Image format article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Computing Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.

Apple Inc. Mid‑importance

	This article is within the scope of WikiProject Apple Inc., a collaborative effort to improve the coverage of Apple, Mac, iOS and related topics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Apple Inc.Wikipedia:WikiProject Apple Inc.Template:WikiProject Apple Inc.Apple Inc. articles
Mid	This article has been rated as Mid-importance on the project's importance scale.

Tiger icons

Doesn't Tiger add support for 256 x 256 icons? The Geeklord 21:59, 17 April 2006 (UTC)[reply]

I haven't seen that. I would be thrilled if they did. Dread Lord CyberSkull ✎☠ 23:09, 17 April 2006 (UTC)[reply]

See Mac OS X 10.4 Tiger which states:

Apple has quietly expanded the maximum supported dimensions of Mac OS X's "icns" icon format to include 256x256-pixel icons, and 512x512-pixel icons are not out of the question for the future.

"Scalable User Interface" By John Siracusa, Published: April 28, 2005

There is some evidence that no 256 x 256 icons have been seen in the wild. Leopard has support for 512 x 512. Both of these sizes of icons appear to depend on "Icon Services" to read or write their data, and the interested reader should search for kIconServices256PixelDataARGB or kIconServices512PixelDataARGB . —Preceding unsigned comment added by 81.97.194.106 (talk) 14:47, 25 May 2008 (UTC)[reply]

Am I doing this right? (OS X Icon Editor link)

Newbie editor here...I added the external link to the OS X Icon Editor page because it seems relevant and is one of the few freeware icon-editing resources available for OS X. (All of the See Also links are commercial products.) Is that the correct usage? Perhaps it ought to have its own Wikipedia article, but I haven't the time right now, and I'm not sure if it's sufficiently notable anyway. Phasma Felis 00:17, 28 July 2007 (UTC)[reply]

Is there actually a 256 x 256 icon

See Scaling Your Artwork —Preceding unsigned comment added by 81.97.194.106 (talk) 16:38, 24 May 2008 (UTC)[reply]

The Mac OS 10.5 version of Icon Composer has a slot for 256x256 icons. David Arthur (talk) 18:54, 24 May 2008 (UTC)[reply]

Developer's Information

See HowToMakeAquaIcons and icns file format specification . —Preceding unsigned comment added by 81.97.194.106 (talk) 16:51, 24 May 2008 (UTC)[reply]

Is the run-length compression used in the icns format really PackBits?

I implemented a reader plugin for the icns format, but couldn't read the run-length compressed icons, even though I believe I have PackBits implemented correctly. After googling around, I came across Apace Sanselan, which implementes icns reading and correctly decodes the compressed icons. While similar, that run-length encoding is not PackBits (at least not as described on WikiPedia).

In particular, the length of the compressed runs are defined in PackBits as 1 - n (2-129, smaller n yields larger lenghts, n == -128 is a no-op), but in icns, they seem to be n + 131 (3-130, larger n yields larger lengths).

Is it me, or is it the article that is wrong about PackBits? Confused...

93.124.242.6 (talk) 13:20, 27 October 2011 (UTC) Harald K[reply]