Major Gamma / Luma Shift Resolve -> Avid DNxHD MXF Media -> Avid

[Thomas Wong]

Been seeing this as well, been so busy haven’t been able to follow up with it with BM support, and Avid support as well. Dwaine knows about it, but their team claims it isn’t an issue and possibly something wrong on my end. This helps support that there is something wrong.

Have taken footage from prores 4×4 alexa, cineform, etc. Did a quick look, exported out dnxhd mxf in every flavor, media tool into avid, major gamma shift, blacks are lifted. just for comparison, i took the same clips out of resolve and outputted as pro res 4×4, and linked it via ama into the same avid session and toggled back and forth. Def. see a gamma shift.

I have a post up on avid forum too, gonna post screen shoots as soon as I get a chance.

[Mike Most]

What are you monitoring this on? Because if you’re looking at a computer screen, you’re not looking at reality. I’ve done an awful lot of tests between Resolve and Avid using Resolve generated DNxHD MXF files and never had a problem – but I have always monitored video output (through a proper SDI output path) on a properly set up grading monitor for both. They have always been essentially identical. But if you’re looking at the computer screen, all bets are off.

[Bill Ravens]

The problem has been reported to BMD. As of this writing, they prefer to ignore it. Use of the DNxHD codec provides for many internal switches, as described in Avid’s SDK. One of the internal switches in the software is to “remap” all input values assuming the input is full range RGB and output studio range 16-235. The problem arises when 16-235 is input and it is incorrectly remapped to 32-215. It’s a function of the encoding/decoding happening in the hyperdeck.

My own research into the recorded signal shows no data loss due to clipping superwhites and superblacks, however, this is an unfortunate situation. Hopefully BMD will offer a firmware update allowing the user to choose what color range they want to output.

[Joseph Owens]

Have been dealing with this on a daily basis.

I think we’ll find its an RGB unscaled vs. Broadcast linear issue. It appears to be almost uncontrollable inProRes 4444 since you can’t flag it as RGB or Y’CbCr, but if Resolve sees a possibility to unscale the media to full 0-1023, it will. Remember there is a right-click available in all clips to toggle this.

You also have to do more than tick the scaling in Config. Even though there is an Auto- function for selecting scaling in the Render dialogue, and it should follow the project scaling, that is not necessarily the case. This was a bug from a couple of versions ago that I can’t say has been thoroughly exorcised. Try explicitly rendering a few clips with this setting selected to broadcast linear legal.

Also try bringing a few of the previously rendered media clips either into Resolve itself, or somewhere you can scope them. You will likely see that blacks are up around 8-10 IRE and whites never exceed about 90. This is not necessarily a gamma issue to start with, but because of the 0-1023 mismatch, the 2.2 scalar induces one, and makes a “re-correction” back in your NLE of choice very difficult — it’s not a challengeto re-establish a black/white point, but it’s fairly obvious that what’s in between is still screwed, and re-mapping graded media is not the objective here!

I ran straight into this issue on a DnxHD series’ last fall and this was the problem, no question because once the render scaling was fixed, we got cloned values on round trips. I’m seeing it again with ProRes 4444.

jPo

You mean “Old Ben”? Ben Kenobi?

[Paul Korver]

In this case we (and our client) are attempting to view the media from the AVID gui. I just got an email from BMD saying that it is because we are not viewing the Avid media over the Avid SDI out to a broadcast monitor. I find that a bit difficult to believe because the image in the GUI looks seriously different and like blacks are even getting crushed as well as lifted.

Would Avid build a system that looks completely different in it’s GUI compared with what is coming out of SDI?

In this case we are doing Avid dailies for our client and they want to view on set and they don’t have a SDI out of their Avid to a broadcast monitor so they’re stuck looking at the Avid GUI and the DP has serious (and founded) complaints that the dailies look like crap (when they actually don’t).

A side note in our research that also may help the issue is that when we export any flavor of ProRes other than 4444 and bring it into Avid using the AMA workflow the same gamma shift happens (in both rec 709 and RGB avid settings). However if we use ProRes 4444 and ingest to Avid using AMA the color looks perfect in the Avid GUI.

