It is really the same problem as that of CG rendering, with worse consequences because you do no act on secondary bounces here! A corollary is that if you need to white balance an image and want to do it right, it is only really possible in the Camera RGB space. Of the Importance of the Basis!
It seems weird to apply a matrix here, because a the space is purposely highly non-linear b you would run the risk of introducing values outside the [0, 1] domain resulting in thermo-nuclear explosions in the cube right after
There are many reasons why movie makers pick a camera/lens kit over another, often it is for its “look” which is directly related to the optical path, hardware and software processing.
You might have noticed that the main camera vendors, e.g. ARRI, RED, Sony and BMD provide not only the hardware but also the software to process the captured imagery. It is common to receive plates/client LUTs that are the product (or highly related) to the software of the camera vendor, e.g. IPP2, K1S1 or ALF2. By extension, it is also quite common for VFX vendors to do comp work in the camera vendor gamut.
Thanks for the answers ! This clarifies a lot !
I have time on my hands and I am more than happy to provide some examples with E-Gamut !
I’ll probably post something later in the day.
OMG. I just understood what you meant. Running the same set of images and using E-gamut as rendering primaries. I thought I had to re-render in CG with E-Gamut primaries in my lights. Might be the whole “cycles” term that confused me. Sorry about that !
I basically used the same settings :
I used V2 of the nuke script (minor differences here and there).
Source gamut is ACEScg.
Destination gamut is the one that comes by default in the Nuke script and E-Gamut.
Output primaries are P3. White Point is D65.
EOTF is for sRGB display (so I suspect Gamma2.2 ?).
What about using Jed’s default with a small hue rotation for the reds that brings them halfway between E-gamut and Jed’s default? 9 degrees should do the trick since I can align ACES 1.3 to E-gamut with a hue rotation of 18 degrees.
Subjectively speaking, it seems to me like the blues and the magentas of the TCAM DRT all clump together in the Y = 1.0 middle region without the vision look. It is a bit of an extreme look though.
E Gamut Blue is a “very far out” blue virtual primary. Not sure if a sweep of full saturated EGamut primaries makes much sense visually, it is definitely a stress test.
For me, it looks the best of all your three published DRTs. It doesn’t make dark skin tone look greenish. Not greenish actually, but it looks like this because of the desaturation in the shadows. And I really like rgbDT doesn’t have this effect! But it have the same effect, that current ACES DRT has - dark colorful objects in the scene have sharp transitions to the clipped solid colors. And also I found it’s most noisy one in the shadows.
Here are images from Alexa (first image, I guess, are two Alexa cams at the same time. This is EXR with a huge dynamic range) with gamut compressor applied. Then I applied different DRTs. And after that I added Gamma up, to better see the shadows.
Doing tests of rgbDT and OpenDRT, I’m seeing that rgbDT appears to do all of the good things that OpenDRT does. It does not have the notorious six shift of skewing blue to magenta or red to yellow for example. I’d be curious to know if there are things that OpenDRT does that rgbDT cannot?
At the same time, rgbDT has out of the box the characteristics that match the current ACES transform - luminous hues of sunshine look yellow-orange instead of pink. Second, the “flattening” of color on faces does not happen with rgbDT. Put differently, these two things which can be changed in OpenDRT with a Look Transform (via a hue shift and zone saturation) are already there in rgbDT out of the box. The only thing one needs to do to make it look like ACES is increase the contrast a bit with a linearGrade.
This leads me to conclude that rgbDT seems pretty perfect. Is there a “gotcha” I’m missing in here somewhere? What is the disadvantage or limitation of using this per-channel display approach instead of OpenDRT?
Let me add that with the Look tools Jed has provided, it’s certainly possible to get OpenDRT+LMT to look like rgbDT. So either way can get to the same desired look. I’d be interested in understanding the pros and cons of each path up the mountain.
sorry for the late reply. A few answers on top of my head…
Probably the chromaticity-linear approach (our “ground truth”) and a proper SDR/HDR match. Without any HDR display, it is hard to say. Jed did some interesting SDR/HDR comparisons in this thread though.
Yes, we may be back to square one because of that ? A look embedded in the Display Transform.
Probably missing a “gotcha” that per-channel is the root of evil ? It does not respect the RGB ratios of the colors used by distorting hue, saturation and luminance. I have tried to describe this behaviour here.
I think Daniele answered this question in this thread. And rgbDT, because of its per-channel nature would probably need a new set of primaries to be invented. We did think about AP2, just like in this thread (even if that’s for a totally different purpose) !
Thanks for that clarification Chris. Given those differences it seems OpenDRT with a look is the clear winner. If one wants the look of rgbDT this is easy to get with an LMT in OpenDRT.
@ChrisBrejon let me add that I am reading through this with great interest.
Of course I’m appreciating the technical content and “color nerd” insights. But perhaps more importantly I appreciate the humble and learning approach you take in the paper. I resonate a lot with those feelings you express. That humility (both towards oneself and towards others) makes learning and grown possible (both for oneself and for others), and without it that’s where we get stuck in a fixed mindset. So thank you for modeling that – both in that paper and on these discussion boards.
Thank you. The humility is because I’m relatively new to Color Management and I know nothing basically.
I have been checking my examples from May 12th (like 5 months ago…) and even if rgbDT seems to be fixing some stuff visually, we still have some gamut clipping on ACEScg primaries sweep and a path-to-white (or path-to-maximal-brightness) converging towards Notorious 6.
I thought for a long time that the OT VWG was about fixing issues. And rgbDT could almost be a candidate for that. But I guess we need to see the bigger picture as explained in this reply. Fixing the issues will only satisfy a minority of users and productions. That’s my take on it.
I have heard some discussion about a per-channel DRT candidate using the SSTS, but I have not seen any prototype.
I thought it might be interesting to share a couple of things in this thread.
The per-channel DRTs have limitations but it is a familiar and well-proven approach which has been used a lot on many productions.
I do agree that considering a per-channel rendering as a candidate makes sense.
I do not think that ACEScg is a suitable “render gamut” for a per-channel DRT, and that a gamut with wider primaries might be better behaved (as demonstrated earlier in the thread).
I updated rgbDT with the same tonescale as opendrt v0.1.2 for easier comparison.
I also had fun with some math for colinear lines and angles one evening and put together an interactive setup for
starting from a base gamut
using sliders to adjust distance along the colinear line between primary and whitepoint for each primary
using sliders to adjust rotation off the colinear line
This lets you interactively create your own render gamut while viewing the results interactively in nuke.
Agreed too, if we consider that the most common production display RGB colourspace is P3-like, a display rendering space with a similar basis but uniformly scaled so that the green and blue primaries are closer to the spectral locus is maybe worth looking at. The red primary will land into non-physically realisable space but it is probably not a big issue.
