Other Finder peculiarities with resource-fork icons (ICNS) rendering in Leopard, when ICNS are created/pasted in at least High Sierra

[B S Magnet]

The title I’m starting here isn’t very helpful and is also kind of vague, so I’ll try to describe here what the title can’t, along with a bit of background.


Some background on why I’m posting:

For many years, I’ve maintained an archival library of music on which I’ve been curating since about 1989. I use the library as my own personal collection, but also as the source for when I do DJing sets. My iTunes 10.6.3 library for the collection also lives on here.

One thing I do with directories in this collection is to paste the image of title’s sleeve art into the parent directory in Finder, creating a custom icon in lieu of a generic folder. File/directory icons are handled by the ICNS resource in the resource fork.

For artists with multiple nested titles/items (e.g., Ryuichi Sakamoto, whose directory contains tens of his works, each work within being their own directories and whose icon is the sleeve art of that work), I came up with my own personal convention for marking a top-level directory.

This convention comes from a Photoshop template I created back in, like, 2014. I use it to plug in names, a big glyph based on the surname or filing name, and a unique hue I assign to all top-level directories sharing the same big glyph (e.g., “A”, “P”, “J”, etc.).

A good example: all artists/bands indexed by letter “S” — Sade, Shiina Ringo, Stacey Q, etc. — use black text and a magenta background. You can see this in the following example here with the directory for “AL STEWART” (which is for, obv., Al Stewart).

In Mojave 10.14.6:

The bug/issue

This issue, or bug only came to my notice very recently.

And I think I know why, but I don’t know mechanism what is causing it. But it is replicable.

Much of the original pasting of directories back in 2014 were prepared and done in Finder from a system running 10.6.8.

I added a great deal of new items in the past year, however, and these were added from Macs running either 10.13.6 or 10.14.6. The method for creating the custom index letter icons was done the same way as always. I hadn’t noticed anything amiss.

This week, I brought the external drive containing the library original/working drive over to my Power Mac G5 running 10.5.8 Server.

In the past, as with present, I use Carbon Copy Cloner 3.4.7 on there to manually back up the external drive’s newly added and revised contents to a server location dedicated to this backup.

What I only just noticed, however, and which has probably been the case this whole time, is any newly-pasted ICNS/icons which were pasted to the directories in High Sierra or Mojave appear as blank icons in Leopard.

In 10.5.8:

The reason I probably hadn’t noticed before was because, until recently, I hadn’t added any directories which would have appeared at the top of the directory listing (in alphabetical order). Now that I have, though, I’m seeing this feature/bug.

To be sure, I opened both the external drive and also network-connected to its cloned backup from another Mac running Snow Leopard (one which has never been involved with my archival work). The icons render just fine.

In 10.6.8:

So this becomes a question I can’t answer, but I’m sharing it with folks anyhow.

The quirk may have emerged in the way finder in macOS, no later than High Sierra and possibly further back. Unfortunately, I have no Macs running Lion through Sierra on which I could test to determine when this quirk emerged. But whatever it is, the issue seems to involve the way the ICNs resource fork data: along the way, something very minor was changed — something which an older system can’t seem to parse properly.

To be sure, I pulled out Build 10A96 of Snow Leopard and had a look from there (whose code base precedes 10.5.8 by several months and whose Finder is Carbonized still). Unpolished gremlins in 10A96 notwithstanding, the quirk seen in Leopard is also seen here.

Conclusion (?)

Something changed in the way Finder managed ICNS/icons in the resource fork from Snow Leopard, forward.

Snow Leopard can correctly parse ICNS/icons added in by later versions of macOS; Leopard (and the Carbonized Finder in PowerPC builds of Snow Leopard developer) cannot, apparently. Leopard can render the ICNS/icons added in by, at least, Snow Leopard, but along the way, ICNS/icons pasted and created in a later build of OS X/macOS stops playing nicely with pre-Snow Leopard.

Unfortunately, I don’t know why. And I’m also not going to, retroactively, fix these icons for Leopard, because all the work of assembling the library happens on Intel Macs running Snow Leopard or greater.

 

[Wowfunhappy]

I'm sorry, none of what I'm about to say is helpful.

But unfortunately, this doesn't really surprise me. There are a surprising number of Finder incompatibilities across macOS versions, which nobody appears to have documented or know about.

Here's another example: let's say that in High Sierra you create a DMG with an alias to the /Applications folder (or elsewhere), as is a relatively standard way to distribute apps. That DMG will mount in Snow Leopard, but the alias will be broken.

The only solution is probably need to do your "archival work" in the oldest version of Mac OS that you care about, or at least an older version that you've tested to work on the oldest version.

I also have a meticulously organized media collection, but as much as I'd like to have e.g. custom folder icons (like, I'm kind of jealous of yours), I avoid using any Apple-specific metadata explicitly because I simply can't trust that it will last. (I do use custom album art for songs/movies because that can be embedded into the media file itself.)

 

[B S Magnet]

I'm sorry, none of what I'm about to say is helpful.

Nah, you’d be surprised. It’s quite helpful.

But unfortunately, this doesn't really surprise me. There are a surprising number of Finder incompatibilities across macOS versions, which nobody appears to have documented or know about.

