Hello all

I am not sure if this topic is programming or more Visual Arts, but I am trying to figure out a texture image format of a game that is soon to be discontinued in order to not loose the data once it is shut down and I was hoping that with what I have figured out so far maybe someone recognizes a pattern that they know an algorithm for.

The file format itself is actually a container consisting of a header with the information of widht, height, depth, etc as well as data for the mip levels. There are over 20 different possible formats that can be indicated in the header, many of them are quite simple, like uncompressed ARGB, single channel R, DXTn, cube textures. However I am struggling to understand how one of them could be interpreted. I have figured out the following things so far:

• In the game the textures are present as DXT5, so I guess its a compression over DXT (crunch?)
• It is variable rate. You can see massive differences in size between two images of the same dimension
• Only that format uses additional fields in the header, the most interesting part are 3 uint32 values that seem to actually be 4 values of 24 bits each. There are only a few pattern for these 4 values I have seen so far. One is 0x00004b, 0x00004B, 0x00004B, 0x00004B. Others are 0x00005C, 0x00005C, 0x00004B, 0x00004B and similar. Less often there is 0x00005C, 0x00005C,  0xFF014B, 0x00004B
• 1x1 mip layers are usually 6 bytes (padded to 16 bytes), but for the last pattern above (with 0xFF014B) its only 4 bytes
• When comparing various 1x1 mip layers there is no common pattern except that they are usually 6 bytes

I was thinking that it could be crunch over DXT5 as mentioned above, but I am not sure if that somehow fits the 4 3 byte values i mentioned above. It does not seem like the individual layers contain any additional information like a codebook for colors or dictionaries or something like that. Maybe are there any other ideas what it could be?

Thank you very much in advance,
Cromon

I made some good progress with this in the past week or so. It turns out that most of what is written above is wrong :)

I found in the client the standard jpeg quantization tables and the 4 values of 3 bytes are in fact quality factors applied to the up to 4 selected tables. The tables are selected based on a field in the header and are either 4 times the standard luminance one or for normal textures slightly different. I have also found Standard Huffman tables used in jpeg in the client. So my best guess is that the actual layer data is just the jpeg compressed image output for each layer.

I have tried to verify this with libjpeg but i am having a hard time with the libraries... They are very much focused on reading files with all the possible additional features available and require a lot of manual pre configuration if you don’t have a file.

Does anyone of you know a good library that can do things like that? I have quantization tables, Huffman tables and the compressed image and need to decompress that.