I am doing a translation project for the PSP version of a game released by Prototype (Japanese company), but I am having trouble with some GIM files (image files).
Now the actual problem is not with the gim format, but a compression that has been placed on the gim files, but before that I will clarify a few thins.
Some of the GIM's work, however sometimes a GIM file appears that neither puyotools or GimConv (software that converts gim to png) can handle. The GIM that doesn't work is a little different in appearance.
I know its a GIM file because it starts with: MIG.00.1PSP, though to be exact, its a little different and written like this:
[integer equals 16, signature?] [integer equals 131792] [MIG.00.1PSP, but where a 00 HEX is placed between each hex byte]
10 00 00 00 D0 02 02 00 4D 00 49 00 47 00 2E 00 30 00 30 00
2E 00 31 00 50 00 53 00 50 00 00 00
Each of the compressed GIM files starts with these two integers values (however an image I have with smaller resolution has a different second integer). I have allready tried removing these two integers and also tried replacing M(00)I(00)G(00).(00)0(00)0(00).(00)1(00)P(00)S(00) P(00), with simply MIG.00.1PSP, but that just ended up making GIMConv saying: wrong chunk data.
Also I have tried analyzing the file with signsrch and TrID to look for hints of some sort, but signsrch finds nothing and TrID only finds: "100 .0% (.) LTAC compressed audio (v1.61) (1001/2)"
Here is the file called to keep the expected output simple: black.gim
Here is a random CG:
Here is a random gim file for refference to how an uncompressed version should look like. Notice that the first 4 bytes of the second line indicates the file size minus 16.
Another thing is the int after MIG.001.PSP, which I from different sources has found to be the version number. Therefore, all the compressed files should problably get that int there too.
Update: I believe this is some kind of lz compression, but I haven't figured out which one yet. Tried lz01,lz00,lz10,lz11,CXLZ, lzss . It seems to me that it begins with a 10 byte like lz, it makes MIG.001.PSP become seperated by 00, due to the compression relying on value, key pair, where I believe the key 0 means that values should be directly send to the output. <- if you are confident that its one of the compressions I have tried, please say so too as it could very well just be the tools I used to try those compressions that was wrong with. GZIP and deflate was tried using .NET's System.IO.Compression in C# and the others has been tried using something called Puyo tools.
Steps for my current algorithm that doesn't work after having found the version number:
Start at byte 9.
1. Get next 2 bytes, we'll call the first byte value and the second byte key.
2. Is Key equal to zero?
- write value to decompressed output
- go to 1).
3. Is Key greater than zero?
- Remember the value of (the short int16 value of Value, Key - 1) as lookupValue
- look at byte 8 + (lookupValue - 1) * 2
- while the bytepair at lookupValue has a key higher than zero, do 3) on that too.
- when 2) has been found, write the value of that to output and each lookup shall extend the output by the same value. In other words, 00 00 01 01 outputs 00 00 00.
4. Go to 1. if end of file hasn't been reached.
However this only works till the end of version number. The size of file is much larger than filesize minus 16 when I tried my algorithm on black.gim.. however I hope this pseudo code despite being the wrong solution give some ideas.
I'll be really happy if anybody could give me some input or lead