I’ve seen some of them, but there are undoubtedly more.

The project management team overseeing Finder dropped the ball, and hard, on at least few occasions since Snow Leopard’s Cocoa re-write.

For the most part, those flaws, inconsistencies, and UI flubs to have emerged, like the two you and I raise in this thread, are more marks of project management going a bit lax (especially relative to Apple’s lineage going straight back to 1984).

I’m going to be indelicate and put this one at the feet of… wait for it… Craig Federighi. None of this ever came up before he took over OS X/macOS from Serlet.

Here's another example: let's say that in High Sierra you create a DMG with an alias to the /Applications folder (or elsewhere), as is a relatively standard way to distribute apps. That DMG will mount in Snow Leopard, but the alias will be broken.

The only solution is probably need to do your "archival work" in the oldest version of Mac OS that you care about, or at least an older version that you've tested to work on the oldest version.

I also have a meticulously organized media collection, but as much as I'd like to have e.g. custom folder icons (like, I'm kind of jealous of yours), I avoid using any Apple-specific metadata explicitly because I simply can't trust that it will last.

If there’s anything to be said in favour of relying on the method I now realize is flawed in this cross-OS X/macOS manner, it’s that I don’t see this physical library being messed with beyond systems running Mojave (if in a later macOS build, connecting the external volume will be treated, softly, as read-only).

Also, contrary to my screen caps, I virtually never, ever have my own content laid out in Icon layout. I pretty much always do so in List format, as it’s easier on both my brain and my eyes o hand-type the first couple of letters of what I’m looking for and not having to, say, worry much over things bouncing around in a distracting manner (as might be the case for Icon view with no arrangement/ordering).

(I do use custom album art for songs/movies because that can be embedded into the media file itself.)

Oh, you can be sure I have that going on, as well.

(But probably to Apple’s chagrin, years ago I halted embedding multiple images within a media file, as I learnt this doesn’t necessary play nice with ID3 metadata standards, even as iTunes completely encourages it.)

 

[f54da]

Does it work properly the other way: resource fork icons created in leopard rendering on newer os versions? If you can dump the resource forks of both and compare, you could maybe try to see if there's an obvious change. Although I'm not sure how well the resource fork encoding of custom icons is documented.

The other way to do it if you really want to make things work on Leopard is probably make a SIMBL plugin that intercepts the icon view and provides its own image. You could look at the code-injection that "dropbox-type" services used to perform on Finder (e.g. dropbox used to draw its own sync status on top of the existing folder icon): https://stackoverflow.com/questions/1294335/how-to-write-os-x-finder-plugin

 

[joevt]

Maybe the resource fork icons used by folders (in the $'Icon\r' file) has the same compatibility issues as data fork icons used by volumes (in the '.VolumeIcon.icns' file).
https://gist.github.com/joevt/9fa524ebbef3db46842f14f33cf64ca5#file-volumeiconutil-sh-L113-L123
https://forums.macrumors.com/thread...an-early-intel-recently.2285317/post-30719875
https://forums.macrumors.com/thread...-show-up-in-option-boot.2412188/post-32754308

Can you post a sample of icons that are ok and not ok?

 

[B S Magnet]

Does it work properly the other way: resource fork icons created in leopard rendering on newer os versions?

Yes. It always works fine the other way: directories for which I created custom icons in Tiger and Leopard (mostly Leopard, but the project began on a Tiger box back in 2005) show up fine at any point thereafter (well, at least through Mojave and probably later, but in this home, we do not fuss with macOS builds which turn their noses at 32-bit applications, no ma’am!).

If you can dump the resource forks of both and compare, you could maybe try to see if there's an obvious change. Although I'm not sure how well the resource fork encoding of custom icons is documented.

At the moment, the only system I have (I think) Resourcerer installed is in storage. So for a dump, that will unfortunately need to wait.

I always operated with the assumption that custom icon handling in the resource fork fundamentally worked the same as all the way back in the Mac OS days, pre-OS X — except with OS X and Aqua, the scalable icon (including vector icons) was brought into the fold. It’s been decades since I tried looking at custom icons made in OS X (for same of simplicity, OS X on PPC) but within Finder of OS 9 or earlier, so I don‘t recall how icons handled with that level of backward compatibility.

The other way to do it if you really want to make things work on Leopard is probably make a SIMBL plugin that intercepts the icon view and provides its own image. You could look at the code-injection that "dropbox-type" services used to perform on Finder (e.g. dropbox used to draw its own sync status on top of the existing folder icon): https://stackoverflow.com/questions/1294335/how-to-write-os-x-finder-plugin

This is developer-level scrutiny which may be worth knowing or discovering for community knowledge (someone, anyone), but for now, it won’t be me.

Maybe the resource fork icons used by folders (in the $'Icon\r' file) has the same compatibility issues as data fork icons used by volumes (in the '.VolumeIcon.icns' file).
https://gist.github.com/joevt/9fa524ebbef3db46842f14f33cf64ca5#file-volumeiconutil-sh-L113-L123
https://forums.macrumors.com/thread...an-early-intel-recently.2285317/post-30719875
https://forums.macrumors.com/thread...-show-up-in-option-boot.2412188/post-32754308

