Hi all,
We are experimenting with Aces on a LED Volume, and have noticed something wierd while running UE in Aces in combination with Multi Process nDisplay. All of these images have been recorder on a physical led wall
We have Ran a couple of tests,
Sanity check.
Working Color Space: Srgb
Ndisplay OCIO: Enabled / working colorspace → rec 2100 pq un-tonemapped
ICVFX CAM A OCIO: Enabled / working colorspace → rec 2100 pq un-tonemapped
Results:
No discrepancies, as expected. Colors match all around frustum
Working color space AP1
Working Color Space: ACES AP1 / ACEScg
Ndisplay OCIO: Enabled / working colorspace → rec 2100 pq un-tonemapped
ICVFX CAM A OCIO: Enabled / working colorspace → rec 2100 pq un-tonemapped
Result:
We see a clear difference between inner and outer frustum. Inner looks a bit darker in the red and green, but brighter in blue and white, that explains why it comes over as blueish instead of natural.
No OCIO, Working colorspace AP1
Working Color Space: ACES AP1 / ACEScg
Ndisplay OCIO: DISABLED
ICVFX CAM A OCIO: DISABLED
Result:
Without OCIO enabled on the inner and outer frustum we see the same results as before.the discrepancy in the green looks better but red is still way too dark. It looks like it is not necessarily an OCIO problem on the camera but that it lies deeper in how the camera interprets ACES
Working color space AP0
Working Color Space: ACES AP0 / ACES2065-1
Ndisplay OCIO: Enabled / ACES2065-1 → rec 2100 pq un-tonemapped
ICVFX CAM A OCIO: Enabled / ACES2065-1 → rec 2100 pq un-tonemapped
Result:
As a test i checked if AP1 gave different results as AP0 .Same offsets as with AP1, also tested with OCIO off and got the same results as with AP1
Working color space rec2020
Working Color Space: rec2020
Ndisplay OCIO: Enabled / working color space → rec 2100 pq un-tonemapped
ICVFX CAM A OCIO: Enabled / working color space → rec 2100 pq un-tonemapped
Result:
To see if the problem lay in ACES I checked if Rec2020 gave the same offsets. It still had the same issues ACES was having, where red and green are way to dark and blues is also a bit darker. Also tested without any ocio and got the same results
What I Suspect is, it looks like the problem lies in the interpretation of ACES in the camera component, because even without any OCIO transformations there is a discrepancy between inner and outer. This could also mean that the offscreen nodes (OS) are the cause if this discrepancy, because they render the frustum.
Aces works with the “old way” of rendering nDisplay.
The “fix”: Because the discrepancy was happening before the ocio transform, our suspect was either the ICVFX cam component or the compositing of the onscreen and offscreen node in the nDisplay.
We tested this by making a setup that was the “old” Multi-GPU instead of the now widely used Multi-Process.
Multi-GPU on only one node, Working color space AP1:
Ndisplay: Multi-GPU, using only one of our nodes instead of two
Working Color Space: ACES AP1 / ACEScg
Ndisplay OCIO: Enabled / working colorspace → rec 2100 pq un-tonemapped
ICVFX CAM A OCIO: Enabled / working colorspace → rec 2100 pq un-tonemapped
Result:
There was no discrepancy between the inner and outer frustum using this method
To sanity check this, we also tried running multi-process again on this particular node to check if our 2 node system wasn’t the cause
Multi-Process on only one node, Working color space AP1:
Ndisplay: Multi-Process, using only one of our nodes instead of two
Working Color Space: ACES AP1 / ACEScg
Ndisplay OCIO: Enabled / working colorspace → rec 2100 pq un-tonemapped
ICVFX CAM A OCIO: Enabled / working colorspace → rec 2100 pq un-tonemapped
Result:
We got the discrepancy again. We think it stems from this function in Ndisplay:
Because when disabling only this (and essentially not sharing any textures) the discrepancy was gone
Some Documentation for the multi process rendering. Multi-Process Rendering | Course
TL;DR
It seems that something goes wrong with the compositing of inner frustum with multi process ndisplay. whether this is due to the way texture sharing works i don’t know but im hoping to gain some insights on what goed on in the transition from “offscreen node” to “regular node”
We are hoping we can find a solution. because the multi process ndisplay is much much faster.
Thanks for reading through.