Add dds to ktx2 lossless converter

[walcht]

Fixes #92.

Still in draft because testing isn't yet done (a bit difficult since I have to use my other BCn PR to test extracts) => is now ready for review (still a couple of missing edge-case test files and invalid dds test files).

Feel free to give an early review but this is still far from done.

[MarkCallow]

This is exciting. A DDS converter has been on our To Do list for a long time.

This together with your BCn codec and the format queries I mention in one of my comments will make a very nice addition to KTX-Software.

Looks good to me.

[walcht]

Does DDS use KTX_GL_UNPACK_ALIGNMENT?

I suspect you copied a comment from the KTX code that refers to handling for KTX v1 data. KTX v2 uncompressed images are always tightly packed.

It doesn't. I just left the comment there so that I verify if there is anything I have to worry about in terms of alignment. Good to know that KTX v2 is always tightly packed (less things to worry about).

I would like generate the reverse mapping from this data to use here but it requires Ruby coding which I am not very familiar with. It should be done from the database because then it is guaranteed spec. compliant.

I will try to figure this out. Ruby should be fairly simple to pick up, I'll open a PR in KTX-Specification if I manage to generate the enum.

What formats are not supported?

I left them commented out. Examples:

//  case TDDS_AYUV: return VK_FORMAT_UNDEFINED;
//  case TDDS_Y410: return VK_FORMAT_UNDEFINED;
//  case TDDS_Y416: return VK_FORMAT_UNDEFINED;
//  case TDDS_NV12: return VK_FORMAT_UNDEFINED;
//  case TDDS_P010: return VK_FORMAT_UNDEFINED;
//  case TDDS_P016: return VK_FORMAT_UNDEFINED;
//  case TDDS_420_OPAQUE: return VK_FORMAT_UNDEFINED;
//  case TDDS_YUY2: return VK_FORMAT_UNDEFINED;
//  case TDDS_Y210: return VK_FORMAT_UNDEFINED;
//  case TDDS_Y216: return VK_FORMAT_UNDEFINED;
//  case TDDS_NV11: return VK_FORMAT_UNDEFINED;
//  case TDDS_AI44: return VK_FORMAT_UNDEFINED;
//  case TDDS_IA44: return VK_FORMAT_UNDEFINED;
//  case TDDS_P8: return VK_FORMAT_UNDEFINED;
//  case TDDS_A8P8: return VK_FORMAT_UNDEFINED;

// ...

//  case TDDS_R16_UNORM_X8_TYPELESS: return VK_FORMAT_UNDEFINED;
//  case TDDS_X16_TYPELESS_G8_UINT: return VK_FORMAT_UNDEFINED;
//  case TDDS_P208: return VK_FORMAT_UNDEFINED;
//  case TDDS_V208: return VK_FORMAT_UNDEFINED;
//  case TDDS_V408: return VK_FORMAT_UNDEFINED;
//  case TDDS_R10G10B10_SNORM_A2_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_R4G4_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_G4R4_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_A4B4G4R4_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_X4B4G4R4_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_A4R4G4B4_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_X4R4G4B4_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_B4G4R4X4_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_R4G4B4A4_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_R4G4B4X4_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_B5G5R5X1_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_R5G5B5A1_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_R5G5B5X1_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_A1R5G5B5_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_X1R5G5B5_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_A1B5G5R5_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_X1B5G5R5_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_R5G6B5_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_B2G3R3_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_B2G3R3A8_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_G8R8_UNORM: return VK_FORMAT_UNDEFINED;
//  case TDDS_G8R8_SNORM: return VK_FORMAT_UNDEFINED;

I don't know what the X stands for in these formats. I also have no idea what the first formats are (e.g., AYUV).

[MarkCallow]

I don't know what the X stands for in these formats. I also have no idea what the first formats are (e.g., AYUV).

In Vulkan formats X means unused a.k.a. padding bits. AYUV is almost certainly a YUV format with alpha.

