Hello trid users,
some days ago i handled COFF objects. For Itanium IA64 CPUs this looks like
uncompressed DEGAS hi-res bitmaps described by
bitmap-pi3-degas.trid.xml. Inside the definition a web site about DEGAS
image is mentioned. That is expressed by line like:
<RefURL>
http://fileformats.archiveteam.org/wiki/DEGAS_image </RefURL>
On that web site samples and format specification are found. DEGAS hi-res
uncompressed bitmaps with PI3 file name extension are described by
bitmap-pi3-degas.trid.xml. This contains only one recognition pattern. That
is expressed by XML construct like:
<Bytes>0002</Bytes>
<Pos>0</Pos>
Unfortunately exact the same pattern is found inside
o-coff-ia64.trid.xml. That definition describes "Intel IA64 Common Object
File Format (COFF) object / library". The same pattern with some nil
patterns occur in fnt-windows-v2.trid.xml. That definition describes
"Windows Font resource (v2)". So all such COFF and font examples are
described as DEGAS bitmap (see appended output/trid-v.txt).
Even worse one bitmap like 640x400white.pi3 is identified first as "Windows
Font resource (v2)". GEM bitmap (v2) are described by bitmap-gem-v2.trid.xml
with pattern like:
<Pattern>
<Bytes>000200</Bytes>
<Pos>0</Pos>
</Pattern>
So two examples like sigirl1.pi3 and vanna5.pi3 are identified first as such
GEM bitmaps.
So i generate a new definition bitmap-pi3-degas-new.trid.xml by running
tridscan on 72 examples. This now contains three additional nil patterns
like:
<Pattern>
<Bytes>00</Bytes>
<Pos>5</Pos>
</Pattern>
<Pattern>
<Bytes>0000</Bytes>
<Pos>8</Pos>
</Pattern>
<Pattern>
<Bytes>00</Bytes>
<Pos>14</Pos>
</Pattern>
After some considerations i come to conclusion that this are probably
triggered by lucky circumstances and it is not reliable.
For comparison reason i also run file command utility on the samples. That
recognition is even worse. This identifies most samples as "Intel ia64 COFF
object file" (See appended output/file-5.39.txt).
The used reference contains links to other resources. The Multimedia Wiki
article about Degas contains file format description. At offset 2 the Atari
ST color palette is stored. This contains 16 color entries named
hardware_palette[16]. Each entry is stored as 16-bit word in big-endian
order. 61 examples have first color 0777h (See output/file.tmp). That is
9-bit white. 24 examples like HIGHRES.PI3 have 0000h as second color palette
index. That is black. That is expected for well behaved Degas high
resolution bitmaps, because that format has dimensions 640x400 and only 2
colors. For all pictures that i inspected with recoil viewer, the pictures
are black and white. I created some own examples (640x400black.pi3
640x400white.pi3 pal1.pi3 pal1wb.pi3 ) with the help of netpbm tool
pbmtopi3. Even when pictures like sigirl1.pi3 looks like containing gray
colors, the pictures contain only white and black dithered pixel clouds.
In theory 2 other colors like white and blue is possible, but recoil, deark
and Toms Editor software always interpret the pictures as black and white (
See pal1wb-blue-recoil.png pal1wb-blue-deark.png). 37 examples have 0700h as
second color. This means red. All these 61 examples are described by new
bitmap-pi3-degas-white.trid.xml with XML construct like:
<Pattern>
<Bytes>00020777</Bytes>
<Pos>0</Pos>
</Pattern>
I find 1 example like LEREDACT.PI3, which start with color 0FFFh. That is
also white but as 12 bit color. So i create
bitmap-pi3-degas-white12.trid.xml for such a case. The characteristic XML
construct look here like:
<Pattern>
<Bytes>00020FFF</Bytes>
<Pos>0</Pos>
</Pattern>
9 examples start with color 0001 in palette. That is nearly black with a
little bit of blue. 8 of these examples have 0000h as second color. That is
full black. One example like VELCRO.PI3 has 0700h as second color. That is
full red. So these 9 examples are described by
bitmap-pi3-degas-blueblack.trid.xml with XML construct like:
<Pattern>
<Bytes>00020001</Bytes>
<Pos>0</Pos>
</Pattern>
I also find one example like devgem7.pi3. That starts with color 0FCF. That
is nearly white or call it violet gray. That example is described by
bitmap-pi3-degas-greywhite.trid.xml. That has characteristic XML construct:
<Bytes>00020FCF</Bytes>
<Pos>0</Pos>
Instead of generic mime type application/octet-stream i used the one that is
mentioned on abydos software page about supported formats. That is now
expressed by line like:
<Mime>image/x-pi3</Mime>
According to documentation besides pi3 name extension also suh is
used. Unfortunately i myself have not found such examples, but now show this
information by line like:
<Ext>PI3/SUH</Ext>
There seems to exist another file format with suh extension, but that is
described by bitmap-suh-gfa-rt.trid.xml and start with a complete different
pattern expressed by XML construct like
<Pattern>
<Bytes>7375680D0A</Bytes>
<ASCII> s u h</ASCII>
<Pos>0</Pos>
</Pattern>
With the 4 new definitions with color palette now misidentification of some
Intel IA64 Common libraries like msvcrt.lib vanish. Also some Windows Font
resource (v2) are not misidentified any more as Degas bitmap.
Furthermore now also examples like 640x400white.pi3, pal1wb-inverted.pi3 and
sigirl1.pi3 are identified as DEGAS high resolution bitmaps first. (see
appended output/trid-v-new.txt).
Assuming that all other Degas bitmaps (*.pi3) behaves well ( color palette
start with white and black) and there exist only 3 exceptions, all PI3
bitmaps should be described with the 4 new definitions.
TrID definition, some examples and output are stored in archive pi3.zip. I
hope that my XML files can be used in future version of triddefs.
With best wishes
Jörg Jenderek
