Merge in changes from upstream? #2
Comments
|
It looks like @kornelski made this fork before we switched the SourceForge project from Subversion to Git, because the Git history is not linked between the two projects. I'm happy to do the work needed to merge the changes from the @kornelski fork into the SourceForge Git repository if @kornelski is happy with that. I am likely to need to adjust the commits slightly, since I noticed they include unrelated whitespace changes. I don't intend to move libicns from SourceForge to GitHub as switching hosting locations is too disruptive to users and redistributors and the two platforms have similar functionality. In case you @SlySven or @kornelski or others are interested in joining the SourceForge project, I'm happy to add you there. If either of you have a sample of the ic07 icon type produced by a macOS machine, that would be helpful for validating the related code changes. |
|
No problem. Feel free to take the code. |
|
What can be done about version numbers? The code in this repository has advanced them to 0.9.0 but the upstream has not had an increment for eight years or so and is still on 0.8.1. I suppose that if upstream went to a 0.9.1 after it gained the Unfortunately I cannot help with that particular icon type as I don't have a Mac - which is what lead me into this area in the first place. 😆 But anyhow, thanks to you both for talking to each other. |
|
Here is the firefox icon. I'm quite sure it contains the ic07 icon type. Let me know if this is what you were looking for. |
|
That is an interesting specimen, which indeed does seem to contain the stephen@Ripley:~/src/libicns$ icns2png -l ./firefox.icns
----------------------------------------------------
Reading icns family from ./firefox.icns...
Extracting icons from /firefox.icns...
Icon family size is 1021785 bytes (including 8 byte header)
Listing icon elements...
's8mk' 16x16 8-bit mask (256 bytes)
'is32' 16x16 32-bit icon (1024 bytes compressed to 642)
'l8mk' 32x32 8-bit mask (1024 bytes)
'il32' 32x32 32-bit icon (4096 bytes compressed to 2031)
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic07'
'ic07' 0x0 0-bit (18391 bytes)
'ic08' 256x256 32-bit icon (262144 bytes compressed to 50218)
'ic09' 512x512 32-bit icon (1048576 bytes compressed to 177374)
'ic10' 1024x1024 32-bit icon (4194304 bytes compressed to 550467)
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic11'
'ic11' 0x0 0-bit (2244 bytes)
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic12'
'ic12' 0x0 0-bit (6115 bytes)
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic13'
'ic13' 0x0 0-bit (56903 bytes)
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic14'
'ic14' 0x0 0-bit (156016 bytes)
12 elements total found in /firefox.icns.
stephen@Ripley:~/src/libicns$For reference on the other types I am referring to: https://en.wikipedia.org/wiki/Apple_Icon_Image_format#Icon_types . |
|
I've rebased, reworded, reformatted and merged the 128px ARGB (ic07)
support and the warning fix upstream to SourceForge. Thanks for the
Firefox icon, that helped me confirm the patch works. PS: I used the
git imerge tool to do the incremental rebase.
https://github.com/mhagger/git-imerge
Re-using the original PNG data is an interesting idea. Probably it is
faster than re-encoding, which I think is useful. The downside is that
it includes all the PNG metadata from the original file, which might
leak some things or might contain a lot of unneeded extra data. In
addition the way it got implemented doesn't fit well with the design of
the library and the command-line code. I think I would definitely
prefer a command-line option to decide on the re-use or not and a
separate function in the API that lets you re-use a PNG file. The
default on the command-line could be to re-use the PNG file.
Interesting, looking at WikiPedia, it seems libicns doesn't yet support
the icp4 icp5 icp6 ic04 ic05 icsB icsb icon types. I don't have any
samples of these formats nor any access to macOS devices, so if anyone
knows where to get samples of those, please let me know.
BTW, the ICNS entry on the File Formats wiki:
http://fileformats.archiveteam.org/wiki/ICNS
I'm happy to bump the version to 0.9.1 if that is wanted.
After the now merged patches, the PNG data reuse change and the version
increase, the two repositories are essentially equivalent as other
committers to upstream did basically the same changes as @kornelski did
for some of the commits.
Once the needed changes are finalised, I'll go have a look at the
distros and other potential sources of patches/fixes/bugs and then
finalise a new release.
…--
bye,
pabs
https://bonedaddy.net/pabs3/
|
|
Here is the Blender icon, which contains the ic04 and ic05 icon types you were looking for. I looked through a bunch of other app icons on my system but couldn't find any of the others. Is there a way to check programmatically if an icon contains a certain type? So far I just used macOS Preview to do the job. |
|
Interesting, the blender one also contains an "info" icon type, which
WikiPedia says is a binary plist, "Usage unknown". I guess I'll try to
take a look at adding something for extracting that.
If you have icns2png installed, the list option of it will tell you all
of the icon types, even the ones that icns2png doesn't know about, and
it will warn on stderr about icon types that it doesn't know about:
icns2png -l foo.icns > /dev/null
…--
bye,
pabs
https://bonedaddy.net/pabs3/
|
|
025_Receiver_Combo_Mac.icns.zip contains the icsB and icsb icon types. |
|
Added support for icp6 upstream since that was pretty easy. The icp4 and icp5 types don't seem to match what Wikipedia says. The icsB and icsb have no description on Wikipedia. The ic04 and ic05 types will need a new decoder to be written as there are no other types in this ARGB format. |
|
@Luflosi: any chance of some more samples of each type? Would be interesting to see if any of the other samples of icp4 and icp5 use PNG like Wikipedia suggests. For the others it would be useful to have a more than one sample for extra validation. |
|
Unfortunately, I couldn't find any more icons with the icp6 icon type. 025_Apps_Combo_Mac.icns is from the same application bundle as 025_Receiver_Combo_Mac.icns from my last comment, so it probably has the same properties. Are there any other types you're interested in? |
|
Thanks, downloaded.
Some containing the 'info' type might be useful to figure out when it
is used and what it contains.
Any containing the unknown 'name' type might be interesting in order to
figure out what it is.
…--
bye,
pabs
https://bonedaddy.net/pabs3/
|
|
😊 It is a bit embarrassing but I was going through my project's artwork repository and I found an stephen@Ripley:~/src/libicns$ icns2png -l ~/src/mudlet-dev/Mudlet/mudlet/src/icons/mudlet.icns
----------------------------------------------------
Reading icns family from /home/stephen/src/mudlet-dev/Mudlet/mudlet/src/icons/mudlet.icns...
Extracting icons from /mudlet.icns...
Icon family size is 914427 bytes (including 8 byte header)
Listing icon elements...
'TOC ' table of contents
'ic08' 256x256 32-bit icon (262144 bytes compressed to 54444)
'ic10' 1024x1024 32-bit icon (4194304 bytes compressed to 461443)
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic13'
'ic13' 0x0 0-bit (54444 bytes)
'ic09' 512x512 32-bit icon (1048576 bytes compressed to 156444)
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic12'
'ic12' 0x0 0-bit (6232 bytes)
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic07'
'ic07' 0x0 0-bit (18279 bytes)
'il32' 32x32 32-bit icon (4096 bytes compressed to 2280)
'l8mk' 32x32 8-bit mask (1024 bytes)
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic11'
'ic11' 0x0 0-bit (2231 bytes)
'is32' 16x16 32-bit icon (1024 bytes compressed to 698)
's8mk' 16x16 8-bit mask (256 bytes)
libicns: icns_get_image_info_for_type: Unable to parse icon type 'ic14'
'ic14' 0x0 0-bit (156444 bytes)
13 elements total found in /mudlet.icns.
stephen@Ripley:~/src/libicns$ From that Wikipedia page that works out to be:
Here is the file - zipped up so I can attach it here: |
|
Thanks. Are you sure that you are using the latest SourceForge version?
When I compile icns2png it works for me with mudlet.icns. You might
need to change your PATH or LD_LIBRARY_PATH to where you installed
icns2png or libicns. I'm installing to ~/opt and using these:
export LD_LIBRARY_PATH=$HOME/opt/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
export PATH=$HOME/opt/bin${PATH:+:$PATH}
…--
bye,
pabs
https://bonedaddy.net/pabs3/
|
|
🤦♂️ I still had some earlier system libraries around from my Distribution - having disposed of them the extraction went fine and I was able to recover all the icon files - however I could not round trip them and make a new stephen@Ripley:~/src/mudlet-dev/Mudlet/mudlet/src/icons/test$ icns2png -x ../mudlet.icns
----------------------------------------------------
Reading icns family from ../mudlet.icns...
Extracting icons from /mudlet.icns...
Saved 'ic08' element to mudlet_256x256x32.png.
Saved 'ic10' element to mudlet_1024x1024x32.png.
Saved 'ic13' element to mudlet_256x256x32.png.
Saved 'ic09' element to mudlet_512x512x32.png.
Saved 'ic12' element to mudlet_64x64x32.png.
Saved 'ic07' element to mudlet_128x128x32.png.
Saved 'il32' element to mudlet_32x32x32.png.
Saved 'ic11' element to mudlet_32x32x32.png.
Saved 'is32' element to mudlet_16x16x32.png.
Saved 'ic14' element to mudlet_512x512x32.png.
Extracted 10 images from /mudlet.icns.
stephen@Ripley:~/src/mudlet-dev/Mudlet/mudlet/src/icons/test$ ls -lart
total 592
drwxrwxr-x 3 stephen stephen 12288 Oct 14 02:05 ..
-rw-r--r-- 1 stephen stephen 351769 Oct 14 02:05 mudlet_1024x1024x32.png
-rw-r--r-- 1 stephen stephen 50662 Oct 14 02:05 mudlet_256x256x32.png
-rw-r--r-- 1 stephen stephen 6408 Oct 14 02:05 mudlet_64x64x32.png
-rw-r--r-- 1 stephen stephen 18127 Oct 14 02:05 mudlet_128x128x32.png
-rw-r--r-- 1 stephen stephen 2183 Oct 14 02:05 mudlet_32x32x32.png
-rw-r--r-- 1 stephen stephen 791 Oct 14 02:05 mudlet_16x16x32.png
drwxr-xr-x 2 stephen stephen 4096 Oct 14 02:05 .
-rw-r--r-- 1 stephen stephen 134249 Oct 14 02:05 mudlet_512x512x32.png
stephen@Ripley:~/src/mudlet-dev/Mudlet/mudlet/src/icons/test$ png2icns mudlet.icns ./*.png
Using icns type 'ic10' (ARGB) for './mudlet_1024x1024x32.png'
Using icns type 'ic07' (ARGB) for './mudlet_128x128x32.png'
Using icns type 'is32', mask 's8mk' for './mudlet_16x16x32.png'
Using icns type 'ic08' (ARGB) for './mudlet_256x256x32.png'
Using icns type 'il32', mask 'l8mk' for './mudlet_32x32x32.png'
Using icns type 'ic09' (ARGB) for './mudlet_512x512x32.png'
Using icns type 'ic12', mask '' for './mudlet_64x64x32.png'
libicns: icns_get_image_info_for_type: Unable to parse NULL type!
libicns: icns_init_image: icon width is 0!
libicns: icns_update_element_with_image_or_mask: Invalid icon type!
Saved icns file to mudlet.icnsIt looks like it is having difficulty with the stephen@Ripley:~/src/mudlet-dev/Mudlet/mudlet/src/icons/test$ icns2png -l ./mudlet.icns
----------------------------------------------------
Reading icns family from ./mudlet.icns...
Extracting icons from /mudlet.icns...
Icon family size is 565553 bytes (including 8 byte header)
Listing icon elements...
'is32' 16x16 32-bit icon (1024 bytes compressed to 698)
's8mk' 16x16 8-bit mask (256 bytes)
'il32' 32x32 32-bit icon (4096 bytes compressed to 2280)
'l8mk' 32x32 8-bit mask (1024 bytes)
'ic08' 256x256 32-bit icon (262144 bytes compressed to 50662)
'ic09' 512x512 32-bit icon (1048576 bytes compressed to 134249)
'ic12' 64x64 32-bit icon (16384 bytes compressed to 6408)
'ic07' 128x128 32-bit icon (65536 bytes compressed to 18127)
'ic10' 1024x1024 32-bit icon (4194304 bytes compressed to 351769)
9 elements total found in /mudlet.icns.So it HAS inserted the BUT IT SHOULD HAVE SAVED THE LATTER AS |
|
It looks like both icns2png and png2icns do not support the @2x
notation for HiDPI icons, only icnsutil does and that is about
converting between .iconset dirs containing PNGs and .icns files rather
than converting ICNS to/from loose PNG files.
I think the right approach here is for icnsutil to share some of its
code with icns2png and png2icns so they can both do the same thing.
Until that happens I suggest you use icnsutil (which is the libicns
clone of iconutil) instead of icns2png/png2icns. There are definitely
some bugs with it that need to be fixed though, but it does at least
work somewhat, despite the warnings/errors it emits.
icnsutil -c iconset mudlet.icns
icnsutil -c icns mudlet.iconset
Does anyone have a macOS system that includes iconutil? If so, please
download this zip file, unpack it including the directory tree and then
convert it to ICNS using the iconutil tool using this command-line and
attach the resulting ICNS file.
https://bonedaddy.net/pabs3/files/tmp/stuff/xyscan.iconset.zip
iconutil -c icns xyscan.iconset
PS: thanks to your comment I noticed the recent commits broke
icnsutil's icon type/name list by making them different sizes so I have
fixed that issue in the latest commit.
PPS: if anyone else wants to work on libicns that would be welcome, I
don't have a lot of time to spend on it.
…--
bye,
pabs
https://bonedaddy.net/pabs3/
|
|
xyscan.icns.zip |
|
Thanks for the samples, I haven't yet had time to work on the ones
above. I welcome help with the code and analysis of the samples as I
don't have a lot of time to work on libicns. I was just a distro
packager of it and got stuck with it after the original maintainer
became inactive. I'll try to prioritise making a release in time for
the Debian freeze.
…--
bye,
pabs
https://bonedaddy.net/pabs3/
|
|
I also meet the icon type 'ic04' 'ic05' 'info' Unable to parse , the icns is: https://github.com/PetoiCamp/OpenCat/blob/main/pyUI/resources/logo.icns icns2png -x pyUI/resources/logo.icns -o debian/Reading icns family from pyUI/resources/logo.icns... |
I note that the upstream project, now located at: https://icns.sourceforge.io/ rather than http://icns.sourceforge.net/ has not visibly gained a release since 0.8.1 but there has been developments since your commit-e261b0a2 which corresponds to its commit-91e2f813 such that it has less spelling errors, odd-line endings (check
icnsutils/png2icns.c!), supports OpenJPEG version 2 as well as 1, and has removed some obsolete SVN junk. Basically the code is cleaner however it does not have your support for 128px (ic07) icon types or for avoiding the need to re-encode the.pngimage data .Do you think there is any chance of bringing in the changes upstream - and/or passing back to them your enhancements?
The text was updated successfully, but these errors were encountered: