You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
yeah I am also super curious and this... I am totally confused. It looks like everything is treated as linear. Which is fine... but would seem like you will lose precision for no reason at all... Knowing this supposed to be a quality SDK on how things should be done it feel strange... I feel like I am missing something from some where. But I do not know what... Also the DDS files are saved as linear which makes me feel like there is a horrible dark elephant in the room... Please help clarify this issue.
UPDATE:
OK I did bit more research...
The library assumes the the user tracks if the image is gamma or linear and ask the SDK for do the right things...
Independently if the input image could have known if it was a gamma texture or not.
Respect to the DDS file:
Seems like DDS is kind of a broken file format where people always assumed that texture using this formats were gamma. That is why in most viewers looks OK. Later on they added an additional header in the file call DX10 which added more detail format which supports _SRGB. But since everyone already assumed the old version everyone ignored it (as we can see in compressonator.
To fixed it you either have to:
Make sure your image serializes with the DX10 header by doing this, after the compression (just in case).
MipSetCompressed.m_dwFourCC = CMP_MAKEFOURCC('D', 'X', '1', '0');
Which will force the DDS serializer to add the header as explained.
Then you have 2 options:
a) fseek to DDS file to 128 and fwrite the correct format.
or
b) Write your own version of the DDS serializer.
compressonatorcli not support BC1/2/3/6H/7_srgb format?
The text was updated successfully, but these errors were encountered: