Curious transformation issue from TIFF & DPX rendered by Davinci Resolve

[antonarap]

Hi guys, I have the following issue: Not sure it is a problem, but still I don't get it:

I am outputting RGB Tiffs out of Davinci Resolve. For my resolve project I use either ACES or RCM, I tried both. The ODT/ Timeline/ Output colorspace is DCI P3. Nevertheless, the transformation option that works correctly in DoM is Rec 1886. Why? Shouldn't it be P3? Shouldn't Gamma be 2.6?

On the other hand, if I output DPX from Resolve with the same project settings, it doesn't work at all. There is no DoM color transformation that does the job.

Mind you, both Tiffs and DPXs look fine when viewed by themselves and when re-imported in Resolve and rendered as Jpeg2000, said Jpeg2000 look right and make good DCPs with no transformation in DoM.

So what's the matter?

Thank you

[Carsten]

Which Resolve and DCP-o-matic version are you using? JPEG2000 from (most) Resolve versions so far create playback problems in real DCI cinema servers. There are reports that Resolve 15 with its revised J2K encoder fixes this, but, as long as that is not confirmed, I would be careful to distribute DCPs that have been created immediately from Resolves J2K export. Even if they play okay in PC based software players like EasyDCP, DCP-o-matic player, etc., they may still fail on real DCI servers.

- Carsten

[antonarap]

Thank you Carsten. I use the latest Dom and the latest Resolve 14 (no 15 for me until it is stable) .

I can create DCPs fom Tiff RGBs. The question is: If I am creating the Tiffs in P3 color space, why is the correct transform BT. 1886?

[Carsten]

I use Resolve 14 myself, let's see if I can replicate your issue.

- Carsten

[rtX]

I've mentioned in an earlier post that I think that some versions of Resolve may incorrectly flag 4444 output and that DoM then interprets the output in the wrong data range and outputs a picture with blacks crushed (making the output too dark in dark shots). I suspect that is still happening. Not usre if that is anything to do with what you're experiencing but if it is useful, then great. I'm going to try rendering from the UHD 4444 master (made by Resolve) to a 2K or HD version of the same content at 4444 using Adobe Premiere to see if the DCP made using DoM from that 2K render has the correct data range etc.

[Carsten]

I think the only way to get this straight is to test this for various output formats and give specific recommendations towards the usage of Resolve/Premiere, etc. export formats. One issue is that some parameters may simply not be flaggable, or, FFMPEG will not read these flags correctly. As we know, many codecs in FFMPEG have been re-engineered and may lack support for certain features.

The question of best fileformat/export practice between Resolve, Premiere, etc. and DCP-o-matic comes up frequently here and elsewhere, and so I guess we should address this by giving best practice recommendations.

In an ideal world, every container and codec would contain all the metadata needed to interpret the video and audio data properly, and all software would support all these features. Unfortunately, that is not the case. Even high profile post production facilities with very costly software and hardware will not allow universal use of file formats in their workflows, but restrict import and export to a very limited range of choices, so that productivity doesn't suffer from uncertainties, misinterpretation, conversions, etc.

- Carsten

[rtX]

@Carsten: I think you are correct - best practice recommendations would be very helpful.

I'm not familiar with FFMPEG CLI, but wonder if there is any way of saying to it that this material is a particular data range etc. and should be interpreted as such regardless of what it may interpret itself in the first instance (using the metadata from the source file)? If DoM had the option to display what it is being told is the data range etc, and to override/'correct' this, if incorrect, then that would at least give some control to the operator, although I realise it adds a degree of complexity.

[antonarap]

My best practice recommendation is simple:

Independently of project color space, in Davinci 14 render to TIFF RGB 16 bits => In DoM encode with transformation set to Rec 1886.

Said transformation, I select it manually. DoM automatic recommendation is Rec 709.

The question is "why is this so"? Is Davinci 14 in fact exporting all TIFF RGBs in Rec 1886 independently of project settings? Or is it DoM doing something strange under the hood?

@Carsten: Have you been able to replicate what I described more analytically in the first post?

PS
Thank you very much for your fantastic software, you are enabling us to do stuff we wouldn't be able to do otherwise.

[Carsten]

If you output video range RGB TIFFs, it's not that far away from BT.1886. It's just a slightly different low range gamma curve difference.

There is a nice 16Bit TIFF test frame here:

https://www.charbon-studio.com/get/test ... _scope.tif

Load it into DCP-o-matic, open Video Waveform under 'Tools'. Change color transform between sRGB and BT.1886, and look at the bottom area of the video waveform. The preview does not reflect the color transform, it is source based, but the video waveform follows the chosen color transform.


- Carsten

[antonarap]

Carsten, and what about full (data) range Tiffs?

And, if I may ask, what about DPXs?

How should I proceed transforming them?

If I remember correctly from the time I did the tests, full range tiffs also work best with REC 1886 transformation.

Thank you very much