wa666ou Posted February 10, 2019 Share Posted February 10, 2019 I've recently got Atomos Ninja V for my Fuji X-H1. I've set F-Log inside the camera and F-Log, F-gamma, inside Ninja. But for some reason, the image from Ninja is more saturated. Is that normal? I have no previous experience with external recorders. And it's not monitoring difference, it's the result file. I will upload a sample tomorrow. Quote Link to comment Share on other sites More sharing options...
thebrothersthre3 Posted February 10, 2019 Share Posted February 10, 2019 18 minutes ago, wa666ou said: I've recently got Atomos Ninja V for my Fuji X-H1. I've set F-Log inside the camera and F-Log, F-gamma, inside Ninja. But for some reason, the image from Ninja is more saturated. Is that normal? I have no previous experience with external recorders. And it's not monitoring difference, it's the result file. I will upload a sample tomorrow. Yes it's a known issue with Fuji, not sure if there is a solution Quote Link to comment Share on other sites More sharing options...
androidlad Posted February 10, 2019 Share Posted February 10, 2019 There was a lengthy discussion/investigation regarding this issue. The conclusion was Ninja files show the correct colour. Fuji internal files are handled incorrectly by certain applications including Premiere and Resolve (version dependent) due to confusing colour metadata tags. Reds turn orange and greens become darkened. In high end finishing tools such as Baselight and Scratch, the files are completely identical. Quote Link to comment Share on other sites More sharing options...
thebrothersthre3 Posted February 10, 2019 Share Posted February 10, 2019 17 minutes ago, androidlad said: There was a lengthy discussion/investigation regarding this issue. The conclusion was Ninja files show the correct colour. Fuji internal files are handled incorrectly by certain applications including Premiere and Resolve (version dependent) due to confusing colour metadata tags. Reds turn orange and greens become darkened. In high end finishing tools such as Baselight and Scratch, the files are completely identical. Was there a workaround in premiere? Quote Link to comment Share on other sites More sharing options...
androidlad Posted February 10, 2019 Share Posted February 10, 2019 12 minutes ago, thebrothersthre3 said: Was there a workaround in premiere? Apply "Rec709toRec601.cube" LUT to Fuji internal files from this pack: http://www.pantarheon.org/601vs709luts.zip Root cause of this problem: Quote Link to comment Share on other sites More sharing options...
wa666ou Posted February 11, 2019 Author Share Posted February 11, 2019 I'm seeing a different image in just viewing the files in Quicktime. So, not even going into editing software. Quote Link to comment Share on other sites More sharing options...
androidlad Posted February 11, 2019 Share Posted February 11, 2019 3 hours ago, wa666ou said: I'm seeing a different image in just viewing the files in Quicktime. So, not even going into editing software. Exactly. The confusing colour metadata tags cause the Fuji internal files to be decoded incorrectly, it doesn't matter if it's video player or video editor. Open a file with MediaInfo and you'll see. Quote Link to comment Share on other sites More sharing options...
thephoenix Posted February 12, 2019 Share Posted February 12, 2019 same issue with xt3 ? Quote Link to comment Share on other sites More sharing options...
thephoenix Posted February 12, 2019 Share Posted February 12, 2019 even if the camera output has been set to fuji in the ninja v menu ? Quote Link to comment Share on other sites More sharing options...
androidlad Posted February 12, 2019 Share Posted February 12, 2019 1 hour ago, thephoenix said: same issue with xt3 ? 8 minutes ago, thephoenix said: even if the camera output has been set to fuji in the ninja v menu ? It's nothing to do with Ninja. It's the way Fuji cameras encode video files with confusing metadata that causes the discrepancy. Ninja recordings show the correct colour, the video level just need to be changed to full instead of limited. Quote Link to comment Share on other sites More sharing options...
Attila Bakos Posted March 5, 2019 Share Posted March 5, 2019 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 thephoenix 1 Quote Link to comment Share on other sites More sharing options...
Attila Bakos Posted March 6, 2019 Share Posted March 6, 2019 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 Quote Link to comment Share on other sites More sharing options...
androidlad Posted March 6, 2019 Share Posted March 6, 2019 54 minutes ago, Attila Bakos said: 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 BBC already published a tool to change colour metadata and I tried it, it didn't work because all it does (including recent ffmpeg builds) is changing the metadata tags at container level (QuickTime), while the actual metadata tags are also present at stream level (H.264/H.265), to change metadata tags at stream level you might need to go extremely sophisticated with hex editor. Quote Link to comment Share on other sites More sharing options...
Attila Bakos Posted March 6, 2019 Share Posted March 6, 2019 14 minutes ago, androidlad said: BBC already published a tool to change colour metadata and I tried it, it didn't work because all it does (including recent ffmpeg builds) is changing the metadata tags at container level (QuickTime), while the actual metadata tags are also present at stream level (H.264/H.265), to change metadata tags at stream level you might need to go extremely sophisticated with hex editor. 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 Quote Link to comment Share on other sites More sharing options...
androidlad Posted March 6, 2019 Share Posted March 6, 2019 22 minutes ago, Attila Bakos said: 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 were you able to change metadata tags for both stream and container ? What does ffprobe say for the altered file? Quote Link to comment Share on other sites More sharing options...
Attila Bakos Posted March 6, 2019 Share Posted March 6, 2019 16 minutes ago, androidlad said: were you able to change metadata tags for both stream and container ? What does ffprobe say for the altered file? 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. Quote Link to comment Share on other sites More sharing options...
Attila Bakos Posted March 6, 2019 Share Posted March 6, 2019 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. Quote Link to comment Share on other sites More sharing options...
androidlad Posted March 6, 2019 Share Posted March 6, 2019 2 hours ago, Attila Bakos said: 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. Interesting. Why do you think internal files and ProRes file match in Scratch despite one uses BT.601 matrix and the other uses BT.709 matrix? Quote Link to comment Share on other sites More sharing options...
Attila Bakos Posted March 6, 2019 Share Posted March 6, 2019 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 Quote Link to comment Share on other sites More sharing options...
androidlad Posted March 6, 2019 Share Posted March 6, 2019 19 minutes ago, Attila Bakos said: 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 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.