Jump to content
  • Advertisement
Sign in to follow this  
dpadam450

GL_COMPRESSED, GL compressing wrong

This topic is 2163 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm loading a jpg and having GL compress it instead of passing in a DDS texture.

On the left is the compressed, the right uncompressed. Somehow the left image gets some color in it even though the original is 100% grayscale. If I desaturate the compressed one back to grayscale it comes out to look just fine.

glTexImage2D( GL_COMPRESSED (internal format), ....GL_RGB (source format) )
vs
glTexImage2D( GL_RGB (internal format), ....GL_RGB (source format) )

rWikd.jpg

Share this post


Link to post
Share on other sites
Advertisement
Just guessing here without knowing the excat format and compression algorithm. I.e. the DXT4/5 compression compress RGB to 16 bit, where ,as far as I know, the green channel got one more bit, that is 16bit = 5 (red),6(green),5(blue).
Compressing a gray scaled picture will leave the green channel with higher resolution which can result in a different green channel value when decompressing. This could be the reason that you got a green tint(higher green channel) and violet tint (lower green channel) in an otherwise grey image.

PS: when you need a grey channel, just use one channel (alpha or green) and expand it to RGB in the shaders. Edited by Ashaman73

Share this post


Link to post
Share on other sites
There's a lot of different algorithms for DXT compressing an image. The best ones will take a long time (seconds) to run, so I would guess that the one provided by your GL driver is optimised for speed over quality.
And as above, the colour palette for each block will be in 16-bit format, which is not so good for grey-scale - the green/purple tint is a tell-tale artefact of the 565 colour format. Edited by Hodgman

Share this post


Link to post
Share on other sites
Consider using the YCoCg colour space with DXT. You can set both chroma channels to zero and just use the luminance component:

http://developer.download.nvidia.com/whitepapers/2007/Real-Time-YCoCg-DXT-Compression/Real-Time%20YCoCg-DXT%20Compression.pdf

Share this post


Link to post
Share on other sites
Actually, if you're using shaders, just assign the green component to r & b. Instant greyscale!

Share this post


Link to post
Share on other sites
Is there anyway in openGL to tell drivers to use a slower but better algorithm for compression instead of a fast one? actally for a 2048x2048 image I take 2 seconds and the result is really ugly.

Share this post


Link to post
Share on other sites
No, and I wouldn't bother.

You might as well use a single channel texture format and be done with it; something like an L8 would be fine.

Edit: I also wouldn't use JPEG source image data to DXT/BC compressed formats either. Both compressors are lossy so you are just compounding the problem.

Source assets are generally best left either uncompressed or compressed via a lossless format such as TGA or PNG before conversion to a DXT/BC format. Edited by phantom

Share this post


Link to post
Share on other sites

Is there anyway in openGL to tell drivers to use a slower but better algorithm for compression instead of a fast one? actally for a 2048x2048 image I take 2 seconds and the result is really ugly.


Try the squish library: http://code.google.com/p/libsquish/

Or maybe L.Spiro's DXT library is available? Edited by mark ds

Share this post


Link to post
Share on other sites
You're better off compressing offline and then using glCompressedTexImage rather than compressing at load time. That way you get at least some measure of control over the quality of compression used, and you get to avoid the slow-downs inherent in compressing RGB/RGBA data at load time. With DDS files you also get to include all miplevels in the file, so you get faster texture loading too, as well as the potential for exploiting higher quality reduction algorithms.

Worth noting that the old GL_ARB_texture_compression, when used in this way, makes no promises about the compression algorithm used (or even if the texture is going to be compressed at all) so you can rely on nothing. The best you have is a glHint (GL_TEXTURE_COMPRESSION_HINT, ....) but that's just a hint, of course, and the driver is under no obligation to honour it.

For better instant greyscale in a shader you can use vec4 (dot (color.rgb, vec3 (0.3, 0.59, 0.11)), color.a) by the way.

Share this post


Link to post
Share on other sites
Wasn't compression covered by patent? Can I release any opensource library with compression algorithm inside? Edited by DemonRad

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!