Exposure variation between "packet_spectral" and "scalar_spectral" modes.

[KelSolaar]

Hi,

I was comparing the packet_spectral and scalar_spectral modes with the mitsuba2/resources/data/scenes/matpreview/matpreview.xml scene and I noticed an almost exactly 1 stop exposure difference between the two modes:

Image with higher exposure is rendered with the scalar_spectral mode.

Cheers,

Thomas

[Speierers]

Unfortunately I can't reproduce this bug on my system.

Could you please check you are running the latest version with the submodules up-to-date?

git pull --rebase origin master
git submodule update --recursive

Are you on Ubuntu? And which compiler are you using?

Thanks!

[KelSolaar]

Hi @Speierers,

This is on macOs Catalina and the code is fresh from just before creating the ticket. I might have added the “packet_” modes after the initial build and rebuilt subsequently, maybe it could be the cause. I’ll check this morning.

Cheers,

Thomas

[greg-cohoon]

Hi,

I was wondering if there was any update to this issue. I am on macOS catalina 10.15 and just compiled mitsuba from release v2.2.1 (fresh clone) and am running into the same issue when comparing packet_rgb to scalar_rgb. I see the same symptom as above: packet mode images have 1/2 the channel values (+ noise) as scalar images. This occured in all channels,

I have tried most combinations(but not exhaustive) of the following primarily using cbox.xml and cbox-rgb.xml from the resources directory: integrators: direct, path film: pixel_format: rgb, rgba, luminance film: file_format: exr, pfm

One last thing that i've done, and im not super confident in it since I am still learning how to run mitsuba, is run a depth AOV and it seems like the same problem is happening, packet is returning half the depth as scalar mode.

Im still getting up to speed so I'll add anything else I can find that is relevant. I am really keen to find a solution for this, especially if there are potentially different results between mac and other targets.

[greg-cohoon]

some additional investigation

The above is with setting direct integrator(2500 shading samples), sampler samples to 1 and reconstruction filter stddev to very very small(.00001) it seems like packet mode on mac is just losing every other column oWith many samples + a larger reconstruction filter this looks like half the value.

Using slightly more reasonable inputs the output of the profiler revealed some interesting results. Im not 100% sure how to interpret this output, but to me it seems that packet only records approximately half the samples as scalar on mac.

[KelSolaar]

Great information @greg-cohoon! I will re-run some tests with the latest version to see if it is still the same for me, probably should be but keen to confirm.

[tomas16]

Hi,

I did a little more digging based on @greg-cohoon 's info. I created attached sample scene, which is simply a camera looking straight into an area light of unit radiance, so all the pixels should see that same radiance. I used the box rfilter, because gaussian using a zero stddev causes an error in Debug mode.

I ran experiments on MacOS and an Ubuntu VM running in Parallels on MacOS. I tried all combinations of Debug/Release, independent/ldsampler sampler and scalar/packet. Below table summarizes the results:

Some conclusions:

1. scalar always works as expected.
2. packet produces incorrect results in Release mode on MacOS. They are slightly different between the 2 samplers (see images below).
3. Running packet in Debug mode causes crashes on both platforms.
4. Somehow, on Ubuntu, packet works fine in Release mode, but trips assertions in Debug mode. That's kind of concerning...

Based on all this, I'm not even sure the assertion errors are related to the incorrect results when using packet on MacOS, since those error also exist on Ubuntu, put produce correct results in Release mode there.

Expected result:

"2-column stripes"

"1-column stripes"

Scene file (renamed to txt as github doesn't allow xml): debug_scene_arealight.txt Note the use of $sampler_type, you can specify this on the command line using -D sampler_type=independent

[Speierers]

Hi,

Thanks a lot for the investigation! Unfortunately I do not have access to a machine with MacOS so I will be unable to help on this issue.

I am pretty sure the assertions you get on Ubuntu in Debug mode are unrelated to this issue.

I would bet that something is wrong in the ImageBlock::put() method. Could be related to the enoki::scatter_add() call maybe?

[arpit15]

I did some digging. I see that the value active var changes from [1, 1, 1, 1, 1, 1, 1, 1] on line integrator.cpp:221 to [1, 1, 1, 1, 0, 0, 0, 0] on line integrator.cpp:243 for no apparent reason. I tested with scene provided by @tomas16 on macos. Maybe there is something weird on how functions are created in packet version and variables are passed onto them.