Decklink HD extreme Gamma Shift

[Luke Maslen]

Hi Alex,

Presumably this is not a new problem for you as I believe this problem has existed at least back to the start of Final Cut Pro 5.0? The Apple uncompressed 422 codecs automatically adjust the gamma of your video to match the display which you are using. This is an area of some controversy as we don’t think that’s a good idea and would prefer that gamma be left alone.

The video that you see on your broadcast monitor is output via the Blackmagic card and we don’t tinker with the gamma so it should look as expected. When making comparisons, look to the broadbast monitor for the real gamma.

The gamma filter that you downloaded from our web site is not relevant to this case. It was designed to help people who had previously captured files in the Blackmagic codecs (in Final Cut Pro 4.5 and older) as they didn’t adjust the gamma. When those same files are used in Final Cut Pro 5.x a gamma shift could be seen and so the filter helps avoid that.

Regards,

Luke Maslen
Blackmagic Design

[Accountneedsrealnameupdate]

Thanks for that, it makes sense.

However it is a real problem when I need to send a QT to a client for approval, after it has been captured by the Decklinck card.

What would be the solution to this?

Thanks
Alex

[Dean Decarlo]

First solution is to really understand the problem. We had a lot of pain on this one. Here is Apple’s explanation.

https://docs.info.apple.com/article.html?artnum=93794

Apple is doing you the “favor” of automatically adjusting the gamma of your footage to emulate the broadcast gamma on your computer monitor. This wouldn’t be such a problem if a.) they made it clear that the software was doing it and b.) that there was a way to defeat this behavior!

I’m on PC so the problem has only been with interchange between PC and Mac. It will happen with anything that Quicktime considers a “video” codec. In that link Shake is used as the example of any normal software that doesn’t screw with the gamma upon input. Their solution of adjusting the gamma by .818 to correct it is absurd as they are changing the gamma and then suggesting you adjust it back with a color correct. How about not changing it in the first place unless requested?!? Apple making things “easy” again… grumble grumble…

P.S. They mention at the tail of that link (and I found this out the hard way) that the Animation codec is also effected by this gamma change even though not really a “video” codec. Thanks again Apple!

[Luke Maslen]

Hi Alex,

As Dean has mentioned, it is no longer possible to correctly view the movie based upon what you see on the computer screen using Final Cut Pro 5.x. If the client wants to see exactly what you are seeing, they should also view on a broadcast montior to see the unaltered gamma.

Regards,

Luke Maslen
Blackmagic Design

[Accountneedsrealnameupdate]

Thanks guys, helpful stuff.

However the gamma adjustment doesn’t occur only in FCP, but also in QT. So does that mean that if I capture it via FCP there is some kind of gamma adjustment embedded in the file that will make it appear like that in both QT and FCP?

If I open the same clip in Shake the gamma will look right (sorry, can’t check right now, not at the office, but would still love to know!!).

Thanks again, great to know that I’m not doing something wrong in my capture..

Alex

[Luke Maslen]

Hi Alex,

You are correct. You will see the automatic gamma change happen in both QuickTime Player and Final Cut Pro as the gamma issue is controlled by QuickTime itself and potentially affects any QuickTime-based application. Shake works a little differently as noted in the article referenced by Dean and “… makes no automatic changes to the gamma of QuickTime or RGB image files and sequences.”

This issue is a source of much confusion but at least is does mean that there is nothing wrong happening with your captures.

Regards,

Luke Maslen
Blackmagic Design

[Dean Decarlo]

I’ll chime in again here. My experience was that when taking clips from FCP over to PC that the gamma of each clip was embedded so that when the clip was opened in any app that could read quicktime (in my case I was using Combustion) the gamma was read using stored gamma in the quicktime file which was a “corrected” gamma to allow the 2.2 gamma broadcast footage to display in pseudo broadcast mode on a 1.8 gamma computer monitor. So even though, as I understand it, it is intended to be a display correction it ended up screwing up a bunch of renders as the footage came in and rendered with this incorrect gamma. Apple’s solution of applying a .818 gamma correction to resolve it basically reverses the display correction but I would imagine throws out some of the luma range. Not sure of that but I don’t like adding artificial color correction to footage just to get it to look like it did on Digibeta in the first place. My solution for now it to interchange with FCP using uncompressed codec only. That doesn’t seem to have this problem. Maybe they’ll fix this in Quicktime V8. Good luck!