Jump to content

Atomos Ninja V and Fuji X-H1


wa666ou

Recommended Posts

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.

Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

@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.

 

Link to post
Share on other sites
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?

Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

Link to post
Share on other sites
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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...