microsoft/directxtex

DirectXTex texture processing library

DirectXTex texture processing library

http://go.microsoft.com/fwlink/?LinkId=248926

Copyright (c) Microsoft Corporation.

March 6, 2024

This package contains DirectXTex, a shared source library for reading and writing .DDS files, and performing various texture content processing operations including resizing, format conversion, mip-map generation, block compression for Direct3D runtime texture resources, and height-map to normal-map conversion. This library makes use of the Windows Image Component (WIC) APIs. It also includes .TGA and .HDR readers and writers since these image file formats are commonly used for texture content processing pipelines, but are not currently supported by a built-in WIC codec.

This code is designed to build with Visual Studio 2019 (16.11), Visual Studio 2022, clang for Windows v12 or later, or MinGW 12.2. Use of the Windows 10 May 2020 Update SDK (19041) or later is required for Visual Studio. It can also be built for Windows Subsystem for Linux using GCC 11 or later.

These components are designed to work without requiring any content from the legacy DirectX SDK. For details, see Where is the DirectX SDK?.

Directory Layout

• DirectXTex\

  • This contains the DirectXTex library. This includes a full-featured DDS reader and writer including legacy format conversions, a TGA reader and writer, a HDR reader and writer, a WIC-based bitmap reader and writer (BMP, JPEG, PNG, TIFF, and HD Photo), and various texture processing functions. This is intended primarily for tool usage.

The majority of the header files here are intended for internal implementation of the library only (BC.h, BCDirectCompute.h, DDS.h, DirectXTexP.h, etc.). Only DirectXTex.h and DirectXTex.inl are meant as the 'public' header for the library.

• Auxiliary\

  • Contains optional source files for the DirectXTex library, such as adapter loading functions using the OpenEXR library, Xbox texture tiling extensions, etc.

• Texconv\

  • This DirectXTex sample is an implementation of the texconv command-line texture utility from the DirectX SDK utilizing DirectXTex rather than D3DX.

    It supports the same arguments as the Texture Conversion Tool Extended (texconvex.exe) legacy DirectX SDK utility. The primary differences are the -10 and -11 arguments are not applicable and the filter names (POINT, LINEAR, CUBIC, FANT or BOX, TRIANGLE, *_DITHER, *_DITHER_DIFFUSION). This also includes support for the JPEG XR (HD Photo) bitmap format.

• Texassemble\

  • This DirectXTex sample is a command-line utility for creating cubemaps, volume maps, or texture arrays from a set of individual input image files.

• Texdiag\

  • This DirectXTex sample is a command-line utility for analyzing image contents, primarily for debugging purposes.

• DDSView\

  • This DirectXTex sample is a simple Direct3D 11-based viewer for DDS files. For array textures or volume maps, the "<" and ">" keyboard keys will show different images contained in the DDS. The "1" through "0" keys can also be used to jump to a specific image index.

• DDSTextureLoader\

  • This contains a streamlined version of the legacy DirectX SDK sample DDSWithoutD3DX11 texture loading code for a simple light-weight runtime DDS loader. There are versions for Direct3D 9, Direct3D 11, and Direct3D 12. This performs no runtime pixel data conversions. This is ideal for runtime usage, and supports the full complement of Direct3D texture resources (1D, 2D, volume maps, cubemaps, mipmap levels, texture arrays, BC formats, etc.).

• ScreenGrab\

  • This contains texture writing modules for Direct3D 9, Direct3D 11, and Direct3D 12 primarily intended for creating screenshots. The images are written as a DDS or as an image file format using WIC.

• WICTextureLoader\

  • This contains a Direct3D 9, Direct3D 11 and Direct3D 12 2D texture loader that uses WIC to load a bitmap (BMP, JPEG, PNG, HD Photo, or other WIC supported file container), resize if needed based on the current feature level (or by explicit parameter), format convert to a DXGI_FORMAT if required, and then create a 2D texture. Note this does not support 1D textures, volume textures, cubemaps, or texture arrays. DDSTextureLoader is recommended for fully "precooked" textures for maximum performance and image quality, but this loader can be useful for creating simple 2D texture from standard image files at runtime.

DDSTextureLoader11, ScreenGrab11, and WICTextureLoader11 are 'stand-alone' versions of the same modules provided in the DirectX Tool Kit for DX11

DDSTextureLoader12, ScreenGrab12, and WICTextureLoader12 are 'stand-alone' versions of the same modules provided in the DirectX Tool Kit for DX12.

