16-bit per pixel TIM image is seen as 8-bit per pixel

[aybe]

XnView MP 0.99.7 64-bit
Windows 10.0.19044.1526

Incorrect bit-depth reported by XnView MP for TIM files.

To reproduce:
1. unzip the attachment as TIM file couldn't be attached as such
2. browse to where the file is with XnView MP
3. see that bit-depth is 8 while it should be 16

Expected behaviour:
TIM files with a bit-depth of 16 should not be reported as with a bit-depth of 8.

Thank you

[xnview]

RGB is packed as 16bits, but not 16bits per component

[aybe]

Don't you think there's some discrepancy in the following?

I mean, if I follow you, then all should be 8 but currently 4bpp reports 4, 8bpp reports, 24bpp reports 24 but 16bpp reports 8 which makes no sense.

Or did I simply miss something in what you've said?

[xnview]

Don't you think there's some discrepancy in the following?

Yes, the first one should be reported as 192x144x24 and not 8

[aybe]

Actually, a 16-bit TIM may either:

#1 remain 16-bit if any of its pixel does not have the STP bit set.

#2 become 32-bit if any of its pixel has the STP bit set, this is because it actually is, semi-transparency, if it wasn't then it could simply be a 15-bit + 1 bit of transparency like TGA format supports.

As for the semi-transparency algorithm, it's a bit contradictory in the PDFs you can find at psxdev.net, the file format specifies one way in table 3-1 at page 182, while the runtime library overview in table 8-11 at page 107 specifies the same but for one case.

Now that really is the cake topping, I understand that there may be higher priority bugs to solve than this one within XnView MP.