@PichouPichou, Sorry for the delay in my response. Friday was indeed recovery time for me after the release. The env file will be a compression of the DDS mip maps using an RGBD algorithm which stores a divisor in the alpha channel. The env map is an 8-bit image, and the alpha channel is used to reconstruct the values that are over 1.0 in each pixel. This is done by: rgb * (maxRange / 255) / alpha. We went with the RGBD method of compression over the RGBM (multiply rgb by alpha to get values over 1.0) because the distribution of values in RGBM is more evenly distributed between 0 and maxRange where RGBD tends to pack precision on the lower end with a few highlights. With IBL environments that is exactly what we normally have. A few pixels of exceedingly high values in the thousands (for the sun) and the rest of the image packed between 0 and 5 or 10.
With all that in mind, you do want to export with as much precision as possible and let the env do the compression for you as @Pryme8 suggests. I will always output a full 32-bit float file at 256 pixels per face and let the env convert for me. This helps the algorithm doing the compression as the tones are more representative of the original image when creating the divisor alpha channel.
If you can share your IBL with me, I can run it through our pipeline for a comparison if you like. We use Lys for our environments, which does tend to turn out a bit differently as I can export a dds using the same lighting model as is implemented in Babylon. IBL Baker does not have the same model available (GGX Log2) for exporting its files and while IBL Baker does an acceptable job I have noticed that if the values are critical from the IBL it’s better to author it with the same lighting model as the renderer expects.
My guess is that exporting with the extra bit depth will get your tones back in line with what you expect, but I can always run the comparison for you if you like. Let me know if you have any other questions!