DDS Compression Types

[BrokenPillar]

He didn't save anything, that is off of the article that Niosop linked to, and he should read the article a little more closely. The images that he compares are done two different ways. In the first, all 3 channels are stored in the RGB channels:

# input.x = normal.x [0, 1]

# input.y = normal.y [0, 1]

# input.z = normal.z [0, 1]

# input.w = 0

In the second one, one of the channels is being stored in the alpha channel:

# input.x = normal.x [0, 1]

# input.y = normal.y [0, 1]

# input.z = 0

# input.w = normal.z [0, 1]

 

In particular, better quality normal map compression can be achieved by using the DXT5 format and moving one of the components to the alpha channel.

 

I did listen to the people who developed the DXT format (That is where I got my information). The reason I am spending time on this is that it has a very large impact on how much memory will be used for textures. There is no difference in quality when you are using only the Red Blue and Green channels.

 

You can also just save out any diffuse texture both ways and compare them yourself.

 

Now whether it would be worth not using the alpha as a spec channel and creating a shader that can read the alpha in for one of the normal channels (like in DTX5nm) is a different matter.

[Niosop]

Well, a DXT5nm shader is pretty trivial to implement and most image programs w/ DXT plugins support output in DXT5nm. But it's not nearly as nice as BC5 which would require support by the engine (I think). Think you might add support for it sometime Josh? Or is this something that we can do just as efficiently ourselves?

[VicToMeyeZR]

No it is not. The second DXT5 image is SOLELY on the RGB channel. I did NOT pull the image from the re-normalize one where they DID use the Alpha Channel.. This is STRAIGHT difference between the DXT1, and DXT5 RGB channels ONLY.

[BrokenPillar]

Those images are the images from the doc, right? Their is no DXT5 image on that document for the object space normal map (that you are showing) that was saved with all three channels in RGB. The only DXT5 object space normal map image on that document was saved with one of the channels in the alpha. Again, read the document very closely.

 

The DXT5 format is designed for color textures with a smooth alpha channel. However, this format can also be used to store object-space normal maps. In particular, better quality normal map compression can be achieved by using the DXT5 format and moving one of the components to the alpha channel. By moving one of the components to the alpha channel this component is stored with more precision.

That paragraph is on top of the image that you showed for DXT5.

 

The easier test though is just to save out an image as DXT1 and then as DXT5 (with no alpha) and compare. They are identical.

[VicToMeyeZR]

I think your not looking close enough...

 

Here, a PSD image, saved as DXT1 no alpha. The bottom is DXT5 No alpha.

 

 

 

So bottom is DXT5 top is DXT1. Clearly there is a slight difference.

 

ok, that didn't attach right.

 

 

Edited February 11, 2010 by VicToMeyeZR

[BrokenPillar]

I am not sure how or what you are saving with. Make sure that you are not saving with DXT1 with 1 bit alpha as that will reduce the RGB channel quality because in that case the 1 bit alpha is being stored at the expense of some of the information in the RGB channels. The RGB channels in DXT5 are saved using the exact same compression method as the RGB channels in DXT1 (without 1 bit alpha).

 

 

This article explains it completely:

http://www.fsdeveloper.com/wiki/index.php?title=DXT_compression_explained

[VicToMeyeZR]

Are you having a hard time with this? DXT1 with NO ALPHA..

 

You can't take an image I already saved and re-save it, and call it the same. This is from an original PSD, no compression. Saved as DXT1 NO ALPHA, and DXT5.

 

They are different.

 

Why are you referring to someone else's article, that is probably using flawed logic again?

 

Case closed..... Like I said, is the space used for DXT5 worht it if you don't use an alpha channel is up to you, but I will stick with my process

[BrokenPillar]

You can if you save from a screen dump to DXT1, then from the same screen dump to DXT5, if it is meant to compare the difference between the two methods.

 

And why should I trust that article and my own tests that I have performed by saving several textures using both methods and comparing less than your opinion?

 

or here it is again on nVidias site:

http://developer.nvidia.com/object/real-time-ycocg-dxt-compression.html

The DXT5 format [2, 3] stores three color channels the same way DXT1 does, but without 1-bit alpha channel.

 

here it is again on Wikipedia:

http://en.wikipedia.org/wiki/S3_Texture_Compression

DXT4 and DXT5 converts 16 input pixels into 128 bits of output, consisting of 64 bits of alpha channel data (two 8 bit alpha values and a 4x4 3 bit lookup table) followed by 64 bits of color data (encoded the same way as DXT2 and DXT3).

DXT2 and DXT3 converts 16 input pixels into 128 bits of output, consisting of 64 bits of alpha channel data (four bits for each pixel) followed by 64 bits of color data, encoded the same way as DXT1

 

or from another forum thread on Polycount:

http://boards.polycount.net/showthread.php?t=67519

Unless you're using a shader permutation, you aren't going to notice a quality increase going from DXT1 to DXT5, you'll just have an alpha channel that now has the same compression quality of all three (RGB) channels combined, hence the doubling of memory going from DXT1 to DXT5. Unless I'm mistaken, the RGB channel compression ratio of a DXT1 and DXT5 are both a 5:6:5 compression ratio.

[VicToMeyeZR]

ok, fine you win. Taking a image already saved with compression, and re-saving again with a different compression is the same, as saving an uncompressed to that compression... I just did the test, and proved they are different.

 