• build\

  • Contains YAML files for the build pipelines along with some miscellaneous build files and scripts.

Documentation

Documentation is available on the GitHub wiki.

Notices

All content and source code for this package are subject to the terms of the MIT License.

For the latest version of DirectXTex, bug reports, etc. please visit the project site on GitHub.

Release Notes

• Starting with the July 2022 release, the bool forceSRGB parameter for the CreateTextureEx and CreateShaderResourceViewEx functions is now a CREATETEX_FLAGS typed enum bitmask flag parameter. This may have a breaking change impact to client code. Replace true with CREATETEX_FORCE_SRGB and false with CREATETEX_DEFAULT.

• Starting with the June 2020 release, this library makes use of typed enum bitmask flags per the recommendation of the C++ Standard section 17.5.2.1.3 Bitmask types. This is consistent with Direct3D 12's use of the DEFINE_ENUM_FLAG_OPERATORS macro. This may have breaking change impacts to client code:

  • You cannot pass the 0 literal as your flags value. Instead you must make use of the appropriate default enum value: CP_FLAGS_NONE, DDS_FLAGS_NONE, WIC_FLAGS_NONE, TEX_FR_ROTATE0, TEX_FILTER_DEFAULT, TEX_FILTER_DEFAULT, TEX_FILTER_DEFAULT, CNMAP_DEFAULT, or CNMAP_DEFAULT.

  • Use the enum type instead of DWORD if building up flags values locally with bitmask operations. For example, DDS_FLAGS flags = DDS_FLAGS_NONE; if (...) flags |= DDS_FLAGS_EXPAND_LUMINANCE;

  • In cases where some of the flags overlap, you can use the | to combine the relevant types: TEX_FILTER_FLAGS filter modes combine with WIC_FLAGS, TEX_FILTER_FLAGS sRGB flags combine with TEX_PMALPHA_FLAGS or TEX_COMPRESS_FLAGS. No other bitwise operators are defined. For example, WIC_FLAGS wicFlags = WIC_FLAGS_NONE | TEX_FILTER_CUBIC;

• WICTextureLoader cannot load .TGA or .HDR files unless the system has a 3rd party WIC codec installed. You must use the DirectXTex library for TGA/HDR file format support without relying on an add-on WIC codec.

• The UWP projects and the Win10 classic desktop project include configurations for the ARM64 platform. Building these requires installing the ARM64 toolset.

• When using clang/LLVM for the ARM64 platform, the Windows 11 SDK (22000) or later is required.

• The CompileShaders.cmd script must have Windows-style (CRLF) line-endings. If it is changed to Linux-style (LF) line-endings, it can fail to build all the required shaders.

Support

For questions, consider using Stack Overflow with the directxtk tag, or the DirectX Discord Server in the dx12-developers or dx9-dx11-developers channel.

For bug reports and feature requests, please use GitHub issues for this project.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

Code of Conduct

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Trademarks

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.

Credits

The DirectXTex library is the work of Chuck Walbourn, with contributions from Matt Lee, Xin Huang, Craig Peeper, and the numerous other Microsoft engineers who developed the D3DX utility library over the years.

Thanks to Paul Penson for his help with the implementation of MemoryStreamOnBlob.

Thanks to Andrew Farrier and Scott Matloff for their on-going help with code reviews.

Thanks to Park DongHa for their contribution of the JPEG/PNG auxiliary functions.

directxtex's Issues

Adobe Photoshop Plug-in for DDS

A plug-in for Adobe Photoshop to support .DDS files based on DirectXTex to provide full support for all formats.

NVIDIA has a DDS plugin in for Adobe Photoshop, but it does not support the "DX10" header extension, BC6H, or BC7. https://developer.nvidia.com/nvidia-texture-tools-adobe-photoshop

Add support for generating octahedron environment maps

Engelhardt & Dachsbacher, "Octahedron Environment Maps", Visualization Research Center, University of Stuttgart. link

Cigolle et al, "A Survey of Efficient Representations for Independent Unit Vectors", Journal of Computer Graphics Techniques Vol. 3, No. 2, 2014. link

Lottes. "Fetching From Cubes and Octahedrons". AMD. link

BC5 compression broken?

Hello, when compressing to BC5_UNORM or BC5_SNORM there seems to be a problem with the generated dds. It can't be opened by any tool. Ddsview is able to open it, but it looks completly broken:

