DNxHR gamma shift with DR 15 CM

High,

I have just noticed that when usin Davinci Color Manegment, importing DNxHR HQX MXF files rendered in Resolve itself produces gamma shifts due to INPUT COLOR SPACE set by default to "REC709 (Scene)" instead of "Project REC709 Gamma 2.4", that is the default for other formats.

No gamma shifts in ACCES.

Resolve Studio 15
Windows 10
GTX 1060 6Gb

How was Resolve set during export to 2.4?
On Mac it seems to be fine.

How I understand it is that Resolve has a new feature that detects (presumably based on certain metadata) what the input color gamma and gamut should be if RCM is used.

Scene referred Rec.709 (the one with the partly linear transfer function) should be used for 'true' Rec.709 cameras (do they still exist?).

Was the MXF file perhaps rendered with Rec.709 (Scene) as the output color space?

Steps to the problem:

-Resolve 15 Windows
-Import any media
-Set the project to Davinci YRGB Color Managed (input, timeline and output: REC709 gamma 2.4)
-Make a simple timeline with your clip.
-Render to MXF OP1A DNxHR HQX 10 bits.
-Render to Quicktime DNxHR HQX 10 bits.
-Import rendered media.

You will see that MXF is gamma shifted but MOV is ok.


MEDIAINFO:

QUICKTIME:
General
Complete name : C:\Users\Adriano\Desktop\base-novo.mov
Format : MPEG-4
Commercial name : DNxHR HQX
Format profile : QuickTime
Codec ID : qt 0000.02 (qt )
File size : 231 MiB
Duration : 10 s 928 ms
Overall bit rate : 178 Mb/s
Writing application : Lavf57.25.100

Video
ID : 1
Format : VC-3
Commercial name : DNxHR HQX
Format version : Version 3
Format profile : RI@HQX
Codec ID : AVdh
Codec ID/Info : Avid DNxHR
Duration : 10 s 928 ms
Bit rate mode : Constant
Bit rate : 176 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 3.540
Stream size : 229 MiB (99%)
Language : English
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709


MXF:
General
Complete name : C:\Users\Adriano\Desktop\base-novo.mxf
Format : MXF
Commercial name : DNxHR HQX
Format version : 1.3
Format profile : OP-1a
Format settings : Closed / Complete
File size : 232 MiB
Duration : 10 s 928 ms
Overall bit rate : 178 Mb/s
Package name : base-novo
Encoded date : 2018-08-13 22:03:24.484
Writing application : Blackmagic Design DaVinci Resolve 15.0
Writing library : libMXF (Win32)

Video
ID : 1
Format : VC-3
Commercial name : DNxHR HQX
Format version : Version 3
Format profile : RI@HQX
Format settings, wrapping mode : Frame
Codec ID : 0D01030102110100-0401020271250000
Duration : 10 s 928 ms
Bit rate mode : Constant
Bit rate : 176 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Active Format Description : Letterbox 16:9 image, with alternative 4:3 center
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 3.540
Stream size : 229 MiB (99%)
Title : base-novo_v1
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

I tried it.

The MXF file is just fine, however, Resolve mistakenly thinks the gamma is now Rec.709 (Scene) and sets the input transform accordingly which will be a problem when using RCM.

The workaround is easy, just set the input transform to project.

I can certainly see how setting the input transform based on the metadata can simplify workflows but the results obviously have to be correct.

The workaround is easy, just set the input transform to project.

Yes, not a problem to workaround it, but I think it is an error that must be addressed.

The workaround is easy, just set the input transform to project.

Yes, not a problem to workaround it, but I think it is an error that must be addressed.

I totally agree!

It's bug in case of MXF container, also on Mac.
Problem is most likely related to the fact that there is no official way to flag Rec.709 2.4 gamma based file.
Official/available flagging is so outdated and rather poor.
There are few options, but 90% are simply some strange and never used ones (probably just old legacy things).
Those which are used in 90% files (like Rec.709 with 2.4 gamma) are simply not there.