Compression ratio of DXT1 is a fixed 8:1

[BrokenPillar]

I meant that it was a valid comparison between the two images I saved using both methods, not as a comparison against the images you displayed.

 

Yes, and DXT5 is a 4:1 ratio, but the RGB channels in both methods are a fixed 5:6:5. All of the additional bit information in a DXT5 is in the alpha channel.

 

I am just trying my best to help out here, VicToMeyeZR, not try to be confrontational or argumentative. I am new to the forum and community, but am not new to real time graphics. Every article that I can read or find on the topic says the same thing and every test I have performed shows the same thing, that there is no difference in bit quality or compression method in the RGB channels of a DTX1 and DXT5.

[VicToMeyeZR]

I understand what you are saying, but nvidia themselves said its similar, not identical, and I tested it, just like you said to do, and it clearly shows a difference down in the pixel levels of the two images.

 

Ok, here..... The compression ratio of the overall image of DXT5 is 4:1 and DXT1 is 8:1, so YES, the RGB channels are stored the same, but you have to think of the OVERALL compression of the file. 8:1 vs. 4:1, that is where the difference comes into play.. SO if you re-open the images, after saving them, because of the compression difference, you see a different pixelation of the two images.

 

I'm not aurguing, I think we are basing on the same thought process, but forgetting the main compression of the image.

[BrokenPillar]

I did re-open them after saving and I get no difference no matter how far I zoom in on them. I have saved out the results, closed them and re-opended them, and then posted them. They are identical. The overall compression ratio difference is all contained within the Alpha channel. DXT1 is 8:1, DXT5 is 4:1, but all of the additional bit information is in the Alpha channel. I think you are assuming since their are more bits in DXT5 (meaning a better compression ratio) that the RGB channels have to be better. But this would only be the case if some of the additional bits went to the RGB channels, which they don't. The RGB channels are always 5:6:5, but the DXT1 has no Alpha while the DXT5 has an alpha with as much bit information as the entire RGB channels combined, giving it the higher overall compression ration of 4:1. None of it is in the RGB channels, which are done the same way for both. Nvidia says they are the same, not similar:

 

The DXT5 format [2, 3] stores three color channels the same way DXT1 does

http://developer.nvidia.com/object/real-time-ycocg-dxt-compression.html

[Niosop]

Ok, I decided to do some testing that doesn't rely on subjective measurements of "can you tell the difference between these two images". Just so the results can be duplicated I'm using Gimp w/ the DDS export plugin.

 

I started w/ a JPEG image. I saved this same image out as a DXT5 compressed image and a DXT1 (no alpha) compressed image (both saved from original JPEG). Then I loaded both of the DXT compressed images as layers into the same image. I set the top layer (the DXT1) image layer mode to difference and the bottom layer (DXT5) to normal. I then flattened the image and adjusted the brightness and contrast to enhance any differences. There were none. I swapped the order and blending modes of the layers and did the same, same result, no differences in pixel color.

 

I then did the same w/ one of the DXT images and the original to ensure this method properly detects differences. The differences in pixels were a little faint before adjusting the brightness/contrast, but once that was adjusted you could VERY clearly see the differences, so I know the method is valid.

 

So I'm going to have to go w/ BrokenPillar on this one. If your DDS exporter is working properly, there is NO difference between a DXT1 (no alpha) compressed image and a DXT5 compressed image as far as the RGB color of the pixels is concerned.

 

If anyone can't duplicate these results on their own, or wants a video demonstrating my testing method, I'll be glad to provide one.

[BrokenPillar]

wow. Smart test Niosop. Wish I would have thought about that yesterday, would have saved me some time and trouble.

 

I just tried it in Photoshop from a PSD to a DDS the same way. I got the same results.

[VicToMeyeZR]

Thats quite funny. MY image clearly shows a difference. Photoshop CS4 with nvidia's plugin.

[Niosop]

Hmm, wonder what's going on there. Plugin error, different settings...odd. Mind posting a quick video of your workflow VicToMeyeZR so we can see what the issue might be? I don't have PS (gimp is good enough for me), but someone here might be able to follow along and figure out what's going on.

[VicToMeyeZR]

I can when I get back home. I am out of town tonight.

[VicToMeyeZR]

I think I found my problem. I had always done it this way before, and I never thought about it. Maybe thats why I always thought there was a difference....

 

(I can admit when i might be wrong. )

 

I clicked save as then saved as a DXT5, then save as and saved DXT1... hmm ooops. So effectively, I was compressing it as a DXT5 then compressing that image as a DXT1, which is where the pixelation was coming from.

 

Man I hate being wrong. lol.... damn it. now I feel like a retard.

[Niosop]

LOL, it happens...I pretty much just gave up and started assuming I am a retard (don't let Palin hear you use that word, she'll demand you get fired, hung, drawn and quartered, then eaten by lions), so when I do something halfway intelligent it's a pleasant surprise.

[BrokenPillar]

It's ok, I'm just glad Niosop figured out an objective test to figure it out. Plus now I know way more about DXT compression types than I did three days ago. When I first started reading this thread I was worried I might have to go and try to convince my work to let me convert our entire diffuse texture library into DXT5.

 

I think I am going to start a new thread talking about trying out the DXT5nm and 3Dc compression methods.