I lost you here, but there is no explicit palettes in my image files. It is inferred. Maybe i should write an encode/decode tool to/from my format for BMP. I have written something for my work that might get GPL'ed later on.
Alright, what I meant was...
A common garden variety palettized image stores its data in the following manner: there is a header which defines the file type, the amount of colours and the image size in pixels or what-have-you, right? Then comes the palette section, which stores the RGB values of all the colours defined earlier. Which would, in a DDS file*, clock in at precisely two bytes per channel or eight bytes per colour**, leading to the palette block being precisely 1 kilobyte in size.
The image block consists of 2X bytes, where X is the amount of pixels we have in our image (for an 8-bit image, naturally). Each pixel is therefore defined by a pair of bytes, denoting the number of the colour to be used for this particular pixel (f.e. [AF] will call colour number 176 off the palette table). This is why, say, a 256x256 8-bit DDS file only weighs 66688 bytes.
This is twice more than that of a DXT1 DDS file of the same dimensions (which would be 32896 bytes large) because DXT is a lossy format, much like JPEG, and from what I understand relies on interpolation of the pixels by defining the colour only of every fourth or something to that effect.
The upside of DXT is small size and full access to 32-bit colour (as opposed to the predefined 8 bits of indexed images), the upside of indexation is crisper textures. But compare this to an uncompressed 32-bit BMP of the same dimensions. 262198 bytes, a little under four times as large as the indexed image and, consequentially, eight times as large as the lossy image.
What BMP does, is it stores huge chunks of data, meticulously defining every single colour there is for every single pixel there is. I'm a tad lazy to find out whether or not a TIFF file will be larger and if so, why, because I've never used TIFF and probably never will. In any case, the BMP file is so large because where the indexed image uses two bytes to define a pixel***, the BMP uses eight, for the full RGBA info.
And now explain to me, pretty please with sugar on top, how can you create a format which will be smaller than BMP if you'll have to define not only the palette from which a particular colour will come****, but also whether a particular colour is achieved by mixing together two colours off two separate palettes? This would double the necessary space up to six bytes, and even so only if we assume that the colours will be mixed in equal proportions, as any other way will requre at least an additional byte. And that's already based off the assumption that we use 8-bit palettes so we only need two bytes to define a colour within one - you still haven't clarified how large yours are going to be.
Bottom line? I can't quite grasp how will this be better than PNG in terms of processing power impact AND video memory usage (for 3d applications) AAAAAAANNNNDDDD, most important, consumption of hard drive space.
_____________
* - Which isn't that far removed from a GIF in its manner of storing indexed images. It's just that I've spent a goodly amount of time staring my eyes out at swizzled and indexed DDS images trying to wrap my head around swizzling itself, so I prefer to stick to what I know.
** - If we're talking RGBA, which we most probably are if we're to discuss any game-related application that doesn't rely on such a fickle trick as transparency colours.
*** - At this point, the header+palette size is small enough to be considered negligible.
**** - That's easy, we tuck on one extra byte to the indexed format, right? Three bytes instead of four, but we can only run with 16 palettes this way.
