Uses wrong geometry for one of multiple layers in .ico

[arand]

Source image (original has questionable copyright regarding stand-alone distribution, hence modified beyond recognition):
http://ubuntuone.com/p/nCG/

When trying to extract the largest 128x128 layer using:

Code: Select all

convert image.ico[3] image.png

It produces

Code: Select all

convert: No IDATs written into file `image.png' @ error/png.c/PNGErrorHandler/1455.

Digging deeper down:

Code: Select all

identify image.ico[3]
image.ico[3]=>image.ico[3] ICO 128x0 128x0+0+0 8-bit DirectClass 0.000u 0:00.000

...it seems that IM thinks that it's geometry is 128x0 and this is what is causing the kerfuffle.

This I can't help but suspect to be a bug.

All other layers[0-2] seems to work fine.

- arand

[glennrp]

I cannot reproduce the problem with IM-6.6.9-5:

• glenn.rp> q8identify | head -1
  Version: ImageMagick 6.6.9-5 2011-04-15 Q8 http://www.imagemagick.org
  glenn.rp> q8identify image.ico[3]
  image.ico[3]=>image.ico[3] ICO 128x128 128x128+0+0 32-bit DirectClass 0.000u 0:00.000
  glenn.rp> q16identify image.ico
  image.ico[0] ICO 16x16 16x16+0+0 32-bit DirectClass 90KB 0.000u 0:00.010
  image.ico[1] ICO 32x32 32x32+0+0 32-bit DirectClass 90KB 0.010u 0:00.020
  image.ico[2] ICO 64x64 64x64+0+0 32-bit DirectClass 90KB 0.010u 0:00.020
  image.ico[3] ICO 128x128 128x128+0+0 32-bit DirectClass 90KB 0.010u 0:00.020
  glenn.rp> q16identify image.ico[3]
  image.ico[3]=>image.ico[3] ICO 128x128 128x128+0+0 32-bit DirectClass 0.000u 0:00.000

[arand]

Yep, works on 6.6.9-5 for me too.
Fails on 6.6.0-4 which is the current on Debian (sid included).
So that's entirely a packaging matter.
Sorry for noise

- arand