[File] [PATCH] of Magdir/images for OS/2 "CI" color icon variant (*.ico)
Jörg Jenderek
joerg.jen.der.ek at gmx.net
Wed Jun 19 13:49:01 UTC 2019
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
some days ago i handle some OS/2 color icons with file name extension
"ico". When i run file command version 5.37 all of these examples
are only described as "data".
More irritating is the fact that ico extension is used for MS
Windows icons. Many popular graphic tools like GIMP, ImageMagick or
XnView can open the Microsoft icon variant, but are not able to open
that OS/2 icon variant. Finally i find a command line converter tool
"deark" which is able to handle such icons by module os2bmp. So
information about inspected icon is shown by list and debug option
like in example command line:
deark -l -d3 os220.ico
So i add/change lines in Magdir/images. Some Information is found on
fileformats.archiveteam.org website.
In Magdir/image there exist an attempt to identify such examples by
line
#0 string CI PC color icon data
Maybe this pattern is too simple. So this line now becomes
0 string CI
And more additional test lines are needed to skip bad examples.
The size of header or file in bytes is stored in variable cbSize.
This is now shown by line like
>>2 ulelong x \b, cbSize %u
For inspected OS/2 color icons i found low values like 1Ah 4Eh 84Eh.
This can be used as additional test by jumping 4 bytes before end of
header/file and test for accessibility by line like
>>(2.l-4) ubelong x End of header is OK!
I do not use this, because accessing bytes beyond ranges is not a
official documented feature in file command.
The coordinates of the hotspot for icons like 0 1 16 20 32 33 63 64
are stored in 2 bytes variables xHotspot and yHotspot, which are now
shown by lines like
>>6 uleshort x \b, hotspot %ux
>>8 uleshort x \b%u
Nowadays icon can becomes big with dimensions, but in ancient times of
OS/2 systems with less RAM dimensions are low. The typical dimension
sizes are 32 40 64. But i also found higher dimensions 128 and 256
like in "DOOM!2 01.ICO". That also means in real examples hot spot
values are low (maybe maximal 256). So upper bits of short stored
value seems to be always null. So maybe skip bad examples by looking
for valid hot spot coordinates by additional test line like
>>6 ulelong&0xFE00FE00 =0
But i do not use this test.
After the first header comes the DIB header. In the first 4 bytes the
DIB header size is stored. This can be shown by line like
>>14 ulelong x \b, dib header size %u
For the considered color icons only 2 values 12 or 64 occur. So test
also for valid dib header sizes and start displaying by line
>14 ulelong <65 OS/2
Now afterwards show file name extension and a user defined mime type
by lines
!:mime image/x-os2-ico
!:ext ico
Afterwards split into 2 branches parts. First considered the OS/2 1.x
variant by checking for dib header size twelve and show specific icon
dimensions by lines
>>14 ulelong 12 1.x color icon
>>>18 uleshort x %u x
>>>20 uleshort/2 x %u
>>>24 uleshort >1 x %u
For OS/2 image width and height fields are unsigned integers whereas
for Microsoft Windows variants signed integers are used. The stored
height value was always the double of the real height. I found no
explanation about this item. So dived value by 2 before displaying
value. Typical values for number of bits per pixel (color depth) are
32 24 16 8 4 1, but i only found value one. So show this values only
if not one.
The other branch is for the OS/2 2.x variant which start with looking
for dib header size 64 and then display specific dimension by lines
>>14 ulelong 64 2.x color icon
>>>18 ulelong x %u x
>>>22 ulelong/2 x %u
>>>28 uleshort >1 x %u
The main difference is that width and height values are stored as 4
byte values instead by 2 bytes.
After applying the above mentioned modifications by patch
file-5.37-images-ico-CI.diff then unrecognized OS/2 color icons are
now recognized and described like
4DOS-B.ICO: OS/2 1.x color icon 32 x 32,
hotspot 1x31, cbSize 26, bits offset 106
Car 02.ICO: OS/2 1.x color icon 80 x 80,
hotspot 0x0, cbSize 26, bits offset 826
DOOM!2 01.ICO: OS/2 2.x color icon 128 x 128,
hotspot 64x64, cbSize 78, bits offset 1188
os22-16rle.ico: OS/2 2.x color icon 256 x 256,
Huffman 1D compression,
hotspot 128x128, cbSize 78, bits offset 228
os220.ico: OS/2 2.x color icon 40 x 40,
hotspot 20x20, cbSize 78, bits offset 228
Team_OS2.ICO: OS/2 1.x color icon 64 x 64,
hotspot 32x32, cbSize 26, bits offset 106
The_Ray.ICO: OS/2 1.x color icon 64 x 64,
hotspot 33x63, cbSize 26, bits offset 826
toolsfop.ico: OS/2 1.x color icon 32 x 32,
hotspot 16x16, cbSize 26, bits offset 58
I hope my diff file can be applied in future version of file utility.
There still exist more OS/2 icons and bitmap files which are not
recognized or misidentified by file command. I will handles such
things in future session.
With best wishes
Jörg Jenderek
- --
Jörg Jenderek
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iF0EARECAB0WIQS5/qNWKD4ASGOJGL+v8rHJQhrU1gUCXQo9RAAKCRCv8rHJQhrU
1nKtAKDM4+qFj3Dw9fKR/XlTZtusshS+SQCgkP5FCkPEKxK8xXDwgSqAlsQri7E=
=KROS
-----END PGP SIGNATURE-----
-------------- next part --------------
--- file-5.37/magic/Magdir/images.old 2019-04-19 00:42:27 +0000
+++ file-5.37/magic/Magdir/images 2019-06-19 13:37:42 +0000
@@ -607,2 +607,41 @@
#0 string CI PC color icon data
+0 string CI
+# test also for valid dib header sizes 12 or 64
+>14 ulelong <65 OS/2
+# test also for valid hotspot coordinates
+#>>6 ulelong&0xFE00FE00 =0 OS/2
+!:mime image/x-os2-ico
+!:ext ico
+>>14 ulelong 12 1.x color icon
+# image width and height fields are unsigned integers for OS/2
+>>>18 uleshort x %u x
+# stored height = 2 * real height
+>>>20 uleshort/2 x %u
+# number of bits per pixel (color depth). Typical 32 24 16 8 4 but only 1 found
+>>>24 uleshort >1 x %u
+# color planes; must be 1
+#>>>22 uleshort >1 \b, %u color planes
+>>14 ulelong 64 2.x color icon
+# image width and height
+>>>18 ulelong x %u x
+# stored height = 2 * real height
+>>>22 ulelong/2 x %u
+# number of bits per pixel (color depth). only 1 found
+>>>28 uleshort >1 x %u
+#>>>26 uleshort >1 \b, %u color planes
+# compression method: 0~no 3~Huffman 1D
+>>>30 ulelong 3 \b, Huffman 1D compression
+#>>>30 ulelong >0 \b, %u compression
+# xHotspot, yHotspot; coordinates of the hotspot like 0 1 16 20 32 33 63 64
+>>6 uleshort x \b, hotspot %ux
+>>8 uleshort x \b%u
+# cbSize; size of header or maybe file in bytes like 1Ah 4Eh 84Eh
+>>2 ulelong x \b, cbSize %u
+#>>2 ulelong x \b, cbSize %x
+# offBits; offset to bitmap data (pixel array) like E4h 3Ah 66h 6Ah 33Ah 4A4h
+>>10 ulelong x \b, bits offset %u
+#>>10 ulelong x \b, bits offset 0x%x
+#>>(10.l) ubequad !0 \b, bits 0x%16.16llx
+# dib header size: 12~Ch~OS/2 1.x 64~40h~OS/2 2.x
+#>>14 ulelong x \b, dib header size %u
#0 string CP PC color pointer image data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: file-5.37-images-ico-CI.diff.sig
Type: application/octet-stream
Size: 95 bytes
Desc: not available
URL: <https://mailman.astron.com/pipermail/file/attachments/20190619/8e6061f5/attachment.obj>
More information about the File
mailing list