Can you post a sample of icons that are ok and not ok?

I mean, if by this you mean for me to grab a couple of directories — one edition with a custom icon, created in Snow Leopard, which appears correctly in Leopard and another, created in HS or MJ, which does not appear in Leopard — I’ve gone ahead and included that in a zip file here. Screen cap below is what one will find (without nested media files) in the attached.

And unrelated: if anyone is looking at my above directories in the first post and wondering what my bizarre system is, well…

Spoiler: How my brain handles the curatorial work for the library (MLIS follks, don’t @ me!)

Let’s go with the start, and a title fitting for this forum.

At top level directory of the library, if I only have one title from an act, they appear right there. Any which have multiple titles are given a unique custom icon I create in a Photoshop template. Those are always in capital letters and tagged/labelled in red.

Lossless titles are marked in either purple or green, and lossy titles are marked in either orange or yellow. The distinctions of these are more for my own internal record keeping.

Sub-libraries (there are four of them for the most part) get brackets, all-caps, and labelled in grey.

(Titles collected and ripped from analogue sources for an old DJing format I ran around 1997–2003 get a blue label).

As for directory of a product title naming convention, using Macintosh Plus’s Floral Shoppe, I can see its provenance flag ([US]), its specific product number ([BOTR009]), and for this release, which was a re-master/re-issue of the original 2011 album, “printed” in 2014 (the original nested at the root). (Scare quotes here, because Vektroid.)

(There is also a spot, as needed, for denoting the source of the recording — handy when ripped from vinyl, and in what bit/sample rates, and whether it is a remastering, which gets the ([RM]) flag.)

It sounds confusing, but at least for my work (and since I’m the only person to look at it, lest I share a set of tracks with a friend), it’s quick and covers a lot of needed info. This comes in especially handy when, say, distinguishing different versions of Steely Dan’s Aja, which in my library is a bit overkill. (Look, it’s Aja, and also, I’m old.)

The more no one wanted to know. 🌠

 

[ojfd]

I did a bit of testing - made icons visible and moved data between the forks.
Rezilla could not open the "problematic" icon file using its template editor.
If opened as hex and compared to the other icon file, one can see the differences.

What's interesting is the mention of IHDR, PNG and sRGB in newer icon file.

I've copy&pasted the data to data fork and named the new files xxx.icns. They do open in Preview as icon files containing several icons of different sizes now. Older file has 5, newer one - 7. Older file has embedded Generic RGB ICC profile, newer file - sRGB ICC profile.
When I tried to open .icns file created from "problematic" icon file in old-ish Icon Composer, I got this alert, so this is probably the culprit.

Leopard's Preview also can not display icons in this .icns file.

Both .icns files attached for further examination.

Over and out.

Apple Icon Image format - Wikipedia

en.wikipedia.org

 

[Wowfunhappy]

The other way to do it if you really want to make things work on Leopard is probably make a SIMBL plugin that intercepts the icon view and provides its own image.

Fwiw, I don't think you'd necessarily have to reach for SIMBL, you could make a QuickLook plugin.

 

[joevt]

It appears that the icons that don't work are missing an it32 icon type.

I've updated my script at https://gist.github.com/joevt/9fa524ebbef3db46842f14f33cf64ca5 so that it can examine and fix folder icon files instead of just volume icon files.

I run it like this:

source "/Volumes/Apps/File Utilities/diskutil pdisk fdisk gpt/DiskUtil.sh"
source "/Volumes/Work/Programming/XcodeProjects/Icons/Scripts/VolumeIconUtil.sh"
checkiconcompatibility -f "/Volumes/Storage/Downloads/test icns directory"

It creates a VolumeIcons# folder in your home folder where it will do all the work (# is a unique number so that it doesn't modify an existing VolumeIcons folder).

It produces this output showing that the first icon needs to have an it32 added and it shows the command needed to replace that icon with the fixed icon that is created in the VolumeIcons folder.

#•••••/Volumes/Storage/Downloads/test icns directory/KANAKO WADA 「和田加奈子」
#it32 added
icontoresource "VolumeIcons34/KANAKO WADA 「和田加奈子」/KANAKO WADA 「和田加奈子」_after.icns" "/Volumes/Storage/Downloads/test icns directory/KANAKO WADA 「和田加奈子」/Icon"$'\r'""
#•••••/Volumes/Storage/Downloads/test icns directory/KENJI OMURA 「大村憲司」
# Found it32 in icon at /Volumes/Storage/Downloads/test icns directory/KENJI OMURA 「大村憲司」

I execute that icontoresource command to replace the offending icon. Then execute the checkiconcompatibility -f command again which created the next VolumeIcons folder and produces this output:

#•••••/Volumes/Storage/Downloads/test icns directory/KANAKO WADA 「和田加奈子」
# Found it32 in icon at /Volumes/Storage/Downloads/test icns directory/KANAKO WADA 「和田加奈子」
#•••••/Volumes/Storage/Downloads/test icns directory/KENJI OMURA 「大村憲司」
# Found it32 in icon at /Volumes/Storage/Downloads/test icns directory/KENJI OMURA 「大村憲司」

I've attached the results.

 

