Page 1 of 1

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

Posted: Mon Feb 14, 2022 5:54 am
by 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 :P

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

Posted: Mon Feb 14, 2022 9:50 am
by xnview
RGB is packed as 16bits, but not 16bits per component

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

Posted: Tue Feb 15, 2022 8:21 am
by aybe
Don't you think there's some discrepancy in the following?
xnviewmp_5AobI58dZP.png
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? :D

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

Posted: Tue Feb 15, 2022 8:27 am
by xnview
aybe wrote: Tue Feb 15, 2022 8:21 am Don't you think there's some discrepancy in the following?
Yes, the first one should be reported as 192x144x24 and not 8

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

Posted: Tue Feb 15, 2022 1:30 pm
by 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. :D