Microsoft RIFF Palette with many colors have wrong data chunk size

[j2j]

Hello,

I use Cyotek Color Palette Editor version 1.6.0.258 to create Microsoft RIFF
Palette. Examples with only 1 color like yellow.pal and also example
with more colors like col300.pal are OK.

When i try to create examples with more colors like black16387.pal and
col32767-data0.pal something went wrong. Maybe not really usable but
probably allowed by specifications. First program use a lot of time (some
minutes with sand glass like animation) and finally produce data inconsistent
pal files.

As reference i use "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"
and a more readable short interpretation found at
http://worms2d.info/Palette_file .

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

But for bad examples this size is too low. For black16387.pal value is 16
and in col32767-data0.pal value is 0. In last case correct value should be
131072 like in col32767.pal.

This wrong data chunk size can be see in in output of patched file(1)
command (see appended output/file-new.txt). I verified sizes also by
using a riff editor like riffpad.exe.

On the other hand i found examples with a higher data size. Graphic tool
Xnview 2.40 produce such examples. I also found examples like
Protan(MS).pal (with 256 colors and data size 1032 instead 1028) on the net
in http://safecolours.rigdenage.com/set(ms).zip. That means some pal files
contain some (found 4) extra bytes after color vector. This is not logical
but not explicitly forbidden by documentation.

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.

This inconsistency in data apparently do not hurt, if graphic software just
reads number of colors, then calculate color vector size and then reads this
vector.

Used OS is Windows version 10.0.14393 inside Virtualbox 5.1.28r117968.

Some examples and output are stored in archive pal_cy.zip.
I hope that this minor bug can be fixed.

With best wishes
Jörg Jenderek

[Richard Moss]

Hello,

Welcome to the forums and thanks for the information.

I've been looking at my RIFF implementation and comparing it with the spec, and the only potential error I can see is that when I calculate the RIFF document size I'm including the 4 bytes which cover the PAL form type. The spec doesn't state if this should be included or not.

My implementation looks the same (in terms of data read and wrote anyway) with the Worms reference link you provided, except that it doesn't include the four bytes I noted previously.

I've been trying to get hold of the original Microsoft Palette Editor (paledit.exe) without success. I remember using it so very many years ago with Windows 3 and if I can dig it out I want to see if I can use it to generate some palettes which I can then test against my implementation.

I briefly tested the 32767 color palette in the editor and noted that the mouse effects essentially stopped working after the halfway point, although keyboard selection still worked. That's a completely separate issue of course but something that still needs to be looked into, although I'm at a loss to find a use case for that many colors in a palette.

I'll do some more digging, perhaps I can find some old .PAL files in my old developer resources. Will let you know once I've confirmed the issue and have a fix available.

Many thanks for the detailed information!

Regards;
Richard Moss

[Richard Moss]

Just as a quick follow up, I did eventually manage to find the old 16bit Microsoft Palette Editor buried in the Internet Explorer 4.0 administration kit, which happily included a sample palette. I did a quick compare of Palette  Editor generating the same palette which I compared with that sample and they were identical. So far it looks like my implementation is correct. However, I haven't yet tested with super huge palettes so it's possible there's still an issue (one thing that springs to mind is words overflowing). I haven't forgotten though and the issue is logged for a more detailed investigation using the samples you've provided, probably as part of the 1.7 release.