Home
Blogs
Forums
News
Portfolios
Projects
Tutorials
32 users logged in
New? Learn about game development.
Before posting, review our community guidelines.
Follow Us
Chat in the GameDev.net Discord!
Mastodon
Back to Graphics and GPU Programming

GL_COMPRESSED, GL compressing wrong

Started by
12 comments, last by Dario Oliveri 11 years, 9 months ago
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

NBA2K, Madden, Maneater, Killing Floor, Sims http://www.pawlowskipinball.com/pinballeternal

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.

Ashaman

Gnoblins: Website - Facebook - Twitter - Youtube - Steam Greenlit - IndieDB - Gamedev Log

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.

. 22 Racing Series .

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
Actually, if you're using shaders, just assign the green component to r & b. Instant greyscale!
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.

Peace and love, now I understand really what it means! Guardian Angels exist! Thanks!

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.

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?
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.

Direct3D has need of instancing, but we do not. We have plenty of glVertexAttrib calls.

Wasn't compression covered by patent? Can I release any opensource library with compression algorithm inside?

Peace and love, now I understand really what it means! Guardian Angels exist! Thanks!

This topic is closed to new replies.

Advertisement

Popular Topics

Aybe One
How do you manage yourself and your time as years pass on? GDNet Lounge
Catomax26
How can i NOT get lost and completely lose interest in the infinite sea of game development? For Beginners
ReignOnU
Do your part to stop global warming and climate change GDNet Lounge
Konjointed
C++ how do you use dependency injection? For Beginners
Jikoob
Too many managers? General and Gameplay Programming
aigan
The promise of freedom in story games Game Design and Theory
Advertisement

Recommended Tutorials

Code_Analysis
Wade Not in Unknown Waters: Part Four General and Gameplay Programming
Myopic Rhino
Super X Studios Interviews
Myopic Rhino
The Clash of Mobile Platforms: J2ME, ExEn, Mophun and WGE General and Gameplay Programming
Myopic Rhino
Michael Bourland Interviews
Myopic Rhino
Game Art Creation and Reviewing Requirements Visual Arts

Reticulating splines

About GameDev.net
Community Guidelines
Terms of Service
Privacy Policy
Contact Us
Copyright (c) 1999-2024 GameDev.net, LLC
Back to Top