(it became all yellowish)

DirectXTex.lib file missing

I've searched everywhere in here for it, and it doesn't seem to be anywhere. any ideas? It's supposed to be in:
DirectXTex-master/DirectxTex-master/DirectxTex/Bin/Desktop_2015/Win32/Debug/DirectXTex.lib
Thanks.
Jeff

Slight shift in non-WIC point/nearest-neighbor

The image appears to shift slightly when doing the non-WIC point-filter. This shift doesn't happen with the WIC point filter.

Color information is lost on transparent pixels when using GenerateMipMaps

When using ::GenerateMipMaps to generate mipmaps on a texture with color-information stored in pixels that has a zero alpha-value, the color-information seems to be cleared. Is this intended behavior? I expected it to retain the color-information.

D3DX11Create*From* Sample

There's no directly equivalent DirectXTex function to the legacy D3DX11 functions D3DX11CreateTextureFromFile, D3DX11CreateShaderResourceViewFromFile, D3DX11CreateTextureFromMemory, and D3DX11CreateShaderResourceViewFromMemory. The same operations can be performed by DirectXTex, and generally these old functions are total overkill for most users.

However, a utility that demonstrates how to implement all the old 'full-fat' functionality' could be useful for porting as well as be a good sample of how to use DirectXTex in complex ways (rather than just texconv/texassemble).

Note that I won't be implementing the "ThreadPump" async loader behavior that is tied into some D3DX11 only tech

typedef enum D3DX11_FILTER_FLAG { 
  D3DX11_FILTER_NONE              = (1 << 0),
  D3DX11_FILTER_POINT             = (2 << 0),
  D3DX11_FILTER_LINEAR            = (3 << 0),
  D3DX11_FILTER_TRIANGLE          = (4 << 0),
  D3DX11_FILTER_BOX               = (5 << 0),
  D3DX11_FILTER_MIRROR_U          = (1 << 16),
  D3DX11_FILTER_MIRROR_V          = (2 << 16),
  D3DX11_FILTER_MIRROR_W          = (4 << 16),
  D3DX11_FILTER_MIRROR            = (7 << 16),
  D3DX11_FILTER_DITHER            = (1 << 19),
  D3DX11_FILTER_DITHER_DIFFUSION  = (2 << 19),
  D3DX11_FILTER_SRGB_IN           = (1 << 21),
  D3DX11_FILTER_SRGB_OUT          = (2 << 21),
  D3DX11_FILTER_SRGB              = (3 << 21)
} D3DX11_FILTER_FLAG, *LPD3DX11_FILTER_FLAG;

typedef struct D3DX11_IMAGE_LOAD_INFO {
  UINT              Width;
  UINT              Height;
  UINT              Depth;
  UINT              FirstMipLevel;
  UINT              MipLevels;
  D3D11_USAGE       Usage;
  UINT              BindFlags;
  UINT              CpuAccessFlags;
  UINT              MiscFlags;
  DXGI_FORMAT       Format;
  UINT              Filter;
  UINT              MipFilter;
  D3DX11_IMAGE_INFO *pSrcInfo;
} D3DX11_IMAGE_LOAD_INFO, *LPD3DX11_IMAGE_LOAD_INFO;

HRESULT D3DX11CreateTextureFromFile(
  _In_   ID3D11Device *pDevice,
  _In_   LPCTSTR pSrcFile,
  _In_   D3DX11_IMAGE_LOAD_INFO *pLoadInfo,
  _Out_  ID3D11Resource **ppTexture
);

HRESULT D3DX11CreateTextureFromMemory(
  _In_   ID3D11Device *pDevice,
  _In_   LPCVOID pSrcData,
  _In_   SIZE_T SrcDataSize,
  _In_   D3DX11_IMAGE_LOAD_INFO *pLoadInfo,
  _Out_  ID3D11Resource **ppTexture
);

HRESULT D3DX11CreateShaderResourceViewFromFile(
  _In_   ID3D11Device *pDevice,
  _In_   LPCTSTR pSrcFile,
  _In_   D3DX11_IMAGE_LOAD_INFO *pLoadInfo,
  _Out_  ID3D11ShaderResourceView **ppShaderResourceView
);

