2

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

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

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

and here is a DXT1 DXT1

Could somebody hint what happens for 16f here?

Christian Rau
  • 1,604
  • 11
  • 32
Samuel
  • 123
  • 3

1 Answers1

2

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

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.

Nathan Reed
  • 24,302
  • 2
  • 63
  • 103
  • 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 Jul 30 '18 at 13:08