Re: [Algorithms] Spurious DXT colors
Brought to you by:
vexxed72
From: Simon F. <sim...@po...> - 2007-04-12 13:52:15
|
I can't speak for all HW vendors but it's more likely to be option "2.5": the more significant bits are replicated into the LSBs. For all intents and purposes, it works out to be the same as option 3. =20 Simon ________________________________ From: gda...@li... [mailto:gda...@li...] On Behalf Of Andreas Brinck Sent: 12 April 2007 14:39 To: gda...@li... Subject: Re: [Algorithms] Spurious DXT colors =09 =09 I just realized that just multiplying with 2 might not do the trick. I think one has to take into consideration the way the compressed green channel is decompressed from 6 to 8 bits on the graphics card. I can see three different scenarios:=20 =09 1. The 6 bits are just shifted by 2. This means that you will never get pure white. In this case multiplying by 2 would be the correct approach. =09 2. Same as above but the last bits are padded with ones instead of zeros. This means you will never get pure black. In this case you should multiply by 2 and also add 1 / 255.=20 =09 3. The bits are multiplied by 255 / 63 with correct rounding applied, so that the entire range from 0 to 255 is covered. In this case you should multiply by 63/31 to get our truncated green value to reach 255. =09 /A.B. =09 =09 =09 Hi, =09 I vaguely remember reading somewhere about a method to remove the spurious greens and magentas that occur when decompressing a DXT (or any 565 format) texture. I think the idea was to multiply the green channel by 0.5 before compressing to remove a bit and then multiply it by 2 after decompressing. =09 Has anyone tried this, and gotten it to work? =09 /A.B. =09 |