HRESULT D3DX11CreateShaderResourceViewFromMemory(
  _In_   ID3D11Device *pDevice,
  _In_   LPCVOID pSrcData,
  _In_   SIZE_T SrcDataSize,
  _In_   D3DX11_IMAGE_LOAD_INFO *pLoadInfo,
 _Out_  ID3D11ShaderResourceView **ppShaderResourceView
);

Code cleanup

DirectXTex was one of my first C++11 libraries, and I started it back in the Windows XP / VS 2010 days. As such, it's got a few lingering issues compared to my current coding style and usage:

• Replace LPVOID, LPCVOID, LPCWSTR with standard types
• Should use =delete
• Use anonymous namespaces instead of static
• Use VS standard 'smart-indent' formatting (otherwise I spend a lot of time fighting it to put back in the spaces)
• Leading _ in identifiers is reserved by the language for use by implementers; should minimize/remove them in case it causes problems with future compiler versions
• Don't need to keep the few conditional paths for Windows XP compat; Windows Vista or later is fine.
• I'm using '0' in a few places where I should be using nullptr

BC7 using only mode 6

One way to make a faster BC7 compressor is to only use mode 6, which essentially gives you the same results as BC3 with a few more bits of end-point color.

Undocumented error code on writing 80070003

Microsoft (R) DirectX 11 Texture Converter (DirectXTex version)
Copyright (C) Microsoft Corp. All rights reserved.

reading controls_controller.png (379x260 B8G8R8A8_UNORM 2D) as (379x260,9 BC3_UNORM 2D)
writing controls_controller.DDS FAILED (80070003)

WARNING: Not all feature levels support non-power-of-2 textures with mipmaps

WARNING: Direct3D requires BC image to be multiple of 4 in width & height

Note: The warnings are unrelated to the error code, I have been seeing these and I am intentionally not making the texture pow2 or mult-of-four.

Request: add documentation of all possible error codes to the Wiki.

Unsupported TGA file

I'm having problems with one .tga file (attached), texconv.exe fails to read it. It opens normally with paint.net and I'm not sure what the problem is.

F:\DirectXTex-master\Texconv\Bin\Desktop_2017\Win32\Debug>texconv.exe bad_file.tga
Microsoft (R) DirectX Texture Converter (DirectXTex version)
Copyright (C) Microsoft Corp. All rights reserved.
*** Debug build ***

reading bad_file.tga FAILED (80070032)

F:\DirectXTex-master\Texconv\Bin\Desktop_2017\Win32\Debug>

bad_file.zip

DirectXTex.lib file missing

Same Issue for texassemble compilation, missing .lib file.
Just curious if there are any other files that the compiler is going to look for AFTER this one is found, that may not have been uploaded to the repository. Would be worth a double check of all appropriate files.
I was actually just looking for a .exe file, and found the source code and project files instead..........sigh
Jeff

Convert to sRGB color space on load

Currently when loading WIC files we use explicit sRGB metadata to distinguish between 'normal 'and 'sRGB' formats. There's also a flag to ignore this metadata.

When loading images, however, some contain additional color information that can be used to convert to sRGB formats.

[Question] Raw .DDS Hex Headers, Using DirectXTex With C#?

Hullo there!

For the past few days, I've been making me first foray into C# through making a program to resize modern .dds files en masse. Me initial intention was to gear it towards Fallout 4, but it's probably usable for all games, so long as ya have the right textures.

Anywho, I've hit a stump. I think texconv.exe wants me to give it the format for the output texture, as there's some blatant texture corruption (super colorful edges around transparent textures, for example) going on. Thing is, I don't know how to rip out the file format from the .dds header.

Now, I have been able to get the first & second texture dimensions (x and y respectively?), with the first being @ offset +0c and the second @ offset +10, both of them being two bytes in size. The number of mipmap levels is @ offset +1c, but that's about as much as I could discern. Ya can read in detail here: https://github.com/MajinCry/Fallout-4-Texture-Resizer/blob/master/DDS%20Header%20Info.txt

So aye, any idea what the offset is to get the .dds format, and what the values at the offset correspond to?

Now, the above is fairly hackish, but I'm resorting to viewing & copying raw bytes, as I can't for the life of me add DirectXTex as a reference to my C# project. The wiki was fairly curt in regards to integrating DirectXTex with Visual Studio, sadly.

If it's possible, would ya be able to explain it like I'm a five year old? Me version of VS is 2013, if that's of any use.

Tah in advance!

Build error

I try to build the solution with VS 2015, it gives me the error below.

