Welcome to our community

Be a part of something great, join today!

Register 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 :)

Lack of a True Uncompressed RGB 10-bit in Resolve

Luis Otero

Luis Otero

Well-known member
Joined
Dec 31, 2006
Messages
1,130
Reaction score
0
Points
36
Location
Orlando, FL
Peter,

I was told that the BMD 10-bits, RGB Uncompressed "codec" is the one called "QuckTime Uncompressed RGB 10-bit" in Resolve. However, whenever I try to use it, a big gamma shift is always observed. I have tried MANY times to contact BMD, via multiple methods, but I never get a response. Most of my projects end as DPX sequences, which does not alter the gamma. However, now I have a project that the client wants it as an Uncompressed RGB 10-bit file, but the gamma shift is too disturbing.

Again, I know I have been asked me to use BMD support page, but everything goes into a black hole, and not a single answer...Very frustrating.....!!!!:emote_hanged:

Please, advise ASAP,
 
Alexander,

Thank for the advise. Believe me, I have tried every avenue withou a resolution. ;-(
 
Gamma shifts are only a function of how QuickTime DISPLAYS the file. It has nothing to do with the levels of the file itself. There is no way around this in any QuickTime-wrapped format, because you are always using QuickTime at some level to either display the file to the screen - or to act as the middleware to "present" that media to another QuickTime-compatible application. If you don't want the gamma shifts, then don't use anything QuickTime-based. Use DPX or use MXF. This includes not using QuickTime as the media player.

- Oliver
 
Oliver,

I can see and use the BMD RGB 10-bit uncompressed "codec" (without the QT on their name) on other software, and they do not change the gamma.

However, on Resolve, there is a RGB 10-bit uncompressed "codec", but it contains QuickTime on its name. I was told by a BMD professional that it is the same, but clearly it changes the gamma as typically QT does.
 
I'm not exactly sure what not having "QT" in the name means, but I presume they are still both QT-wrapped files. The gamma shifts result from the profiles embedded into the file and what QT expects to see. QT 7 and QT X will both yield completely different results from the exact same files.

Where are you actually seeing these gamma shifts? Normally the output through professional applications to a proper grading monitor will look the same through the output of a card, like the Decklinks or Konas, even if they look different on a computer screen.

- Oliver
 
Oliver Peters said:
I'm not exactly sure what not having "QT" in the name means, but I presume they are still both QT-wrapped files. The gamma shifts result from the profiles embedded into the file and what QT expects to see. QT 7 and QT X will both yield completely different results from the exact same files.

Where are you actually seeing these gamma shifts? Normally the output through professional applications to a proper grading monitor will look the same through the output of a card, like the Decklinks or Konas, even if they look different on a computer screen.

- Oliver
Click to expand...

We do not use computer screens for reference. We have all of them calibrated, but our reference image is the one projected on a screen. If I am watching it from Resolve to my projector via DeckLink - HD-SDI - HDLINK, it looks, well...perfect. After rendering from Resolve (uncompressed 10-bit, ProRes 422, ProRes 4444), using the same path, but opening it , let's say, using Blackmagic Media Express player, the gamma is shifted, let alone Final Cut...:w00t:. However, if the export from Resolve is a DPX sequence, the pristine quality is just as it is seen directly from Resolve.

Now, are you saying that if I open it with QT 7 Pro, it will look different from current QT version? I have to try that process.
 
Luis Otero said:
We do not use computer screens for reference. We have all of them calibrated, but our reference image is the one projected on a screen. If I am watching it from Resolve to my projector via DeckLink - HD-SDI - HDLINK, it looks, well...perfect. After rendering from Resolve (uncompressed 10-bit, ProRes 422, ProRes 4444), using the same path, but opening it , let's say, using Blackmagic Media Express player, the gamma is shifted, let alone Final Cut...:w00t:. However, if the export from Resolve is a DPX sequence, the pristine quality is just as it is seen directly from Resolve.

Now, are you saying that if I open it with QT 7 Pro, it will look different from current QT version? I have to try that process.
Click to expand...

Sounds to me like you're taking a file that is already SMPTE scaled data and rescaling it on output. Try changing the display format to full range data and see if there's a difference (there should be).
 
Luis Otero said:
After rendering from Resolve (uncompressed 10-bit, ProRes 422, ProRes 4444), using the same path, but opening it , let's say, using Blackmagic Media Express player, the gamma is shifted
Click to expand...

I believe once you've rendered it, it is a QT file. Media Express is playing back a QT-compliant file, not your original media or DPX files.

Luis Otero said:
However, if the export from Resolve is a DPX sequence, the pristine quality is just as it is seen directly from Resolve.
Click to expand...

This would seem to confirm the suspicion.

Luis Otero said:
Now, are you saying that if I open it with QT 7 Pro, it will look different from current QT version? I have to try that process.
Click to expand...

Some codecs (like Avid DNxHD) display with different levels in QT X and QT 7. Neither is necessarily right.

- Oliver

PS: Mike's suggestion is always quite likely.
 
quicktime X and qt 7 don't look ANYTHING alike, I don't use qt x anymore, qt 7 always seems "truer" to what my original source was. have you tried the BM uncompressed qt, the one with the black magic label on it? this is really the bane of quicktime. do you also have access to after effects? I've had numerous success with rendering out dpx, then taking it into AE, and converting to QT from there. AE does a really good job of rendering out and staying in RGB (minus with pro res a few versions back)
 
Mike,

The file is full range (0 - 1,023). The problem is the stupid QT. If I open it on QT 7 Pro, it looks exactly. Also, I tried the DPX conversion, both via GlueTools and AE, and both are rendering reliable files (no gamma shift at all), as long as you use QT 7 Pro to play it.
 
Gabriele Turchi said:
did you try switch the sdi to full range ?
Click to expand...

Gabriele,

We keep that parameter always on full-range.

What I feel is ridiculous and bothers me is the fact that if I render from FC or other software that offers the BM Uncompressed 10bits option as one of the codecs, it DOES NOT have a gamma shift.

However, the only Uncompressed 10bit option offered by Blackmagic's own Resolve (called QuickTime, not BM), does create gamma shift. Go figures...
 
do you experience the gamma shift over the SDI playback or over the QT player (after the render)?

ps:why you keep always the SDI in full range ? you do film out work ? because for broadcast should stay on scaled ....otherwise everytime you render YUV codec you will have different level reading in FCP , QT , FLAME

g
 
Gabriele,

The gamma shift is observed, after render, both via SDI and player. As to why always in full range, our clients are almost exclusive producing for film/DCP. We change it when, and if, we are asked to provide a broadcast safe version.

Jake,

I did it a while ago as a test (really long time ago), and I remember that there was no gamma shift, so it worked. I will try it tomorrow with the footage of this project. I completely forgot about it...so thanks for point it to me!
 
Well, it seems that I was able to get an almost-final workable new pipeline. See the "investor's teaser" put together today following the procedure. The only different among both versions is the soundtrack.

http://www.vimeo.com/23691962

Hope you can enjoy it.

Cheers!
 
You must log in or register to reply here.
Back
Top