Jump to content
  • Advertisement
Sign in to follow this  

NVTT is not SRGB accurate, possible to avoid generation ?

This topic is 620 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 use NVTT to convert RGBA8 to BC compressed format.
You have to set the gamma, so naturally I set 2.2f for the input gamma and output gamma.
But then I said in my head : "if that ask this param, that means it doew a pow and not an accurate SRGB conversion".
So, I looked the code and I see one function toSRGB but doing a find this function is never used, so basically only the pow is used.
But maybe the visual studio project doesn't have all the files too, so this is just assumptions, surely I'm wrong.
The problem of the pow using gamma is it only gives an approximation of the real SRGB values.
But then I said in my head : "Why ask it the gamma if I set myself the mipmaps generated ?"
I set the input option like that :

InputOptions.setMipmapGeneration( true, m_NumMipMaps );

And then I add each mipmap data I generated previously.
So the question : NVTT does the generation of mipmap ?
I set each mipmap data using setMipmapData :

InputOptions.setMipmapData( MipmapData, MipmapWidth, MipmapHeight, 1, 0, i );

NVTT see this mipmap data is set and doesn't generate the mipmap then ?
So the question is not about SRGB but more about if NVTT bypass the generation of mipmaps correctly.

Edited by Alundra

Share this post

Link to post
Share on other sites

IMHO in this case (mip map generation) difference between ^2.2 and proper sRGB is negligible, so you shouldn't worry about that. As for NVTT and mip map generation - just do a simple test. Provide some random data in mips (e.g. one mip level red, second green etc.) and check if NVTT outputs the same texture or if NVTT will generate new mips from the top level.

Share this post

Link to post
Share on other sites

I did the test of set all the mipmaps other than the first to a filled color and that gives me this color when zoom out so the question is solved, if you set mipmap it doesn't generate.
Which also solve the gamma question surely since when it compress I guess it doesn't convert sRGB<->Linear, I only use NVTT to convert RGBA8 to BC formats.

Share this post

Link to post
Share on other sites
My tool provides better quality and accuracy, and likely performance, in addition to more formats.

The default gamma setting is a full IEC 61966-2-1 compliant conversion rather than a pow() approximation.
It also uses a better filter for mipmaps so mipmaps will be sharper and clearer as well.

The command line for my tool should be identical to NVTT’s.

L. Spiro Edited by L. Spiro

Share this post

Link to post
Share on other sites

I did a test and the gamma is only used in the compression apparently because I tried to gives 188 values on RGB and I got 189 on the texture editor in BC1.
(128, 128, 128 ) gives (129, 128, 129) in BC1, since it's compressed it will never be perfect, the values are not far from the real values.
I generate all the mipmaps using the real conversion function as well and using image sampler based on Rich Geldreich image sampler.
But then if your tool gives better compression, it could be a good thing to look at, I also use -1.0f for the sRGB mode, we are similar on this point.
Only bad thing is your don't provide include + libs to integrate all in the tool instead of launching executable.
I also see you don't provide a way to avoid the gamma correction ? Do you bypass based on the image format ? Normal map for example doesn't need.
I see you have the "-norm" option which is important for the normal map indeed.
Maybe you bypass if the user set gamma 1.0 ? But if it's not bypassed it surely cause precision issue on the conversion from gamma 1.0 to linear which could be avoided.
But, since NVTT is only used to compress, it's surely something which could be removed as dependency for a custom code later, I doubt texture format will change soon.
About the normalize of value for the normal map generation, I guess it's better to do that during the resize to avoid to convert again float<->uint8.
Do you normalize based on the find of min/max on the whole image or for each pixel computing the length of the current pixel ?

Edited by Alundra

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!