Camera File Import Error Under Color Management

Reposting here as Ive confirmed a bug and trying to provide replicatable info.

Resolve 18.5b B16
MacOS: 13.3.1 (22E261)

This is either related to the Sony FX9 or MXF files in general under Davinci Color Management. What I know...

When importing Sony FX9 footage in Rec709 it is misread and mistakenly applied a CST (I believe from Sony SLog3). I have imported other Rec709 footage and it is interpreted correctly. SLog3 Footage is also interprested correctly.

ALSO IMPORTANT: There is no way to change the input color space. The option is missing from the menu. It *IS* however visible on other Rec709 footage not created on my Sony FX9.

Here are screenshots to illustrate the issue along with Color settings.

Color Management Config

Screenshot 2023-04-19 at 12.44.08 PM.png (370.48 KiB) Viewed 1606 times

Here are two shots brought in. Both should come in as Rec709 but be able to have their ICS changed.

Left Sony FX9 Footage (Rec709) | Right Zoom recording

Screenshot 2023-04-19 at 12.43.36 PM.png (105.45 KiB) Viewed 1606 times

The Zoom recording has a contextual menu to change the input color space. The Sony FX9 footage does not:

Sony FX9 Footage (Rec709)

Screenshot 2023-04-19 at 12.43.48 PM.png (82.17 KiB) Viewed 1606 times

Here are screenshots from the same file under Color Management and YRGB. Note there is no ability to change the INPUT COLOR SPACE on these files. The Menu option is missing (see OP for Management settings)

which codec? mxf is only a container

if you open one of the xml files (that lie next to the clips inside finder / explorer) with a normal text editor, what does it say there? you should be able to read about the color space and codec.

did you enable an input LUT for the clip by accident?

which codec? mxf is only a container

if you open one of the xml files (that lie next to the clips inside finder / explorer) with a normal text editor, what does it say there? you should be able to read about the color space and codec.

did you enable an input LUT for the clip by accident?

No, no LUTs, Ive repeatedly tried different projects, databases, and other source files from the last several months. Files that were working perfectly in projects previously. No Input LUT.

I realize the MXF is a container file, but I know that the Sony FS7 and FX9 tag the clip differently because Resolve Color Management could interpet FX9 SLog3 automatically, where I had to choose the ICS for FS7 SLog3 clips. I assume its something in that tag that is broken. However I feel very confident its a bug in 18.5b at this point. Especially since the Input Color Space option is not even available in context menus on these clips, so there is no way to manually fix it. That had me very confused. Only way I have found is to Bypass Color Management all together on the clips to be able to work.

Chceck in Cammera Raw tab is there a option to change white balance.
It looks like resolve is trying to decode those Xavc as raw ROTFL
So it looks like Resolve now have an option to check if you are using CIneEI mode in camera
and then it looks at those files as the are RAW you can, and when you are in ACES or Resolve Color managed then the workflow is as you work with normal RAW files

the input color space dropdown is not available because it's raw. check your raw settings inside resolve

the input color space dropdown is not available because it's raw. check your raw settings inside resolve

Its not raw, its Log footage. I have also checked the raw settings JUST in case something changed in the beta. The raw settings have no effect on the clip as well.

I'm happy to provide a raw clip to someone if they would like to test on their end.

Chceck in Cammera Raw tab is there a option to change white balance.
It looks like resolve is trying to decode those Xavc as raw ROTFL
So it looks like Resolve now have an option to check if you are using CIneEI mode in camera
and then it looks at those files as the are RAW you can, and when you are in ACES or Resolve Color managed then the workflow is as you work with normal RAW files

Where is an option to check that you used CineEI? Also these clips were not shot CineEI, they are shot SDR Rec709 (gamma Cinetone). I did try the Raw Settings, there is no change when adjusting them though (as the clips are not RAW)

Can you share one of the clips for us to examine, Austin?

For a lot of reasons, we refer to do shot-by-shot Color Management with CST nodes. When you manage it all yourself, there's no chance for the software to misinterpret the nature of a clip and try to apply the wrong color/gamma space in a situation like this.

I concede that it is a malfunction if it's coming out wrong in a Color-Managed Session. What if you bypassed the color management for the offending clips and then applied manual color management?

This should clarify

This should clarify

Heres a video so everyone can see exactly whats going on. It is only related to SDR Rec709 files, not LOG. LOG files function fine. I've brought in 2 clips, one LOG, one SDR (shot by same FX9) so everyone can see the difference in behavior. Here are system reports and 2 clips (also same camera) you can use to replicate the issue (hopefully):

Diagnostic files, sample clips, project file, etc:
https://www.dropbox.com/scl/fo/131cl1hy41a9qhwp8zv7g/h?dl=0&rlkey=tqsg5eyzy18ne2ogv7s3gkngw

Video:

For a lot of reasons, we refer to do shot-by-shot Color Management with CST nodes. When you manage it all yourself, there's no chance for the software to misinterpret the nature of a clip and try to apply the wrong color/gamma space in a situation like this.

I concede that it is a malfunction if it's coming out wrong in a Color-Managed Session. What if you bypassed the color management for the offending clips and then applied manual color management?

Bypassing Color Management yields expected results. Currently thats the only way I'm able to work with the native Rec709 files. Luckily these are generally shot with the purpose of being close to Ready to Air as is, so they don't need a lot of work. Ive just been working in Log projects since updating and it caught me off guard (unfortunately while on site with a client). Bypass was a life saver to get through that.

Thanks for the video.It does explain your problem pretty well. Basically resolve is falsely interpreting h264 files as raw.

depending on your color management settings you can (for the moment) work around this false interpretation by applying a CST from timeline to sLog3 on the first node.
resolve falsely thinks it's sLog3 and converts to timeline color space and after the grade frome timeline to rec709, that's why you get double the DRT. reversing the false transform at the start get's you right to the original pixel values before the ODT happens

Bypassing color management has it's drawbacks aswell.(i don't know if they fixed it already but) it doesn't work when there are multiple tracks visble at the same time for whatever reason.

Basically resolve is falsely interpreting h264 files as raw.

Yeah, that is REALLY weird. This looks like a bug to me.