Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Andreas Brinck <andreas.brinck@gm...>  20070412 11:40:55
Attachments:
Message as HTML

Hi, 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. Has anyone tried this, and gotten it to work? /A.B. 
From: Andreas Brinck <andreas.brinck@gm...>  20070412 13:39:10
Attachments:
Message as HTML

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: 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. 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. 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. /A.B. Hi, > > 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. > > Has anyone tried this, and gotten it to work? > > /A.B. > 
From: Simon Fenney <simon.fenney@po...>  20070412 13:52:15
Attachments:
Message as HTML

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: gdalgorithmslistbounces@... [mailto:gdalgorithmslistbounces@...] On Behalf Of Andreas Brinck Sent: 12 April 2007 14:39 To: gdalgorithmslist@... 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 
From: Andreas Brinck <andreas.brinck@gm...>  20070412 14:22:02
Attachments:
Message as HTML

I see, in this case a value of 31 in the green channel would be expanded to 127. In order to expand our 0127 range to 0255 in a pixel shader we would have to multiply with 255 / 127 then. I will try it out :) /A.B. On 4/12/07, Simon Fenney <simon.fenney@...> wrote: > > 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. > > Simon > >  > *From:* gdalgorithmslistbounces@... [mailto: > gdalgorithmslistbounces@...] *On Behalf Of *Andreas > Brinck > *Sent:* 12 April 2007 14:39 > *To:* gdalgorithmslist@... > *Subject:* Re: [Algorithms] Spurious DXT colors > > 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: > > 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. > > 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. > > 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. > > /A.B. > > Hi, > > > > 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. > > > > Has anyone tried this, and gotten it to work? > > > > /A.B. > > > > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithmslist > 
From: Simon Fenney <simon.fenney@po...>  20070412 15:15:41

Andreas Brinck wrote: >=20 > I see, in this case a value of 31 in the green channel would=20 > be expanded to 127. In order to expand our 0127 range to=20 > 0255 in a pixel shader we would have to multiply with 255 /=20 > 127 then. I will try it out :) >=20 Actually, the 6bit green value, 31, i.e 0b011111, should be expanded to an 8bit value of 0b01111101 i.e 125. Cheers Simon 
From: Wolfgang Engel <wolfgang.engel@gm...>  20070412 15:24:41

Hi, I spent some time to think about the best way to generate an orthographic light view frustum for "fullscreen" shadow maps. I actually use code to do this since a long time but I always perceive the resulting frustum as too big. The idea is to tightly fit the light frustum around a slice of the viewer's frustum. Here is how I do it: 1. determine a slice of the camera view frustum 2. calculate a near and far plane for this 3. transform in light space 4. take the extrema and build a bounding box 5. found the center of this box and transform it to world space 5. construct the orthographic frustum from this box By transforming to light space and then taking the extrema, you get a box that encloses one frustum slices. The problem is now rotation. Let's say you contruct the light view matrix upfront just by setting up fixed x and y vectors that just follow the z == light direction vector. If you rotate the camera view under the light what happens is the following: the enclosing orthographic light frustum will rotate around the camera view frustum slice, just by changing its shape. So in worst case it would look on the figure above like a diamond. There are two issues attached to this: the diamond is not necessarily the most efficient form to enclose the slice and second the rotation shows up in the result, because the render target will rotate with it. You can see the shadow flicker because of this. What I did now is a kind of hack: I used the direction of the camera and the x axis of the camera and "crossproduct" them to the light direction. The result is better than before. Do I do anything substantially wrong and is there a better way to handle all this? Maybe I am completely off here ...  Wolfgang 
From: <castano@gm...>  20070412 23:20:55

