Hi @Microno95 ,

Just checking here that you are running setpath.bat before all this? Maybe it is enough to re-run that script after creating the conda environment?

Hi @Speierers,

I actually tried three configurations. setpath.bat before environment creation, setpath.bat before environment activation and setpath.bat after environment activation. All three results in failure to import mitsuba.

Could you print you path in Python? According to setpath.bat, the Mitsuba directory should have precedence:

set PATH=%MITSUBA_DIR%;%PATH%

Ah, I don't think that's the case in the master branch

Just tested that, and now OpenEXR fails to load instead with the error:

>>> import OpenEXR
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: DLL load failed while importing OpenEXR: The specified procedure could not be found.

It seems that the DLL path resolution correctly respects the PATH environment variable, but the same name for the library(s) between conda's OpenEXR and Mitsuba's own OpenEXR means that, depending on the order in PATH, one or the other will fail to load.

From what I've read, a Windows application cannot load multiple DLLs with the same name in the same process unless the DLLs are loaded via the absolute path to the library instead of relying on Windows to resolve the dependency.

This is the result of print(sys.path) in Python after running setpath.bat:

['', 'G:\\research_files\\academic_work\\git_repositories\\mitsuba_renderer_folder\\mitsuba2\\build_windows\\release\\dist\\python', 'G:\\research_files\\academic_work\\git_repositories\\mitsuba_renderer_folder\\mitsuba2', 'C:\\Users\\ekin4\\.conda\\envs\\test_exr_mitsuba2\\python38.zip', 'C:\\Users\\ekin4\\.conda\\envs\\test_exr_mitsuba2\\DLLs', 'C:\\Users\\ekin4\\.conda\\envs\\test_exr_mitsuba2\\lib', 'C:\\Users\\ekin4\\.conda\\envs\\test_exr_mitsuba2', 'C:\\Users\\ekin4\\.conda\\envs\\test_exr_mitsuba2\\lib\\site-packages']

And is it necessary for you to import both mitsuba and OpenEXR in your Python script? We would rather have this not being a limitation, but in the meantime, you could rely on the Mitsuba Bitmap class to manipulate EXR images maybe?

At the moment, not a big priority. I have set up a separate environment for manipulating .exr images, which, for now, is viable.

The convenience of using OpenEXR has been the documentation showing how to go from image data to numpy arrays and back. Other than that, there's no particular reason I could not use Bitmap as long as it lets me do such manipulations (wasn't sure how...).

You can definitely use the Bitmap class from mitsuba to do such manipulations (load file from disk, convert to numpy array, and back, write to file, ...)

Here is a little tuto:

# load image from disk
bmp = Bitmap("some_image_file.png")
# convert to numpy array
np_img = np.array(bmp)
# convert from numpy array
bmp2 = Bitmap(np_img)
# write down to file
bmp2.write("my_image.exr")

You can also specify the image format (e.g. RGB vs XYZ vs RGBA, ...) and the data type (float32 vs int32). Take a look at src/libcore/tests/test_bitmap.py for more examples.

Swapping out OpenEXR for Bitmap worked superbly, much easier interface too. Thanks!

Unfortunately, I ran into a similar issue involving pytorch (my script loads exr images into pytorch tensors). I believe it's due to the fact that pytorch comes with its own version of asmjit which conflicts with mitsuba's version. So in a given environment I can either load pytorch or mitsuba, but not both because the shared library for asmjit for one does not match the other.

I tried setting asmjit to be compiled as a static library instead of shared, but this then breaks mitsuba compilation with many unresolved external symbol errors in MSVC.

Once I figure out the minimal number of steps to reproduce the error, I'll create a proper bug report. But I thought I'd comment here in case you have some idea of what to look at.

I figured out how to make asmjit compile as a static library. Essentially, the preprocessor variable ASMJIT_STATIC is not correctly defined when asmjit/asmjit.h is imported in include/mitsuba/core/jit.h, adding the following lines before the header is imported solves this issue:

#ifndef ASMJIT_STATIC
#define ASMJIT_STATIC
#endif

Now I can import pytorch and mitsuba simultaneously. I am still testing whether I can run them at the same time without issue.

Nice catch! If you think this should be pushed on the main repository, feel free to open a PR 🚀