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.