On 4/12/07, Andreas Brinck <andreas.brinck@...> wrote: > Hi, > > I vaguely remember reading somewhere about a method to remove the spuriou= s > greens and magentas that occur when decompressing a DXT (or any 565 forma= t) > 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= . > > Has anyone tried this, and gotten it to work? Andreas, you can achieve that storing the colors in the reversible YCoCg color space. You can translate from RGB to YCoCg with the following code: Co =3D RB; t =3D B + (Co/2); Cg =3D Gt; Y =3D t + (Cg/2); s =3D Y  (Cg / 2); G =3D Cg + s; B =3D s  (Co / 2); R =3D B + Co; You will loose one bit in each of the CoCg components, since they are signed values, but o the other side you can store Y in the 6 bit component, providing more accuracy to the luminance. A simpler and cheaper alternative is the JPEGLS transform: (RG, G, BG) It might not be obvious why that works, but with the following code you can easily test that pure greys remain pure greys after the transform: for(int i =3D 0; i < 256; i++) { =09int R =3D i; =09int G =3D i; =09int B =3D i; =09int a =3D R  G; =09int b =3D G; =09int c =3D B  G; =09// Quantize/bitexpand colors. =09a =3D ((a >> 3) << 3)  (a >> 5); =09b =3D ((b >> 2) << 2)  (b >> 6); =09c =3D ((c >> 3) << 3)  (c >> 5); =09R =3D a + b; =09G =3D b; =09B =3D c + b; =09=09 =09printf("%d: %d %d %d\n", i, R, G, B); } Hope that helps! =20 Ignacio Casta=F1o castano@... 
From: Andreas Brinck <andreas.brinck@gm...>  20070419 07:13:27
Attachments:
Message as HTML

Hi, thanks for the tip. I will try it out, how well does the DXTcompression scheme suit these color spaces? /A.B. On 4/13/07, Ignacio Casta=F1o <castano@...> wrote: > > On 4/12/07, Andreas Brinck <andreas.brinck@...> wrote: > > Hi, > > > > 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.5befor= e > > compressing to remove a bit and then multiply it by 2 after > decompressing. > > > > Has anyone tried this, and gotten it to work? > > Andreas, > > you can achieve that storing the colors in the reversible YCoCg color > space. You can translate from RGB to YCoCg with the following code: > > Co =3D RB; > t =3D B + (Co/2); > Cg =3D Gt; > Y =3D t + (Cg/2); > > s =3D Y  (Cg / 2); > G =3D Cg + s; > B =3D s  (Co / 2); > R =3D B + Co; > > You will loose one bit in each of the CoCg components, since they are > signed values, but o the other side you can store Y in the 6 bit > component, providing more accuracy to the luminance. > > A simpler and cheaper alternative is the JPEGLS transform: > > (RG, G, BG) > > It might not be obvious why that works, but with the following code > you can easily test that pure greys remain pure greys after the > transform: > > for(int i =3D 0; i < 256; i++) > { > int R =3D i; > int G =3D i; > int B =3D i; > > int a =3D R  G; > int b =3D G; > int c =3D B  G; > > // Quantize/bitexpand colors. > a =3D ((a >> 3) << 3)  (a >> 5); > b =3D ((b >> 2) << 2)  (b >> 6); > c =3D ((c >> 3) << 3)  (c >> 5); > > R =3D a + b; > G =3D b; > B =3D c + b; > > printf("%d: %d %d %d\n", i, R, G, B); > } > > Hope that helps! > >  > Ignacio Casta=F1o > castano@... > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=3Dgdalgorithmsli= st > 
From: <castano@gm...>  20070420 07:45:32

Andreas, you loose some quality, because you loose 2 bits, but I think DXTcompression still does a good job. Take in mind that you also have to adjust the color weighting factors according to the color space, you probably want to have higher accuracy in the luminance than in the chrominance. In the future I'm planning to add these color space transformations to the NVIDIA Texture Tools, that are now publicly available at: http://code.google.com/p/nvidiatexturetools/ =20 Ignacio Casta=F1o castano@... On 4/19/07, Andreas Brinck <andreas.brinck@...> wrote: > Hi, > > thanks for the tip. I will try it out, how well does the DXTcompression > scheme suit these color spaces? > > /A.B. > > > On 4/13/07, Ignacio Casta=F1o <castano@...> wrote: > > > > On 4/12/07, Andreas Brinck < andreas.brinck@...> wrote: > > > Hi, > > > > > > 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. > > > > > > Has anyone tried this, and gotten it to work? > > > > Andreas, > > > > you can achieve that storing the colors in the reversible YCoCg color > > space. You can translate from RGB to YCoCg with the following code: > > > > Co =3D RB; > > t =3D B + (Co/2); > > Cg =3D Gt; > > Y =3D t + (Cg/2); > > > > s =3D Y  (Cg / 2); > > G =3D Cg + s; > > B =3D s  (Co / 2); > > R =3D B + Co; > > > > You will loose one bit in each of the CoCg components, since they are > > signed values, but o the other side you can store Y in the 6 bit > > component, providing more accuracy to the luminance. > > > > A simpler and cheaper alternative is the JPEGLS transform: > > > > (RG, G, BG) > > > > It might not be obvious why that works, but with the following code > > you can easily test that pure greys remain pure greys after the > > transform: > > > > for(int i =3D 0; i < 256; i++) > > { > > int R =3D i; > > int G =3D i; > > int B =3D i; > > > > int a =3D R  G; > > int b =3D G; > > int c =3D B  G; > > > > // Quantize/bitexpand colors. > > a =3D ((a >> 3) << 3)  (a >> 5); > > b =3D ((b >> 2) << 2)  (b >> 6); > > c =3D ((c >> 3) << 3)  (c >> 5); > > > > R =3D a + b; > > G =3D b; > > B =3D c + b; > > > > printf("%d: %d %d %d\n", i, R, G, B); > > } > > > > Hope that helps! > > > >  > > Ignacio Casta=F1o > > castano@... 
From: jacob langford <jacob.langford@gm...>  20070420 14:37:38
Attachments:
Message as HTML

Ignacio, So for the JPEGLS transform you described, how do you treat the negative color channels generated by RG and BG when G>R and G>B? It seems as if one could use the pixelshader frac() function to deal with the wrap, but that mipmapping and texturefiltering would cause artifacts when the sign flips. Or do you scale/bias into the range 1,1? If so it would seem you would also have to scale/bias the green channel to make the trick work. Do you have any tricks on seeing this algorithm all the way through to pixel shader? Andreas, also note that regarding the question of DXT1 treatment of 565, it is possible to generate values with more precision than 565 due to the DXT1 compression. Try out a solid color with values of say (44,44,44) and run through the 565 conversion and back, then run the same texture through NVidia's DXT compressor and you will see that the palette entries spread apart slightly so that when the DXT1 is decoded a better result is returned than with just the straight 565 conversion. Not all DXT compressors are smart enough to do that though... Jacob On 4/12/07, Ignacio Casta=F1o <castano@...> wrote: > > On 4/12/07, Andreas Brinck <andreas.brinck@...> wrote: > > Hi, > > > > 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.5befor= e > > compressing to remove a bit and then multiply it by 2 after > decompressing. > > > > Has anyone tried this, and gotten it to work? > > Andreas, > > you can achieve that storing the colors in the reversible YCoCg color > space. You can translate from RGB to YCoCg with the following code: > > Co =3D RB; > t =3D B + (Co/2); > Cg =3D Gt; > Y =3D t + (Cg/2); > > s =3D Y  (Cg / 2); > G =3D Cg + s; > B =3D s  (Co / 2); > R =3D B + Co; > > You will loose one bit in each of the CoCg components, since they are > signed values, but o the other side you can store Y in the 6 bit > component, providing more accuracy to the luminance. > > A simpler and cheaper alternative is the JPEGLS transform: > > (RG, G, BG) > > It might not be obvious why that works, but with the following code > you can easily test that pure greys remain pure greys after the > transform: > > for(int i =3D 0; i < 256; i++) > { > int R =3D i; > int G =3D i; > int B =3D i; > > int a =3D R  G; > int b =3D G; > int c =3D B  G; > > // Quantize/bitexpand colors. > a =3D ((a >> 3) << 3)  (a >> 5); > b =3D ((b >> 2) << 2)  (b >> 6); > c =3D ((c >> 3) << 3)  (c >> 5); > > R =3D a + b; > G =3D b; > B =3D c + b; > > printf("%d: %d %d %d\n", i, R, G, B); > } > > Hope that helps! > >  > Ignacio Casta=F1o > castano@... > >  > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveysand earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_name=3Dgdalgorithmsli= st > 
From: <castano@gm...>  20070420 20:08:20

Jacob, you just have to scale and bias the RB components, but don't do that with the G channel, because it's not signed! =20 Ignacio Casta=F1o castano@... On 4/20/07, jacob langford <jacob.langford@...> wrote: > Ignacio, > > So for the JPEGLS transform you described, how do you treat the negative > color channels generated by RG and BG when G>R and G>B? It seems as if > one could use the pixelshader frac() function to deal with the wrap, but > that mipmapping and texturefiltering would cause artifacts when the sig= n > flips. Or do you scale/bias into the range 1,1? If so it would seem yo= u > would also have to scale/bias the green channel to make the trick work. = Do > you have any tricks on seeing this algorithm all the way through to pixel > shader? > > Andreas, also note that regarding the question of DXT1 treatment of 565, = it > is possible to generate values with more precision than 565 due to the DX= T1 > compression. Try out a solid color with values of say (44,44,44) and run > through the 565 conversion and back, then run the same texture through > NVidia's DXT compressor and you will see that the palette entries spread > apart slightly so that when the DXT1 is decoded a better result is return= ed > than with just the straight 565 conversion. Not all DXT compressors are > smart enough to do that though... > > Jacob 