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

AVID / REDCINE-X output mismatch

M

martinnoweck

Well-known member
Joined
Feb 18, 2007
Messages
994
Reaction score
0
Points
16
Hello,

I transcode RED Footage with REDCINE-X (with ROCKET) to AVID MXF (DNxHD 36) and made the following observation:

- watching the footage via HD-SDI out directly from RED ROCKET the picture looks fine
- after transcoding to AVID MXF and checking the transcodes in AVID Symphony 6 via AJA Kona 3 (also HD-SDI out, same Monitor, just switching the Monitor Inputs) the picture looks desaturated, not as "punchy" as from the RED ROCKET out

Any thoughts / tips?

Best wishes and kind regards,
Martin

P.S. I am on Mac
 
Are you trancoding with SMPTE levels when going to DNxHD and looking at full range when monitoring out of RCX?

Michael
 
Michael, thanks for chiming in:
- yes I am transcoding with SMPTE-Levels "checked" in the REDCINE output dialog
- I set the monitor out of RCX to YUV422

Is there a proper way to setup the AJA in combination with AVID?
best wishes and kind regards,
martin
 
When you import a clip to Avid, it gives the option to use 709 vs RGB levels. If you are scaling to SMPTE levels during the transcode, you need to make sure Avid is set for 709 levels too. Or you can uncheck that SMPTE levels box and then set Avid to RGB levels. Either way is fine I think, as long as both settings match.
 
Elliott Balsley said:
When you import a clip to Avid, it gives the option to use 709 vs RGB levels. If you are scaling to SMPTE levels during the transcode, you need to make sure Avid is set for 709 levels too. Or you can uncheck that SMPTE levels box and then set Avid to RGB levels. Either way is fine I think, as long as both settings match.
Click to expand...

@elliott: There are no levels to set when creating native DNxHD files in third party applications.
@martin: although set to YUV422 in RCX, are levels set to 16-235 for black and white levels? As far as AJA -I am not familiar with the settings for black/white levels and where to find that. Some hardware may scale 0-255 to 16-235 squeezing full range to SMPTE levels, and some may clip. Take a look in the video output tool settings from Media Composer to see if there is any control there. I would also do a quick test and check waveform/vectorsope settings in RCX for a frame and compare to waveform/vectorscope in MC to ensure they are close.

Michael
 
It may or may not - when you look at the levels in Redcine X scopes, where are the black levels? And looking at the same in MC scopes, are they close?

Michael
 
Michael,

thanks for your reply - when I lower the black level in redcine-x to 0% (on the redcine scope) and export to avid dnxhd36 MXF and look into the mediacomposer scope after import the same frame shows 16 ... I will do another test, where I will uncheck the clamp to legal (restriced smpte range) in redcine export settings.

best wishes and kind regards,
Martin
 
It seems as though the scale to SMPTE feaure always assumes that the source are corrected full range and then when making DNxHD dailies (a rec.709 codec) will 'scale" o to 16 and 255 to 235 evenly on both sides leaving middle grey alone. But the issue might be that it does this regardless of whether the images were adjusted for proper rec.709 levels in Redcine X and still makes what was black at 16 higher than that after the transcode. If you correct to 16-235 range, then do not scale to SMPTE levels for the encode process.

Michael
 
MichaelP said:
It seems as though the scale to SMPTE feaure always assumes that the source are corrected full range and then when making DNxHD dailies (a rec.709 codec) will 'scale" o to 16 and 255 to 235 evenly on both sides leaving middle grey alone. But the issue might be that it does this regardless of whether the images were adjusted for proper rec.709 levels in Redcine X and still makes what was black at 16 higher than that after the transcode. If you correct to 16-235 range, then do not scale to SMPTE levels for the encode process.

Michael
Click to expand...

I have to say I don't understand why somebody would correct to 16-235 range in REDCINE-X. To the best of my knowledge REDCINE-X is designed to work full range, and that is why the "scale to SMPTE range" option is there. The RED gamma curves are full range, rolling off highlights to 255 (or 1023, or 1.0 but let's stick to 8-bit numbers for simplicity). REDCINE-X multiplicative operations assume zero is black. But most importantly the SDI output of the Rocket is SMPTE range, so has a hardware level adjustment, meaning if you manually compress everything to 16-235 in REDCINE-X, the SDI output will be double compensated.
 
Well I think that is where things need to be thought through ahead of time - again, DNxHD is a Rec.709 codec, and in 8 bit terms has black at 16 and white at 235. In the Redcine X pipeline, be aware of what scales or gets compensated for either as file-based export or over the SDI output. Having settings for that would be handy as dailies are most always Rec.709 and having a basis for consistent monitoring is key. Does the SDI out double compress when selecting Rec 709 as output gamma? I usually work 0-255 full range within Redcine X then set SMPTE levels in the DNxHD export settings.