That database I mentioned is to DXGI formats. I do not know if those and DDS formats are equivalent or use the same enumeration values.

[walcht]

I will try to figure this out. Ruby should be fairly simple to pick up, I'll open a PR in KTX-Specification if I manage to generate the enum.

I couldn't get my head around Ruby so I re-wrote the Ruby scripts in Python. I will open a PR feel free to accept it or close it (at least some Python equivalents can be referred to in PR search).

I'm finalizing the testsuite (there are quite a lot of combinations to test). There are also some issues with tinydds.h with regards to arrays/volumes/cubemap arrays (which apparently are supported). I will add another comment about these later.

[MarkCallow]

I couldn't get my head around Ruby so I re-wrote the Ruby scripts in Python. I will open a PR feel free to accept it or close it (at least some Python equivalents can be referred to in PR search).

We want to keep everything in the spec. repo. Ruby, which we need for Asciidoctor, in order to minimize dependencies so I won't accept the PR. Could the Python version of the DXGI to VkFormat generator you created be useful for working on a Ruby version?

What is the answer to my TDDS vs DXGI question?

[walcht]

Could the Python version of the DXGI to VkFormat generator you created be useful for working on a Ruby version?

I will try to translate it and open it as a PR in Ruby but I have never programmed in it before.

What is the answer to my TDDS vs DXGI question?

Ah, I forgot to answer. They are the same (as far as I see they map one-to-one). So once we generate DXGI -> VkFormat the TinyDDS -> VkFormat is trivial. More details:

TinyDDS_Format tinydds_format = TinyDDS_GetFormat(handle); // returns format in this TinyDDS-specific struct `TinyDDS_Format`
if (tinydds_format < TDDS_SYNTHESISED_DXGIFORMATS) {
   DXGI_FORMAT dxgi_format = static_cast<DXGI_FORMAT>(tinydds_format);  // they map 1-to-1
} else {
   // unsupported format (see comment below)
}

The formats that cannot be translated from TinyDDS to DXGI_FORMAT are these:

KTX-Software/external/basis_universal/encoder/3rdparty/tinydds.h

Lines 333 to 387 in 7b08882

	TDDS_G4R4_UNORM = TDDS_SYNTHESISED_DXGIFORMATS,
	TDDS_A4B4G4R4_UNORM,
	TDDS_X4B4G4R4_UNORM,
	TDDS_A4R4G4B4_UNORM,
	TDDS_X4R4G4B4_UNORM,
	TDDS_B4G4R4X4_UNORM,
	TDDS_R4G4B4A4_UNORM,
	TDDS_R4G4B4X4_UNORM,
	TDDS_B5G5R5X1_UNORM,
	TDDS_R5G5B5A1_UNORM,
	TDDS_R5G5B5X1_UNORM,
	TDDS_A1R5G5B5_UNORM,
	TDDS_X1R5G5B5_UNORM,
	TDDS_A1B5G5R5_UNORM,
	TDDS_X1B5G5R5_UNORM,
	TDDS_R5G6B5_UNORM,
	TDDS_B2G3R3_UNORM,
	TDDS_B2G3R3A8_UNORM,
	TDDS_G8R8_UNORM,
	TDDS_G8R8_SNORM,
	TDDS_R8G8B8_UNORM,
	TDDS_B8G8R8_UNORM,
	TDDS_A8B8G8R8_SNORM,
	TDDS_B8G8R8A8_SNORM,
	TDDS_R8G8B8X8_UNORM,
	TDDS_B8G8R8X8_UNORM,
	TDDS_A8B8G8R8_UNORM,
	TDDS_X8B8G8R8_UNORM,
	TDDS_A8R8G8B8_UNORM,
	TDDS_X8R8G8B8_UNORM,
	TDDS_R10G10B10A2_SNORM,
	TDDS_B10G10R10A2_UNORM,
	TDDS_B10G10R10A2_SNORM,
	TDDS_A2B10G10R10_UNORM,
	TDDS_A2B10G10R10_SNORM,
	TDDS_A2R10G10B10_UNORM,
	TDDS_A2R10G10B10_SNORM,
	TDDS_G16R16_UNORM,
	TDDS_G16R16_SNORM,

