directxtex Issue Tracker Rss Feed

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)

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.

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)

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

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

Commented Issue: BC7 Decoder Output for "Reserved Mode" 8 is not as described in the BC7 Format Mode Reference [890]

walbourn — Fri, 03 May 2013 19:42:13 GMT

Decompressing a BC7 file where a block has LSBs of 0x00 results in an opaque black texture. However, the BC7 Format Mode Reference page (http://msdn.microsoft.com/en-gb/library/windows/desktop/hh308954(v=vs.85).aspx) states that if such a block is decompressed "a block initialized to all zeroes is returned", which would suggest that the output should be transparent black.

For an example, see the attached files. bc67ReservedMode.dds is a BC7 compressed texture where the block data is set to all-zeroes. Decompressing this texture with:

```
texconv -f R8G8B8A8_UNORM -m 1 -sx _DEC bc67ReservedMode.dds
```

gives the opaque black output texture bc67ReservedMode_DEC.DDS
Comments: ** Comment from web user: walbourn **

Notes from developer on this issue:

_Question is, what does it mean if a block is all 0? If it is a 3 channel block, the alpha is supposed to be 1.0. If a 4 component block, that makes alpha 0.0. I’d say transparent black is more consistent with the blanket statement of all 0. Another argument for this is that when for other formats that talk about reserved encodings (BC6H), they explicitly call out when alpha should be 1.0. BC7 doesn’t do this, so transparent black seems appropriate._

Closed Issue: skipMip not correctly calulcated for cubemaps and texture arrays [920]

walbourn — Fri, 26 Apr 2013 22:15:48 GMT

In FillInitData() in DDSTextureLoader.cpp, Ln 729 the skipMip variable is arraySize times too big if arraySize is > 1. So for cubemaps or texture arrays it is wrong and results in an invalid (huge) desc.MipLevels value. Moving the line skipMips = 0; line into the arraySize loop is one way to fix it.
Comments: Resolved with changeset 26924: DDSTextureLoader fix for 1D/2D texture and cubemap arrays when skipping mips

Commented Issue: skipMip not correctly calulcated for cubemaps and texture arrays [920]

walbourn — Thu, 25 Apr 2013 23:52:45 GMT

Thanks for the report. I think the better way to solve this is to add if ( !j ) to the condition so that skipMip is only incremented for the first array item (it is the same for all items in the array)

```
else
++skipMip;
```

should be

```
else if ( !j )
++skipMip;
```

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

walbourn — Thu, 25 Apr 2013 22:44:00 GMT

After some more digging, I found that the D3DX flags are actually to use a "MIRROR" model instead of a "WRAP" model. It uses a WRAP model by default. The "MIRROR" behavior is actually more like a CLAMP because it only addresses an off-by-1 scenario.

For DirectXTex I think I'll stick with CLAMP by default but add TEX_FILTER_WRAP_U, TEX_FILTER_WRAP_V, TEX_FILTER_WRAP_W.

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

walbourn — Thu, 25 Apr 2013 18:42:21 GMT

D3DX is actually a little sloppy in the Direct3D difference of mirror vs. wrap. The D3DX MIRROR flags actually treat it as Direct3D would 'wrap' in some cases. Generally these flags are just indicating 'tile' vs. 'non-tiled' treatment in the mipmap generation anyhow.

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

walbourn — Wed, 24 Apr 2013 17:38:42 GMT

For the general case of Resize, I plan to stick to using the WIC only implementation and to focus instead on custom filtering for the GenerateMipmaps[3D] scenarios. General image resizing with high-quality is already done pretty well with WIC.

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

walbourn — Wed, 24 Apr 2013 17:37:49 GMT

D3DX only provided a MIRROR flag set (MIRROR_U, MIRROR_V, MIRROR_W) and did not have a specific WRAP mode. That's because for tileable textures, the difference should be minimal. This saves a lot of implementation complexity as well. Therefore, I'm going to work on the assumption that just having a MIRROR flag set (with clamp being the default) is sufficient.

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

walbourn — Wed, 24 Apr 2013 17:36:54 GMT

Created Issue: skipMip not correctly calulcated for cubemaps and texture arrays [920]

mciragan — Fri, 19 Apr 2013 12:07:20 GMT

Closed Task: Ensure proper SRGB handling [643]

walbourn — Wed, 17 Apr 2013 00:51:37 GMT

The explicit use of _SRGB dxgi formats or the filtering flags TEX_FILTER_SRGB_IN, TEX_FILTER_SRGB_OUT, TEX_FILTER_SRGB should be respected for conversions, resizing, and mipmap generation. While it is partially implemented, WIC-based conversions and resizing isn't properly using those flags.

Furthermore, Use of IWICFormatConverter implicitly assumes all integer content is sRGB and all fixed/float content is scRGB so there's an implicit conversion of color space which is not desired. This is particularly concerning because for many DXGI formats, this interface is used to convert content to 128bpp float for SIMD-based CPU processing by DirectXTex and then converted back. These code paths all need validation that they properly preserve or change sRGB as requested by the client.

Note: IWICColorTransform is not as useful here as hoped because it will fail when given any fixed-point or floating-point format.
Comments: Resolved with changeset 26378: DirectXTex: Resolve SRGB handling problems with conversions
- Convert: TEX_FILTER_FORCE_NON_WIC, TEX_FILTER_FORCE_WIC, TEX_FILTER_RGB_COPY_RED/BLUE/GREEN
- ComputeMSE flags for sRGB colorspace and channel ignore options

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

walbourn — Tue, 16 Apr 2013 05:39:08 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, MIRROR, and WRAP (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 **

Do the filtering in linear space as well (i.e. convert sRGB on input & output, possibly moving it to Load/StoreScanline)

Commented Task: Support for MIRROR and WRAP filtering for resize and mipmap generation [641]

walbourn — Tue, 16 Apr 2013 05:38:08 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, TEX_FILTER_WRAP_U, TEX_FILTER_WRAP_V, TEX_FILTER_WRAP_W, TEX_FILTER_WRAP to be supported by Resize() and GenerateMipmaps().
Comments: ** Comment from web user: walbourn **

Do the filtering in linear space as well (i.e. convert sRGB on input & output, possibly moving it to Load/StoreScanline)

Commented Task: Ensure proper SRGB handling [643]

walbourn — Tue, 16 Apr 2013 05:37:54 GMT

I'll keep that in mind when doing the [custom filtering work](https://directxtex.codeplex.com/workitem/641). WIC-based resize and generate-mipmaps is basically doing to do whatever it wants.

Commented Task: Ensure proper SRGB handling [643]

alexandre_mutel — Tue, 16 Apr 2013 02:23:53 GMT

^ meant "not something that is well known"

Commented Task: Ensure proper SRGB handling [643]

alexandre_mutel — Tue, 16 Apr 2013 02:22:45 GMT

Actually, mipmapping for color textures should be computed in linear space and not in srgb space, for exactly the same reason shader lighting should be done in linear space (with texture fetching values in linear space). This problem is described in "[The Importance of being Linear](http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html)", look for mipmap. Also, there is "[Gamma and Mimap](http://filmicgames.com/archives/327)" that is worth the visual demonstration of calculating a mipmap in srgb instead of linear space.
It is not something that is not well known (even Photoshop is doing it wrong!), but working on a fully gamma correct pipeline/rendering is requiring to handle resize/mipmaps carefully regarding srgv/linear spaces