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

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.

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

In DirectX 12, depth/stencil formats are planar.

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

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.

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

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

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

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"

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

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.

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)

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?

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

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

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.

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

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.

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.

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

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.

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.

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

Need to add overloads for DirectX 12 for:

• CreateTexture
• CreateShaderResourceView
• CaptureTexture
• Compress (GPU)

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).

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...

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
);

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

_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.

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

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.

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

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.

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

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

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.

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

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

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

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

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.

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

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

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

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.

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.

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

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.

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!

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

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.