Atomos Ninja V and Fuji X-H1

[Attila Bakos]

35 minutes ago, androidlad said:

Decoding a BT.709 YCbCr signal using BT.601 and BT.709 matrix should produce two different results, so, if Scratch was truly respecting the tags, internal and external should look different. Of course this is all based on the assumption that the camera originated YCbCr data is the same between internal and external.

That's why I believe that assumption is wrong and the data itself is different.

EDIT: Forgot to tell you that I experimented with extracting the raw stream and inserting it into another container without any flags. In this case even Scratch shows the difference, so my theory seems to be correct.

EDIT2: Or just use this script: ffmpeg -i INPUT.MOV -c copy -bsf:v hevc_metadata=matrix_coefficients=1 OUTPUT.MOV
It only changes the matrix coefficients tag to BT.709, and immediately you can see a difference in Scratch. So it's respecting the tags.

[Attila Bakos]

FYI I contacted Blackmagic support about the issue, it has been forwarded to the development team, but that's all they told me.

[Attila Bakos]

I checked a some footage with the correction matrix, and the funny thing is that I actually prefer the wrong interpretation in many shots

[androidlad]

14 minutes ago, Attila Bakos said:

I checked a some footage with the correction matrix, and the funny thing is that I actually prefer the wrong interpretation in many shots

Do you have X-T3 with Ninja V? Would be interesting to see a comparison between internal H.265 HLG and external ProRes HLG. HLG metadata seems to be precise and complete.

[Attila Bakos]

36 minutes ago, androidlad said:

Do you have X-T3 with Ninja V? Would be interesting to see a comparison between internal H.265 HLG and external ProRes HLG. HLG metadata seems to be precise and complete.

Yes I'm interested in that as well, but unfortunately no external recorder here

If you check the HLG files in Assimilate Scratch and in Resolve, they look different. But if you go to the media section in Scratch and change data format from the recognized Rec2020 to Lin/sRGB and change HLG to SDR, they will look the same.

[wa666ou]

Does the Ninja V record audio with Deity V-Mic D3 Pro? Because I have not managed to do that. I've tried different audio cables, no luck.

At the moment I'm recording to the camera with a cheap (2€) TRS cable and I also have Rode TRS cable, both work with the camera.

But if I connect the mic to the Ninja, no audio input.

Any suggestions?

I have not tried other mics.

[wa666ou]

I've read the manual it states this:

"Ninja V Mic input supports dynamic and powered microphones only. When using these, audio must be set as Mic Level."

I'm guessing Deity mic is not that kind of microphone? Choosing a line or mic does not make it connect.

[Attila Bakos]

@androidlad Upon further inspection I found out that the Rec709toRec601.cube LUT is not 100% accurate, sometimes it will be slightly off. This problem might be something that can't be fixed with a single LUT, or matrix. For a really accurate conversion transcoding seems to be the only way:

ffmpeg -i INPUT.MOV -vf colorspace=all=bt709,scale=in_range=full:out_range=full -c:v prores_ks -profile:v 2 -c:a copy OUTPUT.MOV

Just remember to switch ProRes to full range once it's imported.

 

[androidlad]

1 minute ago, Attila Bakos said:

@androidlad Upon further inspection I found out that the Rec709toRec601.cube LUT is not 100% accurate, sometimes it will be slightly off. This problem might be something that can't be fixed with a single LUT, or matrix. For a really accurate conversion transcoding seems to be the only way:

ffmpeg -i INPUT.MOV -vf colorspace=all=bt709,scale=in_range=full:out_range=full -c:v prores_ks -profile:v 2 -c:a copy OUTPUT.MOV

Just remember to switch ProRes to full range once it's imported.

 

Interesting. In Premiere Pro, that LUT gives a perfect visual match.

Do you think altering the tags on H.264/H.265 files could be achieved without transcoding? And in batch?

[Attila Bakos]

5 minutes ago, androidlad said:

Interesting. In Premiere Pro, that LUT gives a perfect visual match.

Do you think altering the tags on H.264/H.265 files could be achieved without transcoding? And in batch?

Yes in most cases that LUT will give good results, but I had some shots with pink colors where it was ever so slightly off.

Yes you can alter the tags without transcoding, but I don't see why you would do that. Fuji's tags are actually correct, the problem is that the mainstream editors ignore them. If you modify the tags the files will look off even in editors that actually care about the metadata.

[androidlad]

27 minutes ago, Attila Bakos said:

Yes in most cases that LUT will give good results, but I had some shots with pink colors where it was ever so slightly off.

Yes you can alter the tags without transcoding, but I don't see why you would do that. Fuji's tags are actually correct, the problem is that the mainstream editors ignore them. If you modify the tags the files will look off even in editors that actually care about the metadata.

I meant altering the tags to all BT.709 as well as removing the full range tag (or deliberately changing it to limited), because I heard Premiere Pro handles full range tagged files as yuvj420p format and decode using the wrong matrix regardless of resolution. Could you experiment with that if you have time? Thanks.

[Attila Bakos]

1 hour ago, androidlad said:

I meant altering the tags to all BT.709 as well as removing the full range tag (or deliberately changing it to limited), because I heard Premiere Pro handles full range tagged files as yuvj420p format and decode using the wrong matrix regardless of resolution. Could you experiment with that if you have time? Thanks.

I tried removing the full range flag, no change. Also tried removing the full range flag & altering all color related tags, no change. Premiere and Resolve seem to completely ignore these tags.

[Attila Bakos]

On 3/14/2019 at 2:18 PM, androidlad said:

Interesting. In Premiere Pro, that LUT gives a perfect visual match.

I finally figured out why I experienced problems with the LUT. An incorrect YCbCr->RGB conversion will result in values outside the 0-1 range. The LUT sees these values as 0 and 1 in Resolve, that's the reason for the inaccuracy. Premiere handles the LUT differently, there is no clamping there, and the results will be perfect, identical to using the DCTL version in Resolve. However it's possible the build a perfect LUT for Resolve as well, which will come in handy for non-Studio users. I actually built one, I plan to publish it alongside a video describing the problem in detail.