Attila Bakos

DR400 update for the LUT pack. Previous customers will get it for free, I'll send out the download links this week.

Thanks! This wasn't any harder to create than my other LUT packs, they are all math based, I don't do anything by hand. Although I had to choose S-Gamut3.cine instead of S-Gamut for a better match.

Then you tell her no problem sweetheart, we'll fix you in post. ?

My new stuff, details here: http://colorizer.net/index.php?op=slog2 If you have some S-Log2/S-Gamut3.cine footage, I can apply my LUTs to them if that helps to judge quality. Created using an A6300 & X-T3.

Yup, that might be the reason why people think it has more DR, but it's just a different mapping of the same latitude with the same analog amp. It has a bit more precision because it also uses values below 95 (10bit), and this MIGHT lead to ever so slightly cleaner blacks (when both exposed to the right), but it's minimal really. Choose HLG if you run into those magenta issues or if you prefer the workflow, otherwise F-Log is just fine.

I suggest you do your own tests, take a contrasty scene, expose both to the right and compare shadow detail in post. I didn't see a difference in DR. Noise was similar.

Nope

I'd love to see a video about it.

I sell some technical LUTs that fix incorrect YUV-RGB conversion, for those it was absolutely necessary to reach values below 0 and above 1. I didn't have problems in Premiere, although I use different headers than in Resolve. (DOMAIN_MIN and DOMAIN_MAX instead of LUT_3D_INPUT_RANGE). Another example of Premiere supporting these LUTs is when you go to the technical Lumetri presets, they are actually 1D LUTs, this is the source of the Full to Legal range 10 bit ("c:\Program Files\Adobe\Adobe Premiere Pro CC 2019\Lumetri\LUTs\Legacy\FullToSMPTE10.cube") LUT_1D_SIZE 2 DOMAIN_MIN -0.07306 -0.07306 -0.07306 DOMAIN_MAX 1.09475 1.09475 1.09475 0.0 0.0 0.0 1.0 1.0 1.0

What do you call a wide range LUT?

Isn't the Shinobi better for the same price (on B&H)?

Do we know anything about the firmware updates? Will the X-T3 get this new film simulation? Edit: nevermind, just saw this picture:

I use the Studio version but the free version is great, lots of people from this forum use it. I'm typing from a phone now, can't go into details, but I found a feature comparison for v15, it's a good start: https://documents.blackmagicdesign.com/SupportNotes/DaVinci_Resolve_15_Feature_Comparison.pdf

Resolve is free unless you need the features of the Studio version.

This one really works!

Hmm... why is this my workflow? I rarely use CST nodes and I don't use the official LUT's.

Efficiency plays a role as well, HEVC is way more advanced in this regard. The advantage of 4:2:2 might be visible, but I'm not sure about that either. When I had the X-T2 I used it with a Blackmagic Video Assist 4K. In some cases like fine wall textures I could see a difference in detail at 200-300% magnification, but I had to zoom in to like 600-800% to see difference in color transitions (4:2:0 vs 4:2:2). Now with 4x the data rate and a more efficient codec, my guess is that the difference is almost invisible.

I know the technical differences, but I'm not sure if you can actually see any difference, even when zoomed in. Would be great if someone could upload the same scene with lots of detail in 400 Mbps internal and ProRes as well.

Did you have a chance to compare the quality of internal files to ProRes coming from the Ninja V? I wonder if there is any noticeable difference.

During the creation of my F-Log LUT pack I gathered enough data to create what you need. It needs some time and coding, so it would cost a little. PM me if you're interested.

Yeah 16 doesn't have it, 16.1 b2 (the latest beta) added it.

I did my tests using Fujifilm F-Log as input color space, then Rec.709 Gamma 2.4 as timeline & output color space. I don't use HLG but for that I'd use Rec.2100 HLG as input, in fact that's automatically chosen by RCM if you import a Fuji HLG file. (in Resolve 16.1 beta 2) About interpretation of F-Log files (didn't test HLG yet): If you use the Ninja V then you're fine. If you use internal footage then you're fine in Davinci YRGB and ACES, but not (yet) in RCM. If you transcode the footage by doing a matrix conversion from BT.601 to BT.709 then you're fine. If you transcode the footage without a matrix conversion and you preserve the original matrix coefficients flag, then you're fine in Davinci YRGB and ACES, but not (yet) in RCM. If you transcode the footage without a matrix conversion and you omit (or simply rewrite) the matrix coefficients flag, then the footage will be interpreted incorrectly everywhere. It all comes down to how shutter encoder works. I can only help with FFMPEG.

That's kinda the point here, that once the interpretation issue is fixed in RCM there will be almost no difference. Right now RCM is different from the others but yeah, you have to open the files in separate tabs and click back and forth to see the difference. A real world scenario might be more telling.

I tried to match the gamma & overall saturation here to see the color differences. Everything is done in the latest beta of Resolve. 1. WDR LUT 2. My ACES F-Log IDT 3. RCM 4. RCM with fixed YCbCr->RGB conversion. WDR and ACES are pretty similar, the WDR has more saturated reds. RCM is different in many patches, however if the input file is interpreted correctly it looks pretty close to the other two. So in terms of color the differences are minor, once RCM is fixed. I believe the most difference will be caused by WB adjustments.

I'm not sure about this yet, but RCM seems to have some kind of color toning. When I try Davinci YRGB + WDR LUT I get colors pretty close to what I get with my F-Log ACES profile. They both convert gamma and colorspace only, there is no special color treatment. But when I check the same clips in RCM they seem to be overall warmer, the greens are more yellowish, the blues are more cyanish, like a filmic LUT already applied In some situations it will be more pleasant to the eye but I wonder why it's happening. Part of this must be caused by the bad interpretation of the files, especially the yellowish greens, but this alone can't be the cause of such a big difference. Will continue testing.