DDS: various improvements

[aras-p]

Description

• If a DDS pixel format header contains "this is a normal map" flag set, then handle that properly ([HELP] Converting a DDS normal map to jpeg #3525):
  • For a DXT5, this means it's a "DXT5nm" format. Normal X & Y components are in green and alpha channel respectively. Compute Z component from those, and the result is a 3-channel tangent space normal map.
  • For ATI2/BC5 format that also has a "normal map" flag set, compute the Z component automatically too, and result is a 3-channel image. However a bunch of ATI2/BC5 normal maps out there in the wild do not have that bit set, so also have a global "dds:bc5normal" attribute to optionally turn this on.
• Fix support of R10G10B10A2 format - was producing garbage data due to code assumption that truncation down to 8 bits never needs to happen.
• Fix bit expansion ("too dark") of very low-bit formats, e.g. R3G3B2. Code was simply shifting the bits, instead of properly repeating the high bits into new low bit positions (i.e. a 3-bit "111" needs to become an 8-bit "11111111" and not a "11100000").
• Support "RXGB" (DXT5, with red & alpha swapped) as well as "BC4U" and "BC5U" formats (the latter two are just BC4 and BC5, produced by some older tools).
• Support alpha-only (e.g. A8) formats.

All this mostly prompted by doing DDS improvements in Blender, and wanting to get Cycles renderer (which uses OIIO) to the same feature parity. See https://developer.blender.org/T101405 and https://developer.blender.org/D16087.

Tests

⚠️ Not yet! I should probably add a bunch of new images to oiio-images test suite, but first wanted to check if these suggested improvements even make sense.

Checklist:

• I have read the contribution guidelines.
• If this is more extensive than a small change to existing code, I
  have previously submitted a Contributor License Agreement
  (individual, and if there is any way my
  employers might think my programming belongs to them, then also
  corporate).
• I have updated the documentation, if applicable.
• I have ensured that the change is tested somewhere in the testsuite
  (adding new test cases if necessary).
• My code follows the prevailing code style of this project.

[lgritz]

LGTM, other than my comment on how I think we already have an equivalent function to your bit scaling.

[lgritz]

Can I ask for one more thing? In the documentation file builtinplugins.rst, do you think you could add a brief note to the DDS section explaining what's up with normal maps in this format and advising use of the global "dds:bc5normal" attribute if they wish to change the default behavior of how these files are interpreted?

[aras-p]

Can I ask for one more thing? In the documentation file builtinplugins.rst, do you think you could add a brief note to the DDS section

Done! I also took a liberty of replacing "this is an awful format" sentence with something that says "this is for direct-to-GPU usage". It's not awful; it's just very, very specific use case. For something you want to stuff directly into a GPU, DDS is an excellent format; but indeed it's not much of use for use cases outside of that.

[lgritz]

Perfect, and thanks for the cleanup of the intro. I must have been extra cranky when I wrote that, and it's definitely not the style I'm going for in the docs.

[aras-p]

@lgritz by the way would it be possible to get this into 2.4.x release? For Blender they are looking at updating to 2.4 "soon after it's out" and lack of feature parity wrt DDS (compared to internal non-OIIO code) was one of the things that would be nice to address.

[lgritz]

I was definitely going to backport it. Ordinarily, I would have waited until the next tagged release (just had a release yesterday!), but since this is important for Blender, I can do a patch right away if people are waiting for it.

[lgritz]

Released as v2.4.4.2