1> DirectXTexUtil.cpp
1>c:\program files (x86)\windows kits\8.1\include\um\wincodec.h(943): error C3646: 'PixelFormat': unknown override specifier
1>c:\program files (x86)\windows kits\8.1\include\um\wincodec.h(943): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

I had installed the DirectX SDK June 2010 on my PC. It seems, after I uninstalled the DirectX SDK, the build is fine. Why it conflicts to the DirectX SDK June 2010? Are there any way to walk around?

Thank you very much.
Dan

Add support for generating dual-parabola environment maps

Heidrich & Seidel, “View-independent Environment Maps”, Eurographics Workshop on Graphics Hardware, 1998. link

Zink, "Dual Paraboloid Mapping in the Vertex Shader".
link

Kilgard. "View Independent Environment Mapping with Dual Paraboliod Map". NVIDIA. link

Converting to/from cubemaps

Normal map averaging

Would you be interested a feature to calculate the blue channel of a normal map (Given R/G (X/Y))? It was included in the old NVidia tools and would make a great addition to the library, I'd be willing to write the code for this if you'd be willing to merge! Some flag like -navg or something...

Implement polyphase box filtering for improved non-power-of-2 support

The box filtering being used for 3D volume mip-generation as well as the non-WIC 2D case require power of 2 height & width. It is possible to generalize these into a polyphase filter that works with non-power-of-2 filtering.

This is detailed in this NVIDIA article

Improved HDR support

The DirectXTex library can read & write floating-point format DDS files, but the only 'source' HDR format it supports is JPEG XR / HD-Photo.

The library should have support for another HDR format, such as OpenEXR--see here and here--, and functions for converting between the various color spaces:

• Linear RGB
• Rec 709 color primaries / sRGB
• Rec 2020 color primaries
• scRGB
• Adobe RGB
• Adobe Wide Gamut RGB

Support TGA color-mapped files with expansion

The current TGA loader does not support TGA_COLOR_MAPPED or TGA_COLOR_MAPPED_RLE images. Legacy D3DX9 did support them, but loaded them as D3DFMT_P8 (i.e. 256-index palette).

While there are no palette DXGI formats, such TGA files could be expanded to B5G5R5A1_UNORM (bColorMapSize of 15 or of 16) or R8G8B8A8_UNORM (bColorMapSize of 24 or 32).

Fast Block Compress implementation

While intended for real-time rather than build time use, some needs for BC require having a way to quickly generate a BC image at runtime.

BC1 & BC3 algorithm from "Real-Time DXT Compression" by JMP van Waveren
link link link

BC5 algorithm from "Real-Time Normal Map DXT Compression" by JMP van Waveren & Ignacio Castaño link

It should also be possible to adapt the BC3 algorithm to generate BC7 mode 6 blocks.

DXTex rewrite using DirectXTex

The legacy DirectX SDK included the DirectX Texture Tool (DXTEX.EXE), a venerable MFC-based application for viewing all the various components of a DDS file, doing conversions, and creating more complex surfaces in an interactive manner. This tool suffers from numerous issues including no support for "modern" .DDS files, Direct3D 9 only, uses legacy D3DX9, etc.

A new tool should be created that replicates all the existing functionality using DirectXTex including full support for "DX10' DDS files; BC4, BC5, BC6H, and BC7 compression; texture arrays; and height-map to normal map conversions.

Using DXTex to save and load PNGs with SRGB

I have a code generated texture which I save to a file and then reload.

The sequence is:
Generate image data
SaveToWICFile
LoadFromWICFile
Use image data

When I do this saving to a PNG the data comes back having had some sort of gamma transformation applied to it.

If I use SaveToDDSFile / LoadFromDDSFile then the gamma transformation does not occur.

If I set the WIC_FLAGS_IGNORE_SRGB on the call to LoadFromWICFile then the gamma transformation also does not occur.

My internal pixel format is DXGI_FORMAT_R8G8B8A8_UNORM but I'm converting to DXGI_FORMAT_B8G8R8A8_UNORM before saving as this appears to result in more widely supported PNG files.

If I set the format to DXGI_FORMAT_B8G8R8A8_UNORM_SRGB then this doesn't seem to have any affect either way.

It seems like Save then Load of any particular format should always produce nearly the same result which does not appear to be the case.

Is this a bug or is this the intended behaviour?

My data is effectively SRGB, so I want it to be saved in and loaded untransformed. What is the correct way to achieve this?

