Hello, I'm having issues when loading an HDRI map into solaris. It's a 16bit half HDRI which renders fine with CPU, but all geo goes black when switching to XPU. Is that a limitation? See the attached video.

HDRI's (ie 16bit images) do work fine in XPU.
Its most likely a image file format issue (XPU + CPU use different code to load images)
Can you post an example image which is failing with XPU please?
Either on this forum post, or in a bug report
thanks!

Sure, it's an HDR from polyheaven, which I converted to acesCG with "PYCO Color Space converter".
It loads fine in any other app.
https://www.dropbox.com/s/cqhtgnr1ahvafrn/lago_disola_k_ACEScg.zip?dl=0 [www.dropbox.com]

Thanks for sending this through.
The texture had INF (ie garbage) pixels in there.
But I've now made XPU more robust to that kind of data, which fixes the issue.
The fix should be out in 19.5.339
cheers!

Jose Molfino
Sure, it's an HDR from polyheaven, which I converted to acesCG with "PYCO Color Space converter".
It loads fine in any other app.
https://www.dropbox.com/s/cqhtgnr1ahvafrn/lago_disola_k_ACEScg.zip?dl=0 [www.dropbox.com]

The source image on polyhaven is 32bit, converting to 16bit probably incorrectly clamped the solar values as INF instead of FLOATMAX. Since the 32 bit source image has values above the 16bit float max, it shouldn't be converted to 16bit float or it will suffer from energy loss.

Edit:
I used hoiiotool to convert to half float and it also results in INF values for the out of range pixels. I suppose I could use --minc 65504command to clamp it first.

another option is to take the image down a stop before using--solar disc values should normally be about 50k in a sunny 16 daylight exposed image so this image might be a tad overexposed. Multiplying by 0.555 before saving as half float results in a image with no overflow values as well.

hoiiotool -i lago_disola_4k.exr --iscolorspace "Utility - Linear - sRGB" --tocolorspace "ACES - ACEScg" --mulc 0.555555555556 -d half -otex lago_disola_4k_-0.85ev.acescg.half.exr