[Mike Most]

It looks like the time code in Resolve is being calculated as drop frame, even though you say it’s 23.98. DFTC is about 3 1/2 seconds lower per hour, so the difference would be just about right. Check your settings in Resolve and make sure that Drop Frame is not enabled.

[Mike Most]

Resolve Lite can do that. And it’s free.

[Mike Most]

It sounds like you somehow expect Resolve color corrections to be in the form of XML numbers that somehow Final Cut is going to be able to replicate. That has never been the case. You need to render in Resolve to bake in the color corrections you do.

[Mike Most]

With the DaVinci panels, you can navigate up and down the timeline for this via direct access buttons, although at least on the 2K panels, the trackball control of this has been removed.

[Mike Most]

It works the way I just described. Dynamics are preserved (including window tracking) if the time code is the same. If the new clip is longer than the original, it won’t trace properly. Basically it expects all of the frames of the destination clip to be included in the source clip. I’ve never really tried color tracing a project with various versions and I wouldn’t necessarily recommend it, but my guess is that it will reattach all versions of a multi version clip, provided the criteria is met. If not, it might offer you some choices in the color trace dialog, much as it does when there are conflicts because of matching time codes on various clips.

The easiest way to see if any of this works is to try it, then ask questions. It sounds like you’re asking the questions first…….

[Mike Most]

Color Trace works by using tape name and timecode, very similar to Avid relinking. If the tape name and the time code of both clips match, color trace will work. If they don’t, it won’t. So if you create new clips within Resolve, or you bring them in under a different tape name in the editing system, you won’t get a match. If you avoid that, and make sure the tape names and time codes are the same in the source project and the destination project, it will work. Remember that what’s in the EDL is the issue, not how you ID the files themselves for linking.

[Mike Most]

Which is exactly why a number of us have been “prodding” Blackmagic to add a log grading toolset to Resolve.

However, until that happens, you can use the offset controls in place of an exposure control, and the lift and gain masters as a contrast control to essentially achieve similar results and a much better feel when working with log material. As you mentioned, lift gain and gamma are controls that are tailored to and scaled for use with video gamma material, not log original. Since there are currently no pivot controls and no range limiting controls for them, it’s not an optimal way to deal with log material.

[Mike Most]

>Redlogfilm emulates the gamma curve of cineon film scans (although this is a bit of a misnomer as all
> film stocks have a different curve).

It’s not a misnomer at all. Cineon is a defined format that is used to store the information gathered by a film scan. It has nothing to do with specific film stocks. It is simply a way to capture most if not all of the information film chemistry can capture. Think of it more like a codec – if you compress using ProRes, for instance, it really doesn’t matter what camera is doing the shooting. You’re simply taking the resulting video image, compressing it, and putting it into a standard format that other software can then interpret. Same thing with Cineon. The fact that you can see the image is probably a drawback because that’s not an image that is intended to be viewed directly. For more information, you might want to look at 2 posts I did in my blog on this very subject (mikemost.com).

[Mike Most]

>In a purely semantics sense, you’re right. In a pragmatic sense, you’re being misleading. 422 is certainly >”compressed” compared to 444. Technically, this is called chroma subsampling, however, this is a >compression technique.

No, it’s not. Compression is a technique that uses a compression codec to reduce the size of data needed to describe an image or series of images that have already been created, usually by eliminating redundancies, but different codecs use different techniques. Chroma subsampling is chroma subsampling, it’s not compression. Subsampling has been around since the beginning of digital video and is very similar in concept to the scheme used for broadcasting color video since the NTSC standard was developed. You can’t redefine terminology just because the result is similar on one level. Most cars run on gasoline, and some run on electricity. That doesn’t mean that electricity and gasoline are the same thing simply because they can both be used to propel cars.

Redefining terminology just because you think it’s convenient is what is misleading. Data compression is data compression. Chroma subsampling is something else, even if one of the end results is similar. And interframe compression is no more or less “conventional” than intraframe compression. There are intraframe codecs (DNxHD and ProRes are just two among many) and there are interframe codecs (MPEG2, MPEG4, and numerous others). Even H.264 has both interframe and intraframe flavors. The primary reason to use intraframe only compression is to allow proper editing, since all frames are self contained, unlike the “predictive” frames in an interframe compression stream.

[Mike Most]

Technically, that’s true, 3D LUTs are required for color space transforms and any other transform that involves a saturation change. Practically, though, Resolve just seems to prefer 3D LUTs, so that’s what I always use.