[B S Magnet]

I did a bit of testing - made icons visible and moved data between the forks.
Rezilla could not open the "problematic" icon file using its template editor.
If opened as hex and compared to the other icon file, one can see the differences.

What's interesting is the mention of IHDR, PNG and sRGB in newer icon file.

View attachment 2397660

I've copy&pasted the data to data fork and named the new files xxx.icns. They do open in Preview as icon files containing several icons of different sizes now. Older file has 5, newer one - 7. Older file has embedded Generic RGB ICC profile, newer file - sRGB ICC profile.
When I tried to open .icns file created from "problematic" icon file in old-ish Icon Composer, I got this alert, so this is probably the culprit.

View attachment 2397662

Leopard's Preview also can not display icons in this .icns file.

View attachment 2397670


Both .icns files attached for further examination.

Over and out.

Could you share on what OS you used Rezilla to look over the resource fork data?

Also, can I get a verify from anyone else that, when opening the directories in this zip, if opening in Snow Leopard or later, you could see both of them in Finder?

Apple Icon Image format - Wikipedia

en.wikipedia.org

Because this article has been heavily revised and focusses principally on macOS 11 and 10.15.7 — neither germane to this use-case nor instructive on features Apple added and transitioned toward after OS X 10.5.8 — I have browsed back through the article’s history to glean a bit more info.

First, the last snapshot before Lion showed up in mid-2011. Next, a snapshot from the late High Sierra era, just before Mojave.


What I’m seeing (and eyes on corrections where I may be off here):

What’s permitted in resource fork image data has a particular change for ic08 and ic09. This does bear relevance here because the custom icons I paste into the directory resource fork are 512x512, copy-pasted from Preview.app (which handles copy/paste with PNG).

Specifically, my workflow is:
A) use my Photoshop template to set hue and text contents;
B) copy merged layers;
C) paste merged into Preview;
D) copy/paste that one-layer Preview image into the directory icon in Finder (note: this Preview.app step assures I can double-check colour integrity remains consistent, as I found different colour space settings in Photoshop, when doing the step A & B production on another physical Mac, could alter how that icon rendered).

What I’m seeing with the 2011 wikipedia snapshot is ic09 in particular (which accommodates the 512x512 pixel size) allows for paste-ins as JPEG2000 format. What this, I think, may be telling me is OS X Snow Leopard-era, if copy/pasting from an image in Preview, regardless of raster format, to a directory/Finder item resource fork, will paste image data on the fly as a JPEG2000 raster image data for ic09 OSType/fourCC call-out (which, being the 512x512, Finder auto-generates the 256x256 ic08 and smaller variations).

In 2018, the wikipedia article notes how ic08 and ic09 read both JPEG2000 and PNG image data. What it doesn’t say, but can be sussed, is by High Sierra, image data pasted in the above workflow will always be pasted as PNG, not as JPEG2000.

The trouble here — again, inferred, not definitive — is ic08/ic09 image data pasted in PNG format don’t get handled correctly in Leopard because Leopard’s Finder was never coded to recognized PNG image data for a resource fork. (This may also be borne, in part, by mention of PNG resource info in the High Sierra/Mojave-created example I provided which you found, @ojfd — whereas the IHDR and sRGB non-image metadata probably would get ignored if Leopard’s Finder could parse PNG image data in the resource fork).

As mentioned earlier, Finder for OS X, from 10.0 through 10.5.8, was Carbonized.

During Snow Leopard development, appearing in full by Build 10A286, Apple re-wrote Finder from the ground, up, in Cocoa. That re-write, I think, came with project/developer consensus that, going forward, PNG would continue as a de facto image format used as an industry-wide standard, so they accommodated for it having Snow Leopard’s Finder be able to, novelly, parse PNG image data in a resource fork’s ic08 and ic09 OSType/fourCC locations.

Snow Leopard itself may have still pasted Preview image data as JPEG2000 (I don’t know for sure, but that Snow Leopard-created icons do show up fine in Leopard’s Finder would suggest so). But Snow Leopard’s Finder could parse both JPEG2000 and PNG image data; Leopard’s Finder could not.

That there isn’t explicit mention of PNG image data support in the wikipedia edit from the late Snow Leopard days is probably an unintended oversight (or, more precisely, was not generally known yet, publicly speaking, at that moment). Indeed, by late Lion, April 2012, the wikipedia article does add in that accommodation for either JPEG2000 or PNG.

Put another way: Snow Leopard and later were backward-compatible to parse image data in either file format; Leopard and earlier were not forward-compatible to parse image data if it wasn’t in JPEG2000 format.

Please check my deductive work here. Cheers!

 

[joevt]

I tested your original "test icns directory" and my modified/fixed/corrected version.
For 10.5.8, the original icon is invisible and the fixed icon is visible.
For 10.6.8, both original and modified icons are visible.

 

[B S Magnet]

It appears that the icons that don't work are missing an it32 icon type.

I've updated my script at https://gist.github.com/joevt/9fa524ebbef3db46842f14f33cf64ca5 so that it can examine and fix folder icon files instead of just volume icon files.

I run it like this:

