normalMap.png images are poorly normalized

Description of Issue

The normalMap.png file used for testing PreviewSurface and MaterialXvsNative has around 3000 texels that are poorly normalized.

Steps to Reproduce

Examine files https://github.com/PixarAnimationStudios/OpenUSD/blob/release/pxr/usdImaging/usdImagingGL/testenv/testUsdImagingGLPreviewSurface/normalMap.png and https://github.com/PixarAnimationStudios/OpenUSD/blob/release/pxr/usdImaging/usdImagingGL/testenv/testUsdImagingGLMaterialXvsNative/mtlxFiles/normalMap.png (the same file)
Look at for example texel (71,95). The RGB triplet (converting to 8-bit, for visualization; these files are actually 16 bits per channel) is (129,14,221). If you convert using (V/255)*2-1, you get (0.01176470588, -0.89019607843, 0.73333333333). The length of that vector is 1.15341460201. That is considerably longer than the 1.0 expected, far more than can be explained by precision problems.

This texture is mostly flat, so the 3162 texels detected to be of incorrect length are significant. I would submit a fixed image, but I do not have tools that work with 16-bit-per-channel PNGs. As important, the texture's flat areas are suspect. Look at any of the many texels in this image that are supposed to be flat and you'll see values (at texel (0,0)) of (127,124,255) - a truly flat texel will have 127 or 128 for its X and Y values. It would be better to rederive and check this image from its original heightfield image. If the conversion tool is broken, it could be repaired.

Here is a diff using BeyondCompare, showing blue as "somewhat wrong" and red as "significantly wrong" - more than 20 levels of difference between the original and the rough corrected image (8-bit). the "not quite pointing up" normals are left as-is here, since the cleaned-up image fixes only normal lengths.

I checked the UsdPreviewSurface test file and it is using standard normal bias and scale values, meaning Z should indeed be between -1 and 1. I know a bit about this area, having contributed this test file elsewhere.

The analysis program I used is my own NormalTextureProcessor, which is fairly well tested and I believe is pretty reliable (if it's not, I certainly want to know). Its analysis in full:

Image file 'normalMap.png' is probably an XY-only normals texture. Reason: the percentage of unnormalized XYZ vectors (assuming Z -1 to 1) is 4.82483% (3162 texels), larger than the error tolerance of 2%. The Z values were found to be as far off as 74 levels in expected value. 95.1752% of normals are valid for range -1 to 1, 91.8808% are valid for range 0 to 1. Normals that point essentially straight up: 2.00043% (1311 texels). Average input Z channel values, if mapped from -1 to 1: 0.95334 and Z would range from -0.00392157 to 1 *Problem: the X and Y coordinates form vectors considerably longer than 1.0 for 1.6571% of the texels (1086 texels), 2 levels longer for 0.358582% (235 texels), and 1 level longer for 2.32239% (1522 texels). Average XY values: X -0.0077858, Y -0.0301769 X and Y values ranges: X -1 to 1 Y -1 to 1 Color channels range: r 0 to 255; g 0 to 255; b 127 to 255.

Here is a view showing various types of errors in colors (explained at the end of this section:

The point is that, though there are "only" 614 texels that are noticeably wrong, given the flatness of the texture, these are fairly significant.

System Information (OS, Hardware)

Windows 10, though this is mostly irrelevant. The bug can be seen by inspection of its data.

Package Versions

N/A

Build Flags

N/A

I should note that the analysis for https://github.com/PixarAnimationStudios/OpenUSD/blob/release/pxr/usdImaging/usdImagingGL/testenv/testUsdImagingGLMaterialXBasic/normalMapFiles/normalMap.png shows problems around its fringes, but these are minor and so I didn't bother reporting it as not-so-great. Just FYI, here's the analysis:

Image file 'normalMap.png' may be a standard normals texture. Reason: no Z -1 to 1 range values are negative. Reason: the percentage of XYZ's that do not form normalized vectors for Z -1 to 1 is 0.234222% (614 texels), smaller than the error tolerance of 2%. 99.7658% of normals are valid for range -1 to 1, 64.9563% are valid for range 0 to 1. WARNING: input file has 16 bits of precision per channel, but this program currently outputs only 8 bits per channel. Normals that point essentially straight up: 63.4941% (166446 texels). The X and Y coordinates form vectors 2 levels longer than 1.0 for 0.00038147% of the texels (1 texels), and 1 level longer for 0.31395% (823 texels). The first percentage is less than the error tolerance of 2% of the texels. *Problem: bad normals, with the Z values (assuming range -1 to 1) found to be as far off as 42 levels in expected value. 99.7482% of the XYZ normals are normalized well (261484 texels), 0.0175476% are close (46 texels), and 0.234222% are pretty bad (614 texels). Normal lengths found in the file, assuming Z -1 to 1: minimum 0.847304 and maximum 1.0059 (these should be near 1.0). The lowest Z value found was 0.0117648 Average XYZ values, assuming Z -1 to 1: X 0.00172644, Y 0.0017014, Z 0.872954 XYZ values ranges, assuming Z -1 to 1: X -1 to 1 Y -1 to 1 Z 0.0117648 to 1 Color channels range: r 0 to 255; g 0 to 255; b 129 to 255.

The error (heatmap) image shows problems only along the fringes.

PixarAnimationStudios / OpenUSD