DDS: replace libsquish with bcdec, add BC4-BC7

[aras-p]

Description

Implements support for BC4, BC5, BC6H (unsigned and signed) and BC7 GPU texture compressed formats in DDS reader (#2338).

• BC4: loaded into 1 channel uint8,
• BC5: loaded into 2 channel uint8,
• BC6H: loaded into 3 channel half,
• BC7: loaded into 4 channel uint8.

This is implemented by replacing whole of libsquish (~4700 lines of code) with bcdec.h (https://github.com/iOrange/bcdec, ~1300 lines of code). bcdec.h has an advantage of being faster, smaller and supports all BCn formats for decoding.

bcdec.h license is MIT or Unlicense (aka public domain), updated all the relevant third party / license files that I could find.

Tests

This uses just-added extended DDS test coverage (#3459) and enables previously disabled BC4..BC7 tests. The pixel value SHA1 hashes of BC1..BC3 formats do change - BC1..BC3 decoding is not specified bit-exactly anywhere, and out there in the wild there are 4 possible ways to decode it. bcdec.h decodes it slightly differently from libsquish (i.e. some color values might be 1 off in 0..255 range, sometimes). Visually I've compared the results and they are all fine.

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]

Looks great!

Thanks for going as far as changing the license notices, etc.

[lgritz]

@aras-p Keeping in mind that certainly within the next month, we'll branch and have a beta for the first 2.4 release, which will be the primary supported release going forward (with 2.3 becoming the legacy release family that only gets critical fixes), do you think we should also backport this to 2.3? Or just let this overhaul be a 2.4 feature?

[aras-p]

@aras-p Keeping in mind that certainly within the next month, we'll branch and have a beta for the first 2.4 release, which will be the primary supported release going forward (with 2.3 becoming the legacy release family that only gets critical fixes), do you think we should also backport this to 2.3? Or just let this overhaul be a 2.4 feature?

No idea what's the expected backporting / multiple releases policy in OIIO :) In most places I've worked previously, a change like this would not get backported - it's technically not "a fix for something that's broken", but rather "implementing new functionality", and these by default don't get backported.

[lgritz]

I will backport "features" on a case-by-case basis, judging risk versus user benefit, but only when it can be done without breaking backward ABI/link compatibility, and when it's unlikely to harm anybody who isn't using that particular feature. In this case, I would consider backport fairly low risk because it doesn't change any external APIs at all, and it can't possibly hurt anything other than reading DDS files specifically, which is a feature only required by a small percentage of users.

On the other hand, it also means that only a small percentage of users will benefit from the improvement, so maybe they can wait until 2.4 is released within a couple months.

Since you yourself don't need it in a release branch right now, I'll leave it for 2.4 unless somebody else requests the backport.

Thanks, Aras!