source "/Volumes/Apps/File Utilities/diskutil pdisk fdisk gpt/DiskUtil.sh"
source "/Volumes/Work/Programming/XcodeProjects/Icons/Scripts/VolumeIconUtil.sh"
checkiconcompatibility -f "/Volumes/Storage/Downloads/test icns directory"

It creates a VolumeIcons# folder in your home folder where it will do all the work (# is a unique number so that it doesn't modify an existing VolumeIcons folder).

It produces this output showing that the first icon needs to have an it32 added and it shows the command needed to replace that icon with the fixed icon that is created in the VolumeIcons folder.

#•••••/Volumes/Storage/Downloads/test icns directory/KANAKO WADA 「和田加奈子」
#it32 added
icontoresource "VolumeIcons34/KANAKO WADA 「和田加奈子」/KANAKO WADA 「和田加奈子」_after.icns" "/Volumes/Storage/Downloads/test icns directory/KANAKO WADA 「和田加奈子」/Icon"$'\r'""
#•••••/Volumes/Storage/Downloads/test icns directory/KENJI OMURA 「大村憲司」
# Found it32 in icon at /Volumes/Storage/Downloads/test icns directory/KENJI OMURA 「大村憲司」

I execute that icontoresource command to replace the offending icon. Then execute the checkiconcompatibility -f command again which created the next VolumeIcons folder and produces this output:

#•••••/Volumes/Storage/Downloads/test icns directory/KANAKO WADA 「和田加奈子」
# Found it32 in icon at /Volumes/Storage/Downloads/test icns directory/KANAKO WADA 「和田加奈子」
#•••••/Volumes/Storage/Downloads/test icns directory/KENJI OMURA 「大村憲司」
# Found it32 in icon at /Volumes/Storage/Downloads/test icns directory/KENJI OMURA 「大村憲司」

I've attached the results.

Thanks for these uploads. The “test icons directory.zip” you uploaded were post-converted with your VolumeIconUtil.sh script, correct?

The hunch in my previous may be on the right track: that Leopard doesn’t know what to do with it32, which is not used until later and in tandem with PNG image data call-outs in ic08 and ic09.


First, the KENJI OMURA (I recommend his 1983 album, Gaijin Heaven, all in English and has a Steely Dan cover on it, but I’m going off-topic). This icon was prepared in Snow Leopard a little while back, before I took the custom icon workflow over to High Sierra and later.

In the text dump of the as-is KENJI OMURA, we see ic09 and ic08 as:

ic08..(I....jP  ........ftypjp2
ic09..YX....jP  ........ftypjp2

The filetype call-out is for JPEG2000 (“jp2”). This would have been generated in Snow Leopard as JPEG2000 image data. Leopard, thus, parsed it without issue (and because of this once-singular method for parsing resource fork image data, probably didn’t need additional info from an it32 OStype). Because that icon shows up in Leopard (and always has), this would not be too surprising.

Indeed, the first call-out of it32 in the “before” does not exist; the following call-out of it32, the line immediately preceding ic08, appears in both and are both empty.

In the text dump of the after-conversion you performed, we now see ic09 and ic08 as:

ic08..5..PNG........IHDR........
ic09..}..PNG........IHDR........

The filetype call-out is for PNG (with IHDR metadata embedded, I’m guessing). In this after-conversion, there are two different it32 call-out lines, and as you noted earlier, one mentions ic08 and ic09 explicitly:

it32....t8mk..@.ic08..5.ic09..}.

The KANAKO WADA directory follows a similar before/after, except that in the before, there the ic08 and ic09 have PNG call-outs, not JP2/JPEG2000. In the after-conversion, the it32 metadata, as with the after-conversion of KENJI OMURA, was inserted by your shell script. With that insertion, I am seeing the KANAKO WADA icon in Leopard (which is, frankly, confusing, unless for Leopard to parse PNG, it absolutely needs it32 to be filled, whereas with JP2/JPEG2000, it32 is not necessary).


Because I needed something visual around which to wrap my peameal-sized brain, I went ahead and dug out from box storage the Mac with Resourcerer on it. (It’s worth re-packing.) The Mac running Resourcerer is on Leopard; Resourcerer, minimally Carbonized from Mac OS, is from 2002.

I set up a grid. Left column are mine; right column are yours (top row was originally created in High Sierra; bottom row in Snow Leopard).

On both KENJI OMURA examples, it32 is filled with image data — despite the left one in JP2/JPEG2000, before-conversion, lacks that first it32 OStype data pointing to ic08 and ic09 (which seems needed for rendering PNG image data in those OStype locations).

So, if I grasp this correctly: Leopard must have it32 call-out info for ic08 and ic09 if the image data in these two is PNG format; it does not need it32 for parsing JP2/JPEG2000, as-is.

Does this sound correct?

---

p.s., Separately, on opening all four, Resourcerer warns the same:

I’m pasting solely because it calls out ic08 and ic09, the 256x256px and 512x512px image data, respectively.

ic07, ic13, ic04, ic14, ic05, and ic11, meanwhile, are the lines added in by post-SL Finder which includes data about iHDR and ARGB/dARGB (ASCII-encoded RGB colour space).

 

[joevt]

The “test icons directory.zip” you uploaded were post-converted with your VolumeIconUtil.sh script, correct?

