DirectXTex texture processing library

Commented Task: Volume map generation support for MIRROR vs. CLAMP, LINEAR, and CUBIC [642]

walbourn — Mon, 20 May 2013 21:16:45 GMT

The current implementation of GenerateMipmaps3D() only implements POINT and FANT (aka box for down-sizing) filtering. It needs new filters written for LINEAR and CUBIC which should implement clamp vs. mirror (wrap-modes are not meaningful settings for point/box filtering).

WIC filtering can't be used because no concept of volume maps which must be merged together for proper mipchains.
Comments: ** Comment from web user: walbourn **

See related workitem [930](https://directxtex.codeplex.com/workitem/930)

Commented Task: Support for MIRROR/WRAP vs. CLAMP filtering for mipmap generation [641]

walbourn — Mon, 20 May 2013 21:16:43 GMT

DirectXTex uses WIC's IWICBitmapScaler object to resize images and to generate mipmap chains. WIC only supports "Clamp" filtering modes, so this doesn't always result in a properly tileable texture.

This would add TEX_FILTER_FLAGS for TEX_FILTER_MIRROR_U, TEX_FILTER_MIRROR_V, TEX_FILTER_MIRROR_W, TEX_FILTER_MIRROR to be supported by GenerateMipmaps[3D]().
Comments: ** Comment from web user: walbourn **

See related workitem [930](https://directxtex.codeplex.com/workitem/930)

New Post: SRGB support

walbourn — Mon, 20 May 2013 21:16:09 GMT

This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.

Created Unassigned: sRGB "gamma correct" filtering for mipmaps [930]

walbourn — Mon, 20 May 2013 21:16:08 GMT

The current implementation of 2D mipmap generation relies on WIC's filtering implementation. This currently supports only 2D pointer, box, and linear, and cubic filtering using "CLAMP" semantics.

The 3D mipmap generation does not use WIC and currently only supports point, box filtering.

There are already open work items to implement custom filtering options for [2D filtering](https://directxtex.codeplex.com/workitem/641) to support "WRAP/MIRROR" semantics as well as triangle filtering, as well as [3D filtering](https://directxtex.codeplex.com/workitem/642) to support linear, cubic, and triangle filtering.

This work item is to support "gamma correct" filtering for all 2D 'custom' filtering and all 3D filtering cases.

New Post: SRGB support

walbourn — Mon, 20 May 2013 20:44:14 GMT

The sRGB options currently just do SRGB color space conversion for Convert. This was previously not working correctly in all cases due to WIC not handling colorspace quite right.

The library is currently using WIC to do mipmap generation and resizing, which does not do "gamma correct" filtering. I have an open work item to write my own custom filters which will be "gamma correct".

See comments in Codeplex work item 641

New Post: SRGB support

doomtr666 — Mon, 20 May 2013 09:08:21 GMT

Hello,

I'm playing with texconv and can't figure out how the srgbi/srgbo/srgbe options works.
I tried to convert from an R8G8B8A8 png file to a BC1_UNORM_SRGB DDS. In this case, mipmap generation should be done with gamma correction. But the srgb options seems to have no effect.

I've also tested to convert the same file to BC1_UNORM using -srgbi indicating that the orignal image is in SRGB space, and should be de-gamma before mipmap generation and compression. Once again the option seems to have no effect.

I took a look to the texconv source code, and it seems that srgb options are only used in the convert stage (ligne 819), and since my output format is compressed, the code is never called.

Am I missing something, or srgb support is not working ?

Chris

New Post: Support for D3DFMT_A8L8

MVives — Thu, 16 May 2013 06:09:41 GMT

Great, thanks for following up on this!

— Mauricio

Edited Feature: Support for expanding L8, L16, A8L8 on load from .DDS [927]

walbourn — Wed, 15 May 2013 19:41:48 GMT

DirectXTex currently assumes that .DDS files for DDSPF_L8, DDSPF_L16, and DDSPF_A8L8 will be 'non-expanding' and rely on the shader to handle replication of rgb or moving alpha. This is also what DDSTextureLoader does.

DDSPF_L8 -> DXGI_FORMAT_R8_UNORM
DDSPF_L16 -> DXGI_FORMAT_R16_UNORM
DDSPF_A8L8 -> DXGI_FORMAT_R8G8_UNORM

This work item is a request to actually expand these so that no shader changes are required.

DDSPF_L8 -> DXGI_FORMAT_R8G8B8A8_UNORM (r,g,b replicated)
DDSPF_L16 -> DXGI_FORMAT_R16G16B16A16_UNORM (r,b,g replicated)
DDSPF_A8L8 -> DXGI_FORMAT_R8G8B8A8_UNORM (r,g,b replicated)

This will be controlled by a new flag DDS_FLAGS_EXPAND_LUMINANCE

> Note DDS_FLAGS_NO_LEGACY_EXPANSION conflicts with DDS_FLAGS_EXPAND_LUMINANCE, so specifying both with result in E_INVALIDARG.

Reference: [Legacy Formats](http://msdn.microsoft.com/en-us/library/windows/desktop/cc308051(v=vs.85).aspx)

New Post: Support for D3DFMT_A8L8

walbourn — Wed, 15 May 2013 19:40:56 GMT

This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.

Created Feature: Support for expanding L8, L16, A8L8 on load from .DDS [927]

walbourn — Wed, 15 May 2013 19:40:52 GMT

New Post: Support for D3DFMT_A8L8

walbourn — Wed, 15 May 2013 19:31:50 GMT

I actually wrote that table with a co-worker, so some of the mappings are already captured. The key issue is that you want no conversions in the shader, which means you'd rather have the texture get 'bigger' to avoid this.

There are a number of "Not Available" options that don't really come up in DDS files (Depth, VB, IB) or simply don't apply to Direct3D 10.x/11.x (bumpmap). The three I listed above really do seem to be the only cases where this applies.

New Post: Support for D3DFMT_A8L8

walbourn — Fri, 10 May 2013 00:46:57 GMT

Note: The DDSTextureLoader uses the same mappings because it does no conversions or expansions at all...

New Post: Support for D3DFMT_A8L8

MVives — Fri, 10 May 2013 00:13:41 GMT

I guess I wouldn't consider these as expanding or not. What is more important (at least for our purposes) is that alpha from the source ends up in alpha in the destination, and that luminance is replicated to RGB if expansion is required. In this case, DX11 simply doesn't support A8L8, and while R8G8 can store the data, the result is interpreted differently by default.

In other words, if I have a legacy DDS file (like A8L8) and I load it with DirectXTex to a supported format, and then save it again to DDS, will the two DDS files look the same in a DDS viewer? With the existing DirectXTex code, a grayscale A8L8 DDS file turns into a red/green R8G8 file.

That being said, more options wouldn't hurt here. If I were trying to be totally complete, I would use the following list...

http://msdn.microsoft.com/en-us/library/windows/desktop/cc308051(v=vs.85).aspx

... and make sure each "Not Available" entry has a reasonable story.

— Mauricio

New Post: Support for D3DFMT_A8L8

walbourn — Thu, 09 May 2013 23:49:03 GMT

So far I would think:

'standard' (non-expanding)

DDSPF_L8 -> DXGI_FORMAT_R8_UNORM
DDSPF_L16 -> DXGI_FORMAT_R16_UNORM
DDSPF_A8L8 -> DXGI_FORMAT_R8G8_UNORM

'alternative' (expanding)

DDSPF_L8 -> DXGI_FORMAT_R8G8B8A8_UNORM (r,g,b replicated)
DDSPF_L16 -> DXGI_FORMAT_R16G16B16A16_UNORM (r,b,g replicated)
DDSPF_A8L8 -> DXGI_FORMAT_R8G8B8A8_UNORM (r,g,b replicated)

Are there others?

New Post: Support for D3DFMT_A8L8

walbourn — Thu, 09 May 2013 23:45:08 GMT

The general assumption is that you are trying to preserve the 2-channel nature of the data. I could add an optional flag to the DDS loader to convert like this. Can you come up with a complete list of 'alternative' conversions and post it here?

New Post: DDSTextureLoader and auto-gen mipmaps?

walbourn — Thu, 09 May 2013 23:41:16 GMT

DirectXTex is a reasonable option to get full-featured support for scenarios like this, legacy .DDS file formats for conversion (say 24bpp which fail with DDSTextureLoader), general decompression and mip-gen.

New Post: DDSTextureLoader and auto-gen mipmaps?

MVives — Thu, 09 May 2013 23:05:14 GMT

Deathicon,

I needed a relatively seamless replacement for D3DX11CreateTextureFromFile(), which does such mipmap generation, so I ended up doing something similar to you. I am also in a position where the texture inputs are not necessarily artist-generated, and could require a lot of processing to use.

— Mauricio

New Post: Support for D3DFMT_A8L8

MVives — Thu, 09 May 2013 23:01:24 GMT

I noticed that the DDS loader converts D3DFMT_A8L8 files to DXGI_FORMAT_R8G8_UNORM. This will cause the alpha to be lost, and instead be used as green. I made some changes to instead convert it to DXGI_FORMAT_R8G8B8A8_UNORM. This does involve expansion, but at least the alpha is properly preserved, without requiring shader changes.

I am mentioning this here in case anyone encounters the same issue. The changes are in DirectXTexDDS.cpp. Let me know if you are interested in this.

— Mauricio

New Post: DDSTextureLoader and auto-gen mipmaps?

Deathicon — Thu, 09 May 2013 15:02:28 GMT

I totally agree with out regarding the fact that if they didn't export mipmaps, it shouldn't be mipmapped in the first place. But it turns out that in my application I use the mipmaps to control a blurring effect on reflections or image based lighting maps, which can be controlled by the user, and also animated. Because of that, I still need my mipmaps regardless if they were exported in the DDS file or not.

In the light of this, do you still believe it doesn't have its place in the DDSTextureLoader? Or perhaps we should tell the users that if they use DDS files, they need to bake the mipmaps themselves? Its just a lot less elegant to not be able to generate them ourselves.

New Post: DDSTextureLoader and auto-gen mipmaps?

walbourn — Wed, 08 May 2013 18:14:10 GMT

The general design of DDSTextureLoader is assuming you have properly 'cooked' all the texture options into it them most efficiency for a DDS, and is very light-weight. The WICTextureLoader is already having to do a fairly heavy-weight conversion, so it's pretty easy to support auto-gen mips. Also, auto-gen mips is not supported on any device for DXT/BC compressed data which is the most common usage case for a .DDS file over a traditional image bitmap format.

Personally, I would assume that if someone loaded a DDS file without mips, it wasn't intended to be mipmapped in the first place, but I don't know enough about your scenario to be sure.

Another alternative is to use DirectXTex and so a software-based mipmap generation on a DDS if needed which can also do software-based decompression of DXT/BC data.