Thanks

CompressGPU is unsupported for DirectX 12

The DirectCompute BC6H/BC7 codec is only implemented for DirectX 11. To complete DX12 support, the library should have a DirectX 12 version.

Add support for generating spherical environment maps

Spherical Environment Mapping (Direct3D 9)

Sphere mapping

Blinn & Newell, "Texture and Reflection in Computer Generated Images", Communications of the ACM. 1976.
link

Converting to/from cubemaps

Mipmap support for Kaiser / Lanczos filtering

The current filtering modes are only those supported by WIC. Some texture pipelines have implemented more advanced filtering, such as Kaiser or Lanczos filtering, which can produce higher-quality mipmaps.

Advanced filters like Kaiser are covered in this GD Mag article: part 1, part 2

MipMapCount == 0 ?

This is a question.

When converting textures to DDS using texconv, if you don't want mipmaps, you must specify -m 1. If you specify -m 0, the entire chain is generated and saved.

In the wild it is not uncommon to find DDS' which do not set DDS_HEADER_FLAGS_MIPMAP, and which set dwMipMapCount to 0. DirectXTex seems to want to force the behaviour of always setting that flag, and always having a non-zero value for dwMipMapCount

In DirectXTexDDS.cpp, in DecodeDDSHeader, if dwMipMapCount is 0, it is forced to 1. Then, in _EncodeDDSHeader, if dwMipMapCount is > 0, the DDS_HEADER_FLAGS_MIPMAP flag is set.

Should I take it as read, then, that mipmap-less (no flag, and dwMipMapCount == 0) is a deprecated DDS configuration?

WIC I/O Functions - DX12 version

Right now WIC I/O Functions seems to be supported with DX11. I'd like to know if there are any plans for DX12 version of WIC I/O Functions

Support PFM image file format

The old D3DX for Direct3D 9 library implemented a codec for .pfm (Portable Float Map)

Currently the only built-in HDR format supported by WIC is HDPhoto (aka JPEG-XR). As such, there's currently few choices for a source format for BC6H textures.

• LoadFromPFMMemory
• LoadFromPFMFile
• SaveToPFMMemory
• SaveToPFMFile

Remove VS 2012 adapter code

As part of dropping VS 2012 projects, can clean up the following code:

• Remove C4005 disable for stdint.h (workaround for bug with VS 2010 + Windows 7 SDK)
• Remove DIRECTX_STD_CALLCONV std::function workaround for VS 2012
• Remove DIRECTX_CTOR_DEFAULT / DIRECTX_CTOR_DELETE macros and just use =default, =delete directly (VS 2013 or later supports this)
• Remove DirectXMath 3.03 adapters for 3.06 constructs (workaround for Windows 8.0 SDK)
• Make use of std::make_unique<> (C++14 draft feature supported in VS 2013)
• Remove some guarded code patterns for Windows XP (i.e. functions that were added to Windows Vista)
• Make consistent use of = {} to initialize memory to zero (C++11 brace init behavior fixed in VS 2013)
• Remove legacy WCHAR Win32 type and use wchar_t

Chroma-key conversion

A number of older textures used chroma-keying since it was supported by DirectDraw and D3DX. Windows 10's Direct2D includes a Chroma-key effect.

A conversion function (and related texconv command-line option) for these older files would be a useful addition.

Support SNORM formats

Texconv will fail to load formats such as U8V8, U16V16 (R8G8_SNORM & R16G16_SNORM in D3D10 lingo).

Looking at dds files with these formats, it appears that they're exactly the same as their unsigned counter parts (e.g. R8G8_UNORM, R16G16_UNORM) except that the 'flags' member of the DDS_PIXELFORMAT structure has the DDPF_RGB bit unset, and the undocumented bit 0x00080000 set instead.

GPU Compression for BC1 - BC5

DirectXTex supports doing DirectCompute GPU compression of BC6H and BC7 images.

It does not yet have a BC1 - BC5 GPU compressor.

BC1 srgb to BC1

Hi I don't have a lot of experience with textures but I am doing my best to figure it out. I hope you can bear with me, I will try to give as much detail as I can. I am actually using this tool for modding purposes and it is great. What I am trying to do is convert a BC1 4bpp (sRGB DX10+) dds image to a BC1 4bpp (Linear) dds image. I am doing this because photoshop seems to be the only program that can open the first dds file and I just don't have the money for it. I am able to convert the image and have it work on paint.net but when I convert it back the image is lighter than it originally was. It is making me think that some of the dds files information is being lost in the process that you can't get back. Is this the case or is there a different reason for this happening?
Thank You for any help, RevCarl

