143
Replies
Thanks for your quick reply. As for it being overcooked - yes this is very true. That's why not I'm not fully happy with the DVR conversion either. But I'm not that experienced in the Danvinci color controls - I just wanted to brighten the dark region a little and yeah... I recorded the scene intentionally darker, so I could capture everything from the sky.
Here is the same scene in DVR. My target is a gamma of 2.2 since that historically worked best for me.
Going via the intermediary color space is closer to what I want to archieve. But does this mean it does something non standard behind the scenes?
What catches me offguard here is that, apparently Gamma 2.2 doesn't mean the same thing in both programs. Using viewer Gamma 2.2 in Premiere Pro needs a conversion to gamma 2.6 in DVR to get a visually similar brightness. Anyways, that's not my main concern here. 🙂
But would it make sense than for me to basically create a LUT (which gives me a closer gamma) I apply in the input section, to "fix" this for me?
Keep in mind that the Shadows and Highlights sliders in DVR are spatial effects. Premiere/Lumetri do not have such operations in their grading tools.
By @Shebbe
I've already noticed that these won't stick in the LUTs I exported from DVR.
After I get the look correct in Premiere, I wanted to test, whether it would work, if I applied those spatial effects in DVR in the intermediary color space and exported it back as NLOG. Basically for "more difficult" scenes.
DaVinci uses a per channel style tone mapper by default. You can set Premiere's to "By Channel" to get a more similar look. You can try the Brightness & Contrast effect to add contrast if you feel like the range of Lumetri's sliders are too limiting. The brightness slider is the equivalent of Offset in DVR and contrast is the same as that of DVR too if "Use S-Curve for contrast" is disabled.
By @Shebbe
Thanks for mentioning that. I tried that out and it does look very similar if it is set by channel.
Overall the conversion in Premiere Pro does look a lot better than it used to for me. Last time I tried the NLOG workflow in Premiere Pro I had to deal with a lot of off color and burnt out hightlights. Which kind of caught me offguard and made me not use NLOG for the time being.
If you can get by with the more simplistic approach without ACEScct that's great nothing wrong with that.
"Is there than still a reason to use any input log if you overwrite the media color space anyways?"
What do you mean exactly?
"Considering the gamma - would it then be better to just work in 2.4 and apply the gamma correction on export to save the headache?"
From the perspective of mitigating the differences and washed out presentation it would probably be more practical to disable display color management and work on an sRGB display, then grade towards what you want to see and call it a day so no extra operations are required in the delivery process.
"The only thing that seems pretty clunky for me is, that you have to switch between the settings and edit edit tab in Lumetri color to dial the footage in. Will this always stay in the settings tab or could this be placed at the top spot in the edit tab in Lumetri?"
This is a really good question/feature request and requires some considerations.
@Alexis Van Hurkman do you have any thoughts on that?
I think that it's great that there is a scene-referred, managed exposure slider available even when using Direct Rec.709 where this especially matters since that of Lumetri's is based on normalized content. But it is incredibly cumbersome that you'd have to switch back and forth. I can think of two possible solutions.
1. As @Agrarvolution suggested, move the entire sequence clip management over to the main Lumetri Panel as a management step before the Basic section.
Example:
2. Transform the Exposure slider of Lumetri itself to function the same as that of the sequence clip one. This is more complex and requires an inverse DRT for all tonemapping methods but that will inevitably need to be made anyway to make ACEScct workflows work...
I personally would favor option 1 as this cleans up a lot of the messiness that is currently on the management page which mostly comes from the fact that it is all possible features from global/display related down to a clip in a sequence is presented as a flat list of sliders and dropdown menus. It also allows the editor to become more aware of the state of how the clip is processed at any point in the production without the need to go to Lumetri's settings to look for it.
Looking at your new examples it's looking a lot more sensible. One of my initial feedback on Premiere's color management was that I felt they were putting the shadows/black very high and overall perhaps a little too sparse on contrast but it generally serves as a usable starting point. It would probably be a bit better if they added a bit more so those that don't want to color correct or grade can use it out of the box with a good look.
We have a lot of customers that are looking for the most straightforward, standards-based mathematical conversion of one format into another, without any bias for making signals look more attractive. I've always viewed the underlying color management that we're providing in this first version as management of your media, and not the grade itself, so that's the spririt of this first release.
Down the road, there's plenty to explore in terms of providing options for more opinionated output, perhaps in the tone mapping, perhaps via other means, and we're exploring what makes the most sense going forward. However, these fundamentals are intended to provide the best starting point for grading, to do no harm to the image, and to be as standards-based as we can.
I kindof feared that I didn't express well enough what I am doing, when I sent the last post.
But it seems like I can't reproduce the issue anymore now. This morning there was another Beta update, so I might be confusing what happened with Build 18, in which I worked in this morning as well.
But here is hopefully a better explanation anyways:
Basically all my footage is nested in subsequences, so I can sync it with audio tracks and other stuff that is related to the footage itself, while Ia m avoid cluttering the main timeline.
The grading is done in the subsequence, this is where I did the tonemapping and applied the grade. But the NLOG color profile is applied to the footage (obviously).
But I can't check if I used the correct display for the main sequence now, since I can't reproduce it anymore. But I know that the little grading I applied to bring the contrast up to the amount I want for the footage was still applied, since the display did change and brighten when I turned all effects off.
So it might be fixed already or not - I don't know.
The converison is applied in the subsequence and the subsequence is outputting Rec.709.
The mainsequence has no conversion and is just Rec.709.
If I nested it like you discribed (which I tried when I got into things), things didn't work.
When you say Premiere Pro doesn't apply it - why does this than work for me?
Here is how it is set up:
It just seemed pretty logical to me to "encapsulate" the color space stuff in the subsequence - so I can do whatever in the main sequence.
Hey @Chetan Nanda , I'm finding some inconsistencies.
When I create an ACEScct timeline and place it in a fully unmanaged timeline, it becomes a Rec.709 un-tonemapped image in the viewer when Display Color Management is enabled. This means that the data does get converted from ACEScct ('metadata' from the timeline's clip?) to the display. Attention to -> to display, rather than to the new timeline because it does not have color managemenet enabled. This is weird don't you think? It means Premiere still enforces certain conversions even when the user says not to? This oddity is not observed on Media Files, only on Sequences and I think this should be disabled.
I can set the new timeline to Direct SDR and re-enable tonemapping but in this case Input Tone Mapping to tonemap the still high dynamic range of the nested timeline to the new Rec.709 based timeline. This can, when choosing the same tonemapping method as used on output in the ACEScct timeline, result in the same appearance.
This part totally makes sense to me and is also neatly reflected in the information given in the settings.
Back to the display management oddity, it's actually equally weird that for Media Files you still see the gamma 'shift' conversion from 2.4 to display in a Disable Color Management timeline. Where is it even expecting that the intended timeline space is Rec.709? This setting seems to be removed for this context. So what the viewer does when you load a log or HLG clip is also incorrect? Unless I'm not understanding something here...
Resolve uses a mechanism in unmanaged mode that allows you to specify both a timeline working space and output space. The timeline choice is intended to define the grading space for sake of Color Space Aware effects/tools and the output space is for sake of how the scopes should read the data and what the auto tagging should do on exporting files.
Perhaps it is good to think about a similar mechanism to make colormanagement more flexible, consistent and predictable.
AdChoices