For all tests we were side-by-siding the ProRes clip on the SAME LCD monitor as the Avid GUI at the same time.

I’m fairly certain it’s an avid issue but I’m having a difficult time believing that just looking at it over SDI would fix these issues. And if it did that would be lame because and Avid editor shouldn’t be forced to only see a correct image over SDI… the should see a “ballpark” correct image in the preview / edit GUI as well.

-Paul

[Mike Most]

They’re saying exactly what I said. And they’re most likely correct.

I think a lot of people who used, say, Final Cut, have gotten used to the software compensating for the fact that a computer monitor and a video monitor are two different things. However, the automatic in-GUI compensation made by Final Cut also permeates a lot of other things in Quicktime transcodes, which has led to the rather notorious and universally loathed “gamma shift” issue. Avid doesn’t make any compensations unless you go into the settings and enable it – and I believe that is only invoked when looking at full screen playback. But since HD video is generally assumed to have SMPTE scaled levels – certainly all “non-RGB”, 422 HD video – unless you set up your computer monitor to resemble a video monitor, video that’s properly scaled for video display is always going to appear too light. So you have two choices: calibrate your computer monitor to more closely resemble a video monitor (you can do this rather easily on a Mac by using the Calibrate function under the Displays control panel), or get a video card and feed a video monitor. If you’re using MC6, that’s a pretty inexpensive thing to do now that Avid supports third party video cards (a Decklink SDI card is under $300).

[Bill Ravens]

you guys didn’t read what I posted. Yes, it’s an Avid issue because it’s Avid’s DNxHD codec. BUT, the problem is an apathetic BMD who doesn’t know how to use the codec, and hasn’t read the AVID SDK. There’s a switch inside of the codec to choose the video range. And BMD, in all their wisdom, thinks we, the user, doesn’t need the option.
There’s all a very good writeup on the use of the codec at the Calibrated {Q} website, here….
https://www.calibratedsoftware.com/downloads/CalibratedQ-MXF-UserGuide.pdf

[Jef Huey]

When testing this issue, please remember that there are scopes in the Avid Color correction tool. While basic, they is accurate enough to eliminate the setup of a computer monitor from this whole discussion.

Plus you can take a screengrab and send it off to BMD.

That said, I agree with Joesph on this. We struggled with this constantly at first.

Jef

[Mike Most]

Uhh, right. I’m sure the guys at Blackmagic really don’t care about you or any other user and are just doing things to make it easy for themselves, while they continue to screw up their customers and sit at their desks in Singapore laughing about it.

Perhaps it might be a bit more constructive to report the issue as you see it, direct that to one of the engineering team leads (perhaps Rohit, who posts here quite regularly and is very attentive to users’ issues), and see what they have to say and/or if they can reproduce your problem. My feeling is that approach might get a bit more positive action than essentially calling the company a bunch of aloof, incompetent programmers who don’t care about what their customers do or need, and essentially trying to tell them how to do their job. I really don’t mean to go off on you or anyone else here, but if I were a Blackmagic engineer, that would probably be my reaction to what you posted.

Just a thought.

[Bill Ravens]

Mike,
Of course, you’re quite right. Jumping to insinuation and borderline insulting is really not very effective. So, let me elaborate. This issue has been reported on the BMD COW site, as well as in an email to BMD Customer Support. Their response has been nil.

It is exceedingly frustrating to have to work to customers expectations while dealing with color issues. I’m sure you understand what I mean. My apologies for seeming to offend anyone. I would just like some sort of response from BMD that says they recognize a problem…or not…..something that says they heard the complaint from myself and others. I’m not alone.

Given that this is beta firmware, I have to take what I get. Nevertheless, it would be nice, as I said, to think they are on top of this issue….or if they feel the problem is entirely my fault, that they at least offer that, as a response.

My biggest concern is that there is data being lost in the shadows and highlights. Having some feedback from BMD that this is not happening would certainly help out. But their silence is the issue.