PS this is what I am using to convert them:
texconv -f BC1_UNORM -srgbi -if LINEAR "C:\Users\kyle\Downloads\Arkham knight\Mods\resorep\retrieved textures\*.dds"
Then Back:
texconv -f BC1_UNORM_SRGB -srgbo -if LINEAR -bcdither "C:\Users\kyle\Downloads\Arkham knight\Mods\resorep\retrieved textures\Black and grey\DXGI_FORMAT_BC1_UNORM_SRGB\new\*.dds"

Retire Windows 8.1 Store, Windows phone 8.1. and VS 2013 projects

At some point we should remove support for these older versions in favor of UWP apps

DirectXTex_Windows81.vcxproj
DirectXTex_WindowsPhone81.vcxproj

This would also be a good time to retire the VS 2013 compiler support:

DirectXTex_Desktop_2013.vcxproj

Please put any requests for continued support for one or more of these here.

Support for loading/saving 'native' premultiplied WIC content

As part of the support for premultiplied alpha, the library will load DDS files with 'native' pm alpha data and preserve it with a metadata flag to indicate this, and the DDS writer respects this as well.

The WIC loader will currently always convert to 'straight alpha' before returning the data. The majority of the WIC built-in codecs do not support 'native' pm alpha pixel formats. There are one case that could potentially store 'native' pm alpha data.

TIFF

• GUID_WICPixelFormat32bppPBGRA
• GUID_WICPixelFormat64bppPRGBA
• GUID_WICPixelFormat128bppPRGBAFloat

These are all the WIC native pixel formats for pmalpha, although they are not returned by most of the built-in native codecs. They primarily exist for conversions.

• GUID_WICPixelFormat32bppPRGBA
• GUID_WICPixelFormat32bppPBGRA
• GUID_WICPixelFormat64bppPRGBA
• GUID_WICPixelFormat64bppPBGRA
• GUID_WICPixelFormat128bppPRGBAFloat
• GUID_WICPixelFormat64bppPRGBAHalf (WIC2+)

This work item would be to include these in the 'direct-load' DXGI mappings to avoid any conversion and then setting the metadata flag, and the converse.

TexConv - Corrupts Alpha Channel In DXT5 Texture

After trying multiple combinations of arguments (different mipmap levels, different resolutions, including -pmalpha and/or -sepalpha), it seems that the issue would lie more with TexConv than with anything else.

The texture is the "DirtPath01_D.DDS" that is used by Fallout 4. Running the texture through TexConv causes the alpha to corrupt,

Screenshot of the texture (after being resized through TexConv) itself: http://i.imgur.com/WsUPHd6.png
Screenshot of the texture used in-game: http://i.imgur.com/tGnc66N.png
I've attached an archive containing texconv.exe, the original texture file, the resultant texture file, the texture file to be processed and a .bat file.
Tex.zip

The .dds format used by the texture is BC3_UNORM_2D.

So aye, seems like TexConv doesn't like the alpha channel in that image for some reason, causing the pixels at the edge of the texture (where colour meets 100% transparency) to corrupt. The alpha channel itself, however, looks fine.

Loading or capture depth/stencil formats is unsupported for DirectX 12

In DirectX 11, depth/stencil formats are non-planar so DDS files are as well.

In DirectX 12, depth/stencil formats are planar.

Add LoadTextureFromTexture sample

The D3DX11LoadTextureFromTexture can be used to copy from one D3D11 texture to another starting with a specific source/dest box/rect, mip level, array element, num elements. It performs necessary conversions.

DirectXTex can be used to implement something like this using CopyRectangle, but it would be useful and informative to have a more full-featured LoadTextureFromTexture in the DirectXTex library.

The signature of the D3DX11 function this would replicate is:

typedef struct _D3DX11_TEXTURE_LOAD_INFO {  D3D11_BOX *pSrcBox;  D3D11_BOX
*pDstBox;  UINT      SrcFirstMip;  UINT      DstFirstMip;  UINT      NumMips;
UINT      SrcFirstElement;  UINT      DstFirstElement;  UINT      NumElements;  UINT      Filter;
UINT      MipFilter;} D3DX11_TEXTURE_LOAD_INFO;

