09-12-2013, 07:33 PM
I was just saving the images as PNG just so I could be sure everything was correct, and I figured you guys were after the images, anyway. Mostly the images are stored as compressed raw pixel data, not in some kind of usable format.
I didn't really look into the ANB format any more than I had to; there's a LOT of data in those files that I just ignore. Some of it may be important for different things. What my program does is search through the file until it encounters a ZLFW header (Which denotes a wflz-compressed image in a set of chunks), and decompresses that. Once that is done, you're left with some raw DXT1-compressed image data (which is actually two images; one for the color map and the other for the multiply map). Parsing back a bit from the original ZLFW header, you can get a header that contains those image's width and height, and I pass the width and height along to libsquish to get raw RGBA data out. From there, I multiplied the alpha and color maps together using the algorithm they used (Different from a standard multiply) and saved the result to PNG.
That's what the first program of mine puggsoy posted here did, anyway. My new one then searches back through the ANB file until it stumbles across data that looks like it might be a piece header, and follows that to find the UV and texture coordinates to figure out what parts of each image go where. This part's kinda hackish, and for all I know doesn't work with some files just because they've got data that'll fool my code into thinking it found a header, but it generally seems to have fairly good results. It's pretty slow, but they're small files and images, anyway.
As far as I know, there isn't any standard sort of DDS or DXT header, though I haven't researched the formats much at all. From what it looked like, however, it's all proprietary stuff that no other format uses, hence the need for specialized tools to get meaningful data out.
I can change the program to stop at any particular point if you think it'd help. The thing is that some of the ANB files may not have actual image data inside them, hence no output/botched output. Some images could even be 24-bit for all I know. Having the raw pixel data may help in that regard; I dunno.
I didn't really look into the ANB format any more than I had to; there's a LOT of data in those files that I just ignore. Some of it may be important for different things. What my program does is search through the file until it encounters a ZLFW header (Which denotes a wflz-compressed image in a set of chunks), and decompresses that. Once that is done, you're left with some raw DXT1-compressed image data (which is actually two images; one for the color map and the other for the multiply map). Parsing back a bit from the original ZLFW header, you can get a header that contains those image's width and height, and I pass the width and height along to libsquish to get raw RGBA data out. From there, I multiplied the alpha and color maps together using the algorithm they used (Different from a standard multiply) and saved the result to PNG.
That's what the first program of mine puggsoy posted here did, anyway. My new one then searches back through the ANB file until it stumbles across data that looks like it might be a piece header, and follows that to find the UV and texture coordinates to figure out what parts of each image go where. This part's kinda hackish, and for all I know doesn't work with some files just because they've got data that'll fool my code into thinking it found a header, but it generally seems to have fairly good results. It's pretty slow, but they're small files and images, anyway.
As far as I know, there isn't any standard sort of DDS or DXT header, though I haven't researched the formats much at all. From what it looked like, however, it's all proprietary stuff that no other format uses, hence the need for specialized tools to get meaningful data out.
I can change the program to stop at any particular point if you think it'd help. The thing is that some of the ANB files may not have actual image data inside them, hence no output/botched output. Some images could even be 24-bit for all I know. Having the raw pixel data may help in that regard; I dunno.