Michael
 
MichaelP said:
Does the SDI out double compress when selecting Rec 709 as output gamma?
Click to expand...

No, the Rec709 gamma option in REDCINE-X is just the pure mathematical Rec709 transfer function, and has nothing to do with 16-235 levels. It is also really just there for historical completeness, as it was there on the original RED ONE, before the newer curves (which include a tone mapping function as well as gamma) were introduced.

I believe (and I'd love Graeme to chip in on this to confirm) that because the linear sensor black level on the RED ONE was set to 12-bit code value 50 in the ADC (to preserve the noise floor) and when this value is passed through a Rec709 transfer function it comes out at 8-bit code value 14, this is close enough to 16 that people mistakenly believed that the code values were meant to be treated as SMPTE range. I believe RED's intention was in fact that the user should sit the blacks down to zero, or near zero, as a creative decision using "shadow" or other controls.

The QuickTime writer in REDCINE-X when writing ProRes movies takes the full range image data from REDCINE-X and scales it to the SMPTE range values ProRes uses internally. Whether this is coded into REDCINE-X or it just uses the built in levels adjustment in the QuickTime API I do not know. But in any case, if you take the same clip and render it out as a ProRes QuickTime with "use restricted SMPTE levels" off, and a DNxHD MXF with "use restricted SMPTE levels" on, those two files match perfectly in terms of levels. I just confirmed this in Media Composer, Resolve and Baselight. I don't have a Media Composer with an SDI output here, but I know that the ProRes file viewed on the SDI output of FCP7 matches the SDI output of the Rocket.

Of course it is possible to work to the 16-235 range in REDCINE-X, using the RED SDK parameters to restrict your levels. But given that the two ways you can monitor while working in REDCINE-X are via the SDI output of the Rocket, with its hardware full to legal range scaling, and on the computer monitor, which is inherently full range, I don't see any point of doing so, when you can work full range and apply a mathematically accurate scale with the "use restricted SMPTE range" option when you render. As you say, the latter is what you normally do.
 
Interesting conversation here: So this then would apply to any workflow, not just AVID. So for those of us grading in RCX and outputting to Prores or any other codec and noticing a color shift--what many continue to call an Apple Gamma shift may then only be that RCX is grading in full range and then when transcoding to Prores or other codecs it's becoming clamped to 16-235 range? If i got this right....Now, Even if that's the case, would this clamping of the colors to SMPTE levels cause the desaturation of colors? Is that even possible?

I'm on a similar path since 2007 where i can NEVER get RCX looks graded in Redcine via RR card out SDI to a REC 709 monitor to look ANYTHING like the original grades in RCX. So what i hear Nick saying is this is somehow getting double squeezed? So would turning off REC709 and switching to Full range on one's monitor allow for a closer transcoded look? Sounds like Prores will squeeze to 16-235 levels? So if going Tiff or DPX, we should not experience this color shift....That said, i've always gotten a color shift when transcoding to DPX or TIFF, but this might make sense if i'm viewing my output on a rec709 monitor and not in Full range.

Sure would be nice to figure this out after many years.....
 
Johnny Friday said:
...when transcoding to Prores or other codecs it's becoming clamped to 16-235 range?
Click to expand...

No, it is being scaled not clamped to 16-235. And most applications which read ProRes expand it back to full range on playback.

Johnny Friday said:
I'm on a similar path since 2007 where i can NEVER get RCX looks graded in Redcine via RR card out SDI to a REC 709 monitor to look ANYTHING like the original grades in RCX.
Click to expand...

I find that on an external broadcast monitor (and scopes) I get a perfect (or as near to perfect as makes no difference) match between ProRes QuickTime, DNxHD MXF and a DPX sequence. The DPX sequence is a good reference, as being uncompressed RGB, the image data is identical to that being sent to the screen in REDCINE-X. It is important to be clear that this is on an external broadcast monitor, and that is what I treat as critical.

I believe that differences that people experience are due to playing back QuickTime movies on a computer screen in different applications. There adjustments are being made to the image as it is displayed, and different applications do different things in terms of gamma, levels and colour profile. Indeed QuickTime Player X and QuickTime Player 7 can display the same movie slightly differently (how differently depends on if "Final Cut Studio Compatibility" is switched on in QuickTime 7 player preferences, and also the ColorSync setup of the machine). This is what is hard to control for. If you are targeting a deliverable to be seen on a computer screen, then you need to thoroughly test your specific pipeline, and you need to accept that some things will be beyond your control.
 
You must log in or register to reply here.
Back
Top