Hello,
when handling some Microsoft color palettes (*.pal) trid describes only three
inspected examples like morewi~1.pal as "Microsoft (color) Palette" by
pal.trid.xml, whereas the "Generic RIFF container" by riff.trid.xml is always
a match but a little too general ( see appended output/trid-old.txt ).
There does not exist an official documentation on Microsoft site or complete
specification for such files. Most official matching documentation found was
"Multimedia Programming Interface and Data Specifications 1.0" older than 1991
found for example at www-mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Docs/
as "riffmci.pdf". But this document is not full complete, handles also other
riff based files and also is difficult to understand. So i choose an other
reference URL by line:
<RefURL>
http://worms2d.info/Palette_file</RefURL>
On systems i found no file type registration for such PAL files. So best type
matching riff files is expressed by line:
<Mime>application/x-riff</Mime>
At offset 22 number of palette color entries is stored as short little endian
"palNumEntries". In most cases the palette contains 256 (0100h) colors ( see
output/file.txt). That was last part in pattern
<Pattern>
<Bytes>524946461004000050414C20646174610404000000030001</Bytes>
<ASCII> R I F F . . . . P A L d a t a</ASCII>
<Pos>0</Pos>
</Pattern>
But also found on windows 98 CD travel~1.pal with 176 colors. With help of
Cyotek Color Palette Editor version 1.6.0.258 i was able to create also
palette with only 1 color like yellow.pal and also example with more colors
like col300.pal. Maybe not really usable but probably allowed by
specifications.
Before number of colors at offset 20 "palVersion" is stored as short value.
According to documentations it specifies the Windows version number for the
structure. Not clearly described but seems to be introduced in Windows 3.0 and
apparently never changed in later Window OS. So this value is constant 0x0300.
Before at offset 16 data chunk size is stored as long value. The size should be
calculated by formula:
palVersion + palNumEntries + palPalEntry =
2 + 2 + palPalEntry
where palPalEntry is the raw palette or color vector which size is calculated
by formula:
number of color entries * 4
So for palette with 256 colors we expect
2 + 2 + 256 * 4 = 4 + 1024 = 1028 = 00000404h
That is found in original pattern before palVersion pattern part. But data
size varies if number of colors is different. Assuming unsigned values with
upper limit for colors is below 10000h, we got 00040000h as upper limit for
data chunk size or in other words upper byte of this size is always 0. So
data chunk size and palVersion are now expressed by XML construct:
<Pattern>
<Bytes>000003</Bytes>
<Pos>19</Pos>
</Pattern>
When looking in output of patched file(1) command we see that Cyotek Color
Palette Editor produced wrong data sizes for palettes with many colors like
black16387.pal and col32767-data0.pal. Graphic tool Xnview 2.40 produce instead
1028 a 1032 data size for 256 colors like in palette-logos.pal. I found this
also for examples like Websafe(MS).pal on the net. That means some pal files
contain some (4) extra bytes after color vector. This is not logical but not
forbidden by documentation. I verified these extra bytes by using a riff
editor like riffpad.exe. Xnview also seems to generate pal files with 256
colors even if less colors are used like in BWrgb.pal with 5 colors. These
software bugs are irritating when you try to understand and verify pal
format. So i mention these facts.
Like other riff based files starts with that magic expressed by XML construct:
<Pattern>
<Bytes>52494646</Bytes>
<ASCII> R I F F</ASCII>
<Pos>0</Pos>
</Pattern>
Afterwards at offset 4 riff size is stored as long value. Then the following
formula should be true:
file size = riff size + 8 = data size + 12 + 8
But when we compare real size mentioned in output/ls-la.txt with calculated
bytes based on riff size in output/file.txt we see in Xnview generated
examples like iEditor.pal real file size is 4 bytes lower. So two errors
"equalize" each other. According to internal structures extra bytes should exist
here, but the bytes do not exist because of lowered file size. This
inconsistency in data apparently does not hurt, if software just reads number of
colors, then calculate color vector size and then reads this vector.
Because the riff size is just twelve bytes higher than data chunk size the
upper byte is also always 0. This gives a new second XML construct:
<Pattern>
<Bytes>0050414C2064617461</Bytes>
<ASCII> . P A L d a t a</ASCII>
<Pos>7</Pos>
</Pattern>
In documentation 2 PAL types are described. The extended PAL Format has a
"plth" chunk signature after "PAL " magic at offset 8. I found no examples for
that format. So somebody in the future may create a trid definition file. The
simple PAL Format has a "data" chunk signature. That is described by above XML
construct.
In old output we got something like:
85.7% (.PAL) Microsoft (color) Palette (24000/1)
14.2% (.) Generic RIFF container (4000/1)
that looks for user at first glance like
49.9% (.PI2) DEGAS med-res bitmap (2000/1)
25.0% (.ABR) Adobe PhotoShop Brush (1002/3)
where trid offers more file types and user must do further inspection to decide
what is true.
But in reality pal file are riff based and introduced by Microsoft to describe
color palette. So this is easy visible for users when using new description
like:
50.0% (.PAL) Microsoft color Palette (RIFF container) (4013/4)
49.9% (.) Generic RIFF container (4000/1)
According to specification each color consists of 4 bytes holding the red,
green, blue and peFlags value. These are not clearly described but for
inspected examples flag value was always 0 and this was mentioned as unused
byte on selected reference site. But some people interpret these 4 bytes as
RGBA value. And in a posting fourth byte has become uninitialized and filled
with FFh value. So for clearness i added forth byte value of first color by
XML construct:
<Pattern>
<Bytes>00</Bytes>
<Pos>27</Pos>
</Pattern>
With updated definition file all inspected PAL files are now detected as
color palette (See appended output/trid-new.txt).
TrID definition, some examples and output are stored in archive pal_.zip .
I hope that my XML file can be used in future version of triddefs.
With best wishes
Joerg Jenderek
