ico files - detecting bit depth

[robinesque]

I am trying to extract, from several .ico files, only the 32x32 pixel 8-bit element. Is there a way to do this with Imagemagick?
The order and the number of the elements in an icon file can vary.

Can Imagemagick detect the bit depth of an icon element? When I run "Identify" on any icon file, the bit depth for all elements is always reported as 8-bit, even if the .ico file contains 4-bit or 1-bit elements. This seems like a bug. IM Version is 6.6.3 Q16.

Another possible bug - when I run identify *.ico, I get, after the image info, this error message, once for every .ico file identified-
Magick: invalid colormap index `myIconName.ico' @ error/image.c/SyncImage/3951.

Thanks!

[magick]

We have a patch in ImageMagick 6.6.3-2 Beta to properly report the ICO image depth.

Post a URL to your `myIconName.ico' image so we can download it and reproduce the invalid colormap exception.

[robinesque]

Thanks for your response!

To reproduce the invalid colormap exception (IM Version is 6.6.3 Q16), you need multiple ico files with 8-bit scenes.
So download http://www.iconarchive.com/download/pix ... ry-win.zip
Extract all the .ico files to one directory
Run identify *.ico
At the end of the output, you will see these messages:
Magick: invalid colormap index `CranberryJuice.ico' @ error/image.c/SyncImage/3951.
Magick: invalid colormap index `Honey.ico' @ error/image.c/SyncImage/3951.
Magick: invalid colormap index `IceCream.ico' @ error/image.c/SyncImage/3951.
...
Magick: invalid colormap index `Sugar.ico' @ error/image.c/SyncImage/3951.
Magick: invalid colormap index `TomatoSoup.ico' @ error/image.c/SyncImage/3951.
Magick: invalid colormap index `Tuna.ico' @ error/image.c/SyncImage/3951.

Another question -
convert LOGO: -resize 32x32 -depth 1 ttt3.ico
results in a 32 bit ico.
Is this a bug or a limitation?

[magick]

We eliminated the bogus "invalid colormap index" message.

We'll take a look at the other problem in a day or two.

[robinesque]

Imagemagick version 6.6.3-2 is still reporting the bit depth of .ico scenes incorrectly.

To reproduce,
download & extract http://www.iconarchive.com/download/pix ... ry-win.zip
identify tuna.ico
Output:
tuna.ico[0] ICO 16x16 16x16+0+0 8-bit DirectClass 4.71KB 0.000u 0:00.000
tuna.ico[1] ICO 16x16 16x16+0+0 8-bit DirectClass 4.71KB 0.000u 0:00.015
tuna.ico[2] ICO 32x32 32x32+0+0 8-bit DirectClass 4.71KB 0.000u 0:00.031
tuna.ico[3] ICO 32x32 32x32+0+0 8-bit DirectClass 4.71KB 0.000u 0:00.046

Correct output would report one of the 16x16 scenes as having 4bits/pixel, and one of the 32x32 scenes as having 4 bits/pixel.

[Drarakel]

You can't get the overall bit depth of the actual file/palette from identify like that. You usually can get a palette size from "identify" (e.g. 16 colors, which could mean 4bit) and extended info from "identify -verbose".. But note that:
http://www.imagemagick.org/Usage/basics/#identify

* Normally IM reads in the image into its own data format, using various
image library APIs and delegate programs, before outputting the results it
sees using identify. That is "identify" analyzes the full image/data
content, not the specific file format the image is using for storage.

That being said, there seem to be still some small problems (with IM v6.6.3-2 Q16):

- With a simple "identify", the images within the ICOs are identified as DirectClass, not PseudoClass - so, there's also no palette size. (Is this normal?) I only get these sizes if I use identify on the single images within the ICOs:

Code: Select all

identify Tuna.ico[0]
identify Tuna.ico[1]
identify Tuna.ico[2]
identify Tuna.ico[3]

Tuna.ico[0]=>Tuna.ico ICO 16x16 16x16+0+0 8-bit PseudoClass 16c 4.71KB 0.000u 0:00.000
Tuna.ico[1]=>Tuna.ico[1] ICO 16x16 16x16+0+0 8-bit PseudoClass 256c 0.000u 0:00.000
Tuna.ico[2]=>Tuna.ico[2] ICO 32x32 32x32+0+0 8-bit PseudoClass 16c 0.000u 0:00.000
Tuna.ico[3]=>Tuna.ico[3] ICO 32x32 32x32+0+0 8-bit PseudoClass 256c 0.000u 0:00.000

- And I'm getting this "invalid colormap index" error, too:

Code: Select all

identify Tuna.ico

Tuna.ico[0] ICO 16x16 16x16+0+0 8-bit DirectClass 4.71KB 0.000u 0:00.000
Tuna.ico[1] ICO 16x16 16x16+0+0 8-bit DirectClass 4.71KB 0.000u 0:00.000
Tuna.ico[2] ICO 32x32 32x32+0+0 8-bit DirectClass 4.71KB 0.000u 0:00.000
Tuna.ico[3] ICO 32x32 32x32+0+0 8-bit DirectClass 4.71KB 0.000u 0:00.000
Magick: invalid colormap index `Tuna.ico' @ error/image.c/SyncImage/3936.

Should this be fixed in version 6.6.3-2 - or in the next version, 6.6.3-3 ?
(By the way: Is someone looking into the "invalid colormap index" bug in the PNG format? )

[robinesque]

Thank you, Drarakel! The "Palette size" seems like the right property to use.

Is there a way to use the "palette size" information to extract, from several .ico files, only the 32x32 pixel 256c element?

Is there a way to get "256c" or "16c" into the output filename? This command...

convert tuna.ico -set filename:mySpecs "%wx%h_%k" "tuna_%[filename:mySpecs].png"

...puts the number of unique colors into the filename. But I can't find the format characters to get the palette size into the filename.