[File] [PATCH] of Magdir/images VDC bitmap *.vbm *.bm versus BMP
Christos Zoulas
christos at zoulas.com
Wed May 12 16:35:52 UTC 2021
Committed, thanks!
christos
> On May 3, 2021, at 2:42 PM, Jörg Jenderek <joerg.jen.der.ek at gmx.net> wrote:
>
> Hello,
> some days ago my system with Windows 10 updates itself. When checking
> the system with ccleaner many file name associations are now broken.
> So i look for the reported filename extension.
>
> One file name extension is BM. So i run file command version 5.40 on
> such examples and related files and i get output like:
>
> toucan.bm: data
> coke_can.vbm: data
> oldmill.vbm: data
> winona2.vbm: data
> MARBLES-v3-.vbm: data
> MARBLES-v3-comment.vbm: data
> MARBLES-v3-rle.vbm: data
> MARBLES.PBM: Netpbm image data, size = 1152 x 813
> , rawbits, bitmap
> rpc-org-favicon.ico: PC bitmap, Windows 3.x format,
> 16 x 16 x 24,
> resolution 3780 x 3780 px/m,
> cbSize 822, bits offset 54
> politik-digital-favicon.ico: PC bitmap, Windows 3.x format,
> 15 x 16 x 8,
> resolution 2834 x 2834 px/m,
> cbSize 1336, bits offset 1078
> score9.bmp: PC bitmap, Windows 3.x format,
> 32 x 32 x 8,
> resolution 5333 x 5333 px/m,
> cbSize 54, bits offset 1078
> bubbles.bmp: PC bitmap, Windows 3.x format,
> 64 x 64 x 4, image size 2048,
> resolution 2835 x 2835 px/m,
> 4 important colors,
> cbSize 2118, bits offset 70
> pal8v4.bmp: PC bitmap, Windows 95/NT4
> and newer format,
> 127 x 64 x 8
> rgb32-xbgr.bmp: PC bitmap, Windows 98/2000
> and newer format,
> 127 x 64 x 32
> rgb32h52.bmp: PC bitmap, Adobe Photoshop,
> 127 x 64 x 32
> rgba32h56.bmp: PC bitmap, Adobe Photoshop
> with alpha channel mask,
> 127 x 64 x 32
> RTDICE.BMP: PC bitmap, OS/2 1.x format,
> 640 x 442
> strawb.bmp: PC bitmap, OS/2 1.x format,
> 32 x 32
> diamondb.bmp: PC bitmap, OS/2 2.x format,
> 82 x 112 x 4,
> hotspot 41x56,
> cbSize 78, bits offset 142
> JUR_OS2.BMP: PC bitmap, OS/2 2.x format,
> 640 x 400 x 4,
> cbSize 78, bits offset 94
> pal8os2v2-16.bmp: data
> MEMSIZE-BMP.bga: OS/2 graphic array, cbSize 40; 1st
> PC bitmap, OS/2 1.x format,
> 64 x 64
> IO.EPA: data
> simpsons.epa: Award BIOS Logo, 136 x 126
> awardbmp.bmp: Award BIOS bitmap, 136 x 84
>
> With --extension option i get output like:
> toucan.bm: ???
> coke_can.vbm: ???
> oldmill.vbm: ???
> winona2.vbm: ???
> MARBLES-v3-.vbm: ???
> MARBLES-v3-comment.vbm: ???
> MARBLES-v3-rle.vbm: ???
> MARBLES.PBM: pbm
> rpc-org-favicon.ico: bmp
> politik-digital-favicon.ico: bmp
> score9.bmp: bmp
> bubbles.bmp: bmp
> pal8v4.bmp: ???
> rgb32-xbgr.bmp: ???
> rgb32h52.bmp: bmp
> rgba32h56.bmp: bmp
> RTDICE.BMP: ???
> strawb.bmp: ???
> diamondb.bmp: bmp
> JUR_OS2.BMP: bmp
> pal8os2v2-16.bmp: ???
> MEMSIZE-BMP.bga: bmp/bga
> IO.EPA: ???
> simpsons.epa: ???
> awardbmp.bmp: ???
>
>
> For comparison reason i run the file format identification utility
> TrID ( See https://mark0.net/soft-trid-e.html). This describes these
> examples as "VDC BitMap (v2)" or "VDC BitMap (v3)" by definitions
> bitmap-vbm.trid.xml and bitmap-vbm-v3.trid.xml (See appended
> bm_trid-v.txt.gz ). It also displays used file name extensions "BM"
> and "VBM" and a related URL.
>
> That information about this bitmap file format can be found on file
> formats archive team web site. This is now expressed by additional
> remark lines before BMP section inside Magdir/images like:
>
> # URL: http://fileformats.archiveteam.org/wiki/VBM_(VDC_BitMap)
> # Reference: http://csbruce.com/cbm/postings/csc19950906-1.txt
>
> According to documentation such bitmaps begin with a signature of 'B'
> 'M' 0xCB, followed by a version byte 2 or 3. This is similar to the
> unrelated Windows BMP format.
>
> Therefore i put displaying part inside a sub routine bitmap-vbm to
> check for VDC bitmap and then display image information like version
> and dimensions. This looks like:
> 0 name bitmap-vbm
> >2 ubyte 0xCB VDC bitmap
> !:mime image/x-commodore-vbm
> !:ext bm/vbm
> >>3 ubyte x \b, version %u
> >>4 ubeshort x \b, %u
> >>6 ubeshort x x %u
>
> The version 3 variant have some more fields after starting header.
> That information is shown by lines like:
> >>3 ubyte =3
> >>>8 ubyte 0 \b, uncompressed
> >>>8 ubyte 1 \b, RLE-compressed
> #>>>14 short >0 \b, reserved 0x%x
> >>>16 pstring/H >0 \b, comment "%s"
>
>
> On the documentation site some download links for more examples are
> mentioned. Unfortunately all mentioned examples are version 2
> variants. On the web site a converting tool pbmtovbm is mentioned.
> Luckily i was able to generate some version 3 variants like
> MARBLES-v3-rle.vbm by this tool from Netpbm PBM images as sources.
> The Retro Computer Image Library (RECOIL) was able to display and
> convert such bitmaps; at least for version 2 variants. This can be
> can be done by a shell line like:
> recoil2png -o tmp.png coke_can.vbm; file tmp.png
>
> In current Magdir/images the identification of Windows and OS/2 BMP
> bitmaps happens by lines like
> 0 string BM
> >14 leshort 12 PC bitmap, OS/2 1.x format
> !:mime image/x-ms-bmp
> And later the value of variable cbSize is also displayed. That is
> often size of bitmap file or sometimes the size of the bitmap header.
> This was done by lines like:
> >>2 ulelong x \b, cbSize %u
> #>>2 ulelong x \b, cbSize 0x%x
> This information is not shown for all variants. So i add such lines
> for other variants. Furthermore with --extension option sometimes ???
> instead bmp is displayed. So i add more lines like:
> !:ext bmp
> In current magic a user defined mime type "image/x-ms-bmp" is used.
> Now at IANA by RFC7903 an "official" mime type is registered. This is
> now expressed by a changed line like:
> !:mime image/x-ms-bmp
>
> This above fragment is replaced by the following lines:
> 0 string BM
> >2 beshort 0xCB02
> >>6 short =0
> >>>0 use bitmap-bmp
> >>6 short !0
> >>>0 use bitmap-vmp
> >2 beshort 0xCB03
> >>14 short =0
> >>>0 use bitmap-vbm
> >>14 short !0
> >>>0 use bitmap-bmp
> >2 default x
> >>0 use bitmap-bmp
> 0 name bitmap-bmp
> >14 leshort 12 PC bitmap, OS/2 1.x format
> !:mime image/bmp
> !:ext bmp
>
> If 2 bytes at offset two are unequal of CB02h or CB03h then image is
> definitely a BMP image. This is done by "default" branch calling new
> sub routine bitmap-bmp.
>
> If 2 bytes at offset are equal CB03h it can by lucky circumstances
> also be a BMP example with cbSize=????03CBh=971. So i also look at
> short value at offset 14. For BMP this is low part of the DIB header
> size, which has lowest value 12. For VDC bitmap this value is
> described as reserved with value 0. So for value 0 call sub routine
> bitmap-vbm and for non zero value call sub routine bitmap-bmp.
>
> If 2 bytes at offset are equal CB02h it can by lucky circumstances
> also be a BMP example with cbSize=????02CBh=715. So i also look at
> short value at offset 6. For VDC bitmap this is the height ( positive
> value) of the image. So for zero value call sub routine bitmap-bmp.
> For BMP this is x coordinate of the hotspot. For windows variants
> this seems to be always zero. Non zero value only occur for OS/2
> variants. I hope that no such exotic OS/2 example exist.
>
> As second test the stored DIB header size at offset 14 is checked
> before displaying information. This is stored as 4 byte little endian
> integer and not 2 byte integer. So i also correct this minor not
> hurting error.
>
> According to documentation eight or maybe ten variants exist. The
> highest mentioned value was 124 for Windows 98/2000 and newer format
> variant. But in Magdir/images there exist a section starting with
> lines like:
> >14 leshort 128 PC bitmap, Windows NT/2000 format
> I looked back and see that this entry exist at least since version
> 4.26 dated about August 2008. So i delete that wrong entry.
>
> On the other hand some OS/2 BMP 2.0 variants are missing. The variant
> with DIB header size value 64 is recognized and was described by
> fragment starting with line like:
> >14 leshort 64 PC bitmap, OS/2 2.x format
> According to Wikipedia there exist a variant with a DIB header size
> of 16 like in example pal8os2v2-16.bmp of Jason Summers BMP Suite. In
> this variant the header contains only the first 16 bytes of
> 64-variant and the remaining bytes are assumed to be zero values. So
> i add like for 64-variant line starting with line like:
> >14 ulelong 16 PC bitmap, OS/2 2.x format (DIB header size=16)
>
> According to file formats archive team web site there exist variants
> with DIB header size 48 and 24. Unfortunately i do not found such
> examples, but i add lines to recognize such examples like:
> >14 ulelong 48 PC bitmap, OS/2 2.x format (DIB header size=48)
> >14 ulelong 24 PC bitmap, OS/2 2.x format (DIB header size=24)
>
> When inspecting the cache of an old opera web browser, i found
> examples where file name is ending with favicon.ico. A few of these
> examples are described as "PC bitmap, Windows 3.x format". Such
> examples still can be found under links like:
> https://www.politi-kdigital.de/favicon.ico
> http://forum.rpc1.org/favicon.ico
> Information about such favourite icons (Favicon) is found for example
> on Wikipedia. Typical format for such favicon is the Window ICO
> format with image/x-icon MIME type. Unfortunately and not documented
> there is that some sites use BMP file format and use the proposed
> name favicon.ico. According to Wikipedia such favicon are samle with
> dimensions like:
> 16×16, 32×32, 48×48, or 64×64
> Most BMP examples are matched by first case and a few are matched by
> second case, but i also found a few samples with dimensions like:
> 14x15 15x16 16x14
>
> In current magic file after BMP files with RLE file name extensions
> bitmaps (not RLE compressed and not 320x400 dimension) are handled by
> fragment like:
> !:ext bmp/rle
> >>>>30 default x x
> !:ext bmp
>
> This now becomes like
> !:ext bmp/rle
> >>>>30 default x
> >>>>>18 ulequad&0xffFFffC0ffFFffC0 =0 x
> !:ext bmp/ico
> >>>>>18 default x x
> !:ext bmp
>
> So for bitmaps with "small dimensions" like
> politik-digital-favicon.ico and rpc-org-favicon.ico with --extension
> option of file command "bmp/ico" is shown as file name extensions,
> whereas for bitmaps with "big" dimensions ( > 64) only "bmp" is shown
> as file name extension.
>
> The file name extension "bmp" is also used for some Award BIOS
> bitmaps instead of "epa". So i check such examples. These are
> recognized by file command, but with --extension option only ??? is
> displayed.
>
> For comparison reason i run the file format identification utility
> TrID . This describes these examples like awardbmp.bmp as "Award BIOS
> logo bitmap (v2)" with mime type "image/x-award-bioslogo2" by
> definition bitmap-awbm.trid.xml. It also displays used file name
> extensions "BMP" and "EPA" and a related URL.
> So i add at right position inside Magdir/images lines like:
> !:ext epa/bmp
>
> That information about this bitmap file format can be found on file
> formats archive team web site. This is now expressed by additional
> remark lines before DIB/BMP section inside Magdir/images like:
> # URL: http://fileformats.archiveteam.org/wiki/Award_BIOS_logo
>
> So the following fragment
> 0 string AWBM
> >4 leshort <1981 Award BIOS bitmap
> !:mime image/x-award-bmp
> is replaced by the following lines
> 0 string AWBM
> >4 leshort <1981 Award BIOS Logo, version 2
> !:mime image/x-award-bioslogo2
> !:ext epa/bmp
>
> Furthermore one variant like in example IO.EPA is described by file
> command as "data". With the help of the RECOLIL tool i was able to
> verify that it is an AWARD BIOS logo. This can be can be done by a
> shell line like:
> recoil2png -o tmp.png IO.EPA; file tmp.png
> For comparison reason i run the file format identification utility
> TrID . This describes these examples as "Award BIOS logo bitmap
> (128x126)" with mime type "image/x-award-bioslogo" by definition
> bitmap-awbm-v1x1009.trid.xml.. It also displays used file name
> extensions and the related URL. So i add at right position inside
> Magdir/images in same manner as for other Award BIOS logo lines like:
> 0 string \x10\x09 Award BIOS Logo, 128 x 126
> !:mime image/x-award-bioslogo
> !:ext epa
>
> The correct logo looking and dimensions can be verified by mentioned
> graphic tool XnView or the command line tool by shell line like:
> nconvert -fullinfo *.EPA
>
> After applying the above mentioned modifications by patches
> file-5.40-images-epa.diff file-5.40-images-vbm.diff
> file-5.40-images-dib128.diff file-5.40-images-dib108.diff
> file-5.40-images-dib40.diff file-5.40-images-dib56.diff
> file-5.40-images-dib52.diff file-5.40-images-dib16-64.diff
> file-5.40-images-dib12.diff ( or all summerized by
> file-5.40-images-BMp-ALL.diff ) then such bitmaps are now described like:
>
> toucan.bm: VDC bitmap, version 2, 640 x 480
> coke_can.vbm: VDC bitmap, version 2, 227 x 425
> oldmill.vbm: VDC bitmap, version 2, 1024 x 768
> winona2.vbm: VDC bitmap, version 2, 385 x 480
> MARBLES-v3-.vbm: VDC bitmap, version 3, 1152 x 813,
> uncompressed
> MARBLES-v3-comment.vbm: VDC bitmap, version 3, 1152 x 813,
> uncompressed,
> comment "This is a comment!"
> MARBLES-v3-rle.vbm: VDC bitmap, version 3, 1152 x 813,
> RLE-compressed
> MARBLES.PBM: Netpbm image data, size = 1152 x 813
> , rawbits, bitmap
> rpc-org-favicon.ico: PC bitmap, Windows 3.x format,
> 16 x 16 x 24,
> resolution 3780 x 3780 px/m,
> cbSize 822, bits offset 54
> politik-digital-favicon.ico: PC bitmap, Windows 3.x format,
> 15 x 16 x 8,
> resolution 2834 x 2834 px/m,
> cbSize 1336, bits offset 1078
> score9.bmp: PC bitmap, Windows 3.x format,
> 32 x 32 x 8,
> resolution 5333 x 5333 px/m,
> cbSize 54, bits offset 1078
> bubbles.bmp: PC bitmap, Windows 3.x format,
> 64 x 64 x 4, image size 2048,
> resolution 2835 x 2835 px/m,
> 4 important colors,
> cbSize 2118, bits offset 70
> pal8v4.bmp: PC bitmap, Windows 95/NT4
> and newer format,
> 127 x 64 x 8
> , cbSize 9322, bits offset 1130
> rgb32-xbgr.bmp: PC bitmap, Windows 98/2000
> and newer format,
> 127 x 64 x 32,
> cbSize 32650, bits offset 138
> rgb32h52.bmp: PC bitmap, Adobe Photoshop,
> 127 x 64 x 32
> , cbSize 32578, bits offset 66
> rgba32h56.bmp: PC bitmap, Adobe Photoshop
> with alpha channel mask,
> 127 x 64 x 32
> , cbSize 32582, bits offset 70
> RTDICE.BMP: PC bitmap, OS/2 1.x format,
> 640 x 442 x 4
> , hotspot 1087x35016
> , cbSize 141512, bits offset 72
> strawb.bmp: PC bitmap, OS/2 1.x format,
> 32 x 32 x 8
> , cbSize 26, bits offset 794
> diamondb.bmp: PC bitmap, OS/2 2.x format,
> 82 x 112 x 4,
> hotspot 41x56,
> cbSize 78, bits offset 142
> JUR_OS2.BMP: PC bitmap, OS/2 2.x format,
> 640 x 400 x 4,
> cbSize 78, bits offset 94
> pal8os2v2-16.bmp: PC bitmap, OS/2 2.x format
> (DIB header size=16),
> 127 x 64 x 8,
> cbSize 9246, bits offset 1054
> MEMSIZE-BMP.bga: OS/2 graphic array, cbSize 40; 1st
> PC bitmap, OS/2 1.x format,
> 64 x 64 x 4
> , hotspot 32x32
> , cbSize 26, bits offset 88
> IO.EPA: Award BIOS Logo, 128 x 126
> simpsons.epa: Award BIOS Logo, 136 x 126
> awardbmp.bmp: Award BIOS Logo, version 2, 136 x 84
>
>
> And with --extension option now used file name extensions are shown like:
> toucan.bm: bm/vbm
> coke_can.vbm: bm/vbm
> oldmill.vbm: bm/vbm
> winona2.vbm: bm/vbm
> MARBLES-v3-.vbm: bm/vbm
> MARBLES-v3-comment.vbm: bm/vbm
> MARBLES-v3-rle.vbm: bm/vbm
> MARBLES.PBM: pbm
> rpc-org-favicon.ico: bmp/ico
> politik-digital-favicon.ico: bmp/ico
> score9.bmp: bmp/ico
> bubbles.bmp: bmp
> pal8v4.bmp: bmp
> rgb32-xbgr.bmp: bmp
> rgb32h52.bmp: bmp
> rgba32h56.bmp: bmp
> RTDICE.BMP: bmp
> strawb.bmp: bmp
> diamondb.bmp: bmp
> JUR_OS2.BMP: bmp
> pal8os2v2-16.bmp: bmp
> MEMSIZE-BMP.bga: bmp/bga
> IO.EPA: epa
> simpsons.epa: epa
> awardbmp.bmp: epa/bmp
>
> I hope my diff files can be applied in future version of file utility.
>
> With best wishes
> Jörg Jenderek
> --
> Jörg Jenderek
>
>
>
>
>
>
>
>
>
>
>
>
>
> <bm_trid-v.txt.gz><file-5_40-images-epa_diff.DEFANGED-13741><file-5_40-images-vbm_diff.DEFANGED-13742><file-5_40-images-dib128_diff.DEFANGED-13743><file-5_40-images-dib108_diff.DEFANGED-13744><file-5_40-images-dib40_diff.DEFANGED-13745><file-5_40-images-dib56_diff.DEFANGED-13746><file-5_40-images-dib52_diff.DEFANGED-13747><file-5_40-images-dib16-64_diff.DEFANGED-13748><file-5_40-images-dib12_diff.DEFANGED-13749><file-5_40-images-BMp-ALL_diff.DEFANGED-13750><file-5_40-images-epa_diff_sig.DEFANGED-13751><file-5_40-images-vbm_diff_sig.DEFANGED-13752><file-5_40-images-dib128_diff_sig.DEFANGED-13753><file-5_40-images-dib124_diff_sig.DEFANGED-13754><file-5_40-images-dib108_diff_sig.DEFANGED-13755><file-5_40-images-dib40_diff_sig.DEFANGED-13756><file-5_40-images-dib56_diff_sig.DEFANGED-13757><file-5_40-images-dib52_diff_sig.DEFANGED-13758><file-5_40-images-dib16-64_diff_sig.DEFANGED-13759><file-5_40-images-dib12_diff_sig.DEFANGED-13760><file-5_40-images-BMp-ALL_diff_sig.DEFANGED-13761>--
> File mailing list
> File at astron.com
> https://mailman.astron.com/mailman/listinfo/file
> <sanitizer.log>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 235 bytes
Desc: Message signed with OpenPGP
URL: <https://mailman.astron.com/pipermail/file/attachments/20210512/60d5ec72/attachment.asc>
More information about the File
mailing list