Jump to content
  • Advertisement
Sign in to follow this  
SymLinked

Fighting DXT compression artifacts.

This topic is 3825 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

What can one do to minimize the effects of DXT compression on an image? I've seen a few suggestions: * Upscale the image, then downscale again and save. * Lower the amount of colors in the image. * Move the red pixel data into the alpha channel before compression and swap it back on runtime trough a shader. The first two didn't work, which surprises me. Even with 256 colors I get visible banding. The third ought not to work on images that have transparent parts, right? Since moving the red component in there would kill the alpha. Any other suggestions, or is it simply just the price one has to pay?

Share this post


Link to post
Share on other sites
Advertisement
I assume the last one means *swap* the red and the alpha, rather than just overwriting the alpha with the red. DXT compression treats alpha differently when compressing which may mean you get better results by swapping the channels.

Also try looking at different compressors - there's a few diffrent algorithms for creating DXT files which do better in different circumstances. Squish is one of the better ones.

Share this post


Link to post
Share on other sites
Thanks!

Nvidia's tools use an algorithm based on Squish's and unfortunatly for us I'm not seeing visible differences. Nvidia has a paper on something they call YCoCG, which might or might not be useful to anyone else reading this in the future though.

(www.developer.nvidia.com/object/real-time-ycocg-dxt-compression.html)

I think I'll have to rethink using DXT for everything and only use it for objects that (unlike Skyboxes) won't occupy the whole screen.

Share this post


Link to post
Share on other sites
Do you have a sample of the image you're using before and after compressing ? some things just don't work with DXT or at least suffer, gradient textures being one, I guess that's one of the short falls of using 4 colours to represent 16 texels.

Share this post


Link to post
Share on other sites
Quote:
Original post by Niksan2
Do you have a sample of the image you're using before and after compressing ? some things just don't work with DXT or at least suffer, gradient textures being one, I guess that's one of the short falls of using 4 colours to represent 16 texels.


(Hosting just ran out so can't post any pictures)
Aye, it's a nebula-like image with lots of smooth colors. Would be interesting to try out the alpha/red swap sometime, but not enough time for now.

Share this post


Link to post
Share on other sites
"Lots of smooth colours" makes me think most of the detail in your image is in its luminance, in which case YCoCg would actually be ideal.

The alpha channel of a DXT5 texture block is interpolated which makes it well suited to smooth gradients, it also has more bits than the 5 or 6 bits per channel in the colour blocks.

So you'd store Y (luminance) in the alpha channel and Co and Cg in the colour channels and unpack in the pixel shader.


What are your motives and priorities for using DXT compression, and what can you sacrifice?
- smaller on-disk size?
- faster loading from disk?
- smaller uncommitted in-(system)-memory size?
- smaller committed in-(video)-memory size?
- texture cache efficiency?

There might be alternatives depending on what your priorities are. e.g. using a format like PNG will give you the on-disk benefits, and you could even extend your texture handling to give you some amount of in-memory benefit by decompressing on-demand from memory to memory (if movement through your world is predictable)

Share this post


Link to post
Share on other sites
what was the logic of DXT/s3tc having all 3/4/5 versions
ild preferred to have one of those as a 4:1 RGB only compression (no alpha)
or even a version6

Share this post


Link to post
Share on other sites
Quote:
Original post by zedz
what was the logic of DXT/s3tc having all 3/4/5 versions
ild preferred to have one of those as a 4:1 RGB only compression (no alpha)
or even a version6


You mean some kind of 8bpp RGB format? Ultimately, all of the DXT variants (1-5) compress color in the exact same way, which comes out to 4bpp. Remember that S3TC was invented a long time ago (in the graphics sense of time). Hindsight is 20/20, etc... It is quite clear that we could use a few new formats, but I suspect it's going to take a little while longer before some of the competing ideas get adopted and implemented in hardware. (In particular, I'm talking about compressed HDR formats.) For now, whenever people want to store better or different data, we're forced to cram things into the various channels of DXT1/DXT3/DXT5. It's not elegant, but it works.

Share this post


Link to post
Share on other sites
Quote:
Original post by zedz
what was the logic of DXT/s3tc having all 3/4/5 versions
ild preferred to have one of those as a 4:1 RGB only compression (no alpha)
or even a version6


uhm, you mean like DXT1 ? or do you mean getting a higher resolution by using a 16byte block for just RGB data ?

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!