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

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

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.

I think the underlying YCbCr data is different in the internal version compared to the ProRes version. Both share the same BT.709 primaries but the internal version requires the BT.601 matrix coefficients to convert to the correct RGB values. Resolve and Premiere seems to ignore this flag and they use the BT.709 matrix. This is perfect for the external recording, but not so much for the internal as we have seen. The LUT and the matrix that's included in that package is basicly a multiplication of two matrices, the first one converts from RGB to YCbCr using the 701 matrix, the second one converts YCbCr to RGB with the 601 matrix. So it basicly undoes the wrong YCbCr->RGB conversion and redoes it correctly. Scratch does one thing that Premiere & Resolve does not, it actually gives a shit about the flags

UPDATE: I believe we were looking at this the wrong way. There is only one place for these tags and it's at the stream level, however Premiere and Resolve doesn't even read these flags. Assimilate Scratch does, and if you modify the flags with FFMpeg the footage will look different in Scratch. The difference is also visible with MPC-HC, or FFPlay. At this point I don't think we can do much, maybe tell BM Support that they should care about these flags. This also leads me to believe that the Fuji flags are correct, and the bad interpretation is not a result of a confusion.

I can change the stream metadata tags with the commands I posted earlier. If I list the streams with ffprobe (ffprobe -v error -show_streams INPUT.MOV), then I get this in the original HEVC stream: color_space=smpte170m color_transfer=smpte170m color_primaries=bt709 After converting all to bt709 I get this: color_space=bt709 color_transfer=bt709 color_primaries=bt709 What I don't know is how I can change things on the container level. EDIT: ffprobe -show_format actually shows the container tags, and this is what I get for the original file: [FORMAT] filename=DSCF7556.MOV nb_streams=3 nb_programs=0 format_name=mov,mp4,m4a,3gp,3g2,mj2 format_long_name=QuickTime / MOV start_time=0.000000 duration=25.000000 size=635467264 bit_rate=203349524 probe_score=100 TAG:major_brand=qt TAG:minor_version=0 TAG:compatible_brands=qt TAG:creation_time=2019-01-14T16:13:13.000000Z TAG:original_format=Digital Camera TAG:original_format-eng=Digital Camera TAG:comment=FUJIFILM DIGITAL CAMERA X-T3 TAG:comment-eng=FUJIFILM DIGITAL CAMERA X-T3 [/FORMAT] So there is nothing here about colors. Then it's interesing why changing metadata on the stream level does nothing in Resolve/Premiere.

I see. So it's theoretically possible but we don't have the tools. Doing this by hand is beyond my skills I'm afraid. Btw ffmpeg's manual says, that it modifies headers in the stream: https://ffmpeg.org/ffmpeg-bitstream-filters.html#hevc_005fmetadata

With recent ffmpeg builds you can change HEVC/H.264 flags, and it doesn't solve the issue. There must be something else too. If you want to try it, use this command to change all the color related flags to BT.709: ffmpeg -i INPUT.MOV -c copy -bsf:v hevc_metadata=colour_primaries=1:transfer_characteristics=1:matrix_coefficients=1 OUTPUT.MOV And this to change all to BT.601: ffmpeg -i INPUT.MOV -c copy -bsf:v hevc_metadata=colour_primaries=6:transfer_characteristics=6:matrix_coefficients=6 OUTPUT.MOV

If you're a Resolve Studio user, you can try this DCTL, it does the same thing as the Rec709toRec601.cube mentioned earlier, but it won't clip values, and it's a bit more precise: https://www.dropbox.com/s/pm3nbyco6wg25kx/FujifilmColorFix.dctl?dl=1

We had a discussion in another thread but I forgot what the consensus was. I still have those files with the man in red jacket coming from the X-T3 and from the Ninja V. In Assimilate Scratch they look the same, but in Premiere and Resolve they look different. We already have the LUTs to make them look identical, but I don't know which one is correctly displayed. Edit: nevermind, just found the thread where you said that the Ninja is showing the correct colours. I think I'll do a DCTL for the Fuji internal files for more precision.

It's just a window around the person with a very soft edge, it can be tracked as well. I use this many times to help focusing on the subject. If you don't overdo it can be quite helpful sometimes.

Here's a quickie. A BT.2020-Rec.709 conversion, a curve to highlight the person, some vignette to darken everything else, Kodak 2383 D55 on 40%, slightly boosted saturation and desaturated shadows.

Try setting both clips to full range in Resolve. Do they show a difference?

I wish it had waveform/parade.

Great, thanks!

Does this monitor have RGB parade?

That's what I thought when the issue appeared. I don't think it will be fixed.

The name

Looks good, I use this phone holder until I get something better: https://m.aliexpress.com/item/32797019174.html?trace=wwwdetail2mobilesitedetail&spider=y&productId=32797019174&productSubject=Ulanzi-IRON-MAN-II-Aluminum-Metal-Smartphone-Tripod-Mount-with-Cold-Shoe-Mount-Cell-Phone-Tripod

If we assume that the HEVC is displayed correctly, then applying this conversion to the Ninja V Prores file will do the trick: ffmpeg -i input.mov -vf scale=in_color_matrix=bt709:out_color_matrix=bt601 -colorspace bt709 -c:v prores_ks -profile:v 2 -c:a copy output.mov I used level 2 (normal) compression. Use level 3 for HQ. I don't know if you can do this without recompression. Also commented this on youtube. EDIT: There's also an easier fix, download this LUT pack: http://www.pantarheon.org/601vs709luts.zip Then apply Rec601ToRec709.cube on the Ninja footage.

The magenta banding was horrible on the X-T2, but I didn't see it yet on the X-T3. I remember your post so I know that it's still there, but it might be manageable. Do you have a downloadable MOV with the issue?

Yes, but I don't miss 4:2:2 at all with this camera, so I'm not facing issues like this guy does. Just checked the liftgammagain forum and apparently my conclusion was that the latest Resolve & Premiere are fine, there was no difference between in camera and external recordings. But seeing this video this is not true anymore, at least not for the X-T3 & the Ninja V.

A simple one, I sold my X-T2 and the Video Assist 4K ? Not for this reason though. Unfortunately I can't remember if I applied a conversion or just ignored the issue.

Ah, so this is still an issue. The guy's conlusion that the shift is caused by less color information in the H265 is off, but I see you already addressed it in the comments.

I thought the same so I played with the shutter speed, didn't make a difference, and when I first saw it it was with natural light.