Hi, Dermot. Thanks for your input. Did you mean S-Log3 IDT, or S-Log? For your test did you use a 709 ODT with ACES RRT, or straight 709? I don't use the ACES RRT in Logarist, so I wouldn't expect Logarist's result to match your ACES test if you used the RRT. If you are using a straight 709 output transform (not the ACES ODT with its built-in RRT) and you applied gain in ACES linear, in theory Logarist and ACES would match, assuming middle greys are mapped identically and barring some mistake in making my S-Log3 input transform. broughtonfilm is helping me and I'm going to make sure I didn't screw up S-Log3. Though whether they match would depend on that ACES implementation and how levels are read for the Sony FS7 file before being fed to the IDT. I found a lot of implementations did not map levels correctly, assuming legal when it was full or vice versa. Since you know ACES well, I will say that I used ACES before Logarist. Logarist is the same concept as ACEScc, except I modified the color space to use parameters that I thought were more sane, and the transforms are baked into LUTs. It's not designed to compete with ACES. Though I've never used Baselight, I've seen that it has really good color management and ACES support. The ACES implementation of Resolve is half baked, and its color managed workflow isn't so great either. Logarist is for people who would never use ACES because ACES is too complicated or too expensive to get a good implementation of. And yes, NLEs don't have good film-style grading tools. I made sure the basic corrections were covered in each app, so Logarist can be used as a first-pass correction. After that, it's up to the user whether he wants to do further corrections in the Logarist space or traditional video corrections in the display color space.
Logarist Color Correction for DaVinci Resolve, Vegas Pro, Final Cut Pro X
- Thread starter balazer
- Start date
Well it turns out I did have a rather dumb bug in the generation of S-Log1/2/3 LUTs for DaVinci Resolve, both Mac and Windows versions. I don't know if it explains the problem that broughtonfilm saw, but the bug is causing levels to be mapped incorrectly. I will provide a new Logarist version soon to fix the bug. FCPX and Vegas Pro are unaffected. Sorry about this and thanks for your patience, everyone.
Which LUTs show clean maths?
So, is working with the Logarist LUTs make it easier to grade colors in Resolve?
Are you saying that the results in the above test are different between ACES and Logarist, or that in one case (which one?) the output is identical to the input, while in the other case it isn't?
a few (very few) come to mind, Technicolor, Deluxe, DaWerk's filmout viewer lut's, Steve Shaw's and Nucoda's bundled LUT's come to mind as one's that show lower end of unavoadble math errors
Didn't try in Resolve, was more focused on trying in MC and DS where ACES is not implemented although DS has had linear light as an option since 2008, end game is without a pivot control added to exposure, saturation and contrast controls i find the workflow sub-optimal
neither is even remotly close to the input as expected, and in the earlier version of logirist the logirist output of Slog3->709 did not match ACES output of Slog3->709, both seemed to be a workable starting point to get creative from, would have no issues with either one
I would chose ACES and a gradeing tool in almost any situation, and rarely touch color controls in an NLE anyway
Sony S-Log1/2/3 users: the previous version of Logarist for DaVinci Resolve (Mac and Win) had a level mapping bug. Contrast was lower than it was supposed to be, with elevated blacks. This problem is fixed in Logarist 1.2.0. FCPX and Vegas Pro were not affected. No other color spaces were affected. Thanks to broughtonfilm for helping me. I'm hopeful that this change will correct the problem he was seeing with banding and blockiness in the shadows.
Panasonic GH4 users: if you record V-Log L externally and you use a Mac, I have added a "Panasonic GH4 V-Log L external" transform in Logarist 1.2.0. It maps levels differently from the normal (internal) transform. This distinction is necessary on the Mac due to the way QuickTime decodes the video. No such distinction is necessary in Windows. Thanks to Thomas Smet for providing me with sample footage and running some tests.
Panasonic GH4 users: if you record V-Log L externally and you use a Mac, I have added a "Panasonic GH4 V-Log L external" transform in Logarist 1.2.0. It maps levels differently from the normal (internal) transform. This distinction is necessary on the Mac due to the way QuickTime decodes the video. No such distinction is necessary in Windows. Thanks to Thomas Smet for providing me with sample footage and running some tests.
Thomas Smet
Veteran
Fusion is free for Windows, OS X and now Linux so it might be nice to check it out at some point when you have some free time. As a professional VFX compositing application with built in 32 bit float and lut support it could be very handy to have a version of Logarist to support this application. I used to use Shake for VFX work many years ago and now use Fusion and sometimes taking raw material and applying luts right in Fusion is more desirable than grading in Resolve first and exporting a new video file just to use for compositing. Especially when I just need a rough lut to get log or raw into a decent color space for pulling a key to generate a matte.
Thomas Smet
Veteran
GH4 V-Log L external luts so far work great. Helps to compensate for the 0-255 to 16-235 flag difference when using external recorders. I usually compensate for that difference with my own FCPX effect I built but now I don't have to worry about it and Logarist will take care of it for me. So far I am really enjoying Logarist with V-log though it still is super painful and slow on my 2012 iMac. Not much Logarist can do about that.
broughtonfilm
Well-known member
I'm testing Logarist in DaVinci. This time with Panasonic GX85 footage. It seems that the BT709 to Logarist / Logarist BT709 LUT pair does a good job - it is very close! Still need to see it on a decent display and I haven't done extensive grading but so far I have to say that I LOVE Logarist! Somehow I feel that it works better with GX85 footage than with FS7's, can't explain why. Maybe because I'm more used to grading FS7 footage without Logarist, or maybe because it gives more flexibility in general because of LOG. I will test further and report back. Thank you, Jacob!
Cary Knoop
Veteran
When using GX85 footage always be aware that the GX85 records extended video, e.g 16-255. To use the LUT you either have to interpret the video as full range and lower the blacks or as video levels and put the highlights in range before you aply the correct LUT.
I made a small video to demonstrate the issue with extended video on the GX85 for Premiere but the same applies to Resolve:
The Logarist software includes a GH4 Cinelike D 16-255 to Logarist LUT ( along with Cinelike D 0-255 and Cinelike D 16-235 LUTs ), so if there is enough demand Jacob might consider making some GX85 specific LUTs.
broughtonfilm
Well-known member
It appears that it does not apply in this situation. I did not have to perform the procedure you described, looks like Logarist took care of it. Based on a waveform, it looks like the illegal range had been recovered before LUT / reverse LUT application. Have you tried Logarist?
Cary Knoop
Veteran
I tried it.
When you apply the BT.709 video levels to logarist LUT the out of range values do get clipped.
When you apply the full range version they do not and the highlights will end within legal range after conversion to BT.709.
However the conversion calculations may not be correct because the full range LUT expects the blacks to start at 0 not at 16.
Perhaps Jacob can provide some commentary on this.
broughtonfilm
Well-known member
Settings of our projects must be different because I'm getting different results. This is how I tested it: first I created a project and imported GX85 footage. I did not use Logarist, this was just a single node "traditional" way. On the waveform I could see that part of the highlights was outside of the legal range as in your video. I recovered it by adjusting the gain wheel - no clipping anywhere. I took a screen shot of the waveform. Then I created another project, this time I used Logarist (changed the project settings accordingly, changed clip attributes, per Jacob's instructions). Without making any adjustments with color wheels or curves I used waveform again - the highlights were not clipped - the shape of the topmost part of the waveform was the same as in the project without Logarist after the highlights were recovered, just shifted lower on the waveform scale and the whole waveform shape slightly squished. This is using BT709 Video Levels to Logarist LUT in the first step. Are you sure you followed all the instructions?
Cary Knoop
Veteran
Got it, I missed the clip attributes to video levels step!
Yes I can confirm there is no clipping.
Thanks!
Questions to balazer:
To make sure I got the instructions correct; in the settings for Canon EOS DSLRs the recommendation is Neutral picture style, with contrast, tone and saturation at 0 - which is the camera's default settings for the Neutral picture style. Is that correct?
Does setting the in-camera sharpening all the way down to zero have any effect on the color rendering and the Logarist LUTs?
To make sure I got the instructions correct; in the settings for Canon EOS DSLRs the recommendation is Neutral picture style, with contrast, tone and saturation at 0 - which is the camera's default settings for the Neutral picture style. Is that correct?
Does setting the in-camera sharpening all the way down to zero have any effect on the color rendering and the Logarist LUTs?
I see you figured it out, but yes, all of the Logarist input transforms read the whole range of the source video, including "superwhites" where applicable. There is no clipping in the input transforms. In fact for BT.709 I read all the way up to 130% and down to -15%. If you're wondering why I ask users to set Clip Attributes Data Levels to Video, it's because Resolve itself is not consistent about how it reads files when it's to Auto. Most of the time Resolve's Auto setting is the same as Video, but it depends on the video file format and even on the version of Resolve. To make it consistent, I took Resolve's variability out of the equation and let the Logarist LUTs deal with mapping the levels.
broughtonfilm, thanks for helping out. Glad you're liking it.
Yes, for the Canon EOS Neutral picture style, contrast, shadow, highlight, color tone, and saturation should all be set to zero in the camera. Let me know how that works out for you. I had to reverse engineer Canon's color pipeline and profile the camera to build the Neutral transform. I hope it will work well.
The sharpening setting has no effect on colors. You can set it however you want.
If you use FCPX and the Canon C300mk2 and you record Canon Log 1/2/3 internally and you upgraded the camera's firmware to version 1.0.6, I have new Logarist LUTs that compensate for the levels shift caused by Canon setting the video_full_range_flag erroneously in recordings made with this firmware version. Contact me to obtain the LUTs.
Final Cut Pro X users:
I have released Logarist for Final Cut Pro X 1.3.0, with these changes:
I've also updated the documentation to note that Final Cut Pro's built-in log processing should be turned off for Canon Log, S-Log, and VariCam V-Log.
http://www.logarist.com/
I have released Logarist for Final Cut Pro X 1.3.0, with these changes:
- Fixed a level mapping bug for V-Log L and V-Log
- Reduced the number of LUT points, to improve loading times in the mLUT Plugin and to fix out-of-memory conditions (especially for Cinelike D, which used too many points and could experience failures during rendering)
- Added support for Canon C300 Mark II internal XF-AVC recordings made with firmware version 1.0.6. This firmware version incorrectly sets the video_full_range_flag in its internal Canon Log 1/2/3 recordings, which causes levels to be mapped incorrectly in FCPX. For these recordings, use the full_range_flag LUTs, which compensate for the problem.
I've also updated the documentation to note that Final Cut Pro's built-in log processing should be turned off for Canon Log, S-Log, and VariCam V-Log.
http://www.logarist.com/