This would need to handle decompressing / compressing BC blocks as well, although I may limit this to only decompressing.

Cubemap to and from cross

Tool to convert between cross layout images and cubemaps.

• h-strip (height, width *6): posz, posx, negz, negx, posy, negy
• h-strip-xyz (height, width * 6): pox, negx, posy, negy, posz, negz
• h-cross (height * 3, width * 4): negx, posz, posx, negz, posy, negy
• h-cross-flip
• v-cross (height * 4, width * 3): negx, posz, posx, posy, negy, negz
• v-cross-flip

Support PPM image file format

The old D3DX for Direct3D 9 library implemented a codec for .ppm (Portable PixMap).

• LoadFromPPMMemory
• LoadFromPPMFile

This includes both the ASCII P3 form and the binary P6 format for reading, but only binary P6 for writing.

Resource leak from _GetWIC()

_GetWIC() in DirectXTexP.h implements a singleton. The function stores a static pointer to a IWICImagingFactory. This resource is created on demand but never freed, showing up as a leak with some application verifiers.

Possible Workaround:
Caller can try _GetWIC()->Release() before exiting application.
The timing and code location of such cleanup may not be convenient.
EDIT: For whatever reason, calling Release() on the returned non-null pointer causes read access violation.

Proposed Solution:
As per other 3rd party libraries, create library Init() and Destroy() style functions. Perform whatever initialization and cleanup that may be required. Expose these functions with minimal dependency so they can be called at application startup and shutdown phases.

front-page link to texconv documentation is dead

Can just replace it with internal wiki link: https://github.com/Microsoft/DirectXTex/wiki/Texconv

Support HDR (RGBE) image file format

The old D3DX for Direct3D 9 library implemented a codec for .hdr (aka RGBE).

Currently the only built-in HDR format supported by WIC is HDPhoto (aka JPEG-XR). As such, there's currently few choices for a source format for BC6H textures.

• LoadFromHDRMemory
• LoadFromHDRFile
• SaveToHDRMemory
• SaveToHDRFile

This would include the 32-bit_rle_rgbe and 32-bit_rle_xyze encodings for lossless, rle (aka 'old format', and adaptive rle (aka 'new format').

D3DX9 would load 32-bit_rle_xyze color-space data, but didn't convert it to RGB. We will do the same thing here.

ATI2N (BC5) Conversion failing with error 80070032

Not sure why this is erroring out... http://prnt.sc/c9kuy7 Visual Studio is able to properly open the image files...

a bug of ddsview

ddsview.cpp line 249 should be rc.right = (LONG)mdata.width;

add support for filename wildcards to texconv

texconv and texassemble do not support wilcards like *.png as inputs.

Support for DirectX 12

Need to add overloads for DirectX 12 for:

• CreateTexture
• CreateShaderResourceView
• CaptureTexture
• Compress (GPU)

Are there any pre-compiled versions of this library?

Are there any pre-compiled versions of DirectXTex online that I can use?
I'm desperately trying to find a way to convert an image to the DX10 DDS format but I'm struggling to get DirectXTex to work in its GitHub form.
Being able to drag and drop my file onto a .exe file to convert it, or use a .bat file to convert it would be very appreciated! Thanks.

Issue with BC4 Compression + OptimizeAlpha

there seems to be an issue with OptimizeAlpha in relation to BC4 compression. The result is completely wrong.

Before : https://drive.google.com/file/d/0BzuqIF07GjT8NjZMQWpfZU1DelE/view?usp=sharing
After : https://drive.google.com/file/d/0BzuqIF07GjT8TXp1QkhRSEZVQzA/view?usp=sharing

This is a simple test of a BC4 decompressed as RGBA 32 then recompressed to BC4.
In the 2nd texel, the first block's end points are 84, 0. However, the BC4 compression outputs 84, 255. This seems to be where the problem starts since the only two available values in the texel are either 0 or 84.

This changes the color block size. It will now put twice "1f" in the palette (once as one of the endpoints and once for palette[7])

I think the problem starts in FindEndPointsBC4U.
bUsing4BlockCodec should be renamed to bUsing3BlockCodec and the following "if" reversed.
if (bUsing3BlockCodec) -> OptimizeAlpha for 6 gradients
else -> OptimizeAlpha for 8 gradients

I did modify this in my own code and the result, though still a bit amiss is much improved.

Thanks for looking into it.