Yes.

You can also see the before and after in the VolumeIcons## work folders.

The hunch in my previous may be on the right track: that Leopard doesn’t know what to do with it32, which is not used until later and in tandem with PNG image data call-outs in ic08 and ic09.

You got that backwards. Leopard doesn't know what to do with the new icon types in that file which are these:
ic12, ic07, ic13, ic08, ic04, ic14, ic09, ic05, ic11

it32 is the older icon type that the old Mac OS X version (Leopard) is looking for.

First, the KENJI OMURA (I recommend his 1983 album, Gaijin Heaven, all in English and has a Steely Dan cover on it, but I’m going off-topic). This icon was prepared in Snow Leopard a little while back, before I took the custom icon workflow over to High Sierra and later.

In the text dump of the as-is KENJI OMURA, we see ic09 and ic08 as:

ic08..(I....jP  ........ftypjp2
ic09..YX....jP  ........ftypjp2

The filetype call-out is for JPEG2000 (“jp2”). This would have been generated in Snow Leopard as JPEG2000 image data. Leopard, thus, parsed it without issue (and because of this once-singular method for parsing resource fork image data, probably didn’t need additional info from an it32 OStype). Because that icon shows up in Leopard (and always has), this would not be too surprising.

Indeed, the first call-out of it32 in the “before” does not exist; the following call-out of it32, the line immediately preceding ic08, appears in both and are both empty.

I'm not sure what you mean by not exist. The KENJI OMURA icon does have an it32. It is 0x1cce bytes in size and appears in Preview.app. Preview.app show these types: ic09, ic08, it32, il32, is32.
The it32 data is just an array of 128x128 24-pit pixels consisting of three compressed channels. It doesn't have a header like PNG or ARGB or jpeg or jpeg2000 icons do.

In the text dump of the after-conversion you performed, we now see ic09 and ic08 as:

ic08..5..PNG........IHDR........
ic09..}..PNG........IHDR........

The filetype call-out is for PNG (with IHDR metadata embedded, I’m guessing).

The icon conversion tools prefer PNG over jpeg2000 since jpeg2000 requires more effort and boot loaders like rEFIt, RefindPlus, Clover, or Open Core don't know how to display jpeg2000 (some of them might know how to display old jpeg icon types).
The PNG and IHDR text are part of the PNG format (just look at a PNG screenshot).

In this after-conversion, there are two different it32 call-out lines, and as you noted earlier, one mentions ic08 and ic09 explicitly:

it32....t8mk..@.ic08..5.ic09..}.

That data is part of the TOC (table of contents) which is an optional part of the icon (though some software may require it).
The icon conversion tools add the TOC if it's missing, and resort it. Each entry in the TOC is 8 bytes: icon type followed by icon size in bytes.
After the TOC is an entry for each icon. 4 bytes for type and 4 bytes for size (just like in the TOC), followed by the data for the icon. For png or jpeg or jpeg2000 icons, the data is just the same bytes as you would see in a png or jpeg or jpeg2000 file.

The KANAKO WADA directory follows a similar before/after, except that in the before, there the ic08 and ic09 have PNG call-outs, not JP2/JPEG2000. In the after-conversion, the it32 metadata, as with the after-conversion of KENJI OMURA, was inserted by your shell script. With that insertion, I am seeing the KANAKO WADA icon in Leopard (which is, frankly, confusing, unless for Leopard to parse PNG, it absolutely needs it32 to be filled, whereas with JP2/JPEG2000, it32 is not necessary).

In the KANAKO WADA case, the it32 is indeed created by the script/tools because it did not exist.
it32 is a different format than the icon types that allow PNG.

So, if I grasp this correctly: Leopard must have it32 call-out info for ic08 and ic09 if the image data in these two is PNG format; it does not need it32 for parsing JP2/JPEG2000, as-is.

Again, I think you are confusing the icon list in the TOC with the icon list after the TOC.
it32 is a separate icon from ic08 and ic09. You can see the icons and info by opening them in Preview.app (preferably on a modern Mac where Preview.app has that feature and shows the icon type of each icon).

p.s., Separately, on opening all four, Resourcerer warns the same:

View attachment 2397722

I’m pasting solely because it calls out ic08 and ic09, the 256x256px and 512x512px image data, respectively.

ic07, ic13, ic04, ic14, ic05, and ic11, meanwhile, are the lines added in by post-SL Finder which includes data about iHDR and ARGB/dARGB (ASCII-encoded RGB colour space).

Resorcerer is old and doesn't know about some types introduced later (probably ic08 or ic09).

Look at the .txt files created by my script.

The icon that works has this info:

