usdview complains about being unable to load the StinsonBeach.exr texture file

[zomgrolf]

Description of Issue

When I try to view a simple scene in usdview, I get warnings such as this:

'Warning: in _GetSrcTextureDimensionsAndName at line 105 of E:\w\ca6c508eae419cf8\USD\pxr\imaging\hdSt\domeLightComputations.cpp -- Could not open dome light texture file at c:/temp/nvusd-21.02/lib/usd/hdx/resources/textures/StinsonBeach.exr.'

The file is definitely there and I can view it in an image viewer (so it doesn't look like it's corrupted).
This happens when using the pre-built USD package offered by NVidia (both 21.02 and 20.11) and my own build of 20.11.
Moving the USD directory to different drives or renaming it to include only letters doesn't have any effect.

Is this a benign warning that can be ignored?

Steps to Reproduce

1. Download the pre-built USD package from NVidia (https://developer.nvidia.com/usd), Windows version
2. Follow the instructions in README.txt to set up your Python and environment variables. I'm using Anaconda, so I installed PyOpenGL using conda and PySide2 using pip.
3. Type usdview.cmd %USDROOT%\share\usd\tutorials\traversingStage\HelloWorld.usda from the command prompt with the Python and environment variables set up. Usdview should load and display the scene, but it issues a number of warnings about being unable to load the dome light texture while doing so.

System Information (OS, Hardware)

Windows 10 Pro 20H2,
CPU: Intel Core i7 5960X
GPU: Nvidia RTX 3080, driver 461.92

Package Versions

USD 21.02, but it happens in 20.11 too.
Python 3.6.13
PyOpenGL 3.15
PySide2 5.15.2

Build Flags

[spiffmon]

HI @zomgrolf ,
USD can only read exr textures when it is built with the optional OpenImageIO support enabled. Perhaps @rstelzleni or someone else at NVidia can confirm, but it seems likely that the NVidia binary is not built with OIIO enabled. Unfortunately, the texture is (and needs to be) HDR, so distributing it as a PNG, which USD can read even without OIIO, is not an option.

[zomgrolf]

Hi @spiffmon,

Thanks for the quick reply, this is perfectly fine, I can build an OIIO-enabled version myself.

[asluk]

For completeness, I can confirm that the usd.nvidia.com binaries are currently not built with OIIO enabled.

[NTKKS]

Is there a way to change default dome light to some .hdr or can I get prebuilt libraries with OIIO somewhere?

[spitzak]

We are also having this problem, more due to our installation of USD not including this file. I think it would be acceptable for Storm to fall back to some really simple dome, perhaps all white, or a half-sphere that is white. It can print an error message about what file it tried to open.

[drwave]

In my tree, I have converted that EXR to a 16 bit PNG version of the StinsonBeach image and it works fine without OpenImage IO. Perhaps that might be a way to do it?

…

On Nov 4, 2021, at 09:34, Bill Spitzak ***@***.***> wrote: We are also having this problem, more due to our installation of USD not including this file. I think it would be acceptable for Storm to fall back to some really simple dome, perhaps all white, or a half-sphere that is white. It can print an error message about what file it tried to open. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1481 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM2AOU4TFI6XOQ372HSBJDUKK73LANCNFSM4ZXZOVJA>.

[spitzak]

PNG would be a good idea assuming the image is not HDR

[meshula]

The StinsonBeach image is HDR, so mapping it to a 16 bit LDR image as @drwave did will at least preserve image precision for values under 1.0.

[drwave]

Yea, there’s a bright sun in the shot. I’m not saying it’s a perfect solution, but it definitely will be better than not loading… I have certain builds where I build without ImageIO, and it’s helpful to still be able to use the dome light :-)

…

On Nov 4, 2021, at 09:51, Nick Porcino ***@***.***> wrote: The StinsonBeach image is HDR, so mapping it to a 16 bit LDR image as — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1481 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAM2AOS4KP2OGOYYLTVP3O3UKLB3PANCNFSM4ZXZOVJA>.

[spiffmon]

The builtin STB image loader does support the hdr format, so that is a potential option. I'm trying to discern how that image gets configured and loaded, but as yet without success.

[spitzak]

I'm reasonably certain that preserving the precision of the 0-1 range is useless. However clipping everything above 1 is a problem so it does not look like png (or jpg or many other formats) can be used. If you can avoid the clipping (maybe by adding a big white circle in the sun's direction) then an 8-bit format would work just as well.

[spiffmon]

I am going to reopen this Issue, so that we can investigate changing the shipping exr file to hdr, which in theory (we have never tested this) should always work, and if it does, it's a simple enough change.