Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Davinci and Premiere footage differences

Joel Arvidsson

Joel Arvidsson

Well-known member
Joined
Nov 3, 2008
Messages
3,044
Reaction score
6
Points
38
Age
46
Location
Sweden
When importing rendered clips from davinci into premiere they looks just little flatter. If I add 10% contrast its looks about right.
This is with dnxhd 444. Not a big problem but it keeps bugging me. Changing from data to video output in davinci makes no difference.

Would guess its the the lovely quicktime wrapper that messing a touch with the gamma.
 
I see this with DNxHD and Prores (though a bitter darker with Prores). This does seem to be a characteristic of the codec. Generally, I render 10bit uncompressed from DaVinci and I don't see any shifts between Premiere and Resolve.
 
Joel,

For a film-out we processed last year, we render out of Resolve the entire 5 reels as Uncompress QT since it facilitates the conforming process. Actually, if nothing has changed in Resolve, that is the way to go with a FCP round-trip since it is not capable to do it directly with DPX. Then, from the uncompressed files, we generated the DPX sequences from FCP (using Glue Tools), and it rendered perfect Log images that the lab was able to print into film without any further adjustment.

Hope this helps,
 
I believe DnxHD will alway used "Legal" vs Full range. It is part of the codec, so changing it in Resolve wouldn't make a difference. And that's probably why adding a little contrast works.
 
And with native MXF/DNxHD coming to the next version of Premiere Pro, the QuickTime wrapper interference will go away.

Michael
 
If you're using a blackmagic mini monitor or other type of hardware output, there shouldn't be any difference between FCP, Premiere, or Davinci when viewing the same file, but there will be noticeable differences if you're only using software output to a second monitor.
 
I've been using DNxHD lately only because it's faster to playback in Premiere CS6 vs Uncompressed 10bit, and Prores is not an option on Windows for me right now. I've also found the ouput to be a lot flatter than what I'm seeing in Resolve. Quite annoying really...
 
Bruce Johnson said:
I believe DnxHD will alway used "Legal" vs Full range. It is part of the codec, so changing it in Resolve wouldn't make a difference. And that's probably why adding a little contrast works.
Click to expand...

DNxHD will certainly use full range. It doesn't care. It's how the player or NLE interprets the codec, which is often times influenced by the wrapper, e.g. QT.
 
It's the difference between "white" and "super white". It's a setting that you can change upon import (you can in EDIUS anyway).
 
MichaelP said:
And with native MXF/DNxHD coming to the next version of Premiere Pro, the QuickTime wrapper interference will go away.

Michael
Click to expand...
Sounds great!

I started with dnxhd to get smooth playback in premiere. I got pretty smooth playback with uncompressed but sometimes i drop a frame.
Dnxhd gamma shift is not that bad as its easy to fix since the colors seems to be true to davinci. I wll get cineform and se if it will have any shifts.
Mean while i just stay uncompressed for master.
 
Joel Arvidsson said:
Sounds great!

I started with dnxhd to get smooth playback in premiere. I got pretty smooth playback with uncompressed but sometimes i drop a frame.
Dnxhd gamma shift is not that bad as its easy to fix since the colors seems to be true to davinci. I wll get cineform and se if it will have any shifts.
Mean while i just stay uncompressed for master.
Click to expand...

Learn about super whites and blacks. That is probably what is causing the issues you have.

Simply explained, super whites and blacks are what you find outside the 16-235 range of a 0-255.

Basically.
Some programs take the 16-235 of the image and stretch it to the full 0-255 range for display and by doing so they clip whats above and under.
Other programs take the 0-255 and squeeze it to 16-235 or "legal values" as they are called. It comes from analogue broadcasting where the top and bottom values could not be used as to high or low values could damage broadcast equipment and such, at least thats what im told.

So basically if your image is going flat then your setup is most likely taking your image from 0-255 to 16-235. This is fixable, worse is the opposite, as then you are clipping the image high and lowlights. The best way to fix it is to apply a lut that take the 16-235 and expand it to full 0-255. If I was on my flame and not on my couch I could make it for you.

Another way to slice it would be to apply 11,7647% more contrast. That is 30/255 which is the difference of the two colorspaces. And most color correctors would probably maki it right if their math is right.

But there is one more thing to be aware of... That is the fact that some programs takes the image and put your black point to 0. So then your image that was 0-255 goes 16-235 and then falls down to 0-220.

Such image needs to have lift and contrast applied accordingly to get back to 0-255.

It's odd it's now 2013 and this sh#"&%it is still troubling us, I though we would be living on mars by now, instead we sit here and have different codecs messing up our colors. I can honestly not understand why the colors can not be preserved when jumping between codecs and players. But apparently that's how it is. So we are not moving to mars any time soon.
 
Matthew Scott said:
It's the difference between "white" and "super white". It's a setting that you can change upon import (you can in EDIUS anyway).
Click to expand...

Do not know if you can do it in premiere. But yes, thats the cause of it all.
 
In this scenario, it's most likely the wrapper, not the codec - the codec is what it is - QuickTime is notorious for trying to "correct" the image to look good rather than just leave it alone. I have done many transcodes from Resolve with LUTs and such to DNxHD to Media Composer directly as MXF/DNxHD, and they all match black and white levels and such when looking at the scopes. The default setting in Resolve knows that the DNxHD codec you are going to is Rec.709. If you select full range, then it will stretch blacks and whites. But if you correct in Resolve without scopes or Rec.709 monitoring and make black at 0, it will stay at 0 in the codec. I do not believe that Resolve constrains or clamps to Rec.709 levels on output. Redcine X Pro has this as an option: "SMPTE Legal".

Michael
 
I ran into a similar problem. Exported ProRes422 from Davinci and it becomes more contrasty in Premiere along with some highlight clipping, whereas an exported ProRes4444 will match once it is back in Premiere. (both set to "unscaled full range data")
What does the Video Levels vs. Data Levels in preferences technically change?
 
I've been experiencing this problem since 2010. First i admit i don't know much about setup....i'm middle of the road on this...i understand 0-255 and 16-235. BUT, it seems this can be due to program we are suing...FCP or FCPx or Premier.....but in those 3 programs, i'm completely unaware of HOW or where to setup full range or 16-235---something that is HUGELY important....but where would we set that range? I'm assuming in RCX it is 0-255 until you set SMPTE legal--yes? then SMPTE legal clamps to 16-235 ?

So....when starting a project and grading...would you setup your project and first select SMPTE legal or 16-235 ? This to me is the maze....and those real grading progams like Resolve, Scratch all seem to have multiple ways to setup monitoring etc....but can't seem to find it within FCPx and Premier.

Here's my similar issue back in 2010 with screen shots: http://www.reduser.net/forum/showth...des-to-Prores-4444-look-WASHED-OUT&highlight=
 
I had previously experienced this too and used "levels" in Premiere to expand the values back out to 0-255. However, I think this is Quicktime related. Now that Premiere Pro CC supports writing and reading .mxf natively I've just been spitting .mxfs back out from Resolve and the problem seems to have disappeared completely.

Now if only DNxHD supported higher than HD resolutions, we'd have a free, platform agnostic, gamma-problem-free, future proof intermediate format!
 
You must log in or register to reply here.
Back
Top