00000000: 69636e73 0000e9ed                                                        icns....
00000008: 69733332 000001ca 93000324 44442587 000723a7 94616296 aa268400 021de084  is32.......$DD%...#..ab..&......
000001D2: 73386d6b 00000108 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff  s8mk............................
000002DA: 696c3332 00000494 cc000106 06970009 1c64a8cf dcdccfa9 671f9100 0d168df0  il32.............d......g.......
0000076E: 6c386d6b 00000408 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff  l8mk............................
00000B76: 69743332 00001cce 00000000 ff00ff00 ff00ff00 ff00ff00 ff00ff00 ff00ff00  it32............................
00002844: 74386d6b 00004008 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff  t8mk..@.........................
0000684C: 69633038 00002849 0000000c 6a502020 0d0a870a 00000014 66747970 6a703220  ic08..(I....jP  ........ftypjp2 
00009095: 69633039 00005958 0000000c 6a502020 0d0a870a 00000014 66747970 6a703220  ic09..YX....jP  ........ftypjp2

The icon that doesn't work has this info:

00000000: 69636e73 000223c8                                                        icns..#.
00000008: 69633132 00000e81 89504e47 0d0a1a0a 0000000d 49484452 00000040 00000040  ic12.....PNG........IHDR...@...@
00000E89: 69633037 00001f56 89504e47 0d0a1a0a 0000000d 49484452 00000080 00000080  ic07...V.PNG........IHDR........
00002DDF: 69633133 00004800 89504e47 0d0a1a0a 0000000d 49484452 00000100 00000100  ic13..H..PNG........IHDR........
000075DF: 69633038 00004800 89504e47 0d0a1a0a 0000000d 49484452 00000100 00000100  ic08..H..PNG........IHDR........
0000BDDF: 69633034 00000284 41524742 fffffbff 00dd81e0 00dd81e0 01dddf80 e03fddda  ic04....ARGB.................?..
0000C063: 69633134 0000aaf3 89504e47 0d0a1a0a 0000000d 49484452 00000200 00000200  ic14.....PNG........IHDR........
00016B56: 69633039 0000aaf3 89504e47 0d0a1a0a 0000000d 49484452 00000200 00000200  ic09.....PNG........IHDR........
00021649: 69633035 00000764 41524742 ffffffff ffffffff ffffffff ffffefff bedd00e1  ic05...dARGB....................
00021DAD: 69633131 0000061b 89504e47 0d0a1a0a 0000000d 49484452 00000020 00000020  ic11.....PNG........IHDR... ...

The old icon types known by Resorcerer are these (the second in the pair is for a 8-bit alpha mask):
is32 s8mk
il32 l8mk
it32 t8mk

Newer icon types are PNG or JPEG or ARGB which all include an alpha mask.
PNG: ic07, ic08, ic09, ic11, ic12, ic13, ic14
ARGB: ic04, ic05 (the A stands for alpha channel)
jpeg2000: ic08, ic09
I don't know which of these newer icon types Resorcerer understands (probably none - according to the error message it displays)

My script and tools add the old icon types (replacing ic04 and ic05 which are redundant in that case). They also add a TOC (table of contents).

PNG and IHDR are part of the PNG format (you can see that in a png screenshot file).

A table of contents looks like this:

00000008: 544f4320 00000068                                                        TOC ...h
 00000010: 69733332 0000027c 73386d6b 00000108 696c3332 00000750 6c386d6b 00000408  is32...|s8mk....il32...Pl8mk....
 00000030: 69743332 00002dbc 74386d6b 00004008 69633038 00004c51 69633039 0000af44  it32..-.t8mk..@.ic08..LQic09...D
 00000050: 69633131 000006b4 69633132 00000f1a 69633133 00004899 69633134 0000ab8c  ic11....ic12....ic13..H.ic14....

The indenting means that data is part of the TOC. The TOC in this case is 0x68 bytes in size (include the size of the TOC type and TOC size fields that precede the TOC data). I suppose I could have formatted the TOC in the text output so that there was only one icon per row to make it easier to understand.

 

[B S Magnet]

Yes.

You can also see the before and after in the VolumeIcons## work folders.

Thanks. Those text files within those work folders was where I was copy/pasting the ic08/ic09 call-outs in the previous reply.

I think it would help if I had a handy way to list out all the resource fork data, en toto. I don’t, and the only hex conversion I have handy is the :%!xxd tool in vi — and that only addresses the data file itself, not the resource fork or its TOC.

You got that backwards. Leopard doesn't know what to do with the new icon types in that file which are these:
ic12, ic07, ic13, ic08, ic04, ic14, ic09, ic05, ic11

OK. I understand. Until this, I thought it32 was a pointer or alias to another OStype call-out containing the actual image data. I didn’t know it was an image data resource. This is why I thought ic08 and ic09 were legacy.

That it32 was missing in the icon generated in High Sierra or later would make more sense behind why Leopard struggled. I guess Apple deprecated/removed it32 entirely at some unspecified point, and unless there is an it32 line in the resource fork’s TOC telling Leopard to look for the image data at ic08/ic09 and not at it32, it wouldn’t know what to do.

it32 is the older icon type that the old Mac OS X version (Leopard) is looking for.

The it32 data is just an array of 128x128 24-pit pixels consisting of three compressed channels. It doesn't have a header like PNG or ARGB or jpeg or jpeg2000 icons do.

I understand. I didn’t before, but I do now. Cheers.

I'm not sure what you mean by not exist. The KENJI OMURA icon does have an it32. It is 0x1cce bytes in size and appears in Preview.app.

What I mean is line/word 00000B76 in the original icon’s .txt dump reads:

00000B76: 69743332 00001cce 00000000 ff00ff00 ff00ff00 ff00ff00 ff00ff00 ff00ff00  it32............................

In the version your shell script updated, it32 appears twice — first, as a line your shell script wrote (in, I think the TOC):

00000030: 69743332 00001cce 74386d6b 00004008 69633038 00003595 69633039 00007dd0  it32....t8mk..@.ic08..5.ic09..}.

