Attila Bakos

12 hours ago, thephoenix said:

to me the real question is "will it still be there after transcoding to prores or dnxhr" because you don't want to work with h265 files directly in resolve. or you have to create proxy files.

did a test and i had a clear difference in red

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.

28 minutes ago, thephoenix said:

you clearly see a difference on my pic anyway. so looks like problem it not solved.

one question.

problem is with fuji flog internal files.

it means ninja files are not affected right ?

to correct it do we have to apply the fuji lut flog to rec709 ? or do we have to always apply this lut to files coming from the fuji and also the ninja ?

because when you mix sources it is a bit a tricky to apply the lut only to some rushes.

or maybe you can convert fuji internal files to prores or dnxhd applying the lut ? (shutter encoder can do that)

 

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.
 

34 minutes ago, keessie65 said:

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.

I like the oval, but the color transitions are a bit harsh around the sun. Nothing serious though, nice colors overall.

40 minutes ago, androidlad said:

Strictly speaking it's full range 0-1023. But Fuji encodes nothing between 0-95.

Yes, that's correct.

30 minutes ago, BrunoCH said:

The most accurate way will be when Resolve will have an F-log preset for rushes. 

For what exactly do we need more accuracy? We know all about F-Log, all the info is there in the data sheet provided by Fujifilm.

2 minutes ago, BrunoCH said:

I think fuji log use full range into the limit of video range (Panasonic log don't use full range into video range) 

Fuji log uses 95-1023, because of the gamma curve. That's still a wider range than video range (64-940).

39 minutes ago, BrunoCH said:

Full data is about still photo, like jpg dpx etc (image sequence); RGB file.

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

20 minutes ago, thephoenix said:

ok. can you tell me more about full data level and why is it not set to full by default ?

just discovered that it was set to auto and when setting to full then image changes and seems to be flatter than without (flog)

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.

Just now, thephoenix said:

well... since i have the free version h265 will not open in resolve

can convert to dnxhr using shutter encoder but will it change something ?

Don't bother with converting, we need to see how Resolve handles the original files. Maybe someone else can help us out.

4 minutes ago, thephoenix said:

what do you mean ?

will be able to do that within a few hours as i have to work in resolve

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.

13 hours ago, keessie65 said:

Shot this one with my X-T3 in April. I was happy with my Samsung NX1, but X-T3 is way better (except battery and grip). Filmed with anamorphic lens Bolex Moller 16/32/1.5x.

 

Nice shots! Which profile is this? The sun looks a bit weird in some of them (at 2:10 for example). Is this due to grading?

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.

3 hours ago, andrew_dotdot said:

Resolve 16 Beta 3 -- I posted this in the thread about Resolve 16, but the Fuji fans are here: Does anyone know what this snippet from the change log specifically is talking about?

If we are lucky they fixed this issue:

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

11 hours ago, kye said:

From Toms video?

What about it don't you like?  I could do without the skin tone smoothing myself, but the technique is pretty standard, I just don't think I'd posted a video showing how to do strong colouring and still keep reasonable skin tones.

I didn't watch all of it, but he doesn't seem to convert S-Gamut to Rec.709. I know that he has skills and a good reputation, but I always find it amateurish when people apply some contrast and forget about the gamut.

6 minutes ago, Andrew Reid said:

Said it before, will say it again. Try H.264.

One of the files he uploaded is actually H.264.

Just tested it with similar settings and conditions, my unit doesn't have this issue.

4 hours ago, Llaasseerr said:

Fair enough that the correction needs to go first and work on the camera original image. In which case there's no need to break up the CST operation with the HLG to linear in one node and linear to LogC in the next one. So if I'm understanding you correctly, could you just use a CST node after your matrix fix, followed by an Arri logC to Rec709 LUT then concatenate the whole thing? There is then no explicit intermediary stage there that has a floating point output outside 0-1 and your start and end points are normalized images.

Having said that, you should be able to handle values outside 0-1 with a shaper LUT so as to prevent clipping. I can definitely do this in Nuke. But then is Resolve really clipping something if you generate a LUT which first goes from HLG to linear then linear to LogC, then Rec709? I haven't tried in Resolve. But going to LogC is inherently a shaper LUT.

Yes I only need to use a single CST node after the fix and then the Arri LogC to Rec709 LUT. The problem is concatenating, because the matrix fix works in a different domain. That is, it does not require a shaper to work with values outside the 0-1 range. In theory I could use a shaper to bring values into the 0-1 range and alter the matrix fix to work with these new values (if I can), then I could concatenate the matrix fix, the cst node, and the arri lut. There is a problem though, while Resolve can load a 3D LUT with a shaper included (which is basicly an 1D LUT), Premiere doesn't seem to support this. So again, I think it's not worth the effort that's required.

You mentioned that it happens in various bitrates, but does it happen in both H.264 and H.265?

9 hours ago, Attila Bakos said:

The matrix fix has to go first (it's not an RGB color space correction, doesn't require linear space). You can absolutely concatenate LUTs, I can even make LUTs from CST corrections, but they will work in the 0-1 floating point range, just like the one you can download from Arri LUT generator. The matrix fix however is a special LUT, it's input range is wider. The reason for that is that a wrong YCbCr->RGB conversion will result in values outside of this range and you need to fix them as well. One does not simply concatenate LUTs with different input ranges But I guess I can scale everything else to the range of the matrix fix. Will be an interesting experiment as soon as I have time.

I couldn't create an all-in-one LUT that addresses the values outside of the 0-1 range as well. If I ignore those values then creating a HLG to Arri 709 LUT with the correction included is no problem. However, I can't include anything in a technical pack that's not technically perfect.
In theory you could apply the correction matrix via DCTL and in that same DCTL you could load the HLG to Arri 709 LUT. (I never used it but I read somewhere that DCTLs can load LUTs.) This could work but only for Resolve Studio users, so I don't think it's worth doing.

4 hours ago, Llaasseerr said:

You can break it down by doing HLG to Scene Linear under the HLG LUT menu -> custom matrix fix ->  Rec2100 (Rec2020) to AWG (CST node) -> Linear AWG to the Alexa 709 look (download a LUT from the Arri LUT generator).

I would do a sanity check to confirm it matches without the matrix fix, then add it in.

As for baking it down into a single LUT, I know I can do this in Nuke but that's an expensive piece of software so it may not be an option for everyone. 

Edit: corrected order of operations.

The matrix fix has to go first (it's not an RGB color space correction, doesn't require linear space). You can absolutely concatenate LUTs, I can even make LUTs from CST corrections, but they will work in the 0-1 floating point range, just like the one you can download from Arri LUT generator. The matrix fix however is a special LUT, it's input range is wider. The reason for that is that a wrong YCbCr->RGB conversion will result in values outside of this range and you need to fix them as well. One does not simply concatenate LUTs with different input ranges But I guess I can scale everything else to the range of the matrix fix. Will be an interesting experiment as soon as I have time.

3 hours ago, thephoenix said:

how does it work with resolve color management ?

If RCM alters the RGB values before the first node, then you can't use these LUTs with them. I don't use RCM, but to use these LUTs I would recommend Davinci YRGB mode, then the correction LUT in the first node, and then a CST node to simulate what you do in RCM.

49 minutes ago, androidlad said:

What's the difference between Resolve cube and Premiere cube? Just clamping?

Can you maybe put in colour space mapping LUTs with the matrix fixes combined? For example, HLG to Alexa 709 with matrix fix as one single LUT?

 

There is only a minor difference in the header of the file, the data is exactly the same.
What you say is theoretically possible if the math for HLG to Alexa 709 conversion is known.

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

I understand your issue but I honestly don't know what's causing it, OSX is unknown territory for me. 

What kind of matrix do you need?