Attila Bakos

Yes, but hopefully they fixed all these issues in 16. Will report back once I can test it. I'm still on 15.

Finally finished this project:
 
More info: http://colorizer.net/index.php?op=xt3

Nice work, thank you !
I'll buy it as soon as I get my X-T3 back !

Finally finished this project:
 
More info: http://colorizer.net/index.php?op=xt3

If you convert your clips anyway, why don't you convert the matrix? It's a bulletproof solution to this issue which I described in my video I recommended you to watch.
Or if you prefer a written version, here it is at the bottom of the page: http://colorizer.net/index.php?op=technical
It uses FFMPEG.

Here's a screen grab of the images in Resolve, the left screen is the XT3 file and the right is from the Ninja. I set them both to 300 and lined them up to form basically one image with a line in the middle. I thought that would be the easiest way to see if there's any difference in the colour. - both are set to Full in Clip Attributes. To my eyes, they're exactly the same, but if there is a difference, I wouldn't even think about it while shooting.
One thing I did notice though, is the capture from the Atomos is 2 or 3 frames behind the file straight from the camera, nothing major, and I'm sure it's not camera / recorder specific, but worth noting.
 
Edit:
If people want, I could also post screen grabs from the colour page, showing the histogram, vector scope, curves etc. But they don't change at all between the clips. Safe to say they're exactly the same image from that perspective too... 

Unfortunately I don't have time to go into the details right now, but I recommend you watch the video in the thread I linked earlier (previous page), it has the answers to most of your questions.
 
I like the oval, but the color transitions are a bit harsh around the sun. Nothing serious though, nice colors overall.

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.
 

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.