Some of this may be hard to follow without the context of the powershell script but I'll do my best to explain what I'm doing. I don't have a very good understanding of Wiimms tools so I may be doing something wrong. Here goes.
First I extract the disc image with wit using the command:
wit extract $GameISO $DiscExtract
This gives me a folder with all the contents of the disc. The next step is to loop through all extracted disc files, and extract the contents of each file. Most of the time these are TPL files, some don't have a file extension but I'm assuming they follow a similar format since they do extract. The ExportPath is equal to the name of the file being extracted. So if "battle_common.tpl" is the current loop item, the exported path will be to a folder named "battle_common". If multiple files with the same name are found, an integer is appended to the end of the folder (for example, PM:TTYD has over 300 "t" files, so over 300 "t" folders are created, like t_000, t_001, t_002, ..., t_312, etc). This scheme is also used for the final texture folder, and lets me rearrange the textures later on.
wszst extract $FilePath --recurse --decode --number -d $ExportPath
This gives me a folder with the file name, and the file's contents (raw images), per file found. Now this next part uses some trickery. I once again loop through all disc files, find the matching folder based on the file name, then loop through that folder. Here PNG images are created from the extracted disc file into that same folder.
wimgt decode $FilePath --number -D ($FolderPath + '\image.png')
This PNG will now be renamed to a Dolphin texture. The dimensions are pulled from the extracted file name (ex: image-0.
184x216.CMPR), this raw image is sent through xxhash (ex: 9528c4565b936dad), and its CMPR format so we know its identifier is 14. So put it all together and we get "tex1_184x216_9528c4565b936dad_14". This is exactly what Dolphin would dump, I have verified a few hundred textures and they are all correct. This newly named image is then moved to a separate folder, using the same name scheme as the extracted files from the disc.
The final step is to re-arrange/rename all texture folders into something useful. This step is not important to discuss since its just a bunch of moving stuff around to end up with this:
http://i.imgur.com/wAfKC27.png
So the TPL files are ran through wimgt to create the PNG image, but the corresponding extracted CMPR files are where the hashes and dimensions come from and serve no purpose other than to provide this information.
Now with all that said....
I have managed to fix the issue with the loss of color by running this command:
wimgt decode $FilePath --transform 'RGBA32' --number -D ($FolderPath + '\image.png')
Adding (--transform 'RGBA32') kinda works, but, transparency is not preserved in some textures. I was wrong in my assumption that this only affects paletted types, as its also affecting some CMPR textures as well. It's seemingly random which ones lose transparency, as most PNG images are correctly created with an alpha channel. But there are some that aren't for some reason.
So really I guess my only issue right now is preserving transparency when creating (some) PNG images, as most come out fine.
Basically the only purpose of all this is to dump the images into names that Dolphin recognizes. This will mostly only be used by contributors to the PM:TTYD pack. The images themselves serve as a template of all PM textures that will be redrawn, so its not extremely important that the images have transparency since common sense will usually notify the artist that the black background is not meant to be there. But I'm OCD and would like to get it working 100% so the artist knows exactly what it is they need to redraw.
EDIT: I guess all this can be ignored. I contacted Wiimm and apparently its a bug.
Wiimm said:
Now I know what you mean.
The tools tries always to find the optimal PNG format. And here only grayscale is used at the main image (first image). And TPL is special, because it supports multiple images. Internal they are manages like mipmaps and stored in the same format as the first image.
Thanks for pointing this bug! it is now at my to-do list.