No, I'm saying I
can extract data from TacData.
I've spent the last few evenings figuring out (what I hope to be) the bulk of Apoc's sprite formats.
But I probably won't have all the armour sprites pulled until sometime tomorrow. Some of the blighters don't want to come out yet and it's getting late here now. There's a lot of them, too - over a hundred images for Marsec helmets alone, for eg.
I'm interested to see what they have to say about the colours thing. Thanks for the link, I'll keep an eye on it.
Out of interest, if you:
- Load one of the affected images
- Apply the full palette to it
- Save as a new GIF and quit GIMP
- Restart it and reload the new file
... does it drop the colours again? What about using other palette-based formats the program might support (eg 8-bit BMP)?
To be clear on how the palette in an image file works, it has to be of a length equal to a power of two. For example, 256 is two to the power of eight; 16 is two to the power of four (see where the terms "8-bit image" and "4-bit image" are coming from?).
What I'm assuming is that while GIMP loads the image, it keeps track of the highest colour index used, then loads an amount of indexes from the palette equal to the lowest power of two it can get away with (instead of loading whatever the file header tells it to load).
For eg, if the highest colour used is 13, then it loads the first 16 colours (it doesn't really care if all those colours are used in the image, it just thinks it doesn't need more then that - two to the power of three is only eight, so it has to jump to two to the power of four, which covers 16). If the highest colour index was 43, it'd load the first 64 colours (two to the power of five is only 32, but two to the power of six is 64), and so on.
However the file header DOES state exactly how many colours are in the palette, and so GIMP should respect that and load the lot. The catch is this means a larger file size when it doesn't seem to be needed (hence why I think someone somewhere thinks this is a feature).