And another further down line/word 00000BBE, which is basically like 00000B76 in the original in what follows:

00000BBE: 69743332 00001cce 00000000 ff00ff00 ff00ff00 ff00ff00 ff00ff00 ff00ff00  it32............................

That data is part of the TOC (table of contents) which is an optional part of the icon (though some software may require it).
The icon conversion tools add the TOC if it's missing, and resort it. Each entry in the TOC is 8 bytes: icon type followed by icon size in bytes.
After the TOC is an entry for each icon. 4 bytes for type and 4 bytes for size (just like in the TOC), followed by the data for the icon. For png or jpeg or jpeg2000 icons, the data is just the same bytes as you would see in a png or jpeg or jpeg2000 file.


In the KANAKO WADA case, the it32 is indeed created by the script/tools because it did not exist.
it32 is a different format than the icon types that allow PNG.


Again, I think you are confusing the icon list in the TOC with the icon list after the TOC.
it32 is a separate icon from ic08 and ic09. You can see the icons and info by opening them in Preview.app (preferably on a modern Mac where Preview.app has that feature and shows the icon type of each icon).

Yah. I‘ve viewed .icns files previously in Preview.app.

Newer icon types are PNG or JPEG or ARGB which all include an alpha mask.
PNG: ic07, ic08, ic09, ic11, ic12, ic13, ic14
ARGB: ic04, ic05 (the A stands for alpha channel)

Thanks. I don’t know where I thought the A stood for ASCII.

jpeg2000: ic08, ic09

I don't know which of these newer icon types Resorcerer understands (probably none - according to the error message it displays)

The error message I shared was less important (and not an issue) than my just taking note of how it was not equipped to handle newer stuff.

My script and tools add the old icon types (replacing ic04 and ic05 which are redundant in that case). They also add a TOC (table of contents).

:nods:

PNG and IHDR are part of the PNG format (you can see that in a png screenshot file).

A table of contents looks like this:

00000008: 544f4320 00000068                                                        TOC ...h
 00000010: 69733332 0000027c 73386d6b 00000108 696c3332 00000750 6c386d6b 00000408  is32...|s8mk....il32...Pl8mk....
 00000030: 69743332 00002dbc 74386d6b 00004008 69633038 00004c51 69633039 0000af44  it32..-.t8mk..@.ic08..LQic09...D
 00000050: 69633131 000006b4 69633132 00000f1a 69633133 00004899 69633134 0000ab8c  ic11....ic12....ic13..H.ic14....

The indenting means that data is part of the TOC. The TOC in this case is 0x68 bytes in size (include the size of the TOC type and TOC size fields that precede the TOC data). I suppose I could have formatted the TOC in the text output so that there was only one icon per row to make it easier to understand.

That may have helped me to grasp this a little more quickly, yes.

 

[ojfd]

Could you share on what OS you used Rezilla to look over the resource fork data?

Yosemite 10.10.5

I think the compatibility with Leopard got broken (was removed) at the same time when x2 icons started to appear for Retina. That could have been around Mountain Lion.


Slightly OT.
The color management of icons (!) and embedded ICC profiles was new to me. Knowing that OS/ColorSync have to calculate every single pixel on the fly using 3x3 matrix present in ebbedded ICC profile before sending this data to display (primitively speaking), I'd say what a waste of computer resources.
I'm also wondering if it's also permitted to embed LUT based ICC profile, that could be several MB in size, btw., into .icns file and how much that would slow computer down, if done excessively.

@joevt , is there a mechanism to remove ICC profile from icns file? I've tried ColorSync's Remove applet, but it didn't work on icns file.

 

[f54da]

Wow excellent sleuthing!

>Knowing that OS/ColorSync have to calculate every single pixel on the fly using 3x3 matrix present in ebbedded ICC profile before sending this data to display

You should take a look at "WWDC 2009: Color Management in snow leopard" (you can find the video on IA) and also https://www.ricciadams.com/articles/osx-color-conversions/. There can actually be up to two conversions: from the color space of the icon resource to the color space of the window backbuffer, the other from the window backbuffer to the screen. In most cases the window backbuffer is the same color space as your screen though, so the second conversion is elided. In many cases things using quartz framework (imagekit, coreimage, etc.) should be doing gpu-drawing anyway so the additional transformation is negligible.

 

[joevt]

@joevt , is there a mechanism to remove ICC profile from icns file? I've tried ColorSync's Remove applet, but it didn't work on icns file.

Extract the jpeg or png from the icns, remove the icc, then put the jpeg or png back into the icns.
The dumpicns command in VolumeIconUtil.sh can do the extract if you use it like this:

dumpicns theicon.icns theicon
where the second parameter is a prefix used for the names of the png and jpeg files.

 

[ojfd]

Thanks, @joevt , but what I ment was getting rid of ICC profile without tearing icns file apart.