<p>The tool seems to be generating an unofficial extended version of DDS in which the FOURCC code is replaced by a value from the <a href="https://docs.microsoft.com/en-us/windows/desktop/direct3d9/d3dformat" rel="nofollow noreferrer"><code>D3DFORMAT</code> enum</a>. The code <code>0x0000006F</code> translates to decimal 111, which translates to <code>D3DFMT_R16F</code>.</p>

<p>The Microsoft DDS documentation notes that this is seen sometimes, although not recommended: <a href="https://docs.microsoft.com/en-us/windows/desktop/direct3ddds/dx-graphics-dds-pguide#dds-variants" rel="nofollow noreferrer">DDS Variants</a></p>

<blockquote>
  <p>There are some common variants in use where the pixel format is set to a DDPF_FOURCC code where dwFourCC is set to a D3DFORMAT or DXGI_FORMAT enumeration value. There is no way to tell if an enumeration value is a D3DFORMAT or a DXGI_FORMAT, so it is highly recommended that the "DX10" extension and DDS_HEADER_DXT10 header is used instead to store the dxgiFormat when the basic DDS_PIXELFORMAT cannot express the format.</p>
</blockquote>

CC BY-SA 4.0
2018-07-30T13:08:31.503Z
Thanks for finding that out. Quite annoying when processing generic DDS to hit a variant which is very hard to detect in the data itself :/
Samuel
CC BY-SA 4.0
2018-07-29T19:03:21.360Z
2018-07-29T19:03:21.360Z
Nathan Reed
<p>I am analyzing the hex code for DDS files which are compressed via Nvidia's dds plugin in photoshop.</p>

<p>I noticed something strange when having a 16 bit float file. This is the dialog: 
<a href="https://i.sstatic.net/J9PiD.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/J9PiD.png" alt="Dialog"></a></p>

<p>When I look at the header of this file it appears to not follow the DDS spec. According to the DDS docs for the pixel format (<a href="https://docs.microsoft.com/en-us/windows/desktop/direct3ddds/dds-pixelformat" rel="nofollow noreferrer">https://docs.microsoft.com/en-us/windows/desktop/direct3ddds/dds-pixelformat</a>)
the dwFlags of 0x4 indicates a FOURCC but the next 4 bytes, which usually contain the FOURCC like "DXT1" etc contain only a "o"
<a href="https://i.sstatic.net/QOvKx.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/QOvKx.png" alt="Hex viewl"></a></p>

<p>AFAIK the for various other formats the locations and FOURCC (when present) are correctly displayed.
Here is a luminance 8 (dwFLags to 0x20000 and no FOURCC)
<a href="https://i.sstatic.net/wU6Vu.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/wU6Vu.png" alt="L8"></a></p>

<p>and here is a DXT1
<a href="https://i.sstatic.net/1MC3r.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/1MC3r.png" alt="DXT1"></a></p>

<p>Could somebody hint what happens for 16f here?</p>

<directx><raster-image><direct3d>
Image saved as DDS with 16f format in photoshop has strange FOURCC text
Samuel
# Image saved as DDS with 16f format in photoshop has strange FOURCC text

(Asked by: username_0 on 2018-07-29)

I am analyzing the hex code for DDS files which are compressed via Nvidia's dds plugin in photoshop.

I noticed something strange when having a 16 bit float file. This is the dialog:
[![Dialog](https://i.sstatic.net/J9PiD.png)](https://i.sstatic.net/J9PiD.png)

When I look at the header of this file it appears to not follow the DDS spec. According to the DDS docs for the pixel format (<https://docs.microsoft.com/en-us/windows/desktop/direct3ddds/dds-pixelformat>)
the dwFlags of 0x4 indicates a FOURCC but the next 4 bytes, which usually contain the FOURCC like "DXT1" etc contain only a "o"
[![Hex viewl](https://i.sstatic.net/QOvKx.png)](https://i.sstatic.net/QOvKx.png)

AFAIK the for various other formats the locations and FOURCC (when present) are correctly displayed.
Here is a luminance 8 (dwFLags to 0x20000 and no FOURCC)
[![L8](https://i.sstatic.net/wU6Vu.png)](https://i.sstatic.net/wU6Vu.png)

and here is a DXT1
[![DXT1](https://i.sstatic.net/1MC3r.png)](https://i.sstatic.net/1MC3r.png)

Could somebody hint what happens for 16f here?

**Tags:** directx, raster-image, direct3d


---

## 1 answers

### Answer by username_1 on 2018-07-29. Score: 2 | Accepted answer

The tool seems to be generating an unofficial extended version of DDS in which the FOURCC code is replaced by a value from the [`D3DFORMAT` enum](https://docs.microsoft.com/en-us/windows/desktop/direct3d9/d3dformat). The code `0x0000006F` translates to decimal 111, which translates to `D3DFMT_R16F`.

The Microsoft DDS documentation notes that this is seen sometimes, although not recommended: [DDS Variants](https://docs.microsoft.com/en-us/windows/desktop/direct3ddds/dx-graphics-dds-pguide#dds-variants)

> There are some common variants in use where the pixel format is set to a DDPF\_FOURCC code where dwFourCC is set to a D3DFORMAT or DXGI\_FORMAT enumeration value. There is no way to tell if an enumeration value is a D3DFORMAT or a DXGI\_FORMAT, so it is highly recommended that the "DX10" extension and DDS\_HEADER\_DXT10 header is used instead to store the dxgiFormat when the basic DDS\_PIXELFORMAT cannot express the format.

> **Comments:**
> **username_0**: Thanks for finding that out. Quite annoying when processing generic DDS to hit a variant which is very hard to detect in the data itself :/  

---

