Image viewer incorrectly previews Windows ico as garbage pixels if last texture size is 256
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
eog (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
ImageViewer version: 42.0
ImageMagick version (should not matter, ImageMagick seems to be doing its work correctly and it's in another package, but dropping just FYI):
$ convert --version
Version: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https:/
Copyright: (C) 1999-2021 ImageMagick Studio LLC
License: https:/
Features: Cipher DPC Modules OpenMP(4.5)
Delegates (built-in): bzlib djvu fftw fontconfig freetype heic jbig jng jp2 jpeg lcms lqr ltdl lzma openexr pangocairo png tiff webp wmf x xml zlib
I was following instructions on https:/
While instructions like:
$ convert icon_256.png -define icon:auto-
and
$ convert icon_256.png icon_128.png icon_64.png icon_32.png icon_16.png icon.ico
will generate a Windows .ico that can be previewed without issues in Image Viewer, although it will only show the 128x128 image, not the bigger 256x256 (not sure if it's a bug or by design).
If you swap sizes to put 256 at the end (you can also switch to ascending sizes but it's not necessary):
$ convert icon_256.png -define icon:auto-
and
$ convert icon_128.png icon_64.png icon_32.png icon_16.png icon_256.png icon.ico
will generate a proper .ico (textures are simply stored in a different order, as can be shown by extracting them with convert icon.icon extracted_icon.png) and looking at the generated files in order of numerical suffixes.
but when opening icon.ico, ImageViewer will show a 128x128 image with only the bottom part filled with garbage pixels (see screenshot).