Attila Bakos

Thanks Attila, I used F-Log for this one and graded with Venice Cine lut; https://www.sierracreativeco.com.
The oval at 2:10 is from the lens, colours from the lut.

This is a bit oversimplified, a lot of cameras use the full range in their video files. Fuji is one of them.

ProRes is always interpreted as video range, even if it's a full range recording. I'm not even sure ProRes has flags for setting the data levels at all. When you set it manually to full range it becomes flatter, that's normal.

Right click the clips in the media pool, choose clip attributes, then select full at data levels.

Okay I won't be able to test it for a while, but if anyone has Resolve 16, here are the files that I used in my video:
https://drive.google.com/drive/folders/1GmZM2IlBIjiVHLdSlpHGRhZpDEg69zVZ
Just download both of them, set the Ninja V clip to full range (or set both of them to be safe), and check if the jacket has the same reds in Resolve.

I can only do it sometime tomorrow.
It's easy to test though. Shoot a color chart or something with reds, export a frame from Resolve, and do another export with ffmpeg like this:
ffmpeg -i input.mov -vframes 1 output.tif
Then compare output.tif with the frame coming from Resolve. If they look identical, the issue is fixed.

I can only do it sometime tomorrow.
It's easy to test though. Shoot a color chart or something with reds, export a frame from Resolve, and do another export with ffmpeg like this:
ffmpeg -i input.mov -vframes 1 output.tif
Then compare output.tif with the frame coming from Resolve. If they look identical, the issue is fixed.

That's actually a good advice, I watched some of Juan Melaras videos on repeat

I removed the free fix, and created a package with more options, including DCTLs: http://colorizer.net/index.php?op=technical
On the bottom of the page you'll still find an option to fix these issues for free using FFMPEG.
I can include more stuff in the package if any of you have suggestions.

I removed the free fix, and created a package with more options, including DCTLs: http://colorizer.net/index.php?op=technical
On the bottom of the page you'll still find an option to fix these issues for free using FFMPEG.
I can include more stuff in the package if any of you have suggestions.

Just keep in mind that you can't fix a bad yuv to rgb conversion with cst. So if you know the math, create a dctl that undoes the 709 matrix and applies the 601 matrix. You can also create one for hlg that undoes the 709 matrix and applies the 2020 matrix. I think I'll create a package with all the possible fixes for this issue, in lut and dctl format, and I might ask a few dollars for it. 

Sometimes I feel stupid that I give away stuff like this for free.. 

Sometimes I feel stupid that I give away stuff like this for free.. 

Respecting or disrespecting the matrix coefficients tag won't result in blown-out footage. I believe you're talking about transfer characteristics, which is basicly the linearization function.
Disrespecting the matrix coefficients tag will result in different colors, as you have seen in my video.
I can show you what I mean. This is from a HLG video using the BT.709 matrix, extracted with FFMPEG. (Resolve has the same colors, I checked it.)

 
This is the same frame using the BT.2020 matrix, this is actually how FFMPEG extracts the frame without any extra options, since it respects the tags by default. But I also used zscale to do the scaling manually and the results are identical to what FFMPEG does by default:

 
Open the files in different tabs and switch between them. You might say that this doesn't matter to you, but the difference is there.

Sorry I couldn't test HLG yet, the only external recordings I got are not HLG.
Something interesting: with the help of @Papiskokuji and a friend of mine I did some tests with Sony footage coming from two different Sony bodies, and it seems the files require the BT.601 matrix as well, but they are not even flagged. In Resolve all files look off, in Premiere some are okay, some are not. More testing is needed, but I'm surprised I don't see topics or videos about this.

The issue this video covers was already mentioned in several topics, but I promised a video explanation and fixes, so here it is.
Beware: long, boring, bad English.
 

DJI "officially announced" in a forum post by staff account that Ronin S will support X-T3 via a future firmware update.
Regarding X-T2 and X-H1, they are "not sure".
https://forum.dji.com/thread-151303-2-1.html

The issue this video covers was already mentioned in several topics, but I promised a video explanation and fixes, so here it is.
Beware: long, boring, bad English.
 

The issue this video covers was already mentioned in several topics, but I promised a video explanation and fixes, so here it is.
Beware: long, boring, bad English.
 

No, the magenta issue is something else, but I wouldn't worry about it too much. It's not something you see in each clip, I haven't seen it on my X-T3 yet.
For the workarounds check this thread:
 
 

The issue this video covers was already mentioned in several topics, but I promised a video explanation and fixes, so here it is.
Beware: long, boring, bad English.
 

I can only speak of ProRes, but it was fine, no color issues there.

No, the magenta issue is something else, but I wouldn't worry about it too much. It's not something you see in each clip, I haven't seen it on my X-T3 yet.
For the workarounds check this thread:
 
 

1. Signal format displays 59.94 instead of 60.
2. Default color temperature changed to “Native”
3. Signal format display and battery info display can be individually turned on/off.
4. User LUT supports 33x33x33 format upload
5. Add “Saturation” adjustment in calibration menu.
6. Fixed other bugs. Tool: SD card, FAT32

There's a thread about it here: https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=88961
Make sure you're updated to the latest drivers.