Thank you for the suggestion to use the RGBA instead of the E channel. I too tried this initially with the three.js renderer, however I ran into the issue of lost precision by the time it was converted from RGBE to RGBA. As you know the A channels are all 255 at that point so I have to look at the RGB part - the problem is that many pixels elsewhere in the GPU-friendly RGBA image will have 255,255,255,255 - especially clouds, snow, white signs, the corona around the sun disk, so therefore I can’t rely on sampling everything that is white with full opacity.
From inspecting the raw data, I noticed that only the exact center pixel (or maybe 2 pixels) of the Sun’s disk will have a higher E channel than every other pixel in the image, even the rest of the small sun disk. If I can indeed narrow it down to 1 or 2 absolute winners in this bright pixel competition, then I can create an exact 3d vector SunDirection that will be sampled from inside the path tracer (with of course some randomness added in so that the shadows aren’t artificially too razor sharp, like old 80’s ray tracers, ha). The problem with using RGBA data is that I don’t know which of the many 255,255,255,255 pixels is actually the center of the Sun.
When I’m able to loop over the raw RGBE data, only 1 or 2 array elements of the large uint8array would have an E channel that was higher than the rest - sometimes narrowly by one digit, like 143 for the absolute brightest pixel, vs. 142 for runners-up elsewhere in the image. I guess because these numbers are exponents and the result is not linear, that one number can make a big difference. I’m not too familiar with loading and converting RGBE files, but that’s my guess.
Apologies if I didn’t understand your luminosity RGB suggestions correctly and it is possible to get the very brightest winning pixel with just the RGB of the final image. I don’t even know if I was using the RGBA data incorrectly somehow and for instance maybe the winning pixel has 255,255,255 (or similar high numbers), and everyone else has maybe 254,254,254, or something similar which would appear just as white to the human eye, but mean much more in terms of exponential brightness values if it where to be converted back. Again, I’m not very experienced with this file format and its conversion calculations, so sorry if I’m not understanding your suggestions as you intended.
I’m hoping we can discover a solution that has minimal impact on the source code. Thanks again for your time and expert input.