Jump to content
  • Advertisement
Sign in to follow this  
L. Spiro

[Release] DXTn Compression Algorithm

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

The free NVidia DXTn compression utility is considered the industry standard in generating DXTn-compressed DDS files.
I am currently building a next-generation game engine and as we all know the quality of the graphics is important for any major title.

I wondered if the quality of the .DDS files could be improved, and I had an idea that seemed to be a reasonable way to do that. I have implemented it and am happy with the results.
It is both higher in quality and faster than the NVidia tool. In fact its low-quality setting is not only many times faster than NVidia’s low setting, but produces quality that is often higher than NVidia’s medium setting.
I have documented the algorithm with code snippets here.

I hope many individuals and game companies alike can make use of this algorithm.


L. Spiro

Share this post


Link to post
Share on other sites
Advertisement
Thanks for releasing the code and algorithm details. However you should really compare against ATI's texture compression library, which is not only fast (it's multithreaded) but has excellent quality. I made some comparison images and gathered some error metrics using Compressonator (the front-end tool for ATI_Compress) and their results had lower error rates, and also look better to my eyes. Yours does a better job of reproducing the gradients on the text in a few cases, however it also has some severe discoloration artifacts. But of course their library is not open source,so it's always great to have full implementation details for alternate approaches.

[attachment=6310:Comparisons.png]

[attachment=6311:ErrorStats.png]

Share this post


Link to post
Share on other sites
Thank you for the suggestion.
I have tweaked a few things on how it decides how close colors are and my percentage of error has been decreasing. For one I used their weights for each channel instead of 0.3, 0.59, and 0.11.

I am now at 14.485, which at least beats their low-quality setting. Their high-quality setting is only at 14.055, so I am pretty close (using db(square error)).
I think the algorithm itself is sound; I just need to tweak a few things and adjust how it grades closeness of colors.
Will post more results later.


L. Spiro


[EDIT]
There is a bug in my implementation of the 3rd part. That is where the discoloration is sneaking in.
I will fix that and I believe my error will drop significantly, since nearly all of my errors are coming from the discolorazation caused there.
[/EDIT]

Share this post


Link to post
Share on other sites
Fixing the bug helped, and I made a few tweaks to the first and second stages of the algorithm.
Here are my current results:
[attachment=6318:LSResults.png]
[attachment=6319:AdOrig copy5.png]

I have a few more ideas to try.


L. Spiro

Share this post


Link to post
Share on other sites
That looks really nice!

Although I can see quite a large amount of very light blue discolorations instead of white, all over the place... especially noticeable on the upper text, along the bottom line. Which seems kind of interesting, because there's a lot of that same light blue, but not really any other noticeable discolorations besides that.


PS. Although admittedly, the light blue is easily perceived as white under normal circumstances... it just seems so abundant, I'm curious if there's something amiss.

Share this post


Link to post
Share on other sites
One may be tempted to expect all greys, but as the DXTn compression is lossy and must represent all colors in a block using only 2 16-bit endpoint colors and 2 values interpolated between them (which are not restricted to 16-bit precision, but still limited by their 16-bit end points), not every color can be exactly reproduced.

As it turns out, you can nudge a grey color closer to another grey color by changing only one of its RGB components, and blue is the component that is least perceptible. The result is of course slight discolorization, but still a closer match to the actual grey perceptually.

If I graded the closeness between 2 colors using 0.333333 for each channel then the images above would all be fully grey.


L. Spiro

Share this post


Link to post
Share on other sites
Nice read!

I would love to see MJP's updated Error Statistics after YogurtEmperor's fixes to the algorithm.

Also, have you guys tried to compute the optimal/global minimum for this problem by brute-forcing through all relevant possibilities for the compression? (minus any obvious pruning of the search space to make it feasible to brute force) Having the global minimum SNR-wise in MJP's statistics would be a nice addition, to be able to estimate how far these algorithms go from the optimal. Of course that doesn't necessarily give the best perceptual result, but having a good raw number for the lower bound is useful when estimating how far it's possible to improve.

Share this post


Link to post
Share on other sites

Nice read!

I would love to see MJP's updated Error Statistics after YogurtEmperor's fixes to the algorithm.

Also, have you guys tried to compute the optimal/global minimum for this problem by brute-forcing through all relevant possibilities for the compression? (minus any obvious pruning of the search space to make it feasible to brute force) Having the global minimum SNR-wise in MJP's statistics would be a nice addition, to be able to estimate how far these algorithms go from the optimal. Of course that doesn't necessarily give the best perceptual result, but having a good raw number for the lower bound is useful when estimating how far it's possible to improve.


If you're targeting next-gen then why would you still use dxt? Why not use BC7 - it has much higher quality and most importantly you don't see the hue-shift which is so common with DXT.

-= Dave


Share this post


Link to post
Share on other sites

[quote name='clb' timestamp='1323117491' post='4890820']
Nice read!

I would love to see MJP's updated Error Statistics after YogurtEmperor's fixes to the algorithm.

Also, have you guys tried to compute the optimal/global minimum for this problem by brute-forcing through all relevant possibilities for the compression? (minus any obvious pruning of the search space to make it feasible to brute force) Having the global minimum SNR-wise in MJP's statistics would be a nice addition, to be able to estimate how far these algorithms go from the optimal. Of course that doesn't necessarily give the best perceptual result, but having a good raw number for the lower bound is useful when estimating how far it's possible to improve.


If you're targeting next-gen then why would you still use dxt? Why not use BC7 - it has much higher quality and most importantly you don't see the hue-shift which is so common with DXT.

-= Dave

[/quote]

DXT1 is still half the size compared to BC7 though if the quality is good enough for a given texture, or you could use the space savings to compensate with larger textures.

But yeah, it would be interesting to see what the mathematically optimal would be like, although it seems to me like it's pretty much as close as it gets in that picture. Perceptually, however might be more difficult... but as far as I can tell, no one seems to have been able to really provide a solid way to estimate perceptual quality. I saw some very high-tech NASA JPEG-encoder that boasted significantly lowered error values (it even allowed you to enter intended viewing distance, pixel density, etc), but to me the perceptual quality still ended up just noticably worse than the standard JPEG library implementation, despite the error values indicating otherwise.

Share this post


Link to post
Share on other sites

DXT1 is still half the size compared to BC7 though if the quality is good enough for a given texture, or you could use the space savings to compensate with larger textures.

But yeah, it would be interesting to see what the mathematically optimal would be like, although it seems to me like it's pretty much as close as it gets in that picture. Perceptually, however might be more difficult... but as far as I can tell, no one seems to have been able to really provide a solid way to estimate perceptual quality. I saw some very high-tech NASA JPEG-encoder that boasted significantly lowered error values (it even allowed you to enter intended viewing distance, pixel density, etc), but to me the perceptual quality still ended up just noticably worse than the standard JPEG library implementation, despite the error values indicating otherwise.


http://pdiff.sourceforge.net/


The above describes a technique they used on Shrek 2 for comparing if two images are perceptually equivalent.

Also, there are some good test images out there used to that are pretty standard for image comparisons when you are doing compression if you just read some of the literature.

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!