Attila Bakos

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?

To me this seems to be the exact same issue as the one described in the video, but with different matrices. There are 3 matrices to go from YUV (YCbCr to be technically correct) to RGB. For SD usually the BT.601 matrix is used, for HD the BT.709 matrix, and there's the BT.2020 matrix which you can see in HLG for example. That doesn't mean that you can't encode an UHD resolution log format with the BT.601 matrix, Fuji does just that. And as androidlad mentioned, you can have Alexa log encoded with the BT.709 matrix. To have the right colors in RGB, you have to use the correct matrix. Then you can delog your footage and convert color space etc. But all this comes after the YUV->RGB conversion.

20 minutes ago, androidlad said:

Yes, doesn't matter for post-production. We use HLG as an alternative log profile.

BT.2020 matrix coefficients tag is required for HDR playback, or on-the-fly conversion for SDR playback.

This is why in Scratch, X-T3 HLG files are default blown-out (on an SDR display) because Scratch respects the tags. If we change the decoding parameter to BT.709 SDR, the images return to the flat look as seen on camera.

Premiere ignores the tags and decodes everything in BT.709, so HLG files have that flat look ready for grading.

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.

1 hour ago, androidlad said:

Also it's not really a problem for external ProRes for HLG to contain all BT.709 tags. HLG/BT.2020 tags are required for instant HDR playback on end user devices, or for automatic HDR to SDR conversion. Doesn't matter for post-production. Alexa Log-C ProRes carry all BT.709 tags as well, ARRI has to put additional metadata field to say it's Log C.

There is a matrix in the ITU-R BT.2020 specification that's different from BT.709 and BT.601. If that doesn't matter, then this whole topic is meaningless

Just now, Llaasseerr said:

I haven't been able to get the externally recorded files to match using CST nodes so far, even though the transform spaces are all common types. It seems better to get it right at a metadata tag level if the Atomos supports that. To be honest I'm okay recording h.265 for now because I'm looking at a 2k finish, so the extra chroma information in the ProRes is less useful. But I'd like to sort out why I'm not getting full range h.265 into Resolve all of a sudden.

I didn't test HLG but if your issue with externally recorded files is metadata only, ffmpeg can change tags without re-encoding using the bitstream filter. I can help you with that if needed.

Yes you have to be careful with externally recorded files. Unless you have some kind of switch they will have BT.709 flags, at least the ones I've seen so far, but sometimes the underlying data requires BT.601 or BT.2020 matrix, so the NLE will have no chance to show it correctly.

On 4/19/2019 at 3:10 PM, thephoenix said:

any shifting in hlg ?

i record botj internal and external in hlg and same color, actualy maybe more about saturation, and exposure difference between internal and external

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.

What happens if you don't convert to ProRes? I'm asking because the changelog of 13.0.2 says that it now reads PQ/HLG color information accurately from ProRes containers.