Same float4 -> float conversion method produces different results in C# vs. shader

So, I'm trying to load grayscale heightmaps images into a shader. Each pixel in the heightmaps is a 32-bit floating point number representing the elevation at that point. I convert these grayscale TIFs to PNGs, but the bytes values for the pixels are still the same. After loading one of these PNG heightmaps into a Unity texture at runtime, I check the grayscale values like so:

 var texBytes = tex.GetRawTextureData();
             float min = System.Single.MaxValue;
             float max = System.Single.MinValue;
             int pxIdx = 0;
             int pxLength = texBytes.Length / 4;
             int minIdx = 0;
             int maxIdx = 0;
             List<float> colorValues = new List<float>();
             for (int i = 0; i < texBytes.Length; i+=4)
             {
                 float colorValue = System.BitConverter.ToSingle(texBytes, i);
                 colorValues.Add(colorValue);
                 if (colorValue > max)
                 {
                     max = colorValue;
                     maxIdx = pxIdx;
                 }
                 if (colorValue < min)
                 {
                     min = colorValue;
                     minIdx = pxIdx;
                 }
                 pxIdx++;
             }
 
             Debug.Log("Min grayscale value is " + min + " at index " + minIdx + "/" + pxLength + ", max is " + max + " at index " + maxIdx + "/" + pxLength);
  

Everything looks fine, min and max elevations are the same as when I look at the heightmap in QGIS.

But I need a way to decode this data in the shader (i.e. turn a float4 color into a single float elevation value that I can use to displace vertices).

Luckily, I found a function written by one @CHPedersen , which I ported from HLSL to C# for easier testing purposes:

 float UnpackFloatRGBA(float[] _input, bool reverse)
     {
         float[] input = _input;
         for (int i = 0; i < 4; i++)
         {
             input[i] *= 255;
         }
 
         if (reverse)
             System.Array.Reverse(input);
 
         int[] bytes = new int[] { (int)input[0], (int)input[1], (int)input[2], (int)input[3] };
 
         // Extract the sign byte of the float, i.e. the most significant bit in the red channel (and overall float structure)
         int sign = (bytes[0] & 128) > 0 ? -1 : 1;
 
         // Extract the exponent's bit parts which are spread across both the red and the green channel
         int expR = (bytes[0] & 127) << 1;
         int expG = bytes[1] >> 7;
 
         int exponent = expR + expG;
 
         // The remaining 23 bits constitute the float's significand. They are spread across the green, blue and alpha channels
         int signifG = (bytes[1] & 127) << 16;
         int signifB = bytes[2] << 8;
 
         float significand = (signifG + signifB + bytes[3]) / Mathf.Pow(2, 23);
 
         significand += 1;
 
         // We now know both the sign bit, the exponent and the significand of the float and can thus reconstruct it fully like so:
         return sign * significand * Mathf.Pow(2, exponent - 127);
     }

Seems to work great when I reverse the input float array order (my heightmaps appear to be little-endian, I think). The unpacking function gives the same result as system.bitconverter. Nice job CHPedersen!

However, when I try the same calculation in the shader (still reversing the input color order)...it doesn't seem to work:

 inline float UnpackFloatRGBA(float4 encoded, bool reverse)
 {
     float4 c = encoded;
 
      // First, convert the color to its byte values
     int4 bytes = c * 255;
 
     if (reverse)
         c = float4(encoded[3], encoded[2], encoded[1], encoded[0]);
  
     // Extract the sign byte of the float, i.e. the most significant bit in the red channel (and overall float structure)
     int sign = (bytes[0] & 128) > 0 ? -1 : 1;
 
         // Extract the exponent's bit parts which are spread across both the red and the green channel
     int expR = (bytes[0] & 127) << 1;
     int expG = bytes[1] >> 7;
 
     int exponent = expR + expG;
 
         // The remaining 23 bits constitute the float's significand. They are spread across the green, blue and alpha channels
     int signifG = (bytes[1] & 127) << 16;
     int signifB = bytes[2] << 8;
 
     float significand = (signifG + signifB + bytes[3]) / pow(2, 23);
 
     significand += 1;
 
         // We now know both the sign bit, the exponent and the significand of the float and can thus reconstruct it fully like so:
     return sign * significand * pow(2, exponent - 127);
 }

I thought changing the color order of the texture in Unity might help (e.g. trying RGBA32, ARGB32, BGRA32), but it doesn't. The shader elevations are either much too large or too small, not in the range that is printed with my debugging code above or QGIS. I have verified this by having the shader output red if the values are in the expected interval. Most of the pixels are not red.

So my question is: Why is the same calculation on the same pixel color values producing different results when done in the shader vs. the C# script?

Thanks in advance for any help.