04-06-2015, 07:35 AM
Ah. I think it's simply due to the way the data is stored and converted. The pixel data is these files is 16-bit (RGBA4) instead of 32-bit (RGBA8), so each channel only has 4 bits instead of 8. When you convert them to 32-bit 0s get padded onto the end to make them 8-bit. This works fine with RGB channels, but with alpha it causes these kind of artefacts.
For example if a pixel is stored with 100% opacity the 4-bit alpha channel is 1111 or 0xF. Turning this into 8-bit makes it 1111 0000 or 0xF0 (240), not 0xFF (255). This results in 94% opacity instead of 100%.
Chances are that the game actually reads and displays it as 16-bit instead of converting it like CTPK Tool does, and manages to display them properly. Unfortunately I'm not completely sure how one would fix this. Of course the obvious solution would be to say "if I find an alpha of 0xF then it's just 0xFF", but for intermediate transparencies it's not that simple.
*time passes*
After a little bit of thinking and fiddling with the programmer mode of the Windows calculator (one of my trustiest tools), I think I've got it. For true 4-bit to 8-bit conversion you have to not shift over the bytes, but actually copy them over. So instead of turning 1101 into 1101 0000, turn it into 1101 1101. This means 0xF will actually become 0xFF, and if you do the math, it actually works out perfectly for everything else. I won't bore you with details but from what I can tell that's the true way to convert it. So in actual fact, the red, green, and blue channels are also off, it's just not as noticeable since you having nothing to compare it with.
tl;dr the program's not converting it correctly. Maybe I can get in contact with the tool's developer and get them to fix it.
For example if a pixel is stored with 100% opacity the 4-bit alpha channel is 1111 or 0xF. Turning this into 8-bit makes it 1111 0000 or 0xF0 (240), not 0xFF (255). This results in 94% opacity instead of 100%.
Chances are that the game actually reads and displays it as 16-bit instead of converting it like CTPK Tool does, and manages to display them properly. Unfortunately I'm not completely sure how one would fix this. Of course the obvious solution would be to say "if I find an alpha of 0xF then it's just 0xFF", but for intermediate transparencies it's not that simple.
*time passes*
After a little bit of thinking and fiddling with the programmer mode of the Windows calculator (one of my trustiest tools), I think I've got it. For true 4-bit to 8-bit conversion you have to not shift over the bytes, but actually copy them over. So instead of turning 1101 into 1101 0000, turn it into 1101 1101. This means 0xF will actually become 0xFF, and if you do the math, it actually works out perfectly for everything else. I won't bore you with details but from what I can tell that's the true way to convert it. So in actual fact, the red, green, and blue channels are also off, it's just not as noticeable since you having nothing to compare it with.
tl;dr the program's not converting it correctly. Maybe I can get in contact with the tool's developer and get them to fix it.