[walcht]

Add a note that this is ignored if the input type is not ktx and make sure the implementation follows the note.

There is this comment already that addresses it, no? Ignored unless @b type is @c ktx.
I verified the implementation and this option is only used in convertKtx function.

[MarkCallow]

30a7e76 has an incorrect commit id for tests/cts. The id does not exist. Hence the build failures.

[walcht]

Yes, I always keep forgetting to push local CTS changes. Apologies for the mess/many CI runs.

On a side note, I'm trying to clean-up all my currently open PRs so that they are finally finalized.

[walcht]

There is an edge case where UNORM textures are actually storing sRGB values and so they should be somehow mapped to sRGB (e.g., GIMP DDS exporter always exports UNORM). I haven't looked at this yet but hopefully there is some field in DDS that indicates what colorspace (or at least whether sRGB) is the data saved in.

[MarkCallow]

There is an edge case where UNORM textures are actually storing sRGB values and so they should be somehow mapped to sRGB

Ouch! That definitely needs fixing. Sounds like a bug in the GIMP exporter to me.

[walcht]

Sounds like a bug in the GIMP exporter to me

It's probably not. Even for older versions of NVTT sRGB is being exported as UNORM and not UNORM_SRGB because viewers (at that time) did not support UNORM_SRGB textures. You can read some details here:
https://forums.developer.nvidia.com/t/color-conversion-exceptions-using-nvtt-export/219142

Also bc7enc_rdo does not save sRGB DDS files as UNORM_SRGB. From their source code:

		// Not all tools support DXGI_FORMAT_BC7_UNORM_SRGB (like NVTT), but ddsview in DirectXTex pays attention to it. So not sure what to do here.
		// For best compatibility just write DXGI_FORMAT_BC7_UNORM.
		//hdr10.dxgiFormat = srgb ? DXGI_FORMAT_BC7_UNORM_SRGB : DXGI_FORMAT_BC7_UNORM;
		hdr10.dxgiFormat = dxgi_format; // DXGI_FORMAT_BC7_UNORM;
		hdr10.resourceDimension = D3D10_RESOURCE_DIMENSION_TEXTURE2D;
		hdr10.arraySize = 1;

A great argument on why KTX is superior to DDS is that we have the KHR_DF_TRANSFER_* field for each KTX file regardless of the set vkformat.

At worst, we might just add a flag to force to-sRGB vkFormat conversion even if input is UNORM.

I will address this once I finalize the BCn PR.

[MarkCallow]

A great argument on why KTX is superior to DDS is that we have the KHR_DF_TRANSFER_* field for each KTX file regardless of the set vkformat.

KTX has rules that allow "mismatched" VkFormat and KHR_DF_TRANSFER only in limited circumstances. Using a UNORM format with KHR_DF_TRANSFER_SRGB when there is a matching SRGB format is not one of those. It is explicitly disallowed.

At worst, we might just add a flag to force to-sRGB vkFormat conversion even if input is UNORM.

This would not be conversion. It would be assignment, --assign-oetf in ktx create. Only possible if the DDS file provides an indication that the data is really sRGB. If there is no indicator, I suggest raising a fatal error with a brief explanation about broken DDS tools and guiding them to use --assign-oetf to specify the correct OETF to avoid the error.

I will address this once I finalize the BCn PR.

Please. There is no rush as I will not be merging the converter until v5.0.0 is released. Unfortunately I do not know how much longer it will be until the item blocking its release is resolved. It has nothing to do with the software.

[MarkCallow]

because viewers (at that time) did not support UNORM_SRGB textures. You can read some details here

What a shit show. In my view broken viewers are no excuse for a texture creation tool to be outputting incorrect data.